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

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

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

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

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

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

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

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

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

Бизнес-стандарты обычно бывают менее конкретны – скорее, это принципы, которыми следует руководствоваться. Технические стандарты по сравнению с ними более конкретны и детальны, и они должны учитывать выбранное средство моделирования или BPMS и рекомендации поставщика ПО. Насколько это возможно, они должны содержать модификации, поддерживающие все используемые в компании средства BPM/BPMS. Разумеется, технические стандарты должны отражать текущие стандарты и политики в области IТ. При появлении дополнительных стандартов, относящихся к определенным областям IТ, все стандарты должны быть просмотрены и при необходимости дополнены ссылками и/или изменены, чтобы устранить расхождения, избыточность и конфликты.

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

Центр компетенции должен отслеживать изменения в технических и бизнес-стандартах и руководящих принципах на предмет их воздействия на используемое в компании ПО BPM/BPMS и при необходимости корректировать стандарты BPM. Примеры:

• сбор информации: руководство по выявлению бизнес-процессов;

• имитационное моделирование: контроль информации, ее качества и отражения в моделях;

• нотация моделирования бизнес-процессов (BPMN): определяет символы, используемые для графического проектирования процессов, и обеспечивает возможность генерации приложений BPMS;

• язык исполнения бизнес-процессов (BPEL): кодирование приложений, генерируемых BPMS;

• расширяемый язык разметки (XML): обмен данными и документами;

• расширяемый язык определения процесса (XPDL): общий формат файлов для обмена моделями между программными продуктами;

• база данных и моделирование данных: схемы использования и хранения данных;

• Java: стандарты применения языка;

• веб-сервисы: структура, использование и контроль;

• SOA: стратегия, использование, разработка и т. д.;

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

Примечание: этот только примерный список стандартов, которые следует анализировать. Он не претендует на полноту.

Начинать создание собственных стандартов использования ПО BPM/BPMS следует с обращения к поставщику ПО, который может дать набор рекомендаций по применению своего программного продукта. Затем обратитесь к опыту членов ABPMP и другим надежным источникам информации. Поиск по Интернету тоже может быть полезным, но качество найденной здесь информации под вопросом. Если ПО BPM/BPMS уже используется в другом департаменте компании, то в работе над стандартами может быть полезен их опыт.

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

На эволюции технологий BPM отражается появление новых информационных технологий. В этом разделе мы рассмотрим четыре новые технологии/подхода, способных повысить гибкость ПО BPM/BPMS.

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