Архитектор не знает систему изначально.
Он быстро строит рабочую модель, достаточную для принятия решений о цене, рисках и устойчивости.

Аналитик описывает “что есть” и “что нужно”.
Архитектор определяет “как это должно быть устроено системно”.

AS-IS / TO-BE делают оба, но на разных уровнях и с разной ответственностью.

Table of Contents

Что именно делает системный аналитик в AS-IS / TO-BE

Это важно проговорить, чтобы не обесценить аналитику (и себя).

Уровень аналитика

Бизнес-процессы
Пользовательские сценарии
Функциональные разрывы
Требования
Ограничения со стороны бизнеса

AS-IS аналитика

как сейчас работают процессы и системы с точки зрения бизнеса.

TO-BE аналитика

как бизнес хочет работать, какие функции нужны.

👉 Это “что” и “зачем”.

Что делает архитектор в AS-IS / TO-BE (и почему это его зона)

Уровень архитектора

Границы систем
Контуры ответственности
Архитектурные стили
Интеграции
Нагрузки
Эксплуатация
TCO и риски
TCO (Total Cost of Ownership) — совокупная стоимость владения. Это полная сумма расходов на продукт или услугу за весь период использования.

AS-IS архитектора

как реально устроен ИТ-ландшафт:
какие системы есть, как связаны, где узкие места.

TO-BE архитектора

какая структура системы будет устойчивой при росте требований.

👉 Это “как и за счёт чего”.

Аналитик отвечает за корректность требований,
архитектор — за жизнеспособность решения.

Аналитик описывает желаемое состояние,
архитектор отвечает за последствия его реализации.

Почему AS-IS / TO-BE без архитектора — опасно

Аналитический TO-BE часто:

функционально правильный,
архитектурно нежизнеспособный.

Без архитектора:
- растёт технический долг,
- ухудшается производительность,
- ломается эксплуатация.

👉 Поэтому архитектор обязан участвовать в AS-IS / TO-BE.

Аналитики делают AS-IS/TO-BE с точки зрения бизнес-процессов и требований.
Я же делаю AS-IS/TO-BE на уровне ИТ-архитектуры: ландшафт систем, интеграции, контуры ответственности и эксплуатационные ограничения.

AS-IS архитектора

сколько систем участвует,
какие интеграции существуют,
где дублирование функций,
где точки отказа,
где “ручные костыли”.

TO-BE архитектора

какие контуры должны быть в ERP,
где границы между системами,
какие данные где живут,
какие интеграции допустимы,
какие — запрещены,
как система будет масштабироваться.

Аналитик может предложить TO-BE, но архитектор принимает решение, потому что он несёт ответственность за последствия.

Когда AS-IS / TO-BE — НЕ зона архитектора

Чтобы быть честным:

детальные BPMN бизнес-процессов,
пользовательские экраны,
регламенты работы пользователей.

Это аналитика, и туда архитектор обычно не лезет.

Кейс: внедрение / переработка складского учёта AS-IS / TO-BE архитектора

Контекст (исходные вводные)

Компания:

5–50 складов
магазины / производство / e-commerce
растущие объёмы
проблемы с остатками, резервами, скоростью

Аналитик говорит:

«Нужно вести складской учёт, чтобы остатки были точные»

Архитектор задаёт другой вопрос:

Где, как, за счёт чего и какой ценой система будет это выдерживать?

AS-IS архитектора (как есть СЕЙЧАС)

1️⃣ Границы систем (что реально участвует)

Архитектор фиксирует факты, а не пожелания:

1С УТ / ERP — основной учёт
Excel / ручные файлы — инвентаризации
POS / магазины — продажи
Производство / сборка — списания
BI — отчёты
Возможно:
- WMS (Axelot)
- самописка
- e-commerce

👉 Ключевой вопрос архитектора:
где сейчас фактически меняются остатки?

2️⃣ Контуры ответственности (кто за что отвечает)

Архитектор выявляет опасные зоны:

Остатки:
- считаются в 1С
- но корректируются вручную
Резервы:
- есть в ERP
- но магазины их не видят
Инвентаризация:
- раз в месяц
- расхождения — “ну бывает”

👉 Здесь архитектор уже видит будущие риски, которые аналитик может не заметить.

3️⃣ Интеграции (где боль)

Архитектор смотрит не на “есть обмен”, а на качество обмена:

Продажи приходят с задержкой
Списание может прийти дважды
Нет идемпотентности
Идемпотентность — свойство объекта или операции, при повторном применении которой к объекту даётся тот же результат, что и при первом.
Нет SLA: когда остатки считаются актуальными?

👉 AS-IS архитектора — это карта слабых мест, а не схема “что куда”.

4️⃣ Нагрузки (о чём обычно забывают)

Архитектор считает:

количество движений в день
пиковые часы
количество SKU
количество складов

И видит, например:

100k движений в день
всё в одном регламентном задании
отчёты тормозят

👉 Это архитектурный AS-IS, а не аналитический.

5️⃣ Эксплуатация (как система живёт)

Архитектор выясняет:

кто узнаёт о сбое?
где логи?
можно ли безопасно повторить обмен?
сколько времени чинят?

👉 Часто выясняется:

«Пока бухгалтер не позвонит — никто не знает»

6️⃣ TCO и риски (скрытая часть AS-IS)

TCO (Total Cost of Ownership) — совокупная стоимость владения. Это полная сумма расходов на продукт или услугу за весь период использования.

Архитектор фиксирует:

высокая стоимость ручных операций
зависимость от конкретных людей
риск деградации при росте

👉 Это исходная точка для TO-BE.

TO-BE архитектора (как ДОЛЖНО БЫТЬ)

Теперь архитектор проектирует устойчивую модель, а не просто “новый учёт”.

1️⃣ Границы систем (целевая модель)

Архитектор решает:

где единственный источник истины по остаткам
где допустимы копии
где запрещено менять данные

Например:

ERP — мастер остатков
WMS — операционный контур
Магазины — только чтение + события

2️⃣ Контуры ответственности (чётко)

В TO-BE:

складской учёт → ERP / WMS
продажи → POS
аналитика → BI
корректировки → строго регламентированы

👉 Архитектор запрещает опасные сценарии, даже если они “удобные”.

3️⃣ Архитектурный стиль

Архитектор выбирает стиль:

не “как удобнее”
а “что выдержит рост”

Например:

события (приёмка / отгрузка)
асинхронные обмены
запрет прямых правок остатков

👉 Это архитектурное решение, не аналитическое.

4️⃣ Интеграции (по правилам)

Архитектор задаёт:

каноническую модель движений
контракты
идемпотентность
Идемпотентность — свойство объекта или операции, при повторном применении которой к объекту даётся тот же результат, что и при первом.
SLA (T+5 мин, T+1 час, ночь)

👉 Теперь остатки предсказуемы, а не “примерно”.

5️⃣ Нагрузки (заложены заранее)

В TO-BE:

разделены оперативные и аналитические контуры
тяжёлые отчёты вынесены
регламенты распараллелены

👉 Система не умирает при росте.

6️⃣ Эксплуатация (не героизм)

Архитектор проектирует:

логирование
алерты
повторы
понятную реакцию на сбои

👉 В результате:

инцидент — это событие, а не паника.

7️⃣ TCO и риски (осознанно)

Архитектор:

сравнивает варианты (ERP-only vs ERP+WMS)
считает стоимость сопровождения
учитывает рынок специалистов

👉 Выбирается не “самое умное”, а самое жизнеспособное.

Аналитик отвечает за то, что складской учёт нужен и как он должен выглядеть для бизнеса.
Архитектор отвечает за то, чтобы этот учёт работал стабильно, масштабировался и не ломался через год.

Роль архитектора в складском учете — определить границы систем, источник истины, интеграции, нагрузки и эксплуатационную модель,
чтобы решение было устойчивым при росте объёмов и количества складов, а не только функционально корректным.

Роль архитектора: Ключевая стратегия для устойчивых систем