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

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

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

Молодые специалисты больше не гонятся за быстрым карьерным ростом — один из главных приоритетов теперь стабильность.

Количество вакансий с ДМС выросло почти в 3 раза за год

В условиях высокой конкуренции за кадры льготы и ДМС становятся стратегически важными для бизнеса.

Каждый третий россиянин хочет сменить место работы в 2025 году

Основные причины такого решения – желание зарабатывать больше и отсутствие перспектив в текущей сфере.

Росстат оценил разницу в зарплатах мужчин и женщин в России

В среднем среднемесячный разрыв в зарплате составил более 26 тыс. руб.