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