Способы внедрения бизнес процессов

Как мы внедряли бизнес-процессы и зачем оно вообще надо

Когда компания маленькая и все всех знают (примерно до 30 человек) никакие формализованные бизнес-процессы, по идее, не нужны. Когда компания большая, географически раздёлённая или же задачи стоят нетривиальные, количество бардака начинает стремительно увеличиваться. С этим надо бороться. Например, мы решили внедрять бизнес-процессы в тот момент, когда перестали узнавать в лицо некоторых собственных сотрудников.

Первый же резонный вопрос, который хочется задать — это зачем вообще нужна эта «бюрократия». Ответ простой: в принципе, это похоже на рефакторинг. Снаружи всё так же, но внутри уже логично, чётко работает и можно быстро разрабатывать дальше.

Пример постановки процесса из 1900-х

Рабочие на заводе Форда собирают детали на конвейере. Рабочий получает 5 баксов в день и собирает 30 единиц продукции. Генри Форд в течение часа смотрит на рабочего и понимает, что тот делает много лишних действий. Он пробует сам собрать деталь по новой схеме, и понимает, что, по идее, это можно делать быстрее, но нужно чуть изменить конвейер, подвинуть оборудование, и, главное, научить рабочего совершать другие движения. Через «не хочу» он обучает этого человека делать как надо — и, вуаля! — он всё ещё продолжает получать 5 баксов в день, но производит уже 42 единицы продукции.

Привычно? Нет. Интуитивно-понятно? Нет. Выгодно? Да, если затраты на переобустройство и переобучение рабочих меньше, чем предполагаемая прибыль.

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

Хронология борьбы с бардаком

Нужны ли процессы, если команда из 10 человек?

Да, но не для понимания «что и где», а для устаканивания рабочего процесса и ограничения ответственности. Приведу пример из жизни своей бывшей компании.

Пример 1: простой, но знакомый до боли — фича от клиента.

1. Встреча клиента и менеджера для постановки задачи.
2. Согласование критериев приёмки задания.
3. Руководитель отдела составляет техзадание разработчику.
4. Техзадание или контрольные точки согласовываются с клиентом.
5. Ведётся разработка.
6. Руководитель отдела проводит приёмку.
7. Менеджер проводит сдачу проекта клиенту.

Если вы разработчик, при таком процессе это означает следующие вещи:

• Никто кроме вашего руководителя не может ставить вам задачи (даже гендиректор).
• Вы никогда не работаете без чёткого техзадания.
• Вы не видите клиента. Вы даже не видите менеджера, если уж совсем хочется.
• Внезапно передумавший клиент с новой идеей в последний день разработки — это проблема менеджера.
• Вы отвечаете за косяки только перед своим руководителем (а он — перед клиентом).
• Вы работаете не на «усталость», а на результат. То есть если разработка была закончена за час, это не значит, что вы получите меньше, чем если бы она была сделана за месяц.

Всё просто, логично и понятно, но вызывает издержки, связанные с необходимостью соблюдения протокола.

Пример 2, теперь из практики Мосигры
Вводная: есть безумный офис на 50 человек и чётко структурированные розничные магазины. Предположим, продавцу в рознице нужна новая полка взамен только что сломавшейся. Вот что он делает в старой схеме:

1. Обращается к старшему точки и сообщает о проблеме.
2. Старший точки обращается к региональному координатору и сообщает о проблеме.
3. Координатор стучит к руководителю отдела АХО и сообщает о проблеме.
4. Руководитель отдела АХО ставит задачу разнорабочему.
5. Разнорабочий утверждает бюджет у своего руководителя на новую полку.
6. Финансовому директору на стол ложится счёт под подпись.
7. Наступает следующий день.
8. Рабочий наконец-то ставит новую полку.

Если в процессе что-то прервётся, полка приедет только после того, как продавец скажет о ней ещё раз старшему и вся схема будет пройдена заново. Понятно, что описано достаточно утрированно и в реале всё проще, но 10-15% процессов без чёткой схемы всё равно могут дать сбой, например, если руководитель заболел.

Теперь та же ситуация выглядит так:

1. Продавец обращается в АХО и сообщает о проблеме.
2. Сотрудник АХО принимает решение о целесообразности использования средств.
3. Рабочий ставит новую полку.

Обратите внимание: руководитель сотрудника магазина в процессе не участвует. И ещё одно: если сотрудник АХО решил, что новая полка может стоит в два раза дороже нормальной цены для таких ситуаций, автоматически генерится алерт для финансового директора.

Если АХО выставляет счёт, который выходит за план их отдела, генерится алерт для руководства, где есть две кнопки: «дать люлей» и «разрешить». При желании можно нажать обе. Суть механики: путь короче и быстрее, но полный контроль при этом сохраняется. Никаких лишних действий.

Метрики

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

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

Работу закупщика оценивать уже сложнее: но построение бизнес-процесса даёт возможность понимать, что именно дальше стало с товаром, как именно оно стало и насколько эффективно.

Косяки

Всё вышеописанное было бы просто теорией, если бы не встраивалось в систему управления и учёта (в нашем случае – в 1С). Теперь, например, если кто-то звонит в магазин и заказывает товар, которого нет в наличии прямо сейчас, эта информация либо сразу доносится до закупщика, либо складывается в сборщик косяков. В итоге руководитель отдела закупок чётко видит проблему и имеет возможность принять меры.

Когда десантируются сектоиды

Как это всё внедряется в компанию

1. Сначала аналитик разговаривает с руководителем и понимает задачу. Бывает так, что процессы внедряются для галочки, чтобы потом выгоднее продать бизнес иностранцем, бывает, что для понтов, а бывает — что для дела. Последний случай наиболее интересный и сложный.
2. Выставляется счёт, вызывающий оху когнитивный диссонанс. В этот момент нужно договариваться на такие условия, что оплата производится при повышении конкретных показателей. Грубо говоря, стали получать на 20% больше прибыли в результате внедрения — платите.
3. Затем аналитик обходит всю компанию и задаёт много-много вопросов о том, как оно работает.
4. Потом каждому сотруднику приходит анкета с просьбой указать свои выполняемые задачи (заполняется полчаса).
5. Аналитик напряжённо думает и составляет блок-схему взаимодействия, из которой растут процессы и оргсхема компании.
6. Компания реорганизовывается под новые процессы.
7. Сотрудникам доносится суть изменений. Если сотрудники в возрасте, они понимают туго, но делают сразу. Если молодые — понимают отлично, но изменяются медленно.
8. Корректируются баги. Структура меняется по мере изменения компании и её процессов.

Сроки

У нас процесс занял около месяца на сбор данных при аналитике (работающем по программе «Луноход-1») и аналитике в штате, ещё месяц ушел на сбор и проверку анкет, ещё через кучу времени появилась оргсхема и процессы, потом всё это было внедрено. В общей сложности на всё ушло примерно полгода.

Зачем ещё нужно внедрять такие штуки

• Чтобы контролировать рабочий процесс, не терять задачи и видеть, кто и что конкретно делает.
• На каждую вещь в компании появляется конкретное ответственное лицо (у каждой проблемы появляется фамилия).
• Не объяснять каждый раз новому человеку, к примеру, как оформлять выезд и т.п.
• Эффективнее масштабироваться без объяснения всей сути жизни каждому сотруднику в другом городе.
• Быстро принимать новых людей.

Резюме: плюсы и минусы

Плюсы:

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

Минусы:

• Процедура занимает много времени и требует много средств: например, начинать её в сезонный пик продаж — не лучшая идея.
• Консультант — не волшебник. Он не решает проблемы, а предлагает типовые решения (которые есть и в книгах) и помогает дотачивать их под компанию. Эти типовые решения внедряются при непосредственном участии руководства.
• Придётся много и сильно работать самим как по построению процессов, так и по внедрению.
• В конечном итоге это дорого для компании, поэтому нужно очень чётко понимать, что конкретно всё это даст.

Продолжу сравнение с рефакторингом: он дорогой, сложный, его не стоит начинать делать за неделю до большого релиза, но зато он очень полезен, если проект вырос в большой, тяжелый и над ним работает много разных людей. А ещё завершение рефакторинга (но не сам процесс) очень успокаивает нервы всем тем, кто раньше впадал в ярость, видя китайский код.

UPD. В личку напомнили, что для построения бизнес-процессов нужно сформулировать стратегические цели и даже миссию (в хорошем смысле этого слова). Да, иначе будет непонятно, что делать, куда делать и как делать: нужна своеобразная ДНК или modus operandi компании.

Источник

Описание бизнес-процессов: методы и инструменты

Описание бизнес-процессов: методы и инструменты

Финансовый директор группы компаний «Радиус». Имеет большой опыт работы в финансовом консалтинге, а также в управлении финансовой службой инвестиционной компании, специализирующейся на вложениях в высокотехнологичные проекты.

Определение и суть бизнес-процессов

Каждое предприятие можно рассматривать как целостную структуру взаимодействующих объектов, субъектов и функций. Взаимодействия, в результате которых происходит преобразование исходного материала в целевой материал, называют процессами, а всю структуру часто называют архитектурой процессов. Читайте также, как внедрить систему 5S на производств е.

Действующее предприятие можно описать в рамках одной из нескольких парадигм:

1. Инфологическая – предприятие как база данных.
2. Коммуникационная – предприятие как совокупность участников, которые находятся в совокупности отношений между собой – «договаривающиеся стороны».
3. Трансформационная – предприятие как фабрика по переработке ресурсов в конечный продукт. Ключевой частью понимания предприятия в рамках этой парадигмы являются бизнес-процессы.

Бизнес-процессы – это взаимосвязанные и последовательные действия, отвечающие следующим опциям:

• целью является производство продукции или услуги;
• в процессе участвуют люди. В противном случае мы говорим о технологическом процессе, который подчиняется иным принципам управления.

Этапы внедрения бизнес-процессов

Постановка бизнес-процессов на предприятии состоит из нескольких этапов (см. рисунок 1).

Рисунок 1. Этапы постановки бизнес-процессов на предприятии

Недооценка любого из этапов делает бессмысленным проект постановки бизнес-процесса.

1. Выявление и документирование процесса. Важно проанализировать текущую ситуацию, прежде чем приступать к изменениям. В результате этого этапа должна появиться модель «AS IS» (как есть), выявлены узкие места и потенциал возможных изменений.
2. Анализ процесса проводится до и после его внедрения. Этот этап определяет необходимые изменения, инструментарий и ресурсы.
3. Описание бизнес-процесса дает полную информацию по планируемым изменениям. Результатом этого этапа должен стать задокументированный план, обязательный к исполнению. На практике этот этап ошибочно принимают за завершающий. И тогда документ, описывающий процесс, становится «неработающим».
4. Реализация – это исполнение принятых решений. Во время этого этапа формируется дополнительная информация об эффективности бизнес-процесса в целом, его участников и ключевых этапов. Информация, генерируемая в процессе реализации, способна поддержать и усилить конкурентные преимущества компании на рынке.
5. Контроль остается самой недооценённой частью задачи постановки бизнес-процесса. Без последующего контроля и анализа действующих процессов, весь проект по внедрению окажется неэффективным. Недооценка этого этапа отчасти оправдана тем, что от процесса ожидается его самодостаточность. Механизм внедряется для экономии времени и ресурсов. Но любой процесс продолжает требовать внимания.

Часто кажется, что у менеджмента компании в результате постановки бизнес-процесса должна появиться «волшебная кнопка». После нажатия на «волшебную кнопку» автоматически получается ожидаемый результат. Однако не все решения лежат в области автоматизации. Компетентный аналитик должен своевременно учитывать все аспекты деятельности предприятия и предложить оптимальные для конкретной ситуации решения.

Методологии и инструментарий описания бизнес-процесса

Важным, но непринципиальным моментом является вопрос выбора инструментария для описания бизнес-процесса. Эффективность инструмента определяется гибкостью и простотой применения, а также способностью учитывать все парадигмы описания деятельности предприятия. В современной методологии управления чаще всего упоминается инструмента описания бизнес-процессов: BPMN 2.0 (Business Process Model and Notation). Его отличают:

• умеренная плотность подачи информация;
• гибкость;
• широкая аудитория (бизнес-аналитики, системные аналитики, разработчики баз данных и приложений).

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

В результате описания получается графическая иллюстрация и текстовое сопровождение, поясняющее ключевые аспекты процесса (см. рисунок 2).

Рисунок 2. Пример графического описания бизнес-процесса в рамках нотации BPMN 2.0

BPMN 2.0 – это своего рода баланс между легкостью восприятия и сложностью описания бизнес-процесса. Инструмент находится в свободном доступе на сайте Object Management Group.

Виды бизнес-процессов

Описание бизнес-процессов невозможно без понимания их видов и классификации основных участников.

В литературе и практике встречается несколько видов классификаций. Чаще всего процессы классифицируют по следующим группам:

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

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

Управленческие оказывают влияние на деятельность всех подразделений и в то же время непосредственно не участвуют в их работе. Основные задачи управленческих процессов:

• выбор направлений развития компания;
• контроль за исполнением поставленных задач.

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

Участники

Участников группируют по-разному, но так или иначе, следующие роли присутствуют во всех методиках:

Владелец – это основной бенефициар бизнес-процесса. Владелец распоряжается ресурсами, владеет полномочиями, необходимыми и достаточными для исполнения процесса, и несет ответственность за его эффективность. У конкретного процесса свой владелец. Например, владельцем процесса поиска нового сотрудника и его трудоустройства является руководитель службы HR.

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

Кроме разделения по ролям, участников разделяют по степени контролируемости или простым языком – по месту работы.

Внутренние – сотрудники компании, ответственные за выполнение задач.

Внешние – участники, неработающие в компании. При этом они влияют на ход исполнения задач, стоящих перед сотрудниками компании.

Роли, нотации BPMN, программное обеспечение и оборудование, обеспечивающие автоматизацию бизнес-процесса – все это неотъемлемые объекты и субъекты процесса описания.

Практика работы с бизнес-процессами

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

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

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

При описании бизнес-процессов следует придерживаться следующих рекомендаций:

1. Результаты, которые компания ожидает получить на выходе процесса, должны быть четко сформулированы и измеримы.

2. Не стоит внедрять процесс, не имея инструментария и ресурсов для контроля за его исполнением.

3. Самыми дисциплинированными исполнителями задач бизнес-процессов должны стать генеральный директор и топ-менеджмент компании.

4. «First things first». Основное внимание следует уделять основным процессам. Если есть критичные сложности в основных, эффективность вспомогательных процессов не будет давать никакой добавочной стоимости.

5. Все участники должны быть осведомлены и мотивированны. Каждый сотрудник должен хорошо представлять:

• свои задачи;
• сроки для исполнения задач;
• формулу и способы измерения результата;
• вознаграждение в случае успешного выполнения поставленных задач.

6. При описании бизнес-процесса используйте простые и распространенные определения. Задача описания процесса – сделать его понятным для целевой аудитории. Самовыражение желательно оставить для других задач.

7. Никто не знает ваш бизнес лучше, чем вы сами. Консультанта целесообразно привлечь лишь в качестве модератора. Основную работу по описанию бизнес-процесса эффективнее доверить его будущим исполнителям.

8. «Лучшее – враг хорошего». Оптимизация бизнес-процессов – это цикличная задача, но процесс оптимизации не следует делать вечным. Если же процесс «сбоит», то можно использовать стандартные методы:

• упрощение (исключаются несущественные звенья);
• стандартизация определенных участков (например, шаблоны документов).
• исключение дублирующих задач, исключение излишнего описания БП;
• аутсорсинг (передача исполнения дискретных задач сторонним компаниям);
• оптимизация сроков (сокращение или увеличение сроков для регламентированных задач).

9. Разные уровни описания. При выборе глубины описания следует ориентироваться на его пользователя. Описание для сотрудника IT подразделения, для исполнителя и для сотрудника генерального директора должны иметь разную глубину.

10. Следует помнить, что основная задача постановки бизнес-процесса – это автоматизация исполнения существенных для бизнеса задач. Игнорирование современных инструментов автоматизации приводит к существенному снижению эффективности процесса.

Выводы

Внедрение бизнес-процессов – это сложный и цикличный процесс. Описание бизнес-процессов – ключевой, но не завершающий этап его внедрения. Без последующего анализа и контроля, процесс не даст ожидаемого эффекта. Нотации и инструментарий описания выбирается исходя из стадии жизненного цикла компании, наличии ресурсов и готовности к серьезным кадровым решениям. При этом учитывается способность инструментария автоматизировать процессы. Язык BMPN 2.0 является одним за наиболее популярных среди языков, используемых для описания.

Внедрение управления бизнес-процессами особенно эффективно при необходимости минимизировать в работе влияние человеческого фактора. Первостепенное влияние при внедрении и описании стоит уделить основным процессам: проблемы в ключевых процессах не могут быть компенсированы конкурентоспособным уровнем во вспомогательных процессах.

Источник