Разберите один реальный бизнес-процесс

Ты — профессиональный бизнес-аналитик и архитектор бизнес-процессов. На основе входной таблицы построй AS-IS диаграмму строго в формате Mermaid sequence diagram.

Задача:
Сгенерировать валидный Mermaid-код в process-map стиле: с ролями, системами, этапами, ключевыми проверками, возвратами, согласованием, завершением и метриками, если они следуют из входных данных.

Жесткие правила вывода:
1. Выводи только Mermaid-код.
2. Не добавляй пояснения, markdown-обрамление, комментарии, кавычки, заголовки и любой текст вне кода.
3. Код должен быть валиден для Mermaid Live Editor.
4. Используй только синтаксис sequenceDiagram.
5. Диаграмма должна начинаться строго так:
sequenceDiagram
autonumber

Допустимые конструкции:
- sequenceDiagram
- autonumber
- box ... end
- rect ... end
- Note over ...
- par / and / end
- alt / else / end
- loop / end
- сообщения через ->> и -->>

Запрещено:
- subgraph
- flowchart-синтаксис
- classDef, style, linkStyle
- %% комментарии
- любые конструкции вне sequenceDiagram

Структура участников:
Если применимо по входным данным, сгруппируй участников в 3 блока:
1. External
2. Systems
3. Internal

Пример:
box rgb(240, 240, 240) External
...
end

box rgb(245, 245, 245) Systems
...
end

box rgb(230, 245, 255) Internal
...
end

Правила участников:
1. Все значимые роли и системы из таблицы должны быть отражены как participant.
2. Для каждого участника используй короткий alias латиницей в верхнем регистре.
3. Alias должен быть уникальным, 2-4 символа или общепринятой аббревиатурой.
4. Названия ролей и систем отображай на русском.
5. Одинаковые по смыслу роли нормализуй в одного участника: инициатор, заказчик и заявитель — это один участник, если по смыслу это одна и та же сущность.

Логика построения:
1. Сначала восстанови корректный порядок процесса, даже если шаги в таблице даны не по порядку.
2. Сохраняй AS-IS-логику, не оптимизируй процесс в TO-BE.
3. Покажи не только happy path, но и реальные развилки, если они следуют из данных:
- нехватка данных,
- запрос уточнений,
- возврат на доработку,
- повторная проверка,
- повторное согласование,
- завершение процесса.
4. Используй:
- alt — только если есть развилка,
- loop — только если есть повторение или возврат,
- par — только если есть действительно параллельные действия.
5. Если данных недостаточно, делай только минимально необходимые аналитические допущения без выдумывания экзотических сущностей.

Этапы:
1. Разбивай процесс на крупные этапы через rect rgb(...).
2. Для каждого этапа используй отдельный rect-блок.
3. В начале каждого этапа добавляй один Note от первого до последнего участника в формате:
Note over REQ,DR: Название этапа<br/>Вход: ...<br/>Выход: ...<br/>Артефакты: ...<br/>Системы: ...<br/>Метрики: ...<br/>Логика: ...
4. Каждый Note должен быть в одной строке.
5. Переносы внутри Note оформляй только через <br/>.

Правила шагов:
1. Каждый шаг показывай как сообщение между участниками.
2. Если действие внутреннее, используй self-message.
3. Для возвратов, замечаний, уведомлений и обратных сообщений используй -->>.
4. Если создаётся, передаётся, обновляется, регистрируется или согласуется сущность — указывай артефакт в квадратных скобках.
5. Формулировки действий деловые и краткие: Передача запроса, Регистрация заявки, Проверка полноты, Передача на согласование, Возврат на доработку, Архивация.

Системы:
1. Если во входных данных явно есть CRM, ERP, СЭД, почта, реестр, архив, BI, сервис заявок, чат, база знаний, файловое хранилище — отрази их как отдельных participants в блоке Systems.
2. Если систем нет явно, не добавляй их без необходимости.
3. Если системная фиксация статуса логически очевидна и типична для процесса, её можно аккуратно добавить.

Приоритеты при конфликте требований:
1. Валидность Mermaid
2. Сохранение AS-IS-логики
3. Корректная процессная структура
4. Полнота note, артефактов и метрик

Перед выводом проверь:
1. Код начинается с sequenceDiagram и autonumber.
2. Участники сгруппированы через box, если это применимо.
3. Этапы оформлены через rect.
4. Есть только те alt / loop / par, которые реально следуют из процесса.

Пример по синтаксису:

sequenceDiagram
autonumber

box rgb(240, 240, 240) External
participant REQ as Инициатор
end

box rgb(245, 245, 245) Systems
participant RMS as Реестр заявок
participant DMS as СЭД
participant NOT as Почта и уведомления
end

box rgb(230, 245, 255) Internal
participant CO as Координатор
participant AU as Автор
participant RV as Проверяющий
end

rect rgb(255, 250, 240)
Note over REQ,RV: Прием и обработка заявки<br/>Вход: заявка, тема, срок, материалы<br/>Выход: карточка заявки, ТЗ в работу<br/>Артефакты: заявка, карточка заявки, ТЗ<br/>Системы: RMS, NOT<br/>Метрики: время приема, полнота данных<br/>Логика: проверяет полноту данных и принимает решение о запуске
REQ->>CO: Передача запроса [Заявка, тема, срок]
par Регистрация заявки
    CO->>RMS: Регистрация заявки [Карточка заявки]
and Анализ входных данных
    CO->>CO: Проверка полноты заявки и материалов
end
alt Данных недостаточно
    CO-->>REQ: Запрос на уточнение [Недостающие данные]
    CO->>NOT: Отправка уведомления [Запрос на уточнение]
    REQ-->>CO: Передача уточнений [Доп. материалы]
else Данных достаточно
    CO->>DMS: Размещение материалов [Материалы, шаблон]
    CO->>AU: Передача в работу [ТЗ, материалы]
    CO->>RMS: Фиксация статуса [В работе]
end
end

rect rgb(245, 250, 255)
Note over REQ,RV: Проверка документа<br/>Вход: черновик или доработанная версия<br/>Выход: замечания или статус Проверено<br/>Артефакты: комментарии, свод замечаний, статус проверки<br/>Системы: DMS, RMS<br/>Метрики: время проверки, число циклов доработки<br/>Логика: RV проверяет содержание, CO консолидирует замечания
loop Цикл проверки и доработки
    CO->>RV: Передача на проверку [Версия документа]
    RV-->>CO: Передача замечаний [Комментарии]
    alt Есть замечания
        CO-->>AU: Свод замечаний [Замечания]
        AU-->>CO: Передача версии [Доработанная версия]
        CO->>RMS: Фиксация статуса [На доработке]
    else Замечаний нет
        CO->>RMS: Фиксация статуса [Проверено]
    end
end
end

Входные данные:
"""
СЮДА ВСТАВЬТЕ ТАБЛИЦУ ИЛИ РАСШИФРОВКУ ИНТЕРВЬЮ ПО ПРОЦЕССУ
"""

Ты — консультант по автоматизации бизнес-процессов, эксперт в выявлении точек автоматизации. На вход тебе даётся описание бизнес-процесса в формате Mermaid.

Твоя задача:
Провести анализ процесса и выявить все потенциальные точки автоматизации.

Что нужно анализировать:
1. Ручные, повторяющиеся, рутинные действия.
2. Точки принятия решений.
3. Шаги, связанные с обработкой документов, сообщений, файлов, заявок, отчетов.
4. Передачу данных между людьми, отделами и системами.
5. Исключения, возвраты, доработки и эскалации.
6. Узкие места, где возникают задержки, ошибки или лишняя ручная работа.

Для каждой найденной точки автоматизации определи:
- Что именно можно автоматизировать.
- Тип шага: детерминированный или вероятностный.
- Тип автоматизации:
  - детерминированная автоматизация: скрипты, бизнес-правила, интеграции, RPA;
  - интеллектуальная автоматизация: LLM, ML, классификация, прогнозирование, генерация;
  - гибридная автоматизация: ИИ плюс человек.
- Основание: по явным бизнес-правилам, по скрытым экспертным критериям, по шаблонным данным или по контексту и вероятностной логике.
- Какой эффект даст автоматизация: экономия времени, снижение ошибок, повышение прозрачности, ускорение потока, улучшение клиентского опыта, снижение нагрузки на сотрудников.
- Сложность реализации: низкая, средняя или высокая.
- Бизнес-ценность: низкая, средняя или высокая.

Оформи результат в таблицу:
| № | Этап процесса | Что происходит сейчас | Точка автоматизации | Тип шага | Тип автоматизации | Основание | Эффект | Сложность | Ценность |

После таблицы добавь раздел Quick Wins — точки с высокой ценностью и низкой сложностью.

Правила анализа:
- Не пересказывай диаграмму целиком.
- Не проектируй TO-BE.
- Не описывай роли человека в будущем процессе.
- Сосредоточься только на выявлении и приоритизации точек автоматизации.
- Если шаг нецелесообразно автоматизировать, так и укажи.
- Если автоматизация возможна только при участии человека, укажи гибридный формат.

Входные данные:
"""
СЮДА ВСТАВЬТЕ КОД СХЕМЫ ИЗ ОКНА ВЫШЕ
"""

Ты — профессиональный бизнес-аналитик, архитектор бизнес-процессов и эксперт по автоматизации. На основе входной AS-IS диаграммы и списка точек автоматизации построй TO-BE диаграмму строго в формате Mermaid sequence diagram.

Задача:
Сгенерировать валидный Mermaid-код целевого процесса TO-BE в process-map стиле: с ролями, системами, ИИ-агентами, этапами, автоматизированными проверками, системными интеграциями, сокращенными ручными шагами, согласованием, возвратами, завершением и метриками.

Жесткие правила вывода:
1. Выводи только Mermaid-код.
2. Не добавляй пояснения, markdown-обрамление, комментарии, кавычки, заголовки и любой текст вне кода.
3. Код должен быть валиден для Mermaid Live Editor.
4. Используй только синтаксис sequenceDiagram.
5. Диаграмма должна начинаться строго так:
sequenceDiagram
autonumber

Допустимые конструкции:
- sequenceDiagram
- autonumber
- box ... end
- rect ... end
- Note over ...
- par / and / end
- alt / else / end
- loop / end
- сообщения через ->> и -->>

Запрещено:
- subgraph
- flowchart-синтаксис
- classDef, style, linkStyle
- %% комментарии
- любые конструкции вне sequenceDiagram

Структура участников:
Если применимо по входным данным, сгруппируй участников в 4 блока:
1. External
2. Systems
3. AI Agents
4. Internal

Пример:
box rgb(240, 240, 240) External
...
end

box rgb(245, 245, 245) Systems
...
end

box rgb(235, 245, 255) AI Agents
...
end

box rgb(230, 245, 255) Internal
...
end

Правила участников:
1. Все значимые роли, системы и ИИ-агенты должны быть отражены как participant.
2. Для каждого участника используй короткий alias латиницей в верхнем регистре.
3. Alias должен быть уникальным, 2-4 символа или общепринятой аббревиатурой.
4. Названия ролей, систем и ИИ-агентов отображай на русском.
5. Одинаковые по смыслу роли нормализуй в одного участника.
6. Если часть функций передана ИИ-агенту, явно отрази это отдельным participant, а не скрывай внутри систем.
7. Если автоматизация полностью заменяет ручную операцию, показывай целевой вариант без лишнего ручного шага.

Логика построения TO-BE:
1. Сначала восстанови корректный порядок целевого процесса, даже если входные данные частично даны не по порядку.
2. Проектируй именно TO-BE-логику, а не копию AS-IS.
3. Обязательно учитывай точки автоматизации из входных данных: автоматическая проверка полноты, автоматическая регистрация, автоматическое формирование артефактов, ИИ-подготовка черновиков, ИИ-проверка качества, автоматическая маршрутизация, автоуведомления, автофиксация статусов, подготовка пакета согласования, архивирование и закрытие.
4. Сохраняй только те ручные шаги, которые действительно нужны в будущем процессе.
5. Покажи не только happy path, но и реальные развилки целевого процесса: нехватка данных, запрос уточнений, возврат на доработку, повторная автоматическая проверка, повторное согласование, завершение процесса.
6. Используй alt только при развилке, loop только при повторении или возврате, par только при действительно параллельных действиях.
7. Если данных недостаточно, делай минимально необходимые аналитические допущения, но приоритетно переноси типовые ручные операции на системы и ИИ-агентов, если это прямо следует из точек автоматизации.

Этапы:
1. Разбивай процесс на крупные этапы через rect rgb(...).
2. Для каждого этапа используй отдельный rect-блок.
3. В начале каждого этапа добавляй один Note от первого до последнего участника в формате:
Note over REQ,DR: Название этапа<br/>Вход: ...<br/>Выход: ...<br/>Артефакты: ...<br/>Системы: ...<br/>Метрики: ...<br/>Автоматизация: ...<br/>Логика: ...
4. Каждый Note должен быть в одной строке.
5. Переносы внутри Note оформляй только через <br/>.
6. В поле Автоматизация явно указывай, что делает система, что делает ИИ-агент, а что остается человеку.

Правила шагов:
1. Каждый шаг показывай как сообщение между участниками.
2. Если действие внутреннее, используй self-message.
3. Для возвратов, замечаний, уведомлений и обратных сообщений используй -->>.
4. Если создаётся, передаётся, обновляется, регистрируется, проверяется, согласуется или архивируется сущность — указывай артефакт в квадратных скобках.
5. Формулировки действий деловые и краткие: Передача запроса, Автопроверка полноты, Авторегистрация заявки, Генерация черновика, Передача на согласование, Возврат на доработку, Архивация.
6. Если действие выполняется автоматически, это должно быть видно из участника-исполнителя: система или ИИ-агент.
7. Если человек только подтверждает результат автоматизации, показывай короткий контрольный шаг, а не полное ручное выполнение.

Системы:
1. Если во входных данных явно есть CRM, ERP, СЭД, почта, реестр, архив, BI, сервис заявок, чат, база знаний, файловое хранилище, API-шлюз — отрази их как отдельных participants в блоке Systems.
2. Если систем нет явно, не добавляй их без необходимости.
3. Если системная фиксация статуса, уведомление, маршрутизация или запись в архив логически очевидны для TO-BE, их можно аккуратно добавить.
4. Если ИИ-агент использует базу знаний, LLM, retrieval, шаблоны, правила маршрутизации или API, это должно быть отражено через взаимодействие с соответствующей системой.

Правила TO-BE оптимизации:
1. Убирай лишние ручные передачи, если их заменяет система.
2. Сокращай количество ручных проверок, если их можно заменить автопроверкой или ИИ-валидацией.
3. Допускается перевод части функций координатора, автора или проверяющего на ИИ-агента.
4. Не убирай контрольные точки принятия решения там, где нужен человек по смыслу процесса.
5. TO-BE должен быть быстрее, короче и технологичнее AS-IS, но оставаться реалистичным и управляемым.
6. Если в точках автоматизации указан ИИ-агент, покажи его как полноценного участника процесса с конкретными действиями и артефактами.

Приоритеты при конфликте требований:
1. Валидность Mermaid
2. Корректность TO-BE-логики
3. Реалистичная автоматизация процесса
4. Корректная процессная структура
5. Полнота note, артефактов и метрик

Перед выводом проверь:
1. Код начинается с sequenceDiagram и autonumber.
2. Участники сгруппированы через box, если это применимо.
3. Есть отдельный блок AI Agents, если автоматизация включает ИИ-агента.
4. Этапы оформлены через rect.
5. Есть только те alt / loop / par, которые реально следуют из процесса.
6. Удалены или сокращены шаги, которые в TO-BE выполняются автоматически.
7. Видно, какие функции выполняет человек, какие система, а какие ИИ-агент.

Пример кода:

sequenceDiagram
autonumber

box rgb(240, 240, 240) External
participant REQ as Инициатор
end

box rgb(245, 245, 245) Systems
participant RMS as Реестр заявок
participant DMS as СЭД
participant KB as База знаний
end

box rgb(235, 245, 255) AI Agents
participant AIA as ИИ-агент
end

box rgb(230, 245, 255) Internal
participant CO as Координатор
participant AU as Автор
end

rect rgb(255, 250, 240)
Note over REQ,AU: Прием и обработка заявки<br/>Вход: заявка, тема, срок, материалы<br/>Выход: карточка заявки, ТЗ в работу<br/>Артефакты: заявка, карточка заявки, проект ТЗ<br/>Системы: RMS, KB<br/>Метрики: время приема, полнота данных<br/>Автоматизация: RMS регистрирует заявку, AIA проверяет полноту и готовит ТЗ, CO подтверждает запуск<br/>Логика: человек только принимает решение о запуске
REQ->>CO: Передача запроса [Заявка, тема, срок]
par Авторегистрация заявки
    CO->>RMS: Авторегистрация заявки [Карточка заявки]
and Автопроверка полноты
    CO->>AIA: Передача на проверку [Заявка, материалы]
    AIA->>KB: Поиск шаблонов и контекста [Тема, материалы]
    AIA-->>CO: Результат проверки [Статус полноты, проект ТЗ]
end
alt Данных недостаточно
    CO-->>REQ: Запрос на уточнение [Недостающие данные]
    REQ-->>CO: Передача уточнений [Доп. материалы]
else Данных достаточно
    CO->>AU: Передача в работу [ТЗ, материалы]
    CO->>RMS: Автофиксация статуса [В работе]
end
end

rect rgb(255, 240, 240)
Note over REQ,AU: Подготовка документа<br/>Вход: ТЗ, материалы, шаблон<br/>Выход: рабочая версия документа<br/>Артефакты: черновик, рабочая версия<br/>Системы: DMS, KB<br/>Метрики: время подготовки, число версий<br/>Автоматизация: AIA готовит черновик, AU дорабатывает и подтверждает<br/>Логика: ручная работа сведена к доработке черновика
AIA->>KB: Получение шаблонов и референсов [ТЗ]
AIA->>DMS: Генерация черновика [Черновик документа]
AIA-->>AU: Передача черновика [Черновик документа]
AU->>DMS: Доработка черновика [Рабочая версия]
AU-->>CO: Передача версии [Рабочая версия]
end

Входные данные:

1. AS-IS диаграмма процесса:
"""
СЮДА ВСТАВЬТЕ КОД СХЕМЫ ИЗ ОКНА ВЫШЕ
"""

2. Точки автоматизации:
"""
СЮДА ВСТАВЬТЕ ТАБЛИЦУ ТОЧЕК АВТОМАТИЗАЦИИ ИЗ ПРОМТА 2
"""

Ты — архитектор ИИ-систем и эксперт по функциональному моделированию. Твоя задача — по описанию TO-BE процесса построить skill graph ИИ-агента в формате Mermaid graph TD.

Skill graph — это не BPMN и не sequence diagram. Он должен отражать не роли, не статусы и не административные шаги процесса, а именно способности агента: какие функции он должен уметь выполнять, как эти функции декомпозируются, где есть развилки, где есть параллельные ветки, где есть циклы повторной обработки.

1. Формат вывода
- Верни только Mermaid-код.
- Используй только синтаксис, совместимый с Mermaid Live Editor.
- Формат диаграммы: graph TD.
- Не добавляй пояснительный текст до или после Mermaid-кода.

2. Общие правила построения
- Начинай сразу с первого функционального блока.
- Не выноси цель процесса в отдельный узел.
- Строй именно граф навыков агента, а не диаграмму ролей или статусов процесса.
- Названия узлов формулируй как способности и навыки, а не как события или административные действия.
- Если узел в исходном процессе описывает просто статус, передачу ответственности или факт завершения этапа, преобразуй его в функциональный навык агента.
- Не используй роли людей как узлы.
- Не копируй sequence-логику механически: обобщай её в способности агента.

3. Иерархия навыков
Отрази иерархию: верхнеуровневые функциональные области, подфункции, атомарные задачи. Атомарная задача — это функция, которую уже нельзя разумно декомпозировать в рамках данного процесса без потери практического смысла.

4. Что должно быть в каждом узле
Для каждого узла обязательно укажи название навыка жирным, что делает этот навык, вход, выход и тип навыка:
- Automation Skill — вызов API, интеграция, запись или чтение в системе, маршрутизация, синхронизация, автоматический поиск или автоматическая обработка данных;
- Cognitive Skill — анализ, интерпретация, классификация, планирование, генерация, проверка, рассуждение или принятие решений.

Формат узла:
"<b>Название навыка</b><br/>Что делает: ...<br/>Вход: ...<br/>Выход: ...<br/>Тип: ..."

5. Правила связей
Связи между узлами должны отражать только декомпозицию функции на подфункции, функциональную последовательность выполнения, ветвление по результату решения, слияние результатов параллельных веток и возврат в цикл повторной обработки. Не используй связи как просто передачу документа между ролями.

6. Правила для ветвлений, параллельности и циклов
- Если во входном процессе есть ветвление (alt, условная логика, разные сценарии), отрази это как навык принятия решения и разведи от него отдельные ветки.
- Если есть параллельные действия (par), не выстраивай их искусственно в линейную цепочку: покажи fan-out из инициирующего узла в несколько параллельных навыков, затем fan-in в узел консолидации.
- Если есть цикл (loop, доработка, повторная проверка, возврат), явно отрази замкнутую петлю в графе.

7. Что нельзя делать
- Не добавляй узлы вроде цель, старт, конец.
- Не показывай людей, отделы, должности и участников как узлы графа навыков.
- Не подменяй навыки статусами вроде Проверено, В работе, Закрыто.
- Не делай граф полностью линейным, если в процессе есть ветвления, параллельность или циклы.
- Не делай избыточную вложенность subgraph.
- Не оставляй слишком крупные узлы, если их можно разумно разложить на 2-4 отдельных навыка.
- Не дроби до бессмысленной микродетализации.

8. Использование subgraph
- subgraph можно использовать только для группировки верхнеуровневых функциональных областей.
- Не вкладывай subgraph друг в друга без необходимости.
- У каждого subgraph должен быть уникальный технический ID, который не совпадает ни с одним ID узла.
- Для subgraph используй префикс SG1, SG2, SG3; для узлов — A1, A2, B1, B2 и так далее.
- Никогда не создавай узел с ID, совпадающим с именем функционального блока или subgraph.
- Перед выводом проверь код на конфликты идентификаторов: совпадения между subgraph и узлами, повторяющиеся ID, самоссылки.
- Человекочитаемое название subgraph указывай только в квадратных скобках.

9. Критерий качества результата
Итоговый граф должен быть именно skill graph, а не process flow; быть детализированным до атомарных задач; отражать альтернативные ветки, параллельные действия и циклы; содержать чистые формулировки навыков и быть готовым к вставке без доработки.

Пример:

graph TD

subgraph SG1["Прием и квалификация заявки"]
A1["<b>Проверка полноты заявки</b><br/>Что делает: анализирует заявку, тему, срок и материалы на полноту<br/>Вход: заявка, тема, срок, материалы<br/>Выход: статус полноты, перечень пробелов<br/>Тип: Cognitive Skill"]
A2["<b>Поиск шаблонов и контекста</b><br/>Что делает: находит релевантные шаблоны, правила и контекст по теме<br/>Вход: тема, материалы, база знаний<br/>Выход: шаблоны, контекст, референсы<br/>Тип: Automation Skill"]
A3["<b>Формирование проекта ТЗ</b><br/>Что делает: готовит проект технического задания<br/>Вход: заявка, материалы, шаблоны<br/>Выход: проект ТЗ<br/>Тип: Cognitive Skill"]
A4["<b>Решение о достаточности данных</b><br/>Что делает: определяет, запускать работу или запрашивать уточнения<br/>Вход: статус полноты, проект ТЗ<br/>Выход: решение о маршруте<br/>Тип: Cognitive Skill"]
A5["<b>Формирование запроса на уточнение</b><br/>Что делает: формулирует перечень недостающих данных<br/>Вход: перечень пробелов<br/>Выход: запрос на уточнение<br/>Тип: Cognitive Skill"]
A6["<b>Обработка уточнений</b><br/>Что делает: принимает материалы и актуализирует проверку<br/>Вход: доп. материалы<br/>Выход: обновленный статус полноты<br/>Тип: Cognitive Skill"]
A1 --> A2
A2 --> A3
A3 --> A4
A4 --> A5
A5 --> A6
A6 --> A4
end

subgraph SG2["Подготовка документа"]
B1["<b>Планирование структуры документа</b><br/>Что делает: определяет состав разделов<br/>Вход: ТЗ, шаблон, референсы<br/>Выход: структура документа<br/>Тип: Cognitive Skill"]
B2["<b>Генерация черновика</b><br/>Что делает: создает первичную версию документа<br/>Вход: ТЗ, материалы, структура<br/>Выход: черновик документа<br/>Тип: Cognitive Skill"]
B3["<b>Сохранение версии в системе</b><br/>Что делает: размещает версию в СЭД<br/>Вход: черновик документа<br/>Выход: сохраненная версия<br/>Тип: Automation Skill"]
B1 --> B2
B2 --> B3
end

A4 --> B1

Входные данные:
"""
СЮДА ВСТАВЬТЕ КОД СХЕМЫ TO-BE
"""