# Сутки на разгрузку: что видно на камерах и не видно в интервью
> Разбор лекции по процессному управлению из программы MBA CIO: четыре способа исследовать деятельность — от документации до камер, алгоритм проектирования процесса, верификация против валидации модели, чем нормализация отличается от оптимизации и четыре принципа моделирования.
Источник: https://blog.uspeshnyy.ru/blog/sutki-na-razgruzku/
Автор: Александр Успешный · blog.uspeshnyy.ru
Опубликовано: 2015-02-21
Теги: MBA, система, аналитика, автоматизация, Процессное управление, Владислав Сирота
---
Владелец нескольких точек, торгующих электроникой и бытовой техникой, пожаловался накануне Нового года на падение спроса. Само по себе это звучит странно: электроника перед Новым годом не падает никогда — даже в самые тяжёлые годы под праздник идёт всплеск.
Смотрели процесс так, как смотрят обычно: интервью с сотрудниками, опросы, разбор регламентов. Всё в порядке.
Поставили камеры. Выяснилось, что **фура с товаром разгружается двадцать четыре часа**.
Дальше — по шагам, как это получалось. Водитель приезжал вечером, стучался на склад, ему не открывали: людям было лень, да и не слышали. Водитель ложился спать в кабине. Утром снова стучался — на складе ещё никого не было. Уходил завтракать. Возвращался, дозванивался до первого пришедшего, тот шёл искать кладовщиков, разгрузку начинали к обеду и заканчивали к вечеру следующего дня.
Сутки склад стоит — значит, сутки в зале нет товара. В обычные месяцы это незаметно: спрос ровный, полки не выметают. Перед Новым годом люди сметают всё, и отсутствие поставки становится видно на выручке.
Ни один опрос этого бы не показал. Разбираю, как исследуют деятельность на самом деле, — по девятой лекции [процессного управления](/blog/svoevremenno-kachestvenno-i-deshevo/) из программы MBA CIO.
## Четыре способа посмотреть, как работает деятельность
Способы идут по возрастанию цены и, честно говоря, цинизма по отношению к аналитику.
**1. Изучение документации.** Первое и самое дешёвое. Здесь есть побочный результат, который стоит отдельно: **сам факт отсутствия документации говорит об уровне зрелости**. Если на процесс или функцию нет никаких описаний — это уже диагноз, и его можно ставить, не открыв ни одного файла.
**2. Фотография рабочего дня.** Аналитик находится в помещении, где идёт работа, и записывает, кто что делает. Неделю и больше. Первые дни все стесняются и изображают деятельность, потом привыкают, как к предмету обстановки, — и начинают работать как обычно.
**3. Аналитик внутри процесса.** Более циничный вариант: аналитика трудоустраивают. Удобная позиция — сопровождение экстраординарных заказов: тех, что делаются потому, что «об этом лично просил владелец». Такой человек по роду занятий проходит через весь процесс и видит все его стыки.
**4. Камеры.** Крайний способ и самый дорогой: помимо работы аналитика нужно поставить и оплатить оборудование, а камеры должны писать ещё и звук — иначе половина информации теряется. Именно так вскрылась история с фурой: другими способами добиться понимания не удавалось.
**Честная оговорка.** Наблюдение — не замена разговорам, а дополнение к ним. Интервью даёт представление о том, как деятельность выглядит **с точки зрения говорящего**: верхнее руководство описывает её так, как оно её видит; сотрудник — так, как ему безопасно рассказать. Наблюдение отвечает на другой вопрос — что происходит фактически. Расхождение между двумя картинами и есть материал для работы.
## Алгоритм проектирования целиком
Наблюдение — только первый шаг. Полная последовательность выглядит так.
Первый шаг пропускается, если деятельности раньше не было: изучать нечего, процесс создаётся с нуля.
Последний шаг — регламент, текстовый документ, описывающий процесс, — **не обязателен**. Модель уже описывает, как выполняется процесс, просто не словами, а картинками. Текст пишут в двух случаях: когда участники не в состоянии читать схемы и когда формы документов требует регулятор. Регламент, вопреки ожиданиям, обычно **сложнее** для понимания, чем модель. А если он написан — участники должны подтвердить, что понимают его одинаково, и слова в нём должны точно соответствовать модели.
## Верификация и валидация: две подписи под моделью
Оценить модель можно двумя способами, и разница между ними принципиальная.
| | Верификация | Валидация |
|---|---|---|
| Что это | подпись участника: «да, мы работаем так» | совпадение прогнозных показателей с реальными |
| Что требует | чтобы участник понял модель | детальную модель и систему имитационного моделирования |
| Как часто применяется | почти всегда | единичные проценты случаев |
**Верификация** проста: участник читает модель, соглашается, что она адекватна, и подписывается. Обязательное условие — он должен модель **понять**, иначе подпись ничего не стоит.
**Валидация** строже: вы подаёте на вход процесса то, что должно подаваться, прогнозируете выходные параметры — и, если по факту получаете спрогнозированное, модель валидна. Способ честнее, но требует такой детализации, которую в реальных проектах почти никогда не делают.
## Нормализация — это не оптимизация
Различение, которое стоит держать в голове, когда вам обещают «оптимизировать процессы».
**Нормализация** — управленческие усилия, направленные на то, чтобы процесс стал **управляемее**. Убрали лишнее, навели порядок, повысили уровень зрелости. Выходные параметры при этом не меняются.
**Оптимизация** — перестройка процесса под конкретный критерий. Критериев четыре, и выбирать нужно один:
- **скорость** — процесс выполняется быстрее;
- **качество** — меньше брака на выходе;
- **себестоимость** — процесс дешевле обходится;
- **ценность** — за результат можно взять с клиента больше.
Критерии конфликтуют. Ускорение может удорожить процесс — и это нормально, если конкурентное преимущество компании держится на скорости. Ненормально другое: браться за оптимизацию, не назвав критерий, — тогда каждый участник будет улучшать своё и результат окажется случайным.
**И ещё одно различение внутри оптимизации.** Содержательная оптимизация — то, что делает команда процесса, чтобы изменить его параметры. Управление оптимизацией — то, что нужно сделать, чтобы команда за это взялась. Пятнадцати людям недостаточно сказать «поменяйте параметры процесса»; вторая половина работы обычно и оказывается сложнее первой.
**Где сегодня помогает AI.** Первичное исследование деятельности стало заметно дешевле: расшифровки интервью, логи систем и выгрузки по срокам модель разбирает за минуты и показывает, где данные расходятся с тем, что рассказывают люди. Камеры это не отменяет, но резко сужает участок, на который их имеет смысл ставить.
## Зачем вообще моделировать
Прежде чем выбирать нотацию, стоит ответить на вопрос, ради чего вы рисуете. Практических целей всего две:
1. **Дать представление об объекте тому, кто его никогда не видел.** Компания большая и сложная, целиком её никто не наблюдает.
2. **Создать условия для изменения.** Модель — заготовка, на которой перестраивают процесс, прежде чем трогать реальность.
Из цели вытекает то, что определяет всё остальное, — **существенные характеристики**: что должно быть отражено в модели, а на что можно не смотреть.
| Цель | Что существенно | Что можно игнорировать |
|---|---|---|
| Сократить время выполнения | что делается и сколько времени занимает | кто именно делает |
| Показать зоны ответственности | виды деятельности и точки передачи | время выполнения |
Чем больше существенных характеристик, тем ближе модель к оригиналу — и тем дороже её разработка. Здравый предел очевиден: полностью идентичная модель объекта — это сам объект.
А чем именно рисовать модель, разбираю отдельно: [карта нотаций и правила работы с ними](/blog/tridcat-pyat-znachkov/) — от диаграммы потоков до дорожек.
## Четыре принципа, без которых модель врёт
**Иерархичность.** Систему описывают набором моделей, каждая следующая уточняет предыдущую. Правило жёсткое: **сумма декомпозиции равна целому**. Если раскрываете элемент — раскрывайте полностью, а не ту его часть, которая интереснее.
**Целостность.** Все выбранные существенные характеристики отражены для каждого элемента. Отсюда практическое следствие, которое ловит половину ошибок: **ни один поток не возникает из воздуха и не исчезает в воздух**. У каждого потока — информационного, материального, финансового — есть источник и приёмник.
**Множественность.** Работает в обе стороны. Одна модель может описывать множество разных систем — так и живут типовые схемы. И наоборот: один объект описывается множеством моделей, потому что смотреть на него можно с разных точек. Нарисуйте комнату изнутри, из коридора и с улицы — получите три разных рисунка одной комнаты, и все три верны.
**Разумная реалистичность.** Модель должна быть настолько подробной, насколько это нужно для цели, и не подробнее. Здесь же — про относительность аналогии, на которой моделирование вообще держится: автомеханик может сколько угодно возмущаться, что чинит двигатель так же, как кардиолог чинит сердце. Аналогия есть, но она не полная: для полноты пришлось бы перебирать работающий двигатель.
## Вывод
Проектирование процесса начинается не с рисования, а с двух вопросов: что происходит на самом деле и ради чего вы это описываете.
Три вещи стоит унести. **Опрос показывает картину мира говорящего, наблюдение — факты**: если цифры не сходятся с рассказами, смотреть надо глазами, а не переспрашивать. **Оптимизация без названного критерия невозможна** — скорость, качество, себестоимость или ценность, что-то одно; всё сразу не улучшается. И **существенные характеристики определяются целью моделирования**, а не полнотой: модель, где отражено всё, стоит столько же, сколько сам объект.
**Следующий шаг:** возьмите процесс, на который вы жалуетесь, и найдите в нём одно место, о котором вы знаете только со слов исполнителей. Проведите там полдня и просто запишите, что происходит и сколько это занимает. Расхождение с тем, что вам рассказывали, обычно и есть искомая проблема.