Демонстрація СЕД без маркетингового туману: сценарії для перевірки наживо

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

Що підготувати до демонстрації СЕД

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

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

Постанова № 642 стосується експериментального проєкту для документів зі службовою інформацією, тому її не слід перетворювати на універсальне технічне завдання для кожної організації. Водночас визначений нею набір випробувань дає корисний орієнтир для оцінювання СЕД у державному секторі та середовищах із підвищеними вимогами до захисту.

• Знеособлений документ із реальним складом реквізитів і додатків.
• Схема погодження з ролями, строками, заміщенням і щонайменше одним винятком.
• Перелік полів, якими СЕД повинна обмінятися з іншою системою.
• Очікуваний результат: підписаний документ, журнал дій, повідомлення та пакет для зберігання.
• Критерії оцінювання, однакові для всіх систем, що порівнюються.
• Узгоджений спосіб фіксації доказів: запис екрана, журнали або експорт результату.

Один документ: перевірка повного життєвого циклу

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

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

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

• Чи зберігаються всі версії документа та зв'язок між ними?
• Що відбувається із завданнями під час заміщення або зміни структури підрозділу?
• Як система поводиться після недоступності сервісу підпису або інтеграції?
• Які дані входять до журналу аудиту і хто може їх переглядати?
• У якому форматі вивантажуються документ, картка, підписи, зв'язки та історія дій?
• Чи можна повторити той самий сценарій після оновлення системи та порівняти результат?

Маршрути та інтеграції: що змінює адміністратор

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

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

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

Реквізити, підписи й безпека: що показати наживо

Для організаційно-розпорядчих документів перевірте формування реквізитів і бланків за ДСТУ 4163:2020, а для установ, на які поширюється постанова № 55, — правила електронного діловодства та міжвідомчого обміну. Невідповідність окремому правилу оформлення не означає автоматичної юридичної нікчемності документа: наслідки залежать від виду документа, обов'язкових реквізитів і застосовного законодавства. Тому на демо потрібно фіксувати конкретну вимогу та доказ її виконання, а не просити абстрактний сертифікат «повної відповідності».

Для електронного підпису підготуйте тестові сертифікати та покажіть накладання, перевірку, позначку часу, відмову для неприйнятного або нечинного сертифіката і збереження результатів перевірки. Політика підписання має враховувати чинний Закон «Про електронну ідентифікацію та електронні довірчі послуги», тип документа, роль підписувача та правила конкретної організації. Універсальна вимога однаково застосовувати КЕП і УЕП до всіх документів була б некоректною.

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

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

Як зафіксувати результат і порівняти системи

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

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

Поширені питання

Джерела

• Постанова Кабінету Міністрів України № 642 від 20.05.2026
• Постанова Кабінету Міністрів України № 55 від 17.01.2018
• Закон України «Про електронні документи та електронний документообіг»
• Закон України «Про електронну ідентифікацію та електронні довірчі послуги»
• ДСТУ 4163:2020 «Вимоги до оформлення документів»
• Правила безпечного використання КЕП у цифровій взаємодії