Продолжая тему предыдущего поста, является ли бизнес-процессом “Добыча нефти” или “Продвижение нового продукта”?
Опять-таки, ответ зависит от контекста. В контексте BPMN - однозначно нет. С точки зрения BPMN бизнес-процесс это конкретная последовательность действий, инициируемая определенным событием и завершающаяся тем или иным, но тоже конкретным результатом.
С одной стороны, что такое бизнес-процесс вроде бы знает каждый. Но с другой, затруднительно найти даже двух человек, которые понимали бы этот термин одинаково. Как быть? Заглянуть в книжку? Но в литературе можно найти десятки различных определений бизнес-процессов.
По-видимому надо принять как данность, что единого определения бизнес-процесса нет и не будет. И не имеет смысла навязывать единственно верное определение. Я этого делать и не буду, а всего лишь попытаюсь объяснить, что лично я понимаю под термином “бизнес-процесс”.
Данный паттерн не столь универсален, как, например, «Внутренний заказ», но все же встречается достаточно часто: если не на каждой практике по BPMN, то через одну - точно.
Примеры:
Упрощенная схема иллюстрирует идею паттерна: » читать дальше
На правах рекламы
В 2005, когда мы запускали сайт bpms.ru, и в 2006, когда участвовали в первых конференциях по BPM, в России BPM предлагали буквально единицы.
Сейчас BPM стал раскрученным брендом, на российском рынке активно работает примерно десяток вендоров, и несколько десятков компаний предлагают консалтинг. У многих уже есть квалификация и опыт выполненных проектов. Технически грамотно выполнить BPM-проект сегодня способны многие: смоделировать процесс, разработать модель данных и экранные формы, добавить бизнес-правила, оргструктуру, интеграцию и бизнес-аналитику – и процессное приложение готово.
Но основные проблемы BPM-проектов сегодня не в разработке приложений и вообще не в ИТ. По общению с потенциальными заказчиками, дискуссиям на форумах, выступлениям на конференциях просматриваются две общие проблемы: 1) как получить от BPM реальную, измеримую выгоду и 2) как сделать так, чтобы BPM не остался однократным проектом, а стал частью культуры организации.
Этот вопрос часто поднимается в форме - как «продать» BPM внутри организации. Спонсор проекта не дает себя увлечь голым энтузиазмом, а просит объяснить, как успех проекта отразится на строке прибылей и убытков компании.
Не секрет, что разные люди понимают под BPM очень разные вещи. Некоторые называют BPM старый добрый реинжиниринг с его «as-is» и «to-be», другие - регламентацию бизнес-процессов и/или внедрение Системы менеджмента качества, третьи - автоматизацию бизнес-процессов в ERP-системе, четвертые - покупку и внедрение BPMS, пятые - workflow в ECM-системе и т.д.
Мне лично ближе позиция тех, кто понимает BPM в духе книги Смита и Фингара «Business Process Management: The Third Wave» - как цельную дисциплину, включающую в себя методологическую и технологическую (BPMS) составляющие, а также (добавляю я от себя) принципы реализации проектов Agile. Ключевые классифицирующие признаки BPM в этой трактовке - 1) управление изменением бизнес-процессов в замкнутом цикле и 2) устранение разрыва между бизнесом и ИТ. Такая трактовка мне больше нравится по той простой причине, что я считаю расточительством вводить новый термин для обозначения практик, существующих уже добрый десяток лет. (Аббревиатура BPM стала широко распространяться примерно с 2003 г., в то время как реинжиниринг существует с начала 90-х, а идеи TQM относятся к 80-м.)
Таким образом, мы имеем две основные трактовки BPM:
В свое время Александр Самарин предлагал выработать общеупотребительное определение BPM. К сожалению, общеупотребительное определение может только сложится само, его нельзя «выработать». Достижению консенсуса мешает то, что каждый вендор и консультант в конечном итоге претендует на то, что BPM - это то, чем занимается он или его организация. Ведь BPM - достаточно раскрученный бренд.
Конечно, такое положение дел не способствует росту рынка BPM (в любой из трактовок этого термина). Ведь что должен думать потенциальный спонсор проекта BPM, слыша эту разноголосицу? «Если вы все такие умные и беретесь учить меня, то что же вы друг с другом договориться не можете?!»
Доходит до курьезов: недавно на семинаре bpms.ru один из участников, представлявший крупную российскую страховую компанию, говорил, что BPM-а у них нет, а другие участники семинара убеждали его, на основе его же собственных слов, что есть. Что же такое этот BPM, если мы даже не можем решить, есть он в нашей собственной компании или нет?!
Полагаю, нам следует смириться с тем, что единой трактовки термина BPM нет и не будет - как, к слову сказать, нет и уже не будет единой трактовки термина «бизнес-процесс». Соответственно, каждый желающий высказаться на эти темы, предложить или запросить услугу в этой области, должен начать с определения: что лично он называет BPM и, заодно, что он называет бизнес-процессом. Как минимум, ответственный специалист должен уточнить, имеет ли он в виду BPM в широком или в узком смысле слова.
Но желательно было бы позиционироваться более точно.
За основу классификации я предлагаю взять шкалу зрелости BPM по Гартнеру (Gartner BPM Maturity Model).
В 2006 г. Гартнер предложил 6-уровневую (от 0 до 5) модель зрелости BPM, которую, дабы не нарушать авторские права, я перескажу своими словами:
Последние две фазы я бы отнес к разряду научной фантастики. Подозреваю, их до сих пор никто, включая аналитиков Гартнер, в глаза не видел, и не факт что когда-нибудь увидит. Нулевая фаза - непроцессная. Итого остается три:
BPM-1: Описание и моделирование бизнес-процессов
BPM-2: Управление отдельными бизнес-процессами
BPM-3: Управление сетью сквозных бизнес-процессов
С этим уже можно работать. Все-таки исходная шкала Гартнер столь громоздка и изложена таким языком, что объяснить ее свежему человеку «на пальцах» я лично не способен.
При желании можно выделить подуровни:
Если бы и заказчики, и вендоры/консультанты формулировали свои запросы и возможности, ссылаясь на эту шкалу, то это способствовало бы лучшему между ними взаимопониманию. Например, заказчик мог бы для себя определиться так:
Мы сейчас находимся на уровне BPM-1, в основном пользуемся текстовыми регламентами. Для регулярной сертификации по ISO9000 нам нужна собственная компетенция в полном объеме BPM-1, с графическими моделями и единым каталогом процессов.
Для вспомогательных процессов в области управления персоналом нам нужен внешний консультант с подтвержденной отраслевой компетенцией и квалификацией BPM-2.
Для операционных процессов «от заказа до оплаты» нам нужен внешний консультант с квалификацией BPM-3. Помимо работы над процессами, он должен помочь нам создать собственный центр компетенции, который через 12 месяцев сможет взять на себя 80% работ.
После этого можно подбирать исполнителей среди консалтинговых компаний, работающих на уровнях BPM-1, BPM-2 и BPM-3, и присматриваться к инструментарию:
При этом не следует смотреть на это дело таким образом, что нижние уровни - это плохо, а верхние - хорошо, и что мы изо всех сил должны стремиться достичь верхних уровней зрелости BPM для всех своих процессов. У меня большая претензия к шкале Гартнера из-за того, что она создает именно такое представление.
Ключевые слова - «для всех процессов». Пытаться равномерно поднимать зрелость всех процессов - это верный путь к краху. Закон Парето никто не отменял - условно говоря, 20% процессов отвечают за 80% эффективности компании. Не лучше ли сфокусироваться на этих 20%?
Конечно, BPM-3 обеспечивает намного более полный контроль над процессами по сравнению с BPM-1. Но он ведь и обходится намного дороже! Полноценная реализация сквозного бизнес-процесса в BPMS - это, помимо всего прочего, заказная ИТ разработка. А заказная ИТ разработка дешевой не бывает.
Консультант BPM-3 может добиться более глубокого контроля над бизнес-процессом, но это не дает ему права смотреть свысока на коллег, работающих на уровне BPM-1, так как он способен добиться результата только на относительно узком фронте, а они могут охватить, пусть и не со столь глубоко, деятельность компании в широких границах.
Вторая моя претензия к шкале зрелости Гартнер: она создает представление, что ее надо проходить последовательно, ступень за ступенью. Совершенно не обязательно!
Организация, заразившаяся идеями процессного управления, вполне может поставить себе цель перейти от нулевого уровня BPM на третий. Да, это займет некоторое время, потребует накопления собственной компетенции, но делать промежуточные остановки на уровнях 1 и 2 вовсе не требуется.
Все, что относится к бизнес-процессам, принципиально изменчиво. Например, мы должны быть готовы к тому, что через полгода мы придем к выводу, что какие-то процессы, для которых мы определили достаточным уровень BPM-1, требуют уровня BPM-3. Естественно, хотелось бы видеть преемственность: чтобы результаты работы на уровне BPM-1 были бы использованы при переходе на уровень BPM-3.
Рецепт прост: используйте BPMN.
Принципиальной особенностью этой нотации является методологическая нейтральность - проще говоря, ее можно использовать очень разными способами для очень разных целей.
Что ценно - между этими, достаточно разными, диаграммами будет сохраняться преемственность: превратить аналитическую BPMN-диаграмму уровня BPM-1 в исполняемую BPMN-диаграмму уровня BPM-2 будет проще и намного надежнее, чем, скажем, перерисовывать IDEF0 в BPMN. На уровне BPM-3 альтернативы BPMN практически нет, поэтому лучше придерживайтесь его на всех уровнях.
Да, и чуть не забыл - мы (Бизнес-Консоль) специализируемся на BPM-3.
В прошлой заметке мы рассмотрели ситуацию, когда сообщение из внешнего мира требует предварительной обработки для определения к какому экземпляру процесса оно относится. Но там по крайней мере у нас не было неоднозначности по поводу того, к какому шаблону (типу) процесса относится сообщение: клиент обращается за кредитной картой к клерку (процесс выдачи кредитной карты), резюме попадает в отдел персонала (процесс приема на работу), а информация о поступившем платеже – в финансовый отдел (процесс продажи).
Теперь рассмотрим более сложную ситуацию: документы приходят в компанию обычной почтой по официальному почтовому адресу компании и попадают не напрямую на стол участнику того или иного процесса, а в общую канцелярию. » читать дальше
Рассмотрим процесс выдачи банковской карты клиенту:
Рис. 1. Выдача банковской карты с «пассивной» задачей «Выдать карту».
Обратим внимание на задачу «Выдать карту». Бизнес-сценарий: после того как карта изготовлена, клиент в течение 45 дней должен прийти в отделение банка и получить ее. Если считать, что в среднем клиент приходит за картой через 10 дней, и что отделение выдает по 100 карт в день, то у банковского клерка скопится очередь из 1000 задач. » читать дальше
Напомню, что дорожки (lane в BPMN 2.0, swimlane в BPMN 1.x) изображают исполнителей процесса.
Правила для дорожек:
Начинающие пользователи BPMN любят дорожки и с энтузиазмом рисуют их в своих первых диаграммах:
Рис.1. BPMN-диаграмма с дорожками.
Однако, используя дорожки, вы лишаете себя возможности показать на магистральный путь процесса (happy path), что, возможно, является более ценным с точки зрения легкости восприятия схемы процесса:
Рис.2. BPMN-диаграмма, на которой показан магистральный путь процесса.
Когда же вы переходите к масштабным задачам, то обнаруживаете, что в них применить дорожки не получается.
Дело в том, что существует универсальное правило, применимое к любой нотации, не только BPMN: число активностей на одном уровне диаграммы не должно превосходить 7-9. Иначе схему становится сложно воспринимать:
Рис.3. “Плоская” диаграмма с большим числом активностей сложна для понимания.
Соответственно, если процесс состоит из большего числа задач, его следует подвергнуть структурной декомпозиции – разбить на подпроцессы:
Рис.4. С помощью подпроцессов сложный процесс можно изобразить в виде простой диаграммы.
Однако в этом стиле моделирования для дорожек не остается места:
Точнее, правило 4 относится только к встроенным процессам, а в повторно-используемых процессах дорожки могут быть. Мне приходилось видеть диаграммы, в которых авторы использовали повторно-используемые подпроцессы вместо встроенных исключительно для того, чтобы иметь возможность изобразить дорожки. Это плохая практика – для структурной декомпозиции следует применять встроенные подпроцессы. Повторно-используемые подпроцессы привносят неоправданную дополнительную сложность, так как, в отличие от встроенных, они исполняются в собственном контексте данных.
Если вам так уж необходимо показать исполнителей на схеме встроенного подпроцесса, используйте BPMN-артефакт «группа»:
Рис.5. Исполнители во встроенном подпроцессе изображены группами.
Если вы взялись за достаточно сложный бизнес-процесс, то скорее рано, чем поздно вы столкнетесь с тем, что схема процесса разрослась и стала нечитаемой. Это значит, что пришла пора выполнить иерархическую декомпозицию - проще говоря, разбить процесс на подпроцессы. На BPMN распространяется старое правило: на одном уровне декомпозиции желательно иметь от 5 до 9 активностей.
Рассмотрим в качестве примера процесс заключения договора, состоящий из трех фаз:
Зачастую приходится встречать наивные процессные диаграммы типа следующей:
Мы (Бизнес-Консоль) решили больше не предлагать потенциальным заказчикам пилотные проекты. Сразу говорюсь: идет о проектах PoC (Proof of Concept), которые мы в своей бизнес-практике называем «демонстрационными пилотами».
Сначала расскажу почему, потом – что взамен. » читать дальше
