Цей допис — для тих, хто замовляє стратегію, затверджує її або потім має її виконувати: секретарів і скарбників в органах влади, голів і членів правлінь комунальних підприємств, президентів і фінансових директорів компаній, а також керівників ІТ, які хочуть, щоб документ нарешті допомагав їм у розмові про бюджет. Про типові помилки в стратегіях органів влади я писав окремо в дописі ІТ-стратегія в JST (органах місцевого самоврядування): найпоширеніші помилки. Тут я зосереджуся на тому, що повинно бути в самому документі.
Чому стратегії опиняються в шухляді
З того, що я бачив у публічних і приватних організаціях, стратегія рідко буває поганою по суті. Вона опиняється в шухляді, бо нею неможливо скористатися при першому ж конкретному рішенні.
- Починається з бачення, а не з інвентаризації. Ніхто не перевірив, які системи, договори та залежності вже існують, тому план розходиться з реальністю при першій же закупівлі.
- Описує цілі, але не послідовність. Усе важливо, тому нічого не є першочерговим.
- Немає грошей. Відсутність зв'язку з бюджетом призводить до того, що стратегія і фінансовий план живуть окремо.
- Не змінює спосіб закупівель. Наступні системи й надалі купують так само, як раніше, — на основі пропозицій постачальників, а не власних стандартів.
- Немає власника. Документ ухвалили рішенням ради чи правління, і на цьому його життя закінчилося.
- Написана мовою ІТ. Правління і рада не бачать у ній відповідей на свої питання: скільки, навіщо, що станеться, якщо нічого не зробити.
Сім елементів стратегії, якою справді користуються
- Поточний стан. Реєстр систем із власником, договором, ліцензією, вартістю та датою завершення підтримки, карта процесів та інтеграцій, реєстр ризиків. Без цього кожен наступний пункт — лише здогадки. Це завдання для інвентаризації.
- Цільова архітектура. Проста схема того, як співвідносяться між собою реєстри, процеси, інтеграції та доступ. Йдеться не про технічні схеми, а про відповідь на питання, які системи є центральними, а які їх підтримують, де мають створюватися дані і які системи повинні ці дані успадковувати.
- Стандарти. Кілька правил, обов'язкових для кожної закупівлі: як ми надаємо права доступу, яким має бути інтерфейс для працівників, як ми документуємо вимоги, які права на дані ми повинні мати, якою мовою (стандартом) описуємо процеси, як убезпечуємо себе на випадок завершення співпраці.
- Дорожня карта з поділом на зобов'язання та інвестиції. Окремо те, що ми маємо зробити, бо цього вимагає закон чи договір (в органах влади це, наприклад, система класу EZD — система електронного документообігу та діловодства, KSeF — польська система електронного фактурування, або e-Doręczenia — польська система електронної доставки), і окремо те, що ми робимо, бо це вигідно. З послідовністю та обґрунтуванням. Наприклад: рахунок-фактуру, отриману з KSeF, можна зберегти у справі, але відповідно до закону вона повинна пройти змістовне затвердження, формально-розрахункову перевірку і завершити свій шлях автоматичним записом у фінансово-бухгалтерську систему.
- Бюджет із поділом на інвестиції та утримання. Витрати на утримання зростають із кожною новою системою, і вони мають бути видимими ще до ухвалення рішення про закупівлю. Більше про це в дописі про сукупну вартість володіння. Пам'ятайте, що впровадження — це, як правило, одноразова інвестиція (CAPEX), але з погляду бюджету, безперервності роботи та безпеки йдеться, зокрема, про сервісне обслуговування й оновлення (OPEX), які повторюються рік у рік.
- Правила закупівель для систем. Коли потрібна інвентаризація чи аналіз перед закупівлею, хто погоджує пропозицію, які положення обов'язково мають бути в договорі. Частину з них я описав у дописі про SWZ без vendor lock-in.
- Власник і ритм перегляду. Конкретна особа з боку управління повинна здійснювати перегляд стратегії та вартості володіння щонайменше раз на рік під час формування бюджету, дотримуючись чіткого принципу циклічності цих переглядів.
Найпростіший тест стратегії: чи може скарбник або фінансовий директор, готуючи бюджет на наступний рік, прямо взяти з неї позиції та їх обґрунтування? Якщо ні — стратегія і бюджет живуть окремо, а про витрати на ІТ вирішує те, що саме наразі термінове.
Приклад із практики
Компанія «Міський водоканал», що належить гміні середнього розміру, готувала план ІТ-закупівель на наступний рік. Спочатку ІТ-відділ пропонував одночасно замінити офісні комп'ютери, придбати нову систему моніторингу та модернізувати мережеву інфраструктуру. Проте правління попросило показати, які витрати є найтерміновішими з погляду безперервності водопостачання.
Компанія почала з інвентаризації: зібрала дані про обладнання, програмне забезпечення, мережеві з'єднання та сервісні договори, а потім прив'язала їх до конкретних процесів — від обслуговування клієнтів до керування роботою станцій водопідготовки. Виявилося, що частина пристроїв, які забезпечували зв'язок зі станціями, наближалася до кінця терміну підтримки, а документація з'єднань не охоплювала всі локації. Водночас більшість офісних комп'ютерів могла й далі працювати без суттєвого впливу на ключові послуги.
На цій основі змінили послідовність закупівель. Спочатку передбачили впорядкування та захист з'єднань із технологічними об'єктами, а також заміну пристроїв, вихід з ладу яких міг би ускладнити контроль за водопостачанням. Потім запланували доповнення резервного копіювання та моніторингу. Заміну частини офісних комп'ютерів перенесли на пізніший етап.
Перед правлінням ІТ-відділ уже не обґрунтовував бюджет загальною фразою «обладнання застаріле». Він показав залежність: конкретний елемент інфраструктури → обслуговуваний процес → наслідок відмови → пропонована закупівля. Завдяки цьому правління змогло затверджувати витрати поетапно й пояснити наглядовій раді, чому пріоритет отримала інфраструктура, пов'язана з безперервністю послуг, а не найпомітніше для працівників офісне обладнання.
Коли потрібен незалежний радник
Стратегію можна написати власними силами, якщо в організації є людина, яка має на це час і бачить картину в цілому. Зовнішня підтримка стає в нагоді, коли поточний стан не задокументовано, коли стратегія має бути основою для захисту бюджету перед радою, власником чи центральним органом, коли одночасно насувається кілька регуляторних зобов'язань, або коли правління та ІТ по-різному бачать пріоритети і потрібен хтось, хто перекладе одну перспективу на іншу.
Я готую стратегію цифровізації та цільову архітектуру на основі інвентаризації: з дорожньою картою, стандартами, правилами закупівель і бюджетом, який можна буде захистити.