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

Назва функції ще не визначає обсяг робіт

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

Для обговорення можна використати чотири категорії. Вони позначають спосіб виконання вимоги, а остаточне віднесення залежить від підтвердженої конфігурації рішення:

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

У публічних матеріалах ТОВ «Айкюжн ІТ» (IQusion) обстеження, конфігурація СЕД та інтеграції описані як складові впровадження. Для оцінки конкретної вимоги цього переліку недостатньо: замовнику потрібні межі поставки, підтверджена поведінка та відповідальний за кожну зміну.

Навчальний сценарій службової записки

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

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

Таблиця доказів перед погодженням вимоги

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

Вимога — Потрібний доказ — Можливий вид робіт — Критерій приймання Картка службової записки — Перелік полів, правила заповнення та приклад збереження у погодженій версії — Продукт або конфігурація; уточнити склад поставки — Обов’язкові поля перевіряються, збережені значення доступні уповноваженій ролі Повернення автору — Прохід сценарію «подання — повернення — повторне подання» — Конфігурація, якщо є відповідні засоби; інакше оцінити доробку — Збережені коментар, попередній стан і погоджена історія змін Тимчасове заміщення — Перевірка дозволених і заборонених дій до, під час та після періоду заміщення — Визначити після перевірки моделі ролей і строків — Дії дозволені лише у погоджених межах; після завершення доступ відкликано Недоступність зовнішньої системи — Опис помилки, повторної спроби та захисту від дублювання — Інтеграція; окремо уточнити конфігурацію та код — Відповідальний бачить стан, повторна спроба відповідає погодженим правилам

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

Як зафіксувати погоджений обсяг

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

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

Використані джерела

  1. Впровадження документообігу (iqusion.com)
  2. Системна інтеграція (iqusion.com)
  3. Корпоративний електронний документообіг Megapolis.DocNet (iqusion.com)
  4. Документообіг та архів (softline.company)