Зачем малому бизнесу процессный подход

В нашей стране давно и прочно закрепилось правило: небольшим компаниям не нужна системная работа, измерение эффективности и прочие 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, в которой обилие возможных обозначений зачастую приводит к путаницам даже среди команды разработчиков модели - еще до момента защиты перед заказчиком.

"Больше" далеко не всегда означает "лучше", хотя иногда так и может казаться. Нотация Вигерса представляет собой вполне приемлемый компромисс между количеством доступных элементов и необходимой детализацией моделирования.

Инженер-конструктор, Санкт-Петербург
Евгений Равич пишет:
Еще немного о картинках, рисовании и моделировании.
Как Вам такая? Взял из текста Карла Вигерса о контекстных диаграммах. Как автор пишет, 
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. 
Система заказов для кофейни (пример).
Используются всего три символа - прямоугольник, круг и стрелки.

Вполне допустимо так делать.

Я обратил внимание на то, что относится к меню.

Тут есть связи (стрелки):

menu contents, menu, menu feedback.

Как я понял, есть:

Menu Manager, Patron и Cafeteria Ordering System - система управления.

Menu Manager формирует menu.

Если система управления оперативно вносит изменения в меню, например, кончаются инградиенты для какого-то блюда, то Menu Manager получает информацию об этом - menu feedback.

Patron получает информацию о том, какое menu и что изменилось в menu - menu feedback. Но он сам напрямую с меню не работает.

Researcher, Москва
Эрнст Мальцев пишет:
Это не всегда так.

Я же не сказал -- повышать размерность бездумно.
Есть критерии, которые указывают на недостаточность размерности.

Управляющий партнер, Санкт-Петербург
Михаил Лурье пишет:

Как я понял, есть:

Menu Manager, Patron и Cafeteria Ordering System - система управления.

Menu Manager формирует menu.

Если система управления оперативно вносит изменения в меню, например, кончаются инградиенты для какого-то блюда, то Menu Manager получает информацию об этом - menu feedback.

Patron получает информацию о том, какое menu и что изменилось в menu - menu feedback. Но он сам напрямую с меню не работает.

Да. В книге пример приводится просто для демонстрации высокого уровня абстракции контекстной диаграммы, какого-то содержательного анализа из этого не следует.

Инженер-конструктор, Санкт-Петербург
Антон Соболев пишет:
Да. В книге пример приводится просто для демонстрации высокого уровня абстракции контекстной диаграммы, какого-то содержательного анализа из этого не следует.

Мы примерно так схему автоматизации делаем, но обычно добавляем указания на техническое средство (контроллер такой-то, станция оператора, местная панель управления) и виды связи между элементами с протоколами (Ethernet, ControlNet, Modbus, физические сигналы от датчиков и кнопок.).

Можно указать место размещение элементов - машзал, аппаратная (контроллерная), операторная.

Кстати, в приведенной схеме еще нужно, наверное, местную панель управления - это место, где принимают заказы и производят рассчет.

Управляющий партнер, Санкт-Петербург
Михаил Лурье пишет:
Антон Соболев пишет:
Да. В книге пример приводится просто для демонстрации высокого уровня абстракции контекстной диаграммы, какого-то содержательного анализа из этого не следует.

Мы примерно так схему автоматизации делаем, но обычно добавляем указания на техническое средство (контроллер такой-то, станция оператора, местная панель управления) и виды связи между элементами с протоколами (Ethernet, ControlNet, Modbus, физические сигналы от датчиков и кнопок.).

Можно указать место размещение элементов - машзал, аппаратная (контроллерная), операторная.

Кстати, в приведенной схеме еще нужно, наверное, местную панель управления - это место, где принимают заказы и производят рассчет.

Так это и правильно - просто нотации разные используются, например, если для потоков данных - DFD могут применяться, если для декомпозиции систем - возможно использование онтологического моделирования (IDEF5), если для конкретных взаимодействий между пользователями - собственно процессные модели (IDEF3, BPMN, UML). Автор в книге, кстати, далее к UML и переходит:

 

Можно использовать различные нотации, но методология структурно-системного анализа и моделирования будет постоянной для всех случаев, отсюда и общность подходов, совпадение шагов реализации моделей.

Генеральный директор, Москва
Антон Соболев пишет:
Евгений Равич пишет:

Как Вам такая? Взял из текста Карла Вигерса о контекстных диаграммах.

Отличная схема. Лет 20 назад у него на эту тему была и книга, и статья. Чем меньше обозначений, тем проще донести суть выстраиваемой модели, поскольку убирается все ненужное. 

Например, в IDEF0, который разрабатывался в 1970-х в рамках американских военных программ, вообще - два объекта: прямоугольник и дуга (стрелка). Профессиональному аналитику этого вполне хватает для построения функциональной модели анализируемой сущности.

Для контраста можно сравнить с нотацией BPMN, в которой обилие возможных обозначений зачастую приводит к путаницам даже среди команды разработчиков модели - еще до момента защиты перед заказчиком.

"Больше" далеко не всегда означает "лучше", хотя иногда так и может казаться. Нотация Вигерса представляет собой вполне приемлемый компромисс между количеством доступных элементов и необходимой детализацией моделирования.

Это только самый верхний уровень с минимумом подробностей. И, конечно, у Вигерса много и книг, и статей, и прочих текстов для всех и каждого.

Эта картинка про кофейню - из сегодняшнего текста, но понятно, что идеям подготовки контекстных диаграмм полсотни лет.

Генеральный директор, Москва
Михаил Лурье пишет:
Евгений Равич пишет:
Еще немного о картинках, рисовании и моделировании.
Как Вам такая? Взял из текста Карла Вигерса о контекстных диаграммах. Как автор пишет, 
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. 
Система заказов для кофейни (пример).
Используются всего три символа - прямоугольник, круг и стрелки.

Вполне допустимо так делать.

Я обратил внимание на то, что относится к меню.

Тут есть связи (стрелки):

menu contents, menu, menu feedback.

Как я понял, есть:

Menu Manager, Patron и Cafeteria Ordering System - система управления.

Menu Manager формирует menu.

Если система управления оперативно вносит изменения в меню, например, кончаются инградиенты для какого-то блюда, то Menu Manager получает информацию об этом - menu feedback.

Patron получает информацию о том, какое menu и что изменилось в menu - menu feedback. Но он сам напрямую с меню не работает.

Могу прислать сам текст, чтобы не пересказывать своими словами несколько страниц, но, если вкратце, в круге - основной изучаемый объект (например, система), прямоугольники - внешние системы и оъекты, а стрелки - основные интерфейсы. На этой картинке только самый верхний уровень без детализации.

Управляющий партнер, Санкт-Петербург
Евгений Равич пишет:

идеям подготовки контекстных диаграмм полсотни лет.

Так и есть. Фактически разрозненные разработки начали обдумываться еще после WWII, но реально "плотину прорвало" после выхода методологии SADT (1969-73) -  сейчас мы просто видим последствия революционного для того времени изменения мышления.

Примечательно, что при отсутствии современных CAD/CAM-средств разработчикам удавалось реализовывать крупные оборонные и инфраструктурные проекты, что было бы просто недостижимо при использовании нечетких/нечитаемых диаграмм.

Мне приходит на ум аналогия с качеством разработки софта: в 80-90е старались оптимизировать использование каждого бита, и программы доводились до уровня технического/инженерного совершенства. Удешевление машинного времени привело к более "либеральной" разработке: потери эффективности стали компенсироваться большей вычислительной мощностью. Так и с диаграммами: изобилие нотаций, правильность большого числа вариаций, терпимость к неточностям, - иногда приводят к падению качества конечного продукта. Парадоксально, но технические ограничения прошлого приводили к большей глубине проработки как структуры, так и функционала в моделях. Отсюда - предельная четкость и однозначность получаемого результата.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Преграды на пути женщин к лидерству

Сейчас есть все возможности для карьерного роста женщин, однако часто эти опции ограничиваются средним уровнем управления.

Большинство россиян страдают «синдромом вечной занятости»

Испытывают вину, когда ничего не делают.

Финансовая подушка – источник стресса для Россиян

Люди копят деньги «на черный день», но психологически не готовы их тратить в случае форс-мажора.

Треть работодателей планирует пересмотреть программы мотивации

Итоги 2025 года показали, что взгляды работников и их руководства на финансовые и нефинансовые факторы мотивации расходятся.