 |
На сегодняшний день большинство существующих программных продуктов на рынке средств описания бизнеса (Business Process Management Suite — BPMS) не требуют выполнения процедур, связанных с проведением подготовки методологии и настроек среды моделирования. Это обусловлено тем, что данные средства или вообще не базируются на какой-либо методологии описания деятельности (характерный пример — Microsoft Visio), или представленная в этих средствах методология охватывает ограниченное количество аспектов моделирования архитектуры компании. Наиболее часто именно последнее является тем основанием, когда компании пытаются выбрать инструментарий для моделирования деятельности, который, с одной стороны, базируется на развитой методологии и возможности поддержания моделирования интегрируемых подсистем архитектуры компании (например, организационной структуры, процессов, информационных систем, данных), и одновременно способен эффективно обеспечить задачи моделирования деятельности, включая централизованное хранение данных.
Стремясь применять на практике средства, которые могут обеспечить реализацию приведенных задач, часто делается выбор в пользу систем моделирования архитектуры компании — EAMS (одной из таких систем является ARIS). Они обеспечивают комплексный методологический подход описания компонентов архитектуры и эффективную инструментальную поддержку, включающую как компоненты для моделирования и анализа, так и элементы интеграции с другими системами на этапах внедрения и контроллинга бизнес-процессов (например ERP, BPM, Workflow). Применение большинства систем класса EAMS требует проведения подготовительного этапа (внедрения), в рамках которого проводится четкая формализация целей моделирования, организационная подготовка, настройка и формализация методологии документирования.
Однако именно этап предварительной подготовки очень часто недооценивается и не реализуется отечественными компаниями, начинающими применение средств моделирования ARIS, что приводит к неудаче проектов, связанных с документированием деятельности. Подходя к данному этапу формально (или пропуская его вообще), часто допускается ряд характерных ошибок, который будет рассмотрен в статье. Исправление таких ошибок на поздних этапах может быть затруднено или не реализуемо вообще.
Следует отметить, что ошибки из данного перечня характерны именно для применения средств класса EAMS и не включают классические ошибки, присущие постановке процессного управления, которые, безусловно, также следует учитывать.
ОТСУТСТВИЕ КОНЦЕПЦИИ ВНЕДРЕНИЯ И ЧЕТКИХ ЦЕЛЕЙ ДОКУМЕНТИРОВАНИЯ
Приступая к документированию деятельности с применением ARIS, многие компании делают акцент на реализации некоторого перечня задач, которые перед ними стоят, — это может быть подготовка компании к процессно-ориентированному внедрению информационных систем, постановка системы менеджмента качества, анализ и совершенствование деятельности, управление операционными рисками и т. д. ARIS подходит для реализации большинства из них, однако подходы, требования к моделированию и сроки реализации задач при этом могут существенно отличаться. Одной из основных целей разработки и формализации концепции применения ARIS как раз и является гармонизация подходов реализации различных задач применения системы, обеспечивая при этом согласованность используемых методов моделирования и организационной модели документирования.
Безусловно, применение ARIS в приведенных «локальных» задачах может значительно повысить эффективность их реализации, однако потенциал системы, охватывающий возможность реализации нескольких задач одновременно, при этом будет не задействован. Более того, при попытке расширения сфер применения системы и перехода к реализации других целей с применением методологии и инструментария ARIS может возникнуть целый ряд проблем, порой непреодолимых.
В качестве примера можно привести ситуацию, когда некоторая условная компания, используя ARIS в проекте документирования процессов для внедрения информационной системы, при дальнейшем расширении задач применения процессных технологий (анализ и совершенствование деятельности) столкнулась с тем, что выбранная изначально модель организации документирования не подходит для реализации новых задач, а выбранные методы моделирования и детализации плохо совместимы. Если на начальном этапе применения ARIS перспективные задачи применения системы были бы учтены, подобных проблем не возникло бы.
Важный момент, который также часто упускается отечественными компаниями, связан с отсутствием связи между стратегией компании и концепцией применения процессных технологий. Возникающий при этом разрыв между стратегическими целями и целями применения процессного подхода также часто приводит к неудаче проектов внедрения ARIS.
Разработка и формализация процессной стратегии на уровне высшего руководства компании позволяет значительно снизить риски проектов внедрения ARIS. Соответствующий документ, как правило, должен содержать перечень стратегических целей применения процессных технологий в организации с учетом их интеграции в общую стратегию компании, организационную и ролевую модель с четким распределением функций в рамках проекта внедрения, сроки реализации этапов и техническую концепцию организации процессов. Главная задача, которая достигается при этом, — создание прозрачной архитектуры проекта внедрения в разрезе целей внедрения, этапов и сроков их реализации, организационной и информационной моделей проекта.
ОТСУТСТВИЕ ФОРМАЛИЗОВАННОЙ МЕТОДИКИ ДОКУМЕНТИРОВАНИЯ
Каждая организация является уникальной бизнес-системой, обладающей рядом нестандартных характеристик архитектуры, в том числе отраслевых. С учетом таких особенностей и целей документирования деятельности каждая отдельная компания может предъявлять специфический набор требований к методологии и средствам моделирования архитектуры. Как правило, в качестве такого средства моделирования выбирается ARIS, поскольку, во-первых, во многих случаях может учесть отраслевую специфику модели компании (как за счет существующих в ARIS референтных моделей, так и за счет решений ARIS Scouts) и, во-вторых, предоставляет широкий набор интегрированных методик для описания различных компонентов архитектуры компании. Так, помимо основной методологии моделирования процессов ARIS, на сегодняшний день система поддерживает такие методологии и нотации, как Balanced Scorecard, Business Process Execution Language (BPEL), IT City Planning, BPML, UML. При этом для документирования и анализа самых разнообразных сфер деятельности компании представлено более 125 типов моделей и более 600 типов графических объектов.
Успешность реализации проекта внедрения ARIS и эффективность проведения внутренних работ по документированию во многом зависит от корректности и полноты настройки и формализации предлагаемой методологии — то есть подбора тех методов моделирования и анализа, моделей, глубины детализации предметных областей, нотаций и объектов, которые обеспечат реализацию задач компании. Отсутствие формализованного подхода к документированию деятельности с применением инструментария ARIS зачастую приводит как к малой эффективности применения самой системы, так и значительным рискам при достижении целей компании.
Так, произвольный (не формализованный) выбор методов моделирования и нотаций фактически превращает систему из средства моделирования в инструмент для рисования, при этом теряется не только наглядность модели архитектуры компании (а это одно из основных назначений ARIS), но и становится недоступным большинство уникальных свойств системы, таких, например, как автоматизированный анализ и генерация регламентной документации. При этом достаточно характерной ошибкой является неправильный выбор глубины детализации каждой из моделируемых предметных областей (в первую очередь, это касается выбора глубины детализации бизнес-процессов) — например, поверхностный подход к документированию не позволяет реализовать большинство возможностей методологии и системы. С другой стороны слишком детализированный подход приводит к значительным временным затратам на моделирование и также может не дать ожидаемого результата.
Формализация методики документирования дает возможность четко определить единые требования к описанию деятельности организации, а также правила документирования и анализа компонентов архитектуры. В контексте применения ARIS такая методика, как правило, оформляется отдельным документом (Соглашением по моделированию) — сводом правил, содержащим описание совокупности нотаций, типов моделей, объектов, их атрибутов и связей между ними, которые используются для комплексного описания предметной области компании. Такой документ помогает сформировать единый язык общения внутри компании, а также позволяет настроить систему ARIS для более эффективной работы пользователей и корректной работы программ генерации отчетов и модулей анализа. Следует отметить, что система ARIS поддерживает развитый механизм настройки методологии при помощи методологических фильтров, при этом соглашение по моделированию является, в некотором роде, техническим заданием для настройки методологии в системе.
ОТСУТСТВИЕ ЧЕТКОЙ ОРГАНИЗАЦИОННОЙ И РОЛЕВОЙ МОДЕЛИ ОРГАНИЗАЦИИ ПРОЕКТА
Подходя к внедрению ARIS, часто может упускаться важный момент определения ролей участников проекта и распределения функций между ними, что приводит к значительному увеличению времени внедрения системы и дополнительным затратам. В отличие от классических организационных моделей при построении системы процессного управления, при использовании ARIS появляется ряд специфических особенностей, присущих только этой системе. Так, например, при использовании ARIS в компании обычно выделяются роли администратора среды моделирования (именно среды, а не аппаратной или серверной части) и скриптолога-аналитика. Кроме этого, появляется ролевое распределение ответственности за моделирование различных предметных областей компании (например, одна из ролевых групп в рамках централизованной базы данных ARIS осуществляет моделирование организационной структуры, другая группа — бизнес-процессов и т. д.).
На сегодняшний день существует две основные организационные модели документирования — централизованная и децентрализованная.
Централизованная модель предполагает создание в компании отдельного подразделения, занимающегося документированием и актуализацией базы знаний по архитектуре компании, как правило, такое подразделение не обладает достаточной компетенцией во всех направлениях деятельности компании, поэтому вынуждено привлекать экспертов из других структурных единиц (именно этот момент формализации взаимодействия подразделений очень часто упускается).
Децентрализованная модель, в свою очередь, предполагает проведение работ по документированию на уровне бизнес-подразделений, при этом создается центр компетенции, который контролирует соблюдение методологии документирования и поддерживает централизованное хранилище знаний ARIS. Выбор той или иной организационной модели (и, соответственно, распределение ролей проекта) крайне важен на начальном этапе, это дает возможность компании оценивать время реализации и затраты на проект, создает прозрачную структуру направлений развития и предоставляет эффективный инструментарий управления проектом.
Следует отметить, что компании, учитывающие приведенные ошибки на начальном этапе внедрения ARIS, смогут значительно эффективнее применять процессные технологии, тогда как отсутствие концептуального подхода к проекту внедрения приводит к серьезным рискам и преждевременному завершению проекта. Безусловно, приведенный перечень проблем внедрения далеко не полный, однако учет именно отмеченных проблем может значительно сократить риски при внедрении ARIS.
Об авторе:
Александр Чередниченко, управляющий партнер, Business Process Solutions (г. Киев)
|
|
