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

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

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

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

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

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

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

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

Мы прошли вот такие стадии:

1. Нас четыре человека, все всё понимают.
2. Появляется два разных магазина: уже нужны правила приёма почты и правила обязательных ответов на неё.
3. Появляются представительства в городах. Начинается систематический сбор информации для внутренних инструкций, советов и других штук, призванных помочь в разных ситуациях: по сути, позитивный опыт и наследственные коллекции грабель.
4. Усложняются взаимодействия по сайту. Разработчики поднимают трекер и систему тикетов.
5. Нас столько, что одни и те же вопросы задаются больше трёх раз. Заводится закрытый корпоративный блог, чтобы иметь возможность быть в курсе всего, быстро сообщать о проблемах, меняться механиками процессов.
6. Нанимается команда специалистов, которые планируют бизнес-процессы внутри компании, составляют точные инструкции и оргсхему. По сути, идёт процесс описания уже существующих процессов и их оптимизации там, где это нужно.
7. Вся эта радость дотачивается под ситуации.

Нужны ли процессы, если команда из 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 компании.