Альтернативы BPM

21 апреля 2014
41

В первой части мы коротко охарактеризовали черты управления бизнес-процессами (BPM) в современном прочтении, и показали, за что тут стоит бороться – каких успехов удается добиться компаниям, преуспевшим в BPM.

Но если BPM такая классная вещь, то почему тогда он до сих пор не достиг всеобщего признания и повсеместного внедрения? Короткий ответ – потому что BPM способен дать заведомо меньше, чем другие подходы обещают.

Ведь недостатка в предложениях волшебных рецептов наведения порядка в бизнесе не наблюдается. BPM – это стратегия, BPM – это сложно… спрашивается зачем, если на соседней конференции предлагают более простые и понятные рецепты, и тоже вместе с впечатляющими историями успеха от их внедрения?

С другой стороны, энтузиастов BPM можно упрекнуть в том, что они зациклены на своих бизнес-процессах. Для них процессное управление – это ценность, которая принимается за аксиому. Они убеждают, что надо все бросать и срочно заниматься бизнес-процессами, но может им просто не хватает широты кругозора?

Давайте попытаемся честно сравнить BPM с популярными альтернативами.

1. Управление поручениями

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

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

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

С процессной точки зрения, поручение – это такой «армейский бизнес-процесс» из одного шага: выполнить и об исполнении доложить. Внедрив процессную систему, вы заодно решите и задачу управления поручениями, обратное же утверждение неверно.

Вывод: управление поручениями – это паллиатив: да, мы будем видеть, кому назначена задача, но это совершенно не помешает, например, сотрудникам играть в «корпоративный футбол» – до бесконечности перепасовывать поручения друг другу.

2. Документооборот и ECM

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

Разница эта двоякая: технологическая и методологическая.

С технологической точки зрения необходимо различать задачи управления контентом (сканирования, распознавания, хранения, индексации и т.п.) – этим занимаются системы ECM – и задачи управления процессами. Функциональность ECM с функциональностью BPMS не пересекается, и все BPMS-вендоры рекомендуют использовать эти системы совместно.

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

Еще существеннее отличие методологическое: управление бизнес-процессами оперирует понятием ценности для клиента, причем документ априори (пока не доказано обратное) не считается представляющим ценности для клиента. В процессной работе все внимание уделяется тому, кто, что и в какой последовательности должен сделать, а документы появляются как побочный результат выполнения работы.

Документооборот же понятием ценности для клиента вообще не оперирует. Здесь документ – это альфа и омега, начало и основа миропорядка. Внедрение документооборота просто «бетонирует» сложившиеся неэффективные схемы работы («асфальтирует коровьи тропы», по знаменитому выражению Майкла Хаммера). Порядка в документах становится больше, но их число не только не уменьшается, а зачастую даже увеличивается.

Разумеется, сказанное не означает, что документы не нужны; сказать, что такое-то действие не добавляет ценности – это еще не все: действие может не добавлять ценности, но при этом быть необходимым. Речь о другом: о том, что надо концентрироваться на работе и на кратчайшем пути к цели, которая определяется клиентом, с соблюдением ограничений на документальное оформление, налагаемых законодательством.

Вывод: нужно навести порядок в канцелярии – внедряйте документооборот. Хотите достичь новых высот в бизнесе – занимайтесь BPM.

3. Управление проектами

Есть организации, которые традиционно рассматривают свою деятельность как проектную. Например, фармацевтическая компания разрабатывает новый лекарственный препарат – что это? До определенного момента компания считала, что проект. Но затем обнаружила (реальная история реальной компании), что у этих проектов есть типовой шаблон. А значит, это уже не проект, а бизнес-процесс.

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

У проектного управления по сравнению спроцессныместь два недостатка. Во-первых, он требует использования дорогого и дефицитного ресурса – менеджера проекта. В процессной системе его функцию выполняет «робот» – процессный движок.

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

В системах BPMS выполнение работы и контроль – это одно и то же: задача доставляется исполнителю вместе с контентом (входными данными), и отметить задачу как выполненную нельзя иначе как заполнив выходные данные и/или приняв решение.

Но у проектного управления есть преимущество, которое способно перекрыть все его недостатки: вы имеете возможность вносить изменения в проект на лету. Проектные системы постепенно движутся в эту сторону, развивая функциональность ACM – Adaptive Case Management, но в основном все же ориентированы на рутинную, предсказуемую работу.

Еще один штрих к картине: проектное управление строится на основе процессов (процесс открытия проекта, процесс пересмотра параметров проекта, процесс закрытия проекта), а внедрение BPM представляет собой последовательность проектов.

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

4. Отчетность и аналитика: BI (Business Intelligence), BSC (Balanced Score Card), EPM (Enterprise Performance Management)

Перечисленные подходы роднит то, что все они представляют собой обратный канал управления бизнесом. BPM – это и прямой, и обратный каналы.

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

Возвращаясь к бизнесу и менеджменту – предположим, вам дали первоклассную систему отчетности: вверх и вниз, вдоль и поперек. Все мыслимые разрезы, все в реальном времени и в максимально удобном виде на планшете. Похоже на фантастику, но пусть.

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

Никто не отрицает ценность отчетности, но у нее есть один недостаток: ею нельзя командовать. Отчетность – это замечательно, но управлять вы можете только процессами.

Вывод: хотите быть «пассажиром» – внедряйте систему контроля показателей, хотите быть «водителем» – внедряйте BPM.

5. ERP и другие корпоративные системы

Если проектное и процессное управление – два взаимодополняющих элемента, то ERP(а также CRM, PLM, MESи другие корпоративные информационные системы) – это тот фундамент, на котором стоит любое управление современным предприятием, включая проектное и процессное.

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

Но не пытайтесь с помощью ERP заменить BPM, т.е. реализовать средствами ERP управление ключевыми бизнес-процессами компании.

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

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

Методологически, ERP– это, по сути, старый добрый реинжиниринг с его «asis» и «tobe». Проектная методология ERP – это вариации на тему классического «водопада». ERP рассматривает бизнес-процессы как нечто статическое: проанализировали, закодировали – запустили в эксплуатацию.

Но вся практика BPM свидетельствует, что такой подход не работает, потому что бизнес-процессам присуща изменчивость. В особенности это относится к процессам сквозным, взаимодействующим с клиентами. Поэтому BPM обязан следовать методологии Agileв том или ином виде. Процессная работа – это «roundtrip», а не «oneway».

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

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

Вывод: хотите первоклассные транзакции – внедряйте ERP, хотите первоклассные процессы – внедряйте BPM.

6. SOA (Service Oriented Architecture, сервис-ориентированная архитектура)

SOA сегодня превратилась в де-факто стандарт для интеграции компьютерных систем, и в этом качестве ее польза несомненна.

Системы класса ESB (Enterprise Service Bus, корпоративная сервисная шина) стали неотъемлемой частью корпоративного ИТ-ландшафта. Косвенный показатель зрелости этой технологии – наличие достаточно качественных Open Source реализаций.

Все современные системы BPMS разрабатывались уже в сервис-ориентированную эпоху, и поэтому являются «добропорядочными гражданами» SOA-среды. Они умеют вызывать вебсервисы и, что не менее важно, предоставляют в виде вебсервисов свои API, т.е. дают возможность вызывать свои функции извне. Например, исполняющийся в BPMS бизнес-процесс может отправить в ERP информацию об утвержденном заказе и получить обратно сообщение о поступлении оплаты от заказчика.

Поэтому BPMS и ESB – органично дополняющие друг друга технологии, и в идеале организации нужно и то, и другое.

Но поскольку живем мы в неидеальном мире, уместно будет сделать пару предостережений.

Во-первых, надо рассчитывать свои силы. Хочется конечно всего и еще вчера, но вряд ли оправданным будет решение внедрять BPM и SOA (ESB) в одной связке. Это проекты сильно различающиеся по целям, по участникам, по срокам. ИТ-службы склонны переоценивать значимость интеграции в управлении бизнес-процессами. Это конечно важный, но не самый важный аспект BPM. Более прагматичный подход – планировать стратегически, но действовать тактически. В некоторых сценариях и/или на некоторый переходный период допустимы и интеграция точка-точка (без ESB), и «интеграция» через копипаст.

Во-вторых, не рассчитывайте, что ESB способна заменить BPMS. В ней может наличествовать процессная функциональность в виде т.н. оркестровки сервисов, но это только автоматизация «безлюдных» процессов – последовательность обращения к функциям разных автоматических систем. Такие процессы встречаются в банках и телекоммуникационном бизнесе, но даже в этих отраслях они не составляют 100%. Для остальных отраслей это и вовсе экзотика, бизнес был и остается очень «человеческим» занятием.

Вывод: BPM – это проект (точнее, серия проектов), нацеленный непосредственно на бизнес-результаты. SOA – это инфраструктурный проект, который непосредственной пользы не приносит, но пренебрежение инфраструктурой в перспективе может привести к большим издержкам. В идеале нужно и то, и другое, но надо считать.

7. Шесть сигм, LEAN, TPS (Toyota Production System, Система Тойоты), ToC (Theory of Constraints, Теория ограничений)

Общая черта популярных управленческих концепций – все они так или иначе говорят о бизнес-процессах. Поэтому BPM прекрасно с ними со всеми сочетается.

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

Вывод: управленческие методологии отвечают на вопрос «чего мы хотим добиться», BPM – «как этого добиться». BPM – это «приводной ремень», средство эффективной реализации любой выбранной управленческой методологии.

Итоги

Организации – как живые организмы: у каждого своя история, своя культура, свои ценности, свои сильные и слабые стороны. Соответственно, траектория развития тоже у каждого своя.

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

Бизнес приложения и BPM

Альтернатива

Характеристика

Управление поручениями

Ограниченные возможности, полностью перекрывается BPM

Документообороти ECM

Документооборот полностью перекрывается BPM, ECM и BPM дополняют возможности друг друга

Управление проектами

Управление проектами и процессами дополняют друг друга

Отчетность и аналитика

Анализировать можно что угодно и сколько угодно, но управлять можно только процессами

ERP и корпоративные системы

ERP – это фундамент для BPM, элемент необходимый, но не заменяющий

SOA и ESB

Инфраструктура – полезная, но не всегда остро необходимая

Управленческие методологии

Целеполагание для BPM

 

Часть 3

– Белайчук Анатолий Анатольевич
Президент Ассоциации профессионалов управления бизнес-процессами

(ABPMP Russian Chapter), к.т.н., CBPP, BPM-блоггер.

6974
Поделиться
Коментарии: 41

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    21.04.2014 16:24

    Спасибо. Бодро. Доходчиво. Познавательно.

    Но мне показалось, что ряд противопоставлений несколько искусственны. :) И тут очень хорошо видна ситуация, когда "каждый кулик хвалит своё болото", т.е. с завидной периодичностью появляется подход, который превозносится апологетами как вершина развития, "all-in-one", "magic wand" и решение всех-всех проблем навсегда.

    На счет п.п. 6 и 7 надо подумать.

  • Анатолий Белайчук
    Рейтинг: 10
    Comindware
    Chief Evangelist
    21.04.2014 16:51

    Естественно, в заметке представлен взгляд "с кочки зрения BPM" - это и не скрывалось. Это не попытка дать сбалансированную картину всего ландшафта корпоративных платформ и систем.

    Но насчет all-in-one и прочих серебряных пуль, мне кажется, Вы к автору несправедливы ;) Те, кто атакуют клиента таким способом, совершенно не склонны рассматривать какие-либо альтернативы. (И даже больше того - обычно и сами не в курсе альтернатив.)

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

    • Марк Шварцблат Анатолий
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      23.04.2014 13:35

      Нет-нет. Хорошие продавцы "панацей" прекрасно знают все слабые места альтернатив. :)

      • Анатолий Белайчук Марк
        Рейтинг: 10
        Comindware
        Chief Evangelist
        24.04.2014 09:21

        Есть мнение, что лишнее знание продавцу только мешает, хорошему продавцу рефлексии не нужны ;)

        • Марк Шварцблат Анатолий
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          25.04.2014 15:58

          Лишние знания мешают "впаривателям". Хороший продавец должен уметь грамотно работать с возражениями.

          • Виктор Федько Марк
            Рейтинг: 299
            АО МПО им.И.Румянцева
            Зам. начальника управления информационных технологий
            25.04.2014 16:28

            В точку!

  • Анатолий Белайчук
    Рейтинг: 10
    Comindware
    Chief Evangelist
    21.04.2014 21:29

    Мне тут на опечатку указали:

    Проектные системы постепенно движутся в эту сторону, развивая функциональность ACM – Adaptive Case Management

    Имелись в виду процессные системы, конечно.

  • Михаил Петров
    Рейтинг: 264
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    24.04.2014 12:17

    Отличный текст.
    Анатолий, спасибо!

  • Александр Огнивцев
    Рейтинг: 60
    Атомстройэкспорт
    Зам директора по ИТ
    28.04.2014 14:25

    Весьма противоречивый текст, в особенности п. 3 и п.5.

    В п.3 читаем:
    процессный подход позволяет добиться большей предсказуемости и большей эффективности

    В п.5 читаем:
    бизнес-процессам присуща изменчивость...BPM обязан следовать методологии Agile в том или ином виде.


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

    • Анатолий Белайчук Александр
      Рейтинг: 10
      Comindware
      Chief Evangelist
      28.04.2014 15:11

      Просто процессный подход включает в себя две составляющих:
      1) управление бизнесом на основе процессов
      2) управление самими бизнес-процессами, т.е. их изменениями

      И если первое, действительно, никакой не аджайл, а следование утвержденному плану (хотя и тут есть нюансы, см. ACM), то второе без аджайла недостижимо.

      Так что никакого противоречия. Но спасибо за комментарий, заставивший внести полезное уточнение.

      • Александр Огнивцев Анатолий
        Рейтинг: 60
        Атомстройэкспорт
        Зам директора по ИТ
        28.04.2014 16:07

        Скорость изменения бизнес-процессов это не синоним аджайла. Аджайл это не синоним эффективности. На мой взгляд было бы правильно говорить о том, что бизнес-процессы должны изменяться быстро, этого достаточно и абсолютно правильно сказано о том, что бизнес-процессы в ERP быстро менятся не могут и скорее бизнес-процесс изменится под SAP, чем SAP под бизнес-процесс.

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

        • Анатолий Белайчук Александр
          Рейтинг: 10
          Comindware
          Chief Evangelist
          28.04.2014 16:32

          не совсем правильно синонимизирована скорость изменения бизнес-процессов и методика их изменения

          Скорость изменения - декларированная цель (рад, что по этому пункту возражений нет), Agile - рекомендованный метод достижения этой цели. Что не так?

          При правильной организации и хорошем уровне зрелости методом водопада можно всё сделать гораздо быстрее и эффективнее аджайла.


          Что ж - попробуйте. Мой личный опыт, равно как и доступные мне литературные источники, рекомендуют следовать Agile: короткие итерации - программа, состоящая из серии проектов, вместо одного мега-проекта, непрерывный контакт с бизнес-пользователями, работа с бэклогом, а не с фиксированным набором требований - все это в процессной работе оказывается востребовано в максимальной степени.

          • Александр Огнивцев Анатолий
            Рейтинг: 60
            Атомстройэкспорт
            Зам директора по ИТ
            28.04.2014 16:41

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

            Вся суть аджайла в коротком цикле, на котором можно просто зафиксировать требования. Больше - НИЧЕГО. Большими буквами. Если вы адекватный заказчик и умеете управлять своими требованиями, то вполне способны управлять промежутком на котором требования фиксированы. Вплоть до полугода/года по моему опыту. Тогда водопад будет эффективней. Если заказчик может фиксировать требования только на неделю/две - тогда поможет только аджайл.

            • Анатолий Белайчук Александр
              Рейтинг: 10
              Comindware
              Chief Evangelist
              28.04.2014 16:54

              Мода?! Простите, сколько ему лет-то уже? О какой моде тут можно говорить.

              Фиксирование требований - это аджайл? Извините, у нас с Вами какие-то очень разные представления о том, что стоит за этим термином. В моем представлении, аджайл - это намеренный отказ от фиксированных требований и, соответственно, определенные методы работы в таких условиях. "Срок важнее функциональности!" - вот что такое аджайл.

              Если заказчик может фиксировать требования только на неделю/две

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

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

              (Извините за категоричность суждений - разумеется, все имхо.)

              • Александр Огнивцев Анатолий
                Рейтинг: 60
                Атомстройэкспорт
                Зам директора по ИТ
                28.04.2014 17:46

                Возьмите модный сейчас scrum и разберите детально, что по сути означают спринты. Если убрать всю шелуху, то только то что на 2-4 недели фиксируются требования и генерируется рост функциональности. Но требования во-первых должны быть, а во-вторых они должны быть фиксированы. В середине и конце 90-х разработчики только так и работали, ваш покорный слуга в их числе. Только слова agile тогда не было еще.

                Что касается изменчивости, то в большинстве случаев ее природа не во внешней среде, а в низком качестве менеджмента. А крайняя изменчивость - это сказки и медные тазики для манагеров, не больше. Но тем не менее, возвращаясь к исходной теме, я согласен с тем, что нужно уметь быстро менять процессы, особенно с нашими особенностями руководящего состава. Но жесткое отождествление BPM и какой-либо методики по управлению изменениями (напр. agile) не считаю вполне правомерным.

            • Виктор Федько Александр
              Рейтинг: 299
              АО МПО им.И.Румянцева
              Зам. начальника управления информационных технологий
              28.04.2014 18:14

              Да нет, все-таки не мода. Этот метод существовал всегда. Очень давно, по крайней мере. Просто сейчас это назвали Agile.

              • Александр Огнивцев Виктор
                Рейтинг: 60
                Атомстройэкспорт
                Зам директора по ИТ
                28.04.2014 18:24

                Соглашусь. Особенно в начале времен, когда всё писали на коленке. Потом начали пробовать другие методики, но к коленке все же тянет, вот и назвали agile, а то не солидно как-то :) Но это конечно отдельная большая тема, причем с налетом религиозности. Если придут адепты, дискутировать будет бесполезно и невозможно.

                • Марк Шварцблат Александр
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  29.04.2014 11:14

                  Это нормально состояние - начали делать, а затем оформили теоретическую базу и вычленили главные аксиомы и постулаты. Практика вне рамок "чистой науки" - основа теории.

    • Виктор Федько Александр
      Рейтинг: 299
      АО МПО им.И.Румянцева
      Зам. начальника управления информационных технологий
      28.04.2014 15:31

      Отчего же прямая противоположность ?

      Вот основные идеи Agile :

      1. люди и взаимодействие важнее процессов и инструментов
      2. работающий продукт важнее исчерпывающей документации
      3. сотрудничество с заказчиком важнее согласования условий контракта
      4. готовность к изменениям важнее следования первоначальному плану.
      По п.1 важнее имхо не значит входит в противоречие.
      Добиться большей предсказуемости и эффективности можно разными методами и способами. Процессный подход это более других, возможно, способствует. Второй вопрос - а по какой методологии ?
      BPM обязан следовать методологии Agile в том или ином виде.
      Я бы тут только слово обязан обязан заменил. Очень уж категорично.
      BPM вполне может следовать методологии Agile в том или ином виде. - так мне кажется правильнее. И все встает на свои места.

      • Александр Огнивцев Виктор
        Рейтинг: 60
        Атомстройэкспорт
        Зам директора по ИТ
        28.04.2014 16:03

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

        • Виктор Федько Александр
          Рейтинг: 299
          АО МПО им.И.Румянцева
          Зам. начальника управления информационных технологий
          28.04.2014 16:16

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

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

          • Александр Огнивцев Виктор
            Рейтинг: 60
            Атомстройэкспорт
            Зам директора по ИТ
            28.04.2014 16:43

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

            • Марк Шварцблат Александр
              Рейтинг: 10
              КТ "Акведук"
              ИТ-директор
              28.04.2014 17:51

              А процесс можно рассматривать, как путеводный трос во время бурана.

              • Виктор Федько Марк
                Рейтинг: 299
                АО МПО им.И.Румянцева
                Зам. начальника управления информационных технологий
                28.04.2014 18:12

                Точно! А уж как за трос держаться - дело мастерства и искусства каждого.

            • Виктор Федько Александр
              Рейтинг: 299
              АО МПО им.И.Румянцева
              Зам. начальника управления информационных технологий
              28.04.2014 18:11

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

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

              • Марк Шварцблат Виктор
                Рейтинг: 10
                КТ "Акведук"
                ИТ-директор
                29.04.2014 11:15

                Странно вообще противопоставлять "свободу в коммуникациях" и процессные подходы.

                • Виктор Федько Марк
                  Рейтинг: 299
                  АО МПО им.И.Румянцева
                  Зам. начальника управления информационных технологий
                  29.04.2014 11:19

                  Вот вот, именно так. Разные несколько вещи.

        • Анатолий Белайчук Александр
          Рейтинг: 10
          Comindware
          Chief Evangelist
          28.04.2014 17:13

          Я не говорю о том, плох или хорош процессный подход и аджайл, я говорю о том, что эти подходы вместе не живут и не должны вместе применяться.

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

          • Виктор Федько Анатолий
            Рейтинг: 299
            АО МПО им.И.Румянцева
            Зам. начальника управления информационных технологий
            28.04.2014 18:32

            "напиши что делаешь - делай что написал"

            Я бы добавил - "сделал - опиши, что сделал"

        • Дмитрий Бацюро Александр
          Рейтинг: 10
          -
          независимый эксперт по управлению ИТ
          28.04.2014 22:01

          Александр, мне кажется, вы смешиваете операционный процесс, который является объектом изменения, и сам процесс изменения этого операционного процесса. В операционном процессе важно, чтобы участники следовали стандартизированным в нём правилам - иначе пропадает смысл такой стандартизации. А в процессе изменения часто важна скорость этого изменения, и для скорости как раз нужно применять гибкие методики. Когда бизнес-процесс стандартизирован на бумаге, то если тормозить, с обновлением регламента, то особо страшного для бизнеса не случится - просто на какое-то время жизнь пойдёт чередом, не описанным на бумаге. А вот если процесс заложен в BPMS, то из-за подобной нерасторопности можно поставить в интересную позицию половину компании.

          • Марк Шварцблат Дмитрий
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            29.04.2014 11:26

            Точно. На микроуровне процесс стабилен и в больших организациях это важно, а на макроуровне процесс изменения процессов запускаются постоянно.

          • Александр Огнивцев Дмитрий
            Рейтинг: 60
            Атомстройэкспорт
            Зам директора по ИТ
            29.04.2014 11:46

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

      • Анатолий Белайчук Виктор
        Рейтинг: 10
        Comindware
        Chief Evangelist
        28.04.2014 16:40

        2. работающий продукт важнее исчерпывающей документации

        Кстати да - об этом я не упомянул в комментарии выше, но быстрое прототипирование - обязательная фича BPMS-систем и методологии BPM.

        Я бы тут только слово обязан заменил. Очень уж категорично.

        Позволю себе настаивать: BPM без Agile - это не BPM. В лучшем случае BPMS, а это не то же самое. Проекты "BPMS без BPM", увы, нередки.

        • Александр Огнивцев Анатолий
          Рейтинг: 60
          Атомстройэкспорт
          Зам директора по ИТ
          28.04.2014 17:49

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

        • Виктор Федько Анатолий
          Рейтинг: 299
          АО МПО им.И.Румянцева
          Зам. начальника управления информационных технологий
          28.04.2014 18:07

          Уговорили))). Оставляйте обязан. Хотя , все-таки, слух режет.

          • Анатолий Белайчук Виктор
            Рейтинг: 10
            Comindware
            Chief Evangelist
            28.04.2014 18:24

            ОК, я тоже сделаю шаг назад и внесу уточнение: Agile - это то, к чему надо стремиться. Мой целевой показатель времени цикла - 3 недели, максимум - 4. Но первый шаг - продуктивный пилот - обычно делается водопадом, и срок там обычно 2-3 месяца.

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

            • Виктор Федько Анатолий
              Рейтинг: 299
              АО МПО им.И.Румянцева
              Зам. начальника управления информационных технологий
              28.04.2014 18:36

              Да, насчет срока 2-3 месяца соглашусь. Именно так сейчас у меня идет один интересный проект, связанный с отображением процесса учета реализации. Интеграция из 3-х систем, задействованы 5-6 подразделений. Выстраивается единый процесс под всех бизнес-пользователей. Интересная получается штука. Стартовали в феврале именно таким методом. Потом был небольшой останов, сейчас продолжение.

  • Александр Трапезин
    Рейтинг: 10
    АО "Темiрбанк"
    ИТ-Директор
    06.05.2014 11:43

    отличная статья, спасибо Анатолий!
    "BPM обязан следовать методологии Agileв том или ином виде. Процессная работа – это «roundtrip», а не «oneway»." - в точку.

    • Анатолий Белайчук Александр
      Рейтинг: 10
      Comindware
      Chief Evangelist
      06.05.2014 12:09

      Вам спасибо за поддержку. Сразу видна разница между теми, кто уже "плавал, знает" и теми, кто только ножкой воду пробует ;)

  • Алексей Колоколов
    Рейтинг: 10
    Институт бизнес-аналитики
    Директор
    06.05.2014 21:59

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

Предметная область
Отрасль
Управление