Пока собрался попросить у Гугла приглашение, пока они его прислали (месяца два пришлось ждать), пока нашлось свободное время разобраться и поэкспериментировать… в результате только сейчас дозрел поделиться впечатлениями.

Начну с резюме: полезная вещь, жалею что раньше не включился.

Теперь в подробностях. Сначала ссылки на первоисточники - о чем собственно идет речь. (Поскольку продукт в бета-тестировании, все пока по-английски.)

• О сервисе
• Где использовать

Цитирую: “Google Wave - это онлайновое средство коммуникации и совместной работы в реальном времени”. Понятно? Мне лично ни черта. Поэтому расскажу на что это похоже, отталкиваясь от привычных вещей. Google Wave состоит… гм… из Waves. Буду называть их “гугл-волнами” или просто волнами. Сам сервис, чтобы не путаться, буду называть “GW”.

Итак, что такое гугл-волна? Представьте себе текст MS Word. Теперь представьте, что:

• Он хранится на сервере Гугл и вы обращаетесь к нему из браузера через страничку GW.
• Сильно урезан в части форматирования, но минимально необходимые вещи имеются: шрифты, цвета, поля, заголовки, списки, вставка картинок. Можно прикреплять файлы, как к email.
• В нем постоянно включен режим отслеживания изменений (наглядно видно что, кто и когда менял).
• Насыщен комментариями, вопросами-ответами, обсуждениями. Только не на полях, как в Word, а прямо в тексте блоками, выделенными рамками, и с теми же возможностями форматирования, что и в основном тексте.
• Текст и комментарии создаются, правятся, удаляются любым участником, так что при желании можно все подчистить и получить на выходе аккуратный текст. Но все ходы записываются и есть кнопка replay, показывающее что с документом происходило.
• Участник - это создатель волны и те пользователи GW, кого он пригласил в волну.
• Под реальным временем подразумевается вот что: если кто-то из участников что-то делает с волной, а у вас в это время открыто окно GW, то вы видите как он набирает буковки.
• Совместная работа в самом полном смысле этого слова: запросто я могу вводить текст в один раздел и одновременно другие участники - заполнять свои разделы, и при этом мы будем подбрасывать друг другу комментарии, замечания и вопросы. Никакой блокировки, никаких конфликтов благодаря реальному времени (правда, я не пытался их провоцировать).

Законный вопрос: настолько ли это лучше комбинации MS Word +электронная почта, чтобы осваивать еще одно средство? Полагаю, да. GW избавляет от вопросов типа “где последняя версия документа?” или “внесены ли в него мои последние правки?”. Кейт Свенсон справедливо указывает (тут и тут), что мы все подвержены “наркотической зависимости от email”, и GW - правильное лекарство от этой болезни.

Первые волны, на которых я экспериментировал:

1. На работе обсуждали принимать или нет приглашение на очередную конференцию. Решили принять, и дело плавно перетекло в координацию подготовки: график подачи материалов, раздача поручений, мозговые штурмы и т.п. Естественно, с подключением новых людей. Без GW это все пошло бы в почту, что было бы гораздо менее удобно и эффективно.
2. Дома с сыном обсуждали апргейд плеера для кино. Все это продолжалось несколько дней: определяли критерии, выбирали модели, сравнивали цены. Опять-таки, заметно удобнее почты.

С чем еще можно сравнить гугл-волну:

• С дискуссией на форуме. Волна с большим числом комментариев становится на него похожа. Поддерживается иерархия комментариев (комментарии к комментариям). Разница в том, что в любой момент можно отредактировать и основной текст, и любой комментарий.
• С фото-сайтом. Можно опубликовать фотографию в новой волне и обсуждать ее в кругу друзей.
• С хранилищем документов (Document Management System) вообще и с wiki, в частности. Похоже коллективной работой. Непохоже наличием реального времени в GW и тем, что обсуждение ведется не на отдельной страничке, как в wiki, а прямо в тексте. И то, и другое по моему плюс. Простая до тривиальности модель доступа: участник может все, остальные ничего. Отсутствие оглавлений и жесткой классификации, только тэги. Вывод: wiki - для нетленки, волна - для пены дней.
• С багтрекингом. Там тоже есть кейс, к которому цепляются файлы и по которому ведется обсуждение. Непохоже отсутствием в GW какой-бы то ни было структуры - чистый ad-hoc. В багтрекинге же без структуры не обойтись.

Еще плюсы:

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

Теперь минусы вместе с вопросами. (Возможно, какой-то минус - это на самом деле минус не GW, а мне, потому что не так понял или не смог разобраться.)

• Нет уведомления об изменениях в ваших волнах. Правда, если страница GW открыта в одной из вкладок браузера, то в заголовке появляется “Google Wave (3)”, что означает, что в волнах, за которыми вы следили, появились три изменения. Но надо постоянно держать страницу открытой. На странице идей народ массово высказывает по этому поводу свое неудовольствие. Есть мнение, что Гугл таким образом хочет “убить” email. Но по-моему, это врядли. Думаю, они реалисты и понимают, что это дополнение, а не замена. Так что надеюсь, в финальной версии возможность уведомления появится. По почте и по RSS. Кстати, мне лично второй вариант нравится больше, ведь страница Google Reader у меня и так постоянно открыта.
• Так же абсолютно необходим постоянный адрес (URL) волны. Пообсуждали-поредактировали, зафиксировали (запретили дальнейшие изменения) и получили HTML-страницу, на которую можно сослаться из письма или из блога. Пока я не вижу, как гугл-волну сделать частью Паутины. А концептуально это очень круто: при помощи GW можно было бы добавить ad-hoc функциональность везде, где ее не хватает. SAP со своим Gravity (BPMN-дизайнер для GW) добился той же цели, но при помощи плагина. Мне кажется, логичнее поступать наоборот: к примеру, вставить ссылку на волну в поле Link задачи MS Project, а не делать из Project плагин GW. <updated>URL волны отображается в адресной строке браузера, когда выбираешь волну. Так просто!</updated>
• Почему-то нет возможности оформить нумерованный список. Мелочь, но странно: маркированный список в панели форматирования есть, а нумерованного нет.
• Самая главная проблема: чтобы все это у вас реально заработало, необходимо, чтобы все те, с кем вы собираетесь общаться или совместно работать, были пользователями GW. Это барьер, и довольно высокий. Для сравнения, чтобы начать пользоваться гугловыми картами, этого не требуется, не говоря уж о поисковике. И чтобы отправить почту через gmail, тоже не требуется чтобы получатель имел почтовый ящик тоже обязательно у гугла. В гугловом фотобанке picasaweb  я могу дать доступ к моему приватному альбому, послав “секретную” ссылку на него по почте. Можно было бы в GW реализовать тот же подход - это даст возможность разово подключить к конкретной волне случайного участника без постоянного аккаунта. Впрочем, уверен, что ребята в гугле что-то придумают в плане облегчения доступа к GW. Не забываем: пока речь идет о версии сервиса для ограниченного тестирования.

Как стать пользователем GW? Для начала, у вас должен быть гугловый почтовый ящик (@gmail.com). Дальше самый простой путь - обратиться к кому-то, у кого уже есть GW. У каждого из нас есть по 25 приглашений. Можно обратиться непосредственно к гуглу, но приготовьтесь к тому, что придется ждать. Не исключено, что за это время гугл сделает сервис общедоступным. Приглашение же от существующего пользователя приходит практически сразу.

<updated>Полезные ссылки:

• Google Wave 101
• The Complete Guide to Google Wave
• Ultimate List of Google Wave Gadgets and Tools
• How to Install a Google Wave Gadget Extension

Happy waving!</updated>

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

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

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

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

Бизнесмен: мы принимаем решения на основе предварительной оценки окупаемости или возврата на инвестиции (ROI).

Шахматист: конечно надо считать когда и сколько материала - пешек, фигур - ты выиграешь в результате того или иного хода. Мы тоже считаем комбинации. Только у нас партия состоит не из одних комбинаций. Бывают ходы вынужденные, когда думаешь не о том, чтобы побольше съесть чужих пешек и фигур, а о том, чтобы не съели твои. Бывают ходы, улучшающие позицию. Бывает, что жертвуют материалом, чтобы улучшить позицию  - “получить игру”. Ведь если позицию не развивать, то просто не будет возможности развернуть атакующую комбинацию и ни до какого ROI дело вообще не дойдет.

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

Бизнесмен: у нас тоже есть стратегия компании.

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

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

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

Военный: мы тоже считаем темпы операций. Классический пример: время мобилизации и развертывания в начале войны стали краеугольным камнем знаменитого плана Шлиффена немецкого Генштаба на войну, которую потом назвали Первой мировой. Загонять противника “под флажок” мы тоже умеем: наводнить его штабы противоречивой информацией и дезинформации, совершать ходы, которых он не ожидает, чтобы он не успевал переваривать информацию и в результате постараться добиться паралича управления войсками.

Бизнесмен: так, кажется я начинаю понимать что это за business agility, о которой в последнее время столько разговоров…

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

Скачивая пробную версию или демо-ролик BPMS, имейте в виду, что когда дело дойдет до промышленной эксплуатации, система, которая в итоге получится, многими существенными чертами будет отличаться от исходной “коробочной” версии:

1. Пользовательский портал - веб-интерфейс, позволяющий запускать процессы, работать со списком  назначенных пользователю заданий, отображать формы, соответствующие этим заданиям, а также контролировать и администрировать процессы. В промышленной системе он будет отличаться, как минимум, по внешнему виду, а скорее всего, и по функциональности. Если повезет, вам удастся обойтись кастомизацией “коробочного” портала, но будьте готовы к тому, что на каком-то этапе вам придется переписать его “с нуля”. Или, как вариант, вообще уйти от отдельно стоящего портала BPM, а тесно интегрировать процессную функциональность с корпоративной системой. Причина - пользователи обычно не готовы согласиться с мнением BPM-поставщика или интегратора, что BPMS должна быть центром его, пользователя, вселенной.
2. В частности, на каком-то этапе в вашей системе должна исчезнуть кнопка “запустить процесс”. С точки зрения пользователя, он не “запускает процессы”, а занимается конкретным делом: например, принимает поступивший заказ или составляет заявление на отпуск. Стартовать соответствующие процессы система должна автоматически.
3. Будьте готовы к тому, что на каком-то этапе экранные формы к шагам процессов, которые можно сгенерировать средствами BPMS в несколько кликов мыши, перестанут удовлетворять с точки зрения функциональности, юзабилити и дизайна. В связи с этим полезно с самого начала представлять себе, как вы будете разрабатывать эти формы: в какой среде, какими инструментами, силами каких программистов, с какими трудозатратами. Важность этого пункта трудно переоценить: например, что толку от того, что схема процесса рисуется за два дня, если (условно) разработка экранных форм к нему потом займет два месяца? (При этом я нисколько не преуменьшаю важность средств быстрого прототипирования экранных интерфейсов - в контексте BPM они абсолютно необходимы и без них ни до какой промышленной системы дело вообще не дойдет.) Кстати, скорее всего вы захотите воспользоваться этим же инструментарием и для переписывания портала.
4. Аналогично, на определенном этапе вам перестанет хватать штатных отчетов и средств мониторинга.
5. Демо- и пилотные версии процессов обычно хранят все необходимые данные в атрибутах процесса, процессных переменных или операндах (разные системы используют разную терминологию). В промышленной системе в таком виде хранятся только относительно малозначащие данные, представляющие интерес только в момент исполнения процесса. Большая же часть данных уходит в традиционную базу данных, а в контексте процесса хранится только первичный ключ соответствующей записи. Например, в процессе согласования клиентского заказа на покупку информация о клиенте и о позициях заказа скорее всего будет хранится в базе данных, а идентификаторы клиента и заказа и дата контрольного звонка клиенту по поводу заказа останутся в атрибутах процесса. Причина, по которой необходимо действовать именно так, очевидна: данные, представляющие интерес после завершения экземпляра процесса, должны храниться так, чтобы до них можно было добраться независимо от экземпляра процесса. Это, кстати, означает не только отдельное хранение, но и отдельные, не связанные с процессной функциональностью, экранные формы для доступа к этим данным. Соответственно экранные формы к шагам процессов должны будут работать “на два фронта”: и с атрибутами экземпляра процесса через API движка BPMS, и с полями базы данных через API СУБД.
6. Развивая предыдущий пункт, скорее всего для части долгосрочной информации (но обычно не для всей) уже есть место в какой-то из имеющихся у вас корпоративных систем. Соответственно, в атрибутах процесса будут храниться идентификаторы соответствующих бизнес-объектов, а формы к шагам бизнес-процессов должны будут уметь обращаться еще и к корпоративным системам. (Впрочем, последнее не является абсолютом - зачастую это оказывается очень трудоемким делом, что оправдывает компромисс в виде лишь частичной интеграции с корпоративными системами.)
7. Аналогично, если в демо- или пилотной версии процесса связанные с ним документы (обычно файлы Word или Excel) хранятся в виде приложений к экземпляру процесса, то в какой-то момент вам придется подумать о чем-то более солидном. Причина та же самая: если документ представляет интерес после завершения экземпляра процесса, значит, храниться он должен независимо от экземпляров процесса и доступ к нему должен предоставляться также независимо от процессной функциональности. Некоторым облегчением является то, что вам не нужна для этого тяжеловесная система документооборота - ведь задачу собственно документооборота вы уже решили при помощи BPM, вам нужно только хранение документов с соответствующими интерфейсами (пользовательским и программным) и сервисом (поиск, архивация, разграничение доступа).
8. В демо- или пилотной версии аутентификация и авторизация пользователей обычно делается через собственный, независимый каталог LDAP, базу данных или вообще статический список пользователей, хранящийся в XML-файле где-то на сервере. Понятно, что промышленная система должна работать с уже имеющимся у вас каталогом пользователей. Но неприятным сюрпризом зачастую оказывается то, как много усилий это требует. Начать с того, что таких каталогов зачастую оказывается несколько. Типичный пример: есть Active Directory, есть собственная система авторизации в унаследованной бухгалтерской системе и есть информация о пользователях удаленных подразделений и пользователях компаний-партнеров, которая хранится в базе данных. По мере развития проекта могут возникать дополнительные требования: учет планового отсутствия сотрудников, замещение обязанностей на время отсутствия, автоматическое перенаправление заданий и т.д. Известно, что для компании, в которой число пользователей превышает сотню, внедрение только Active Directory представляет собой нетривиальный проект, а тут мы сталкиваемся явно с более сложной задачей. В результате в проектах BPM трудоемкость, приходящаяся на решение вопросов авторизации и аутентификации, в некоторых проектах достигает 50%. Представьте себе на минуточку, что это произошло именно в вашем проекте, причем при планировании проекта вы эти сложности недооценили: в результате до 100% превышения сроков и бюджета!
9. Для демонстрации и для пилотного проекта обычно выбирают не самый сложный бизнес-процесс. Это бы ладно - хуже то, что и технически реализуют один бизнес-процесс. Но в реальности даже процесс приема на работу технически реализуется как несколько взаимодействующих друг с другом процессов (достаточно заметить, что рассмотрение присланных резюме не связано напрямую с публикацией вакансии). Тем более это справедливо по отношению к сквозным процессам, представляющим наибольший интерес с точки зрения бизнеса (см. анти-паттерн “Оркестровка сквозного процесса” и паттерн “Внутренний заказ”). Соответственно, вам довольно скоро придется расширить объем используемой функциональности вашей BPM-системы - освоить не только оркестровку, но и хореографию. Современные BPM-системы с этим нормально справляются, но для системы класса workflow или документооборота, встроенного в вашу учетную или бухгалтерскую систему, это может стать камнем преткновения.
10. Ну и наконец, промышленная система отличается от пилотной уровнем надежности, производительности, защищенности … но это стандартные требования, ничего относящегося именно к BPM в них нет.

Но не пугайтесь: ведь все перечисленное делается не враз, а постепенно, и все компании, преуспевшие в 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) выбран другой путь. В палитре этой системы есть специальный “магический” активити, который может забрать на себя управление с любого активити и/или передать на любой активити. Это решает большую часть проблемы - отсутствие на схеме необходимого перехода.

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

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

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

“Правда можно многие задачи 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” от Скотта Адамса на околопроцессные темы. » читать дальше

С третьей попытки научил-таки свой ноут 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 (делается однократно) и подключиться.