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

Процессная модель как пошаговая инструкция

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

И здесь процессный подход становится оптимальным решением:

  1. Четко определены рамки – начало работы и нужный результат. Все дальнейшие действия проходят уже в обозначенных пределах и не выходят за них, что помогает сосредоточиться на задаче.
  2. Простая последовательность действий. Вы прописываете действия «шаг за шагом». Человеческий мозг так устроен, что попытки охватить все и сразу приводят к ошибкам и путанице. Намного проще и удобнее постепенно выстраивать последовательность действий, проверяя каждый из шагов на однозначность решения и выстраивая логические разветвления там, где это необходимо (конструкция типа «если – то – иначе»). Не зря именно так строятся все инструкции – четко, пошагово, однозначно.

Рассмотрим в качестве примера фрагмент процесса продаж:

  1. Прием звонка от покупателя;
  2. Сохранение звонка (запроса);
  3. Создание задачи «обработка запроса» на основе запроса от покупателя;
  4. Автоматическое создание Сделки на основе обработанного запроса.

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

Теперь начинается анализ каждого этапа:

  1. Прием звонка. Его нужно автоматически зафиксировать. в CRM-системе и сохранить запись. При выборе программного обеспечения рассматриваем, какие CRM-системы работают с этой телефонией. Все программные решения, которые не могут быть интегрированы с телефонией, более не рассматриваются.Выбор сужается до перечня тех, что удовлетворяют реализации этого этапа.
  2. Сохранение звонка. Нужно ли вам хранить записи телефонных разговоров? Предоставляет ли телефония эту возможность? Определяем варианты реализации решения. Добавляем с техническое задание для специалиста, который будет настраивать CRM-систему требование: сохранение события – «звонок от клиента» с обязательной ссылкой на запись разговора.
  3. Создание задачи. Прорабатываем детали. Как назначается ответственное лицо – автоматически или руководителем? Нужно ли отправлять уведомление о созданной автоматически задаче руководителю? Какие сведения необходимо получить от покупателя на этапе обработки запроса? Как определить, что задача выполнена, и можно открывать сделку? В некоторых случаях этот этап требует 1-2 действий, например, уточнения наличия товара и повторного звонка клиенту. В других случаях создается «подпроцесс», т.е. этап детализируется подробно. И прописывается перечень требований по автоматизации к каждому из действий.
  4. Создание Сделки. Аналогично: после каких выполненных условий Сделка будет создаваться автоматически? Какие данные (информационные поля) должны быть в документе Сделка? Ответы на вопросы позволяют еще больше детализировать требования к выбору и настройке CRM. Конечно же если возможно оптимизация тех или иных действий, то оптимизируем.

И так, этап за этапом, вы продумываете подробно. В результате вы получаете четкое и однозначное решение – как это должно работать и что для этого нужно.

Т.е. в процессе разработки процессной модели и ее детализации вы получаете всю необходимую информацию:

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

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

Процессный подход при составлении плана работы

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

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

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

  • В качестве приглашенного специалиста – составить план работ с указанием сроков и стоимости в общем или для каждого этапа.
  • В качестве клиента – четко и однозначно понимать, что именно вам предлагают, как это будет реализовано, какие ресурсы от вас потребуются, и когда ждать результата.

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

Процессное моделирование для взаимодействия с заказчиком

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

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

Нередко для подобных целей используют другие варианты:

  • Объемные коммерческие предложения, где текстом описываются возможные преимущества. Обычно в них много слов и очень мало конкретных решений. В итоге, заказчик просто не понимает, что и зачем ему хотят продать.
  • Технические задания. Иногда составляются заказчиком (особенно часто в крупных компаниях), иногда – подрядчиком после устного обсуждения задачи. Содержат большой объем сложной терминологии, перечень ГОСТов, других технических требований. И множество другой информации, которая, на самом деле, не нужна ни заказчику, ни подрядчику (специалисту по внедрению, бизнес-консультанту и т.д.). Понять суть проблемы или предлагаемые решения на основе таких документов крайне затруднительно.
  • Устные переговоры и демонстрация возможностей системы. Подходят для внедрения небольших программных систем, но в сложных случаях почти всегда такой вариант оканчивается неоправданными ожиданиями заказчика и неверным пониманием задачи подрядчиком.

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

Как это происходит:

  1. Постановка задачи. Заказчик сообщает о проблеме и о том, что он хотел бы получить.
  2. В BPMN создается графическая процессная нотация, которая проходит согласование. На этом этапе заказчик понимает, что он получит, и согласен с выбранным решением, исполнитель – что именно нужно сделать.
  3. На основе согласованного решения выполняется выбор программного обеспечения (с учетом иерархии систем, о которой я уже писал в прошлых статьях).
  4. Формируется план выполнения работ.
  5. Выполняется внедрение.
  6. Заказчик на основе согласованной процессной модели оценивает результат.

Если все действия были выполнены правильно, то в итоге система (подразделение компании или бизнес в целом) работает так, как было оговорено на этапе согласования процессной модели. Результат соответствует ожиданиям. Сотрудничество завершается успешно.

Два уровня: графика и текст

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

Потому я сочетаю всегда два уровня:

  1. Графическая нотация. Она позволяет понять, что именно получит заказчик. Причем, показывает решение максимально наглядно.
  2. Текстовое описание. Здесь я подробно объясняю, каким образом будет реализовано решение. Текстом можно подробно описать все важные этапы самой процессной модели, здесь же перечисляется необходимое оборудование и программное обеспечение. В текстовом виде предоставляется и план выполнения работ.

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

‍