Основи бізнес-аналізу у військовій сфері. Роль і завдання аналітика

Тема 3: Бізнес-аналіз та вимоги до ІТ-продуктів · Заняття 1

1. Поняття та цілі бізнес-аналізу у проєктах ЦТ ЗСУ

1.1. Що таке бізнес-аналіз

Бізнес-аналіз — діяльність із виявлення потреб, аналізу проблем і визначення рішень, що приносять цінність зацікавленим сторонам. У проєктах ЦТ бізнес-аналіз відповідає на питання «яку проблему ми вирішуємо і що саме має робити рішення», перш ніж переходити до «як його побудувати».

1.2. Роль «містка» між потребою і рішенням

Бізнес-аналітик (BA) — інтерфейс між користувачами (носіями потреби) і розробниками (реалізаторами рішення). Він перекладає «біль» підрозділу мовою вимог, зрозумілою розробникам, і навпаки — пояснює користувачам можливості й обмеження рішення.

1.3. Цілі бізнес-аналізу

розв’язати правильну проблему (а не ту, що «на поверхні»);
сформувати повні, однозначні, верифіковні вимоги;
уникнути найдорожчої помилки — «зробили не те»;
забезпечити, щоб рішення реально використовувалося й давало ефект (outcome).

1.4. Бізнес-аналіз і суміжні ролі

Роль	Фокус
Бізнес-аналітик (BA)	Яку проблему вирішуємо; що має робити рішення (вимоги).
Проєктний менеджер (PM)	Як організувати роботу: строки, ресурси, ризики.
Системний аналітик / архітектор	Як технічно побудувати рішення.

1.5. Специфіка у ЗСУ

У військовій сфері бізнес-аналіз ускладнюється: користувачі не завжди можуть чітко сформулювати потребу; діють нормативні обмеження та вимоги захисту інформації; потрібно враховувати умови застосування (польові, бойові). Тому BA у ЗСУ особливо потребує спостереження за реальною роботою й перевірки припущень.

1.6. Цінність бізнес-аналізу: вартість поганих вимог

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

Де виявлено помилку вимоги	Відносна вартість виправлення
На етапі збору вимог	Мінімальна (переформулювати).
На етапі розробки	Помітна (переробити частину).
На етапі випробувань	Висока (переробка + повторне тестування).
Після впровадження	Дуже висока (переробка, погодження, втрата довіри).

Саме тому вкладення в якісний бізнес-аналіз на старті — це економія ресурсу й часу надалі, а не «затримка перед розробкою».

1.7. Принципи бізнес-аналізу

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

Типові помилки:

перехід до «як побудувати» без відповіді «яку проблему вирішуємо»;
ототожнення потреби з першим запропонованим рішенням;
ігнорування нормативних вимог і вимог ЗІ на етапі аналізу.

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

2. Роль і завдання бізнес-аналітика на кожному етапі проєкту

2.1. BA у життєвому циклі проєкту

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

2.2. Завдання BA за етапами

Етап	Завдання BA	Артефакт
Discovery	Виявити реальну потребу й проблему підрозділу.	Проблемна заява.
Аналіз	Дослідити поточний процес, причини, стейкхолдерів.	Аналітична записка, модель AS-IS.
Вимоги	Сформувати вимоги різних рівнів, пріоритезувати.	Специфікація вимог.
ТЗ	Формалізувати вимоги у ТЗ, приймальні критерії.	ТЗ.
Розробка	Уточнювати вимоги, відповідати на питання команди.	Оновлені вимоги, роз’яснення.
Приймання	Перевірити відповідність приймальним критеріям.	Результати приймання.
Розвиток	Аналізувати зворотний зв’язок, формувати доопрацювання.	Беклог доопрацювань.

2.3. Ключові компетенції BA

аналітичне мислення (декомпозиція, причинно-наслідковий аналіз);
комунікація й уміння слухати (виявлення прихованих потреб);
чіткість викладу (однозначні формулювання вимог);
розуміння предметної області (процесів підрозділу).

2.4. Взаємодія зі стейкхолдерами

BA працює з різними стейкхолдерами: користувачі (потреба), командування (цілі), розробники (реалізація), орган ЗІ (безпека), PM (координація). Уміння узгодити суперечливі очікування — частина роботи BA.

2.5. Наскрізний приклад роботи BA

Розглянемо роботу BA на прикладі потреби «облік майна займає багато часу».

Discovery. BA спостерігає за інвентаризацією й інтерв’ює відповідальних; виявляє, що час іде на ручне звіряння паперових журналів і пошук розбіжностей — це і є справжня проблема, а не «повільність» узагалі.

Аналіз. BA будує модель поточного процесу (AS-IS), визначає вузьке місце (ручне звіряння) і причини (дублювання даних, відсутність єдиного джерела).

Вимоги. BA формує вимоги: єдиний реєстр майна, автоматичне звіряння, розмежування доступу; пріоритезує (MoSCoW: єдиний реєстр — Must).

ТЗ. BA формалізує вимоги у ТЗ з приймальними критеріями (час інвентаризації ≤ 1 дня) і закладає вимоги ЗІ.

Приймання й розвиток. BA перевіряє відповідність критеріям, збирає зворотний зв’язок і формує беклог доопрацювань.

Приклад показує: якби BA одразу «прийняв» рішення «зробити систему швидшою», справжня проблема (ручне звіряння) могла б лишитися невирішеною.

Типові помилки:

залучення BA лише на етапі ТЗ, а не з discovery;
робота «за столом» без контакту з реальними користувачами;
ігнорування частини стейкхолдерів (напр., органу ЗІ).

Проміжний висновок: BA задіяний на всіх етапах; його рання участь (з discovery) визначає якість усього проєкту.

3. Методи і техніки збору вимог

3.1. Огляд методів

Збір вимог (elicitation) — активний процес виявлення потреб, а не просте «записування» того, що скаже користувач. Різні методи дають різну інформацію; зазвичай їх комбінують.

Метод	Суть	Коли доречний
Інтерв’ю	Бесіда з користувачем/стейкхолдером.	Глибоке розуміння потреб окремих осіб.
Спостереження	Спостереження за реальною роботою.	Виявлення того, що не проговорюється.
Workshop	Груповий збір вимог, узгодження.	Швидке узгодження між стейкхолдерами.
Анкетування	Опитування багатьох респондентів.	Масовий збір, кількісні дані.
Аналіз документів	Вивчення наявних НПА, інструкцій, звітів.	Розуміння правил і обмежень.
Прототипування	Показ чернетки рішення для уточнення.	Уточнення вимог через реакцію на зразок.

3.2. Інтерв’ю

Інтерв’ю потребує підготовки: визначити мету, скласти план запитань, поєднувати відкриті питання («розкажіть, як ви це робите») і закриті (уточнення). Уникати навідних питань, що підказують «потрібну» відповідь. Фіксувати відповіді й перевіряти розуміння перефразуванням.

3.3. Спостереження

Спостереження за реальною роботою користувача виявляє те, що люди не проговорюють (звички, обхідні шляхи, реальні складнощі). У ЗСУ це особливо цінно: реальний процес часто відрізняється від «паперового».

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

3.4. Workshop

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

3.5. Анкетування

Анкетування ефективне для масового збору (багато користувачів, географічно розподілених). Дає кількісні дані, але не глибину; питання мають бути однозначними.

3.6. Вибір методу

Метод обирають під ситуацію: для глибини — інтерв’ю та спостереження; для узгодження — workshop; для масштабу — анкетування; для контексту правил — аналіз документів. Найкращий результат дає комбінація.

3.7. Документування та валідація вимог

Зібрані вимоги потрібно задокументувати й перевірити. Документування: чіткі, однозначні формулювання, згруповані за рівнями (бізнес, стейкхолдер, рішення). Валідація — перевірка з користувачами, що вимоги правильні й повні (наприклад, повторний перегляд, прототип). Верифікація — перевірка якості формулювань (однозначність, несуперечливість).

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

Типові помилки:

«записування» вимог без активного виявлення прихованих потреб;
навідні питання, що підказують відповідь;
опора лише на слова без спостереження за реальною роботою.

Проміжний висновок: збір вимог — активний процес; комбінація методів (особливо спостереження) виявляє справжні потреби.

4. Структура та правила підготовки аналітичної записки

4.1. Призначення

Аналітична записка — документ, що структуровано подає результат аналізу проблеми та обґрунтовує рекомендоване рішення для прийняття управлінського рішення. Це «місток» від аналізу до рішення командування.

4.2. Структура

Проблема / привід: що спонукало до аналізу.
Поточний стан (AS-IS): як процес відбувається зараз, з даними.
Аналіз: причини проблеми, вузькі місця, наслідки.
Варіанти рішення: 2–3 альтернативи з перевагами й недоліками.
Оцінка варіантів: за критеріями (цінність, вартість, строк, ризик).
Рекомендація: обґрунтований вибір і наступні кроки.

4.3. Правила підготовки

спиратися на дані й факти, а не на враження;
писати чітко й стисло, мовою рішення (для командування);
подавати кілька варіантів, а не єдиний «очевидний»;
чітко відокремлювати факти від припущень і оцінок.

4.4. Практичне значення

Якісна аналітична записка перетворює аналіз на рішення: командування отримує обґрунтовану основу для вибору, а не «сиру» інформацію. Це один із головних інструментів впливу BA/офіцера ЦТ.

4.5. Приклад структури заповненої записки

Проблема. Інвентаризація майна у частині триває 3 дні, є розбіжності обліку й факту.

Поточний стан. Облік ведеться в паперових журналах; звіряння — вручну; дані дублюються.

Аналіз. Вузьке місце — ручне звіряння; причина — відсутність єдиного реєстру; наслідок — втрата часу й помилки.

Варіанти. А — готове ПЗ обліку; Б — власна розробка; В — електронні таблиці.

Оцінка. За критеріями (цінність, строк, ризик) перемагає варіант А (готове ПЗ).

Рекомендація. Впровадити готове ПЗ обліку; наступні кроки — ТЗ, пілот, погодження ЗІ.

Повний приклад — Додаток 6.

Типові помилки:

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

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

Контрольні питання

Що таке бізнес-аналіз і які його цілі у проєктах ЦТ?
У чому різниця між ролями BA, PM і системного аналітика?
Опишіть завдання BA на етапах життєвого циклу проєкту.
Порівняйте методи збору вимог: коли який доречний?
Чому спостереження часто виявляє більше, ніж інтерв’ю?
Опишіть структуру аналітичної записки та правила її підготовки.

Завдання на самостійну підготовку

Тема: Типи вимог та підходи до їх категоризації.

Опрацювати функціональні, нефункціональні та бізнес-вимоги: визначення та приклади.
Опрацювати визначення пріоритетності вимог: метод MoSCoW та модель Kano.
Підготувати проблемну заяву й план збору вимог для реального процесу свого підрозділу.

Довідка для підготовки:

Типи вимог: бізнес-вимоги (навіщо, який ефект) → стейкхолдер-вимоги (що потрібно користувачам) → вимоги до рішення (функціональні: що робить; нефункціональні: безпека, продуктивність, доступність) → перехідні (міграція, навчання);
MoSCoW — швидко розподілити вимоги на Must / Should / Could / Won’t;
Kano — модель, що розрізняє базові (обов’язкові), очікувані (лінійні) та захопливі (delighters) вимоги за впливом на задоволеність користувача.

Додаток 1. Порівняння методів збору вимог

Метод	Переваги	Обмеження
Інтерв’ю	Глибина, гнучкість, довіра.	Витратне за часом; суб’єктивність.
Спостереження	Виявляє реальну роботу й приховане.	Ефект присутності; час.
Workshop	Швидке узгодження, синергія.	Ризик домінування окремих осіб.
Анкетування	Масштаб, кількісні дані.	Немає глибини; ризик нечітких питань.
Аналіз документів	Правила, обмеження, контекст.	Документи можуть бути застарілі.

Додаток 2. Шаблон аналітичної записки

Розділ	Зміст (заповнити)
Проблема / привід
Поточний стан (AS-IS) з даними
Аналіз причин і вузьких місць
Варіанти рішення (2–3)
Оцінка варіантів за критеріями
Рекомендація та наступні кроки

Додаток 3. Гайд підготовки та проведення інтерв’ю

Визначити мету інтерв’ю та ключові питання, на які треба відповісти.
Скласти план: відкриті питання (розуміння) + закриті (уточнення).
Уникати навідних питань, що підказують відповідь.
Фіксувати відповіді; перевіряти розуміння перефразуванням.
Уточнювати «як є насправді», а не «як має бути за інструкцією».
Наприкінці узагальнити почуте й узгодити висновки.

Додаток 4. Чек-лист якості вимоги

Однозначність: вимога тлумачиться лише в один спосіб.
Повнота: описано все потрібне, без прогалин.
Несуперечливість: не конфліктує з іншими вимогами.
Верифіковність: можна перевірити виконання (є приймальний критерій).
Трасовність: відомо джерело вимоги (потреба, стейкхолдер).
Реалістичність: вимога здійсненна в межах обмежень.

Додаток 5. Глосарій ключових термінів

Бізнес-аналіз — діяльність із виявлення потреб і визначення рішень, що дають цінність.
Бізнес-аналітик (BA) — фахівець-«місток» між потребою користувача та рішенням.
Elicitation — активний збір (виявлення) вимог.
Стейкхолдер — зацікавлена сторона проєкту.
Аналітична записка — структурований документ аналізу з рекомендацією.
Функціональна вимога — що система має робити.
Нефункціональна вимога — якісні характеристики: безпека, продуктивність, доступність.
MoSCoW — пріоритезація: Must, Should, Could, Won’t.
Модель Kano — класифікація вимог за впливом на задоволеність користувача.
Трасовність (traceability) — простежуваність вимоги від потреби до рішення.

Додаток 6. Приклад заповненої аналітичної записки (для розбору)

Розділ	Зміст
Проблема / привід	Інвентаризація майна триває 3 дні; систематичні розбіжності обліку й факту (до 15%).
Поточний стан (AS-IS)	Облік у паперових журналах; ручне звіряння; дублювання даних у кількох підрозділах.
Аналіз	Вузьке місце — ручне звіряння (60% часу); причина — відсутність єдиного реєстру; наслідок — втрата часу, помилки, недостовірні дані для командира.
Варіанти	А — готове ПЗ обліку; Б — власна розробка; В — електронні таблиці.
Оцінка (цінність/строк/ризик)	А: висока/швидко/середній; Б: висока/довго/середній; В: низька/швидко/високий.
Рекомендація	Впровадити готове ПЗ (А). Кроки: розробка ТЗ, погодження ЗІ, пілот у 1 підрозділі, масштабування.

Додаток 7. Приклад матриці стейкхолдерів проєкту БА

Стейкхолдер	Інтерес / потреба	Внесок у вимоги
Користувачі (відповідальні за облік)	Швидкий і простий облік.	Функціональні вимоги, зручність.
Командування	Достовірні дані для рішень.	Бізнес-вимоги, звітність.
Орган ЗІ	Захист інформації.	Нефункціональні вимоги (ЗІ, доступи).
Розробники / підрядник	Чіткі вимоги й ТЗ.	Реалізовність, уточнення.

Додаток 8. Шаблон проблемної заяви (problem statement)

Проблемна заява — стислий (кілька речень) опис проблеми, з якого починається бізнес-аналіз. Структура:

Елемент	Опис (заповнити)
Кого стосується проблема
У чому проблема (симптом)
Наслідки / вплив (чому це важливо)
Бажаний результат (outcome)

Приклад: «Відповідальні за облік майна витрачають до 3 днів на інвентаризацію через ручне звіряння паперових журналів, що призводить до розбіжностей і недостовірних даних для командира. Бажаний результат — інвентаризація за 1 день із достовірними даними».