> For the complete documentation index, see [llms.txt](https://kotovich.gitbook.io/ua/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kotovich.gitbook.io/ua/sistemnii-ai-strateg-dlya-biznesu/ai_target_framework.md-arsenal-ta-metodologiya.md).

# ai\_target\_framework.md (Арсенал та методологія)

## `kotovich_ai_target_framework.md` (Арсенал та методологія)

База знань та інструментарій агента TARGET / Ціль. Містить адаптовану методологію Теорії обмежень (ТОС), алгоритми пошуку вузьких місць та бібліотеку готових Markdown-шаблонів (Дерево поточної реальності, Хмара конфлікту, Паспорт цілі тощо). Агент спирається на цей документ, щоб генерувати глибокі аналітичні звіти, а не загальні поради.

* **Для чого використовується:** завантажується в *Knowledge Base* (Базу знань) або підключається як контекстний файл (RAG), щоб агент міг «підглядати» в правильні структури під час роботи.

#### Метадані документа

| Параметр                                                                        | Значення                                                                                                                                                                     |
| ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Назва файлу                                                                     | `kotovich_ai_target_framework.md`                                                                                                                                            |
| Назва файлу з ідентичністю та поведінкою агента, для якого написано цей арсенал | `kotovich_ai_target_core.md`                                                                                                                                                 |
| Призначення                                                                     | Методологічна база, алгоритми, навички та шаблони вихідних документів для AI-агента TARGET / Ціль                                                                            |
| Методологічна база                                                              | Теорія обмежень, управлінські Thinking Processes, системне вдосконалення, причинно-наслідковий аналіз, операційний потік, стратегія та тактика                               |
| Джерела натхнення                                                               | «The Goal / Ціль. Процес безперервного вдосконалення»; «Goal 2 / Ціль-2. Справа не у везінні» Еліягу М. Ґолдратта; загальнодоступна практика ТОС без відтворення тексту книг |
| Цільова аудиторія                                                               | Українські підприємці, власники, CEO/COO/CFO/CMO/CPO, керівники функцій та проєктні команди                                                                                  |
| Мова                                                                            | Українська                                                                                                                                                                   |
| Версія                                                                          | v2.0                                                                                                                                                                         |
| Дата                                                                            | 2026-08-03                                                                                                                                                                   |
| Автор                                                                           | **Kotovich AI** (kotovich.uk)                                                                                                                                                |

***

#### 1. Призначення навичок

Цей файл задає практичний інструментарій агента TARGET / Ціль. Він працює в парі з `kotovich_ai_target_core.md`, який задає ідентичність і логіку поведінки.

Агент використовує цей арсенал, щоб:

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

***

#### 2. Карта методологічних доменів

| Домен                     | Що вирішує                                               | Основні інструменти                                           |
| ------------------------- | -------------------------------------------------------- | ------------------------------------------------------------- |
| Ціль системи              | Визначає, заради чого існує бізнес / функція / процес    | Goal Charter, Goal Tree, Success Criteria                     |
| Метрики результату        | Пов'язує дії з економічним результатом                   | Throughput, Inventory/Investment, Operating Expense, KPI Tree |
| Обмеження системи         | Шукає головний фактор, що обмежує результат              | Five Focusing Steps, Constraint Map, Bottleneck Scan          |
| Поточна реальність        | Упорядковує симптоми та причини                          | Current Reality Tree, UDE List                                |
| Конфлікт                  | Розв'язує дилеми та глухі кути                           | Evaporating Cloud, Assumption Audit                           |
| Майбутня реальність       | Проєктує бажаний стан                                    | Future Reality Tree, Injections, Negative Branch Reservation  |
| Перехід                   | Будує шлях впровадження                                  | Prerequisite Tree, Transition Tree, Change Plan               |
| Операційний потік         | Вдосконалює потік робіт, замовлень, постачань, проєктів  | Drum-Buffer-Rope, Buffer Management, WIP Control              |
| Стратегія та ринок        | Пов'язує цінність, ринок, продажі та обмеження зростання | Strategy & Tactics Tree, Market Constraint Map, Offer Logic   |
| Безперервне вдосконалення | Робить вдосконалення регулярним процесом                 | CI Backlog, Weekly Review, Improvement Loop                   |

***

#### 3. Базові поняття агента

**3.1. Головна ціль системи**

**Головна ціль** — вимірюваний результат, заради якого існує система.

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

Перевірочні запитання:

1. Що система повинна виробляти як кінцевий цінний результат?
2. Хто є клієнтом результату?
3. Як виміряти, що система стала ближчою до цілі?
4. Які показники можуть поліпшуватися локально, але шкодити загальній цілі?
5. Які рішення зараз приймаються без зв'язку з головною ціллю?

***

**3.2. Три глобальні метрики**

Агент використовує три управлінські категорії як основу системного аналізу:

| Метрика                                    | Сенс                                                                                       | Управлінське запитання                                       |
| ------------------------------------------ | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------ |
| Throughput / Пропускна здатність           | Швидкість, з якою система генерує корисний результат через продажі / цінність / постачання | Що збільшує потік результату?                                |
| Inventory / Investment / Пов'язані ресурси | Гроші, час, запаси, незавершене виробництво, потужності та активи, пов'язані в системі     | Що зв'язує капітал і сповільнює потік?                       |
| Operating Expense / Операційні витрати     | Витрати, потрібні для перетворення ресурсів на результат                                   | Які витрати потрібні, а які лише підтримують неефективність? |

Правило агента:

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

***

**3.3. Обмеження**

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

Типи обмежень:

| Тип обмеження            | Приклади                                                                           |
| ------------------------ | ---------------------------------------------------------------------------------- |
| Ринкове                  | Недостатній попит, слабке позиціонування, неочевидна цінність для клієнта          |
| Операційне               | Вузьке місце у виробництві, delivery, погодженнях, обробці заявок                  |
| Ресурсне                 | Дефіцит людей, компетенцій, бюджету, потужностей, даних                            |
| Політичне / управлінське | Правила, KPI, процедури, культура, які блокують потік                              |
| Продуктове               | Продукт не розв'язує ключову задачу клієнта, слабкий UX, поганий value proposition |
| Продажне                 | Довгий цикл угоди, незрозумілий ICP, слабкий офер, немає довіри                    |
| Фінансове                | Unit economics не сходиться, маржа низька, cash gap                                |
| Інформаційне             | Немає даних для прийняття рішень, слабка аналітика, запізнілі звіти                |

***

#### 4. Five Focusing Steps / П'ять фокусувальних кроків

Це головний алгоритм усунення обмеження.

| Крок | Дія         | Що робить агент                                                             |
| ---- | ----------- | --------------------------------------------------------------------------- |
| 1    | Identify    | Визначає головне обмеження системи                                          |
| 2    | Exploit     | Знаходить, як максимально використати обмеження без великих інвестицій      |
| 3    | Subordinate | Підпорядковує решту процесів обмеженню, щоб не створювати зайвий WIP та шум |
| 4    | Elevate     | Пропонує підсилення обмеження: ресурси, автоматизація, найм, зміна процесу  |
| 5    | Repeat      | Після зняття обмеження шукає наступне та запобігає інерції                  |

**Шаблон застосування**

```markdown
## Five Focusing Steps

### 1. Identify — головне обмеження
- Гіпотеза обмеження:
- Докази:
- Симптоми:
- Що потрібно перевірити:

### 2. Exploit — як використати обмеження краще зараз
- Швидкі дії без інвестицій:
- Що прибрати з навантаження обмеження:
- Що дати обмеженню в пріоритеті:

### 3. Subordinate — що підпорядкувати обмеженню
- Які процеси повинні змінити правила:
- Які KPI заважають:
- Що перестати робити:

### 4. Elevate — як підсилити обмеження
- Варіант 1:
- Варіант 2:
- Вартість / складність:
- Очікуваний ефект:

### 5. Repeat — наступний цикл
- Як зрозуміти, що обмеження знято:
- Де може з'явитися нове обмеження:
- Як уникнути інерції:
```

***

#### 5. Current Reality Tree / Дерево поточної реальності

**5.1. Призначення**

Current Reality Tree допомагає перевести хаос симптомів у причинно-наслідкову карту.

Використовувати, коли:

* багато проблем і незрозуміло, з чого починати;
* керівники сперечаються про причини;
* видно повторювані симптоми;
* є підозра, що лікують наслідки, а не причину.

**5.2. Алгоритм побудови**

1. Зібрати список небажаних явищ — UDE.
2. Прибрати дублі та емоційні формулювання.
3. Сформулювати кожне UDE як спостережуване явище.
4. Знайти зв'язки «якщо → то».
5. Побудувати ланцюжки причин.
6. Знайти 1–3 кореневі причини.
7. Перевірити, чи пояснюють вони більшість UDE.
8. Сформулювати гіпотезу обмеження.

**5.3. Шаблон документа**

```markdown
# Current Reality Tree / Дерево поточної реальності

## 1. Контекст системи
- Система:
- Головна ціль:
- Межа аналізу:
- Горизонт:

## 2. Список UDE / небажаних явищ
| № | Небажане явище | Джерело даних | Частота / масштаб | Вплив на ціль |
|---|---|---|---|---|

## 3. Причинно-наслідкові зв'язки
| Причина | Наслідок | Логіка зв'язку | Впевненість |
|---|---|---|---|

## 4. Кореневі причини
| № | Коренева причина | Які UDE пояснює | Перевірка |
|---|---|---|---|

## 5. Гіпотеза головного обмеження

## 6. Що перевірити даними

## 7. Управлінський висновок
```

***

#### 6. Evaporating Cloud / Діаграма розв'язання конфлікту

**6.1. Призначення**

Evaporating Cloud використовується для управлінських дилем, де сторони вважають, що вибір можливий лише між двома конфліктуючими діями.

Приклади:

* знижувати ціни чи зберігати маржу;
* прискорювати delivery чи зберігати якість;
* навантажувати команду сильніше чи знижувати WIP;
* інвестувати у зростання чи економити cash;
* стандартизувати процеси чи зберігати гнучкість.

**6.2. Структура**

```markdown
# Evaporating Cloud / Розв'язання управлінського конфлікту

## 1. Спільна ціль
[Що обидві сторони насправді хочуть забезпечити]

## 2. Потреба A
[Чому сторона A хоче свою дію]

## 3. Потреба B
[Чому сторона B хоче протилежну дію]

## 4. Дія A
[Що пропонує сторона A]

## 5. Дія B
[Що пропонує сторона B]

## 6. Конфлікт
A і B здаються взаємовиключними, тому що...

## 7. Приховані припущення
| Зв'язок | Припущення | Як перевірити | Чи можна оскаржити? |
|---|---|---|---|

## 8. Ін'єкція / рішення без компромісу
[Нове рішення, яке задовольняє обидві потреби]

## 9. Ризики рішення

## 10. Перший тестовий крок
```

***

#### 7. Future Reality Tree / Дерево майбутньої реальності

**7.1. Призначення**

Future Reality Tree показує, як запропоновані зміни повинні призвести до бажаних ефектів.

Використовувати, коли:

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

**7.2. Шаблон**

```markdown
# Future Reality Tree / Дерево майбутньої реальності

## 1. Цільова реальність

## 2. Головні бажані ефекти
| № | Desired Effect | Як виміряти | Зв'язок із ціллю |
|---|---|---|---|

## 3. Ін'єкції / зміни
| № | Ін'єкція | Яку причину усуває | Очікуваний ефект |
|---|---|---|---|

## 4. Причинно-наслідкова логіка
| Якщо впровадити | То відбудеться | Тому що | Впевненість |
|---|---|---|---|

## 5. Вразливі місця логіки

## 6. Необхідні перевірки

## 7. Підсумковий висновок
```

***

#### 8. Negative Branch Reservation / Перевірка негативних гілок

**8.1. Призначення**

Negative Branch Reservation потрібна, щоб заздалегідь знайти небажані наслідки гарного на вигляд рішення.

**8.2. Шаблон**

```markdown
# Negative Branch Reservation

| № | Планована дія | Можливий негативний ефект | Чому може виникнути | Ранній індикатор | Мітигація |
|---|---|---|---|---|---|

## Критичні негативні гілки

## Що потрібно змінити у рішенні

## Рішення після коригування
```

***

#### 9. Prerequisite Tree / Дерево необхідних умов

**9.1. Призначення**

Prerequisite Tree допомагає побудувати карту перешкод і необхідних умов для досягнення цілі.

**9.2. Шаблон**

```markdown
# Prerequisite Tree / Дерево необхідних умов

## 1. Амбітна ціль

## 2. Перешкоди
| № | Перешкода | Чому заважає | Критичність |
|---|---|---|---|

## 3. Необхідні умови
| Перешкода | Необхідна умова | Як перевірити готовність |
|---|---|---|

## 4. Послідовність умов

## 5. Мінімальний шлях до цілі
```

***

#### 10. Transition Tree / Дерево переходу

**10.1. Призначення**

Transition Tree переводить стратегію в послідовність дій.

**10.2. Шаблон**

```markdown
# Transition Tree / План переходу

| Крок | Поточний стан | Дія | Чому ця дія потрібна | Очікуваний проміжний результат | Відповідальний | Термін |
|---|---|---|---|---|---|---|

## Критична послідовність

## Контрольні точки

## Метрики прогресу

## Ризики впровадження
```

***

#### 11. Strategy & Tactics Tree / Дерево стратегії та тактики

**11.1. Призначення**

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

**11.2. Шаблон**

```markdown
# Strategy & Tactics Tree

| Рівень | Стратегія / що має бути досягнуто | Тактика / як досягнути | Передумова | Метрика | Ризик |
|---|---|---|---|---|---|

## Головна стратегічна логіка

## Критичні передумови

## Що має бути доведено даними

## Управлінські рішення
```

***

#### 12. Drum-Buffer-Rope / Управління потоком

**12.1. Призначення**

DBR застосовується для систем, де результат обмежений потоком через bottleneck.

Приклади:

* виробництво;
* fulfillment;
* розробка продукту;
* обробка заявок;
* підготовка комерційних пропозицій;
* погодження договорів;
* маркетинговий production;
* проєктний delivery.

**12.2. Поняття**

| Елемент | Сенс                                                           |
| ------- | -------------------------------------------------------------- |
| Drum    | Ритм роботи, що задається обмеженням                           |
| Buffer  | Захисний буфер перед обмеженням або перед клієнтським терміном |
| Rope    | Механізм запуску роботи в систему лише в потрібному темпі      |

**12.3. Шаблон**

```markdown
# DBR Improvement Plan

## 1. Потік робіт

## 2. Обмеження потоку

## 3. Drum / ритм обмеження
- Потужність обмеження:
- Що має потрапляти в обмеження:
- Що не має потрапляти:

## 4. Buffer / захист
- Де потрібен буфер:
- Розмір буфера:
- Правила управління буфером:

## 5. Rope / запуск робіт
- Коли запускати нову роботу:
- Які правила WIP:
- Хто контролює вхід:

## 6. Зміни процесу

## 7. Метрики

## 8. Очікуваний ефект
```

***

#### 13. Continuous Improvement Loop / Цикл безперервного вдосконалення

**13.1. Алгоритм**

1. Зафіксувати головну ціль.
2. Виміряти поточний результат.
3. Знайти обмеження.
4. Запустити мінімальне вдосконалення на обмеженні.
5. Перевірити ефект.
6. Підпорядкувати суміжні процеси.
7. Підсилити обмеження за потреби.
8. Зафіксувати новий стандарт.
9. Знайти наступне обмеження.
10. Повторити цикл.

**13.2. Шаблон щотижневого управління**

```markdown
# Weekly Constraint Review

## 1. Головна ціль періоду

## 2. Поточний результат
| Метрика | План | Факт | Відхилення | Коментар |
|---|---|---|---|---|

## 3. Поточне обмеження

## 4. Що зробили на обмеженні

## 5. Ефект

## 6. Нові симптоми

## 7. Рішення на наступний тиждень

## 8. Відповідальні

## 9. Ризики
```

***

#### 14. Діагностичні алгоритми агента

**14.1. Швидка діагностика цілі**

```markdown
1. Що є головною ціллю системи?
2. Хто отримує кінцеву цінність?
3. Як вимірюється досягнення цілі?
4. Які поточні KPI можуть вести вбік від цілі?
5. Який результат має змінитися за 30/60/90 днів?
```

**14.2. Швидка діагностика обмеження**

```markdown
1. Де найчастіше виникає черга, очікування або зависання?
2. Який ресурс завжди перевантажений?
3. Яке рішення найчастіше потребує ручного погодження?
4. Що заважає збільшити потік результату прямо зараз?
5. Що відбувається, якщо додати більше задач у систему?
6. Який показник не зростає, попри активність команди?
7. Що клієнти або внутрішні замовники найчастіше чекають?
```

**14.3. Перевірка: симптом чи обмеження**

| Перевірочне запитання                               | Якщо відповідь «так»             |
| --------------------------------------------------- | -------------------------------- |
| Усунення фактора збільшить результат усієї системи? | Це кандидат на обмеження         |
| Фактор лише дратує, але не впливає на throughput?   | Це симптом або локальна проблема |
| Фактор створює чергу перед собою?                   | Імовірно bottleneck              |
| Фактор пов'язаний із політикою, KPI або правилом?   | Можливо управлінське обмеження   |
| Фактор проявляється в різних місцях системи?        | Можливо коренева причина         |

***

#### 15. Каталог вихідних документів агента

| №  | Документ                       | Призначення                                             | Коли використовувати                    |
| -- | ------------------------------ | ------------------------------------------------------- | --------------------------------------- |
| 1  | Goal Charter                   | Зафіксувати головну ціль, межі системи, критерії успіху | На початку будь-якої роботи             |
| 2  | System Boundary Map            | Визначити межі аналізованої системи                     | При складних задачах                    |
| 3  | Constraint Diagnostic Report   | Знайти обмеження та докази                              | При стагнації результату                |
| 4  | UDE List                       | Зібрати небажані явища                                  | При хаосі симптомів                     |
| 5  | Current Reality Tree           | Знайти кореневі причини                                 | При множинних проблемах                 |
| 6  | Evaporating Cloud              | Розв'язати управлінський конфлікт                       | При дилемах                             |
| 7  | Assumption Audit               | Перевірити приховані припущення                         | При спірних рішеннях                    |
| 8  | Future Reality Tree            | Спроєктувати бажаний стан                               | При розробці рішення                    |
| 9  | Negative Branch Reservation    | Знайти побічні ефекти                                   | Перед впровадженням ініціативи          |
| 10 | Prerequisite Tree              | Визначити необхідні умови                               | Перед запуском трансформації            |
| 11 | Transition Tree                | Розкласти перехід на дії                                | Для впровадження                        |
| 12 | Strategy & Tactics Tree        | Зв'язати стратегію та тактику                           | Для стратегічних ініціатив              |
| 13 | DBR Improvement Plan           | Вдосконалити операційний потік                          | Для bottleneck / delivery / виробництва |
| 14 | Buffer Management Dashboard    | Управляти буферами                                      | Для потокових систем                    |
| 15 | Throughput Metrics Dashboard   | Зв'язати метрики з результатом                          | Для управлінського контролю             |
| 16 | Continuous Improvement Backlog | Вести чергу вдосконалень                                | Для регулярної роботи                   |
| 17 | 30/60/90 Improvement Plan      | Запустити зміни поетапно                                | Для впровадження                        |
| 18 | Executive Decision Memo        | Підготувати рішення для власника / топ-команди          | Для нарад                               |
| 19 | Risk & Mitigation Map          | Перевірити ризики                                       | Для передфінального QA                  |
| 20 | Weekly Constraint Review       | Вести регулярний цикл вдосконалень                      | Для операційного управління             |

***

#### 16. Шаблон Goal Charter

```markdown
# Goal Charter / Паспорт цілі

## 1. Назва цілі

## 2. Система
- Компанія / підрозділ / процес:
- Межі системи:
- Власник цілі:

## 3. Формулювання головної цілі

## 4. Чому ця ціль важлива

## 5. Критерії успіху
| Метрика | Поточне значення | Цільове значення | Горизонт | Джерело даних |
|---|---|---|---|---|

## 6. Що НЕ є ціллю

## 7. Обмеження та умови

## 8. Основні стейкхолдери

## 9. Головні ризики

## 10. Наступний крок діагностики
```

***

#### 17. Шаблон Constraint Diagnostic Report

```markdown
# Constraint Diagnostic Report / Діагностика обмеження

## 1. Executive Summary

## 2. Головна ціль системи

## 3. Симптоми недосягнення цілі
| Симптом | Де проявляється | Частота | Вплив |
|---|---|---|---|

## 4. Кандидати на обмеження
| Кандидат | Тип обмеження | Докази | Контраргументи | Впевненість |
|---|---|---|---|---|

## 5. Головне обмеження / гіпотеза

## 6. Чому саме воно обмежує результат

## 7. Five Focusing Steps

## 8. Швидкі дії на 7–14 днів

## 9. Рішення на 30–90 днів

## 10. Метрики контролю

## 11. Ризики помилки діагностики

## 12. Що потрібно перевірити даними
```

***

#### 18. Шаблон Executive Decision Memo

```markdown
# Executive Decision Memo

## 1. Рішення, яке потрібно прийняти

## 2. Контекст

## 3. Головна ціль

## 4. Головне обмеження

## 5. Варіанти рішення
| Варіант | Суть | Плюси | Мінуси | Вплив на ціль | Ризики |
|---|---|---|---|---|---|

## 6. Рекомендований варіант

## 7. Чому не інші варіанти

## 8. Побічні ефекти та мітигації

## 9. План впровадження

## 10. Метрики успіху

## 11. Рішення для затвердження
```

***

#### 19. Шаблон 30/60/90 Improvement Plan

```markdown
# 30/60/90 Improvement Plan

## 1. Ціль плану

## 2. Головне обмеження

## 3. Етап 0–30 днів
| Дія | Ціль | Відповідальний | Результат | Метрика |
|---|---|---|---|---|

## 4. Етап 31–60 днів
| Дія | Ціль | Відповідальний | Результат | Метрика |
|---|---|---|---|---|

## 5. Етап 61–90 днів
| Дія | Ціль | Відповідальний | Результат | Метрика |
|---|---|---|---|---|

## 6. Ризики

## 7. Контрольні точки

## 8. Що вважатиметься успіхом
```

***

#### 20. Пріоритизація ініціатив

Агент оцінює ініціативи не за привабливістю, а за впливом на обмеження та головну ціль.

| Критерій                | Запитання                                                        | Бал 1–5 |
| ----------------------- | ---------------------------------------------------------------- | ------- |
| Вплив на обмеження      | Наскільки ініціатива розвантажує або підсилює головне обмеження? |         |
| Вплив на Throughput     | Чи збільшує потік результату?                                    |         |
| Швидкість перевірки     | Чи можна швидко перевірити ефект?                                |         |
| Складність впровадження | Наскільки складно впровадити?                                    |         |
| Ризик побічних ефектів  | Чи може погіршити іншу частину системи?                          |         |
| Потреба в інвестиціях   | Чи потрібні суттєві ресурси?                                     |         |

Рекомендована формула для управлінського ранжування:

```markdown
Priority Score = (Constraint Impact + Throughput Impact + Speed of Validation) - (Implementation Complexity + Side Effect Risk + Investment Load)
```

***

#### 21. QA-чекліст агента

Перед видачею фінального результату перевір:

| №  | Перевірка                            | Так/Ні |
| -- | ------------------------------------ | ------ |
| 1  | Головна ціль явно сформульована      |        |
| 2  | Ціль не підмінена засобом            |        |
| 3  | Обмеження відокремлене від симптомів |        |
| 4  | Є причинно-наслідкова логіка         |        |
| 5  | Пропозиції пов'язані з обмеженням    |        |
| 6  | Є перевірка побічних ефектів         |        |
| 7  | Зазначені припущення                 |        |
| 8  | Є конкретний план дій                |        |
| 9  | Є метрики контролю                   |        |
| 10 | Є next steps                         |        |

***

#### 22. Міні-скрипти запитань для користувача

**22.1. Якщо користувач прийшов із загальною ціллю**

```markdown
Щоб не піти в загальні поради, уточню 5 речей:

1. Яку ціль потрібно досягнути і в який термін?
2. У якій системі шукаємо обмеження: бізнес, продукт, продажі, виробництво, команда, процес?
3. Що зараз не виходить у вимірюваних термінах?
4. Які 3–5 симптомів ви бачите найчастіше?
5. Які рішення вже пробували і чому вони не дали потрібного ефекту?
```

**22.2. Якщо користувач прийшов із конфліктом**

```markdown
Уточню конфлікт:

1. Які два рішення зараз конфліктують?
2. Яку спільну ціль обидві сторони хочуть захистити?
3. Чому кожна сторона вважає свій варіант необхідним?
4. Що поганого станеться, якщо обрати варіант A?
5. Що поганого станеться, якщо обрати варіант B?
```

**22.3. Якщо користувач хоче план вдосконалень**

```markdown
Для плану вдосконалень потрібні мінімальні ввідні:

1. Яка головна бізнес-метрика має змінитися?
2. Де зараз виникає основне очікування, черга або перевантаження?
3. Хто власник процесу?
4. Які ресурси можна змінювати, а які поки зафіксовані?
5. На який горизонт будуємо план: 30, 60 чи 90 днів?
```

***

#### 23. Типові помилки, яких агент має запобігати

| Помилка                                  | Як запобігати                             |
| ---------------------------------------- | ----------------------------------------- |
| Вдосконалювати все підряд                | Завжди повертатися до головного обмеження |
| Плутати активність із результатом        | Перевіряти зв'язок із Throughput / ціллю  |
| Лікувати симптоми                        | Будувати Current Reality Tree             |
| Приймати компроміс як рішення            | Використовувати Evaporating Cloud         |
| Ігнорувати побічні ефекти                | Робити Negative Branch Reservation        |
| Будувати план без умов                   | Використовувати Prerequisite Tree         |
| Давати стратегію без тактики             | Використовувати Strategy & Tactics Tree   |
| Перевантажувати систему задачами         | Використовувати WIP / DBR-логіку          |
| Давати рекомендації без перевірки даними | Маркувати припущення та список перевірок  |

***

#### 24. Стандарт фінальної упаковки відповіді

Якщо користувач не вказав інший формат, агент видає:

```markdown
# [Назва розбору]

## 1. Executive Summary

## 2. Головна ціль

## 3. Поточна реальність

## 4. Головне обмеження / гіпотеза обмеження

## 5. Причинно-наслідкова логіка

## 6. Конфлікт / приховані припущення, якщо є

## 7. Майбутня реальність

## 8. План переходу

## 9. Метрики контролю

## 10. Ризики та мітигації

## 11. Next Steps
```

***

#### 25. Головний операційний принцип навичок

> Не пропонуй користувачу «більше працювати». Знайди, що обмежує результат системи, і допоможи змінити саме це.

<p align="right"><em>Автор:</em> <a href="https://kotovich.uk/"><em>Kotovich</em></a></p>