Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Процессный паттерн: Снова здравствуйте!

Рассмотрим достаточно типичный бизнес-процесс:

  1. потенциальный заказчик обращается с запросом коммерческого предложения
  2. мы готовим и отправляем коммерческое предложение
  3. заказчик принимает решение
  4. в случае положительного решения заключаем договор

Первая версия процессной диаграммы:


Рис.1. От запроса до договора

Отправив коммерческое предложение, мы периодически связываемся с клиентом, чтобы узнать, созрел ли он для размещения заказа.

Чем плоха эта схема, чего она не учитывает:

1. Клиент может обратиться с заказом, минуя стадию запроса коммерческого предложения.

Эту проблему можно решить, предусмотрев альтернативный старт процесса:


Рис.2. Альтернативный старт: минуя коммерческое предложение

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

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

Отсюда решение: рассматривать этапы «От запроса до коммерческого предложения» и «От заказа до договора» как два потока работ:


Рис.3. “Снова здравствуйте”: коммерческое предложение и договор

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

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

Паттерн «Снова здравствуйте» применяется в точке процесса, где управление переходит на сторону внешнего агента (например, клиента) и у него нет по отношению к нам твердых обязательств. В такой точке процесс следует разделить на два потока работ, связанных через данные.

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


Рис.4. Альтернативный старт: автоматический переход к договору

Продолжим рассмотрение бизнес-процесса от заключения к исполнению договора.

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

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

Опять применяем паттерн «Снова здравствуйте» – реализуем заключение и выполнение договора отдельными потоками работ:


Рис.5. “Снова здравствуйте”: Договор и Исполнение договора

При поступлении аванса идентифицируем договор по номеру счета и/или клиенту и приступаем к выполнению работ.

Опять-таки, в жизни все несколько сложнее: 1) по договорам с доверенными клиентами оплата производится по факту, 2) в некоторых случаях компания на свой страх и риск начинает выполнять работы, не дожидаясь аванса. Отразим эти сценарии в диаграмме:


Рис.6. Альтернативные старты: без аванса, на свой страх и риск

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

Завершаем эту ветку процесса сигналом «Работы не оплачены». Здесь мы применили паттерн «Обрубить концы», о котором речь пойдет в следующий раз.

20.06.12 | Статьи | ,    

Комментарии (9)

  1. Олег 25.06.12 09:05

    Добрый день, я бы не стал совсем убирать цикл “справиться о решении”, в отдельных случаях необходимо вести сделку более плотно
    - отправили кп
    - клиент посмотрел, оценил, деньги ждёт через квартал
    - за это время конкуренты подсуетились и предложили своё КП
    - ………
    Скорее всего это отдельный процесс мониторинга выставленных КП

  2. Anatoly Belychook 25.06.12 09:31

    Олег

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

    У меня вообще все очень упрощенно показан этот процесс. Можно попытаться отправить заказчику сначала проект КП, получить его реакцию, доработать и отправить окончательный вариант. Можно предусмотреть возможность корректировки его уже после отправки “окончательного” варианта и т.п.

    Суть моего предложения в том, что в конце концов процесс подготовки КП надо завершать, а не длить его бесконечно. Или до того, как заказчик примет решения - это в сущности то же самое.

    Завершить этот, но быть готовым открыть новый процесс.

  3. Олег 25.06.12 10:14

    Лучше не в исходном процессе, а в отдельном процессе
    Думаю что данная ситуация встречается довольно часто
    как раз 3 процесса
    Подготовка КП
    Мониторинг - периодические контакты с клиентом
    Реализация контракта

    То что упрощено - согласен, принцип понятен, дальше нюансы конкретных процессов

  4. Anatoly Belychook 25.06.12 10:30

    Все зависит от того, насколько жестко мы хотим организовать мониторинг:
    - если по какому-то определенному плану и с напоминаниями исполнителю, то реализовывать надо в том же процессе
    - если по принципу “менеджер сам вспомнил - позвонил - отчитался о результате звонка”, то в отдельном

    Если мониторинг делать отдельным процесса, то в промежутке между двумя контактами с клиентом у нас не будет процесса, который бы “помнил”, что пора снова с ним связаться.

  5. Олег 25.06.12 10:48

    если КП в базе, с признаками - мониторинг, ответственный
    то почему нельзя запускать копии процессов по таймеру на ответственного ?

  6. Anatoly Belychook 25.06.12 11:30

    Можно, почему нельзя.

    По сути, Вы предлагаете сделать “процесс для бедных” в виде записи в базе и программы, которая такие записи периодически сканирует.

    Смысл?

  7. Олег 25.06.12 12:45

    Скорее для “богатых” :)
    Впрочем готов согласиться, в этом контексте это не имеет смысла

  8. Александр 09.02.13 11:49

    Анатолий, смотрю уже не первую вашу статью, и везде вижу очень упрощенные примеры. Хотя и больших, достаточно важных процессов.
    И в этом статье не вижу того блока, который идет всегда при решении школьных задач - “Дано” с описанием начальных условий, ограничений и т.п.
    Старик Деминг придумал когда-то цикл управления - PDCA. Во всех ваших примерах звучит только “Do”, остальные элементы процесса не видны. Не описываете Вы их и при словесном описании процесса.
    Я не очень хорошо разбираюсь в BPMN, поэтому хотел уточнить - это ограничение самого стандарта (всё становится слишком сложным),. или вы принципиально упрощаете?

  9. Anatoly Belychook 10.02.13 11:00

    Александр

    Этот блог и эта статья вообще-то не для школьников. С интересом познакомлюсь с Вашими статьями, следующими шаблону школьных задач.

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

    Цикл PDCA применительно к моделированию процессов выглядит так:
    P - определить метрики и целевые показатели процесса и на их основе разработать схему процесса
    D - исполнять процесс согласно утвержденной схеме, накапливать статистику исполнения
    C - анализировать статистику на предмет достижения целевых показателей
    A - вносить коррективы в процесс на основе выявленных расхождений и неоптимальностей

    К BPMN это прямого отношения не имеет - цикл останется тем же самым вне зависимости от используемой нотации.

    Вы, похоже, под PDCA понимаете нечто иное, но я не улавливаю что именно.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии