Як підготувати компанію до вибору системи workflow/BPM/RPA/ERP/CRM, щоб не потрапити в залежність від постачальника?

Потім запишіть вимоги, що захищають від залежності від постачальника: експорт даних і історії справ у відкритому форматі, задокументоване API, процеси, записані за стандартом BPMN, право на власну конфігурацію та чіткі правила виходу з договору. Назвіть ризики, які ви вже сьогодні можете визначити. Не будьте наївними — запишіть усі ризики. Пропозиції порівнюйте на власних сценаріях і за сукупною вартістю за кілька років (інвестиція плюс повторювані операційні витрати). Ліцензії, поновлення, навчання, утримання команди, зміни, міграції. Подумайте, наскільки ймовірно, що постачальник втратить ключових консультантів, вирішить замінити адміністраторів і розробників на ШІ, перестане підтримувати поточну операційну систему.

Ця публікація — для керівництва компаній і комунальних підприємств (spółka komunalna), які хочуть упорядкувати обіг документів, видаткових рахунків-фактур, договорів або заявок і стоять перед вибором системи workflow, тобто інструмента, який веде справу від однієї особи до наступної за встановленими правилами. Зазвичай на вибір є три шляхи: готова платформа BPM, інструмент low-code або система, розроблена на замовлення; наведені нижче принципи стосуються кожного з них. Також це буде корисно фінансовим директорам, адже саме їм зазвичай доводиться платити за наслідки неправильного вибору.

Чому залежність від постачальника виникає ще на старті

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

Крок 1. Опишіть процеси, перш ніж говорити з постачальниками

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

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

Крок 2. Перевірте, що у вас вже є

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

Крок 3. Вимоги, що захищають від залежності від постачальника

Ці вимоги варто внести до запиту на пропозицію як умови, а не побажання:

1. Експорт даних і історії справ у відкритому, задокументованому форматі, у будь-який момент і без додаткової оплати.
2. Задокументоване API для інтеграції з іншими системами, з правом користуватися ним для інших виконавців.
3. Процеси, записані за стандартом (BPMN), які можна експортувати та відтворити в іншому місці.
4. Право на конфігурацію власною командою або будь-яким партнером, із документацією змін.
5. Правила виходу з договору: перехідний період, допомога в міграції даних і її заздалегідь відома вартість.
6. Вибір партнера з обслуговування: чи можна після впровадження перейти до іншої компанії-впроваджувача без втрати підтримки виробника.

Те саме стосується RPA, ERP і CRM

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

RPA. Перше запитання звучить так: чому саме RPA, а не BPM? Програмний робот перебирає на себе повторювані дії людини в наявних системах, але не змінює сам процес; BPM упорядковує сам процес. Якщо мета — звільнити людей від переписування даних між системами, робота може бути достатньо. Якщо мета — новий, коротший обіг справ, робот часто лише закріплює старий. Робот також залежить від екранів і форматів інших систем: будь-яка їхня зміна може його зупинити, тому варто знати вартість утримання сценаріїв і мати їхній опис поза інструментом виробника.

ERP. Тут ключове питання звучить так: чи має ERP дати нам найкращі практики та готові процеси, чи має підтримувати наші власні процеси, що формують конкурентну перевагу? У першому випадку варто дотримуватися стандарту системи й обмежувати зміни, бо кожна з них ускладнює оновлення та зміну партнера. У другому випадку іноді краще працює простий ERP, обгорнутий гнучкою BPM-системою, у якій змінюються процеси, що вирізняють компанію, без переробки ядра. В обох випадках фінансові, складські та кадрові дані, а також інтеграції з KSeF і банками мають повністю вийматися разом з історією.

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

Крок 4. Порівняйте сукупну вартість, а не ціну ліцензії

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

Крок 5. Приймання та договір обслуговування

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

Приклад із практики

У групі дочірніх компаній міжнародного концерну компанія використовувала центральну систему ERP і водночас потребувала автоматизувати фінансові процеси групи procure-to-pay, причому відповідно до корпоративних закупівельних настанов (corporate purchasing guidelines). Була сильна спокуса скористатися корпоративними інструментами для групової роботи, але вони виявилися доволі дорогими і не відповідали вимогам незалежності та легкого виходу, якби виникли проблеми.

На зустрічах із зацікавленими сторонами ми підготували детальний опис вимог, який виходив за межі стандартних функцій готових рішень. Ми розробили кілька альтернативних способів інтеграції з галузевими системами та механізми, що обмежують ризик прив'язки до одного постачальника. Результатом стала узгоджена прикладна стратегія, заснована на стандартах, і середовище, у якому нові обіги створюються гнучко, через прототипування на коротких зустрічах із власниками процесів, зокрема нетехнічними. Це середовище обгортає систему ERP: воно дає велику гнучкість там, де компанія вирізняється, без витрат на масштабні впровадження.