Содержание
О преимуществах процессного управления, наверное, многие из вас уже слышали. Об успешных кейсах также написано немало статей. Но на практике всё бывает зачастую не так просто и радужно. Исходя из статистики, достаточно много проектов по описанию бизнес-процессов заканчиваются досрочно, так и не достигнув своих целей. Итак, перед вами ТОП-10 причин неудач внедрения исходя из нашего личного опыта:
1. Невнятные цели и нечёткие сроки
Деятельность по описанию бизнес-процессов необходимо рассматривать как проект. А у проекта должен быть руководитель, этапы, чёткие сроки и конкретные измеримые задачи (цели). Само по себе «описание процессов» — не может являться конечной целью проекта.
Несколько хороших примеров постановки целей проекта:
- Регламентировать ответственность сотрудников подразделений логистика и производство, сформировать онлайн базу знаний и нормативных документов.
- Создать подробную бизнес-модель предприятия с целью дальнейшего масштабирования и работы по франшизе.
- Определить требования к компетенциям и личным качествам сотрудников отделов производства и продажи для быстрого поиска и закрытия вакансий, а также адаптации новых сотрудников на рабочем месте.
За каждой такой целью могут стоять конкретные задачи, которые необходимо реализовать. Например, для регламентации ответственности необходимо построить и декомпозировать модели процессов, а затем сгенерировать из них соответствующие регламенты (должностные инструкции, положения и т.п.). Первично оценить выполнение таких целей достаточно просто (речь пока что не идёт об эффективности): вы либо сформировали набор документов, либо нет; требования к вакансиям либо определены, либо нет.
Примеры плохих целей:
- Устранить узкие места в деятельности предприятия
- Повысить конкурентоспособность предприятия на рынке
- Улучшить взаимодействия между сотрудниками
В отличие от предыдущих примеров оценить достижение этих целей практически невозможно. Это скорее побочные эффекты, которые мы можем получить от внедрения процессного подхода, но они не могут быть первичной целью проекта для описания бизнес-процессов.
Отсутствие конкретных измеримых целей, конечного срока и руководителя проекта – гарантия того, что работы не будут выполнены никогда.
2. Отсутствие вовлеченности руководства
Инициатива по внедрению процессного управления должна исходить от руководителя или собственника компании. Или хотя бы должна активно ими поддерживаться. Рядовым сотрудникам описывать бизнес-процессы не интересно, для них это пустая трата времени. У них уже выработались свои привычки, они установили личные связи со своими коллегами и не всегда желают делиться навыками и знаниями с молодыми специалистами, так как видят в них своих потенциальных конкурентов. И их можно понять, ведь отсутствие регламентации и чётких правил позволяет им оставаться «незаменимыми» специалистами, не бояться увольнения и выполнять работу так как удобно лично им.
Руководитель должен показать своим подчинённым важность данного проекта для предприятия, а также обозначить личную ответственность и возможные последствия за нежелание сотрудничать с группой, занимающейся описанием процессов. Также важно дать понять сотрудникам, что целью описания бизнес-процессов является не только желание руководства заставить всех работать больше за те же самые деньги. При построении процессов можно учесть пожелания всех его участников, уменьшить количество конфликтов и переделок, избежать переработок, избавиться от внеплановых совещаний и «летучек».
3. Перекладывание ответственности на консультантов
Даже опытные руководители зачастую не желают вникать в нюансы, выделять и обучать специалистов, которые должны заниматься проектом описания бизнес-процессов на предприятии. Они рассуждают так: «Почему бы не поручить данную задачу консультантам или привлечённому со стороны бизнес-аналитику? Ведь они построили уже множество процессов и наверняка справятся с этой работой лучше нас».
К сожалению, это большая ошибка. Даже самые опытные консультанты, построившие сотни процессов не могут знать все нюансы деятельности вашего предприятия. В лучшем случае, они проведут опрос персонала и построят модель с их слов. А что произойдёт, когда консультанты завершат свою работу? Кто будет поддерживать построенную модель, вносить в неё изменения?
Модель процессов строится не навсегда. Для наилучших результатов рекомендуется постоянно совершенствовать модель с применением цикла Деминга.
При этом важно заметить, что польза от опытных консультантов конечно же есть. Они могут помочь с обучением сотрудников, формированием планов и постановкой целей. На начальных этапах они помогут выделить основные бизнес-процессы и, за счёт своего опыта, избежать типичных ошибок и подводных камней. В идеале консультанты должны сопровождать проект до полного его внедрения.
Тем не менее, основную работу по описанию бизнес-процессов должны выполнять сотрудники предприятия, которое внедряет данный проект. Из нашей практики, ни один проект, в котором консультанты выполняли все работы самостоятельно, без участия руководства и специалистов от предприятия, нельзя назвать успешным.
4. Недостаточный уровень зрелости предприятия
Вот вам реальный пример из нашей практики. Руководитель одного производственного предприятия обратился к нам за помощью. Проблемы стандартные: сотрудники работают неэффективно, перекладывают ответственность друг на друга, заказы срываются, клиенты не довольны. Было решено выполнить проект по описанию бизнес-процессов с целью регламентации ответственности и внедрения простой системы контроля.
Но в результате этой деятельности большинство сотрудников решило уволиться. Оказалось, что все они получали минимальный оклад, а работали только потому, что имели возможность дополнительного заработка, делая часть заказов «налево». Оперативно найти им замену не удалось, так как предложение руководителя на рынке труда было неконкурентоспособно, ведь на соседнем заводе платят в 2,5 раза больше.
Какая мораль данного кейса? Вы, как руководитель, можете требовать от своих подчинённых «нормальной» работы только в случае, если предлагаете им «нормальные» условия труда и оплаты. Разумеется, уровень зрелости предприятия измеряется не только окладами подчинённых. Предприятие, как минимум, должно уже иметь конкурентоспособный продукт или услугу на рынке, а также сформировавшийся коллектив из 20-30 сотрудников, как минимум. В случае, если вы только начинаете свою деятельность и не определили основной вид деятельности, а при этом с вами работает только жена, ваш друг детства (подробнее о родственниках чуть ниже) и наёмный бухгалтер, то думать об описании бизнес-процессов вам ещё рано.
5. Построение модели под конкретных людей (родственников/друзей и т.п.)
Важно понимать, что в моделируемой бизнес-модели предприятия первичны именно процессы, которые строятся для достижения заданных целей, а сотрудники – это ресурс, который необходим для эффективного выполнения данных процессов. Если на предприятии появляется сотрудник, который работает неэффективно, то у вас есть следующий выбор:
- Перевести сотрудника на другую должность, которая соответствует его навыкам и личным качествам;
- Оправить сотрудника на дополнительное обучение;
- Уволить сотрудника;
А что делать, если этот неэффективный сотрудник чей-то друг/сват/брат? В лучшем случае – такому сотруднику найдут такую работу, где он не будет мешать остальным. А в худшем – поставят руководить подразделением или создадут под него целую отдельную бизнес-структуру.
Кейс из нашей практики: описывая бизнес-процессы небольшого предприятия мы обнаружили, что должность «заместитель главного маркетолога» практически ничего не делает. Всю основную работу выполняют либо подчинённые, либо руководитель подразделения. Наше предложение сократить данную должность, либо распределить ответственность за текущие работы более равномерно было проигнорировано, так как данную должность занимала двоюродная сестра директора из другого города. Вместо этого, для создания видимости, на данную должность были возложены дополнительные ненужные и дублирующие функции абстрактного анализа и контроля. Естественно, ни о каком эффективном построении бизнес-модели в данном случае не может быть и речи.
6. Нежелание руководства делегировать ответственность
Обычно одной из целей проекта по описанию бизнес-процессов является освобождение руководства от «текучки». Но что делать, если директор не готов делегировать часть полномочий на нижестоящих сотрудников, а хочет всё контролировать сам. Замыкая все ключевые задачи на себя, он сам становится узким местом бизнес-процессов своего предприятия.
Как правило, такие руководители жалуются на недостаток свободного времени, в их кабинет всегда выстраивается очередь, а телефон звонит каждые несколько минут. Описание бизнес-процессов и распределение ответственности за функции может решить данную проблему, но только в том случае, если руководитель сам готов делегировать часть ответственности своим подчинённым и заняться стратегическим планированием и развитием бизнеса.
К сожалению, не все руководители готовы пойти на данный шаг, в нашей практике были примеры, когда директор продолжал координировать все работы вручную в обход установленных правил и регламентов работы. В итоге построенные схемы бизнес-процессов не работали, а предприятие продолжало работать точно также, как и до внедрения процессного подхода к управлению.
7. Саботаж со стороны наёмных сотрудников
Иногда подчинённый персонал делает вид, что согласен с целями проекта, но делает всё от него возможное, чтобы его сорвать. Например, специально излишне усложняет схемы собственной работы, даёт ложную информацию и сроках выполнения своих функций, отказывается принимать на себя ответственность за выполнение части работ.
Данная проблема возникает как следствие из уже описанных в предыдущих пунктах проблем: недостаточной вовлеченности руководства и перекладывания ответственности за проект по описанию бизнес-процессов на внештатных специалистов. Обмануть привлечённого консультанта намного проще, ведь он не знает специфику работы предприятия. Но если в проекте участвует руководство, то соврать или исказить информацию так просто уже не выйдет.
К сожалению, бывают случаи, когда сотрудники в сговоре с руководителями своих подразделений целенаправленно и довольно успешно зарывают проект: сначала специально описывают схемы бизнес-процессов недостаточно точно, а затем принципиально срывают работы придерживаясь несовершенных алгоритмов, заложенных в бизнес-процессы, чтобы показать, что весь этот процессный подход – полная ерунда и стало только хуже. В итоге предприятию приходится либо уволить таких сотрудников, либо отказаться от проекта и вернуться к ручному управлению. Естественно, наилучший вариант – вовремя предотвратить подобные действия сотрудников максимальным вовлечением и участием руководителей в проекте.
8. Перфекционизм и стремление к совершенству
Прочитав множество литературы и прослушав специализированные тренинги по процессному управлению, многие сотрудники начинают думать о бизнес-процессах как о чём-то чрезвычайно сложном и непонятном. Ответственный специалист пытается следовать всем рекомендациям и с нуля выстроить совершенную бизнес-модель, идеально распределив ответственность и загрузку персонала. При этом он ставит целью решить сразу множество задач: и распределить ответственность за функции, и пронормировать все работы, и определить требования к компетенциям для каждой функции для дальнейшего подбора персонала. Переходя к моделированию следующего процесса, он вдруг понимает, что утверждённый ранее процесс можно усовершенствовать и возвращается к нему. В итоге проект по описанию процессов затягивается, участники теряют терпение, а уже построенные графические диаграммы теряют свою актуальность.
Наша практика показывает, что проекты описания бизнес-процессов, которые длятся больше года, обычно заканчиваются неудачей. Важно понять, что моделирование и улучшение бизнес-процессов – это не разовая задача, а постоянная работа. Поэтому ничего страшного не случится, если модели процессов на первом этапе выйдут несовершенными. Важно получить обратную связь и со временем внести соответствующие правки. Не пытайтесь сразу предусмотреть всё, если в каком-то процессе возникают сбои – детализируйте его при необходимости.
Если на данном этапе развития вашего предприятия у вас всё ещё не сформирована оргструктура и ответственность за большинство работ не распределена, то начните с решения данных задач. Не пытайтесь сразу «перепрыгнуть» через несколько уровней зрелости и внедрить постоянный контроль и совершенствование процессов с вовлечением всех сотрудников предприятия, созданием отделов орг. развития и процессных офисов. Двигайтесь к цели постепенно. Попытка прыгнуть с места выше головы – частая причина провалов проектов по описанию бизнес-процессов.
9. Ложные надежды и ожидания
Давайте будем откровенны, описание бизнес-процессов – это не панацея от всех бед. Если ваше предприятие в глубоком кризисе, ваши товары никто не покупает, а предлагаемые услуги больше не нужны на рынке, то никакой процессный подход вам не поможет. Вы можете оптимизировать свои процессы по времени, снизить издержки и количество брака, но, если в вашей бизнес-модели заложены стратегическое недочёты, то это не принесёт желаемого результата.
Другими словами, даже самая совершенная бизнес-модель не позволит вам продать песок в пустыне, а эскимосам — лёд. Чтобы избежать будущих разочарований, важно определить круг проблем своей организации и убедиться, что выбранный инструмент способен их решить.
Проект по описанию бизнес-процессов не увеличит ваши продажи, не выведет вас на новые рынки и не привлечёт новых партнёров. Но он может предоставить нужную руководителю информацию, которая позволит решить эти проблемы принимая правильные стратегические решения.
10. Нежелание обучаться/читать руководство пользователя и методики
Конечно читать руководство пользователя скучно, а проходить обучение – не интересно. Но знаете, что ещё менее интересно? Построить множество бизнес-процессов и лишь после этого понять, что выбранный программный продукт не поддерживает подобное расположение блоков и для полноценной работы необходимо описать бизнес-процессы заново. Или вот вам ещё один пример из нашей практики: пользователь распределял ответственность за функции бизнес-процессов не на должности, а на физических лиц и понял это только после попытки сформировать должностную инструкцию. После этого, начал строить дерево оргструктуры заново, меняя походу ответственность за процессы, но со временем сдался и создал новую базу данных, потеряв несколько недель своей работы.
Из этого кейса следует простой вывод: перед описанием бизнес-процессов необходимо хотя бы минимально ознакомиться с возможностями и методологией моделирования бизнес-процессов того программного продукта, с которым вы планируете работать. Если вы до этого строили бизнес-процессы в CRM-системе или системе документооборота, то этот опыт хоть и будет полезен, но не всегда применим к системам бизнес-моделирования, ведь у них разные цели и задачи. Если не желаете самостоятельно изучать документацию, то пройдите хотя бы минимальное онлайн-обучение или посмотрите видеоролики.
Вывод: описывать или не описывать процессы?
Заниматься описанием ради описания процессов однозначно не стоит. Вместо этого – поставьте конкретную измеримую цель, которую вы хотите достигнуть, реально оценив текущий уровень зрелости своего предприятия. Если вы не руководитель, убедитесь, что топ-менеджмент и/или собственник полностью поддерживает вашу инициативу и добейтесь понимания наёмных сотрудников. Будьте готовы к тому, что с некоторыми сотрудниками придётся попрощаться, а «пристроенные» на хлебные должности родственники вас возненавидят. При всех описанных сложностях важно понимать, что альтернативного пути развития крупных и средних предприятий на сегодняшний день не существует. Рано или поздно ручная координация работ сделает невозможным или неэффективным масштабирование вашего бизнеса.
Автор: Петров Дмитрий
Источник: материалы сайта fox-manager.com.ua
