В нашей стране давно и прочно закрепилось правило: небольшим компаниям не нужна системная работа, измерение эффективности и прочие KPI.
А что же нужно?
- Грамотные и мотивированные исполнители.
- Руководитель, постоянно контролирующий их работу.
- Клиенты, которые рекомендуют компанию «по сарафану» своим друзьям и партнерам.
- Сайт в интернете и реклама в поисковиках.
Выстраивание бизнес-процессов в таких компаниях всегда считалось бесполезным занятием, а приглашение для этой задачи сторонних экспертов – деньги на ветер. Но в последние 2-3 года ситуация меняется и тому есть важные причины.
Чем отличается процессный подход от функционального
Для начала кратко сравним оба подхода.
Процессный подход рассматривает всю деятельность организации как набор связанных бизнес-процессов. Бизнес-процесс – последовательность действий, направленная на получение заданного результата для организации. Например: прием заявки от клиента, закупка запчастей, согласование договора, выставление счета.
В рамках бизнес-процесса могут взаимодействовать сотрудники разных отделов, которым не требуется для этого взаимодействия согласования непосредственных руководителей. Их работа четко определена регламентами и должностными инструкциями на уровне всей компании. Каждый сотрудник отвечает за решение определенных задач, а руководитель отдела является «владельцем ресурсов», отвечающим за подготовку, мотивацию своих сотрудников и их эффективное взаимодействие. В рутинную работу руководитель не вмешивается без крайней необходимости.
При функциональном подходе гораздо меньше «горизонтальных» взаимодействий между сотрудниками разных отделов. Как правило, эти взаимодействия происходят через руководителей и требуется их согласование для использования ресурсов отдела. Распределения задач между сотрудниками на уровне компании не существует, только между отделами. Руководители отделов сильно вовлечены в оперативную работу. Они по каждой задаче сами назначают исполнителей и несут ответственность за результат. Иногда их приоритеты не совпадают с интересами других отделов, что порождает конфликты.
Как зарождается функциональный подход в бизнесе
Он появляется «по умолчанию», когда владелец бизнеса, не способный более выполнять все задачи самостоятельно, начинает нанимать людей.
Приведу пример из жизни. Мой товарищ занимался ремонтом катеров и у него это хорошо получалось. По рекомендациям пошли заказы от новых клиентов и в какой-то момент от части заказов пришлось отказываться из-за нехватки времени. Он взял в помощь механика для выполнения ремонтов, потом еще одного, сейчас задумывается о найме менеджера по запчастям.
На каждого нового сотрудника он тратил очень много времени. Обучал его, показывал, как нужно работать с клиентами, как важно выполнять свои обязательства и иногда делать даже немного больше, чтобы клиент оставался доволен. Фактически он пытался «скопировать» главные принципы своей работы, принесшие ему успех, и «загрузить» их в наемного сотрудника. Иногда новые сотрудники уходили и для моего товарища это была настоящая катастрофа.
В итоге ему удалось собрать «костяк» команды из трех человек, но дальше он решил обучением новичков не заниматься и передал эти задачи опытным сотрудникам. Теперь уже они «загружают копии своей работы» в новых сотрудников.
В чем проблемы функционального подхода
Что бывает, когда делаешь копию с копии документа? Правильно, качество ухудшается, появляются ошибки. И так происходит в большинстве компаний. Основная проблема функционального подхода – новым сотрудникам не дается четких инструкций «на все случаи жизни». Передается скорее общее видение в выполнении задач и какие-то элементы «исходного кода компании», сохранившиеся еще с того момента, когда она только зарождалась и владелец бизнеса сам обучал сотрудников.
Но с ростом бизнеса появляются новые задачи, а способы их решения передаются на откуп вновь принятым сотрудникам, которые, в лучшем случае, согласовывают их с руководителями – «доверенными лицами» владельца бизнеса. А чаще просто делают свою работу как умеют, на основе своего собственного опыта.
Все меньше и меньше становится «исходного кода» компании в каждом новом поколении сотрудников. Все больше приходится руководителям контролировать их работу, чтобы компания не потеряла свою индивидуальность и конкурентоспособность. При этом контроль чаще включается как реакция на какой-то прецедент, вызвавший проблему с клиентом и на примере этого прецедента руководители показывают сотрудникам, чего от них хотят. Чаще всего в виде «разбора полетов».
Но большинство клиентов не жалуются руководителям, а начинают искать альтернативных поставщиков. Поэтому находить проблемы в работе с клиентами только на основе их обращений очень затруднительно.
Если отсутствует постоянная связь руководителя с подчиненными, то сотрудники не будут по своей инициативе просить советов в работе у того, кто увлекается «разбором полетов», а руководитель не узнает, что происходит «на земле». Поэтому и говорят, что большинство хороших идей губит плохая реализация. Все потому что владелец бизнеса создает новые идеи для той компании, которой уже не существует.
Возникают и другие проблемы. Все сложнее и сложнее найти подходящих руководителей отделов из-за отсутствия четкого описания их работы. Появляются «незаменимые сотрудники», которым приходится много платить. И в какой-то момент руководство решает – хватит. Нужно выделить время, обновить все должностные инструкции, четко описать обязанности каждого, поставить индивидуальные цели и привязать их к мотивации. Это первый шаг к необходимой бюрократизации в хорошем смысле этого слова.
Такие ситуации повторяются 2-3 раза, иногда с длительными перерывами, прежде чем компания решится на использование процессного подхода с регулярным пересмотром и обновлением ключевых бизнес-процессов. Должностные инструкции и регламенты при этом могут создаваться и обновляться автоматически, если компания использует подходящие программы для моделирования. А благодаря интернет-порталу эти документы будут всегда доступны всем сотрудникам и всегда актуальны.
Почему процессный подход стал привлекать малый бизнес
Процессный подход был интересен «повзрослевшим» компаниям. Но в последние два года я замечаю тренд на его использование и в малом бизнесе. Некоторые компании обращаются к нам с просьбой спроектировать бизнес-процессы и посчитать финансовую модель для бизнеса, который только создается. И причин здесь несколько:
- Опытные руководители сразу хотят зафиксировать все специфические процессы, отличающие компанию от конкурентов в виде диаграмм, чтобы избежать «ошибок при копировании». При этом они хотят с самого начала выстроить работу так, чтобы им не приходилось «погружаться в операционку» и своим примером обучать каждого сотрудника. Для большинства процессов можно использовать отраслевые шаблоны, а ключевые процессы – дифференциаторы, по которым нужна обратная связь и развитие, закладываются как базовые на основе лучших практик и регулярно обновляются исполнителями, согласовываются руководителями, а после принимаются в работу в качестве новых стандартов. И чтобы такой подход работал, дополнительно проектируются процессы по развитию бизнеса, связанные с KPI и мотивацией исполнителей.
- Использование IT-систем для автоматизации процессов сейчас закладывается еще на этапе проектирования организации. Они позволяют собирать аналитику о работе компании, выстраивать удобные коммуникации с клиентами и исполнителями, сокращать потери времени сотрудников – а это обязательный и крайне важный элемент любого бизнеса. Без них компания не может конкурировать.
IT-системы не понимают функционального подхода. Любое взаимодействие сотрудников между собой или с клиентами рассматривается их алгоритмами как процесс, где после срабатывания триггера – получения заявки от клиента, наступления времени технического обслуживания или другого события – каждый сотрудник выполняет свои задачи по заявке и передает работу другому вне зависимости от того, в каком отделе он работает.
От получения заявки клиента на ремонт до ее закрытия с ней работают разные специалисты: менеджеры, диспетчеры, кладовщики, техники и бухгалтера. Каждый сотрудник добавляет ценность на своем этапе, а IT-система фиксирует время работы и отслеживает, чтобы сотруднику дальше по цепочке была передана вся необходимая информация.
Вывод
- Чтобы не потерять конкурентоспособность сервисным компаниям приходится внедрять IT-системы. Без них сложно выполнить анализ и улучшение существующих бизнес-процессов, сократить потери времени и снизить себестоимость.
- IT-системы не понимают функционального подхода, для их внедрения требуется техническое задание, основу которого составляет описание процессов и KPI, которые система должна измерять и выводить в виде отчетов. При наличии актуальных схем бизнес-процессов, правильно рассчитанной загрузке и правильной мотивации сотрудников, автоматизация бизнес-процессов не представляется сложной задачей.
- Процессный подход стал актуальным для малого бизнеса из-за необходимости внедрения IT-систем и благодаря повышению «уровня зрелости» руководителей, которые стремятся меньше времени тратить на рутинные задачи и больше – на развитие бизнеса, работу с клиентами и сотрудниками.
Читайте также:
Интересно, что в в этом фрагменте нет ни слова ни о малом бизнесе, ни о специфике сервисных компаний, а будущие процессы кем-то проектируются и моделируются с нуля. Что-то масштабное на тему Change Management, причем практически с самых первых шагов.
С таким подходом можно согласиться, если у Вас - как приглашённого исполнителя - есть необходимые опыт и ресурсы, а заказчик предоставляет всю необходимую информацию и готов к долговременному сотрудничеству. Но это уже слишком далеко от содержания статьи.
Тот же вопрос, что и выше - как в процессе автоматизации получилось, что в сервисной компании процессы отдельно, а системы отдельно?
Разговор об интегрированных системах, их проектировании, функционале, внедрении, развитии, эксплуатации и поддержке должен начинаться намного раньше. И это не беседа на 5 минут за чашкой кофе.
Процессы моделируются с нуля для вновь создаваемой компании. И по крайней мере вначале это малый бизнес. Для существующей организации процессы по итогам интервью с сотрудниками записываются в виде текста, потом переносятся в Business Studio в виде диаграмм "как есть", детализируются. Указывается время выполнения каждой функции и исполнители. Строится оргструктура, указывается зарплата исполнителей и рабочее время. Далее происходит имитация выполнения процессов, программа рассчитывает загрузку исполнителей, использование ресурсов, стоимость процессов и время выполнения. После имитации строятся процессы "как должно быть" С учётом перераспределения и автоматизации функций перегруженных исполнителей. Снова проводится имитация выполнения и процессы согласовываются с руководством и ключевыми сотрудниками. Это действительно выглядит сложно и долго но на самом деле зависит от компании и количества моделируемых процессов. На первом этапе совсем не обязательно моделировать все процессы. Работу бухгалтерии, маркетинга, продаж можно не трогать. Для сервиса важны процессы ремонта, ТО, техподдержки и закупок. После построения этих процессов "как должно быть" уже можно подбирать и внедрять подходящую FSM систему которая будет собирать необходимые данные по загрузке и использованию рабочего времени а также данные по времени выполнения каждого этапа процессов для сравнения план/факт и обсуждения с исполнителем с целью дальнейших улучшений. Потом можно переходить к описанию процессов смежных подразделений и интеграцияим ИТ систем компании. Это один из возможных подходов.
У меня есть необходимый опыт и ресурсы. У заказчика не всегда есть необходимая информация. Но её можно собрать или в ручном режиме или в автоматическом после внедрения FSM. В небольших компаниях с использованием шаблонов и своих наработок всё гораздо быстрее, несколько месяцев на весь проект. В среднем бизнесе это обычно 1-2 года. Сложнее всего преодолеть сопротивление сотрудников и недоверие руководителей, убедить их помогать и выделять время на проект а не цепляться к временным мелким неудобствам.
Я понимаю. Но в статье вы говорите, что прооцеессный хорош, а функциональный плох, во всяком случае создается такое ощущение. Но даже схема, кот. вы предложили в одном из комментов, является одновременно как функциями, так и порядком взаимодействия в ее рамках, оэтому я и говорю, что их нельзя сравнивать )
Вот отличные простые иллюстрации, на мой взгляд, как это выглядит наглядно.
Как правило в сервисных компаниях уже есть различные ИТ системы. Тот же Битрикс или 1С. И плюс к этому Excel, электронная почта, мессенджеры. Так называемая "лоскутная автоматизация" которая не даёт прозрачности и понимания эффективности процессов. Отдельные ИТ системы внедряют для решения локальных задач и на момент внедрения руководители не всегда задумываются об их развитии и интеграциях. Задумываются после регулярного повторения серьёзных проблем. Например, при потере заявки от крупного клиента из-за болезни сотрудники который ей занимался или потому что его письмо попало в спам. Из-за постоянных конфликтов и перекладывании ответственности. Разные могут быть триггеры.
Не совсем так. Скорее всему своё время. Не нужен процессный подход в компании из трёх человек, если только это не стартап который собирается набирать по несколько человек ежемесячно и вырасти к концу года в десять раз, имея при этом необходимые инвестиции и план развития. Я пишу в статье, что порог, при котором процессный подход становится интересным для компаний постепенно снижается.
Второй рисунок - иллюстрация процессного подхода, при котором руководители подразделений являются владельцами ресурсов, отвечают за улучшение процессов, набор, обучение и мотивацию сотрудников но не вовлечены в оперативную работу. Сотрудники подразделений взаимодействуют друг с другом в рамках установленных на уровне компании правил (процессов) без привлечения руководителей.
Первый рисунок мог бы быть иллюстрацией функционального подхода но отсутствуют стрелки, означающие взаимодействие между руководителями подразделений. Коммуникации идут через них.
На рисунке в моём примере приведены схемы процессов с указанием функций и исполнителей из разных подразделений. Выполнение этих функций-ответственность данных конкретных исполнителей.это утверждено на уровне компании. При функциональном подходе руководитель подразделения передаёт задачу другому руководителю подразделения. Тот в свою очередь может назначить исполнителя из числа своих сотрудников или выполнить работу сам. В любом случае он отвечает перед руководством компании за выполнение задачи, а не его сотрудник. И каждый раз способ решения задачи может быть разный и не всегда оптимальный. Потому что директором согласованы (иногда просто в устной форме) только процессы взаимодействия подразделений, но не отдельных сотрудников. Необходимость постоянного вовлечения руководителей подразделений в оперативную работу перегружает их и создаёт "узкие места" в процессах.
Вы снова противоречите сами себе:
и далее:
Получается, что компания из трех человек (например, дизайнерское/туристическое/рекламное/юридическое бюро) может сразу "успокоиться" и не пытаться конкурировать? Разумеется, про автоматизацию тоже нужно забыть, раз процессный подход не нужен?
Странно это всё. Очень странно.
Да, мне тоже кажется, что где-то нарушена логика.
Первый и есть иллюстрация функционального в его классическом виде. Второй – процессного. Но второго не существует без первого ) Куда вы процесс-то наложите? ) Это суть, принципы, а дальше уже можно детализировать по потребностям.
Суп сварить из ничего не получится )
Мне показалось - повсюду.
Проблема статьи - в том, что в ней изначально подменяются понятия процессов и функций, и эта "родовая травма" далее наследуется по всему тексту и комментариям, что приводит к предсказуемой путанице.
В классической теории управления функции менеджмента выступают основой для систематизации управленческих процессов, обеспечивая логическую структуру управления (что прекрасно показано на Ваших диаграммах).
Но вместо рассмотрения собственно функций в статье происходит "заваливание" в функциональные структуры, и начинается обсуждение связей между организационными единицами. А дальше в этот "замес" почему-то попадают должностные инструкции, KPI и заявки клиента на ремонт (вопрос – чего?), приходы/уходы персонала и проч.
Как я понял, статья задумывалась как локальное предложение автора: "Освоил Business Studio – готов принимать заказы исключительно от сервисных компаний". Это нормально, вполне понимаемо: каждый монетизирует, что может.
Но если с уровня сервисных компаний мы уходим "преисполняться в гранях" стратегического менеджмента любого уровня, рассуждаем о страт. сессиях, создании стоимости, управлении изменениями, имитационном/симуляционном моделировании, периметре ответственности топов – на этот уровень статья даже "на носилках не заедет". Как и комментарии. И аргументация: "Я просто стараюсь простыми словами и примерами объяснять сложные проблемы, с которыми сталкиваюсь в работе. Мне кажется это обязанность специалиста консалтинговой компании", - никак не спасает ситуацию: коллеги не раз указали на множественные "нестыковки".
Мне видится, что обязанность сотрудника консалтинговой компании – быть специалистом хотя бы в базовом наборе того, о чем планируется консультировать, а простыми ли словами это будет делаться – вторично. Следует хотя бы изучить мат. часть, прежде чем готовить аналитическую статью для экспертного сообщества – тогда не придется "вилять" в комментариях, рассказывая, что читатель что-то не так понял, и "произошла чудовищная ошибка".