Сто лет назад Фрэнк и Лилиан Гилбрет нарисовали первые блок-схемы работы, а в 1990 году Майкл Хаммер призвал процессы не автоматизировать, а сносить. Описание делает работу видимой: кто что делает, в каком порядке и с каким итогом. Олег Брагинский и Владислав Иванов разбирают, зачем описывать процессы, кто за них отвечает и когда браться не надо.
Рис. 1. Единая картина вытесняет десяток частных представлений о ходе дела
Что такое описание процессов?
Описание процессов – фиксация того, как работают сотрудники: какие операции выполняют и какие функции несут. Его часто путают с моделированием, хотя первое подробно записывает шаги, а второе обобщает их для взгляда сверху или рисует желаемое будущее.
Процесс – набор действий, создающих продукт или услугу для потребителя. Клиент бывает внешним и внутренним, но есть всегда: без получателя действия не складываются.
При описании выясняют шесть вещей:
- требуемые ресурсы, включая ПО
- входящие сведения и документы
- роли участников или должности
- правила и особенности работ
- результат деятельности
- совершаемые шаги.
На продвинутом уровне добавляют зависимости с другими процессами, время операций, простои между действиями, показатели и стоимость работ. Собранное превращают в схему, а к ней прикладывают матрицу ответственности, регламент, чек-лист и реестр проблем.
Для каталога процессы делят на три вида: управленческие отвечают за планирование, финансы и маркетинг; основные создают продукт и обслуживают клиента; вспомогательные помогают выполнению остальных.
Рис. 2. Стрелки нотации IDEF0 разводят управление, ресурсы, входы и выходы
Зачем описывать процессы?
Описание повышает прозрачность, обнажает проблемы, сокращает потери и готовит дело к автоматизации. Новички входят в дело быстрее, а старожилы перестают спорить о том, как правильно делается привычное.
Схемы – неотъемлемая часть управления качеством и сертификаций, масштабирования, продажи франшиз или самого дела, аудитов и оценки рисков. Они же выручают в переговорах с автоматизаторами, подрядчиками, поставщиками и смежными подразделениями.
В производстве моделирование улучшает повторяемость и предсказуемость. В услугах оно больше про согласованность, готовность к переменам и ясность для клиента.
Кто отвечает за процесс?
Ключевую роль играет владелец процесса – сотрудник, отвечающий за итог. Он привлекает смежников, налаживает связи, действует сквозь структуру и отвечает за шесть вещей:
- изменения – согласование правок и оценка влияния на смежные процессы
- модель процесса – актуальность описания и инструкций
- улучшения – оптимизация или автоматизация шагов
- ресурсы – люди, системы, бюджет и обоснование
- показатели – срок, качество, стоимость
- результат – процесс выполняет цель.
Владельцем не становятся руководитель всех участников, исполнитель, процессный аналитик и хранитель документов. Каждый несёт свою функцию, но ни один не отвечает за единичный процесс и его итог целиком.
Аналитик поддерживает методологически и руками, исполнитель совершает заданные шаги, архивариус удерживает корпоративную библиотеку. Руководитель участников зачастую слишком высоко, да и сотрудники нередко числятся за разными отделами.
Какие полномочия дать владельцу?
Роль должна действовать, а для этого ей нужны четыре права:
- Влиять на участников. Привлекать смежников и спрашивать за исполнение.
- Менять процесс. Предлагать, согласовывать и утверждать правки.
- Отвечать за итог. Держать ответ перед руководством.
- Видеть данные. Получать показатели и отчёты.
Лучший кандидат – руководитель, подходящий по смыслу: его сотрудники заняты в процессе больше прочих, он разбирается в происходящем, а его показатели привязаны к итогу.
Рис. 3. Дорожки нотации BPMN показывают, кто и на каком шаге вступает в дело
Что даёт описание?
Прозрачность и единое понимание. Участники видят одну картину и перестают расходиться в толкованиях. Новички входят в дело быстрее, а инструкции и чек-листы повышают шансы на качественный итог.
Основа для перемен. Нельзя улучшить то, чего не видно. Узкие места, дублирования и потери проявляются при изучении, а рядом встаёт мерило будущего и настоящего.
Готовность к автоматизации. Схема – обязательный документ для передачи в ИТ-систему: разработчик опирается на модель, а не на противоречивые пересказы. Упорядоченный хаос превращается в стройную систему.
Контроль и аудит. Стандартную работу легче отслеживать и оценивать, описание упрощает сертификации, а иногда без него их не пройти. На вопросы «кто отвечает», «за что» и «где записано» находится ответ.
Независимость от звёзд. Знания, приёмы и хитрости переходят из голов отдельных сотрудников в компанию. Незаменимый специалист теряет возможность торговаться увольнением.
В чём недостатки?
Высокая цена. Сбор сведений, интервью, проверка данных и схем – недели работы, которые растягиваются на месяцы. Вовлечённым специалистам приходится выделять время, отрывая его от основного дела и задач.
Скорость устаревания. Реальность меняется быстрее, чем обновляется документация. Устаревшие материалы становятся рассадником разночтений.
Работа в стол. Формализация рождает десятки красивых схем, цветные папки и толстые регламенты. Результат складывают на полку, гордо им хвалятся и забывают.
Сопротивление сотрудников. Описание принимают за усиление надзора или первый шаг к сокращению. Опасения не беспочвенны: реинжиниринг применялся и для этого. Люди расскажут «как положено», а не «как есть».
Границы метода. Творческую, переговорную и исследовательскую работу удаётся описать лишь верхнеуровнево. Точные ступени там не фиксируются, а неформальные договорённости и вовсе остаются за кадром.
Рис. 4. Таблица SIPOC сводит поставщика, вход, шаг, выход и получателя в одну строку
Когда браться за описание?
Постоянные ошибки. Бесконечные переделки, сорванные сроки и потерянные клиенты – верные признаки беспорядка. Непонимание того, какой шаг сломался, служит отличным маркером.
Рост. На стадии расширения нанимают много людей, открывают филиалы и продают франшизы. Управление не поспевает за развитием и потом благодарит за первые шаги к порядку.
Автоматизация. Желание внедрить CRM, ERP или WMS рождает запрос на описание. Без него задуманное не выйдет либо обойдётся дороже и дольше, а итог разочарует.
Кадровые риски. Уход ключевых людей уносит знания и умения. Полное понимание, сосредоточенное у собственника, превращает его в самое дорогое узкое место.
Внешние требования. Регуляторы, аудиторы и сертифицирующие организации просят показать устройство дела. Инвесторы и покупатели тоже хотят видеть кота вне мешка – и цена компании от такой ясности растёт.
Не стоит торопиться там, где бизнес ещё ищет себя, живёт скоростью и частыми опытами. Разовой задаче регламент не нужен, а отсутствие цели – повод не браться.
Чем описывают процессы?
Самый распространённый инструмент – нотация, условный язык для отображения работы. В ходу BPMN, UML, EPC, IDEF0, VSM и VAD. Кроме схем есть табличная запись SIPOC: поставщик, вход, процесс, выход, клиент.
Для системного подхода – архитектуры, иерархии, поддержания актуальности, верных названий участников – существует BPMS, специальное программное обеспечение. Школа траблшутеров пользуется собственной нотацией: граф шагов поверх дорожек участников.
Рис. 5. Участники, шаги и итог «до – после» умещаются на одном листе
Что запомнить?
- Описание фиксирует, как работают сейчас, моделирование обобщает и рисует будущее
- У каждого процесса есть владелец, а у него четыре права, иначе роль бездействует
- Схема – обязательный документ для передачи работы в ИТ-систему
- Описание устаревает быстрее, чем обновляется, и живёт только при воле руководства
- Стартапу мешает, растущей компании помогает, стареющей добавляет бюрократии.