Вчера прошел очередной семинар BPMS.ru: “Автоматизация процессов в вузе“. Интересен он был, на мой взгляд, не столько проблемами вузов, сколько элементами ноу-хау, которым поделилась Бизнес-Консоль, в частности:

1. Анализ цепочки создания ценности на основе стандартного фреймворка. Он нам нравится своей простотой (5 основных процессов, 4 вспомогательных) и универсальностью. Последнее как раз и иллюстрирует вузовский пример: если на фреймворк ложится деятельность такого специфического “бизнеса”, как университет, то нормальным компаниям - производственным, торговым, финансовым - и подавно подходит. Правда, оборотная сторона такой универсальности - фреймворк необходимо адаптировать для каждого бизнеса. Начиная с того, что переименовать каждый процесс (а строго говоря, прямоугольники фреймворка - это не процессы, а группы процессов), используя лексику данного бизнеса. Но это крайне полезное упражнение, которое, по хорошему, должно предшествовать любой BPM-инициативе. Благо трудоемкость его вполне разумна.
2. Паттерны моделирования B2C и B2B процессов. Традиционный жесткий workflow годится только для внутренних процессов: там все в нашей власти, всем участникам можно выдать жесткий регламент и исполнять процесс “на раз-два”. Но как только появляются контрагенты, правила игры меняются. К примеру, послали вы ему счет - а он его не оплачивает (об этом антипаттерн “Гарантированное получение сообщения”). Вместо оркестровки приходится реализовывать хореографию: асинхронное исполнение нескольких процессов, обмен сообщениями-сигналами… Вуз в этом смысле, опять-таки, интересный объект: там непредсказуемость очень велика. Студенты, что с них возьмешь. К примеру, нельзя закладываться на то, что абитуриент сначала заключит договор, потом оплатит, потом пройдет тестирование - последовательность будет любой. В ходе обсуждения рассмотрели несколько вариантов решений, в том числе конечный автомат обычный и многомерный.
3. Отдельно был рассмотрен новый паттерн с рабочим названием “продолжение с повтором”. Он пока еще нигде не докладывался, собираюсь написать о нем в отдельной статье здесь на блоге.

О планах дальнейших семинаров. Во-первых, обращаю внимание всех заинтересованных лиц: объявления о семинарах публикуются в виде RSS вместе с новостями сайта: http://bpms.ru/rss/news.xml, подписывайтесь.

Во-вторых, на сайте появилась отдельная страница “Семинары”. Правда, на данный момент опубликованный на нем график предстоящих семинаров неактуален: доклад Виталия Елиферова не состоится (надеюсь, пока), а неконференцию планируется перенести на 23 июня (среда). После этого - перерыв до осени.

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

Мы такое мероприятие недавно провели на конференции вузов-партнеров Unify. Народ был в восторге, теперь будем проводить регулярно.

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

Место проведения будет тем же (РосНОУ), регламент несколько другой - времени нужно больше, чем на семинар. Поэтому начнем в 6 вечера, а закончить рассчитываем ближе к 10. Регистрация на livents.ru.

18 февраля - очередной семинар BPMS.ru. Роман Ткачев (BI Telecom) обещает поделиться сокровенным

Следующий семинар BPMS.ru предварительно запланирован на 25 марта.

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

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

НИСКУ - это Национальный Институт Сертифицированных Консультантов по Управлению (niscu.ru), контакт у нас установился на круглом столе CNews. Взаимный интерес возник закономерно: упрощенно, управленческий консалтинг говорит что надо делать, а BPM-консалтинг - как.

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

Семинар позиционирован как дискуссионный и назван “Бизнес-технология BPM”. В термине Business Technology, который активно раскручивается Forrester, на мой взгляд, есть смысл. Ведь сейчас у нас, с одной стороны, есть бизнес- и управленческий консалтинг, которым не хватает технологичности, а с другой - ИТ, информационные технологии, которым не хватает ориентированности на бизнес-результат. BPM, по идее, призван работать на стыке между бизнесом и ИТ и таким образом, стать бизнес-технологией. Вот и обсудим, как этого достичь на практике, во взаимодействии с консультантами по управлению.

Семинар состоится 15.12.09. Информация о семинаре и регистрация.

На следующий день, 16.12.09 - очередной семинар BPMS.ru “Внедрение BPM в полиграфической компании“. Компания  Элевайз поделится опытом своего самого масштабного, на сегодняшний день, BPM-проекта. Во избежание недоразумений: заявленный в качестве оппонента Анатолий Белайчук - это не я, а Анатолий Константинович, зав.кафедрой корпоративных информационных систем РосНОУ, и мы с ним не однофамильцы

Семинар получился оживленным - интересными были и сам доклад, и последующие выступления - и нестандартным по тематике. Если обычно на семинаре мы разбираем опыт конкретных проектов BPM, то в этот раз была доложена концепция, существующая пока только в теории. Доклад планируется опубликовать на bpms.ru. По существу доложенного, абсолютно правомерной мне представляется постановка задачи. Действительно, существуют проблемы 1) совмещения в организации элементов функционального и процессного управления (а вообще-то еще и проектного, для полноты картины) и 2) отторжения творческими личностями сильно формализованных процессов, в которых они чувствуют себя “винтиками”. Но предложенное решение, на мой взгляд, откровенно утопично. Сервисно-ориентированное управление вполне имеет право на жизнь, но в несколько ином виде - более авторитарном, чем было предложено автором. Попытался в своем выступлении вкратце изложить, как такая схема могла бы выглядеть, но боюсь получилось скомкано; эта тема заслуживает отдельного рассмотрения.

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

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

Качество докладов было на высоте. Особенно мне понравились:

• Роман Ткачев (операционный директор БиАй Телеком, партнера Lombardi в России) рассказал про проекты в банке ВТБ-24 и в ритейловой компании. Отличный программный продукт, грамотный консалтер - мы вправе были рассчитывать на интересный доклад, и мы его получили. В кулуарах задал Роману пару ключевых вопросов. Во-первых, заплатили ли клиенты деньги за лицензию? Ответ - да. Вопрос, на мой взгляд, важный, так как проводит грань между инициативным пилотом, выполняемым поставщиком за свой счет и фактически без обязательств со стороны клиента, и следующей ступенью - продуктивным пилотом, выполняемым за деньги клиента и в условиях, когда клиент уже четко осознал, что ему это нужно. Второй вопрос - на каком уровне поддерживались проекты, конкретно - кто выступал в роли спонсора. Ответ - в ВТБ-24 проект поддерживался на уровне председателя правления банка. Это еще один ключик, позволяющий отличить “игрушечный” проект с сомнительными перспективами от реального. В общем, я рад за коллег из BI Telecom. Роман согласился, что ему стоило бы акцентировать эти моменты в презентации - что ж, так бывает, что самое интересное для аудитории для докладчика оказывается само собой разумеющимся.
• Алексей Будин (директор компании “Элевайз”, отечественного разработчика BPM-системы ELMA) живо и убедительно представил два взгляда на BPMS: со стороны заказчика и со стороны поставщика. Судя по презентации, система выглядит достаточно симпатично. А наличие интеграции с 1С (подтвержденной сертификатом “1С-совместимо”) является серьезным конкурентным преимуществом на отечественном рынке. Ведь поставщики импортных BPMS об интеграции с 1С не беспокоятся, а для среднего бизнеса в России 1С - практически стандарт. Поскольку мы тоже ориентируемся в основном на средний бизнес, сделал для себя вывод, что стоит познакомиться с этой системой поближе.
• Алексей Бойко (руководитель методического центра по проектированию бизнес-процессов КЭС-Холдинг) поделился опытом внедрения процессного управления в крупном энергетическом холдинге. Выдающееся достижение - то, что удалось заразить этой идеей высшее руководство. Причем видно, что для них это не увлечение, а систематическая работа по организации бизнеса сверху-вниз на принципах BPM. Для каждого бизнес-процесса верхнего уровня назначен владелец на уровне вице-президента, и в соответствии с утвержденным положением, владелец процесса отвечает в том числе за дизайн процесса. Наличие владельца процесса - это отличный критерий чтобы определить, является ли процессное управление для компании преходящим увлечением и поводом поговорить или же образом жизни. Алексей отдельно остановился на том, как повлиял на их планы кризис: они отказались от “ковровых бомбометаний” и перешли работе адресной, малыми силами, в сжатые сроки. Похоже, они сами не поняли как им повезло: кризис случился в самый подходящий для них момент, буквально заставив их начать работать так, как собственно и рекомендуется теоретиками BPM. Если бы не кризис, они бы наверное продолжали действовать в духе старого доброго реинжиниринга, и мы бы имели шанс услышать доклад из серии “как мы дошли до документирования четвертого уровня бизнес-процессов и поняли, что до шестого мы не дойдем никогда”. А так благодаря кризису получился такой “Lean поневоле”. С другой стороны, систематически пройти два уровня процессов сверху-вниз безусловно полезно. Из доклада осталось не до конца понятно как они расставляют приоритеты процессам - похоже, интуитивно-волевым способом. Если так, то им стоило бы подойти к этому более систематически - попробовать применить TOC, на основе экспертных оценок определить потенциал улучшения процессов. Да, и до использования BPMS (а следовательно, до детального моделирования и поддержки исполнения процессов в реальном времени) они еще не дошли. А я все-таки не очень верю в BPM без BPMS. Это как бухгалтерия без компьютера - теоретически возможно, в рамках обучения полезно, но в практической работе смысла не имеет.
• Самым солидным мне показался доклад Александра Башкова (менеджер бизнес-приложений компаний “Тетра Пак”). До этого я про компанию не знал ничего, кроме названия, теперь знаю - это один из лидеров в управлении бизнес-процессов в мировом масштабе. Александр очень хорошо рассказал как организовано процессное управление на уровне глобальной компании, и что особенно интересно, про кастомизацию на региональном уровне. Известно, что компании, достигшие выдающихся достижении в области управления бизнес-процессами, зачастую добровольно делятся своим опытом - я слышал такие истории про Toyota, Xerox, Motorolla. Поэтому я задал вопрос Александра после его доклада, и он подтвердил, что действительно, в их компании такое тоже практикуется. Так что если ваша компания вынашивает амбициозные планы в области BPM, я настоятельно советую попробовать обратиться к Тетра Пак за опытом. И пожалуйста напишите здесь в комментариях, что из этого вышло.

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

Аудитория производила впечатление подготовленной - и вопросы, и кулуарные разговоры были содержательными. Диссонировали, на мой взгляд, только вопросы представителя Академии при госслужбы при Президенте РФ: как-то странно на конференции по BPM спрашивать у докладчика чем BPMS отличается от Sharepoint.

Большой упрек организаторам - заявленная дискуссия фактически не состоялась. Даже те куцые 15 минут, которые были отведены в конце регламента, не были использованы. Складывается впечатление, что организаторам это просто не нужно. Вступительный доклад сделали? сделали. Спонсорам за их деньги выступить дали? дали. А дискуссия - какой от нее прок? Только аудиторию занимать, а ее аренда денег стоит. Неправильная, близорукая позиция. Причем, это становится тенденцией - конференции не только CNews, но остальные все больше становятся похожими не на конференции, а на шоу.

Хорошо, что есть площадка семинаров BPMS.ru, где можно отвести душу - вдумчиво разобрать доклад, высказать свое мнение, подискутировать с грамотными коллегами. Кстати, очередной семинар состоится через неделю, регистрация, как обычно, на livents.ru.

Кирилл Курышев рассказал о бизнес-процессе “Управление заявкой на предоставление услуги связи”, которым команда bpexpert занималась в одной крупной телекоммуникационной компании.

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

Почему я назвал доложенный проект образцовым: в нем все делалось как положено -

1. Отсутствие четко сформулированных требований на входе проекта. В настоящих проектах BPM по-другому не бывает. Начиная, ты никогда не знаешь какой процесс у тебя получится в результате. Выявление процесса (process discovery) в ходе проекта, пять итераций схемы процесса от старта проекта до запуска процесса в эксплуатацию - это классика.
2. Разработка в стиле agile: короткими циклами, с постоянной обратной связью с заказчиком. Говорим BPM - подразумеваем agile!
3. Добротный инструмент Oracle BPM Studio (aka BEA AquaLogic BPM). Бывает так, что основное содержание проекта - борьба с инструментом. Но не в данном случае. Докладчик отметил: были моменты, когда у них возникали затруднения с реализацией в Oracle требований заказчика. В этих случаях они поступали очень правильно: не насиловали инструмент, а пытались работать в том стиле, который он предлагает. В частности, им удалось обойтись “малой кровью” в решении задач, связанных с авторизацией, ролями, делегированием, замещением и т.п. (п.8 моей недавней заметки). Удалось заинтересовать заказчика возможностями имитационного моделирования (simulation), действительно неплохими в Oracle.
4. Удалось принести пользу “заказчику заказчика”, т.е. клиентам компании: среднее время обработки заказа уменьшилось с 5 до 3 дней. В рамках пилотного, по сути, проекта, этого добиться удается не часто.
5. Использование eTOM не как инструкции - “делай раз - делай два”, а как справочника. Т.е. живешь, все-таки своим умом, но время от времени сверяешься с образцом. Такая сверка позволяет существенно повысить ценность решения при незначительном расширении проекта, что и было наглядно нам продемонстрировано.
6. Стремление сделать протекание процесса если не полностью автоматическим (т.е. довести его до STP, straight-through process), то максимально гладким. Похоже, проектная команда интуитивно нашла известный, в общем-то, магистральный путь: направлять человеку только те задания, которые не удалось обработать автоматически. Т.е. использовать человека в качестве “обработчика бизнес-исключений”.
7. И главное: всего за 20 рабочих и 30 человеко-дней им удалось запустить процесс в промышленную эксплуатацию. Скептики посрамлены!
8. Причем есть одна пикантная подробность: на самом деле это была вторая попытка компании-заказчика чего-то добиться при помощи BPM. Причем в первой попытке BPM-система была та же самая, только исполнитель другой. Как я и говорил однажды на конференции: прежде чем критиковать BPM, убедитесь сначала, что то, что вы делаете - это действительно BPM. По-видимому, первая попытка как раз и не была попыткой BPM. И тем ценнее результат команды bpexpert, ведь добиться успеха после фальстарта вдвойне труднее.
9. И последнее - то, что стало предметом оживленной дискуссии после доклада: удалось не только успешно выполнить проект, доведя его до промышленной эксплуатации; по утверждению докладчика, им удалось передать заказчику и компетенцию, и интерес к тому, чтобы продолжать работать над процессом все в большей и большей мере самостоятельно. Этим могут похвастаться очень немногие проекты, а ведь без этого, положа руку на сердце, тоже нельзя говорить о BPM в полном смысле слова.

Должен признаться, у меня даже не получается как положено выдать порцию критики (хотя обычно с этим проблем нет). Ну разве что по мелочи:

1. Хотелось бы все-таки увидеть экраны пользовательского интерфейса. Понимаю, что это не главное, понимаю, что время ограниченно, но все же.
2. Процесс реализован в виде одного монолитного куска, причем сложность его уже, на мой взгляд, на пределе. С учетом того, что процесс должен обслуживать разные услуги, обрабатываемые по разным алгоритмам, я бы скорее ожидал увидеть некоторую центральную часть процесса и отдельно - подпроцессы для каждого вида услуги, желательно технически реализованных как независимые модули. Это добавило бы масштабируемости: в дальнейшем заказчик сможет добавлять новые виды услуг, не трогая уже отлаженную общую часть процесса. Впрочем, с другой стороны, это утяжелило бы проект, поэтому наверное правильно в пилоте они обошлись без этого. Главное теперь не откладывать рефакторинг слишком надолго.

Интересуетесь BPM? Свободны вечером в среду 7 октября? Приходите обсудить за чашкой кофе очередной BPM-проект. Регистрация тут.

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

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

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

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

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

Правда, был момент, когда дискуссия свернула не туда: мы чуть не свалились в религиозную войну на тему “что такое BPM”. А заодно - “что такое процессное управление”, “что такое документооборот” и в итоге “так что же такое, в конце концов, бизнес-процесс”?! Все это можно обсуждать и спорить, только лучше не на семинаре - никто ведь не отменял форумы, блоги и т.п. Например, есть новая площадка BPM Nexus, которую люди организовали специально для сверки и сближения позиций, а в идеале - для выработки консенсуса. У семинара другая, уникальная функция: рассмотрение реальных проектов, конкретных проблем создания BPM-систем (и в смысле ПО, и в смысле организации как системы). Как показывает опыт, для этого не подходят ни онлайновые ресурсы, ни конференции. Поэтому давайте оставаться именно в этом формате, ценить время семинаров и не тратить его на вопросы, которые можно обсуждать в других рамках.

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

По регламенту. Если время вышло, а докладчик закругляться не собирается, то председатель должен прервать его словами: “отведенное регламентом время закончилось, сколько еще вам надо?” и, получив ответ, обратиться уже к аудитории: “ну как, дадим?”. Это способствует атмосфере взаимного уважения.

Переходя к существу доклада - нам был представлен уникальный, без преувеличения, опыт тотального внедрения процессного управления (и процессного мышления) в компании численностью 700 человек. К тому же мы получили “два доклада в одном”: помимо основной темы использования Runa WFE нам рассказали про реализацию управление бизнес-процессов средствами 1С. Сравнение получилось интересным и поучительным.

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

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

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

Осталось у меня и несколько вопросов по докладу:

1. Использование Runa WFE с jBPM и вообще технологическим стеком jBOSS. Особенно с учетом того, что выходит 4-я версия jBPM, которая мне представляется весьма интересной. В частности, в ней jBPM переходит к нотации, близкой к BPMN.
2. Привязка к бумажным документам. Непонятно почему нельзя обойтись без них, непонятно даже - рассматривалась ли вообще безбумажная альтернатива. Вместо того, чтобы гонять в процессе бумажные документы, можно было собирать структурированную информацию, передавать электронные задания, а бумаги печатать на основе собранных данных только там, где это абсолютно необходимо (например, командировочное удостоверение, с которым сотрудник поедет  в чужую организацию). Но зачем в виде документов нужны заявление на отпуск или авансовый отчет - я не понимаю. Вроде мы рассматривали не колхоз “сорок лет без урожая”, а прогрессивную организацию! Естественно, в результате возникла масса проблем - ну не рассчитаны BPMS на такую работу.
3. Докладчик упомянул, что в какой-то момент возникли проблемы с масштабированием, которые были успешно решены. Хотелось бы получить подробности, но понятно, что все рассказывать в подробностях - никакого регламента не хватит.

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

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

Очередной семинар BPMS.ru пройдет в среду 24 июня; время и место прежние. Андрей Михеев расскажет про практические применения своего детища Runa WFE.

Регистрация была организована через livents.ru, но он лежит уже больше недели (кстати, кто-нибудь знает что с ним?), записывайтесь через контактный адрес на bpms.ru.

Обращаю внимание почтеннейшей публики, что 8 июля, т.е. всего через две недели, мы проведем еще один семинар, чтобы потом сделать длинную паузу до осени (скорее всего до октября).