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