В своем блоге я пишу много не очень понятных слов относительно преимуществ адаптивного кейс-менеджмента (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 разработаны в предположении, что процесс стартуют «с нуля» и что процесс завершается, иногда успешно иногда нет. Реальная жизнь показывает, что экземпляры процессов тесно сплетены друг с другом в сложнейшую сеть бизнес-процессов. Стройки замораживаются и возобновляются. Неисправности ликвидируются, но затем появляются вновь. Услуга, разработанная для одного клиента, но им невостребованная, оказывается полезной другому и т.д. и т.п. Кейс-менеджмент это попытка как следует разобраться в связях между разными инстансами разных процессов. Понять что их объединяет. Собрать воедино обращение одного и того же клиента, связанные дела, схожие проблемы и обращения клиентов, связать экземпляр с классом или же выделить в отдельный класс схожие последовательности работ. Никогда не понятно, что лучше сделать: вернуться на ранний шаг текущего процесса или же остановить экземпляр процесса и запустить новый. Однако фиксация происходящих в процессе событий, наблюдение его трека позволяет нам избежать бесконечных циклов.
Похоже, много материала получается вокруг чек-листов, а тема все еще раскрыта не полностью. Наверное, стоит сделать их этого презентацию, статью или электронный курс. Потому я буду признателен за комментарии к этому сообщению