Реализация бизнес-процессов при помощи чек-листов

В своем блоге я пишу много не очень понятных слов относительно преимуществ адаптивного кейс-менеджмента (adaptive case management) перед системами управления бизнес-процессами (BPMS). На самом деле ACM существенно проще для понимания, чем большинство BPMS, а чек-листы или, если хотите, контрольные списки, намного более простой инструмент, чем модели бизнес-процессов. Не буду углубляться в эту тему. Интересующихся перенаправляю к сообщениям Keith Swenson — Is the Checklist mightier than the Model? и The Checklist Manefesto. От себя отмечу лишь одно преимущество контрольных списков. Модель бизнес-процесса – это всегда довольно высокоуровневая абстракция, т.е. идеальное представление о том, как может развиваться процесс. Глядя на ветвящуюся модель довольно сложно представить по какому пути обычно проходит процесс (см. Петли обратной связи), какие из активностей будут выполнены в большинстве экземпляров процесса, а какие встретятся крайне редко. Контрольные списки объединят модель процесса с его конкретным экземпляром. В определенной степени на контрольный список можно смотреть как на журнал экземпляра процесса, т.е. перечень случившихся в процессе событий и событий, которые должны произойти. Такая форма крайне удобна для восприятия. Именно она позволяет замкнуть ту самую обратную связь между разработкой процесса и его исполнением (round trip).
Ну а теперь о том, как делать «правильные» контрольные списки.

Правило 1. Четкая формулировка результата. Как бы банально это не звучало, но главное в любой нашей деятельности точно понимать, что мы в её результате собираемся получить. Это особенно важно для крупных организаций, разделенных на отделы и департаменты. Известная притча о вопросе камнетесам о том, что они делают и различные ответы на этот вопрос показывают, что такого понимания вряд ли бывает много. Неверное или неоднозначное понимание ожидаемого результата процветает повсюду. Предположим, в компанию обратился клиент с жалобой на качество обслуживания. Технические специалисты априори считают, что обработка такого обращения должна заключаться в поиске и устранении неисправности. Отдел работы с клиентами будет думать немного иначе. Для них важнее сохранение лояльности клиента. Нет смысла ждать пока неисправность обнаружат и ликвидируют. Возможно, целесообразней сейчас вернуть клиенту деньги, а с причиной разбираться потом. Однако, у финансового подразделения есть свое мнение по этому же вопросу… Эти рассуждения можно продолжать до бесконечности, но намного лучше просто записать наши возможности и сопутствующие им ограничения. Кстати, список таких ограничений – это уже отличная основа для построения чек-листа. Своего рода набор бизнес-правил и ограничений, причем заметьте, слабо связанных между собой по времени и последовательности исполнения. Техническому специалисту нет смысла откладывать поиск и устранение неисправности до принятия финансовым контролером решения о возможности возврата части стоимости услуги. Где на диаграмме процесса, и в какой нотации отразить цели действующих в бизнес процессе лиц? С чек-листом такой проблемы просто не возникает. МЫ просто четко описываем ситуацию, в которой хотим оказаться.

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

Правило 3. Подлежащее, сказуемое и дополнение. Принято считать, что диаграммы упорядочивают наше мышление. На самом деле, это не совсем так. Картинка, в какой-то мере, способно облегчить понимание между собеседниками, но для этого её автор должен сам понимать, что же он собирается сказать. В противном случае, модели лишь все еще сильнее запутывают. Хорошее понимание обеспечивается не картинками, а системным подходом. Человеческое мышление – это классификация объектов и явлений и обнаружение отношений между ними. Любой современный язык обладает необходимыми средствами для того чтобы это выразить, надо лишь правильно подбирать слова. Потому действия в чек-листе следует описывать полными и максимально простыми предложениями, например: клиент создает заявку. Я подозреваю, что глаголов может быть не больше пяти (Create, Read, Update, Delete), а подлежащие и дополнения практически всегда могут быть выбраны из соответствующих списков (типы клиентов, перечни услуг, виды обращений и т.п.). Как только один из членов предложения пропадает, моментально теряется смысл. Айтишники очень часто забывают упомянуть того, что совершается действия, а в результате появляются совершенно бессмысленные требования в стиле «система должна…». С дополнениями тоже не всегда хорошо. Зачастую активности бизнес-процесса выглядят так: «клиент обращается в компанию». После такой фразы всегда хочется задать вопрос: «ну и что?». И, безусловно, в современных практиках моделирования данных очень мало распространены глаголы. Найдите мне UML-диаграмму классов с отношением create между классами.

Правило 4. Фиксируйте ответственность и полномочия. Не смотря на важность всех членов предложения в формулировке записи в чек-листе, главная роль принадлежит подлежащему. Это то самое действующее лицо, подразделение, сотрудник, внешняя организация, которое заставляет на данном шаге двигаться наш бизнес-процесс вперед. Это же действующее лицо способно остановить или даже отправить вспять наш процесс по объективным или не вполне объективным причинам. Кроме того, зачастую только данное конкретное лицо обладает возможностью провести с объектом необходимую операцию. Поведет ли оно себя как шестеренка в отлаженном механизме, либо станет палкой в колесе, не всегда зависит от нас. Но мы всегда может четко сформулировать свои ожидания для конкретного шага, причем сделать это в контексте всего процесса. Чек-лист это своего рода соглашение или контракт между участниками процесса о том кто и что делает, регламентирующий вклад каждого участника в достижение общей цели. Диаграммы, особенно включающие замкнутые циклы, не обладает необходимой ясностью и простотой. Что приводит к диалогам типа:

— Когда вы выполните наш новый заказ?
— А когда вы заплатите за старый?
Впрочем, об этом следующее правило.

Правило 5. Выявляйте и обрабатывайте исключения. Адаптивный кейс-менеджмент ставит своей целью адекватно реагировать на возникающие события. Есть определенная мудрость в том, чтоб решать проблемы по мере их появления. Точно так же, как есть определенная глупость в попытке предусмотреть все возможные и не возможные варианты развития событий. Любое событие в чек-листе, по тем или иным причинам может не состояться в ожидаемый срок. Дисциплина управления рисками для того и существует чтобы своевременно выявлять такие события. На самом деле, эволюция бизнес-процесса в том и заключается, что с каждым экземпляром процесса мы узнаем что-то новое о поведении окружающей нас среды. Гибкость – это свойство процесса, заключающееся в сохранении работоспособности, несмотря на возникающие изменения. Существует два способа обеспечить эту самую гибкость. В первом случае, при проектировании процесса аналитик пытается предусмотреть все возможные варианты развития событий. Этот способ требует существенных затрат времени и ресурсов. Причем затраты осуществляются на этапе разработки процесса, т.е. в тот момент когда реальная отдача от процесса еще отсутствует. Зачастую, увеличение затрат на этом этапе приводит к отрыву от реальности и может закончится так называемым аналитическим параличом, ситуацией когда изменения в процессах происходят быстрее, чем аналитик может их задокументировать. Второй подход заключается в том, что аналитик находится внутри процесса и выполняет функцию его адаптации к выявляемым изменениям. Т.е. ошибки и исключения обрабатывает не компьютерная программа, а человек, с присущей ему гибкостью ума и широтою мышления. Конечно, если конкретное исключение происходит в значительном количестве случаев, обработку его следует автоматизировать. Еще лучше, если выявление исключений и создание процесса их обработки будет происходить с небольшим упреждением, но это уже тема облачных вычислений(и не только вычислений). Оставив её в стороне, я хотел бы обратить внимание на еще один аспект исключений. Бывают хорошие исключения (клиент отказался от претензии), но бывают и плохие. Самыми неприятными, являются исключения, отбрасывающие нас на несколько шагов назад, т.е. требующие повторного выполнения пунктов нашего чек-листа. Уточнения, доработки, изменения требований, вновь открывшиеся обстоятельства – это огромная проблема современных бизнес-процессов и это же одна из причин появления adaptive case management. Традиционные BPMS разработаны в предположении, что процесс стартуют «с нуля» и что процесс завершается, иногда успешно иногда нет. Реальная жизнь показывает, что экземпляры процессов тесно сплетены друг с другом в сложнейшую сеть бизнес-процессов. Стройки замораживаются и возобновляются. Неисправности ликвидируются, но затем появляются вновь. Услуга, разработанная для одного клиента, но им невостребованная, оказывается полезной другому и т.д. и т.п. Кейс-менеджмент это попытка как следует разобраться в связях между разными инстансами разных процессов. Понять что их объединяет. Собрать воедино обращение одного и того же клиента, связанные дела, схожие проблемы и обращения клиентов, связать экземпляр с классом или же выделить в отдельный класс схожие последовательности работ. Никогда не понятно, что лучше сделать: вернуться на ранний шаг текущего процесса или же остановить экземпляр процесса и запустить новый. Однако фиксация происходящих в процессе событий, наблюдение его трека позволяет нам избежать бесконечных циклов.

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

Реализация бизнес-процессов при помощи чек-листов: 11 комментариев

  1. Все так, весь Adaptive Case Management крутится фактически вокруг чек-листов, представляющих собой список из чек-пойнтов или milestones — контрольных точек.

    Для ACM такой чек-лист из контрольных точек — это то же самое, что для «традиционного» BPM «happy path» — основной перечень действий, которые надо сделать и представление о которых имеется перед началом процесса. В ACM этот перечень по мере исполнения процесса корректируется и дополняется.

    Собственно, обработка статусов контрольных точек (открытие, закрытие, отмена, деактивирование, назначение и контроль сроков исполнения) + информационные сообщения (дискуссии и отчеты о предпринимаемых действиях) — это и есть основной функционал ACM

    Опять привожу в пример конкретный продукт — PayDox Case Management. В нем основные действия — это именно обработка milestones — контрольных точек и выставление им статуса, причем статусу «закрыто» как раз и соответствует пиктограмма с галочкой — аналог бумажного чек-листа.
    Фильтры меню позволяют увидеть и на лету сформировать все такие необходимые списки контрольных точек в разных разрезах:
    «Открытые» – актуальные сообщения
    «Требующие ответа» – сообщения, требующие создания ответных сообщений
    «Просроченные» – открытые сообщения с просроченной датой исполнения
    «Созданные мной» – сообщения, созданные текущим пользователем
    «Для меня» – сообщения, адресованные текущему пользователю

  2. А причем тут «облачные вычисления» ? Я конечно понимаю тренд, но вроду и тут не блог маркетолога

    с небольшим упреждением, но это уже тема облачных вычислений(и не только
    вычислений)

    1. Мне кажется предпочтительным в контексте данной темы развивать вместо абстрактных «облачных вычислений» концепцию распределенного хранения и ведения таких чек-листов (кейсов, на самом деле), скажем, часть действий (и соответствующих чек-боксов, т.е. контрольных точек чек-листа) поддерживается на стороне заказчика (исполнение заказа …), а часть на стороне клиента (платеж, приемка ..), в результате появляется задача поддержки распределенных по нескольким сайтам кейсов с возможностью их консолидированного просмотра на любом из таких сайтов. В такой постановке задача мне вполне понятна и реализуема

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

  3. На самом деле, с ACM как таковым понятием столкнулся недавно и, к своему удивлению, не нашёл в нём «много нового»:). Хотел бы рассказать свои выводы, как можно технологически решать проблему изменчивости процессов и поддержку их актуальности.

    По опыту (Apache ODE и другие open-source) предпочитаю закладывать расширения/гибкости за счёт поднятия «принятия решений» с процесса на человека, далее описание некоторого корпор.фреймворка, где смешаны шаблоны BPM, Web2.0, социальных инструментов и event-driven:
    * представление процесса больше не workflow, а в стиле state-machine business entity (привет IBM http://www.ibm.com/developerworks/ru/library/0610_beers/🙂 — где граф переходов и их бизнес-правила точно понятны бизнес-менеджерам (следует из предметной области), а вот всякие детали обеспечения переходов в процессе и т.п. — инкапсулированы (в связке с ESB) и понятны аналитику. Собственно, такой подход создаёт условия для взаимодействия с процессом больше в event-driven: входящие в процесс события инициируют переходы, процесс генерирует события которыми общается с другими процессами-машинами. Очевидно, связка на основе событий (pub/sub) достаточно мощная, хотя сложнее реализовать конечные сервисы/потребители процесса (они должны работать в асинхронном режиме).
    * бизнес-события семантически классифицируются (с TopicMap), собираются в какой-то GUI-Журнал (вплоть до простого представления событий топиков в виде RSS-лент в REST-стиле), счётчик BAM (сброс в БД, Hadoop с последующей агрегаций и отчётностью), CEP и т.п. На получение событий можно подписываться, события доступны для анализа и настройки генерации на основе них пиналок каких-нибудь саппортов или просто возможности отображения всего жизненного цикла процесса (например, заказа). Журналы событий легко представить, удобны и дают возможность для бизнес-менеджеров принимать решения об оптимизации, проведению расследований и др.
    * в процессах выделены т.н. «точки задач» — там где нужно участие человека, нелинейная логика, использование сторонних систем. В точках происходит генерация событий с задачей для какой-нибудь ticket-системы (RequestTracker, jabber etc): «подтвердить документ», «обработать заказ» — при этом сам процесс переходит в промежуточное состояние ожидания подтверждения-ответа по задаче (используется специальная подписка на «оповещение о решении задачи»).
    * много wiki, URL-ссылки на процесс, ленту журнала (REST-GET), тикеты-событий и др. — для упрощённого построения GUI Mashup c данными из процессов.
    * сам по себе процесс содержит мало бизнес-данных (только необходимые для работы машины), а больше ссылок на них (в wiki, rss и др.), которые можно включать в процесс в любом, «адекватном» кол-ве в стиле key-values — именно эти данные передаются в событиях и задачах, соответственно, создавая подписки на них и принимая запросы, мы получаем, по-сути, весь изменяемый контекст (документы, данные клиентов и т.п.) в виде ссылки. Да, здесь возможны коллизии, что какие-то ссылки протухли и т.п. — но, скорей всего, человек получит эти ссылки и сам будет разбираться с тем, куда они пропали, добавить новые ссылки; либо mashup агрегируя инфу сможет отрезолвить ситуацию.

    При этом, на практике получается, что чаще всего меняется не сам процесс business entity, а какие-нибудь ссылки в его данных, подписчики на события или mashup — т.е. потребительская часть BPMS, а не он сам… Хотя может у меня не та практика, с которой сталкиваются коллеги:).

  4. Максим, вы применяете при описании процессов технику ВИСИ? http://it-4-all.blogspot.com/2010/06/blog-post_14.html

    Мне она очень помогла и сейчас каждый раз при начале описания процесса или проектирования какой то задачи я понимаю что мыслю именно так. И это очень помогает.

    А что касается чек-листа… то тут у меня мысли такие:
    1. Мне кажется по похожей теме сделали gosuslugi.ru. Там на каждую услугу (процедуру, цель) есть множество полей, от описания результата, требований к входящим документам, причин для отказа и т. д.
    2. Вроде бы похожая техника применяется в businessstudio.ru. Там тоже на каждый процесс по сути фиксируются конкретные элементы.
    3. Ну и я печенкой чую что это круто и да это правильно… но вот не могу словами выразить )
    Было бы круто какой нибудь пример… я правильно понимаю что эта техница не зависит от инструментов? Ну например процесс с чек-листам можно и в Word’е описать?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *