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

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

Базовое допущение BPMN 3: К задаче прилагается инструкция

Базовые допущения BPMN:

  1. Вся информация сохраняется
  2. У организации есть механизм назначения и передачи поручений
  3. К каждой задаче прилагается инструкция
  4. У задач есть нормативные сроки, а у организации - механизм их контроля

3. К каждой задаче прилагается инструкция

Эта рекомендация совсем простая: еще один способ упростить диаграмму – вовремя вспомнить, что к любой задаче можно прикрепить текстовое описание и/или инструкцию для исполнителя.

Это позволяет вместо вот такой схемы (взятой из студенческой работы на BPMN-тренинге) –

обойтись простой и изящной:

а все подробности приемки – как общаться с клиентом, что должно быть в документе, как регистрировать в ERP – опустить на уровень инструкций к задаче. В названии задач отразить только главные, конечные результаты цепочки активностей на данном участке.

Правда с этим не все согласятся – кто-то может сказать, что первая схема лучше, ведь она более детальная.

Прежде всего, надо разобраться с какой целью мы моделируем бизнес-процессы. Среди всего многообразия вариантов выделю два:

  1. Чтобы научить сотрудников выполнять свои обязанности.
  2. Чтобы повысить эффективность кросс-функциональных, сквозных процессов.

В первом случае лучше первый вариант схемы процесса, во втором – второй. Мне лично ближе второй вариант – объясню почему:

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

Теоретически между двумя обозначенными целями – моделирование процедур на уровне отдельного рабочего места и моделирование сквозных бизнес-процессов – противоречия нет, а BPMN в принципе годится и для того, и для другого. Но на практике почему-то получается или одно, или другое: как только аналитик чересчур концентрируется на процедурных деталях, он теряет из виду «большую» картину. И наоборот: если начать проектировать процесс как сквозной (т.е. начинающийся и заканчивающийся на клиенте), то желание заниматься микроменеджментом как-то пропадает.

Еще одна причина, по которой мне больше импонирует вторая схема – ее большая устойчивость.

Есть такой эффект: любой процесс, если его слишком глубоко детализировать, превращается в кейс. Например, с задачей «Купить персик» справится любой. Но что если слишком увлечься детализацией?

- Милый, я, пожалуй, съела бы персик.

Малыш Мак-Гарри встал и надел пальто и шляпу. Он был серьезен, строен, сентиментален и сметлив.

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

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

У О.Генри в рассказе «Персики» дело в итоге закончилось тем, что полиция перевернула вверх дном притон Денвера Дика. Могла ли новобрачная предусмотреть такие расклады в схеме процесса? Очевидно нет. Какой отсюда вывод – нас спасет ACM? А может просто ограничиться задачей, доверив ее надежному исполнителю?

Даешь управление по целям вместо микроменеджмента!

Еще по теме:

Окончание следует…

05.01.13 | Статьи | ,    

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

  1. Дмитрий Бацюро 06.01.13 17:54

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

    К сожалению, в BPMN отсутствует способ выделить переход от уровня бизнес-процесса к уровню технологического - чтобы не репутать это с подпроцессом, когда мы на более нижнем уровне все еще продолжаем моделировать бизнес-процесс. Может быть, в следующую версию стандарта это включат (как бы это предложить? могу эту идею более полно развернуть). Ведь не секрет, что некоторые технологические схемы удобно обозначать в виде диаграммы, а не в виде текстового описания, и почему бы тогда не использовать ту же нотацию, но при этом четко обозначить водораздел между этими двумя уровнями.

  2. Дмитрий Бацюро 06.01.13 17:56

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

  3. Anatoly Belychook 06.01.13 20:57

    Дмитрий

    Предложенное Вами терминологическое деление мне нравится. Что касается внесения в стандарт - вряд ли, BPMN сознательно сделан методологически нейтральным. Внесите во внутренний стандарт моделирования.

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

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

  4. Дмитрий Бацюро 06.01.13 23:56

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

    В таком подходе есть следующие особенности, из-за которых это не всегда работает - в особенности, в России:
    1) Серис для процессов, которые его вызывают, представляется черным ящиком с определенными интерфейсами и установленным SLA. Т.е. вмешиваться в его устройство при построении вызывающих его процессов нельзя - иначе это будет уже не внутрисервисный подход.
    2) Из п. 1 следует, что кто-то должен отдельно организовать бизнес-процессы самого сервиса. Обычно это отдают на откуп самому его владельцу. В случае с ИТ это работает (хотя тоже не всегда :-) ), поскольку есть такой фреймворк по организации ИТ-сервиса, как ITIL, и ИТ-руководители в большей степени, чем другие, являются приверженцами процессного или сервисного подхода. С сервисами типа логистического или еще какого-то дела обстоят хуже, поскольку их владельцы хуже разбираются, как управлять деятельностью именно как сервисом.
    3) Поскольку сервисный процесс - это всегда отдельный пул в терминах BPMN, возникает следствие из теории ограниченных систем, о котором вы сами много рассказывали: сглаживаются пики входной загрузки сервиса, но снижается удовлетворенность потребителя (в данном случае, внутреннего).

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

  5. Дмитрий Бацюро 07.01.13 00:02

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

  6. Anatoly Belychook 07.01.13 08:24

    >> указание бизнес-аналитику - не лезть в эти дебри
    +100500

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

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

    >> сервисный процесс - это всегда отдельный пул в терминах BPMN
    Почему? Я его вижу как подпроцесс. Вызывается синхронно. Никаких проблем.

  7. Дмитрий Бацюро 07.01.13 22:43

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

    >>>> дела обстоят хуже, поскольку их владельцы хуже разбираются, как управлять деятельностью именно как сервисом
    > Мне кажется, все не так страшно. Создавать фреймворк не требуется…
    Речь не о том, чтобы абсолютно все сначала создавали некий абстрактный фреймворк, а потом еще и выстраивали свою деятельность в соответствии с ним. Я имел в виду, что ИТ такой фреймворк уже есть, многие ИТ-руководители с ним знакомы и руководствуют им при выстраивании ИТ-сервиса. А в других областях таких фреймворков может не быть, и там от руководителей требуется определенный талант, чтобы в отсутствие фреймворка (т.е. подсказки) создать хорошо функционирующий сервис. К сожалению, не часто это получается.

    >>>> сервисный процесс - это всегда отдельный пул в терминах BPMN
    >> Почему? Я его вижу как подпроцесс. Вызывается синхронно. Никаких проблем.
    Вызывается синхронно, но исполняется не вполне синхронно. Т.е. вызывающий процесс дает заявку на сервис, эту заявку кто-то принимает синхронно по отношению к вызывающему процессу (если этот процесс не полностью автоматизирован), а дальше заявка на сервис ложится в базу заявок, сервис исполняет ее по своей логике (аналогия с паттерном производственного заказа), в процессе может произойти еще какое-то общение между сервисом и вызывающим процессом в случае каких-то нестандартных ситуаций, в конце сервис сообщает, что он завершил обработку заявки, и вызывающий процесс тогда продолжается. Т.е. все-таки ситуация отличается от той, когда мы просто вызываем подпроцесс, который полностью исполняется внутри определенного подразделения, и выстраивание которого отдается полностью на откуп его руководителю.
    Я изобразил, что я имею в виду: https://docs.google.com/open?id=0B8N0PG6hk_54ajF3U09BaVkta28

  8. Anatoly Belychook 07.01.13 22:52

    Дмитрий

    Можно и так как Вы изобразили, но я не вижу причин почему сервис не может вызываться синхронно, просто как подпроцесс. Заявки не накапливаются в буфере, а принимаются в работу незамедлительно, в темпе поступления.

  9. Дмитрий Бацюро 08.01.13 09:16

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

  10. Anatoly Belychook 08.01.13 10:04

    Дмитрий

    Что-то мы друг друга не понимаем. Может о разных вещах говорим?

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

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

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

  11. Дмитрий Бацюро 08.01.13 18:00

    До тех пор, пока внутри задачи каждого такого подразделения отсутствует взаимодействие с другими, это внутренний технологический процесс этого подразделения, и туда, как мы ранее уже обсудили, при выстраивании БП лучше не заныривать глубоко. Взаимодействие внутри подразделения в рамках этого процесса при вашем подходе должен выстроить его руководитель - ну и пусть. Т.е. на самом-то деле это не совсем в чистом виде технологический процесс, но на определенном уровне абстракции мы можем его считать таковым - с точностью до границ подразделения, а не конкретного исполнителя. Я согласен, что можно применять такой подход, хотя в нем есть два “но”:
    1) Через некоторое время руководитель подразделения замахается вручную дирижировать внутренним взаимодействием и либо потребует отстроить полноценный процесс, который будет протекать с его минимальным участием (или сделает это сам, если умеет), либо просто забьет, и сервис станет работать неуправляемо. Последнее неблаготворно скажется на соблюдении SLA, но в ряде компаний я наблюдал, как в такой ситуации на протяжении длительного времени от этого руководителя безуспешно требуют подтянуть SLA, а он либо не хочет, либо не умеет выстроить взаимодействие, а передать это бизнес-аналитикам идеология отношения как к сервису не позволяет. Замкнутый круг. :-)
    2) Как правило, в ходе выполнения сервиса может потребоваться взаимодействие с вызвавшим его процессом. Мой вариант это предусматривает без прерывания выполнения сервисной задачи, а ваш - только путем ее прерывания с ошибкой и повторного входа заново, насколько я понимаю.

  12. Anatoly Belychook 08.01.13 21:15

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

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

Captcha

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