Недавно я работал над проектом для одной компании: описывал их бизнес-процессы и строил BPMN-карту. Изначально все, включая руководство, были уверены: «У нас всё просто и понятно». Но реальность оказалась интереснее.
1. «Просто» — не значит «понятно»
Когда я начал интервьюировать сотрудников по отдельности (чтобы избежать перепалок и давления), выяснилось, что:
• Один и тот же процесс разные специалисты описывали совершенно по-разному.
• Были моменты, когда люди даже называли одни и те же этапы разными словами – и это создавало путаницу в работе.
• Взаимное недопонимание между отделами иногда было настолько явным, что некоторые сотрудники даже не знали, кто за что отвечает на стыке процессов.
Оказалось, что «просто» только на первый взгляд. На деле — запутанные цепочки действий, дублирование функций и зоны неопределённости, где решения принимались «как получится».
2. Описание процессов — не повод для наказания, а возможность улучшений
Когда процессы начали фиксировать на бумаге, то всплыли недочёты. Вот пару, казалось бы, безобидных примеров:
1) одни работники ожидают, что им должны писать в одной программе, а другие пишут другой или вообще предпочитают звонить;
2) одни считают, что клиента встречают, а другие считают, что ему говорят куда надо пройти.
С одной стороны это кажется, что какая разница в где писать или встречают ли клиента? Но на деле оказывается, что те, что ожидают информацию в другой программе, теряют время на перенос информации в нужное им место. А бродящие клиенты могут так и не дойти до ответственного специалиста или будут недовольны, что должны «путаться в лабиринтах».
Но тут хочу отметить важный момент: если руководители используют такое описание для поиска виноватых, а не для оптимизации — сотрудники начинают бояться. Это не редкое явление, когда работники не получили гарантий от руководства, что не будут наказаны.
Так и произошло: часть людей, с которыми я уже общался, стали менять показания, опасаясь, что их откровенность обернётся проблемами. Вместо «как есть» — начали рассказывать «как должно быть».
Вывод:
• Честное описание процессов — это инструмент роста, а не способ контроля.
• Если сотрудники боятся говорить правду — систему крайне тяжело улучшить.
• Лучше поощрять открытость, чем наказывать за найденные ошибки.
В итоге мы зафиксировали реальное положение дел, выявили точки роста и построили BPMN-схему, которая помогла компании увидеть процессы целиком и начать их оптимизацию.
А главное — после разъяснений руководства, что цель не «наказать», а «сделать лучше», сотрудники снова стали более открытыми.
Ваш опыт похож? Сталкивались с тем, что процессы оказались сложнее, чем казались?
#Кейсы
