За роки роботи наша команда неодноразово брала участь у розробці та впровадженні облікових систем — від автоматизації окремих бізнес-процесів до комплексних рішень, що охоплюють фінанси, склад, закупівлі, продажі, виробництво та управлінський облік. І майже завжди результат такого проєкту залежить не стільки від того, наскільки добре програмісти пишуть код, скільки від того, наскільки правильно побудований сам процес розробки.
Власна система чи адаптація готового рішення
Коли компанія вирішує створити власну облікову систему з нуля, найпоширеніша помилка — сприймати це як просту розробку програмного забезпечення за принципом «ось наші процеси, ось список функцій — зробіть нам систему». Між ідеєю та готовою системою є ланцюжок етапів: обстеження, формалізація вимог, проєктування, пріоритизація, розробка, тестування, приймання та подальший супровід. І відповідальність за результат лежить не лише на підряднику.
Перш ніж починати розробку, варто відповісти на базове питання: чи справді компанії потрібна власна система. У більшості бізнесів уже є готові продукти — ERP, CRM, складські та бухгалтерські платформи, галузеві рішення. Якщо стандартний функціонал закриває 70–90% потреб, часто економічно доцільніше адаптувати готову облікову платформу, ніж будувати нову.
Власна розробка виправдана тоді, коли бізнес-процеси суттєво відрізняються від типових, потрібна специфічна логіка розрахунків, є особливі вимоги до інтеграцій або компанія свідомо хоче повністю контролювати архітектуру та подальший розвиток продукту. Важливо одразу розуміти: розробка з нуля — це не одноразова покупка програми, а створення інформаційної системи, яку далі потрібно підтримувати, розвивати, тестувати, захищати та адаптувати до змін бізнесу.
Хто за що відповідає
Одна з ключових умов успішного проєкту — чіткий розподіл відповідальності між замовником і виконавцем.
На боці замовника. Замовник найкраще знає власний бізнес. Тому на його боці має бути людина, яка розуміє бізнес-процеси підприємства, може пояснити, як процес працює зараз і як він має працювати після автоматизації, визначає пріоритети, погоджує зміни та приймає результати розробки. Залежно від масштабу компанії це може бути Product Owner, керівник проєкту або бізнес-аналітик — але роль має бути реальною, а не формальною. Якщо підрядник змушений сам з'ясовувати, як працює підприємство, у кого запитувати інформацію і хто ухвалює рішення, проєкт швидко починає буксувати.
На боці виконавця. З боку розробника має бути зрозуміла структура ролей: керівник проєкту, бізнес-аналітик, розробники, QA, за потреби — архітектор, DevOps, UI/UX. Замовнику не обов'язково щодня спілкуватися з кожним розробником, але має бути прямий канал комунікації з командою або керівником проєкту. Коли між замовником і командою стоїть кілька рівнів менеджменту, інформація спотворюється, а прості питання перетворюються на довгі погодження.
Як обрати підрядника
Ми радимо починати не з питання «скільки коштує година роботи». Перше, на що варто дивитися, — як підрядник підходить до проєкту ще до початку розробки. Досвідчений виконавець не обіцяє після короткого дзвінка «так, ми все зробимо, ось кошторис». Він ставить запитання: як побудовані процеси зараз, хто користувачі системи, які обсяги даних, які потрібні інтеграції, де виникають проблеми, які документи формуються, хто погоджує операції, які дані мають потрапляти до бухгалтерського та управлінського обліку, які вимоги до ролей і доступів. Чим складніша система, тим більше таких питань має виникнути до оцінки.
Досвід саме в облікових системах. Розробити вебзастосунок і побудувати систему, яка коректно веде залишки, проводки, взаєморозрахунки, собівартість та історію операцій, — різні задачі.
Аналітична компетенція. Якщо комунікація зводиться до «надішліть нам список функцій» — це тривожний сигнал. Виконавець має допомагати переводити бізнес-процеси у функціональні вимоги системи.
Прозорість процесу. Замовник має будь-коли розуміти, що розробляється зараз, що заплановано далі, які задачі в роботі та що вже прийнято.
Поступовий результат. Для великої облікової системи підхід «зустрінемося за рік, коли все буде готово» — один із найризикованіших.
Права на результат. Домовтеся заздалегідь і письмово: кому належить вихідний код, де він зберігається, чи передається документація, чи зможете ви залучити іншого підрядника на доробку без повного переписування.
І не варто обирати підрядника лише за найнижчою ставкою. Різниця у вартості години зазвичай значно менша, ніж вартість помилкових вимог, переробок і місяців простою.
Етап 1. Передпроєктне обстеження
Розробку облікової системи не варто починати одразу з коду. Перший етап — передпроєктне обстеження. Його мета — зрозуміти, що саме автоматизуємо, для кого, навіщо і яким має бути результат.
На цьому етапі аналізуються організаційна структура, ролі користувачів, основні бізнес-процеси, документообіг, довідники та нормативно-довідкова інформація, облікові регістри, звітність, інтеграції з іншими системами, джерела та споживачі даних, права доступу, обсяги операцій і проблеми поточного обліку.
Досліджувати потрібно не лише те, як процес описаний у регламентах, а й те, як він реально відбувається в компанії. Дуже часто ці дві картини відрізняються.
Результат обстеження — не фраза «ми все зрозуміли», а зафіксована модель майбутньої системи: основні модулі, процеси, ролі, інтеграції, обмеження та пріоритети, а також backlog верхнього рівня з попередніми оцінками. З цим документом замовник може працювати навіть з іншим підрядником.
Етап 2. Не велике ТЗ, а керована система вимог
Після обстеження виникає спокуса написати технічне завдання на кілька сотень сторінок і лише потім почати розробку. Для великих систем це рідко ефективно: поки ТЗ пишуть, вимоги встигають змінитися, а замовник остаточно розуміє, чого хотів, лише побачивши робочий екран.
Ми віддаємо перевагу декомпозиції. Спочатку формується загальний backlog — перелік функціональних і технічних задач. А вже перед реалізацією конкретної задачі готується її міні-ТЗ: що потрібно зробити, який процес автоматизується, хто користувач, які вхідні дані, яка бізнес-логіка виконується, який очікується результат, які винятки та обмеження і як перевірити, що задача виконана правильно. Це документ обсягом пів сторінки — сторінка, а не тижні роботи аналітика наперед.
Етап 3. Agile і розробка короткими ітераціями
Для великих облікових систем добре працює ітеративний підхід. Backlog розбивається на пріоритети та спринти по один-два тижні. У межах спринту команда реалізує конкретний блок: частину складського обліку, закупівлі, документообіг або окрему інтеграцію. Наприкінці спринту результат демонструється замовнику на робочій системі, а не у вигляді звіту.
Якщо щось пішло не туди, замовник дізнається про це за два тижні, а не наприкінці проєкту. Планування спринту, демо і коротка ретроспектива — це не бюрократія, а механізми, які тримають постійний потік інформації між командою і замовником.
Роль керівника проєкту замовника: формування і приймання задач
Це критично важлива частина, і саме тут проєкти найчастіше буксують. Представник замовника має бути повністю залучений з обох боків процесу.
На вході він бере участь у формуванні задач: перевіряє, що міні-ТЗ описує процес так, як він реально має працювати, доповнює деталями від предметних експертів — комірника, бухгалтера, оператора — і розставляє пріоритети в backlog.
На виході він приймає розробку за критеріями приймання, а не «на око»: прийнято або не прийнято, із конкретною причиною. Без цього кроку за кілька місяців накопичується обсяг «начебто готового», що насправді не працює у бойовому процесі.
Розподіл простий: замовник відповідає за бізнес-пріоритети та відповіді на питання про процес, виконавець — за технічну реалізацію та оцінку складності. Коли замовник каже «потрібно автоматизувати переміщення товару між складами», команда ставить уточнення: які склади, які типи переміщень, чи потрібне резервування, які документи створюються, хто їх погоджує, як змінюються залишки, чи потрібна інтеграція. Нормальна постановка задачі народжується саме на стику бізнес-експертизи замовника і технічної експертизи виконавця.
Архітектура: закладати запас на майбутнє
Типова помилка — проєктувати систему виключно під сьогоднішні потреби. Якщо сьогодні в системі 20 користувачів, це не означає, що за три роки їх не буде 200. Якщо зараз одна інтеграція — за рік їх може бути десять.
Тому ще на етапі архітектури варто продумати масштабованість, продуктивність, безпеку, розмежування доступів, резервне копіювання, журналювання операцій, інтеграційні API, структуру даних і можливість розширення функціональності. Не обов'язково будувати складну enterprise-архітектуру з першого дня — але вона не повинна створювати технічний борг уже на старті.
Критерії приймання задач
Ще одна проблема великих проєктів — нечітке розуміння того, коли задача вважається виконаною. Для кожної функціональності мають існувати критерії приймання: які сценарії повинні працювати, які дані формуються, які документи створюються, які перевірки виконуються, які ролі мають або не мають доступ, який результат отримує користувач.
Це потрібно не лише замовнику. Для розробника чіткі критерії приймання означають, що він теж розуміє, який результат вважається готовим.
Що замовник отримує в результаті
Правильно організована розробка — це не просто «програма, що працює». У результаті компанія отримує керовану інформаційну систему, у якій зрозуміло, які бізнес-процеси автоматизовані, як побудована система, хто має доступ до даних, які інтеграції використовуються, як розвивати функціональність, як тестувати зміни і хто відповідає за підтримку. Знання про систему не повинні залишатися виключно в голові одного розробника.
На нашу думку, головні правила можна сформулювати просто. Замовник не може повністю передати відповідальність за результат підряднику. Підрядник відповідає за технологію, архітектуру, якість коду, процес розробки та реалізацію погоджених вимог. Замовник відповідає за те, щоб у проєкті була людина, яка знає бізнес, ухвалює рішення, визначає пріоритети і має достатньо повноважень. Найкращі результати ми бачили там, де з боку замовника був залучений сильний керівник проєкту або Product Owner, а команда розробки могла напряму спілкуватися з людьми, які знають процеси підприємства. Тоді розробка перестає бути передаванням нескінченного списку завдань «на сторону» і стає спільною роботою над продуктом, яка дозволяє створювати облікові системи, що реально працюють на бізнес і розвиваються разом із ним.