Риски BPM-проектов, как их минимизировать?

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

Каковы основные риски BPM-проектов?

• В первую очередь, это риск выхода за рамки бюджета. Неудачное завершение одного или нескольких этапов приводит к дополнительным расходам, необходимым для исправления ошибок.
• Второй риск связан с потерей потенциальных преимуществ. Если проект уже подходит к стадии завершения, но при этом основные вопросы по-прежнему упираются в бюджет, то с большой вероятностью можно сказать, что преимущества и ценность BPM упущены.
• Третий тип рисков связан с возможными конфликтами, в результате которых управление эффективностью не используется полноценно и не дает нужных преимуществ. Часто такие столкновения возникают с владельцами проекта и заинтересованными сторонами. Иногда этим людям кажется, что их потребности совершенно не затрагиваются. Кроме того, нередки споры и столкновения между финансовым и IT-отделом. Так как попытки удовлетворить всех могут привести к не разумному нарастанию масштабов проекта, что угрожает и бюджету и конечному результату, то в такой ситуации полезен независимый арбитр.
• Еще один риск – риск незаинтересованности пользователей. Необходимо учитывать интересы тех, кто будет работать с программным обеспечением и процессами. Важно создать такие условия, чтобы люди на местах не игнорировали проект, привлечь их еще на этапе формирования требований, иначе все вложения окажутся напрасными.
• Велик также риск потери исходных стратегических целей. В результате готовый проект решает совсем не те задачи, для которых был предназначен, а значит - не приносит должной пользы. Предыдущий опыт и знание тех этапов, на которых компания может забыть об основной цели, существенно сокращает этот риск. В этой ситуации, очевидно, стоит воспользоваться опытом тех, кто уже прошел этот путь.

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

Почему это происходит? Каковы причины повышения рисков и как их можно избежать?

Сосредоточенность на единственном поставщике

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

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

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

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

Почему же сегодня некоторые компании рассматривают только одного поставщика, выбирая BPM-проект? Тому есть две основные причины. Первая известна давно. IT-отдел стремится к расширению уже существующих систем. Следовательно, логично было бы обратиться к своему ERP или BI-поставщику и приобрести у него BPM-модуль. На первый взгляд, это кажется разумным. Такой подход согласуется с принципами корпоративной стандартизации с целью стабилизации или сокращения количества различных систем или поставщиков, с которыми работает компания. Кроме того, в этом случае можно использовать уже накопленный опыт, знания, взаимоотношения с поставщиком и даже структуры данных. Однако BPM – это не только еще одна новая система. Это важнейшее звено в цепи работы компании, поэтому от удачного выбора системы управления эффективностью успех и процветание компании зависят в очень большой мере.

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

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

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

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

Как уже говорилось выше, невозможно понять, является ли продукт данного поставщика наиболее подходящим, не рассмотрев альтернативы. Даже бесплатный тестовый период не решит этой проблемы. Можно понять, что продукт «умеет» делать, но невозможно разобраться, что мы при этом теряем. Возможно, отчеты выполняются за 20 секунд, и это вполне приемлемо. Но есть ли уверенность в том, что у другого производителя какой-то, наиболее актуальный для вашей организации отчет, не будет выполняться, к примеру, за 5 секунд? Если пересчитать всё, исходя из сотен пользователей, выполняющих отчеты, то 15 секунд могут оказаться очень существенной разницей.

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

Самостоятельное выполнение проектов

Временные и денежные затраты, связанные с проектами управления эффективностью, очень существенно отличаются в зависимости от отрасли, размера компании, числа пользователей, количества исходных систем и проч. Однако, о среднем проекте можно сказать, что его внедрение занимает от 3 до 12 месяцев и стоимость составляет от 100 тыс. до 1 млн. долларов.

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

Так как корпоративный проект требует тесного сотрудничества между отделами (в особенности между IT и финансами), а также взаимодействия со множеством систем, то потенциальных ошибок может быть очень много. Если еще участь тот факт, что более сотни поставщиков готовы бороться за клиента, то отличить агрессивный маркетинг от реальности бывает очень сложно. В такой среде велика вероятность больших просчетов. И, таким образом, остро встает вопрос, насколько велики будут издержки от этих ошибок. В самом худшем случае система управления эффективностью потерпит полный крах. Согласно данным опроса BPM Pulse Survey, более 13% компаний после неудачной первой попытки вынуждены полностью перерабатывать свои системы управления эффективностью.

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

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

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

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

Стоит ли выбирать поставщика, который предлагает только инструменты?

Рассмотрим самый спорный подход к внедрению BPM, который может существенно повысить риски таких проектов. Это выбор поставщика, предоставляющего только инструменты.

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

Сразу надо оговориться, что сами по себе BI-инструменты играют важную роль в решении многих бизнес-проблем. И если у компании в наличии большие объемы данных, и необходимо внедрить нерегламентируемую отчетность, то что же еще выбрать, как не инструмент отчетности и запросов? Если необходимо перемещать и отображать данные из одной системы в другую, то как тут обойтись без ETL-инструмента? Если необходимо исследовать в разных измерениях многомерную выборку данных, то лучше всего это сделать с помощью OLAP-куба.

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

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

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

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

Собственная разработка или покупка?

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

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

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

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

Следует, однако, заметить, что некоторые сферы управления эффективностью, например операционная аналитика, находятся в стадии зарождения. Готовые решения здесь зачастую либо отсутствуют, либо не достаточно проработаны. В этом случае единственным выходом является применение business intelligence.

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

Публикации

1. Как повысить риски управления эффективностью. Часть 1 (How to Increase Your Performance Management Risk, Part 1), Крейг Шиф (Craig Schiff), Июль 2007 г, http://www.b-eye-network.com/view/5606;
2. Как повысить риски управления эффективностью. Часть 2 (How to Increase Your Performance Management Risk, Part 2), Крейг Шиф (Craig Schiff), Август 2007 г, http://www.b-eye-network.com/view/5764;
3. Как повысить риски управления эффективностью. Часть 3 (How to Increase Your Performance Management Risk, Part 3), Крейг Шиф (Craig Schiff), Сентябрь 2007 г, http://www.b-eye-network.com/view/6028.

Автор: По материалам зарубежных сайтов