Активность на ниве BPMN привела к тому, что меня стали воспринимать как эксперта в области анализа и моделирования бизнес-процессов. Я не против, но считаю это скорее азами ремесла, чем его вершиной, и для меня лично гораздо больший интерес представляет проблематика на стыке между BPM и управленческим консалтингом, а также методологические аспекты реализации бизнес-процессов в BPMS. Впрочем, это обычное дело: больший интерес для широкой публики обычно представляет то, что для эксперта почти тривиально, а то, что он сам считает достижением, проходит почти незамеченным. В качестве примера, наибольшее число просмотров и откликов на моем блоге набирают заметки с тэгом FAQ.
Вот и редактор портала ebizQ Питер Шофф записал подкаст, представив меня в роли «modeling guy». Впрочем, если Питер считает, что сегодня актуально именно это, то у меня нет никакого желания с ним спорить. Оригинал подкаста на английском: «Process discovery and modeling done right» (расшифровка на английском).
ebizQ: Здравствуйте, это Питер Шофф из ebizQ и сегодня я снова имею удовольствие говорить с Анатолием Белайчуком, президентом компании Бизнес-Консоль, Москва, занимающейся разработкой и консалтингом в области BPM. Сегодня мы собираемся поговорить о выявлении и моделировании процессов, в которых Анатолий является признанным экспертом. Прежде всего, Анатолий, еще раз огромное спасибо за участие.
АБ: Здравствуйте Питер, рад снова Вас слышать. Спасибо за оценку моих усилий, с удовольствием с Вами побеседую.
ebizQ: Хорошо. Итак, читая Ваш блог в последнее время, я увидел, что вы подняли вопрос о классификации, которую можно использовать для BPM.
АБ: Позвольте мне сначала объяснить, почему я вообще озаботился всей этой классификацией. Как и большая часть того, что делаю на блоге, это не теоретическое упражнение или что-то вроде этого. На самом деле, это ответ на повторяющиеся вопросы от клиентов и потенциальных клиентов. Многих из них приводит в смущение широкий спектр самых разнообразных вещей, каждая из которых называется BPM. Чистое моделирование и документирование процессов многие сегодня называют BPM. Далее, автоматизация процесса тоже называется BPM, а если используется BPMS, то это точно BPM. И даже то, что в 90-е называлось реинжинирингом, сегодня называют BPM. Это очень странная ситуация. Тут я должен признаться, что до недавнего времени был немного экстремистом, потому что я убеждал людей, что все эти методы не есть «настоящий» BPM. Под настоящим, или полномасштабным, или современным BPM, я понимаю цельную и конкретную дисциплину, разработанную за последнее десятилетие, которая охватывает методологию, технологию и принципы реализация.
Это проверенный способ получить значительные бизнес-преимущества за счет улучшения критических бизнес-процессов. Но тут клиенты задают вопрос: «должны ли мы применять полномасштабный BPM ко всем нашим бизнес-процессам?» Ответ, очевидно, отрицательный. Потому что это не только самый мощный способ улучшить ваш бизнес-процесс, но также и самый дорогой способ, так что это будет просто не по карману. Реальное применение BPM - это относительно короткий список процессов, управляемых таким способом, и основная массам процессов, которые управляются не очень продвинутыми, но менее дорогостоящими технологиями и методами. Так я пришел к идее классификации BPM. Чтобы внести ясность, я предложил следующие уровни классификации. BPM уровень 1 - это чистое моделирование и документирование. BPM уровень 2 - это автоматизация изолированных процессов, или workflow. И BPM уровень 3 - это замкнутый цикл управления сетью процессов, составляющих сквозной бизнес-процесс. Можно еще сюда добавить уровень 0 - процессы, исполняющиеся неформально, так сказать, под ковром. Эта классификация напоминает хорошо известную модель компании Gartner, она соответствует первым трем уровням модели Gartner. Но мне кажется, она проще и ее легче объяснять, потому что мне никогда не удавалось объяснить модель Gartner потенциальным клиентам.
И еще одно отличие: за этой классификацией стоит концепция многоскоростного BPM. Если организация достигла BPM уровня 3, то это не значит, что она применяет методы и технологии 3-го уровня для всех своих процессов. Нет, это означает только, что она способна взять любой процесс по своему выбору и довести его до 3-го уровня. Но большинство процессов при этом будет управляться на уровне 2, 1 или даже на уровне 0, и это вполне нормально. Так что уровень BPM говорит о способности, а не о фактической реализации - это второй момент.
ebizQ: Очень интересно. Теперь, чтобы погрузиться в выявление и моделирование,- как Вы оцениваете текущее состояние выявления и моделирования в организациях?
АБ: Я полагаю, что как раз сейчас очень интересный момент, когда BPMN становится мэйнстримом. Мы видим это по растущему числу вопросов о BPMN от клиентов. Мы видим это по росту числа заказов наших BPMN-тренингов. И мы видим, как во многих организациях BPMN дает новую жизнь процессным усилиям. Некоторые организации задумываются о переносе существующих схем и моделей в BPMN. Другие присматриваются к исполняемому BPMN, что для многих является новой и свежей идеей, и это путь прямо к BPM 3-го уровня.
Я верю, что это огромный шаг для всей отрасли BPM, и мы все являемся должниками ребят из комитета OMG, которые смогли достичь консенсуса и опубликовать стандарт BPMN 2.0. Он может быть не идеален, но это не имеет значения, потому что мы видим, что родился общепризнанный стандарт, а это в нашей отрасли происходит не часто.
Поэтому я считаю, что этот год станет важной вехой для любого историка BPM, который посмотрит назад из будущего, благодаря финализации BPMN 2.0.
И еще один момент, касающийся BPMN: если мы вернемся к концепции многоскоростного BPM, которую я только что описал, то BPMN тут имеет большое преимущество. Он обеспечивает плавный переход от нижних к верхним уровням. Вы можете начать с рисования некоторых упрощенных аналитических BPMN-моделей, используя всего несколько элементов BPMN: очень просто, не требуется какое-то обучение, все можно освоить очень быстро. Но вам открывается путь к достижению любого уровня по желанию, в том числе 3-го уровня. Вы просто расширяете свою палитру BPMN и делаете модель более сложной, более тщательно описывающей процесс. И это большое дело, а другая конкурирующая нотация не сможет провести вас этим путем, так что это большое преимущество.
ebizQ: Да, это звучит как большое преимущество. Теперь, как по-вашему, насколько важно получить взгляд на процессы «как есть», и как лучше всего это сделать?
АБ: Очевидно, есть две основные точки зрения на этот вопрос. Если вспомнить известные слова «не мостить коровьи тропы», то они говорят, что ключевой является оптимизация. Но на самом деле, всегда есть выбор. Либо мы начнем с оптимизации и внедряем оптимизированную версию процесса, либо мы сначала берем процесс под контроль, а затем улучшаем его, оптимизируем его в один шаг, в несколько шагов - как захотим. Я считаю, что путь BPM - это второй вариант. Мы всегда идем этим путем, поэтому процесс «как есть» является отправной точкой нашего проекта BPM, так что это, очевидно, очень важная вещь.
Что касается выявления процесса, то есть старые, хорошо известные и проверенные методы, например опрос участников или прохождение процесса плечом к плечу с исполнителем, и все они работают хорошо. Но самый лучший способ выявления процесса по нашему опыту - это короткий цикл, включающий моделирование, выполнение процесса в тестовой среде в BPMS (мы называем это верификацией) и затем исправление найденных в модели проблем.
Современные BPMS настолько хороши в прототипировании, что этот цикл можно прокручивать за часы, если не за минуты. Удивительно, насколько это эффективный способ выявления процесса. Это происходит раз за разом: вы посмотрите на модель процесса, на диаграмму процесса, и она выглядит просто отлично, но как только вы пытаетесь ее запустить, вы сталкиваетесь с разнообразными проблемами в процессе. Например оказываются пропущены потоки управления, пропущены входные данные, не хватает исключений или наоборот есть лишние задачи, неверная последовательность задач. Вы прогоняете этот цикл 5, 6, 10 раз, и вы получите не просто процесс, а единственно верный процесс. Вы в нем уверены, вы знаете, что он может быть выполнен и что входы и выходы связаны между собой. Так что это лучший способ, который я знаю.
ebizQ: В это на самом деле есть большой смысл. А что по Вашему мнению является наилучшей практикой эффективного моделирования процесса?
АБ: Вы могли заметить из моего блога, что я сторонник процессных паттернов. Паттерн представляет собой типичный фрагмент процесса, общий для множества процессов реального мира. Парное слово для паттерна - распознавание. При надлежащей подготовке и некоторой практике, процессный аналитик просто видит знакомые паттерны в процессной задаче, над которой он работает. И таким образом он или она получает результаты гораздо быстрее, и они меньше подвержены ошибкам, потому что основаны на проверенных паттернах.
Небольшое замечание: я здесь говорю не об элементарных паттернах, разработанных Ван Аалстом и другими для оценки процессных движков. Речь идет о высокоуровневых и более бизнес-ориентированных паттернах, таких как планирование ресурсов или внутренний заказ, опубликованных на моем блоге. Общей темой является сопоставление паттернов и шаблонов. Мое личное мнение таково, что шаблоны менее полезны, потому что те, которые я встречал, относятся к вспомогательным процессам, всерьез не оказывающим влияния на бизнес. Никто не отдает свои основные бизнес-процессы в публичный доступ. Это что касается паттернов.
Еще одна ключевая техника моделирования - процессная декомпозиция. Опять-таки, это определенное видение и способ мышления, которые должен развивать каждый процессный аналитик. Это способность видеть уровни абстракции и технические знания того, как изолировать эти уровни в подпроцессах BPMN. Так что вот две рекомендации, которыми я могу поделиться.
ebizQ: Приятно слышать. Теперь с другой стороны: какие самые большие ошибки вы видите у компаний, выявляющих и моделирующих процессы?
АБ: Я могу указать на одну из самых больших, но очень распространенную ошибку. Она называется «поставить во главу угла процессную функциональность». Потому что правильный путь - это начать с бизнес-проблем, потом перейти к процессным проблемам и на третьем шаге перейти к процессной функциональности. Таким образом, вы начинаете с того, что проговариваете текущие бизнес-цели и определяете бизнес-процессы, отвечающие за достижение этих целей. Затем вы устанавливаете целевые показатели для этих процессов и только потом переходите к желаемой функциональности процесса.
К сожалению, слишком часто люди и организации переходят сразу к процессной функциональности. Большинство осознает насколько сильно процессная архитектура и окончательная схема процесса зависят от конкретных бизнес-целей, от которых они отталкиваются. Если краеугольным камнем процесса разработки или анализа были бизнес-цели, то в итоге в процессе реализуется больше контроля, больше мониторинга, больше эскалаций. В противном случае, если сразу начинают с процессной функциональности, процесс оказывается перегружен микроменеджментом, а кросс-функциональные проблемы оказываются за рамками и не находят решения, и я считаю, что это самая большая ошибка, которую можно совершить.
ebizQ: Очень интересно. Это был разговор Питера Шофф из ebizQ с Анатолием Белайчуком, президентом Бизнес-Консоль. Большое спасибо за сегодняшнюю ценную информацию, Анатолий.
АБ: Спасибо за вопросы, Питер. С удовольствием поделился мыслями с Вами и с нашими слушателями.
