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