# Что такое Postmortem?
# 🧾 Постмортем после внедрения: как и зачем анализировать каждый запуск

> **Важно:** В нашем контексте «постмортем» — это не про сбой, а про **глубокий разбор завершённого внедрения**. Мы не ищем виноватых. Мы ищем **возможности стать лучше**.

***

## 🔹 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**: конкретное, назначено ответственному, с дедлайном.
*   Не должно быть общих фраз вроде «быть внимательнее».
*   Действия могут касаться: чек-листов, ТЗ, обучения, документации, ПО, сборки.

**Пример:**

> 1.  **Добавить в чек-лист предпроектного обследования пункт**: «Уточнить количество кодов за такт для каждой линии и каждой номенклатуры»
>     — Ответственный: Руководитель проекта
>     — Срок: до 30.11.2025
> 2.  **Разработать универсальный шаблон ТЗ для дуплекс-машин**, включающий требования к фиксации пленки и доступу к датчикам
>     — Ответственный: В. Пупкин
>     — Срок: 10.12.2025
> 3.  **Внедрить обязательную проверку распиновки всех разъёмов на этапе сборки оборудования на складе**
>     — Ответственный: Инженер по сборке
>     — Срок: немедленно
> 4.  **Добавить в методику обучения клиентов раздел по регулировке смещения печати на ограниченных пространствах**
>     — Ответственный: И. Иванов
>     — Срок: 15.12.2025

***

## 💬 Заключение для команды

> Каждый проект — это **уникальный опыт**, который исчезнет, если его не зафиксировать.
> Постмортем — это не отчёт «наверх», а **инструмент роста для нас самих**.
> Чем честнее и подробнее мы его заполним — тем проще, быстрее и спокойнее будет следующий запуск.

## 🧾 Примеры

*   e1cib/data/Справочник.Файлы?ref\=96cfd00d194c128211efdb3aece9dd12
*   e1cib/data/Справочник.Файлы?ref\=96cfd00d194c128211efdb371542a6f8