ChatGPT для бізнес-аналітиків: 8 кейсів аналізу та моделювання
Бізнес-аналітики витрачають 40-50% часу на документацію: вимоги до бізнесу, сценарії використання, процесні потоки, комунікація зі стейкхолдерами. ChatGPT структурує це за хвилини.
Середня економія: 10-12 годин/тиждень на бізнес-аналітика.
📚 Читайте також:
Кейс 1: Документ бізнес-вимог за 45 хвилин
Проблема: Написання повного документа вимог — 4-6 годин
Рішення з ChatGPT: Структурований документ за 45-60 хвилин
Економія: 4-5 годин на документ
Готовий промпт:
Створи документ бізнес-вимог для [проєкт/ініціатива].
Бізнес-контекст:
- Проблема: [поточна болюча точка]
- Можливість: [що можна покращити]
- Стейкхолдери: [хто залучений]
- Бюджет: [орієнтовний]
Створи документ вимог:
1. ВИКОНАВЧЕ РЕЗЮМЕ (300 слів):
- Проблема та її вплив
- Запропоноване рішення
- Очікувані вигоди (віддача від інвестицій)
- Часові рамки та ресурси
2. ПОТОЧНИЙ СТАН:
- Поточний процес (крок за кроком)
- Болючі точки (що не працює)
- Базові метрики (поточні показники)
- Вартість бездіяльності
3. ЗАПРОПОНОВАНЕ РІШЕННЯ (МАЙБУТНІЙ СТАН):
- Новий процес (як буде)
- Ключові зміни (що змінюється)
- Вигоди (кількісні та якісні)
4. ФУНКЦІОНАЛЬНІ ВИМОГИ:
Обов'язково має бути:
- [Вимога 1]: [опис, критерії прийняття]
- [Вимога 2]: [опис, критерії прийняття]
Бажано мати:
- [список]
Можна мати:
- [список]
5. НЕФУНКЦІОНАЛЬНІ ВИМОГИ:
- Продуктивність
- Безпека
- Масштабованість
- Відповідність нормам
6. АНАЛІЗ СТЕЙКХОЛДЕРІВ:
- Хто зачеплений
- Їхні інтереси
- Рівень впливу
- Стратегія комунікації
7. ПРИПУЩЕННЯ ТА ОБМЕЖЕННЯ:
- Що припускаємо
- Обмеження (бюджет/час/технології)
8. РИЗИКИ ТА ЗАЛЕЖНОСТІ:
- Потенційні ризики (Високий/Середній/Низький)
- Стратегії пом'якшення
- Залежності від інших проектів
9. КРИТЕРІЇ УСПІХУ:
- Метрики (ключові показники)
- Цільові значення
- Часові рамки
10. ЗАГАЛЬНИЙ ЧАСОВИЙ ПЛАН:
- Фаза 1: [що, коли]
- Фаза 2: [що, коли]
- Запуск: [цільова дата]
Формат: формальний шаблон документа вимог
Обсяг: 2500-3500 слів
💡 Як працює цей промпт:
Структура документа вимог — класична для бізнес-аналізу:
- Виконавче резюме — для керівництва що має схвалити
- Поточний стан — що маємо зараз, які проблеми
- Майбутній стан — як буде після впровадження
- Вимоги — що саме має бути реалізовано
- Стейкхолдери — хто залучений та як комунікувати
- Ризики — що може піти не так
- Успіх — як вимірюємо результат
✅ Поради для документа вимог:
- Почніть з проблеми: чітко сформулюйте що не працює зараз
- Кількісні вигоди: "економія 10 годин/тиждень" краще ніж "буде швидше"
- Критерії прийняття: для кожної вимоги опишіть як перевіримо
- Пріоритизація: розділяйте на обов'язкове/бажане/можливе
Результат: Час на документ вимог: 5 год → 1 год. Рівень схвалення з першого разу: 85% (було 45%).
Кейс 2: Аналіз розривів за 30 хвилин
Проблема: Комплексний аналіз розривів — 3-4 години
Рішення з ChatGPT: Структурований аналіз за 30-40 хвилин
Економія: 2.5-3 години
Готовий промпт:
Виконай аналіз розривів для [система/процес/можливість]. ПОТОЧНИЙ СТАН: - Що маємо зараз: [список можливостей] - Поточні метрики: [показники] - Болючі точки: [проблеми] - Хто: [хто використовує] БАЖАНИЙ СТАН: - Що потрібно: [цільові можливості] - Цільові метрики: [показники] - Чому потрібно: [бізнес-обґрунтування] - Коли: [дедлайн] ОБМЕЖЕННЯ: - Бюджет: [ліміт] - Час: [термін] - Ресурси: [команда] - Технології: [що можна використовувати] Створи аналіз розривів: 1. ЗАГАЛЬНИЙ ОГЛЯД: Таблиця на високому рівні: | Область | Поточний стан | Бажаний стан | Розрив | Пріоритет | | [Область 1] | [що є] | [що треба] | [різниця] | [Високий/Середній/Низький] | 2. ДЕТАЛЬНИЙ АНАЛІЗ РОЗРИВІВ: Для кожної області: РОЗРИВ 1: [Назва] Поточна ситуація: - Що маємо: [детальний опис] - Метрики: [поточні цифри] - Чому недостатньо: [проблеми] Бажана ситуація: - Що потрібно: [детальний опис] - Цільові метрики: [цілі] - Чому це покращить: [вигоди] Розрив: - Що відсутнє: [конкретний список] - Вплив на бізнес: [як впливає зараз] - Терміновість: [чому важливо зараз] Оцінка: - Складність заповнення: [Низька/Середня/Висока] - Очікувана вигода: [Низька/Середня/Висока] - Пріоритет: [співвідношення вигоди до зусиль] 3. МАТРИЦЯ ПРІОРИТИЗАЦІЇ: Візуальна матриця (2×2): | Швидкі перемоги | Стратегічні | | (Низька складність, | (Висока складність, | | Висока вигода) | Висока вигода) | |-------------------|----------------| | Низький пріоритет | Розглянути пізніше | | (Низька складність, | (Висока складність, | | Низька вигода) | Низька вигода) | Розподіл розривів: - Швидкі перемоги: [Розрив 1, Розрив 3] - Стратегічні: [Розрив 2, Розрив 5] - Низький пріоритет: [Розрив 4] 4. РЕКОМЕНДОВАНІ ДІЇ: Фаза 1 (0-3 місяці): Швидкі перемоги 1. [Розрив] - дія: [що зробити], вигода: [результат] 2. [Розрив] - аналогічно Фаза 2 (3-6 місяців): Середня складність 1. [Розрив] - дія, вигода Фаза 3 (6-12 місяців): Стратегічні 1. [Розрив] - дія, вигода 5. ОЦІНКА ВПЛИВУ: | Розрив | Поточна вартість/втрата | Потенційна економія/вигода | Чиста вигода | Термін окупності | | [Розрив 1] | [$/міс] | [$/міс] | [$/рік] | [місяців] | 6. НЕОБХІДНІ РЕСУРСИ: Для заповнення всіх розривів: - Бюджет: [сума] - Час: [місяців] - Команда: [ролі та кількість] - Технології: [що потрібно] 7. РИЗИКИ: | Ризик | Імовірність | Вплив | Пом'якшення | | [Ризик незавершення] | [%] | [Високий/Середній/Низький] | [як зменшити] | 8. РЕКОМЕНДАЦІЯ: Запропонований підхід: - Почати з: [які розриви першими] - Чому: [обґрунтування] - Очікуваний результат: [що отримаємо] - Віддача від інвестицій: [розрахунок] Формат: аналітичний звіт з таблицями Візуалізація: матриця пріоритизації, графік впливу
💡 Як працює аналіз розривів:
Чому це критично:
- Розуміння відставання: де ми зараз проти де маємо бути
- Пріоритизація: що робити першим (найбільша віддача)
- Ресурси: скільки потрібно для заповнення розривів
- Обґрунтування: чому потрібні інвестиції
Результат: Аналіз розривів: 4 год → 40 хв. Чітка пріоритизація, розрахунок віддачі.
Кейс 3: Моделювання процесів за 1 годину
Проблема: Документування процесу — 3-4 години
Рішення з ChatGPT: Модель процесу за 1-1.5 години
Економія: 2.5 год × 10 процесів/міс = 25 годин/міс
Готовий промпт:
Створи модель бізнес-процесу для [назва процесу].
Контекст:
- Що робить процес: [мета]
- Хто залучений: [ролі]
- Як часто: [частота]
- Чому моделюємо: [навіщо документувати]
Вхідні дані про процес:
- Тригер (що запускає): [подія]
- Кроки (загалом): [перелік]
- Результат: [що отримуємо]
- Поточні проблеми: [що не так]
Створи модель процесу:
1. ЗАГАЛЬНА ІНФОРМАЦІЯ:
- Назва процесу: [повна назва]
- Власник процесу: [роль/відділ]
- Мета: [навіщо цей процес]
- Обсяг: [скільки разів виконується]
2. УЧАСНИКИ ПРОЦЕСУ:
| Роль | Відповідальність | Повноваження | Частота участі |
| [Роль 1] | [Що робить] | [Що може вирішувати] | [Завжди/Іноді/Рідко] |
3. ВХІДНІ ДАНІ (ВХОДИ):
Що потрібно для старту:
| Вхід | Джерело | Формат | Критерії якості |
| [Дані 1] | [Звідки беремо] | [У якому вигляді] | [Коли прийнятно] |
4. ВИХІДНІ ДАНІ (ВИХОДИ):
Що отримуємо:
| Вихід | Споживач | Формат | Критерії якості |
| [Результат 1] | [Хто використовує] | [У якому вигляді] | [Коли добре] |
5. ДЕТАЛЬНІ КРОКИ ПРОЦЕСУ:
Крок 1: [Назва кроку]
- Хто виконує: [Роль]
- Що робить: [детальний опис дій]
- Вхідні дані: [що потрібно]
- Вихідні дані: [що створюється]
- Інструменти: [які системи використовує]
- Час виконання: [типовий]
- Критерії завершення: [коли крок завершений]
- Точки рішення: [якщо є вибір - що вирішується]
Крок 2: [Назва кроку]
- [Аналогічна структура]
[... продовжити для всіх кроків]
6. ТОЧКИ РІШЕННЯ ТА РОЗГАЛУЖЕННЯ:
| Точка рішення | Умова | Якщо ТАК → | Якщо НІ → |
| [Рішення 1] | [Критерій] | [Крок X] | [Крок Y] |
7. ВИНЯТКИ ТА ОСОБЛИВІ ВИПАДКИ:
Що робити якщо:
- [Виняток 1]: [особливий сценарій] → [як обробляти]
- [Виняток 2]: аналогічно
8. СИСТЕМИ ТА ІНСТРУМЕНТИ:
| Система | Для чого використовується | Які дані | Хто має доступ |
| [Система 1] | [Призначення] | [Що зберігає/обробляє] | [Ролі] |
9. МЕТРИКИ ПРОЦЕСУ:
Ключові показники ефективності:
- Час циклу: [скільки займає від початку до кінця]
- Час обробки: [скільки фактично працюють]
- Час очікування: [скільки процес простоює]
- Відсоток помилок: [як часто щось йде не так]
- Вартість процесу: [$/на виконання]
Поточні значення:
| Метрика | Поточне | Ціль | Розрив |
10. ПРОБЛЕМИ ТА МОЖЛИВОСТІ ПОКРАЩЕННЯ:
Виявлені вузькі місця:
- [Проблема 1]: [опис] → вплив [час/вартість]
- [Проблема 2]: аналогічно
Можливості оптимізації:
- [Покращення 1]: [що змінити] → економія [час/вартість]
- [Покращення 2]: аналогічно
11. ВІЗУАЛІЗАЦІЯ ПРОЦЕСУ:
Опис для створення діаграми:
ПОЧАТОК → [Крок 1] → [Точка рішення 1?]
↓ ТАК ↓ НІ
[Крок 2a] ←→ [Крок 2b]
↓ ↓
[Об'єднання] → [Крок 3] → КІНЕЦЬ
Альтернативні види:
- Нотація: [доріжки для ролей]
- Позначення: [стандартні символи процесів]
12. РЕКОМЕНДАЦІЇ ПО ПОКРАЩЕННЮ:
Швидкі виграші:
1. [Що змінити] → економія [X год/міс]
2. [Що автоматизувати] → економія [Y год/міс]
Середньострокові:
1. [Що переробити] → покращення [метрика]
Довгострокові:
1. [Що замінити] → трансформація процесу
Формат: документація процесу з діаграмою
Нотація: BPMN або проста блок-схема
Деталізація: достатня для впровадження
💡 Як працює моделювання процесів:
Навіщо моделювати процеси:
- Розуміння: як насправді працює процес
- Документація: знання не зникає коли люди йдуть
- Оптимізація: бачимо де вузькі місця
- Автоматизація: зрозуміло що можна автоматизувати
- Навчання: нових співробітників легше ввести
Результат: Моделювання процесу: 4 год → 1.5 год. Чітка візуалізація, виявлені вузькі місця.
Кейс 4: Сценарії використання за 45 хвилин
Проблема: Написання сценаріїв — 2-3 години
Рішення з ChatGPT: Набір сценаріїв за 45 хвилин
Економія: 2 год × 15 наборів/проєкт = 30 годин/проєкт
Готовий промпт:
Створи сценарії використання для [функція/система]. Контекст: - Система: [що будуємо] - Користувачі: [ролі] - Функція: [що має робити] - Мета: [навіщо користувачу] Створи сценарії: 1. СПИСОК СЦЕНАРІЇВ: | № | Назва сценарію | Актор | Частота | Пріоритет | | 1 | [Базовий успішний сценарій] | [Роль] | [Щодня/Щотижня] | [Високий/Середній/Низький] | 2. ДЕТАЛЬНІ СЦЕНАРІЇ: СЦЕНАРІЙ 1: [Назва - дієслово + об'єкт, наприклад "Створити замовлення"] Базова інформація: - Актор: [хто виконує] - Мета: [чого хоче досягти] - Передумови: [що має бути виконано до] - Постумови (успіх): [що має статися після] - Частота: [як часто виконується] - Пріоритет: [наскільки критичний] Основний потік (успішний сценарій): 1. Актор [дія користувача] 2. Система [реакція системи] 3. Актор [наступна дія] 4. Система [реакція] [... продовжити всі кроки ...] Альтернативні потоки: A1: [Якщо щось інакше на кроці X] - Крок X: Якщо [умова] - Тоді: [що відбувається] - Продовжити з кроку: [номер] Потоки помилок: E1: [Помилка валідації] - Крок: [де відбувається] - Помилка: [що пішло не так] - Система: [як реагує] - Актор: [що може зробити] Критерії прийняття: ☐ Актор може [основна дія] ☐ Система [основна реакція] ☐ Помилки обробляються коректно ☐ Продуктивність: [вимоги] Бізнес-правила: - [Правило 1]: [опис] - [Правило 2]: [опис] 3. МАТРИЦЯ СЦЕНАРІЇВ ТА ВИМОГ: Зв'язок сценаріїв з вимогами: | Сценарій | Функціональна вимога 1 | Вимога 2 | Вимога 3 | | Сценарій 1 | ✓ | ✓ | - | | Сценарій 2 | ✓ | - | ✓ | Покриття вимог: [%] 4. ТЕСТОВІ СЦЕНАРІЇ: На основі сценаріїв використання: | Тест | Сценарій | Передумови | Кроки | Очікуваний результат | Формат: стандартна специфікація сценаріїв Деталізація: достатня для розробки та тестування
💡 Як працюють сценарії використання:
Структура якісного сценарію:
- Мета чітка: що користувач хоче досягти
- Кроки конкретні: що саме робить користувач і система
- Всі варіанти: основний потік + альтернативи + помилки
- Критерії прийняття: як перевіримо що працює
Результат: Сценарії використання: 3 год → 45 хв. Повне покриття функціональності.
Кейс 5: Аналіз стейкхолдерів за 30 хвилин
Проблема: Мапування стейкхолдерів — 2 години
Рішення з ChatGPT: Матриця стейкхолдерів за 30 хвилин
Економія: 1.5 год × 8 проєктів/рік = 12 годин
Готовий промпт:
Створи аналіз стейкхолдерів для [проєкт]. Інформація про проєкт: - Що робимо: [опис проєкту] - Які зміни: [що змінюється] - Хто зачеплений: [відділи/ролі] - Термін: [коли впроваджуємо] Відомі стейкхолдери: - [Ім'я/Роль]: [як залучений] - [Ім'я/Роль]: [як залучений] Створи аналіз: 1. ПОВНИЙ СПИСОК СТЕЙКХОЛДЕРІВ: | Стейкхолдер | Роль/Посада | Відділ | Як зачеплений проєктом | | [Ім'я] | [Посада] | [Відділ] | [Вплив проєкту на них] | 2. МАТРИЦЯ ВЛАДИ ТА ІНТЕРЕСУ: Класифікація по двом осям: - Влада (здатність вплинути на проєкт): Висока/Низька - Інтерес (наскільки зацікавлені): Високий/Низький Матриця 2×2: | УПРАВЛЯТИ ТІСНО | ТРИМАТИ ЗАДОВОЛЕНИМИ | | (Висока влада, | (Висока влада, | | Високий інтерес) | Низький інтерес) | |------------------|---------------------| | ІНФОРМУВАТИ | МОНІТОРИТИ | | (Низька влада, | (Низька влада, | | Високий інтерес) | Низький інтерес) | Розподіл стейкхолдерів: - Управляти тісно: [Стейкхолдер 1, 2] - Тримати задоволеними: [Стейкхолдер 3] - Інформувати: [Стейкхолдер 4, 5] - Моніторити: [Стейкхолдер 6] 3. ДЕТАЛЬНИЙ АНАЛІЗ КЛЮЧОВИХ СТЕЙКХОЛДЕРІВ: Для кожного з квадранта "Управляти тісно": СТЕЙКХОЛДЕР: [Ім'я, посада] Інтереси: - Що їх хвилює: [проблеми, цілі] - Що хочуть від проєкту: [очікування] - Критерії успіху для них: [як оцінюють] Впли на проєкт: - Рівень впливу: [може заблокувати/сповільнити/підтримати] - Ресурси під контролем: [бюджет/люди/рішення] Позиція щодо проєкту: - Поточна: [Підтримує/Нейтральний/Опирається] - Чому: [причини позиції] - Ризики: [що може піти не так] Стратегія взаємодії: - Як залучити: [підхід] - Частота комунікації: [як часто] - Формат: [зустрічі/емейли/звіти] - Що комунікувати: [які повідомлення] - Хто комунікує: [з нашої сторони] 4. ПЛАН КОМУНІКАЦІЇ: | Стейкхолдер | Що комунікувати | Як часто | Формат | Відповідальний | | [Ім'я] | [Які повідомлення] | [Частота] | [Канал] | [Хто з команди] | 5. АНАЛІЗ РИЗИКІВ СТЕЙКХОЛДЕРІВ: | Стейкхолдер | Ризик | Імовірність | Вплив | Пом'якшення | | [Ім'я] | [Може заблокувати] | [%] | [Високий/Середній] | [Як запобігти] | 6. СТРАТЕГІЇ ДЛЯ РІЗНИХ ГРУП: Прихильники (підтримують): - [Ім'я]: Використати як чемпіонів, залучити до промоції Нейтральні: - [Ім'я]: Показати вигоди конкретно для них Опоненти (опираються): - [Ім'я]: Зрозуміти причини, адресувати занепокоєння 7. ПЛАН ДІЙ: Фаза 1: До старту проєкту - [Дія зі стейкхолдером]: термін [дата] Фаза 2: Під час проєкту - Регулярні оновлення: [частота] Фаза 3: Після впровадження - Збір зворотного зв'язку: [коли та як] 8. МЕТРИКИ УСПІХУ УПРАВЛІННЯ СТЕЙКХОЛДЕРАМИ: Як вимірюємо: - Рівень задоволеності стейкхолдерів: [цільовий %] - Своєчасність схвалень: [терміни] - Кількість змін через стейкхолдерів: [менше ніж X] Формат: аналіз стейкхолдерів з матрицею та планом Візуалізація: матриця влада/інтерес
💡 Як працює аналіз стейкхолдерів:
Чому це критично:
- Підтримка: без стейкхолдерів проєкт провалиться
- Схвалення: розуміємо кого переконувати
- Ризики: хто може заблокувати
- Комунікація: кожному потрібне своє повідомлення
Результат: Аналіз стейкхолдерів: 2 год → 30 хв. Чітка стратегія комунікації.
Кейс 6: Аналіз даних для рішень за 1 годину
Проблема: Аналіз даних для рекомендацій — 4-5 годин
Рішення з ChatGPT: Структурований аналіз за 1-1.5 години
Економія: 3.5 год × 12 аналізів/міс = 42 години/міс
Готовий промпт:
Проаналізуй дані та дай рекомендації щодо [рішення]. Питання для рішення: - Що вирішуємо: [опис рішення] - Варіанти: [які розглядаємо] - Критерії: [що важливо] - Термін: [коли треба вирішити] Доступні дані: [вставити таблиці даних або опис] Створи аналіз: 1. РЕЗЮМЕ ДАНИХ: Що маємо: - Джерела: [звідки дані] - Період: [який проміжок] - Обсяг: [скільки записів] - Якість: [чи достатньо для висновків] 2. КЛЮЧОВІ ВИСНОВКИ З ДАНИХ: Топ-5 інсайтів: 1. [Інсайт]: [що показують дані] → [що це означає для бізнесу] 2. [Інсайт]: аналогічно Візуальне представлення: - [Тип графіка] для [показник] - Тренди: [що бачимо] 3. АНАЛІЗ ПО ВАРІАНТАХ РІШЕННЯ: ВАРІАНТ A: [Назва підходу] Дані на підтримку: - [Показник 1]: [значення] - що це означає - [Показник 2]: [значення] - інтерпретація Оцінка: - Очікуваний вплив: [кількісно] - Ймовірність успіху: [%] на основі [які дані] - Ризики: [що може не спрацювати] ВАРІАНТ B: [Інший підхід] - [Аналогічна структура] 4. ПОРІВНЯЛЬНА ТАБЛИЦЯ: | Критерій | Вага | Варіант A | Варіант B | Варіант C | | [Критерій 1] | [%] | [Оцінка 1-10] | [Оцінка] | [Оцінка] | | Віддача від інвестицій | 30% | 8 (висока) | 5 (середня) | 3 (низька) | | Ризик | 20% | 4 (високий) | 7 (низький) | 9 (мінімальний) | | Час впровадження | 15% | ... | ... | ... | Зважена оцінка: - Варіант A: [загальний бал] - Варіант B: [загальний бал] 5. ПРОГНОЗ РЕЗУЛЬТАТІВ: Якщо оберемо Варіант A: - Через 3 місяці: [очікуваний показник] - Через 6 місяців: [очікуваний показник] - Через рік: [очікуваний показник] На основі: - Історичні дані: [схожі випадки] - Тренди: [які спостерігаємо] - Припущення: [що передбачаємо] 6. АНАЛІЗ РИЗИКІВ: | Ризик | Імовірність (дані) | Вплив | Індикатор (як побачимо) | Дія якщо трапиться | | [Ризик 1] | [% на основі історії] | [Високий/Середній] | [Що відстежуємо] | [План Б] | 7. РЕКОМЕНДАЦІЯ: На основі даних рекомендую: [Варіант X] Обґрунтування: - Дані показують: [ключові факти] - Це означає: [інтерпретація] - Тому: [логіка рекомендації] Очікуваний результат: - [Метрика 1]: покращення на [%] - [Метрика 2]: зростання до [значення] - Віддача від інвестицій: [розрахунок] Ризики та як пом'якшуємо: - [Ризик]: [план мітигації] 8. ПЛАН МОНІТОРИНГУ: Після впровадження відстежувати: | Метрика | Частота вимірювання | Цільове значення | Тригер для коригування | | [Метрика] | [Щодня/Щотижня] | [Значення] | [Якщо падає нижче X] | 9. НАСТУПНІ КРОКИ: 1. [Дія] - відповідальний [хто], термін [коли] 2. [Дія] - аналогічно 3. Переглянути дані через [термін] Формат: аналітична записка з рекомендацією Візуалізація: графіки трендів, порівняльні діаграми Тон: базований на даних, об'єктивний
💡 Як працює аналіз даних:
Принципи якісного аналізу:
- Дані говорять: не припущення, а факти
- Контекст важливий: цифри самі по собі нічого не значать
- Прогноз обережний: краще консервативно і перевиконати
- Ризики враховані: що може піти не так
Результат: Аналіз даних: 5 год → 1.5 год. Базовані на фактах рекомендації.
Кейс 7: Технічне завдання за 2 години
Проблема: Написання специфікації — 6-8 годин
Рішення з ChatGPT: Детальна специфікація за 2-3 години
Економія: 5 год × 6 специфікацій/проєкт = 30 годин
Готовий промпт:
Створи технічне завдання для [функція/фіча].
Контекст:
- Що будуємо: [опис]
- Для кого: [користувачі]
- Навіщо: [бізнес-мета]
- Обмеження: [технічні/бюджетні]
Бізнес-вимоги:
- [Вимога 1]: [що потрібно досягти]
- [Вимога 2]: аналогічно
Створи технічне завдання:
1. ОГЛЯД:
- Назва: [повна назва фічі]
- Мета: [що має робити]
- Користувачі: [ролі]
- Пріоритет: [критичний/високий/середній]
2. ФУНКЦІОНАЛЬНА СПЕЦИФІКАЦІЯ:
Для кожної функції:
ФУНКЦІЯ: [Назва, наприклад "Пошук замовлень"]
Опис:
- Що робить: [детальний опис]
- Хто використовує: [ролі]
- Коли використовується: [контекст]
Вхідні дані:
- [Поле 1]: тип [текст/число], обов'язкове [так/ні], валідація [правила]
- [Поле 2]: аналогічно
Обробка:
- Крок 1: Система [що робить]
- Крок 2: Система [що робить]
Вихідні дані:
- [Що показується користувачу]
- Формат: [таблиця/список/деталі]
- Сортування/фільтрація: [можливості]
Бізнес-правила:
- [Правило 1]: [деталі]
- [Правило 2]: [деталі]
Валідація та помилки:
- [Помилка 1]: коли відбувається, що показати
- [Помилка 2]: аналогічно
Критерії прийняття:
☐ [Що має працювати]
☐ [Як має виглядати]
☐ [Як має себе поводити]
3. ДИЗАЙН КОРИСТУВАЦЬКОГО ІНТЕРФЕЙСУ:
Для кожного екрану:
ЕКРАН: [Назва екрану]
Елементи:
- [Елемент 1]: тип [кнопка/поле/таблиця], розташування, поведінка
- [Елемент 2]: аналогічно
Взаємодія:
- При натисканні [елемент]: [що відбувається]
- При зміні [поле]: [валідація/дія]
Навігація:
- Як потрапити на екран: [з чого]
- Як піти з екрану: [куди можна]
4. НЕФУНКЦІОНАЛЬНІ ВИМОГИ:
Продуктивність:
- Час відгуку: [макс секунд]
- Одночасних користувачів: [кількість]
- Обсяг даних: [записів]
Безпека:
- Аутентифікація: [метод]
- Авторизація: [ролі та права]
- Захист даних: [шифрування/маскування]
Доступність:
- Час роботи: [24/7 або години]
- Допустимий простій: [%]
Сумісність:
- Браузери: [які підтримувати]
- Пристрої: [комп'ютер/планшет/телефон]
- Інтеграції: [з якими системами]
5. ІНТЕГРАЦІЇ:
| Зовнішня система | Що інтегруємо | Метод | Дані | Частота |
| [Система 1] | [Мета інтеграції] | [API/файл/база] | [Які дані] | [Реальний час/щодня] |
6. ДАНІ ТА МОДЕЛЬ:
Сутності:
- [Сутність 1]: поля [список], зв'язки [з чим]
- [Сутність 2]: аналогічно
Міграція даних (якщо є):
- Звідки: [стара система]
- Що: [які дані]
- Трансформація: [як перетворюємо]
- Валідація: [як перевіряємо]
7. ТЕСТУВАННЯ:
Тестові сценарії:
| № | Сценарій | Передумови | Кроки | Очікуваний результат |
Тестові дані:
- [Набір 1]: [опис]
- Граничні випадки: [що тестуємо]
8. ВПРОВАДЖЕННЯ:
План розгортання:
- Підготовка: [що зробити до]
- Міграція: [якщо потрібна]
- Навчання: [хто, коли]
- Запуск: [стратегія - поступово/відразу]
- Відкат: [план Б якщо проблеми]
9. ДОКУМЕНТАЦІЯ:
Що потрібно:
- Технічна документація: [для розробників]
- Користувацька інструкція: [для кінцевих користувачів]
- Адміністраторська: [для підтримки]
10. ПІДТРИМКА:
Після запуску:
- Відповідальні: [хто]
- Канали звернення: [як користувачі звертаються]
- Час реагування: [SLA]
Формат: технічна специфікація
Деталізація: готова передати розробникам
Обсяг: залежить від складності
💡 Як працює технічне завдання:
Що робить специфікацію якісною:
- Деталізація: достатня щоб розробник зрозумів без запитань
- Критерії прийняття: як перевіримо що працює
- Усі випадки: основний сценарій + помилки + крайні випадки
- Нефункціональні вимоги: не тільки що робить, а й як швидко/безпечно
Результат: Технічне завдання: 7 год → 2.5 год. Повна деталізація, менше запитань від розробників.
Кейс 8: Звіт прогресу проєкту за 45 хвилин
Проблема: Підготовка статус-звіту — 2-3 години
Рішення з ChatGPT: Структурований звіт за 45 хвилин
Економія: 2 год × 4 звіти/міс = 8 годин/міс
Готовий промпт:
Створи звіт прогресу проєкту за [період].
Дані проєкту:
ЗАГАЛЬНЕ:
- Назва проєкту: [повна]
- Період звіту: [дати]
- Менеджер проєкту: [ім'я]
- Спонсор: [хто]
ПРОГРЕС:
- Завершено: [що зроблено]
- В процесі: [над чим працюємо]
- Заплановано: [що далі]
- Відхилення: [де відстаємо/випереджаємо]
МЕТРИКИ:
- Прогрес: [% завершення]
- Бюджет: [витрачено/залишок]
- Терміни: [за розкладом/затримка]
- Якість: [дефекти/проблеми]
ПРОБЛЕМИ:
- [Проблема 1]: [опис, вплив]
- [Проблема 2]: аналогічно
РИЗИКИ:
- [Ризик 1]: [опис, план]
Створи звіт:
1. ВИКОНАВЧЕ РЕЗЮМЕ:
Загальний статус: 🟢 За планом / 🟡 Під ризиком / 🔴 Проблеми
Ключові досягнення:
- [Досягнення 1]
- [Досягнення 2]
Критичні проблеми (якщо є):
- [Проблема]: [вплив, що робимо]
Що потрібно від стейкхолдерів:
- [Рішення/ресурс що треба]
2. ПРОГРЕС ПО ВІХАМ:
| Віха | Заплановано | Фактично | Статус | Коментар |
| [Віха 1] | [Дата] | [Дата] | ✅ Завершено / 🚧 В процесі | [Деталі] |
3. ДЕТАЛІ ВИКОНАНИХ ЗАВДАНЬ:
За період завершено:
- [Завдання 1]: [що зроблено, хто, коли]
- [Завдання 2]: аналогічно
Ключові результати:
- [Що працює]
- [Які вигоди вже бачимо]
4. ПОТОЧНІ РОБОТИ:
Зараз в процесі:
| Завдання | Відповідальний | Прогрес % | Очікуване завершення | Ризики |
| [Завдання] | [Ім'я] | [%] | [Дата] | [Якщо є] |
5. ПРОБЛЕМИ ТА РІШЕННЯ:
ПРОБЛЕМА: [Назва]
- Опис: [що не так]
- Вплив: [як це впливає на проєкт]
- Коли виявлено: [дата]
- Рішення: [що робимо]
- Відповідальний: [хто вирішує]
- Термін вирішення: [до коли]
- Статус: [Вирішено/В роботі/Ескальовано]
6. РИЗИКИ:
| Ризик | Імовірність | Вплив | Триггер | План пом'якшення | Відповідальний |
| [Ризик] | [%] | [Високий/Середній] | [Коли спрацює] | [Що робимо] | [Хто] |
7. БЮДЖЕТ ТА РЕСУРСИ:
Фінанси:
- Бюджет загальний: [сума]
- Витрачено: [сума] ([%])
- Залишок: [сума]
- Прогноз витрат: [чи вкладемося]
- Відхилення: [якщо є, чому]
Команда:
- Заплановано: [людино-годин]
- Фактично: [скільки витрачено]
- Завантаження: [чи достатньо ресурсів]
8. ЗМІНИ В ОБСЯЗІ:
Запити на зміни:
| Зміна | Запитувач | Вплив на термін | Вплив на бюджет | Статус | Рішення |
| [Зміна 1] | [Хто] | [+X днів] | [+Y грн] | [Схвалено/Відхилено] | [Коли/чому] |
9. НАСТУПНІ КРОКИ:
На наступний період:
- Заплановані роботи: [що робитимемо]
- Ключові віхи: [чого досягнемо]
- Потрібна підтримка: [що треба від стейкхолдерів]
10. ДОДАТКИ:
- Детальний план робіт
- Перелік завершених deliverables
- Метрики якості
Формат: статус-звіт проєкту
Аудиторія: стейкхолдери та керівництво
Тон: об'єктивний, прозорий
💡 Як працює звіт прогресу:
Принципи якісного звіту:
- Прозорість: показуйте і успіхи, і проблеми
- Статус чіткий: зелений/жовтий/червоний одразу зрозуміло
- Проблеми з планом: не тільки що не так, а й що робимо
- Запит конкретний: що потрібно від стейкхолдерів
Результат: Звіт прогресу: 2.5 год → 45 хв. Стейкхолдери завжди в курсі.
🚀 Бізнес-аналіз з ШІ
Навчіть бізнес-аналітиків працювати з ChatGPT та іншими ШІ-інструментами.
Результат курсу: аналітики економлять 12+ год/тиждень, більше фокусу на складних завданнях.
Висновки: Бізнес-аналіз + ШІ = Більше стратегії
Загальна економія часу з 8 кейсів:
- Документ бізнес-вимог: 4 год × 8/міс = 32 год/міс = 384 год/рік
- Аналіз розривів: 2.5 год × 6/міс = 15 год/міс = 180 год/рік
- Моделювання процесів: 2.5 год × 10/міс = 25 год/міс = 300 год/рік
- Сценарії використання: 2 год × 15/проєкт = 30 год/проєкт
- Аналіз стейкхолдерів: 1.5 год × 8/рік = 12 год/рік
- Аналіз даних: 3.5 год × 12/міс = 42 год/міс = 504 год/рік
- Технічне завдання: 5 год × 6/проєкт = 30 год/проєкт
- Звіт прогресу: 2 год × 4/міс = 8 год/міс = 96 год/рік
Загалом: 1,500+ годин/рік на бізнес-аналітика — це 9 місяців повної зайнятості що можна витратити на складний аналіз та стратегічні ініціативи.
Що робити далі:
- Почніть з документа вимог — найчастіше завдання
- Створіть бібліотеку шаблонів: для повторюваних типів аналізу
- Стандартизуйте формати: єдиний підхід в команді
- Навчіть команду: всі аналітики мають вміти з ШІ
- Автоматизуйте рутину: щоб був час на складне
💡 Поради для бізнес-аналітиків:
- ШІ не замінює аналітика: він підсилює вашу експертизу
- Ви додаєте контекст: ChatGPT дає структуру, ви — розуміння бізнесу
- Перевіряйте результат: ШІ може помилятися, ви експерт
- Ітеруйте: уточнюйте промпти, отримуйте кращий результат
🎯 Пам'ятайте: ChatGPT — це інструмент, який робить вас суперпродуктивним бізнес-аналітиком. Він бере на себе структурування та форматування, ви фокусуєтесь на аналізі та рішеннях.