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

Многие вендоры, понимая бесперспективность подобных попыток, предлагают заказчикам различные варианты облегчения выбора, такие как бесплатные пробные версии, пилотные проекты, демонстрации и т.п. В заметке 5 Tips for Selecting the Best BPM Software Vendor for your next BPM Project ("5 Советов по выбору BPM вендора для вашего следующего BPM проекта") описывается взгляд со стороны вендора на проблему выбора BPM или Workflow системы.

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

1. НЕ создавайте RFP (Request for Proposal)  или RFI (Request for Information) для выбора BPMS вендора
2. Составьте список из трех вендоров и предложите им сделать PoC (Proof of Concept) на вашей площадке
3. Выберите для PoC процесс, замкнутый на внешнего заказчика
4. Выберите процесс, в котором есть одна или две точки интеграции и на котором можно легко измерить произведенные улучшения
5. Настаивайте, чтобы ваши специалисты работали бок о бок со специалистами вендора, чтобы они могли задавать вопросы о том, почему вендор делает то или это при создании процесса.

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

С этими рекомендациями, конечно, сложно спорить. Они основательны. Некоторые из них не всегда реалистичны. Если вендор не запрашивает за проект масштаба предприятия от 200 тысяч долларов в год, то не стоит ожидать, что конкурирующие вендоры, придут на вашу площадку делать PoC. В этом случае альтернативой может быть дистанционный PoC или ПО типа Workflow Software Quick Start (Cloud Process Maker).

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

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

Дело в том, что софтверные функции – это вовсе не софтверные функции. Это верно и для машин, и для смартфонов, и для BPMS. В жизни и в технологиях есть хорошо разработанные и элегантные функции, но также есть и плохо продуманное барахло. Ручка MontBlanc выполняет те же функции, что и стандартная одноразовая ручка Bic, купленная в обычном магазине – так? Но разве они одинаковы?

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

1. Дружественный BPMN 2.0 дизайнер – да/нет?
2. Интуитивно понятный инструмент для создания веб-форм – да/нет?

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

Не все BPM или Workflow системы одинаковы. Просто помните один маленький совет. Вспомните, как вы покупали свой смартфон, а потом подумайте, как ваша организация проводит анализ, выбирая  BPMS или Workflow… есть ли в этом смысл?

PoC или, как его чаще называют, пилотный проект – это наиболее распространенная практика, которую применяет большинство вендоров BPMS. Но эта практика имеет и свои подводные камни, о которых недавно писал в своем блоге один из авторитетных экспертов в области BPM Анатолий Белайчук. По его мнению, проблема кроется не столько в самой идее PoC, сколько в отношении заказчика к пилотному проекту. Анатолий называет по меньшей мере две причины, по которым практика выполнения пилотных проектов не оправдывает себя:

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

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

2) Мы стали делать пилотные проекты за деньги. По фиксированной цене – это принципиально, поскольку, напомню, целью является снизить риск для заказчика. Расчет был на то, что заказчик станет более ответственно подходить к заказу пилотного проекта, и тот факт, что на него потрачены какие-никакие, но деньги, заставит его заинтересованно отнестись и к ходу, и к результатам проекта.

К сожалению, это тоже не сработало. Проблема в том, что как мы не бьемся, объясняя заказчику, что цель пилота – не разработать для него некую автоматизированную систему, а предоставить информацию для принятия решения о том, подходят ему или нет предлагаемые управленческие подходы и программное обеспечение – до конца он этого не понимает. На словах соглашается, а на деле требует все новых и новых доработок а) совершенно непринципиальных и б) о которых не было речи в начале проекта. Слишком сильна оказывается инерция взгляда на BPM как на проект автоматизации.

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

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

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

=WJ

Комментарии