Читать онлайн «Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0». Страница 106

10.5.1. Стандарты и методологии BPM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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