На сегодняшний день аббревиатура BPM (Business Process Management) очень популярна. Большие и малые компании из самых разных отраслей в какой-то момент приходят к выводу, что некоторые процессы надо пересмотреть: выделить в соответствии с заданными критериями, описать с определенной точки зрения, оптимизировать, а потом провести работы по их автоматизации. Однако на пути внедрения BPM-систем встречается много подводных камней.

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

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

Проблемы внедрения «сверху»

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

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

  • презентации для широкого круга потенциальных пользователей, плавно перетекающие в дискуссии;
  • встречи с пользователями для обсуждения перспектив и предложений (опять же нужно привлекать широкий круг сотрудников — чтобы были понятны цели каждой единицы: группы, отдела, управления);
  • показ работающих workflow-систем с определением точек интеграции с другими системами компании — CRM (Customer Relations Management), специфическими для отрасли учетными решениями, системой документооборота и др.

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

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

Конечно, есть еще и административные меры (жесткий контроль, штрафы и т. д.), но это самый неэффективный путь, который сильно снижает лояльность сотрудников к компании в целом и к текущему внедрению в частности.

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

Работа в проектной команде

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

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

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

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

Ещё одним немаловажным аспектом, определяющим ход внедрения, является так называемая трассируемость требований. При одновременно идущих проектах по внедрению разных систем необходимо отслеживать, чтобы требования и замечания пользователей поступали к нужному интегратору и не терялись. Каждое требование должно отражаться либо в списке изменений артефактов (может быть оформлено как Request for Changes — список запросов на изменения), либо в виде мотивированного отказа. Это позволяет избегать ситуаций, когда «никто не виноват», т. е. пользователь высказывал свои требования, но один интегратор не услышал, второй не записал (ведь к нему это «не имеет отношения») и т. д. Между тем поезд уже ушел: техническое задание написано, часы исполнителя отработаны, и время осталось только на согласование требований, которое уже изначально обречено на провал, так как не соответствует нуждам пользователей. В качестве сотрудника, отвечающего за полноценность требований, можно использовать аналитика, в целом представляющего себе стратегию модернизации информационных систем.

От малого к большому

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

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

Принципиальна наглядность карт процессов. Можно использовать различные нотации и методологии — например, EPC-диаграммы, IDEF0-модели. Стоит иметь в виду, что регламенты, написанные формальным строгим языком, сложно согласовывать, и они должны быть результирующим документом — не нужно загружать пользователей чтением текстов по нескольку раз, так как любой глаз в конце концов «замыливается».

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

Организация взаимодействия, открытость

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

  • подготовка, правка и согласование различной документации;
  • экспертное участие в автоматизации — ответы на вопросы, сбор и поддержка информации, оценка результатов;
  • обсуждение спорных моментов;
  • обсуждение замечаний к системе по результатам эксп­луа­тации.

Традиционным подходом к обмену такого рода информацией является электронная почта. Однако при участии в команде многих людей и постоянном изменении состава привлечённых к проекту лиц эта система обмена оказывается малоэффективной и плохо управляемой. Здесь целесообразно использовать так называемые проектные порталы, содержащие в себе всю необходимую информацию. Системы для управления запросами на изменения и ошибками — вроде Trac или Bugzilla — сильно облегчают и ускоряют фиксацию и исправление ошибок. Они позволяют хранить вопросы с различным статусом и отслеживать текущих владельцев, что даёт возможность постоянно контролировать, «на чьей стороне мяч» по той или иной теме. Для более оперативного управления эти системы обеспечивают почтовые рассылки уведомлений об изменениях вопросов. Хорошей практикой является вариант, когда представители функциональных служб во время тестирования имеют доступ к специально организованному для тестирования внешнему трекеру.

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

  • графические описания — карты процессов в каком-либо формате;
  • регламенты процессов;
  • разделы технических заданий;
  • протоколы встреч;
  • планы тестирования;
  • замечания к системе.

Кроме того, технология wiki позволяет довольно просто хранить любую разнородную информацию. Для синхронизации деятельности нескольких разработчиков, обеспечения надёжности и возможности наблюдать необходимо использовать системы хранения версий. Наиболее распространены SVN, VSS и CVS. Всем известно правило фиксировать версии как минимум раз в день или по достижении любого рабочего варианта системы, что позволяет иметь пусть незаконченные, но устойчивые версии приложения. При таком подходе и обеспечении доступа пользователей к тест-серверу тестовая команда может работать параллельно с разработчиками, что позволяет существенно сократить сроки разработки и повысить качество системы в силу более своевременного исправления критических ошибок и замечаний.

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

Заключение

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