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

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

Семинар 07.10.09: образцовый проект BPM

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

Комментарии (5)

  1. Alex Capital 15.10.09 00:22

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

  2. Anatoly Belychook 15.10.09 07:12

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

  3. Кузин Сергей 16.10.09 09:33

    Выявлены общие вещи, которые раз за разом реализуются при реализации процессов:
    1. Управление ходом выполнения процесса (диспетчеризации, эскалации, контроль времени выполнения, …). Наблюдаю подобные решения с 2006 г., сам реализовывал тоже.
    2. По п.6 - так и есть, в этом основная цель процессного управления - 80% ситуаций “разруливаются” исполнителями по поставленным процессам, 20% - на более высоком уровне в качестве обработки исключений.
    3. Прозвучало довольно любопытное высказывание презентатора: моделирование процесса во взаимодействии с Заказчиком - лишь 20% работы по проекту, остальное - реализация кода.

  4. Anatoly Belychook 16.10.09 10:37

    Сергей

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

  5. Кузин Сергей 19.10.09 11:57

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

А что вы думаете?

Captcha

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