Добавить в корзинуПозвонить
Найти в Дзене

Статья 14. 1С:ERP — Этап 7: после запуска проект только начинается. Гиперподдержка, инциденты, корректировки и т.д. (Артефакты 7.3–7.19)

Есть две иллюзии, которые часто появляются после запуска 1С:ERP: Именно эти две иллюзии чаще всего и убивают доверие к ERP. Потому что после запуска неизбежно всплывают: Если в этот момент нет организованной гиперподдержки, предприятие быстро откатывается в “ручной режим”: Этап 7 нужен ровно для того, чтобы закрепить новый порядок. Мы запустились. Зачем ещё гиперподдержка? Давайте просто “подумаем по месту”. Почему нельзя исправлять проблемы в чатике? Зачем журнал инцидентов и протоколы? Зачем договор техподдержки, если система уже работает? После запуска 1С:ERP начинается самая уязвимая фаза. В этот период у проекта есть две задачи: Если этого не сделать, возникают типовые симптомы: Поэтому после запуска нужны артефакты эксплуатации. Это расписание дежурств и правил реакции: Коротко: 7.3 нужен, чтобы поддержка была системой, а не “кто свободен — тот отвечает”. Единое место фиксации проблем по формуле: симптом → причина → решение → статус. Что обычно фиксируется: Почему нельзя “в чатик
Оглавление

Есть две иллюзии, которые часто появляются после запуска 1С:ERP:

  1. «Мы запустились — значит проект закончился».
  2. «Если что — поправим по месту».

Именно эти две иллюзии чаще всего и убивают доверие к ERP.

Потому что после запуска неизбежно всплывают:

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

Если в этот момент нет организованной гиперподдержки, предприятие быстро откатывается в “ручной режим”:

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

Этап 7 нужен ровно для того, чтобы закрепить новый порядок.

Вопрос подписчика

Мы запустились. Зачем ещё гиперподдержка? Давайте просто “подумаем по месту”.

Почему нельзя исправлять проблемы в чатике? Зачем журнал инцидентов и протоколы?

Зачем договор техподдержки, если система уже работает?

Суть проблемы

После запуска 1С:ERP начинается самая уязвимая фаза.

В этот период у проекта есть две задачи:

  1. Стабилизировать систему — чтобы ключевые процессы шли без постоянных остановок.
  2. Закрепить правила — чтобы предприятие не скатилось обратно в Excel и «ручные договоренности».

Если этого не сделать, возникают типовые симптомы:

  • инциденты теряются;
  • решения не фиксируются;
  • исправления ломают другое;
  • пользователи привыкают к обходам;
  • доверие к системе падает.

Поэтому после запуска нужны артефакты эксплуатации.

Артефакты статьи (7.3–7.19)

  • 7.3 — График дежурств гиперподдержки
  • 7.4 — Журнал инцидентов
  • 7.5 — Летучки и протоколы решений
  • 7.6 — Список задач после запуска
  • 7.7 — Отчёты мониторинга
  • 7.8 — Корректирующие документы в 1С:ERP
  • 7.9 — Акт сверки окончательных остатков
  • 7.10 — Акт критериального аудита успешности перехода
  • 7.13 — Договор техсопровождения 1С:ERP
  • 7.14 — Заявки на сопровождение
  • 7.16 — Доработки: ТЗ и смета
  • 7.17 — Лист учёта рабочего времени
  • 7.18 — Сдача-приёмка услуг сопровождения
  • 7.19 — ЭДО и рабочие каналы коммуникации

7.3: график гиперподдержки

Что это такое

Это расписание дежурств и правил реакции:

  • кто дежурит,
  • когда доступен,
  • по каким каналам,
  • с каким уровнем сервиса (SLA),
  • как происходит эскалация.

Коротко:

7.3 нужен, чтобы поддержка была системой, а не “кто свободен — тот отвечает”.

7.4: журнал инцидентов

Что это такое

Единое место фиксации проблем по формуле:

симптом → причина → решение → статус.

Что обычно фиксируется:

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

Почему нельзя “в чатике”?
Потому что чат не держит:

  • статусы,
  • причины,
  • повторяемость,
  • контроль закрытия.

Журнал превращает хаос в управляемый поток.

7.5–7.6: протоколы решений и список задач после запуска

7.5 — летучки и протоколы

Это короткие регулярные встречи с фиксированием:

  • что решили,
  • кто делает,
  • в какой срок,
  • к какому артефакту относится (права, инструкция, настройка, доработка).

7.6 — бэклог после запуска

Это управляемый список:

  • что исправляем;
  • что улучшаем;
  • что переносим в следующую волну.

Коротко:

7.5–7.6 нужны, чтобы решения не растворялись и не повторялись.

7.7: мониторинг

После запуска важно не только реагировать, но и предупреждать.

Мониторинг обычно включает:

  • очереди обменов;
  • ошибки интеграций;
  • производительность;
  • блокировки;
  • регламент реакции.

Коротко:

7.7 нужен, чтобы система не умирала “в тишине”, пока кто-то случайно не заметил.

7.8: корректирующие документы

Что это такое

Легальные способы исправления учёта.

Главный запрет:

нельзя лечить учет ручными правками базы.

Корректировки делаются документами и с контролем отчетов после исправления.

Коротко:

7.8 защищает предприятие от “тихого разрушения данных”.

7.9–7.10: финальная сверка и критериальный аудит

7.9 — акт сверки окончательных остатков

Это финальная фиксация, что цифры сошлись после запуска:

  • по контрольным отчетам,
  • с подписанием ответственных.

7.10 — акт критериального аудита

Это подтверждение, что запуск успешен по заранее заданным критериям:

  • ключевые процессы проходят;
  • отчеты сходятся;
  • роли работают;
  • интеграции стабильны.

Коротко:

7.9–7.10 снимают вечный вопрос “а точно мы запустились нормально?”

7.13–7.19: контур сопровождения

Запуск завершается не “тишиной”, а переходом в нормальный режим сопровождения.

7.13 — договор техсопровождения

Фиксирует:

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

7.14 — заявки

Жизненный цикл обращений: как подаются, как классифицируются, кто отвечает.

7.16 — доработки: ТЗ и смета

Когда появляется развитие, оно снова должно быть управляемым: что делаем, почему, сколько стоит.

7.17 — учет времени

Чтобы сопровождение не было “черным ящиком”, а было прозрачным.

7.18 — сдача-приёмка

Фиксация выполненных работ.

7.19 — ЭДО и каналы

Чтобы коммуникации и документы не терялись.

Коротко:

7.13–7.19 переводят проект в стабильное сопровождение и развитие.

Как 7.3–7.19 прошивают слои TOGAF/ArchiMate

  • Бизнес: пользователи не уходят в обходы, процессы стабилизируются.
  • Данные: корректировки делаются легально, качество данных растёт.
  • Приложения: изменения фиксируются, регресс контролируется.
  • Техслой: мониторинг держит интеграции и производительность.
  • Управление: появляется управляемый цикл развития, KPI и финконтур стабилизируются.

Цепочка «7.3–7.19 → следующий шаг»

  • 7.3–7.6 → стабилизация (снятие основных болей и закрепление правил)
  • 7.7 → предотвращение повторов (проактивный контроль)
  • 7.8–7.10 → финальная фиксация успешности перехода
  • 7.13–7.19 → перевод проекта в штатное сопровождение и развитие (волна 2)

Хороший сценарий

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

Плохой сценарий

  • “пишем в чатик”;
  • инциденты теряются;
  • правки делаются вручную;
  • обходы становятся нормой;
  • доверие к ERP падает;
  • начинается откат в Excel и «ручной режим».

Итог простыми словами

Запуск 1С:ERP — это старт эксплуатации.

Артефакты 7.3–7.19 — это то, что удерживает систему живой, а предприятие — управляемым.

Мини-чеклист для заказчика

  1. Есть график гиперподдержки и SLA.
  2. Есть единый журнал инцидентов.
  3. Есть протоколы решений и бэклог.
  4. Есть мониторинг обменов/ошибок.
  5. Исправления делаются только корректирующими документами.
  6. Есть финальная сверка и аудит.
  7. Есть договор сопровождения и порядок заявок.

Что дальше

Следующая статья — заключительная: 1С:ERP как опорная база интеллектуализации предприятия.

Там свяжем весь цикл артефактов с будущим контуром: KPI-движок, стресс-модели, управленческий цикл и путь к интеллектуальному предприятию (как перспективе искусственной личности).