Contents

Побудова судової інформаційної системи відбувається не лише в коді. Їй передують і супроводжують її сотні документів: технічні завдання, за якими пишеться програма; нормативні акти, які надають електронним діям юридичної сили; аудити, які показують справжній стан справ; концепції, які визначають, куди рухатися.

Робота з цими документами — і є основна частина впливу на те, якою система врешті стане. Нижче — огляд того, що опрацьовувалося: не перелік файлів, а пояснення, що це за типи документів і чому робота з кожним із них має значення.

Загалом ідеться про 175 комплексних документів, які стосуються 33 підсистем, модулів і наскрізних напрямів. Це без урахування листування, запитів, витягів і робочих версій — лише самостійні документи.

Технічні завдання та вимоги — 47 документів

Найбільша за впливом група. Технічне завдання — це документ, за яким розробник пише програму. Усе, що в ньому не написано, у системі не з’явиться. Усе, що написано нечітко, буде реалізовано так, як зрозумів виконавець.

Тому опрацювання технічних вимог — момент найбільшого важеля. На цьому етапі виправлення коштує зауваження в таблиці. Після здачі системи те саме виправлення коштує окремого договору, грошей і місяців.

Опрацьовувалися вимоги до електронного кабінету, документообігу, суддівського досьє, кадрового й бюджетного модулів, базових сервісів та управління доступом, реєстру виконавчих документів, реєстру судових рішень, контакт-центру, модулів обміну даними.

Практична форма цієї роботи — не просто «прочитати й погодити». Це порівняльні таблиці функціональності, аналітичні звіти щодо вимог, консолідовані переліки й протоколи розбіжностей — документи, які фіксують, у чому замовник і виконавець не дійшли згоди. Останні особливо важливі: незафіксована розбіжність згодом перетворюється на суперечку про те, чи входило це в обсяг робіт.

Аудити — 22 документи

Аудит відповідає на питання, на яке всередині системи відповісти неможливо: чи справді працює те, що заявлено як працююче.

Проводилися перевірки двох типів. Функціональний аудит — чи покриває система реальні процеси суду, чи відповідає тому, як насправді рухається справа. Технічний аудит — стан програмного забезпечення, обладнання, документації, супроводу, захисту інформації, придатність системи до подальшого розвитку.

Перевірка охопила окремі модулі — електронний кабінет, електронний суд, відеоконференцзв’язок, вебпортал, реєстр судових рішень, системи документообігу загальних і спеціалізованих судів — а також наскрізні напрями: апаратне забезпечення, підтримку, тестування, безпеку, інтеграції.

Окремий пласт — акти державних перевірок: Рахункової палати, Державної аудиторської служби, висновки за результатами службових розслідувань. Ці документи фіксували, зокрема, відсутність підсистем, передбачених законом.

Цінність аудиту не в самому факті перевірки, а в тому, що він переводить розмову з площини оцінок у площину фактів. Твердження «система працює погано» можна заперечити. Зафіксовану в аудиті відсутність документації на модуль — ні.

Нормативне регулювання — 42 документи

Найбільша за кількістю група і найменш помітна ззовні.

Технічна система без правових підстав не має юридичної сили. Щоб електронна повістка вважалася врученою, щоб поданий через кабінет документ мав ту саму вагу, що й паперовий, щоб дії в системі можна було оскаржити — усе це має бути описано в нормативному акті.

Основний документ тут — Положення про ЄСІТС, яке визначає порядок функціонування системи та її окремих підсистем. Робота з ним триває роками: система розвивається, з’являються нові модулі, змінюється законодавство — і кожна зміна потребує внесення до Положення.

Технічно ця робота виглядає як порівняльні таблиці змін: чинна редакція, запропонована, обґрунтування. Опрацьовувалися зміни щодо модуля взаємодії, автоматизованого розподілу, розподілу ролей у системі, нагляду за розробкою, кабінету правового утворення, суддівського досьє.

Сюди ж належить узагальнення пропозицій судів. Коли до проєкту змін надходять зауваження від десятків судів, хтось має їх звести, зіставити, відсіяти суперечливі й підготувати підсумкову редакцію. Це чорнова робота, від якої залежить, чи буде норма придатною до застосування на практиці.

Концепції та стратегії — 27 документів

Документи, які визначають напрям руху: якою система має стати, у якій послідовності будуватися, як пов’язана із зобов’язаннями держави.

Сюди належать редакції Концепції побудови системи різних років, стратегічні документи, дорожні карти, техніко-економічні обґрунтування, плани заходів впровадження. Окремо — документи, що пов’язують цифровізацію правосуддя з ширшими зобов’язаннями у сфері верховенства права.

Значення цієї групи в тому, що вона задає критерій, за яким можна оцінити будь-яке окреме рішення. Без зафіксованого бачення кожна пропозиція обговорюється сама по собі, і система розвивається як набір непов’язаних модулів.

Звіти, висновки та аналітика — 22 документи

Проміжні й підсумкові результати роботи: звіти робочих груп, висновки щодо стану окремих підсистем, аналітичні записки, аналіз бізнес-процесів судочинства, звіти щодо ресурсів і архітектури.

Окремо варто виділити описи бізнес-процесів — детальний розбір того, як насправді рухається справа: від первісного подання до виконання рішення, у цивільному, господарському, адміністративному й кримінальному процесах. Це фундамент для будь-яких технічних вимог: не можна автоматизувати процес, який не описано.

Експлуатаційна документація

Найменша за обсягом, але необхідна група: інструкції адміністратора, інструкції з розгортання й відновлення даних, посібники користувача.

Відсутність такої документації — типова проблема, яку фіксували аудити. Система, яку вміє підтримувати лише той, хто її написав, є ризиком незалежно від якості коду.

Що ця робота змінює

Опрацювання документів рідко виглядає результатом. Немає нової кнопки в інтерфейсі, немає запуску, про який можна повідомити. Проте саме тут вирішується більшість того, що згодом стане системою.

Вимоги визначають продукт. Функція, не описана в технічному завданні, не з’явиться. Описана неточно — з’явиться в непридатному вигляді.

Норма визначає юридичну силу. Найдосконаліша технічно система не має значення, якщо дію в ній не можна визнати вчиненою в правовому сенсі.

Аудит визначає, що обговорюється. Поки стан системи не зафіксовано незалежно, будь-яка розмова про її проблеми залишається обміном думками.

Концепція визначає послідовність. Без неї ресурси витрачаються на те, що простіше зробити, а не на те, що потрібніше.

Межі цього огляду

Кілька застережень, без яких цифри були б оманливими.

175 — це комплексні документи, а не весь обсяг роботи. До підрахунку не входять листування, запити, відповіді, витяги, протоколи засідань і робочі версії. У самій робочій теці таких матеріалів у кілька разів більше.

Різні версії одного документа враховані як один. Концепція, що пережила чотири редакції, — це один документ у переліку, хоча роботи з нею було вчетверо більше.

Межа «комплексності» умовна. Порівняльна таблиця змін до нормативного акта — самостійний документ чи етап однієї тривалої роботи? Залежно від відповіді підсумок змінюється приблизно на три десятки.

Огляд не розкриває змісту. Значна частина матеріалів не є публічною, а результати перевірок безпеки не підлягають оприлюдненню з очевидних причин. Тут описано типи документів і характер роботи, а не конкретні висновки.