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