Матрица хрупкости ERP: Устраните опасные риски

Ниже — универсальная матрица хрупкости ERP-проекта на 1С, которую можно:

• сразу применять на проекте,
• копировать в Confluence / Excel / Notion,
• использовать как аргумент в разговоре с руководством и бизнесом.

Я дам:

1. модель оценки
2. набор вопросов (15 — не 10, потому что 10 мало)
3. шкалу хрупкости
4. приоритет исправления
5. пример заполнения
6. как превратить это в план действий

1. Что мы оцениваем

Объект оценки — процесс, а не:

• модуль,
• документ,
• разработчик.

Примеры процессов:

• Обмен заказами с сайтом
• Загрузка банковских выписок
• Закрытие месяца
• Расчёт себестоимости
• Формирование реализации из заказов
• Регламент расчёта НДС
• Обновление остатков из WMS
• Массовое перепроведение

2. Шкала оценки (простая и жёсткая)

Каждый вопрос оценивается:

• 0 — безопасно
• 1 — риск есть, но контролируем
• 2 — хрупко / потенциальная авария

3. Вопросы матрицы хрупкости (15 шт.)

A. Повторы и идемпотентность

1. Что произойдёт, если процесс выполнится повторно?
   • 0 — ничего / восстановление
   • 1 — частичное дублирование
   • 2 — порча данных / дубли
2. Есть ли явный ключ операции (бизнес-ключ)?
   • 0 — есть и используется
   • 1 — есть частично
   • 2 — нет
3. Результат зависит от истории запусков?
   • 0 — нет
   • 1 — частично
   • 2 — полностью

B. Сбои и перезапуски

4. Безопасен ли перезапуск после падения на середине?
   • 0 — да
   • 1 — зависит от этапа
   • 2 — нет
5. Есть ли точки фиксации состояния процесса?
   • 0 — есть
   • 1 — косвенно
   • 2 — нет
6. Можно ли восстановить процесс без ручной правки БД?
   • 0 — да
   • 1 — сложно
   • 2 — нет

C. Документы и регистры

7. Документы — состояние или побочный эффект?
   • 0 — состояние
   • 1 — смешано
   • 2 — побочный эффект
8. Регистры можно безопасно пересчитать?
   • 0 — да
   • 1 — частично
   • 2 — нет
9. Повторное проведение документов безопасно?
   • 0 — да
   • 1 — не всегда
   • 2 — опасно

D. Интеграции и входные данные

10. Есть журнал входящих сообщений / данных?
    • 0 — есть
    • 1 — частично
    • 2 — нет
11. Повтор входящего сообщения корректно обрабатывается?
    • 0 — да
    • 1 — иногда
    • 2 — нет
12. Можно отследить путь “вход → результат”?
    • 0 — да
    • 1 — с трудом
    • 2 — невозможно

E. Управляемость и поддержка

13. Ошибки логируются и диагностируются?
    • 0 — да
    • 1 — частично
    • 2 — глушатся
14. Изменение логики процесса предсказуемо?
    • 0 — да
    • 1 — рискованно
    • 2 — ломает всё вокруг
15. Есть архитектурное описание процесса?
    • 0 — есть
    • 1 — устарело
    • 2 — нет

4. Подсчёт хрупкости

Сумма баллов:

• 0–10 — устойчивый процесс
• 11–20 — рискованный
• 21–30 — хрупкий
• 31+ — аварийный (технический долг с процентами)

5. Приоритет исправления (самое важное)

Приоритет ≠ баллы.

Используем формулу:

Приоритет = Хрупкость × Частота × Бизнес-критичность

Частота:

• 1 — редко
• 2 — регулярно
• 3 — постоянно

Бизнес-критичность:

• 1 — вторично
• 2 — важно
• 3 — критично

6. Пример заполнения (реальный)

Процесс: Загрузка заказов с сайта

• Баллы: 28
• Частота: 3 (постоянно)
• Критичность: 3 (деньги)

Приоритет: 28 × 3 × 3 = 252 → ТОП-1 в очередь

Процесс: Закрытие месяца

• Баллы: 22
• Частота: 1
• Критичность: 3

Приоритет: 66 → второй эшелон

7. Что делать после матрицы (важно!)

❌ Типичная ошибка

«Мы всё оценили — отлично».

✅ Правильный следующий шаг

Для ТОП-3 процессов:

1. Зафиксировать целевой инвариант
2. Определить ключ операции
3. Решить:
   • пересчёт,
   • восстановление,
   • запрет повторов
4. Записать архитектурное решение (ADR)

8. Альтернативные варианты и точки зрения

1. Ты можешь переоценивать хрупкость
   👉 Проверь: были ли реальные инциденты за год?
2. Бизнес может принять риск
   👉 Проверь: зафиксирован ли он письменно?
3. Не всё нужно чинить сразу
   👉 Проверь: есть ли процесс с приоритетом > 150?