Откуда архитектор 1С ERP «все знает»?

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

Это принципиально.

Откуда архитектор берёт понимание «какой ценой»

Цена = люди + сложность + время + риск эксплуатации.
Архитектор извлекает это не из знания всех регистров, а из структуры системы.

1️⃣ Первый источник — структурированные опросы (не “интервью”)

Да, опросы. Но специальные, архитектурные, не “расскажите как работает”.

Кого опрашивает архитектор

  • ключевых аналитиков,
  • ведущих 1С-разработчиков,
  • эксплуатацию / поддержку,
  • владельцев ключевых контуров (склад, финансы).

Какие вопросы он задаёт (примеры)

Не:

«Как у вас устроен складской учёт?»

А:

  • где считается остаток фактически?
  • что ломается чаще всего?
  • где самый тяжёлый код?
  • какие изменения делать страшно?
  • что нельзя трогать перед акцией?
  • где всё “держится на одном человеке”?

👉 Эти ответы быстро показывают цену.

2️⃣ Второй источник — AS-IS архитектуры, а не учёта

Архитектор не лезет в детали расчёта себестоимости.

Он смотрит:

  • количество систем,
  • количество интеграций,
  • синхронность / асинхронность,
  • объёмы данных,
  • наличие регламентов,
  • характер отказов.

👉 Даже без знания учёта видно:

  • где будет дорого,
  • где риск,
  • где техдолг.

3️⃣ Третий источник — сигналы из эксплуатации (самый ценный)

Эксплуатация говорит правду, даже если не знает терминов.

Архитектор слушает:

  • “это нельзя перезапускать”
  • “это чинится только ночью”
  • “тут всегда расхождения”
  • “если упадёт — магазин встанет”

👉 Это чистая цена владения, без бухгалтерии.

4️⃣ Четвёртый источник — типовые паттерны и анти-паттерны

Архитектор узнаёт знакомые формы, даже не зная конкретную систему.

Например:

  • прямые правки остатков → высокий риск
  • отсутствие идемпотентности → дорогая эксплуатация
  • единый регламент на всё → масштаб не держится
  • Excel в цепочке → скрытый TCO

👉 Это опыт, а не знание учёта.

5️⃣ Пятый источник — точечное погружение, а не полное

Только после первых гипотез архитектор погружается выборочно:

  • один ключевой документ,
  • один тяжёлый отчёт,
  • один проблемный обмен.

Не всё.
Ровно столько, сколько нужно, чтобы подтвердить или опровергнуть гипотезу.

6️⃣ Ответ на твой прямой вопрос (чётко)

Да, архитектор сначала опрашивает и строит модель,
а уже потом сверяет её с реальной реализацией в ERP.

Но:

  • не для того, чтобы всё понять,
  • а чтобы проверить критические допущения.

7️⃣ Как архитектор говорит об этом (очень важно)

Если тебя спросят:

«Откуда вы знаете, что это будет дорого / рискованно?»

Ты отвечаешь так:

Я не претендую на знание всех деталей учёта.
Я работаю через выявление архитектурных рисков:
количество связей, сложность интеграций, нагрузку и эксплуатационные сигналы.
Этого достаточно, чтобы оценить цену решений и сравнить варианты.

💥 Это очень сильный, честный ответ.

8️⃣ Что архитектор НЕ делает (и это нормально)

❌ не изучает все регистры
❌ не знает все бизнес-правила
❌ не заменяет аналитика или бухгалтера

👉 Его сила — в системном срезе, а не в деталях.

9️⃣ Альтернативная точка зрения

  1. Если проект сверх-специфичный
    → потребуется более глубокое погружение в отдельные контуры.
  2. Если нет аналитиков
    → архитектор временно берёт часть аналитической работы.
  3. Если компания ждёт “архитектора-всезнайку”
    → это неправильное ожидание, и лучше выявить его заранее.

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

+ There are no comments

Add yours