Цей текст призначений для правлінь та осіб, які підписуються під купівлею системи: секретаря та скарбника в установі, директора комунального підприємства, фінансового директора, власника компанії. А також для керівника ІТ, який готує тендер або запит пропозицій і хоче знати, на що правління повинно звернути увагу, перш ніж затвердити документи.
Чому виникає ця проблема
Більшість проблем із постачальниками виникають з боку замовника, причому задовго до підписання договору. Не через погані наміри: підготовка тендеру - це робота, на яку в організації рідко вистачає часу й компетенцій, а постачальники охоче її полегшують. Вони приносять готові описи, презентації та кошторисні пропозиції. Внаслідок цього замовник купує те, що постачальник вміє продати, а не те, що йому насправді потрібно. Проблемою є також те, що дуже часто закупівельні рішення залишаються в руках профільних підрозділів, а ІТ виконує лише роль охоронця безпеки. Відсутність стандартів і довгострокової ІТ-стратегії призводить до того, що організація здійснює закупівлі, які не завжди відповідають рамкам, завданням яких є мінімізація ризиків.
Ті самі помилки я бачу і в установах, і в компаніях. Їх відрізняє процедура закупівлі, а не сам механізм.
Дванадцять помилок
- Вимоги, складені на основі пропозиції або презентації одного постачальника. Це обмежує конкуренцію та закріплює залежність ще до вибору виконавця. Детальніше я писав про це в статті про залежність від постачальника в тендерній специфікації (SWZ).
- Відсутність бізнес-власника. У проєкту формально є керівник, але ніхто з мандатом правління не вирішує, як мають працювати процеси.
- Відсутність критеріїв приймання та тестових сценаріїв до підписання. Приймання перетворюється на суперечку щодо тлумачення, а не на перевірку того, чи продукт проєкту відповідає критеріям успіху впровадження.
- Незнання того, що вже є. Ви купуєте нову систему, не знаючи, які наявні договори, ліцензії та функції з нею перетинаються.
- Пропущені інтеграції. З чим нова система має обмінюватися даними, в яких напрямках, які системи мають провідну роль, які дані, за допомогою яких форматів, а також чи знає про це постачальник і чи гарантує, що надасть необхідні механізми та візьме на себе відповідальність за безперервність їхньої роботи.
- Міграція даних, описана одним реченням. Без визначення того, які дані, за який період, хто їх очищає і хто перевіряє результат.
- Вимоги у формі переліку функцій замість опису процесів. Кожен постачальник відповість «так» на запитання про функцію. А на запитання, як він обслужить ваш конкретний випадок, відповіді вже відрізняються.
- Порівняння стартової ціни замість загальної вартості. Ліцензія - це лише початок. За обслуговування, зміни й інтеграції платять роками. Про цей механізм я пишу в статті про загальну вартість володіння (TCO) і варіння жаби.
- Відсутність правил зміни обсягу. Незрозуміло, хто подає зміну, хто її оцінює і хто затверджує.
- Договір без умов виходу. Відсутні положення про експорт даних, документацію та передачу обслуговування іншому суб'єкту. Немає інструментів мінімізації ризику.
- Договір на обслуговування, прийнятий за шаблоном постачальника. У такому разі рівні послуг, час реакції та вартість змін визначає одна сторона.
- Рішення, відкладене до останнього моменту перед строком. Коли законодавчий термін або кінець підтримки старої системи вже близько, не залишається місця для порівняння пропозицій чи переговорів.
Помилки з першої до третьої є первинними. Якщо ви їх усунете, більшість решти стане помітною на етапі підготовки, а не реалізації.
Для ради, наглядової ради або центрального органу найважливіше те, чи має рішення про вибір постачальника документально підтверджене обґрунтування. Дванадцять пунктів вище - це водночас перелік запитань, які варто поставити, перш ніж правління затвердить документи тендеру.
Приклад з практики
Один із наших клієнтів отримав від постачальника системи ERP інформацію про те, що обмін даними про контрагентів із впроваджуваною системою управління кореспонденцією (EZD/e-Doręczenia) відбудеться без проблем. Система управління кореспонденцією найчастіше зберігає дані всіх контрагентів, а не лише тих, щодо яких відбудуться господарські події, тобто вони стануть клієнтами або постачальниками. Просто життєвий цикл даних нового контрагента найчастіше починається значно раніше, ніж відбуваються господарські події.
Під час впровадження виявилося, що витрати на адаптацію API-інтерфейсу для двостороннього обміну даними про контрагентів з боку постачальника системи ERP становлять 80% усієї вартості проєкту впровадження обігу видаткових документів в інтеграції з KSeF, з OCR, WIES, GUS і, нарешті, з експортом даних до фінансово-облікової системи. Ця одна інтеграція, яку на початку не обговорили детально з постачальником, практично подвоїла вартість проєкту.
Коли потрібен незалежний радник
Якщо у вас досвідчена команда, яка вже підготувала кілька подібних тендерів, цей перелік слугуватиме контрольним списком. Незалежний погляд має сенс, коли тендер великий за масштабом організації, коли вимоги формувалися в контакті з одним постачальником, коли рішення доведеться захищати перед контролюючим органом, радою чи центральним органом, або коли з боку замовника ніхто не знає ці системи зсередини.
Я можу переглянути документи перед публікацією тендеру або надсиланням запиту пропозицій, підготувати вимоги та тестові сценарії або оцінити вже подані пропозиції. В установах стартова точка виглядає трохи інакше, я описую її на сторінці для органів місцевого самоврядування (JST).