Кондратьев Вячеслав Леонидович - Проектируем корпоративную архитектуру стр 17.

Немаловажное значение при выборе структуры «как надо» играет изучение лучших практик (рис. 6.6.1). Использование специализированного опыта «лучших компаний» может восполнить пробелы в теории.

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

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

6.7. Организационно-распорядительная документация

Рис. 6.7.1. Типология ОРД

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

В ОРД указываются значимые структурные характеристики компании и их связи между собой.

Практика менеджмента сформировала весьма значительный набор типовых ОРД. Среди них можно назвать ряд широко известных (см. рис. 6.7.1).

1. Положение о компании – показывает наиболее общее описание компании (продукты и услуги, задачи, функции, организационную схему, распределение общих характеристик по основным подразделениям).

2. Положение о подразделении – задает существенные характеристики работы подразделения (задачи, функции, права, обязанности, документы по подразделению в целом и образующим его отделам и секторам)....

3. Положение о функциональной области или бизнес-процессе – задает существенные характеристики (задачи, функции, права, обязанности, документы) о работе компании в функциональной области (поставки, производство, сбыт, финансы, персонал и т. д.) или в бизнес-процессе.

4. Должностная инструкция – задает существенные характеристики работы сотрудника.

6.8. Электронные регламенты

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

Отчеты могут быть:

• текстовыми;

• табличными;

• графическими;

• комбинированными.

Рис. 6.8.1. Пиктограмма «Электронные регламенты»

Изменение характеристик электронных моделей сразу же отображается в создаваемых на их основе отчетах и тем самым позволяет существенно ускорить документированную поддержку производимых изменений.

Электронные модели могут быть доставлены потребителю через внутренние сети, Интранет и Интернет.

В целом представление регламентирующей документации с использованием электронных моделей и электронных коммуникативных сервисов получило название электронных регламентов.

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

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

Как следствие становятся взаимосогласованными и регламенты компании. Пример архитектуры простой электронной модели описан в табл. 6.8.1 (см. также рис. 2.7.2).

Таблица 6.8.1. Пример интегрированной системы разнородных электронных регламентов

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

6.9. План создания и улучшения ОРД

Рис. 6.9.1. План создания ОРД

Часто специалисты предлагают стартовый алгоритм построения архитектуры ОРД с использованием структурного моделирования (см. рис. 6.9.1).

Сначала определяется минимально необходимый набор классификаторов значимых организационных характеристик компании. В качестве распространенных характеристик компании могут выступать:

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

• задачи;

• процессы;

• функции;

• структурные единицы;

• и т. д.

Для проект-ориентированных компаний в состав первоочередных организационных характеристик входит реестр поддерживаемых компанией проектов.

Далее выбирается состав матриц соответствия характеристик и осуществляется их заполнение. Матрицы соответствия рассматриваются как удобный аппарат описания связей характеристик.

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

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

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

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

Распространенный вариант улучшения ОРД компании может выглядеть сегодня примерно так (см. рис. 6.9.2).

• Изучение ОРД «как есть».

• Оценка соответствия ОРД стратегии компании и передовым практикам.

• Разработка проекта улучшений структуры и состава ОРД.

• Создание библиотеки электронных регламентов.

• Разработка и внедрение системы постоянных улучшений ОРД.

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

Рис. 6.9.2. Алгоритм улучшения ОРД

В ходе проведения разработок:

– создается специальная проектная группа;

– проводится целевое обучение участников проекта и пользователей его результатов;

– привлекаются при необходимости независимые эксперты и внешние консультанты;

– решается вопрос об использовании специальных программных средств для моделирования и проектирования ОРД;

– определяется порядок постоянного мониторинга и совершенствования ОРД;

– обеспечивается интеграция разрабатываемых решений с другими приложениями.

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

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

В другом варианте – Б) – предварительно осуществляется разработка «ядра модели». В осуществлении ключевую роль играют действующие менеджеры и руководители. На этой стадии применение специализированных программных средств играет вспомогательную роль. Бизнес-инженеры системно организуют исполнение проекта и обрабатывают получаемую информацию. На второй стадии разрабатываются подробные тематические детализации и приложения. Роль специализированных программных средств и участие бизнес-инженеров в разработке моделей увеличивается (рис. 6.9.3).