В нашей стране давно и прочно закрепилось правило: небольшим компаниям не нужна системная работа, измерение эффективности и прочие KPI.
А что же нужно?
- Грамотные и мотивированные исполнители.
- Руководитель, постоянно контролирующий их работу.
- Клиенты, которые рекомендуют компанию «по сарафану» своим друзьям и партнерам.
- Сайт в интернете и реклама в поисковиках.
Выстраивание бизнес-процессов в таких компаниях всегда считалось бесполезным занятием, а приглашение для этой задачи сторонних экспертов – деньги на ветер. Но в последние 2-3 года ситуация меняется и тому есть важные причины.
Чем отличается процессный подход от функционального
Для начала кратко сравним оба подхода.
Процессный подход рассматривает всю деятельность организации как набор связанных бизнес-процессов. Бизнес-процесс – последовательность действий, направленная на получение заданного результата для организации. Например: прием заявки от клиента, закупка запчастей, согласование договора, выставление счета.
В рамках бизнес-процесса могут взаимодействовать сотрудники разных отделов, которым не требуется для этого взаимодействия согласования непосредственных руководителей. Их работа четко определена регламентами и должностными инструкциями на уровне всей компании. Каждый сотрудник отвечает за решение определенных задач, а руководитель отдела является «владельцем ресурсов», отвечающим за подготовку, мотивацию своих сотрудников и их эффективное взаимодействие. В рутинную работу руководитель не вмешивается без крайней необходимости.
При функциональном подходе гораздо меньше «горизонтальных» взаимодействий между сотрудниками разных отделов. Как правило, эти взаимодействия происходят через руководителей и требуется их согласование для использования ресурсов отдела. Распределения задач между сотрудниками на уровне компании не существует, только между отделами. Руководители отделов сильно вовлечены в оперативную работу. Они по каждой задаче сами назначают исполнителей и несут ответственность за результат. Иногда их приоритеты не совпадают с интересами других отделов, что порождает конфликты.
Как зарождается функциональный подход в бизнесе
Он появляется «по умолчанию», когда владелец бизнеса, не способный более выполнять все задачи самостоятельно, начинает нанимать людей.
Приведу пример из жизни. Мой товарищ занимался ремонтом катеров и у него это хорошо получалось. По рекомендациям пошли заказы от новых клиентов и в какой-то момент от части заказов пришлось отказываться из-за нехватки времени. Он взял в помощь механика для выполнения ремонтов, потом еще одного, сейчас задумывается о найме менеджера по запчастям.
На каждого нового сотрудника он тратил очень много времени. Обучал его, показывал, как нужно работать с клиентами, как важно выполнять свои обязательства и иногда делать даже немного больше, чтобы клиент оставался доволен. Фактически он пытался «скопировать» главные принципы своей работы, принесшие ему успех, и «загрузить» их в наемного сотрудника. Иногда новые сотрудники уходили и для моего товарища это была настоящая катастрофа.
В итоге ему удалось собрать «костяк» команды из трех человек, но дальше он решил обучением новичков не заниматься и передал эти задачи опытным сотрудникам. Теперь уже они «загружают копии своей работы» в новых сотрудников.
В чем проблемы функционального подхода
Что бывает, когда делаешь копию с копии документа? Правильно, качество ухудшается, появляются ошибки. И так происходит в большинстве компаний. Основная проблема функционального подхода – новым сотрудникам не дается четких инструкций «на все случаи жизни». Передается скорее общее видение в выполнении задач и какие-то элементы «исходного кода компании», сохранившиеся еще с того момента, когда она только зарождалась и владелец бизнеса сам обучал сотрудников.
Но с ростом бизнеса появляются новые задачи, а способы их решения передаются на откуп вновь принятым сотрудникам, которые, в лучшем случае, согласовывают их с руководителями – «доверенными лицами» владельца бизнеса. А чаще просто делают свою работу как умеют, на основе своего собственного опыта.
Все меньше и меньше становится «исходного кода» компании в каждом новом поколении сотрудников. Все больше приходится руководителям контролировать их работу, чтобы компания не потеряла свою индивидуальность и конкурентоспособность. При этом контроль чаще включается как реакция на какой-то прецедент, вызвавший проблему с клиентом и на примере этого прецедента руководители показывают сотрудникам, чего от них хотят. Чаще всего в виде «разбора полетов».
Но большинство клиентов не жалуются руководителям, а начинают искать альтернативных поставщиков. Поэтому находить проблемы в работе с клиентами только на основе их обращений очень затруднительно.
Если отсутствует постоянная связь руководителя с подчиненными, то сотрудники не будут по своей инициативе просить советов в работе у того, кто увлекается «разбором полетов», а руководитель не узнает, что происходит «на земле». Поэтому и говорят, что большинство хороших идей губит плохая реализация. Все потому что владелец бизнеса создает новые идеи для той компании, которой уже не существует.
Возникают и другие проблемы. Все сложнее и сложнее найти подходящих руководителей отделов из-за отсутствия четкого описания их работы. Появляются «незаменимые сотрудники», которым приходится много платить. И в какой-то момент руководство решает – хватит. Нужно выделить время, обновить все должностные инструкции, четко описать обязанности каждого, поставить индивидуальные цели и привязать их к мотивации. Это первый шаг к необходимой бюрократизации в хорошем смысле этого слова.
Такие ситуации повторяются 2-3 раза, иногда с длительными перерывами, прежде чем компания решится на использование процессного подхода с регулярным пересмотром и обновлением ключевых бизнес-процессов. Должностные инструкции и регламенты при этом могут создаваться и обновляться автоматически, если компания использует подходящие программы для моделирования. А благодаря интернет-порталу эти документы будут всегда доступны всем сотрудникам и всегда актуальны.
Почему процессный подход стал привлекать малый бизнес
Процессный подход был интересен «повзрослевшим» компаниям. Но в последние два года я замечаю тренд на его использование и в малом бизнесе. Некоторые компании обращаются к нам с просьбой спроектировать бизнес-процессы и посчитать финансовую модель для бизнеса, который только создается. И причин здесь несколько:
- Опытные руководители сразу хотят зафиксировать все специфические процессы, отличающие компанию от конкурентов в виде диаграмм, чтобы избежать «ошибок при копировании». При этом они хотят с самого начала выстроить работу так, чтобы им не приходилось «погружаться в операционку» и своим примером обучать каждого сотрудника. Для большинства процессов можно использовать отраслевые шаблоны, а ключевые процессы – дифференциаторы, по которым нужна обратная связь и развитие, закладываются как базовые на основе лучших практик и регулярно обновляются исполнителями, согласовываются руководителями, а после принимаются в работу в качестве новых стандартов. И чтобы такой подход работал, дополнительно проектируются процессы по развитию бизнеса, связанные с KPI и мотивацией исполнителей.
- Использование IT-систем для автоматизации процессов сейчас закладывается еще на этапе проектирования организации. Они позволяют собирать аналитику о работе компании, выстраивать удобные коммуникации с клиентами и исполнителями, сокращать потери времени сотрудников – а это обязательный и крайне важный элемент любого бизнеса. Без них компания не может конкурировать.
IT-системы не понимают функционального подхода. Любое взаимодействие сотрудников между собой или с клиентами рассматривается их алгоритмами как процесс, где после срабатывания триггера – получения заявки от клиента, наступления времени технического обслуживания или другого события – каждый сотрудник выполняет свои задачи по заявке и передает работу другому вне зависимости от того, в каком отделе он работает.
От получения заявки клиента на ремонт до ее закрытия с ней работают разные специалисты: менеджеры, диспетчеры, кладовщики, техники и бухгалтера. Каждый сотрудник добавляет ценность на своем этапе, а IT-система фиксирует время работы и отслеживает, чтобы сотруднику дальше по цепочке была передана вся необходимая информация.
Вывод
- Чтобы не потерять конкурентоспособность сервисным компаниям приходится внедрять IT-системы. Без них сложно выполнить анализ и улучшение существующих бизнес-процессов, сократить потери времени и снизить себестоимость.
- IT-системы не понимают функционального подхода, для их внедрения требуется техническое задание, основу которого составляет описание процессов и KPI, которые система должна измерять и выводить в виде отчетов. При наличии актуальных схем бизнес-процессов, правильно рассчитанной загрузке и правильной мотивации сотрудников, автоматизация бизнес-процессов не представляется сложной задачей.
- Процессный подход стал актуальным для малого бизнеса из-за необходимости внедрения IT-систем и благодаря повышению «уровня зрелости» руководителей, которые стремятся меньше времени тратить на рутинные задачи и больше – на развитие бизнеса, работу с клиентами и сотрудниками.
Читайте также:
Еще немного о картинках, рисовании и моделировании.
Как Вам такая? Взял из текста Карла Вигерса о контекстных диаграммах. Как автор пишет,
I’m a simple person. I like simple things, such as tools that anyone can understand and apply. When I learned about the value of modeling software systems many years ago, the first tool I encountered was indeed simple: the context diagram.
Система заказов для кофейни (пример).
Используются всего три символа - прямоугольник, круг и стрелки.
Отличная схема. Лет 20 назад у него на эту тему была и книга, и статья. Чем меньше обозначений, тем проще донести суть выстраиваемой модели, поскольку убирается все ненужное.
Например, в IDEF0, который разрабатывался в 1970-х в рамках американских военных программ, вообще - два объекта: прямоугольник и дуга (стрелка). Профессиональному аналитику этого вполне хватает для построения функциональной модели анализируемой сущности.
Для контраста можно сравнить с нотацией BPMN, в которой обилие возможных обозначений зачастую приводит к путаницам даже среди команды разработчиков модели - еще до момента защиты перед заказчиком.
"Больше" далеко не всегда означает "лучше", хотя иногда так и может казаться. Нотация Вигерса представляет собой вполне приемлемый компромисс между количеством доступных элементов и необходимой детализацией моделирования.
Вполне допустимо так делать.
Я обратил внимание на то, что относится к меню.
Тут есть связи (стрелки):
menu contents, menu, menu feedback.
Как я понял, есть:
Menu Manager, Patron и Cafeteria Ordering System - система управления.
Menu Manager формирует menu.
Если система управления оперативно вносит изменения в меню, например, кончаются инградиенты для какого-то блюда, то Menu Manager получает информацию об этом - menu feedback.
Patron получает информацию о том, какое menu и что изменилось в menu - menu feedback. Но он сам напрямую с меню не работает.
Я же не сказал -- повышать размерность бездумно.
Есть критерии, которые указывают на недостаточность размерности.
Да. В книге пример приводится просто для демонстрации высокого уровня абстракции контекстной диаграммы, какого-то содержательного анализа из этого не следует.
Мы примерно так схему автоматизации делаем, но обычно добавляем указания на техническое средство (контроллер такой-то, станция оператора, местная панель управления) и виды связи между элементами с протоколами (Ethernet, ControlNet, Modbus, физические сигналы от датчиков и кнопок.).
Можно указать место размещение элементов - машзал, аппаратная (контроллерная), операторная.
Кстати, в приведенной схеме еще нужно, наверное, местную панель управления - это место, где принимают заказы и производят рассчет.
Так это и правильно - просто нотации разные используются, например, если для потоков данных - DFD могут применяться, если для декомпозиции систем - возможно использование онтологического моделирования (IDEF5), если для конкретных взаимодействий между пользователями - собственно процессные модели (IDEF3, BPMN, UML). Автор в книге, кстати, далее к UML и переходит:
Можно использовать различные нотации, но методология структурно-системного анализа и моделирования будет постоянной для всех случаев, отсюда и общность подходов, совпадение шагов реализации моделей.
Это только самый верхний уровень с минимумом подробностей. И, конечно, у Вигерса много и книг, и статей, и прочих текстов для всех и каждого.
Эта картинка про кофейню - из сегодняшнего текста, но понятно, что идеям подготовки контекстных диаграмм полсотни лет.
Могу прислать сам текст, чтобы не пересказывать своими словами несколько страниц, но, если вкратце, в круге - основной изучаемый объект (например, система), прямоугольники - внешние системы и оъекты, а стрелки - основные интерфейсы. На этой картинке только самый верхний уровень без детализации.
Так и есть. Фактически разрозненные разработки начали обдумываться еще после WWII, но реально "плотину прорвало" после выхода методологии SADT (1969-73) - сейчас мы просто видим последствия революционного для того времени изменения мышления.
Примечательно, что при отсутствии современных CAD/CAM-средств разработчикам удавалось реализовывать крупные оборонные и инфраструктурные проекты, что было бы просто недостижимо при использовании нечетких/нечитаемых диаграмм.
Мне приходит на ум аналогия с качеством разработки софта: в 80-90е старались оптимизировать использование каждого бита, и программы доводились до уровня технического/инженерного совершенства. Удешевление машинного времени привело к более "либеральной" разработке: потери эффективности стали компенсироваться большей вычислительной мощностью. Так и с диаграммами: изобилие нотаций, правильность большого числа вариаций, терпимость к неточностям, - иногда приводят к падению качества конечного продукта. Парадоксально, но технические ограничения прошлого приводили к большей глубине проработки как структуры, так и функционала в моделях. Отсюда - предельная четкость и однозначность получаемого результата.