Інвентаризація ІТ-систем і архітектурних стандартів — найменший і найдешевший крок на всьому шляху цифровізації. І єдиний, що дає органу влади чи компанії, а не постачальнику, контроль над напрямом розвитку на наступні 10 років.
Приклад односторінкового резюме для керівництва. Ілюстративні дані.
Система класу EZD (електронне діловодство), електронні адміністративні послуги, обіг рахунків-фактур у KSeF (польській національній системі електронних рахунків-фактур), нова платформа для бізнес-процесів — кожне з цих рішень коштує сотні тисяч злотих і на роки прив’язує організацію до постачальника. Інвентаризація дає об’єктивне знання про те, що у Вас насправді є, у якому воно стані і чого бракує, ще до ухвалення рішення — щоб напрям визначали Ви, а не комерційна пропозиція постачальника.
| Без інвентаризації | Після інвентаризації |
|---|---|
| Тендерну документацію пишуть на основі пропозицій постачальників. Нерідко саме ці пропозиції й визначають вимоги. | Тендерну документацію пишуть на основі реальних потреб — вимоги визначає замовник, постачальник їх виконує |
| Положення про відкритість і план виходу залишаються на рівні «може, допишемо згодом» | 20 типових архітектурних положень, обов’язкових у кожному ІТ-договорі |
| Системи з функціями, що дублюються, — організація платить двічі | Точно відомо, що є в організації і де прогалини, — купуються лише ті можливості, яких бракує |
| Додаткові угоди за інтеграції, пропущені в тендерній документації, — коштом замовника | Каталог обов’язкових інтеграцій із центральними системами в тендерній документації з першого дня |
| Ризик невідповідності KSC/NIS 2/GDPR/AI Act виявляється лише під час аудиту | Вимоги щодо регуляторної відповідності прописані в тендерній документації, і їх виконання вимагають від постачальника |
| Залежність від постачальника — через роки його неможливо змінити без утрати даних | Положення про експорт даних, план виходу, депонування вихідного коду — замовник повністю зберігає контроль |
| Немає обґрунтування закупівельного рішення, коли його вимагають контролюючі органи | Задокументована категоризація A/B/C/D та обґрунтування рішення |
| Заявки на фінансування ЄС без надійної аналітичної бази | Вихідні матеріали для заявок на кошти ЄС, KPO та національних програм |
Підготовлений з нуля незалежним радником і адаптований до специфіки Вашої організації — а не шаблон, який Вам доведеться заповнювати самостійно. Загалом 16 документів та інструментів, що становлять фундамент цифрової трансформації та реалізації довгострокової ІТ-стратегії.
Стартовий семінар із керівництвом (староста повіту чи голова правління, секретар, тобто керівник апарату, та ІТ) та інвентаризаційна анкета для структурних підрозділів і постачальників.
Аналіз документації, інтерв’ю з власниками систем (5–10 × 45–60 хв), технічна перевірка разом з ІТ. 1–3 дні зустрічей із власниками процесів на місці, решта — онлайн.
Попередня категоризація A/B/C/D і валідаційний семінар з керівниками підрозділів.
Звіт і повний комплект документів; підготовка та проведення презентаційної сесії для керівництва (60–90 хв).
Наведіть курсор на рядок або виберіть його клавішею Tab, щоб побачити приклад.
| Кат. | Визначення | Типова дія |
|---|---|---|
| A | Системи, що відповідають цільовій архітектурі, висока зрілістьПриклад: кадрово-зарплатна система з чинним сервісним договором і відкритим API. | Підтримка та контрольований розвиток |
| B | Правильний напрям, потрібні доопрацюванняПриклад: фінансово-бухгалтерська система без інтеграції з KSeF. | План модифікацій, переговори з постачальником |
| C | Система несе ризик — застаріла технологія, завершення підтримки, залежність від постачальника, відсутність інтеграціїПриклад: система документообігу, виробник якої наступного року припиняє підтримку. | План виведення з експлуатації та заміни |
| D | Можливість, якої бракує в портфелі й яка знадобиться в горизонті 1–10 роківПриклад: обіг рахунків-фактур за витратами, який сьогодні ведеться через електронну пошту й таблицю. | Пріоритизація впроваджень, вибір моделі реалізації |
A зберегти
B доопрацювати
C вивести та замінити
D заповнити прогалину
Оцінка ґрунтується на 5 зважених критеріях: функціональність і бізнес-цінність (20%), архітектура та відкритість — API, інтеграції, стандарти, готовність до ШІ (25%), безпека та відповідність — KSC/NIS 2/GDPR/KRI/WCAG (20%), технологія та постачальник — актуальність, підтримка, залежність від постачальника (20%), економіка та повна вартість володіння (15%).
Вартість залежить від кількості систем і структурних підрозділів. Точну ціну я визначаю після 30-хвилинної розмови про масштаб Вашої організації.
Для порівняння: повний комплект стратегічних документів і стандартів, замовлений окремо, коштував би 40 000–80 000 злотих.
Методика → картка ініціативи → архітектурна оцінка → положення для закупівлі → реєстр ризиків.
Каталог стандартів, 20 договірних положень і картка оцінки — Ви знаєте, про що питати, ще до того, як сядете за стіл із постачальником.
Матриця інтеграцій із центральними системами як готова відправна точка для кожного наступного інтеграційного проєкту.
Оновлення кожні 12–18 місяців — самостійно силами Вашої ІТ-служби за тією самою методикою або як оновлення інвентаризації, яке проводить радник.
Зазвичай 2–6 тижнів від підписання договору до презентаційної сесії для керівництва — залежно від кількості систем. Лише 1–3 дні припадає на роботу на місці, решта відбувається дистанційно. Координатор з боку організації витрачає загалом близько 10 годин.
Ні. Її результат — вимоги, договірні положення та матриця інтеграцій, тобто те, що однаково потрібно підготувати перед закупівлею. Зазвичай вона навіть скорочує підготовку закупівлі, бо замінює збирання пропозицій від постачальників як відправну точку.
Це метод оцінювання кожної системи за п’ятьма зваженими критеріями (функціональність, архітектура та відкритість, безпека та відповідність, технологія та постачальник, економіка та повна вартість володіння), за підсумками якого система потрапляє до однієї з чотирьох категорій: A (зберегти), B (доопрацювати), C (запланувати заміну) або D (можливість, якої бракує і яку треба запланувати).
Ні — роботу ведуть на рівні систем, договорів і конфігурації, без доступу до персональних даних, що обробляються в цих системах. Якби в конкретному випадку такий доступ був потрібен, для цього знадобився б окремий договір доручення обробки відповідно до ст. 28 GDPR.
Вони стають відправною точкою для подальших кроків: технічного завдання нового проєкту, підготовки до переговорів із постачальниками, заявок на фінансування, наступного періодичного оновлення, яке Ваша власна ІТ-служба проводить самостійно за тією самою методикою. Це не звіт, який ляже в шухляду.
Аудит безпеки перевіряє відповідність конкретному стандарту чи нормі і завершується переліком невідповідностей. Інвентаризація дає ширшу, бізнесову картину всього портфеля систем — витрати, ризики, прогалини, напрям розвитку — і одразу перетворюється на робочі документи для наступних рішень, а не лише на перелік того, що треба виправити.
Так. Реєстр застосунків містить для кожної системи власника, договір, ліцензію, вартість і дату завершення підтримки. Завдяки цьому видно, строк яких договорів спливає, де організація залежить від одного постачальника і скільки насправді коштує обслуговування.
