Впровадження проєктів автоматизації обліку

Вічні впровадження — це реалії життя майже кожного фінансового керівника.

Спостерігаючи за цим процесом багато років і беручи участь у ньому як проджект, бізнес-аналітик, розробник і тестувальник, хочу розповісти про чотири типові сценарії, як відбуваються проєкти автоматизації фінансового управління в різних компаніях. Це буде цікаво і стане в пригоді тим, хто запланував ІТ-проєкти на наступний рік.

Сценарій звичайний із всеосяжною назвою «Перший раз»

У компанії приймають рішення про перехід на нову програму обліку, бо далі так жити не можна: кількість даних збільшилася, процеси змінилися, всі стомилися від помилок у розрахунках у розподілених базах даних.

Купують новий софт, кимось рекомендовану конфігурацію, і налаштування відбувається самотужки за участю представника компанії софту, який відповідає на запитання і пропонує використовувати той функціонал, який вважає доречнішим для конкретного випадку.

Робота кипить. Заповнюють довідники, конвертують дані, під час процесу з’ясовують, що не все зручно у базовому функціоналі, і тоді починають проводити зміни в коді та отримують рахунки на доопрацювання софту. Минають тижні, місяці, роки. Картинка обліку формується поступово, з планами доводиться почекати, з’являються складнощі у відстеженні окремих процесів, бо про них заздалегідь не подумали. Тому купують ще один софт для розширення функціоналу, з’являються проєкти з інтеграції кількох рішень, система ускладнюється і дорожчає. Виявлені елементарні помилки дратують усіх, а суми рахунків на супроводження натякають на те, що це не скінчиться ніколи.

10 типових причин буксування проєкту

Чому ці проєкти безкінечно буксують? У них, як правило, цілий букет типових причин:

1. Немає реального керівника проєкту, який добре розуміє архітектуру даних і бізнес-аналітику конкретної діяльності. Такі компетентні співробітники у штаті вельми цінні, в аутсорсі їх послуги дорожче втричі, або їх нереально знайти взагалі.
2. Немає реального досвіду успішного впровадження у команди проєкту, вони навчаються разом із замовником і думають, що роблять правильно.
3. Немає повних виявлених і розроблених функціональних вимог, блоки завдань формуються стихійно.
4. Немає стадії передпроєктної бізнес-аналітики, не зважають на рівень організаційної зрілості, постановки ключових бізнес-процесів, на плани змін, які вже стартують.
5. Бракує фахівців для виконання завдань щодо проєкту: внести та перевірити дані, продумати структуру аналітики, перевірити ланцюжок документів і поєднувати це з основними обов’язками якісно не встигає і не вміє майже ніхто.
6. Бажання зробити так, як здається зручно, а не так, як правильно з погляду бізнес-логіки або закону, — це просто основа поганої карми тих, у кого ніколи нічого не сходиться, — це потенційні помилки у валюті, собівартості, курсових різницях, ПДВ , балансі, фінансовому результаті тощо.
7. Суперсучасні алгоритми замість простих дій, тому що це «специфіка бізнесу», призводить до того, що відтепер це рішення не просто важко супроводжувати, а й набагато дорожче оновлювати та адмініструвати, а от продавати свої товари / послуги дорожче ніхто не готовий, тому зростають тільки витрати.
8. На середині проєкту всі розуміють, що припустилися помилки, коли не спроєктували потрібних звітів одразу, а відтак стало зрозуміло, що не всі дані можна подати так, як належить, з’являється розробка нових регістрів, і з’ясовується, що внесена інформація не годиться для аналітики. Дані, «набиті» ночами, виявляються некорисними, виправити їх неможливо і тепер невідповідності і помилки фальстарту будуть, як привиди, з’являтися в різні періоди історії аналітики.
9. Немає документації змін: немає завдань на зміни, немає списку змін, немає процедур тестування, верифікації, валідації і трасування. Це буде зрозуміло вже після оплати розрахунків за проєкт, коли помилки виправлятимуть, а нові рахунки на послуги зростатимуть за ціною і строками виконання.
10. Є чимало ідей, як краще зробити; ці ідеї надходять із різних департаментів, ніхто не готовий переконати всіх як оптимальніше, а тому роблять так, як видається, або слухають того, хто голосніше вимагає. Зрештою з обліку виходить «собака-кіт», який викликає сумнів навіть у того, хто був найгучнішим під час узгодження вимог.

Чи є варіант, як зробити правильніше? Так, але він дорожчий. Клієнт «перший раз» вірить, що може зробити дешевше. Тут, як свідчить життя, перший раз, як і перший млинець нанівець. Це ціна досвіду. За спостереженнями, його вартість 100—600 тис. грн.

Професійні підрядники не вельми люблять клієнтів, у яких «перший раз». Утім, є й такі, що на них полюють. Вічні проєкти для любителів процесу — це як вічний двигун доходу, чи не так?

Другий сценарій «Розквіт сепаратизму»

Компанія зростала, відбувся розподіл праці, призначені начальники, які опікуються розбудовою різних функцій. Деякі з них мали досвід і пройшли згадуване випробування «перший раз» в автоматизації, і тепер у такій компанії ІТ-проєкт сприймають із повною відповідальністю. А тому обов’язково з’явиться підрядник для впровадження, складуть список функціональних вимог і призначать відповідального керівника, який забезпечить навіть добір фахівців до штату для завдань нового проєкту.

Проте чому ж буксують навіть такі проєкти?

Проблемний «сеператизм»

Тут проблем більше за попередній десяток, і всі вони мають один корінь — «сепаратизм».

1. Немає єдиного управління. Директор компанії ще не вибудував чіткої вертикалі влади і розподілу обов’язків-повноважень. Найчастіше такий СЕО — це керуючий і власник компанії без системного корпоративного досвіду. Він сам робить те, що розуміє, і не робить того, що мав би робити на цій позиції. Це відбувається через брак знань або такий керманич переконаний, що можна керувати фрагментарно, тобто наскоками, наприклад: «сьогодні я у продажах, а логістикою займуся згодом». Тому більшість концептуальних, фундаментальних, принципових і стратегічних питань, що постають у проєкті з автоматизації, зависає в повітрі, і проєкт виконують без їх відпрацювання, що буде очевидним, але потім. Та й хто буде тиснути на СЕО?
2. Завдання для підготовки до автоматизації нарізають на блоки і їх роздають по відділах, всі суміжні питання, які часто найскладніші (бо стосуються взаємодії різних відділів), вирішують по-різному. У відриві від контексту і без взаємозв’язку ці рішення будуть дуже незручними в момент щоденного використання вже написаного алгоритму. Тут з’ясується, що варто було б обміркувати процес з погляду загальної стратегічної логіки, але дивись пункт 1.
3. Кожен відділ і функцію, якою він наділений (логістична, маркетингова тощо), розробляють у софті до рівня її усвідомлення начальником. Досвідченіші фахівці продумують деталі, тоді як колегам з іншого відділу достатньо і простіше. Кожен модуль стає схожим на свого творця, а там, де цей витвір вельми невдалий, починають рятувати і вигадувати завдання автоматизації ті, хто небайдужий і лояльний, але зовсім не фахівець у тематиці питання. Собака-кіт? Чудо-юдо!
4. Якщо всі перелічені проблеми збираються у щільний вузол, — приймають соломонове рішення — «відділити бухгалтерію», в іншу базу, на інший сервер тощо, хай бухгалтери роблять як правильно і не заважають «творити» управління. І з цього дня сепаратизм починає набирати обертів і починає звучати (майже як образа): «Це ваше бухгалтерське, а це наше реальне управлінське».

Далі з’являється закономірна низка подій:

1. Реальна бухгалтерська дебіторка (тому що за документами та з печатками) у розрізі договорів «веде спір» з управлінською більш правильною заборгованістю, бо має додаткові розрізи аналітики і терміни, замовлення й домовленості. Синхронізація обох баз даних, постійні звірки і виявлені помилки призводять до того, що ніхто до кінця не впевнений, яка дебіторка насправді. Тут як на митниці: у кожної країни своя правда. Тоді як комерційний директор дивиться той звіт, якому довіряє найбільше, а звіт, у якому йому не все зрозуміло, використовує інший відділ. Так розвивається сепарація звітів та аналітичних висновків.
2. Умовні витрати, віртуальні склади, плутанина в оцінці суми продажів, тому що в одних аналізують суму із ПДВ, а в інших сума не збігається, бо врахована без ПДВ і з урахуванням повернення, — все це призводить до того, що в кожному відділі з’являється свій звіт із продажу. А позаяк є дві реальності, дві бази, — з’являється ще купа інтерпретацій і навіть доробок, щоб усе пояснити і «полагодити» чи то в голові, чи то в софті.
3. Різний підхід у формуванні та списанні собівартості, з’являються такі відмінності як різні періоди нарахування, різні політики та різні оцінки — це лише малий список сепаратизму. Є ще 40 пунктів і цілий букет ризиків…
4. Усе це призводить до того, що всі відділи компанії живуть у своїй вихолощеній реальності, агресивно реагують на претензії інших відділів і завжди не задоволені бухгалтерами, які, на відміну від інших, мають працювати «як правильно», адже вони взагалі окремо, і не лише морально, а ще й фізично та законодавчо.

«Допоможіть, бо у нас не сходиться те й те», — чую часто від таких колег.

Ох, якби у цьому варіанті проєкту воно сходилося, — це була б Нобелівська премія, друзі! Не можна розірвати ціле на частини, ліпити його окремо, а відтак думати, що воно буде збігатися дивним чином в одне ціле. Ні. В усіх не сходиться. І не зійдеться. Ніколи!

У таких проєктах звинувачують розробників і не в тому, що вони погодилися програмувати в умовах сепаратизму, намагаючись догодити всім. Від них очікували майстрів, здатних «одружити» в новій системі і функції, і сепаратистів. Але підрядники підкорилися технічному завданню і зробили так, як просили замовники.

Війна за фінансову істину спалахуватиме на кордоні функцій, починаючи з запитань:

• Чому в управлінні збиток, а в бухгалтера прибуток?
• Як отримати позику?
• Які результати показати банку?
• Як це пояснити інвесторові?
• Де цей Нобель зрештою?

Корпоратив, тимбілдинг і робота із залученням не рятують, з таким головним болем сепаратистських запитань, воно, як пластир на лоб. Бережіть нерви.

Третій сценарій «Авторський стиль»

Чи мріяли ви побудувати фінансове управління та зробити облік по-своєму? Безперечно. Всі, хто розвивався як аматор, переживали особливе відчуття, коли в них виходило створити щось своє, зручне і, як зараз кажуть, авторське та кастомне. А якщо ви проходили на практиці перші два згадувані сценарії, то обов’язково замислювалися про третій варіант проєкту автоматизації, про який мова буде далі.

Зазвичай третій сценарій, який дістав назву «Авторський стиль», починається з думки: «А, можливо, годі вже підганяти до свого бізнесу різні ІТ-рішення? Кількість ярличків на робочому столі невпинно зростає, а всі важливі питання системного управління й досі не закриті. І взагалі це дуже незручно, коли все працює, як склалося з часом, а не так як треба саме вам, і тепер це зрозуміло». У цю мить купувати велику суперсучасну інформаційну систему страшнувато, а раптом і вона не покриє всіх вимог без доопрацювань, а натомість забере багато сил і грошей.

Можливо, варто взяти до штату програмістів та ІТ-директора, і вони зроблять під нас, з нами і для нас, бо знатимуть наші процеси, займатимуться тільки нашим бізнесом і братимуть участь у житті компанії щодня.

Авторський продукт — це шлях генія, авторський стиль якого визначає результат.

Хто буде генієм у такому проєкті? Можливо ІТ-директор, фінансовий директор чи генеральний? Де буде новизна, а де просто невдала копія? Чим саме унікальні наші процеси прийняття рішень, що їм знадобився авторський проєкт і самописна база? Чи обійдуться вони без інтеграцій?

Можливо, третій сценарій відрізняється від перших двох лише власною ІТ-командою?

Я починала працювати у великих компаніях у 2000-х. Тоді багато хто утримував цілий штат ІТ-фахівців, це був спражнісінький бум авторських розробок. І вже за 5—7 років стало зрозуміло, що динамічне бізнес-середовище потребує нових швидкостей, а тому місяцями очікувати на доробки з дрібних питань зовсім нераціонально.

Двадцять айтішників, великі парки машин і постійна закупівля для зростання потужностей — це були тривіальні будні системного бізнесу. Чи вдалося мені, активному учаснику, відчути задоволення від авторського рішення, в якому я брала активну участь? Ні. Ми жили у постійному проєктуванні нових завдань, нової аналітики, і не вдавалося встигати автоматизувати плани, бракувало досвіду обміркувати глобальні питання, щоб врахувати їх у інформаційній системі. Проте досі відчуваю особливий трепет до авторських розробок своїх або чужих, іноді захоплююся тим, як успішно вдалося спроєктувати рішення і як багато для цього знадобилося вивчити нового.

Основним недоліком цього сценарію вважаю відсутність генія, здатного створити авторський стиль, кращий, ніж чуже рішення, обкатані на ринку роками і сотнями впроваджень. Утім, назву банальні недоліки такого сценарію: довго й дорого. Якщо ваш бізнес може це собі дозволити або типового рішення для адаптації просто немає — авторський стиль — це кращий і єдиний шлях. Шукайте генія. Подвійного запису не зачіпайте, він працює ідеально 500 років (його автор Лука Пачолі).

Сценарій четвертий «По-багатому»

Сценарій «По-багатому» передбачає щедре фінансування. Не варто його плутати з марнотратством. Не так вже й рідко у компаніях приймають рішення вкладати серйозні бюджети в автоматизацію і робити все за останнім словом в індустрії. Уже ніхто не сумнівається, що наближається епоха конкуренції роботів. А тому правильно вирішувати питання системно і технологічно, аніж «закидати» проблему новими співробітниками. Кращі з них однаково запропонують щонайменше автоматизувати тупу роботу і рутину.

У попередніх сценарії неодноразово згадувалась ціну помилок. тут можна зауважити, що ціна може бути й високою, аби врешті вдалося зробити те, що планувалося». Однак із плануванням ІТ-проєктів просто біда. Швидкість змін невпинно зростає: це стосується і технологій, і життя самих проєктів. Усі відомі методології планування та управління проєктами не ідеальні. Тому часто втрачається купа грошей, і залишається зовсім небагато тих, кому вдалося  заробити завдяки таким вкладенням.

Інструмент — це продовження руки майстра. Крута система управління підійде крутим управлінцям, але ніколи не замінить їх

Уявіть, що у вас є бюджет на крутий проєкт для автоматизації управління в бізнесі, коли можна дозволити собі гарну команду із проджектів, програмістів і бізнес-аналітиків та закупити кращі технології і техніку тощо. Команда із 7 осіб по 2500$ за 1,5 року роботи коштуватиме 315 тис. доларів. Чи вистачить для середнього масштабу 1,5 року та 7 осіб — це ще питання, але 315 тисяч — питання набагато серйозніше. Додамо до цієї суми 50% для резерву на ризик, що часто практикується при плануванні і реалізується по факту зростання функціональних вимог і кошторисів. Отже, вийдемо на 473 тис. $. Додамо 127 тис. $ на техніку, ліцензії та базову конфігурацію і отримаємо дуже реальний бюджет проєкту у 600 тис. $.

Коли можуть окупитися ці 600 тис. $ або 16 млн грн? У який вид бізнесу та в якій галузі і якому етапі розвитку варто робити такі інвестиції? Вважаю такий варіант проєктів для завдань інтеграції готових систем бізнесів, що вже працюють і добре структуровані, об’єднання яких неминуче і обов’язкове, а прогнозована дохідність висока. Тобто не для створення  автоматизованої системи управління з нуля, а для адаптації в одне ціле окремих вузлів, що вже працюють, для виходу на новий рівень та задля актуалізації застарілих попередніх технологічних рішень. А ви як думаєте?

Проєкт із щедрим бюджетом передбачає: дуже точне розуміння цілей і перспектив використання, реальну оцінку обсягів майбутніх робіт, наявність коштів на підтримку після завершення, відповідний інтелектуальний рівень користувачів.

Сумніваюся, що так, з першого разу, навіть за допомогою великого бюджету можна відбудувати все те, що не було зроблено роками, навіть якщо була хороша бізнес-ідея, клієнтська база та деякий досвід.

Великим витратам потрібно відповідати не лише матеріально, а й ментально, і навіть духовно.

На цьому тлі 600 тис. грн втрат за невдале впровадження «перший раз» має не такий вже й трагічний вигляд. А якщо «перший раз» коштуватиме 600 тис. $?

Побудова систем управління — як виховання внутрішньої дисципліни. З першого разу складно. Гіркий шлях помилок неминучий. Щоб зрозуміти важливість об’єднання зусиль усіх функцій і керівників, варто колись прожити досвід сепарації та егоцентризму. Яскравий шлях своїх новаторств та авторських рішень навчить цінувати чужі розробки. І мабуть, тільки потім з’явиться дуже  чітке розуміння  потреби крутого інструменту, коли знадобляться будуть тільки великі гроші для великих цілей. Хай вони будуть! І цілі, і гроші, і результати.

ІТ-проєкти обов’язково з’являтимуться у всіх, хто прагне розвитку бізнес-ідеї, бо в сучасному цифровому світі алгоритми управління коштами є невід’ємною частиною ухвалення управлінських рішень, час розробки яких весь час скорочується.

Чи існують ідеальні плани та фактичні обставини впровадження проєктів автоматизації фінансового управління, коли вдається за оптимальною ціною  та у заплановані строки реалізувати цілі та завдання проєкту? Мабуть, що ні. Принаймні мені поки що не вдалося побачити такий ідеальний варіант у реальному бізнесі. Сподіваюсь, що описані типові сценарії дозволять вам зробити власні висновки для побудови раціональних планів з огляду на досвід інших.

Залучайте до своїх проєктів фахівців, що стояли у джерел проєктування  проєктів та успішно довели їх до завершення, щоб уникнути типових і примітивних помилок, які насправді чимало коштують. Враховуйте вартість технологічних рішень при проєктуванні фінансових моделей розвитку бізнесу у цінах продуктів і послуг, бо ІТ-бюджети наразі тільки зростають, а число звільнених робочих місць завдяки роботизації поки що мінімальне. Проєктуйте системи управління з врахуванням сучасних вимог до структури та безпеки бази даних. Бо тільки у бізнесі навчаться ефективно впровадити ІТ-проєкти, прийде новий еволюційний етап — інтеграція своєї системи в інформаційні бізнес-конгломерати для швидкої взаємодії, коли більшість типових рішень буде автоматизована не лише в середині бізнесу, а й зовні між учасниками ринку. Цей процес вже розпочався.