Власна облікова система з нуля: що потрібно знати замовнику до початку розробки

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

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

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

Власна система чи готове рішення?

Перш ніж починати розробку, варто відповісти на базове питання: а чи дійсно компанії потрібна власна система?

У більшості бізнесів уже є готові рішення — ERP, CRM, складські системи, бухгалтерські програми, галузеві продукти. Якщо стандартний функціонал закриває 70–90% потреб компанії, часто економічно доцільніше адаптувати готову систему, ніж розробляти нову. Власна система має сенс тоді, коли бізнес-процеси суттєво відрізняються від типових, потрібна специфічна логіка, існують особливі вимоги до інтеграцій або компанія хоче повністю контролювати архітектуру та подальший розвиток продукту.

І тут важливо одразу розуміти: розробка з нуля — це не одноразова покупка програми. Це створення інформаційної системи, яку надалі потрібно буде підтримувати, розвивати, тестувати, захищати та адаптувати до змін бізнесу.

Хто за що відповідає

Одна з ключових умов успішного проєкту — чіткий розподіл відповідальності між замовником і виконавцем.

На стороні замовника.

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

Це може бути Product Owner, Project Manager, бізнес-аналітик або інша відповідальна особа — залежно від масштабу компанії. Але ця роль повинна бути реальною, а не формальною.

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

На стороні виконавця.

З боку розробника також має бути зрозуміла структура відповідальності: керівник проєкту, бізнес-аналітик, розробники, QA, а за необхідності — архітектор, DevOps, UI/UX та інші спеціалісти.

Замовнику не обов’язково щодня спілкуватися з кожним розробником. Але має бути прямий і зрозумілий канал комунікації з командою або керівником проєкту.

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

Як обрати підрядника

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

Хороший виконавець не буде після короткого дзвінка обіцяти: «Так, ми все зробимо. Ось кошторис». Навпаки, він почне ставити запитання.

Як зараз побудовані процеси? Хто користувачі системи? Які обсяги даних? Які є інтеграції? Де виникають проблеми? Які документи формуються? Хто погоджує операції? Які дані повинні потрапляти до бухгалтерського та управлінського обліку? Які є вимоги до доступів та ролей?

Чим складніша система, тим більше таких питань має виникнути до оцінки проєкту.

На що варто звернути увагу:

1) Досвід саме в облікових системах. Розробити красивий вебзастосунок і розробити систему, яка повинна коректно вести залишки, проводки, взаєморозрахунки, собівартість, документи та історію операцій, — не одне й те саме.

2) Наявність аналітичної компетенції. Якщо вся комунікація зводиться до «напишіть нам список функцій», це тривожний сигнал. Виконавець має допомагати переводити бізнес-процеси у функціональні вимоги системи.

3) Прозорість процесу. Замовник повинен розуміти, що зараз розробляється, що буде зроблено наступним, які завдання перебувають у роботі та що вже прийнято.

4) Можливість поступово отримувати результат. Для великої облікової системи підхід «зустрінемося через рік, коли все буде готово» — один із найризикованіших.

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

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

Етап 1. Передпроєктне обстеження

Розробку облікової системи я б не починала одразу з написання коду. Перший етап — передпроєктне обстеження.

Його мета — зрозуміти, що саме автоматизуємо, для кого, навіщо і яким має бути результат.

На цьому етапі аналізуються:

— організаційна структура;
— ролі користувачів;
— основні бізнес-процеси;
— документообіг;
— довідники та нормативно-довідкова інформація;
— облікові регістри;
— звітність;
— інтеграції з іншими системами;
— джерела та споживачі даних;
— права доступу;
— обсяги операцій і даних;
— проблеми поточної системи або ручного обліку.

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

Результатом обстеження має стати не «ми все зрозуміли», а зафіксована модель майбутньої системи: основні модулі, процеси, ролі, інтеграції, обмеження та пріоритети.

Етап 2. Не величезне ТЗ, а керована система вимог

Після обстеження виникає спокуса написати величезне технічне завдання на кілька сотень сторінок і тільки після цього почати розробку.

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

Тому я віддаю перевагу декомпозиції вимог.

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

У ній повинно бути зрозуміло:

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

Це дозволяє не намагатися передбачити весь проєкт до останньої кнопки ще до написання першого рядка коду.

Етап 3. Agile та розробка короткими ітераціями

Для великих облікових систем добре працює ітеративний підхід. Весь backlog розбивається на пріоритети та спринти.

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

Після завершення спринту результат демонструється замовнику.

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

Замовник відповідає за бізнес-пріоритети, виконавець — за технічну реалізацію та оцінку складності.

Наприклад, замовник може сказати: «Нам потрібно автоматизувати процес переміщення товару між складами».

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

Саме на стику бізнес-експертизи замовника та технічної експертизи виконавця і формується нормальна постановка задачі.

Архітектура: не можна думати тільки про сьогодні

Ще одна типова помилка — проєктувати систему виключно під поточні потреби.

Якщо сьогодні у компанії 20 користувачів, це не означає, що система через три роки не матиме 200. Якщо зараз є одна інтеграція, це не означає, що через рік їх не буде десять.

Тому ще на етапі архітектури потрібно думати про:

— масштабованість;
— продуктивність;
— безпеку;
— розмежування доступів;
— резервне копіювання;
— журналювання операцій;
— інтеграційні API;
— структуру даних;
— можливість подальшого розширення функціональності.

Необов’язково будувати складну enterprise-архітектуру з першого дня. Але архітектура не повинна створювати технічний борг уже на старті.

Приймання задач

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

Для кожної функціональності мають існувати критерії приймання.

Наприклад:

— які сценарії повинні працювати;
— які дані мають формуватися;
— які документи створюються;
— які перевірки виконуються;
— які ролі мають або не мають доступ;
— який результат повинен отримати користувач.

Це важливо не тільки для замовника. Для розробника чіткі acceptance criteria також означають, що він розуміє, що саме вважається готовим результатом.

Що в результаті отримує замовник

Правильно організована розробка — це не просто «програма, яка працює».

У результаті компанія повинна отримати керовану інформаційну систему, в якій зрозуміло:

— які бізнес-процеси автоматизовані;
— як побудована система;
— хто має доступ до даних;
— які інтеграції використовуються;
— як розвивати функціональність;
— як тестувати зміни;
— хто відповідає за підтримку.

І бажано, щоб знання про систему не залишалися виключно в голові одного розробника.

Найголовніше: облікова система — це спільний проєкт

На мою думку, найважливіші правила можна сформулювати дуже просто:

1) Замовник не може повністю передати відповідальність за результат підряднику.

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

3) Замовник відповідає за те, щоб у проєкті була людина, яка знає бізнес, приймає рішення, визначає пріоритети та має достатньо повноважень.

Найкращі результати я бачила саме там, де з боку замовника був залучений сильний Product Owner або Project Manager, а команда розробки мала можливість напряму комунікувати з людьми, які знають процеси підприємства.

Тоді розробка перестає бути передачею нескінченного списку завдань «на сторону». Вона перетворюється на спільну роботу над продуктом.

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