🧾 Постмортем после внедрения: как и зачем анализировать каждый запуск
Важно: В нашем контексте «постмортем» — это не про сбой, а про глубокий разбор завершённого внедрения. Мы не ищем виноватых. Мы ищем возможности стать лучше.
🔹 1. Краткое описание
Цель раздела:
Через полгода любой коллега (или вы сами) должен за 30 секунд понять: что, у кого и зачем внедряли.
Что писать:
- Имя клиента и отрасль (например, «Aller Petfood — производство сухого корма для животных»).
- Тип оборудования (например, «9 фасовочных линий типа Effytec»).
- Основная задача внедрения («Печать DataMatrix-кодов по требованиям системы “Честный ЗНАК” с сериализацией и интеграцией в 1С»).
- Сроки (фактические или план/факт).
- Ключевые участники с нашей стороны.
Пример:
«Внедрение комплекса маркировки на 9 упаковочных линиях завода Aller Petfood. Требовалась печать двух DataMatrix-кодов на упаковке (основной + дубль) с использованием пьезопринтеров Yeacode и интеграцией в 1С:ERP. Срок — 2 недели с момента прибытия оборудования. Участвовали: В. Пупкин (инженер), И. Иванов (настройка ПО).»
🔹 2. Обнаруженные проблемы
Цель раздела:
Выявить системные и технические сложности, которые помешали работе — даже если их в итоге обошли.
Что писать:
- Конкретные технические препятствия (например, «не хватило места в шкафу под СНПЧ»).
- Пробелы в информации от клиента («не сказали, что на линии два кода за такт»).
- Архитектурные или проектные недоработки («не учли особенности дуплекс-машины»).
Пример:
«1. Внутри корпуса упаковочной машины Effytec оказалось недостаточно места для размещения пьезопринтера и СНПЧ одновременно — пришлось искать нестандартное решение по креплению.
2. Клиент не сообщил заранее, что на части линий требуется печать двух кодов за один такт — это повлияло на настройку ПО и задержало ПНР.
3. На машине типа “дуплекс” невозможно корректно настроить датчик метки без фиксации пленки — стандартное решение не сработало.»
🔹 3. Что было хорошо
Цель раздела:
Зафиксировать лучшие практики, которые стоит сохранить и масштабировать.
Что писать:
- Удачные решения клиента или наших специалистов.
- Быстрые и грамотные действия.
- Инструменты, подходы или договорённости, которые сработали.
Пример:
«1. Клиент самостоятельно подключил отбраковщик через сухой контакт с машины — сэкономили 4 часа на настройке.
2. Механики клиента приварили монтажные шкафы, не нарушив герметичность — это ускорило монтаж и повысило надёжность.
3. Удалось использовать существующий датчик продукта — не пришлось тянуть новые провода.»
🔹 4. Что было плохо
Цель раздела:
Честно признать ошибки в планировании, коммуникации или подготовке, которые привели к потерям времени, ресурсов или нервов.
Что писать:
- Что можно было предусмотреть, но не предусмотрели.
- Где не хватило согласования внутри команды или с клиентом.
- Где нарушили собственный процесс.
Пример:
«1. Требование “два кода за такт” выяснилось только на ПНР — не уточнили при сборе ТЗ.
2. Не проверили особенности протяжки пленки на дуплекс-машинах — из-за этого пришлось менять схему установки датчика метки прямо на объекте.
3. На одной из линий разъём принтера был распинован неверно — потратили 8 человеко-часов на поиск причины. Это ошибка сборки, которую можно было избежать проверкой на складе.»
🔹 5. Где нам повезло
Цель раздела:
Выявить уязвимости, которые не привели к провалу только благодаря случайности — и устранить их.
Что писать:
- Что могло обернуться серьёзной проблемой, но не обернулось.
- Помощь клиента, которая спасла ситуацию, но не должна быть обязательной в будущем.
- Обстоятельства, на которые мы не рассчитывали.
Пример:
«1. Клиент сам предложил заменить штатные датчики метки на свои с рамкой фиксации пленки — иначе бы не смогли настроить детектирование.
2. Механики клиента изготовили проставки под СНПЧ — это решило проблему с высотой печатающей головы.
3. Клиент отнёсся без негатива к задержкам и дал дополнительное время — в другом случае ушли бы с незакрытым проектом.»
💡 Вывод: если нам «повезло» — нужно превратить это в стандартную процедуру. Например: «Добавить в чек-лист пункт: уточнить тип фиксации пленки на дуплекс-машинах».
🔹 6. Где нам не повезло
Цель раздела:
Признать внешние факторы, которые усложнили проект, но не являются оправданием — просто контекст для будущих решений.
Что писать:
- Непредсказуемые действия клиента.
- Ошибки поставщиков оборудования.
- Изменения в требованиях «Честного ЗНАК» или законодательстве в самый неподходящий момент.
Пример:
«1. Оказалось, что одна и та же номенклатура на разных линиях требует разного количества кодов (один vs два) — до запуска мы ошибочно считали, что везде одинаково.
2. При установке оборудования “как удобно клиенту” осталось слишком мало места для регулировки смещения печати — пришлось идти на компромиссы по качеству.
3. За день до запуска клиент сменил версию 1С — пришлось экстренно адаптировать интеграцию.»
🔹 7. Предложения (в терминах действий)
Цель раздела:
Превратить уроки в конкретные, измеримые шаги, которые исключат повторение проблем.
Правила:
- Каждое действие — SMART: конкретное, назначено ответственному, с дедлайном.
- Не должно быть общих фраз вроде «быть внимательнее».
- Действия могут касаться: чек-листов, ТЗ, обучения, документации, ПО, сборки.
Пример:
- Добавить в чек-лист предпроектного обследования пункт: «Уточнить количество кодов за такт для каждой линии и каждой номенклатуры»
— Ответственный: Руководитель проекта
— Срок: до 30.11.2025
- Разработать универсальный шаблон ТЗ для дуплекс-машин, включающий требования к фиксации пленки и доступу к датчикам
— Ответственный: В. Пупкин
— Срок: 10.12.2025
- Внедрить обязательную проверку распиновки всех разъёмов на этапе сборки оборудования на складе
— Ответственный: Инженер по сборке
— Срок: немедленно
- Добавить в методику обучения клиентов раздел по регулировке смещения печати на ограниченных пространствах
— Ответственный: И. Иванов
— Срок: 15.12.2025
💬 Заключение для команды
Каждый проект — это уникальный опыт, который исчезнет, если его не зафиксировать.
Постмортем — это не отчёт «наверх», а инструмент роста для нас самих.
Чем честнее и подробнее мы его заполним — тем проще, быстрее и спокойнее будет следующий запуск.
🧾 Примеры
- e1cib/data/Справочник.Файлы?ref=96cfd00d194c128211efdb3aece9dd12
- e1cib/data/Справочник.Файлы?ref=96cfd00d194c128211efdb371542a6f8