Порада, яку дають усі
«Спершу опишіть свої бізнес-процеси, потім обирайте систему». Ця фраза є в кожному матеріалі про впровадження ERP, включно з нашими. Ми самі писали її кілька разів.
Порада виглядає бездоганно. Логіка залізна: не можна автоматизувати те, чого не розумієш. Автоматизований безлад лишається безладом.
Проблема в тому, що на практиці вона працює приблизно ніколи.
Чому вона не працює
Опис процесів вимагає знання системи
Ви не можете описати, як має працювати процес, не знаючи, які варіанти взагалі існують. Компанія, яка десять років працювала в 1С, опише свої процеси так, як вони влаштовані в 1С. Отримається технічне завдання на відтворення старої системи в новій.
Це найдорожчий можливий результат: ви заплатите за доробки, які повторюють обмеження системи, від якої тікаєте.
Опис старіє швидше, ніж пишеться
Повний опис процесів середньої компанії — це кілька місяців роботи. За цей час частина процесів зміниться: прийдуть нові клієнти, зміняться умови з постачальниками, хтось звільниться.
Ніхто не описує чесно
В описі буде те, як процес має працювати за регламентом. Реальність відрізняється: хтось погоджує в месенджері, хтось веде свою таблицю, хтось обходить незручний крок. Саме ці відхилення й визначають, що доведеться налаштовувати — і саме їх в описі не буде.
Що виходить насправді
Компанія чесно намагається виконати пораду. Далі один із трьох сценаріїв.
Перший. Опис не починається взагалі. Задача виглядає надто великою, її відкладають, проєкт зупиняється на етапі «спершу треба описати процеси» на рік.
Другий. Опис пишеться формально, за два вечори, і складається з речень на кшталт «менеджер оформлює замовлення». Користі нуль, але галочка стоїть.
Третій. Опис пишеться сумлінно, займає три місяці, і на першій же зустрічі з підрядником з’ясовується, що половина описаного в системі робиться інакше й простіше.
Жоден із трьох сценаріїв не наближає до запуску.
Що робити замість
Замінити велику задачу на три маленькі, кожна з яких дає результат сама по собі.
Перше: опишіть не процеси, а болі
Не «як у нас влаштована закупівля», а «що конкретно ламається». Одна сторінка, десять пунктів, кожен — конкретна ситуація.
«Не знаємо реальної маржі, бо доставка не потрапляє в собівартість». «Продаємо те, чого немає, бо залишки оновлюються раз на добу». «Закриття місяця займає два тижні, бо звірка робиться вручну».
Такий список пишеться за годину, не старіє й одразу зрозумілий будь-якому підряднику. І він показує реальні відхилення, а не регламент.
Друге: почистіть довідники
Це єдина підготовча робота, яка гарантовано окупається. Дублі в номенклатурі й контрагентах — найбільший чинник вартості міграції, і прибрати їх можна самостійно, без бюджету й без підрядника.
Порядок дій — у чек-листі підготовки даних. За нашим досвідом довідник після чистки зменшується на 15–30%.
Третє: опишіть процеси разом із підрядником, а не до нього
На етапі аудиту, коли ви вже бачите, як влаштована система, і можете відрізнити «у нас так заведено» від «інакше не можна».
Це і є та робота, за яку ви платите на першому етапі проєкту. Робити її самостійно й наосліп — означає зробити її двічі.
Коли порада все-таки правильна
Є два випадки, коли описати процеси заздалегідь справді потрібно.
Ви збираєте пропозиції від кількох підрядників. Тоді письмовий опис задачі обов’язковий — інакше кожен оцінює власне розуміння проєкту, і цифри непорівнянні. Але це має бути опис задачі на дві сторінки, а не повна карта процесів.
У вас справді унікальний процес, який є конкурентною перевагою. Виробництво з нестандартною технологією, специфічна схема роботи з мережами. Тоді цю ділянку варто описати детально, а решту — ні.
В обох випадках мова про кілька сторінок під конкретну мету, а не про проєкт з опису всієї компанії.
Підсумок
Порада «спершу опишіть процеси» правильна за логікою і шкідлива за наслідками: вона ставить перед компанією задачу, яку та не може виконати якісно, і зупиняє проєкт на роки.
Робоча заміна: сторінка з болями, чисті довідники, а опис процесів — разом із підрядником на етапі аудиту. Про те, що ще зриває проєкти, — у статті про сім причин зриву впроваджень.
Часті запитання
Чому не варто описувати процеси до вибору системи?
Тому що опис вийде відтворенням поточної системи. Компанія, яка десять років працювала в 1С, опише процеси так, як вони влаштовані в 1С — і отримає технічне завдання на повторення обмежень, від яких тікає.
Що робити замість опису процесів?
Три речі: сторінка з конкретними болями замість карти процесів, чистка довідників, і опис процесів разом із підрядником на етапі аудиту. Перше пишеться за годину, друге окупається завжди, третє робиться один раз замість двох.
Коли опис процесів усе-таки потрібен?
Коли ви збираєте пропозиції від кількох підрядників — тоді потрібен письмовий опис задачі на дві сторінки, інакше цифри непорівнянні. І коли у вас справді унікальний процес, який є конкурентною перевагою: його описують детально, решту ні.
Як виглядає правильний опис болів?
Конкретні ситуації, а не регламент. «Не знаємо реальної маржі, бо доставка не потрапляє в собівартість» замість «у нас налагоджений процес закупівель». Десять пунктів на одну сторінку.
Чи не вийде так, що ми автоматизуємо безлад?
Ризик реальний, але описом процесів він не знімається — в описі буде регламент, а не реальність із її обходами й винятками. Знімається він на етапі аудиту, коли підрядник бачить, як працює система насправді.