Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0 - [164]

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

Пока преждевременно говорить о наличии каких-то общепризнанных на уровне отраслей или компаний стандартов в области использовании BPMS. BPM и технологии BPMS все еще молоды, и задачей ABPMP и других подобных объединений является выработка таких стандартов. А пока надо двигаться вперед и разрабатывать для своей компании стандарты использования ПО, методы моделирования и т. п. Это важно с точки зрения взаимопонимания между группами внутри компании. Эти стандарты должны включать:

• способ сбора и состав информации, которая будет применяться для настройки системы;

• набор символов, используемых для моделирования (обычно это стандартный BPMN);

• репозиторий;

• ограничения доступа и применимые нормативно-правовые требования;

• архитектуру: модели из разных проектов должны соответствовать друг другу, вместе составляя единую модель предприятия;

• стандартные условия, уровни сервиса и т. п.;

• регулирование.

10.5.2. Модели регулирования

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

Пример: модели зрелости BPM. Gartner, Forrester, IBM и другие группы разработали модели, иллюстрирующие этапы, которые компании проходят на пути к зрелости BPM. Эти модели зачастую похожи друг на друга, но в части регулирования между ними могут быть существенные различия. Некоторые рассматривают только часть вопросов, относящихся к регулированию BPM и BPMS, концентрируясь на использовании. Другие изучают вопросы более широко и детально. В Интернете масса информации на эти темы: статьи, заметки в блогах, сайты консалтинговых компаний, LinkedIn, открытые форумы. Но тут необходима осторожность, так как полезная информация может соседствовать с нуждающейся в проверке. Очевидно, что при разработке собственной модели регулирования следует опираться на максимально достоверную информацию. Кроме того, модель должна быть адаптирована к нуждам вашей компании.

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

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

10.5.3. Целостность данных

Мусор на входе – молитва на выходе.

Род Мойер (Rod Moyer), вице-президент, BenefitAllies[219]

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

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