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

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

Записи в рубрике ‘Заметки’

Майкл Хаммер был прав

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

В 90-е, в эпоху реинжиниринга, на время произошел отказ от принципа непрерывного усовершенствования в пользу технократического,  американского, “ковбойского” подхода. Но представление о том, что можно “с чистого листа” спроектировать идеальный бизнес-процесс, оказалось идеализированным. Во-первых, кросс-функциональный (масштаба компании в целом) бизнес-процесс слишком сложен, чтобы его можно было спроектировать с одной итерации. Во-вторых, нет никакого оптимального “to be”, а есть только бег за вечно ускользающим горизонтом.

В BPM - и методологию, и технологию, и организационные принципы - понимание этих реалий заложено изначально.

“Но есть один момент” (c)

Мы занимаемся проектами BPM уже несколько лет, и четко выработали для себя три условия, которые должны быть выполнены со стороны потенциального заказчика, чтобы проект мог состояться:

  1. Что-то должно “болеть”. У бизнеса должна быть серьезная проблема, от решения или не решения которой существенно зависят конкурентоспособность и вообще перспективы компании. При этом проблема должна быть осознана и хотя бы приблизительно “оконтурена”. Просто попытка “сделать что-нибудь” ни к чему путному не приводит.
  2. Должна быть воля к решению этой проблемы. С этим сложно в компаниях с размытой мотивацией - например, там, где собственник решил полностью удалиться от дел, доверив все наемным менеджерам, не имеющих доли в компании.
  3. Должны быть ресурсы. Финансовые и интеллектуальные. Финансовые - на уровне постоянной оплаты труда минимум двух специалистов, из них минимум одного в своем штате. Интеллектуальные - выполнение топ-менеджерами функций владельцев бизнес процесса, в частности - участие в (пере)проектировании бизнес-процессов на уровне одного-двух часов в неделю.

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

Почему? Да потому, что принцип “не сломано - не чини” никто не отменял. Человек бизнеса, за редкими исключениями, не станет затевать проект BPM (равно как и любую другую серьезную инновацию) просто потому, что жизнь стала слишком спокойной. Чтобы проект имел финансовый смысл, должен быть потенциал улучшения - проще говоря, какой-то из весомых процессов должен быть сломан.

Получается, мы, пусть и на новом уровне, возвращаемся к реинжинирингу. И кстати, к “as-is” и “to-be” - теперь они нужны, чтобы количественно замерить показатели процесса до и после проекта и потом дать спонсору проекта отчет - какую отдачу дали потраченные на него деньги.

Резюмируя: машина BPM “на ходу” - это непрерывное усовершенствование, но “стартером” этой машины служит однократное, достаточно радикальное усовершенствование в духе реинжиниринга.

Жаль, что допер я до этого только теперь, когда Майкла Хаммера уже не стало…

В связи с этой темой не могу не отдать дань уважения еще одному ушедшему в прошлом году титану - Гэри Раммлеру. В своем интервью (возможно, последнем) он сказал: 

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

Спасибо, Гэри, надеюсь мы идем верным путем.

Изменение бизнес-процесса “на лету”

Еще один часто задаваемый вопрос из форума.

Вопрос - В случае изменения шаблона бизнес-процесса (добавили/удалили активити) что происходит с реальными начатыми по этому шаблону (в предыдущей версии) бизнес-процессами? Что происходит в связи с этим с аналитикой?

Ответ - Большинство BPMS в такой ситуации завершат начатые экземпляры бизнес-процесса по старому шаблону, а новые будут создавать по новому. Это можно считать удовлетворительным решением только если изменение шаблона - плановое. Если же, как часто бывает, процесс зашел в тупик из-за того, что в шаблоне в данном месте не предусмотрели переход или развилку, то все что вам остается, это аварийно завершить данный экземпляр процесса и начать его снова по новому шаблону. Аналитика при этом накрывается.

Однако системы, которые позволяют модифицировать схему процесса “на лету”, существуют. Рекомендуемое чтение по теме:

  • Статья Glen Smith из Appian на ebizq.net рассказывает почему важно иметь такую возможность с методологической точки зрения. Если над вами не довлеет жесткая необходимость выявить процесс до мельчайших деталей всех возможных исключений, то вы можете быстрее запустить его в эксплуатацию.
  • Keith Svenson из Fujitsu обращает внимание на то, что изменение схему “на лету” принципиально очень сложно реализовать в системах, в которых для исполнения процесса используется BPEL. Fujtsu Interstage BPM позволяет вам отредактировать схему экземпляра процесса точно так же, как и схему шаблона, и при желании, сохранить полученную схему в качестве новой версии шаблона.

За информацией о последней версии конкретной BPMS обращайтесь к отчету BPTrends.

Если редактор бизнес-процессов (моделер) реализован в виде десктопного приложения (а именно так обстоит дело в большинстве систем), то это принципиально ограничивает возможность исправления процесса “на лету”. Если экземпляр процесса застрял, то необходимо иметь возможность оперативно, в онлайне исправить схему. То есть моделер должен быть реализован в виде тонкого клиента. К примеру, в Fujitsu Interstage имеется и десктопная версия моделера, и онлайновая в виде апплета.

В Oracle BPMS (aka BEA AquaLogic BPM aka Fuego) выбран другой путь. В палитре этой системы есть специальный “магический” активити, который может забрать на себя управление с любого активити и/или передать на любой активити. Это решает большую часть проблемы - отсутствие на схеме необходимого перехода.

Но не стоит полагаться только на инструментарий - надо грамотно проектировать схему процесса.

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

СУБД, ECM/документооборот или BPMS?

В очередной раз на очередном форуме всплыл этот вопрос:

“Правда можно многие задачи BPM решать с помощью документооборота, также, как и с помощью БД. Правда получится не сильно хорошо…”

Это явный FAQ, поэтому дам-ка я на него развернутый ответ. Сам вопрос переформулирую для общности.

Вопрос - Как разграничить области применения СУБД, ECM и BPMS? Как их сочетать?

Ответ - Вообще говоря, у нас есть:

  1. структурированная информация, с которой лучше всего умеют работать СУБД
  2. неструктурированная информация (документы), для которой предназначены ECM
  3. процессная информация, под которую заточены BPMS

(BPMS используют СУБД, а ECM может использовать СУБД или файловую систему, но мы от этого абстрагируемся.)

Каждый из троицы СУБД-ECM-BPMS способен при необходимости подменить любого из двух собратьев, но естественно, в той или иной степени ублюдочным cпособом:

  • СУБД умеют хранить документы в текстовых и двоичных полях, но до полной функциональности ECM не дотягивают (например, в части навигации, поиска по контексту, версионности, разграничения доступа, интеграции с MS Office).
  • В СУБД иногда хранят процессную информацию, например создавая для этого таблицу, каждая запись которой описывает очередной шаг обработки документа. Понятно, что это очень примитивное описание по сравнению с диаграммой процесса в BPMS.
  • В ECM встраивают workflow-движки, но полноценной BPMS такая реализация проигрывает из-за проприетарных нотации, платформы, средств интеграции, а главное, из-за отсутствия поддержки методологии непрерывного усовершенствования. Проще говоря, в ECM можно реализовать бизнес-процесс, но трудно менять его в требуемом темпе.
  • Структурированные данные можно загнать в файл Excel, а файл - в ECM.
  • У BPMS есть типизированные атрибуты для хранения структурированных данных, но пользоваться ими можно только в ограниченных объемах - по производительности такой механизм и близко не стоит с непосредственным хранением в СУБД.
  • BPMS позволяет прицепить к экземпляру процесса документы, но, как и в случае хранения их в СУБД, сервис по сравнению с ECM будет убогий. К тому же возникает вопрос: как добираться до документов после того, как процесс завершился?

Таким образом, если вы планируете инфраструктуру на перспективу, то вам понадобятся все три компоненты. Если же перед вами стоит задача, ограниченная по функциональности, ресурсам и/или срокам, то вы можете поискать решение “для бедных”, скомпенсировав отсутствие компоненты за счет имеющихся в наличии.

Сбалансируйте вашу стратегию во времени: например, в пилотной стадии BPM-проекта зачастую обходятся встроенными в BPMS средствами хранения документов. Ведь в пилотном проекте главное - в возможно кратчайшие сроки выяснить: а нужно ли нам оно вообще? Если да, то ECM можно и потом прикрутить.

Тим Лири и другие служители карго-культа

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

И тогда “бедные люди-дикари” свергли своих прежних богов и стали молиться богам белых людей. Они стали строить свои аэродромы и самолеты в натуральную величину - как умели, из пальм и соломы. Они старались: раскладывали посадочные огни, сажали на вышку “диспетчера” в наушниках из половинок кокосовых орехов… Но божественные самолеты с изумительными грузами не прилетали. Подобные истории фиксировались неоднократно, и этнографы даже изобрели специальный термин: культ карго (cargo = англ. груз). » читать дальше

Процессы - это весело

Точнее, это было очень смешно в 90-е; современные процессные дисциплины не доставляют так, как реинжиниринг и ISO 9000. В качестве иллюстрации - подборка комиксов “Dilbert” от Скотта Адамса на околопроцессные темы. » читать дальше

08.01.09 | Заметки | ,     Комментарии: закрыто

Получен отказ в подключении: от Toshiba к HTC по Bluetooth

С третьей попытки научил-таки свой ноут Toshiba ходит в интернет через HTC 3300, подключенный по Bluetooth. На ноуте Vista, на наладоннике - Windows Mobile 6.

Попытка следовать инструкциям на сайте МТС приводит к сообщению “получен отказ в подключении” на ноуте. Народ на форумах дает разные советы, включая предложение заменить Bluetooth стэк на ноуте. Все бесполезно.

В итоге нашел на сайте Toshiba Bluetooth Information Center правильный документ: Internet via Bluetooth (TOSHIBA PC — WM6_phone — Internet). Тошибе - пятерку за качество документа и двойку за организацию своих сайтов вообще и поиска на них, в частности. На сайт этот по Bluetooth попал каким-то случайным образом; чтобы еще раз найти тот же документ, потратил полчаса.

Но это еще не конец истории. Документ предлагает запускать Internet Sharing из Comm Manager наладонника. Однако у HTC соответствующая иконка на панели Comm Manager отсутствует. Решение: Проводник - папка Windows - IntShrUI. Копировать, вставить ярлык в папку Windows/Главное Меню. Можно переименовать ярлык, например, в “Internet Sharing”. Все, для подключения действуем по инструкции Тошибы:

  1. Из меню Пуск наладонника запустить Internet Sharing и сказать ему “Подключиться” (в предположении, что GPRS на наладоннике уже настроен).
  2. На ноуте добавить подключение к наладоннику по Bluetooth (делается однократно) и подключиться.
01.01.09 | Заметки |     Комментарии: закрыто

Много ли процессов в ваших BPM-проектах?

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

Вообще-то я всегда считал, что BPM - это для тех, у кого “ERP уже есть, а счастья еще нет”. Но выяснилось, что во-первых, компаний, достигших нирваны полной автоматизации, как-то не видно. А во-вторых, продвинутые компании не желают автоматизировать то, что у них еще не автоматизировано, традиционными методами, а хотят сразу заложить в свою недостающую функциональность процессную составляющую. Я был бы последним, кто стал бы их в этом упрекать, но в итоге мы попадаем в проекты, в которых “в нагрузку” к процессной составляющей идет приличный кусок разработки более-менее традиционных корпоративных приложений. И большую часть времени наши разработчики и аналитики тратят не на бизнес-процессы, а на эти приложения! В принципе ничего страшного - мы этим занимаемся больше 15 лет - просто скучноватое это занятие по сравнению с работой над бизнес-процессами.

И на форуме sql.ru помнится были высказывания в таком духе, что мол BPMS - не панацея, потому что “все равно до фига руками делать”.

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

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

Вывод: не столько с BPMS хорошо, сколько без него плохо!

11.12.08 | Заметки |     Комментарии: закрыто

О дизайне этого сайта

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

Вот казалось бы, у вордпресса дофига готовых тем. Но это только на первый взгляд. А на самом деле:

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

Одним словом, быдлокодинг во всей красе.

Нашел бы годную тему готовую, не стал бы экспериментировать. А вам не пришлось бы плеваться.

Зато освоил YUI (Yahoo User Interface) CSS - полезная вещь кстати, всем рекомендую. А то вечно с этими CSS-ами приходится шаманить, и все равно вылезет какая-нибудь фигня не в одном, так в другом браузере. (Что собственно, темы вордпресса наглядно и демонстрируют.)

Смотрел еще Blueprint CSS - YUI у него выигрывает нокаутом. Во-первых, концептуально: у Blueprint мелкий грид с шагом 30 пикселов и классы вида “column span-12″. В результате компрометируется идея разделения структуры контента и верстки. Во-вторых, верстка только фиксированная. В-третьих, перекроить грид под себя можно скриптами на Ruby. Ага, счаз побегу его ставить специально для этого дела. Мало у меня всякого добра установлено. Ну и в-четвертых, YUI откровенно более зрелая и солидная разработка.

Надо будет при случае разобраться что еще есть полезного в YUI.

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