Методология + инструменты + команда = система управления

Иллюстрация: Shutterstock

Дело в том, что, с одной стороны, специализированное программное обеспечение для бизнес-моделирования — инструмент крайне полезный для широкого спектра организаций, как для частного бизнеса (от малого до крупного), так и для государственных учреждений, в силу чего оно весьма популярно в последнее время. С другой стороны, покупатели подобных систем часто недооценивают сложность проектов, для реализации которых данный продукт приобретается. В результате нередко происходит следующее: приобрели систему бизнес-моделирования, «поигрались» и забросили, а задач, для которых покупался продукт, так и не выполнили.

Суть проблемы

При создании эффективной системы управления организации сталкиваются с целым рядом проблем; назову основные из них.

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

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

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

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

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

Решение

На мой взгляд, одним из оптимальных решений является использование итерационного или цикличного подхода к построению системы управления, а также ориентация на стандарты PMBOK (руководство к своду знаниями по управлению проектами) и BABOK (руководство к своду знаний по бизнес-анализу).

В этом контексте следует обратить внимание на существенные изменения (по отношению к предыдущим версиям) в четвёртой версии стандарта по управлению проектами PMBOK, где акцент сделан на то, что реализация подобных проектов должна носить итерационный характер. Другими словами, стандарт PMBOK признаёт тот факт, что гибкие методологии реализации проектов имеют преимущества по сравнению с жёсткими, построенными по принципу водопада, где, выполнив все работы одной фазы проекта, приступают к следующей. Однако PMBOK определяет только общие вопросы реализации проектов и не даёт детальных методических рекомендаций по технологии их выполнения. Я предлагаю воспользоваться некоторыми идеями и практиками стандартов и методологий из индустрии программного обеспечения, таких как Rational Unified Process (RUP) или Microsoft Solutions Framework (MSF), адаптировав их под задачи создания системы управления организации.

RUP подразумевает итерационную и инкрементную модель разработки, в то время как MSF — спиральную с поддержкой итеративности. Несмотря на некоторые различия, в основе этих подходов лежит общая концепция, так как они в разное время были предложены одним и тем же человеком — немецким специалистом в области программного инжиниринга Барри Боемом (к слову, водопадная модель разработки также принадлежит его авторству). То есть разницы между итерационным и спиральным подходом практически никакой нет, вопрос лишь в том, кто как лучше воспринимает модель. В соответствии с методологией RUP процесс разработки состоит из четырёх фаз, каждая из которых может быть разбита ещё на отдельные итерации. В ходе выполнения каждой фазы/итерации осуществляется постоянная последовательность определённых процессов. Если аналогичный подход рассмотреть относительно к системе управления организации, то можно выделить те же самые фазы проекта, но контекст их будет другим.

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

Процессы, точнее, группы процессов можно организовать следующим образом:

• управление проектом — процессы управления проектом в соответствии с PMBOK;
• бизнес-анализ — выполнение задач бизнес-анализа в соответствии с BABOK;
• бизнес-моделирование — определение бизнес-архитектуры компании, детальное моделирование и описание её элементов (целей, процессов, показателей, должностей, подразделений, информационных систем и т. д.) с указанием связей между ними;
• разработка документации — на базе полученной бизнес-модели формируется документация системы управления в виде положений, регламентов и инструкций, заданий на разработку информационных систем;
• разработка информационных систем на базе разработанной ранее бизнес-модели;
• развитие ИТ-инфраструктуры — приведение ИТ-инфраструктуры к состоянию, позволяющему эффективно развернуть и использовать необходимые информационные системы.

В результате получается концептуальная модель построения системы управления, аналогичная RUP. Естественно, отображение трудозатрат выглядит несколько утрированно, но тем не менее оно даёт представление о том, как распределять ресурсы в ходе выполнения проекта (см. рис. 1).

После ознакомления с подобной организацией процессов могут возникнуть вопросы:

1. если речь шла об управлении требованиями, то почему нет такого процесса?
2. где процессы управления качеством, изменениями?

Дело в том, что именно эти вопросы охватывают процессы и процедуры, описанные в стандартах PMBOK или BABOK, то есть:

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

Таким образом, использование PMBOK и BABOK в качестве базы избавляет от необходимости разрабатывать процессы самостоятельно.

Инструменты и команда

Выбор и применение специального ПО для проектирования системы управления является не менее важным аспектом проекта. В качестве примера рассмотрим систему бизнес-моделирования Business Studio. Этот продукт предоставляет набор функциональных возможностей, которые позволяют рассматривать его как центральный инструмент для проектирования верхнего уровня системы управления организации (рис. 2), а также широко использовать его в ряде других задач проекта:

• во время сбора и анализа требований — для фиксирования информации, собранной в результате интервью с заинтересованными лицами, относительно их точки зрения на цели, процессы, организационную структуру и информационные системы путём разработки «эскизной» модели организации, согласования структуры документов;

• во время построения — для ознакомления заинтересованных лиц с результатами проектирования системы управления, например, посредством публикации результатов проектирования системы в виде HTML-навигатора и фиксирования в Business Studio результатов обработки «обратной связи» от заинтересованных лиц;

• во время внедрения — для доведения документации системы управления (в виде инструкций, положений, регламентов и т. д.) до сведения персонала посредством HTML-навигатора, а также внесения изменений и развития бизнес-модели, документации системы управления компании и требований к информационным системам.

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

Заключение

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

Поэтому предложенный подход к организации проекта имеет целый ряд преимуществ, среди которых можно выделить следующие:

1. использование итерационного подхода. В рамках итераций последовательно уточняются и дополняются все элементы системы управления, и таким образом выстраивается «живая система» управления организации. Если же система управления существует только на бумаге или в компьютере, то между ее различными элементами образуются разрывы и нестыковки, которые затем приводят к таким же разрывам и нестыковкам в реальной работе компании. В этом случае неизбежно разочарование в системном управлении и инструментах бизнес-моделирования;

2. разработка системы управления имеет последовательный, предсказуемый, прозрачный и управляемый характер, поэтому более понятна заказчикам проекта (например, высшему руководству организации). Это упрощает процесс выделения необходимых ресурсов на проект и увеличивает его поддержку;

3. повышаются гарантии качества результатов проекта;

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

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

Об авторе:

Андрей Недолужко, независимый эксперт, основатель www.experts2biz.com.