Процессная модель, как пошаговая инструкция
Очень часто мне задают вопрос, где и когда на практике может понадобиться процессный подход, и какая от него польза? Об этом я и постараюсь сейчас рассказать.
- Если вы – консультант, я надеюсь, что мои пояснения помогут вам в работе с клиентами.
- Если вы – бизнесмен, понимание того, зачем и когда нужен процессный подход, поможет вам в оценке профессионализма привлеченных специалистов, а также для определения четких требований к их работе.
Процессная модель, как пошаговая инструкция.
Когда вы что-то автоматизируете, оптимизируете или создаете что-то новое, крайне важно понимать, что именно вы делаете, как это будет работать. Общие слова и красивые формулировки могут пригодиться на презентации решения, но никак не в процессе работы. Здесь нужно четкое, однозначное и максимально конкретное понимание – что именно будет происходить, шаг за шагом.
И здесь процессный подход становится оптимальным решением:
- Четко определены рамки – начало работы и нужный результат. Все дальнейшие действия проходят уже в обозначенных пределах и не выходят за них, что помогает сосредоточиться на задаче.
- Простая последовательность действий. Вы прописываете действия «шаг за шагом». Человеческий мозг так устроен, что попытки охватить все и сразу приводят к ошибкам и путанице. Намного проще и удобнее постепенно выстраивать последовательность действий, проверяя каждый из шагов на однозначность решения и выстраивая логические разветвления там, где это необходимо (конструкция типа «если – то – иначе»). Не зря именно так строятся все инструкции – четко, пошагово, однозначно.
Рассмотрим в качестве примера фрагмент процесса продаж:
- Прием звонка от покупателя;
- Сохранение звонка (запроса);
- Создание задачи «обработка запроса» на основе запроса от покупателя;
- Автоматическое создание Сделки на основе обработанного запроса.
Все эти этапы обязательно будут отражены в бизнес-модели процесса продажи в процессе разработки. Таким образом, у вас появляется четкая последовательность действий, которые необходимо каким-то образом внедрить.
Теперь начинается анализ каждого этапа:
- Прием звонка. Его нужно автоматически зафиксировать. в CRM-системе и сохранить запись. При выборе программного обеспечения рассматриваем, какие CRM-системы работают с этой телефонией. Все программные решения, которые не могут быть интегрированы с телефонией, более не рассматриваются.Выбор сужается до перечня тех, что удовлетворяют реализации этого этапа.
- Сохранение звонка. Нужно ли вам хранить записи телефонных разговоров? Предоставляет ли телефония эту возможность? Определяем варианты реализации решения. Добавляем техническое задание для специалиста, который будет настраивать CRM-систему требование: сохранение события – «звонок от клиента» с обязательной ссылкой на запись разговора.
- Создание задачи. Прорабатываем детали:
- Как назначается ответственное лицо – автоматически или руководителем?
- Нужно ли отправлять уведомление, об автоматически созданной задаче, руководителю?
- Какие сведения необходимо получить от покупателя на этапе обработки запроса?
- Как определить, что задача выполнена, и можно открывать сделку?(в некоторых случаях этот этап требует 1-2 действий, например, уточнения наличия товара и повторного звонка клиенту).
В других случаях создается «подпроцесс», т.е. этап детализируется подробно. И прописывается перечень требований по автоматизации к каждому из действий.
4. Создание Сделки. Аналогично:
- После каких выполненных условий Сделка будет создаваться автоматически?
- Какие данные (информационные поля) должны быть в документе Сделка?
Ответы на вопросы позволяют еще больше детализировать требования к выбору и настройке CRM. Конечно же если возможно оптимизация тех или иных действий, то оптимизируем.
И так, этап за этапом, вы подробно продумываете . В результате вы получаете четкое и однозначное решение – как это должно работать и что для этого нужно.
Т.е. в процессе разработки процессной модели и ее детализации вы получаете всю необходимую информацию:
- Что именно необходимо выполнить, чтобы прийти к нужному результату.
- Какие ресурсы вам нужны: компьютерные мощности, другое оборудование (телефоны, сканеры, IP-телефония, кассовые аппараты и т.д.). В том числе, в этот список входят люди – на каких этапах и каким образом будут действовать сотрудники. И какая квалификация исполнителя в каждом случае нужна.
- Какие требования к программной системе для вас важны. Готовый список требований поможет из перечня «возможно подходящих» быстро выбрать одну или несколько, которые действительно подходят. И далее уже определяться на основе цены, предпочтений сотрудников или каких-то дополнительных пожеланий.
- Каким образом программная система (или системы) должны быть настроены. Т.е. вы сможете быстро и четко описать техническому специалисту, какие документы и справочники необходимы, какие в них должны быть поля для заполнения, какие задачи в какой последовательности должны формироваться и т.д.
Таким образом, процессная модель, по сути, становится основой для всех дальнейших решений.
Процессный подход при составлении плана работы.
Итак, вы составили процессную модель будущей автоматизации или оптимизации какой-то работы. Теперь вы четко понимаете, что именно вы хотите получить, и даже какие ресурсы для этого потребуются.
Но есть еще один плюс. Процессная модель – это уже практически готовый план выполнения работ, так как вы уже четко понимаете, что именно необходимо закупить, внедрить и настроить. И какие сложности предстоят на каждом из этапов.
Благодаря подробно проработанному процессу вы получаете все необходимые данные для разработки плана реализации решения (автоматизации, внедрения программной системы и т.д.). На основе этих сведений вы можете:
- В качестве приглашенного специалиста – составить план работ с указанием сроков и стоимости в общем или для каждого этапа.
- В качестве клиента – четко и однозначно понимать, что именно вам предлагают, как это будет реализовано, какие ресурсы от вас потребуются, и когда ждать результата.
В любом случае, согласованная процессная модель становится основой для взаимопонимания между заказчиком и подрядчиком. Заказчик понимает, что он получит, и будет принимать работу, основываясь на согласованном решении. Подрядчик четко знает, каким должен быть результат. Никаких разночтений и вольных трактовок. Все четко и однозначно. Об этом стоит поговорить подробнее.
Процессное моделирование для взаимодействия с заказчиком.
Процессное моделирование – это один из самых наглядных и однозначных вариантов объяснить заказчику суть вашего предложения. И не важно, хотите вы при этом продать программную систему или обосновываете оптимизацию работы компании как бизнес-консультант.
Впоследствии заказчик, ориентируясь на нотацию бизнес-процесса, будет принимать работу. Для этого достаточно сравнить результат и заявленную в согласованной модели последовательность действий.
Нередко для подобных целей используют другие варианты:
- Объемные коммерческие предложения, где текстом описываются возможные преимущества. Обычно в них много слов и очень мало конкретных решений. В итоге, заказчик просто не понимает, что и зачем ему хотят продать.
- Технические задания. Иногда составляются заказчиком (особенно часто в крупных компаниях), иногда – подрядчиком после устного обсуждения задачи. Содержат большой объем сложной терминологии, перечень ГОСТов, других технических требований. И множество другой информации, которая, на самом деле, не нужна ни заказчику, ни подрядчику (специалисту по внедрению, бизнес-консультанту и т.д.). Понять суть проблемы или предлагаемые решения на основе таких документов крайне затруднительно.
- Устные переговоры и демонстрация возможностей системы. Подходят для внедрения небольших программных систем, но в сложных случаях почти всегда такой вариант оканчивается неоправданными ожиданиями заказчика и неверным пониманием задачи подрядчиком.
Процессное моделирование — позволяет четко определить поставленную задачу и обозначить результат. Вероятность проблем взаимопонимания снижается до минимума, так как графическая нотация – это просто, понятно, наглядно и однозначно. При этом заказчик четко понимает, что он получит в качестве решения поставленной задачи. И сможет легко проконтролировать полученный результат.
Как это происходит:
- Постановка задачи. Заказчик сообщает о проблеме и о том, что он хотел бы получить.
- В BPMN создается графическая процессная нотация, которая проходит согласование. На этом этапе заказчик понимает, что он получит, и согласен с выбранным решением, исполнитель – что именно нужно сделать.
- На основе согласованного решения выполняется выбор программного обеспечения (с учетом иерархии систем, о которой я уже писал в прошлых статьях).
- Формируется план выполнения работ.
- Выполняется внедрение.
- Заказчик на основе согласованной процессной модели оценивает результат.
Если все действия были выполнены правильно, то в итоге система (подразделение компании или бизнес в целом) работает так, как было оговорено на этапе согласования процессной модели. Результат соответствует ожиданиям. Сотрудничество завершается успешно.
Два уровня: графика и текст
Напоследок поделюсь собственным выводом.
Процессная графическая модель – это действительно удобно, как для себя, в процессе поиска решения, так и для взаимодействия с заказчиком. Но в последнем случае этого мало.
Поэтому лучше сочетать:
- Графическую нотацию(она позволяет понять, что именно получит заказчик. Причем, показывает решение максимально наглядно).
- Текстовое описание(здесь следует подробно объяснить, каким образом будет реализовано решение. Текстом можно подробно описать все важные этапы самой процессной модели, здесь же перечисляется необходимое оборудование и программное обеспечение. В текстовом виде предоставляется и план выполнения работ).
Т.е. графика позволяет понять, что именно получит заказчик, а текст поясняет, как это будет реализовано.
Источник: Блог компании Системный интегратор Тринион
