Про процессный подход

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

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

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

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

  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, иерархии программных систем, внедрения программных продуктов. Используйте полученные знания на практике.  

Предыдущая глава

Перейти к содержанию книги

Следующая глава

Об авторе

Кинзябулатов Рамиль

Кинзябулатов Рамиль  специалист по автоматизации трудовых(бизнес) процессов. Консультирую и пишу статьи о компьютерных системах (ERP,CRM), автоматизации бизнес процессов. Автор книги "CRM. Подробно и по делу". Работаю и живу в России в городе Москва.

Заполните форму, и наш менеджер Рузалина свяжется с вами и поможет найти ответ
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.