Коли ERP-проєкт зривається, винним називають інтегратора. Це зрозуміло, адже саме він отримує гроші, але наша практика з понад 200 проєктів каже інше. У переважній більшості зірваних проєктів справжня причина стоїть у порожніх кріслах з боку замовника, бо компанія прийшла на старт з гаманцем, а не з командою. Тож складаємо чесний список ролей, без яких проєкту тісно, і пояснюємо, чим кожна з них займається.
Сторона замовника. Хто потрібен від вашого бізнесу
Ось мінімальний склад, який ми просимо виділити у кожного клієнта. Зменшувати його можна лише ціною строків, і це добре видно на графіку проєкту.
- Спонсор проєкту. Власник, генеральний директор або топ-менеджер з повноваженнями приймати рішення. Ухвалює ключові питання обсягу, вирішує суперечки між підрозділами і тримає пріоритет проєкту серед усіх інших справ компанії. Без нього проєкт пливе, і жодна методологія цього не виправить.
- Керівник проєкту з боку компанії. Людина, яка займається проєктом щодня, збирає рішення з підрозділів, організовує тестування і стежить, щоб команду не відривали на пожежі кожного тижня. Зазвичай це заступник директора або сильний операційний менеджер.
- Ключові користувачі по процесах. По одній людині з продажів, закупівель, складу, фінансів, виробництва. Вони знають процеси на практиці, тестують налаштування на своїх операціях і потім навчають колег. Саме від їхньої залученості залежить, чи прийме компанія систему.
- Головний бухгалтер або фінансовий контролер. Відповідає за міграцію залишків, мапінг рахунків і те, щоб перше закриття місяця в новій системі пройшло чисто.
- IT-фахівець. Дивиться на інфраструктуру, доступи, інтеграції і технічні питання, які виникають під час роботи.
Сторона інтегратора. Хто працює над проєктом
Чесний інтегратор відкрито показує свою команду, і в ній теж є обов’язкові ролі.
- Керівник проєкту. Відповідає за графік, ризики і комунікацію. Саме до нього ви звертаєтеся з будь-яким питанням, і саме він організовує регулярні наради з демонстрацією результату.
- Бізнес-аналітик. Проводить інтерв’ю, описує процеси, робить Fit-Gap аналіз і готує технічне завдання. Це людина, яка перекладає мову бізнесу на мову налаштувань системи.
- Консультанти з фінансів, логістики, виробництва. Налаштовують модулі у своїх ділянках, відповідно до ТЗ, і перевіряють, чи працює сценарій на реальних прикладах замовника.
- Розробники. Пишуть кастомізації та інтеграції там, де типового функціоналу не вистачає.
- Фахівець з міграції даних. Будує скрипти перенесення, проводить тестові міграції та звірку залишків.
- Консультант з навчання. Готує інструкції, проводить тренінги для ключових користувачів і супроводжує запуск.
Якщо інтегратор не може назвати, хто з його людей відповідатиме за кожну з цих ролей, великий шанс, що реально працюватимуть троє програмістів без аналітика, і процеси ви будете описувати самі за власний рахунок, і це буде перший сюрприз із серії тих, про які договір розповідав зовсім інакше.
Як розподілити відповідальність, щоб ніхто ні за що не відповідав
Найгірший сценарій у проєкті називається спільною відповідальністю, бо на практиці це означає, що відповідального немає. Тому в договорі кожна роль має мати свої зобов’язання з термінами, і з обох боків. Наприклад, замовник зобов’язується ухвалювати рішення протягом п’яти робочих днів, а інтегратор надавати матеріали на погодження за три дні до наради. За простій з вини замовника в нашому договорі передбачена оплата 70% вартості робіт, і ця неприємна цифра рятує проєкти від місяців мовчання краще за будь-які мотиваційні листівки.
Те саме стосується тестування. Хтось із замовника має особисто підписати, що прийняв налаштування модуля, бо після підписання переробка стає зміною з окремою ціною. Це жорстко, проте саме так зникає класична ситуація, коли проєкт формально готовий, а бізнес претензій має на сім місяців.
Чого команда не потребує
Для повноти картини варто сказати, кого виділяти не треба. Повний штат співробітників на проєкт не садять, бо це вб’є операційну роботу. Не потрібен і окремий технічний директор з боку замовника, якщо інтегратор несе відповідальність за архітектуру, і не потрібна команда програмістів, бо кастомізацію робить інтегратор. Усе, що потрібно від компанії, це описані вище п’ять ролей, зайняті на частку свого часу, але не замінні на будь-якому етапі.
Скільки часу займає участь у проєкті
Питання, яке цікавить кожного власника перед стартом, звучить приблизно так. А скільки годин на тиждень це все забере у моїх людей? Орієнтовна відповідь з нашої практики виглядає так. Спонсор витрачає кілька годин на місяць, цього достатньо для щомісячної зустрічі та оперативних рішень, які не можуть чекати. Керівник проєкту з боку замовника зайнятий від п’яти до десяти годин на тиждень, залежно від етапу, а в пікові періоди тестування трохи більше. Ключові користувачі відриваються від роботи на десять-п’ятнадцять годин на тиждень лише в місяці тестування і навчання, коли систему треба обжити на реальних операціях до того, як вона торкнеться всіх, а в інші етапи їхня участь обмежується інтерв’ю та короткими погодженнями.
Якщо додати ці години до зарплат цих людей, вийде помітна цифра, яку майже ніхто не рахує, вважаючи участь команди безкоштовною. Краще побачити її на етапі бюджету, ніж дивуватися посеред проєкту, чому операційна робота компанії раптом пішла на спад без жодних видимих причин.
Як команда влаштована у проєктах CBPM Service
На старті ми подаємо склад своєї команди поіменно з ролями і просимо замовника сформувати дзеркальний склад зі свого боку. Працюємо спринтами з нарадами кожні два тижні і щомісячною зустріччю зі спонсором проєкту, тож рішення затримуються днями, а не місяцями. Якщо на якомусь етапі бачимо, що команді замовника не вистачає людей, говоримо про це одразу, поки це питання графіка, а не договору про невиконання.
Хочете зрозуміти, скільки людей і яких потрібно виділити для вашого проєкту, почніть з безкоштовної експрес-оцінки на сайті CBPM Service.
