Литература:

• Статьи
• Обзоры:    0    0    17    16    15    14    13    12    11    10    9    8    7    6    5    4    3    2    1  
• Форумы
• Стандарты
• Книги
• Авторы

Сравнение нотаций UML и BPMN

Сейчас многие говорят о нотациях и языках моделирования бизнес-процессов. Кто и по какой причине делает выбор в ту или иную пользу - такой вопрос довольно часто звучит в обсуждениях на различных форумах. Вот одна из точек зрения, предложеная Андреем Михеевым, компания "Руна".

=WJ

>> Комментарии (всего 0)

Время ли сейчас думать о BPM? Взгляд с позиции бизнеса

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

Пожалуй, как никогда остро вопрос повышения эффективности встал перед большинством компаний именно сейчас, в период мирового спада. Точнее, даже не совсем повышение эффективности. Скорее это звучит так: надо как-то выжить, и все способы для этого хороши. И самый распространенный и, казалось бы, логичный способ выживания – сокращать, сокращать, сокращать! Сокращать персонал, бюджеты, расходы. Ну, тут ничего нового нет, это мы все можем.  Но цель-то не в этом! Цель не в выживании, не в сокращении. Цель – добиться максимальной эффективности с минимальными ресурсами и затратами. И для этого существуют более цивилизованные средства.

Лаура Муни (Laura Mooney, вице-президент по корпоративным связям компании Metastorm) статье «How to Use Business Process Management and Enterprise Architecture Tools to Thrive in a Recession» предлагает вместо слепого сокращения всего и вся обратить внимание на технологии, которые помогут не просто выжить, но и вырасти в период спада мировой экономики. Одна из таких технологий - BPM. Четыре пути экономии средств при помощи BPM:

1.       Повысить эффективность

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

2.       Извлекать больше из того, что у вас уже имеется

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

3.       Снизить риски

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

4.       Выявить балласт

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

BPM не только добавляет выгоду разными путями, но организации, применяющие BPM, постоянно рапортуют о 10-20% возврате инвестиций с каждого проекта.  Короче говоря, BPM-система может помочь усилить корпоративную инфраструктуру, делая организацию более эффективной и более гибкой. И как только в экономике наметятся положительные сдвиги, такая организация будет готова воспользоваться новыми возможностями лучше, быстрее и выгоднее, чем их конкуренты.

Скотт Кливленд (Scott Cleveland, менеджер с 25-летним стажем, консультант по бизнес-процессам) в статье BPM from a Business Point of View. The Value of Business Process Management пишет, что получил от специалиста по развитию документ, в котором перечислялись выгоды, которые можно получить, применяя BPM:

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

Скотт дополнил этот список:

• Повышается контроль над временем цикла процесса – используя программное обеспечение BPM, компании могут определить, как много времени занимает процесс. Используя эскалацию и наглядность состояния процесса, они могут быть уверены, что процесс завершится в течение установленного периода времени.
• Снижение издержек - сокращение расходов за счет устранения не добавляющих стоимость действий и добавления процессу эффективности.
• Увеличение доходов - снижение затрат и производство большего количества товаров / услуг с меньшим количеством людей поможет увеличить доходы. 
• Повышение удовлетворенности клиентов - когда мы говорим о создании стоимости, это ли не о заказчике, который определяет стоимость? Процессы, которые контактируют с заказчиком, должны иметь наивысший приоритет».

В завершении можно привести результаты опроса, который проводила компания Metastorm среди своих действующих клиентов (т.е. это опрос среди компаний, которые уже применяют у себя BPM).  Об этом рассказал Дэннис Байрон (Dennis Byron, ebizQ's Community Manager) в недавней заметке «BPM VIEWPOINT: Are You Asking Yourself the Hard Questions about BPM in Today's Economy?». Было задано два вопроса.

Первый вопрос: На чем будет сфокусировано улучшение бизнес-процессов в 2009 году?

Варианты ответов, среди которых можно было выбрать несколько:

1. Процессы, относящиеся к производству товаров/услуг
2. Внутренние административные процессы
3. Соблюдение законодательства и управление рисками
4. Обслуживание клиентов
5. Цепочки добавления ценности
6. Другое

64% респондентов выбрали первый ответ, 44% - второй, 31% - третий, 29% - четвертый и 24%  - пятый. Учитывая, что пятый вопрос практически в точности повторяет смысл первого, вполне можно объяснить, почему он получил так мало голосов.

Второй вопрос звучал так: Каким образом, по-вашему, BPM поможет вам пережить рецессию 2008-2009 гг.?

Варианты ответов:

1. Повышение производительности труда
2. Усиление контроля и наглядности
3. Снижение расходов
4. Снижение риска
5. Определение недостаточного использования накладных расходов 
6. Большая гибкость и позиционирование на рынке в период упадка
7. Управление слияниями и поглощениями

Примерно 67% отвечавших сказали, что BPM помогает им повысить продуктивность сотрудников. Совсем близок по популярности был ответ «усиление контроля и наглядности» - 64%. Интересно, что снижение расходов было не столь популярным, как первые два пункта – только 46%. И еще 30% выбрали шестой ответ.

Полученные ответы еще раз доказывают, что то, о чем говорили и Лаура Муни, и Скотт Кливленд, подтверждается практикой. И в период кризиса не стоит забывать, что после спада последует подъем, к которому нужно быть готовыми.

=WJ

>> Комментарии (всего 0)

Состоялся первый семинар BPMS.ru для BPM-профессионалов

20 мая состоялся запуск регулярных семинаров для BPM-профессионалов, задуманных не как ликбез по теме BPM, а как возможность обсуждать конкретные решения в области автоматизации бизнес-процессов.

На первом семинаре был рассмотрен бизнес-процесс логистической компании, реализованный компанией Бизнес-Консоль в рамках пилотного проекта в BPM-системе Unify NXJ.

Семинар прошел в традициях научной школы: доклад, выступление оппонента, обсуждение. По качеству заданных вопросов можно сделать вывод, что собравшиеся – не новички в BPM. Вопросы касались как методологической части, так и технической реализации. В частности, подробно разбиралось, какая бизнес-задача была решена в ходе проекта, почему компания предложила именно это решение и как изменился взгляд заказчика на процесс в связи с предложенным решением. В ходе обсуждения были рассмотрены возможности альтернативной организации отслеживания состояний объектов в BPM-системе.

Вместо запланированных двух часов семинар продлился почти три. При этом регламент официальной части был выдержан четко: начало ровно в 19-00 (любителям опаздывать на заметку!), время выступлений и вопросов отслеживалось. Но что касается дебатов и кулуарных обсуждений за чашечкой кофе, то им смогла помешать только охрана, вежливо намекавшая на поздний час.

 

Отзыв участника семинара Никиты Сушко:

«Второй (вообще-то первый- прим.автора) семинар удался на славу.
Всегда приятно смотреть на работу профессионала.
А если к филигранной технике добавить непринужденный стиль изложения и четкую работу с вопросами получится... выступление Юрия Григорьева.
Академический формат выдержан не в ущерб интерактиву, за что большое спасибо Анатолию Белайчуку.
Мероприятие затянулось на час свыше заявленного, и расходиться не хотелось. Да и чай, организованный хозяевами помещения, оказался очень хорош. Всем без исключения участникам хотелось пообщаться с организаторами в кулуарах.
Что до меня - удалось получить ответы на интересующие вопросы и хороший посыл для того, чтобы поплотнее познакомиться с Unify NXJ.
Единственный минус - на это семинар не удалось "вытянуть" своих друзей, но к следующему обязательно исправлюсь.»

Пользуясь случаем, благодарим Российский новый университет (www.rosnou.ru) и Кафедру корпоративных информационных систем, предоставивших помещение для семинара.

Следующий семинар состоится 24 июня.

=WJ

>> Комментарии (всего 0)

Сохранить нельзя трансформировать

Чаще всего BPMS подразделяют на ориентированные на работу с людьми (human-to-human) и ориентированные на оркестровку информационных систем (system-to-system). Иногда дополнительно выделяют ориентированные на работу с документами (document-oriented) и на рассмотрение кейсов, т.е. «дел» (case-oriented).

Это деление отражает различие не только и не столько в назначении, сколько в происхождении конкретных систем. Ведь несмотря на то, что термин BPM получил широкое распространение только примерно с 2003 года, большинство сегодняшних BPMS ведет свою родословную из 90-х:

• human-to-human BPMS «в прошлой жизни» – это workflow-системы
• system-to-system BPMS, как правило, выросли из интеграционных пакетов (EAI framework)
• document- и case-oriented BPMS – это новое название для систем управления документооборотом

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

Не так давно Кейт Свенсон предложил более конструктивную классификацию – основанную не на предназначении/происхождении систем, а на архитектуре. Он выделяет системы с сохранением процессной модели и системы с трансформацией процессной модели. Эта классификация с разных сторон рассмотрена в серии заметок на его блоге:

1. Model Strategy: Preserving vs. Transforming
2. Model Strategy & Analytics
3. Model Strategy, Round-Trip & Agile Development
4. Model Strategy & Performance
5. Model Strategy & Simulation

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

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

Так как эта модель привычна для программистов, ИТ-специалисты часто склонны и на BPM смотреть под этим же углом – как на еще один способ преобразования высокоуровневой модели в исполняемый код. Здравый смысл подталкивает нас к тому, чтобы продолжать использовать подходы, которые себя оправдали, и именно эту философию проповедуют вендоры, придерживающиеся стратегии трансформации процессной модели, и в частности, те, что предлагают трансляцию из BPMN в BPEL.

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

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

• Поддержка замкнутого цикла (round-trip). Суть проблемы: небольшие изменения, вносимые в модель процесса бизнес-аналитиком, не должны приводить к необходимости для программиста делать его работу заново. Здесь мы сталкиваемся с задачей, которая в системах контроля версий называется слиянием версий (merging) – в данном случае, со слиянием правок, сделанных аналитиком, с правками, сделанными разработчиком. В стратегии сохранения модели проблемы не возникает, а в стратегии трансформации возникает нетривиальная, хотя и решаемая задача.
• Видимость состояния исполняемого экземпляра процесса и способность реагировать на проблемы, возникающие на этапе исполнения. Возможность вмешаться в ход выполнения уже запущенного процесса и изменить схему уже запущенного процесса является достаточно востребованной. Очевидно, что решать задачу трансформации, нетривиальную саму по себе, не на этапе разработки, а на этапе исполнения – дело крайне затруднительное. Поэтому стратегия сохранения модели в этом аспекте обладает явным преимуществом, за исключением случая короткоживущих процессов с относительно простой логикой.
• Степень полезности аналитических данных. Аналитика, собираемая движком бизнес-процесса, всегда относится к исполняемой модели. Если бизнес-модель нетривиальным образом от нее отличается, то это затрудняет интерпретацию собираемой статистики в терминах бизнес-модели. Очевидно поэтому, что в этом аспекте стратегия сохранения модели имеет преимущество.
• Поддержка имитационного моделирования и оптимизации. Аналогично предыдущему пункту, результаты имитационного моделирования обязаны быть проинтерпретированы в рамках бизнес-, а не исполняемой модели, поэтому трансформация модели представляется нежелательной.
• Поддержка гибкой (agile) итеративной разработки. Фактически, это та же самая поддержка round-trip (п.1), только «на сверхзвуковых скоростях». Необходимость не просто уметь объединять правки аналитика и разработчика, а делать это непрерывно, автоматически и без задержки, делает преимущество стратегии сохранения модели более явными.
• Производительность. Теоретически, в этом аспекте стратегия трансформации имеет преимущество. Но это аналогично преимуществу компилируемых языков (C++, Fortran) перед интерпретируемыми (JavaScript, PHP). Там, где производительность – ключевой параметр (например, в СУБД или научных расчетах), там компилируемые языки имеют преимущество; в остальных случаях большее удобство работы с интерпретируемым или промежуточным (Java) кодом подталкивает к выбору в их пользу.
• Легкость работы для программиста. Программист предпочитает работать в привычной для него среде и с привычным инструментарием. Модели, создаваемые аналитиками, к числу таковых не относятся, поэтому с точки зрения разработчика, стратегия трансформации выглядит предпочтительной. Все зависит от соотношения между объемом работы над моделью и над программным кодом (в частности, от размера и сложности интеграционных задач). Стратегия трансформации будет выглядеть более предпочтительной в проекте, тяготеющем к чисто интеграционному.

Объективности ради следует заметить, что Кейт является заинтересованным лицом, так как продукт его компании – Fujitsu Interstage – очевидно следует стратегии сохранения модели. Чтобы составить более полную картину, рекомендуем познакомиться с аргументами противоположного лагеря. Например, с заметкой «Why BPEL Matters» на блоге Исмаэля Галими из Intalio – пожалуй, самого активного проповедника стратегии трансформации BPMN-BPEL.

=АБ

>> Комментарии (всего 0)

Подборка мнений на тему simulation

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

Если вы подумали, что это старый добрый метод «Монте-Карло», то вы совершенно правы, несмотря на то, что этот термин в литературе по BPM не встречается. Понятно, что это метод может быть полезен при проектировании нового или ревизии существующего процесса: например, с его помощью можно заранее просчитать последствия того или другого усовершенствования и выбрать из них оптимальный. Типичная задача такого рода: есть финансовый контролер, специалист с относительно высокой зарплатой, проверяющий авансовые отчеты. Вопрос: какую экономию мы получим, если введем в процесс второго исполнителя с более низкой квалификацией и зарплатой, и будем направлять ему авансовые отчеты на сумму меньше 1000 рублей?

Более изощренные реализации имитационного моделирования позволяют подавать на вход фактически наблюдаемые распределения (так называемый round-trip optimization). То есть, в примере выше не строить догадки о том, какова в среднем доля авансовых отчетов на сумму меньше 1000 рублей, а воспользоваться данными завершившихся экземпляров этого бизнес-процесса, уже накопленными BPMS.

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

Недавно в блогах произошел интенсивный обмен мнениями по поводу реальной пользы от имитационного моделирования.

1. Джим Синур из Gartner в заметках «Optimizing Costs? Try Simulation» и «Extra, Extra: Simulation is Bi-Optimal» развенчивает представление о том, что имитационное моделирование – это нечто сложное, требующее большого объема тестовых данных на входе и полезное только при проектировании бизнес-процесса с нуля. Он отмечает, что современные инструменты не требуют глубоких познаний в математике, позволяют подавать на вход накопленные исторические данные и могут эффективно использоваться не только при первоначальной разработке, но и для выбора наилучшего варианта оптимизации процесса в дальнейшем. С его точки зрения, имеющийся сегодня потенциал средств имитационного моделирования недооценен пользователями.
2. В принципе, ему и по должности положено быть оптимистом. Но в заметке «The Hype about Simulation and Optimization» ему оппонирует Рашид Хан, бывший глава Ultimus, а ныне независимый консультант, регулярно выступающий с критических позиций. Он считает оптимизм поводу возможностей имитационного моделирования чрезмерным, отмечая, что для качественного моделирования требуется большой объем исходных данных, которые не так-то легко собрать. Причем если эти данные не будут достаточно точными, то не стоит многого ожидать и от результатов моделирования – «garbage in, garbage out». Имитационное моделирование не подскажет вам путей возможного усовершенствования, то есть помимо владения инструментом вы должны быть сильны как бизнес-аналитик. И вам таки понадобятся знания в области математической статистики. В комментариях к этой заметки отметились несколько авторитетных специалистов.
3. Кейт Свенсон из Fujitsu в заметке «Model Strategy & Simulation» повторяет уже высказанные аргументы о сложности подготовки входных данных. К ним он добавляет соображение о том, что доверять результатам имитационного моделирования в BPMS, построенных на трансляции моделей (распространенный сегодня вариант – трансляция из BPMN в BPEL) можно в меньшей степени, чем системам, в которых BPMN исполняется непосредственно (по чистому совпадению, BPMS от Fujitsu относится именно к этому второму типу).
4. И наконец, заметка Брюса Силвера «Making Simulation Useful». Он считает, что имитационное моделирование – это одна из тех фальшивок («fake feature»), которые вендоры вставляют в свои продукты только чтобы получить галочку в сравнительном обзоре Gartner, но которые не приносят никакой реальной пользы. Он говорит об этом с сожалением, потому что потенциально моделирование дает возможность оценить эффект затеваемых усовершенствований прежде, чем тратить свои ресурсы на их осуществление. Далее он подробно останавливается на основной методологической проблеме, которая этом препятствует (Рашид Хан ее тоже упоминает). А именно: мы не в состоянии разделить время, в течение которого задача была назначена исполнителю («total time»), на время, непосредственно затраченное им на выполнение задачи («active time») и время, в течение которого задача ожидала своего рассмотрения («wait time» или «lag time»). К сожалению, инструментарий имитационного моделирования зачастую не делает различия между total time и active time, и это в значительной мере обесценивает получаемые ими результаты. Плюс к этому в существующих пакетах возникают проблемы с моделированием межпроцессных событий (message flow в BPMN), с учетом корреляцией между значениями различных параметров (предполагать, что параметры независимы – это явно чрезмерное упрощение) и другие. Всего Брюс насчитывает семь критериев оценки качества имитационного моделирования, а лучшие из известных ему систем удовлетворяют всего трем. Впрочем, некоторые комментаторы к его заметке указывают, что инструментарий, удовлетворяющий всем критериям, все же можно найти.

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

=АБ

>> Комментарии (всего 3)

BPM: причины неудач

Почему такая, казалось бы, прогрессивная идея как BPM, буксует?. Рынок BPM-продуктов и услуг совершенствуется, технология просто «прорывная»… а где очереди за BPM-системами? Где вал успешных внедрений?

Анализируя причины, по которым проекты BPM терпят неудачу даже там, где есть и деньги и желание, Глен Смит в своей статье «How (not) to Fail at BPM» приводит 10 ошибок, которых следует избегать при реализации BPM-проектов:

1. Без поддержки бизнеса (бизнес-спонсора) BPM превращается в очередную «игрушку» для ИТ. Если, к тому же, бизнес-собственник не участвовал в выборе BPM-системы, то она вообще может не отвечать его потребностям. И он вообще имеет к ней малый интерес. Система в таком случае может использоваться для внутренних проектов, но едва ли получит широкое применение.
2. Если бизнес принимает решение о покупке системы без привлечения ИТ (случай, обратный предыдущему), , то могут возникнуть сложности с интеграцией системы с внешними приложениями. Следует помнить, что BPM – не отдельно стоящее решение, а слой поверх существующих приложений и инфраструктуры.
3. Неудачно выбранный проект, не приносящий ощутимую выгоду бизнесу. Следует помнить, что BPM должен дать выгоду акционерам. В противном случае, даже если удастся реализовать все как задумано, не будет ожидаемого возврата инвестиций. Это наиболее распространенная ошибка.
4. Попытка объять необъятное на первом же проекте. BPM- нововведение для организации. Следует выбирать для первого шага достаточно простой и понятный процесс. Это может расходиться с предыдущим утверждением, однако это позволяет снизить риски. Это может быть процесс одного департамента, что поможет избежать кросс-функциональных проблем. Либо можно параллельно запустить несколько небольших процессов, объединив их позже.
5. Большое количество внешних зависимостей, что требует достаточно сложных технических решений. По возможности оставьте проблемы интеграции для последующих итераций. Если вам удастся доказать состоятельность BPM, то легче будет получить финансирование для решения этих проблем. Если в организации есть зрелая SOA, то используйте это для создания всех внешних интерфейсов .
6. Плохо определенные критерии успеха. До начала проекта необходимо оценить существующую эффективность и ожидаемую выгоду. По завершении проекта руководство захочет оценить результат и определиться, стоит ли продолжать работу. Снижение стоимости – это наиболее распространенный показатель, хотя существуют и такие как бизнес-возможности, гибкость и готовность к изменениям.
7. Отсутствие наглядных измерений и отчетов. Часто разработчики уделяют недостаточно внимания инструментам анализа. Следует уделить достаточно внимания ключевым измерениям до того, как начнете проект BPM. Это позволит оценить выгоду и ROI от BPM.
8. Отсутствие спонсора из числа руководителей. Проект потребует задействовать ресурсы помимо основной проектной команды, таких как ИТ-ресурсы, бизнес-экспертов. Наличие спонсора из числа руководства обеспечит своевременное получение этих ресурсов.
9. Экономия на обучении. BPM потребует новых знаний и в части разработки, и в части бизнес-анализа. Многие компании экономят на обучении сотрудников, считая, что достаточно обучить пару человек, которые затем обучат остальных. Но имейте в виду, что эти обученные сотрудники имеют слишком мало опыта (в лучшем случае, один проект), что недостаточно для обучения других.
10. Отсутствие собственной команды разработчиков. На первом этапе, для быстрого развертывания BPM, полезно будет воспользоваться сторонними услугами. Но в дальнейшем, для быстрого реагирования на изменения, необходима собственная команда.

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

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

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

Интересная дискуссия на эту тему развернулась на блоге Анатолия Белайчука в ответ на его заметку «10 причин, по которым рынок BPM не оправдывает ожиданий».

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

=WJ

>> Комментарии (всего 2)

ROI или как измерить неизмеримое

Можно ли измерять бизнес-процессы? Этот вопрос волнует многих, поскольку ожидания возврата инвестиций (ROI) редко соответствуют полученным результатам. И происходит это не от того, что результатов нет, а, скорее, от того, что люди пытаются мерить неизмеримое.

Вернувшись с Gartner 2008 BPM Summit, Lance Gibbs (CEO of BP-3) опубликовал в своем блоге две заметки (точнее – одну заметку в двух частях: «Measurable benefit in BPM. Where is it? Part I», «Measurable Benefit in BPM. Where is it? Part II»), в которых высказал свои соображения по этому вопросу. Он пишет, что на саммите присутствующим 450 участникам были заданы вопросы: «Кто уже применил у себя процессный подход с использованием BPMS?», «Кто реализовал 2 или 3 процессных решения с использованием BPMS?», «Кто находится в процессе создания центра компетенции BPM?». На первый вопрос положительно ответили 90% участников, на второй – 50%, на третий – 20%.А на вопрос «Кто измеряет выгоду от BPM?» положительно ответило только 5% участников.

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

С позиции своего опыта Lance Gibbs рассматривает недостатки широко известных методов оценки (не обязательно ключевые, но существенные):

-нехватка воли – измерение «as-is» процесса выглядело слишком тяжелым, непонятным или смущающим. Часто решение было таким «Нам не интересен этот аспект»

- исследовательская работа – BPMS применялись только в очень безобидных областях, и использовались только для оправдания технологических инициатив, и зачастую большая часть успехов не относилась к области BPM

-ИТ-шная замена – BPMS использовался для полного замещения заказных приложений или других систем. Обычно при этом декларируется провал предыдущего проекта усовершенствования; теперь попробуем BPMS.

- Инновации – совершенно новый процесс, для которого отсутствуют исторические данные.

Для реальной оценки качества процессов Lance Gibbs считает достаточным  иметь шесть метрик:

1. Продолжительность цикла (Cycle Time, СТ)– это полное время (среднее или медиана распределения) исполнения задания, например, ввода данных или обработки запроса
2. Время до начала исполнения задания (Lead Time, LT) – это полное время (среднее или медиана), определенное собственником процесса либо руководителем как удовлетворяющее требованиям заказчика.
3. Время прохождения (Throughput Time, TT) – это время от начала до конца процесса, сумма продолжительностей циклов. Ключевая метрика с точки зрения непрерывного усовершенствования.
4. Желаемое время ожидания (“Nice to Have” Takt Time) – время, за которое клиент ожидает получить продукт/услугу.
5. Объем работы (Work In Progress, WIP) – это объем транзакций или число изделий на выходе данного процесса.
6. Количество исполнителей процесса (Number of Operators)– люди, которые работают с процессом.

Рассмотрим вариант процесса, который исполняется за 162 часа. Цель – сократить обработку заказа до 72 часов (рис.1).

Рис.1.

Казалось бы, если сократить время исполнения каждого шага на N часов, то можно добиться снижения общего показателя. Но, к примеру, если сократить время просмотра номенклатуры (Listing)с двух часов до одного, то мы добьемся весьма скромного ускорения, но распылим свои ресурсы. А вот если уменьшить 40 и 120 часов времени исполнения заказа (Order Fulfillment), то это приблизит процесс к желаемым 72 часам весьма существенно. Дальше можно сосредоточиться на других показателях и путем постоянного усовершенствования достичь желаемого результата. Предложенные метрики позволяют сделать цель более обозримой.

Doug Henschen (Intelligent Enterprise Contributing Editor) в статье «The 'Secret Sauce' of BPM Success» приводит результаты исследования Forrester (см. рис.2), в котором отмечается, что среди крупных (свыше $1 млрд. дохода) компаний большинство (57%) ставят на первое место в числе основных показателей сокращение продолжительности цикла Cycle Time. Следующим идет снижение ошибок и риска (52%). Дальше идут наращивание объемов и т.д.

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

 

Рис.2.

Но далеко не все показатели качества могут быть оценены и измерены. К примеру, как пишет в своей заметке «Measuring The Unmeasurable in Business Processes» Nari Kannan (CEO of Ajira Technologies), чем может быть измерена удовлетворенность заказчика? Можно оценить ее по некоторой условной шкале от 1 до 10. Т.е. если заказчик присылает руководителю цветы – то это 10. Если поливает ругательствами – 1. И такие неосязаемые факторы - кругом. Необходимо учиться их измерять и оценивать. Подобные измерения – это скорее из области искусства, нежели науки. Но то, что не может быть измерено, не может хорошо управляться.

=WJ

>> Комментарии (всего 0)

BPMN вчера, сегодня, завтра

В своей колонке на сайте BPMInstitute.org Брюc Cилвер опубликовал статью «Five Things to Love About BPMN 2.0». Вот что понравилось ему в новой версии стандарта:

1. Единый формат, дающий возможность переносить схему из одного инструмента в другой. Как ни покажется это кому-то странным, сегодня это невозможно: стандартизован только внешний вид элементов диаграммы и правила их сочетания, но не упаковка в XML. (Подробнее об этом – на блоге автора.)
2. Обработка событий, не прерывающая поток управления. В текущей версии стандарта сигнал о приходящем событии прерывает нормальный поток управления, и приходится прибегать к специальным ухищрениям, чтобы этого не происходило.
3. Эскалация – разновидность события, возникающая внутри процесса. Полезна для моделирования полу-структурированных и ad-hoc процессов.
4. Новый тип активности: применение бизнес-правила.
5. Возможность назначить для обработки события подпроцесс.

Брюс является членом комитета, разрабатывающего стандарт, и на его блоге можно найти пикантные красочные подробности работы над стандартом. Тон там задают IBM, SAP и (в меньшей степени) Oracle, и любое предложение, чтобы иметь шансы на успех, должно получить одобрение этой тройки. См. также блог Фила Гилберта из Lombardi.

О сроках: ожидается, что в июне OMG проголосует за новую версию стандарта, и поставщики начнут вести под него разработку. Возможно, к концу 2009 года мы увидим первые BPMS, поддерживающие BPMN 2.0. А если брать не полнофункциональные BPMS, а чистые средства моделирования, то и раньше – в частности, itp commerce планирует реализовать поддержку BPMN 2.0 в своем моделере для Visio в июне.

=АБ

>> Комментарии (всего 0)

О BPM в новом номере журнала "Открытые системы"

Небольшое уточнение: номер не посвящен целиком только BPM – этой теме посвящен только один раздел, в который вошли пять статей: «BPMS: на пороге зрелости» Сергея Плаунова, «Избранные паттерны BPM» Анатолия Белайчука, «Эталонная модель BPM» Александра Самарина, «Process Frameworks для BPM» Владимира Аленцева и «Моделирование и контроллинг бизнес-процессов» Михаила Латышева. Две последних я бы отнесла к разряду рекламных, в них рассматриваются продукты и решения компаний, которые представляют авторы. А три остальные могут заинтересовать как начинающих «погружение в тему», так и «продвинутых» читателей.

«BPMS: на пороге зрелости» - полезная статья, в которой систематизированы основные  характеристики компонент BPM-систем. Что, для чего нужно и у кого есть.
Постоянно расширяющиеся предложения от вендоров возбуждают нездоровый аппетит у потенциальных покупателей BPMS:
- Это есть?
- Есть!
- А это есть?
- Есть!
- И это есть?
- Есть! А вам это зачем?
- … не знаю… пусть будет…
На деле же многое из предлагаемой функциональности можно отнести к изыскам, которые если и понадобятся, то так нескоро, что к тому времени будут уже везде и у всех. Так стоит ли платить за то, что будет пылиться на полке?

Статья Александра Самарина для восприятия не-ИТ читателя тяжеловата, поскольку изобилует «ИТ-шной» терминологией и англоязычными акронимами. Однако советую не-ИТ читателям все же собрать волю в кулак и дочитать до конца.  В статье описывается подход к построению архитектуры предприятия и место BPM-систем в этой архитектуре. Ну пора уже об этом знать!

Когда произносится термин «процессные паттерны», то сразу возникает вопрос: это что, типовые процессы? Нет, это не о том. Хотите почувствовать разницу – прочитайте статью Анатолия Белайчука. На своем блоге автор обещает продолжать изыскания в этой области.

=WJ

>> Комментарии (всего 0)

Рейтинг BPMS от Gartner, 2009

По сравнению с версией 2007г. существенно изменилась методика (в 2008г. рейтинг не составлялся), что конечно же повлияло на итоговую расстановку. Оценка теперь выполняется не по функциям, а по поддерживаемым сценариям использования (use cases). По наблюдению Gartner, большинство заказчиков ищет технологию, которая позволила бы создать уровень абстрактных бизнес-процессов поверх имеющихся у них приложений и сервисов. Это общее стремление конкретизируется в следующих типовых сценариях:

1. Создание определенного процессного приложения. Речь идет об автоматизации процесса, специфического для отрасли или компании. В идеале требуется способ быстрого создания приложения, расширяющего и унифицирующего существующие приложения и данные. Ожидаемый результат - не простая интеграция данных и транзакций, а композитное приложение, покрывающее некий сквозной процесс.
2. Поддержка философии непрерывного усовершенствования. В этом сценарии бизнес совместно с ИТ-подразделением на регулярной основе работает над технологическими решениями, которые должны обеспечивать усовершенствование процессов и быструю реакцию ключевых процесов на происходящие изменения. BPMS должна предоставить для этого стабильную платформу с интегрированными сервисами.
3. Перепроектирование SOA на основе процессов. В этом сценарии ИТ-подразделение использует энтузиазм бизнеса по отношению к BPM, чтобы поднять приоритет собственных усилий по рационализации и модернизации имеющегося набора приложений в рамках SOA. ИТ-подразделение приобретает BPMS ради прозрачных для бизнеса процессных моделей и возможности быстрого изменения процессов.
4. Инициативы по преобразованию бизнеса. В этом сценарии за принятием решения стоит высшее руководство. Они стремятся поменять правила игры за счет полного пересмотра бизнес-процессов. Такие покупатели высоко ценят улучшение коммуникаций между бизнесом и ИТ: единый взгляд на процессы, разделяемый всеми заинтересованными лицами, исполнение процесса, не расходящееся с моделью.

Перечисленные сценарии делают востребованными такие характеристики как:

• Ориентированная на бизнес модель процесса. Люди бизнеса не хотят иметь дела с оркестровкой сервисов.
• Объединенные процессы. Компании стремятся к объединению имеющихся приложений в сквозные (end-to-end) процессы, а не отдельные составляющие.
• Обработка исключений. Компании стремятся к автоматизации обработки исключительных ситуаций (ручной и дорогостоящей) в соответствии со стандартным процессом и с помощью машин бизнес-правил. В идеале, в результате непрерывных усовершенствований, число исключений должно постоянно сокращаться.
• Специфические для отрасли процессы. Компании выбирают BPMS вместо привычных приложений с зашитыми в них процессами ради того, чтобы автоматизировать процессы уникальные для отрасли или являющиеся ноу-хау предприятия.
• Предустановленный контент. Чтобы ускорить освоение и разработку, компании хотели бы иметь некий готовый процессный контент, "выжимку" из лучших практик отрасли.
• Контроль и управление. Контроль исполняющихся процессов и возможность вмешательства в них.
• Динамичность/быстрая изменчивость процессов. Компании покупают BPMS в качестве среды для исполнения "от модели" процессов подверженных частым изменениям под воздействием внутренних и внешних факторов.

Результаты забега вы видите на графике:

Подробный разбор продукта каждого представленного вендора - в отчете, который можно скачать у Gartner за $1995 или у Pegasystems за регистрацию.

Ведоры по этому поводу массово публикуют пресс-релизы, а аналитики пока только готовят свои комментарии. Первым отметился Dennis Byron, обозреватель ebizQ.

>> Комментарии (всего 0)

Интервью с Гэри Раммлером

Гэри Раммлер - это человек, которого классики процессного управления называют своим учителем. Он известен как изобретатель Swimlane на процессных диаграммах и как автор многочисленных книг, включая "Managing the White Space on the Organization Chart" и "Serious Performance Consulting According to Rummler". Он всегда был практиком, человеком, решавшим реальные проблемы реальных компаний, а не просто "указывавшим путь". При этом он оставил нам системный подход к таким решениям. Доктор Рамлер скоропостижно скончался 29 октября 2008г. А в мае 2008 он дал очень содержательное интервью, опубликованное на сайте Gartner. Мы публикуем в переводе наиболее интересные выдержки из него:

Я считаю, "процесс" может оказывать как стратегическое, так и тактическое воздействие.
До сегодняшнего дня - за последние 15-20 лет - мы занимались в основном процессным усовершенствованием, которое я рассматриваю как тактическое. Двадцать с лишним лет назад, на основе нашей ранней работы в Моторола, я надеялся, что область деятельности довольно быстро сместится от процессного усовершенствования к управлению процессами и управлению на основе процессов - что менеджмент увидит, что улучшенным/перепроектированным рабочим процессом необходимо управлять, чтобы он оставался эффективным, и что вы способны эффективно управлять бизнесом, управляя этими процессами как системой. Высшее руководство полупроводникового подразделения Моторолы начало это делать в середине 80-х. После того, как они разобрались с сетью процессов, которая делает их успешными, и с необходимостью управлять ими, они начали вводить метрики и систематически управлять процессами для того, чтобы достичь существенных с точки зрения организации результатов. Продемонстрированные результаты были очень впечатляющими, очень значимыми, но и, как потом оказалось, ведущими совершенно не в ту сторону.

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

...

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

В любом бизнесе работа системы, создающей ценность (уровень 1) может быть декомпозирована на три главные подсистемы (уровни 2 и 3) - создание, продажа и доставка продукта/услуги. Эти подсистемы состоят из критических процессов (уровень 4), которые, в свою очередь, состоят из подпроцессов и задач (уровень 5+). На уровне 5 подпроцессы соединяются с теми, кто выполняет работу - либо исполнителями-людьми, либо с технологическими системами, либо с комбинацией тех и других. Уровень 2 иерархии критичен, потому что это последний уровень, на котором процессы организации замыкаются на ожидания потребителей и на требования бизнеса. На этой картинке неявно предполагается, что каждый из этих уровней декомпозиции процессов может/должен быть привязан к следующему уровню выше по иерархии. На самом деле, начиная сверху -  с уровня 2, на котором система создания ценностей замыкается на ожиданиях потребителя - каждый уровень процесса задает контекст производительности и требования для следующего нижележащего уровня. Так что, если вы пытаетесь выделить процессы на уровне 3 или ниже (без привязки к уровню 2 и ожиданиям потребителей), то вы работаете в области, которую мы называем "зоной субоптимизации".

Так вот, в свете этой иерархии, я полагаю, что большинство работ по усовершенствованию процессов выполняется над подпроцессами на уровне 5 или, в лучшем случае, над процессами на уровне 4. Даже беря лучший случай - уровень 4 - это означает, что работа над процессным усовершенствованием отделена от бизнес-целей двумя уровнями. Сочетание того, что работа ведется не на тех уровнях, и того, что процессная работа на уровнях 4 и 5 обычно замыкается внутри "силосных башен" подразделений, шансы на то, что результаты процессного усовершенствования окажут значимое воздействие на бизнес-результаты на уровне 2, находятся где-то между незначительными и нулевыми. Никакие благие намерения и хорошие технологии не способны изменить эту реальность.

Например, если кто-то нацелился на улучшение подпроцесса ввода заказов (уровень 5), но по той или иной причине не имеет возможности замкнуть требования к этому подпроцессу на требования к охватывающему процессу "от заказа до оплаты" (уровень 4), на требования к подсистеме доставки продукции (уровень 3) и на требования к системе создания ценностей (уровень 2), то у него возникнут две серьезные проблемы. Первая: как он узнает что является важным с точки зрения улучшения в этом подпроцессе? Вторая проблема, с которой он столкнется - он никогда не сумеет продемонстрировать, что сделанные улучшения оказали какое-то влияние на бизнес-результаты на 1-м и 2-м уровнях иерархии.

Наш опыт говорит, что вы не можете начать выделять и "улучшать" процесс или подпроцесс, находясь в вакууме на уровнях иерархии 4 и 5. Если вы не можете установить связь с желаемыми бизнес-результатами на уровне 2 на стадии запуска проекта, то у вас ни черта не выйдет побегать и найти эту связь потом, после того как вы выполнили работу по "улучшению" процесса. Опыт всей нашей работы начиная с прошлых дней в Мотороле показывает: если нам не удается установить эту связь с бизнес-требованиями "на берегу", то сделка не состоится.

Вопрос: мы довольно часто сталкиваемся с людьми, которые занимаются "моделированием ради моделирования". Похоже, они не знают зачем они делают то, что делают. Представляется, что это потенциально разрушительная вещь, так как она вызывает опустошенность и приводит к отсутствию конечного результата.

Ответ: Я полностью согласен. Такие вещи убивают нашу область деятельности и я их ненавижу. Это приводит к тому, что менеджмент считает BPM увлечением - сходное с увлечением поведение и сходное с увлечением отсутствие результатов. Именно это я имею в виду, когда говорю, что BPM зарастает сорняками - и я определяю "сорняки" как уровень 5 на моей диаграмме. Эти усилия на уровне подпроцессов не привязаны к уровню 2 и бизнес-результатам. В том, что эти ребята делают, отсуствует бизнес-контекст. Поэтому они моделируют "as-is" процесс (они не могут перейти к "to-be", так как они не знают каковы требования уровня 2), играясь с последним софтверным инструментарием для моделирования. Не удивительно, что вы слышите ворчание о слабой отдаче от усилий в области BPM.

Вопрос: Я постоянно встречаюсь с бизнесом и говорю с ними о том, как соединить бизнес и ИТ при помощи BPM. Я часто обнаруживаю, что бизнес не хочет, чтобы ИТ видел их процессы. Они не желают развивать дисциплину вокруг этого, потому что она выявляет слишком много огрехов в том, как делаются дела, или потому, что кое-что из того, что они делают, больше делать будет не надо. Как Вы с этим справляетесь? Вы верите, что с этим можно справиться, или это то, что всегда будет и с чем надо научиться сосуществовать?

Определенно, мы должны преодолевать это сопротивление. Стратегия, которой мы следуем годами - мы просто идем туда, где у кого-то проблемы достигают такого уровня, что он говорит: "ОК, мы отказываемся от своей секретности, чтобы вы могли взглянуть на нашу систему, потому что мы уже совсем запутались, и у нас будут серьезные трудности если мы не поправим дела". Мы ни в коем случае не откажемся от этой стратегии.

Но мы заходим и с другого угла. Мы надеемся, благодаря двум новым книгам и другим усилиям, убедить высших руководителей бизнеса, что на протяжении лет они сосредотачивались только на одном из двух критических измерений бизнеса. Эти измерения - во-первых, измерение создания ценностей, на которой создается и доставляется потребителям продукт/услуга. Второе измерение - критические ресурсы (деньги, люди и технологии), необходимые для того, чтобы питать измерение создания ценностей. Мы утверждаем, что менеджмент практически полностью концентрируется на хорошо видимом ресурсном измерении и практически игнорирует почти незаметное измерение создания ценности. Измерение создания ценности, создающая ценность работа, необходимая чтобы создать и доставить продукцию и услуги, в действительности является становым хребтом бизнеса - бизнес будет успешным лишь настолько, насколько эффективно измерение создания ценности (или система создания ценности). Однако же в большинстве бизнесов измерение создания ценности не артикулируется, не управляется и пребывает в хаосе. Конечно, в сегодняшнем бизнесе мы знаем это измерение или систему создания ценностей под другим именем - чаще всего мы думаем о ней как о рабочей системе или процессах исполняемых в бизнесе, похороненных в "силосных башнях" функциональных подразделений.

Фокус в том, чтобы не смотреть на процессы как на утомительные и дорогостоящие активности (взгляд ресурсного измерения), а в том, чтобы осознать, что бизнес - это сеть добавляющих ценность рабочих процессов, которые могут и должны быть соединены друг с другом в эффективную систему создания ценности. Мы утверждаем, что "процесс" - это механизм артикулирования сверху-вниз (от уровня 1 до уровня 5) архитектуры создания ценности бизнесом. Мы планируем разработать эти архитектуры и использовать их, чтобы демонстрировать высшему руководству, что процессы (уровни 4 и 5) могут и должны быть увязаны с уровнями 2 и 1 их бизнесов.

ИТ-организации работают над тем, что они называют бизнес-процессами, уже в течение нескольких лет. Но картина ориентирована на технологию и обычно несет в себе какой-то смысл только для других ребят из ИТ. Наша версия этой архитектуры ориентирована на бизнес и приводит к тому, что высший руководитель говорит "Вот он, весь чертов бизнес. Я его вижу. И я вижу место на этой картинке, где я могу предпринять действие, которое приведет к бизнес-результатам." Мы воодушевлены предварительными результатами помощи организациям в составлении карты их измерений или систем создания ценностей. Это задает процессам контекст создания ценности.

Вопрос: Если бы Вы оказались в одном лифте с CEO, что бы вы ему об этом рассказали?

Ответ: Один из самых ценных уроков, который я получил как начинающий бизнесмен - это разница между свойствами и преимуществами товара/услуги. Всегда продавайте преимущества. Консультанты и специалисты слишком много времени тратят на разговоры о свойствах их конкретного бренда или экспертизы и недостаточно на то, чтобы выяснить и донести преимущества их специального блюда до их потребителя - высшего руководителя. В идеале, прежде чем я окажусь в лифте с CEO, я бы узнал все что смог о стоящих перед ним/ней задачами, чтобы иметь возможность сказать: "Я недавно помог одной организации решить проблему, очень похожую на ту, с которой вы столкнулись. Если хотите, я могу дать вам имя и телефон руководителя, который может рассказать что мы сделали и чего добились." Если у меня нет представления о проблемах данного CEO, то наверное мои слова в лифте были бы типа "Кто по-вашему возьмет в этом году супер-кубок?".

Вопрос: Исследования Gartner показывают, что CIO считают улучшение бизнес-процессов своей самой важной задачей, что может означать, что BPM может быть их проектом номер один.

Ответ: "BPM для нас - проект номер один." Ребята, это похоже на поиск проблемы для готового решения. Классический - свойства вместо преимуществ - и очень распространенный. Мы начинали работать с организацией, внутри которой был сильный представитель, первоначально толкавший к тому, чтобы стать "процессно-ориентированной" организацией. Но в то же время, мы обнаружили в организации второго представителя, более ориентированного на конечный результат, который заявил очень определенно, что по соображениям конкурентоспособности, им необходимо повысить удовлетворение клиентов. Наш ответ был - давайте сконцентрируемся на перепроектировании системы, с которой имеет дело потребитель, чтобы соответствовать его ожиданиям и бизнес-требованиям. В процессе реализации улучшенной системы мы превратим вашу организацию в процессно-ориентированную.

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

Вопрос: Я задаюсь вопросом о будущем и о том, найдут ли люди правильный подход к методологии BPM, или они в конце концов просто бросят это дело и перекинутся на что-то новое, многообещающее. Компании - особенно в США - печально известны тем, что предпринимают усилия в течение короткого промежутка времени. Мы видим разницу в других частях мира, но здесь в США период привлечения внимания короткий.

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

Вопрос: Не могли бы Вы выделить необходимые условия и на какой успех могут рассчитывать компании, которые делают это как положено?

Ответ: я думаю, есть всего одно критичное условие - это наличие в организации критической бизнес-проблемы. Если такой проблемы нет (во что трудно проверить) или менеджмент пребывает в глубоком отрицании ее существования, то серьезный, трансформирующий BPM не состоится. Точка. Могут быть уводящие в сторону "демонстрации" и "концептуальные тесты", но ничего существенного не произойдет. Да и как оно может произойти? Серьезный BPM стоит денег, занимает время и может перевернуть множество корзин с яблоками, и вам не удастся это сделать без равнозначного бизнес-обоснования. Я думаю, второе по значимости условие - или фактор - тот, кто занимается BPM внутри организации должен на 70% быть грамотным в бизнесе и на 30% экспертом в области BPM. Потому что ключ к их успеху - способность найти критическую бизнес-проблему, понять как BPM способен ее решить, и затем убедить высшее руководство сделать инвестиции. Я считаю, есть два условия: наличие возможности и кто-то способный эту возможность реализовать.

>> Комментарии (всего 1)

Процессные паттерны

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

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

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

Анатолий Белайчук в своем блоге открыл серию статей, посвещенных паттернам и анти-паттернам процессов. В настоящее время опубликовано только две первых статьи серии Анти-паттерн: “Оркестровка сквозного процесса” и Процессный паттерн: “Внутренний заказ”, но автор обещает продолжить серию.

=WJ

>> Комментарии (всего 0)