Кирилл Курышев рассказал о бизнес-процессе “Управление заявкой на предоставление услуги связи”, которым команда 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 июля, т.е. всего через две недели, мы проведем еще один семинар, чтобы потом сделать длинную паузу до осени (скорее всего до октября).

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

Так что если хотите принять участие в профессиональном разговоре на тему BPM - регистрируйтесь и приходите.

Тема: “Бизнес-процессы, современный взгляд”.

Аудитория Школы Своего Бизнеса (www.shsb.ru) - состоявшиеся предприниматели и менеджеры, а также те, кто хотел бы ими стать. Соответственно, доклад будет рассчитан на бизнес-аудиторию: что такое бизнес-процесс и процессное управление, чего можно добиться с их помощью и как их организовать. ИТ-аспекты управления бизнес-процессов будут представлены в минимальном объеме.

Дата: четверг 15.01.09. Время: 19:00-21:00. Адрес: м. Электрозаводская, Семеновская наб. 3/1 корп.6 подъезд 6/1.  Схема проезда. Стоимость гостевого участия - 300 руб.

Вдогонку к прошедшему семинару и отчету о нем - ответы на вопросы:

Интересно у Unify есть какие-нить средства для сбора статистики по мониторингу БП?

Статистика в любой BPMS накапливается автоматически: информация обо всех событиях (старт процесса, переход к следующему шагу, изменение атрибутов и т.д.) записывается в журнал (т.е. в реляционную СУБД) вместе с отметками о пользователе и времени события. Дальше возможны варианты: практически все системы (включая Unify NXJ) предоставляют готовые и/или позволяют конструировать то, что называется dashboard - панели приборов для мониторинга в реальном времени; более развитые системы строят по оперативным данным аналитические кубы и стыкуются со средствами BI.

…по идеи после мониторинга и моделирования БП можно увидеть - где есть задержки в БП, где можно уменьшить потери и т.д.

По идее, для этого в первую очередь нужна не столько статистика, сколько средства имитационного моделирования по методу Монте-Карло (simulation). Для оптимизации интересно ведь получить ответ не столько на вопрос “что мы имеем”, сколько на вопрос “что будет, если”. В идеале нужно иметь и то, и другое, и иметь возможность подать на вход Монте-Карло фактическую статистику, например, распределение продолжительности времени выполнения каждого шага, распределение входных параметров и т.п. А еще надо бы уметь запускать Монте-Карло не по одному процессу, а одновременно по нескольким - ведь они зачастую конкурируют за один и тот же ресурс, и поэтому моделирование изолированного процесса не будет реалистичным. Поиграться с этим рекомендую на Oracle BPM Suite (a.k.a. BEA AquaLogic) - он умеет и то, и другое.

Управление БП нужно только для некоторых “проблемных” БП, а не для всех БП предприятия. Но как тогда быть с остальными БП?

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

Почему Анатолий дает определение ВРМ как “сочетание управленческо методологии, информационных технологий и организационных принципов, направленных на реализацию процессного управления”, а потом ставит вопрос - “Существует ли BPM без BPMS? Бухгалтерия без бухгалтерских программ?”?

Это потому, что кое-кто опоздал к началу семинара Я ведь начал с того, что предупредил: в области процессного управления сегодня сосуществуют несколько парадигм. Я придерживаюсь той точки зрения, что BPM без BPMS - это абстракция пожалуй даже в большей степени, чем бухгалтерия без бухгалтерского софта. Но на этот счет есть и другие точки зрения, например, ISO 9000 - это тоже в некотором роде управление бизнес-процессами.

Не совсем понятно каким образом будет преобразовываться сквозные сложные БП уровня предприятия в исполняемое приложение.

Умеренной сложности пример реализации сквозного процесса опубликован на сайте Бизнес-Консоль.

BPMS - это вещь сама в себе, которая слабо\никак интегрируется с остальные проектными решениями (Системами Управления Требованиями, Средствами Разработки и т.д.)

Напротив, любая BPMS либо поставляется в комплекте, либо хорошо интегрирована с инструментарием разработки пользовательских и системных интерфейсов. Например, Unify NXJ идет в комплекте со средой разработки экранных форм и веб-сервисов. И все BPMS без исключения ориентированы на SOA.

…есть разрав между Целями\Стратегией\Архитектурой Предприятия (ИТ включаем) - Управления БП - Разработкой ПО

Реально существующая проблема - сегодняшние BPMS нацелены на управление отдельным бизнес-процессом. С другой стороны, есть средства Enterprise Architecture (например тот же ARIS), которые способны охватить сеть процессов компании. Но они не дотягиваются до исполнения процесса. Как будет решаться эта проблема? Брюс Силвер полагает, что BPMS будут развиваться в направлении EA.