Сутки на разгрузку: что видно на камерах и не видно в интервью
Разбор лекции по процессному управлению из программы MBA CIO: четыре способа исследовать деятельность — от документации до камер, алгоритм проектирования процесса, верификация против валидации модели, чем нормализация отличается от оптимизации и четыре принципа моделирования.
Владелец нескольких точек, торгующих электроникой и бытовой техникой, пожаловался накануне Нового года на падение спроса. Само по себе это звучит странно: электроника перед Новым годом не падает никогда — даже в самые тяжёлые годы под праздник идёт всплеск.
Смотрели процесс так, как смотрят обычно: интервью с сотрудниками, опросы, разбор регламентов. Всё в порядке.
Поставили камеры. Выяснилось, что фура с товаром разгружается двадцать четыре часа.
Дальше — по шагам, как это получалось. Водитель приезжал вечером, стучался на склад, ему не открывали: людям было лень, да и не слышали. Водитель ложился спать в кабине. Утром снова стучался — на складе ещё никого не было. Уходил завтракать. Возвращался, дозванивался до первого пришедшего, тот шёл искать кладовщиков, разгрузку начинали к обеду и заканчивали к вечеру следующего дня.
Сутки склад стоит — значит, сутки в зале нет товара. В обычные месяцы это незаметно: спрос ровный, полки не выметают. Перед Новым годом люди сметают всё, и отсутствие поставки становится видно на выручке.
Ни один опрос этого бы не показал. Разбираю, как исследуют деятельность на самом деле, — по девятой лекции процессного управления из программы MBA CIO.
Четыре способа посмотреть, как работает деятельность
Способы идут по возрастанию цены и, честно говоря, цинизма по отношению к аналитику.
1. Изучение документации. Первое и самое дешёвое. Здесь есть побочный результат, который стоит отдельно: сам факт отсутствия документации говорит об уровне зрелости. Если на процесс или функцию нет никаких описаний — это уже диагноз, и его можно ставить, не открыв ни одного файла.
2. Фотография рабочего дня. Аналитик находится в помещении, где идёт работа, и записывает, кто что делает. Неделю и больше. Первые дни все стесняются и изображают деятельность, потом привыкают, как к предмету обстановки, — и начинают работать как обычно.
3. Аналитик внутри процесса. Более циничный вариант: аналитика трудоустраивают. Удобная позиция — сопровождение экстраординарных заказов: тех, что делаются потому, что «об этом лично просил владелец». Такой человек по роду занятий проходит через весь процесс и видит все его стыки.
4. Камеры. Крайний способ и самый дорогой: помимо работы аналитика нужно поставить и оплатить оборудование, а камеры должны писать ещё и звук — иначе половина информации теряется. Именно так вскрылась история с фурой: другими способами добиться понимания не удавалось.
Честная оговорка. Наблюдение — не замена разговорам, а дополнение к ним. Интервью даёт представление о том, как деятельность выглядит с точки зрения говорящего: верхнее руководство описывает её так, как оно её видит; сотрудник — так, как ему безопасно рассказать. Наблюдение отвечает на другой вопрос — что происходит фактически. Расхождение между двумя картинами и есть материал для работы.

Алгоритм проектирования целиком
Наблюдение — только первый шаг. Полная последовательность выглядит так.
flowchart TB
A["Исследуем деятельность<br/>документы, наблюдение"] --> B["Моделируем<br/>«как есть»"]
B --> C["Оцениваем модель<br/>верификация или валидация"]
C --> D["Оптимизируем<br/>под выбранный критерий"]
D --> E["Согласуем модель<br/>«как надо»"]
E --> F["Регламентируем<br/>шаг необязательный"]
Первый шаг пропускается, если деятельности раньше не было: изучать нечего, процесс создаётся с нуля.
Последний шаг — регламент, текстовый документ, описывающий процесс, — не обязателен. Модель уже описывает, как выполняется процесс, просто не словами, а картинками. Текст пишут в двух случаях: когда участники не в состоянии читать схемы и когда формы документов требует регулятор. Регламент, вопреки ожиданиям, обычно сложнее для понимания, чем модель. А если он написан — участники должны подтвердить, что понимают его одинаково, и слова в нём должны точно соответствовать модели.
Верификация и валидация: две подписи под моделью
Оценить модель можно двумя способами, и разница между ними принципиальная.
| Верификация | Валидация | |
|---|---|---|
| Что это | подпись участника: «да, мы работаем так» | совпадение прогнозных показателей с реальными |
| Что требует | чтобы участник понял модель | детальную модель и систему имитационного моделирования |
| Как часто применяется | почти всегда | единичные проценты случаев |
Верификация проста: участник читает модель, соглашается, что она адекватна, и подписывается. Обязательное условие — он должен модель понять, иначе подпись ничего не стоит.
Валидация строже: вы подаёте на вход процесса то, что должно подаваться, прогнозируете выходные параметры — и, если по факту получаете спрогнозированное, модель валидна. Способ честнее, но требует такой детализации, которую в реальных проектах почти никогда не делают.
Нормализация — это не оптимизация
Различение, которое стоит держать в голове, когда вам обещают «оптимизировать процессы».
Нормализация — управленческие усилия, направленные на то, чтобы процесс стал управляемее. Убрали лишнее, навели порядок, повысили уровень зрелости. Выходные параметры при этом не меняются.
Оптимизация — перестройка процесса под конкретный критерий. Критериев четыре, и выбирать нужно один:
- скорость — процесс выполняется быстрее;
- качество — меньше брака на выходе;
- себестоимость — процесс дешевле обходится;
- ценность — за результат можно взять с клиента больше.
Критерии конфликтуют. Ускорение может удорожить процесс — и это нормально, если конкурентное преимущество компании держится на скорости. Ненормально другое: браться за оптимизацию, не назвав критерий, — тогда каждый участник будет улучшать своё и результат окажется случайным.
И ещё одно различение внутри оптимизации. Содержательная оптимизация — то, что делает команда процесса, чтобы изменить его параметры. Управление оптимизацией — то, что нужно сделать, чтобы команда за это взялась. Пятнадцати людям недостаточно сказать «поменяйте параметры процесса»; вторая половина работы обычно и оказывается сложнее первой.
Где сегодня помогает AI. Первичное исследование деятельности стало заметно дешевле: расшифровки интервью, логи систем и выгрузки по срокам модель разбирает за минуты и показывает, где данные расходятся с тем, что рассказывают люди. Камеры это не отменяет, но резко сужает участок, на который их имеет смысл ставить.
Зачем вообще моделировать
Прежде чем выбирать нотацию, стоит ответить на вопрос, ради чего вы рисуете. Практических целей всего две:
- Дать представление об объекте тому, кто его никогда не видел. Компания большая и сложная, целиком её никто не наблюдает.
- Создать условия для изменения. Модель — заготовка, на которой перестраивают процесс, прежде чем трогать реальность.
Из цели вытекает то, что определяет всё остальное, — существенные характеристики: что должно быть отражено в модели, а на что можно не смотреть.
| Цель | Что существенно | Что можно игнорировать |
|---|---|---|
| Сократить время выполнения | что делается и сколько времени занимает | кто именно делает |
| Показать зоны ответственности | виды деятельности и точки передачи | время выполнения |
Чем больше существенных характеристик, тем ближе модель к оригиналу — и тем дороже её разработка. Здравый предел очевиден: полностью идентичная модель объекта — это сам объект.
А чем именно рисовать модель, разбираю отдельно: карта нотаций и правила работы с ними — от диаграммы потоков до дорожек.
Четыре принципа, без которых модель врёт
Иерархичность. Систему описывают набором моделей, каждая следующая уточняет предыдущую. Правило жёсткое: сумма декомпозиции равна целому. Если раскрываете элемент — раскрывайте полностью, а не ту его часть, которая интереснее.
Целостность. Все выбранные существенные характеристики отражены для каждого элемента. Отсюда практическое следствие, которое ловит половину ошибок: ни один поток не возникает из воздуха и не исчезает в воздух. У каждого потока — информационного, материального, финансового — есть источник и приёмник.
Множественность. Работает в обе стороны. Одна модель может описывать множество разных систем — так и живут типовые схемы. И наоборот: один объект описывается множеством моделей, потому что смотреть на него можно с разных точек. Нарисуйте комнату изнутри, из коридора и с улицы — получите три разных рисунка одной комнаты, и все три верны.
Разумная реалистичность. Модель должна быть настолько подробной, насколько это нужно для цели, и не подробнее. Здесь же — про относительность аналогии, на которой моделирование вообще держится: автомеханик может сколько угодно возмущаться, что чинит двигатель так же, как кардиолог чинит сердце. Аналогия есть, но она не полная: для полноты пришлось бы перебирать работающий двигатель.

Вывод
Проектирование процесса начинается не с рисования, а с двух вопросов: что происходит на самом деле и ради чего вы это описываете.
Три вещи стоит унести. Опрос показывает картину мира говорящего, наблюдение — факты: если цифры не сходятся с рассказами, смотреть надо глазами, а не переспрашивать. Оптимизация без названного критерия невозможна — скорость, качество, себестоимость или ценность, что-то одно; всё сразу не улучшается. И существенные характеристики определяются целью моделирования, а не полнотой: модель, где отражено всё, стоит столько же, сколько сам объект.
Следующий шаг: возьмите процесс, на который вы жалуетесь, и найдите в нём одно место, о котором вы знаете только со слов исполнителей. Проведите там полдня и просто запишите, что происходит и сколько это занимает. Расхождение с тем, что вам рассказывали, обычно и есть искомая проблема.








Комментарии
Войдите через Telegram, чтобы оставить комментарий:
Пока нет комментариев. Будьте первым.