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

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

О самолетах для войны и для мирного времени

Мой дед Иван Феофанович Орленко был военным летчиком-торпедоносцем. Воевал на Балтике в 1944-1945, закончил войну командиром полка. (Пользуясь случаем, рекомендую тем, кто интересуется военной историей, сайт моего брата Олега Белайчука.)

На фотографии дед в центре с орденом Ушакова и двумя Красного знамени. А на борту машины можно разглядеть маркировку - это американский Бостон A-20G, поставлявшийся в СССР по ленд-лизу.

Среди множества историй, которые дед рассказывал (а он и книгу написал), запомнилась история про технику для военного и для мирного времени. Перескажу своими словами, как запомнил:

Когда мы получили Бостоны, машины поразили своим комфортом - в них было тепло! Можно было обойтись без унтов и меховых полушубков, к которым мы все привыкли. Но с началом боев обнаружилось, что Бостоны слишком хорошо горят. В чем дело? Стали разбираться и выяснили, что отопление работает от бензиновой печки, а бензопровод тянется через всю машину. Пуля, осколок - и машина сбита. В общем, демонтировали отопление и снова достали унты с полушубками.

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

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

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

В чем тут подвох: простые и сложные процессные задачи отличаются друг от друга не количественно, а качественно! Не тем, что со сложной задачей придется повозиться несколько дольше, чем с простой, а тем, что в ней понадобится реализовывать совершенно другие процессные паттерны и, соответственно, окажутся жизненно важными возможности продукта, потребность в которых на этапе PoC даже не возникало. Поэтому это очень опрометчивый подход: заказчик рискует выбрать BPMS-систему, которая великолепно продемонстрирует себя в пилотном проекте (”техника для мирного времени”), но провалится в промышленном использовании (”техника для войны”).

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

Поэтому я лично, оценивая BPMS, в первую очередь обращаю внимание на межпроцессное взаимодействие. И что же я вижу? В большинстве продуктов поддержка межпроцессного взаимодействия отсутствует! (В частности, я не нашел его ни в одном из популярных Open Source продуктов.) У меня интерес к такому продукту сразу падает до нуля, потому что я знаю - как бы привлекательно он не выглядел, его можно будет использовать только для вспомогательных процессов, а для основных - тех, которые делают деньги! - он будет малопригоден.

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

10.01.13 | Статьи |    

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

  1. Илья 10.01.13 19:00

    Про самолеты - хорошо!
    Понравилось.

    И про системы соглашусь. Но как же быть заказчику? Сразу давать на POC боевые задачи, реализация которых превращается в мини-проект? При чем не только для внедренца, но и самого заказчика.

  2. Anatoly Belychook 10.01.13 19:08

    Илья

    Оперативненько!

    Отвечаю: 1) тренинг http://mainthing.ru/ru/item/445/, плавно перерастающий не в PoC, а в 2) продуктивный пилот. Да, сразу боевые задачи и с нормальной оплатой работы. Но не целиком - заказчик выбирает наиболее критичный фрагмент сквозного бизнес-процесс. Делаем его за 1-2-3 месяца (в зависимости от масштаба) на пробных лицензиях (это важный момент). Потом начинаем раздвигать рамки процесса влево и вправо, пока не охватим процесс целиком.

  3. Владимир 10.01.13 19:29

    Анатолий, PoC выбирается в реальных проектах, я надеюсь, как инструмент минимизации рисков:
    1. Риск того что ПО не подойдет
    2. Риск того что подрядчик окажется некомпетентным
    3. Риск того что нам вообще не нужна BPMS
    Соглашусь, что PoC даст менее качественный результат (в меньшей степени минимизирует риск ) особенно 1-й, чем предложенный вами подход, но он и стоит существенно меньше. К чему я это: необходимо, наверное, смотреть в конкретных проектах соотношение цена/качество обоих подходов и выбирать более подходящий…

  4. Anatoly Belychook 10.01.13 19:50

    Владимир

    Само собой что для оптимизация рисков… Но статья о том, что PoC не дает того результата, который обещает.

    Ну смотрите… это как если вам нужна машина для экстремального бездорожья, а дилер предлагает тест-драйв по ближайшим улицам. И что это вам даст? Цвет подсветки панели приборов узнаете? Качество пластика и кожи в отделке оцените? Ну да, много чего. ТОЛЬКО ГЛАВНОГО НЕ УЗНАЕТЕ. Кроссовер в сто раз лучше внедорожника. Если выбирать, не съезжая с асфальта.

    Так и тут.

    Ни по одному из перечисленных Вами пунктов PoC не даст вам информации для принятия качественного решения:
    1. ПО прекрасно подойдет для заявления на отпуск, но процесс продажи “от и до” не потянет, потому что там нужна совсем другая функциональность, которая в заявлении на отпуск не нужна и поэтому в PoC не проверялась.
    2. Подрядчик компетентен в оркестровке, а что такое межпроцессное взаимодействие - не имеет понятия. Судя по тому, что я вижу на тренингах по BPMN, это так практически у 100% аналитиков.
    3. Тут вообще нет никакого риска - заранее можно сказать что BPMS вам НЕ НУЖНА. Люди, поддавшись увлечению, автоматизируют заявление на отпуск. На отлично автоматизируют, просто идеально. Конфетку делают! Но в конце работы кто-то из руководства, с холодной головой, задает простой вопрос: “НУ И ЧТО?” Что изменилось в строке прибылей-убытков? Ничего не изменилось, ясен пень! Деньги-то в основных процессах, а не во вспомогательных.

    Что касается затрат. Что тут сказать: да, компетенция стоит дорого. Есть только одна вещь, которая обходится дороже: некомпетеность.

  5. Владимир 10.01.13 20:41

    Анатолий, согласен полностью и не пытался даже спорить :)
    Но если рассматривать задачку с точки зрения минимизации рисков, то как максимально дешево убедиться в том, что заявляемая подрядчиком компетенция действительно у него есть? Я про 2-й риск. С 1-м и 3-м можно разобраться и другими способами. Заявляют то ведь все кто есть на рынке. Тупо идти к самому известному и скорее всего, самому дорогому очень не хочется, да и не факт, что он даст в команду настоящих профи, а прикрывшись своей известностью не отправит к тебе “студентов” опыта набираться. Особенно если твой проект - не на миллиард миллиардов, а средний и ниже среднего по масштабу и бюджету.

  6. Anatoly Belychook 10.01.13 21:02

    Владимир

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

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

    Достаточно ли вы богаты, чтобы соглашаться на бесплатный PoC? :)

    Настоятельно рекомендую и Вам, и вообще всем начинать с тренинга http://bpmntraining.ru/ Теория (первая часть) сама по себе ценности не представляет, но в после практики (вторая часть) у слушателей появляется четкое понимание что и как надо делать, чтобы решить их задачу, и даже появляется эксиз схемы процесса, который дальше уже можно развивать даже самостоятельно. Ценность этого упражнения абсолютна, так как вы не привязываетесь ни к конкретному продукту, ни к конкретному поставщику, и вообще не берете на себя никаких обязательств. Но компетенцию поставщика (одного из возможных) оцените. А с BPMN скорее всего придется иметь дело, какой бы продукт в итоге вы не выбрали - это уже мейнстрим.

  7. Анатолий 10.01.13 21:03

    Анатолий, например Bonita (OS версия)
    http://www.bonitasoft.com/products/features
    поддерживает BPMN 2.0 артефакты:
    …. Design your business workflows with Business Process Modeling Notation (BPMN) version 2.0. Use basic or advanced notation.
    В палитре присутствуют и Signals и Messages.

  8. Anatoly Belychook 10.01.13 21:09

    Уважаемый тезка

    Вы сами проверяли? Рекламные заявления делать все горазды. Когда я последний раз смотрел Бониту несколько месяцев назад, нифига не было.

  9. Анатолий 11.01.13 03:21

    Да, еще год назад в версии 5.0 использовал Message Events и есть реально работающие процессы во взаимодействии которых они использованы. Я даже сделал небольшой маршрутизатор сообщений (используемый как подпроцесс), для того чтобы можно было динамически назначать процесс-получатель.

  10. Anatoly Belychook 14.01.13 16:55

    Анатолий

    Спасибо за поправку. Очевидно, я что-то попутал. Сам недавно смотрел activiti, а про bonita похоже мне кто-то рассказал.

    Действительно, сообщения есть, сигналы тоже. Это радует.

  11. Andrei Walter 02.07.13 21:13

    Если не касаться “спора” что и где , жалко что не видел это фото раньше . Могла стать предметом разговора на тренинге в кофе-паузе :)

  12. Anatoly Belychook 02.07.13 21:29

    Андрей, приветствую! Вам ли, с родины скайпа, жалеть? Можем поговорить и на расстоянии, меня легко найдете при желании.

Комментирование закрыто

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