Текст книги "Проектируем корпоративную архитектуру"
Автор книги: Вячеслав Кондратьев
сообщить о нарушении
Текущая страница: 7 (всего у книги 18 страниц) [доступный отрывок для чтения: 7 страниц]
Рис. 6.9.1. План создания ОРД
Часто специалисты предлагают стартовый алгоритм построения архитектуры ОРД с использованием структурного моделирования (см. рис. 6.9.1).
Сначала определяется минимально необходимый набор классификаторов значимых организационных характеристик компании. В качестве распространенных характеристик компании могут выступать:
• направление деятельности, продукты и услуги;
• задачи;
• процессы;
• функции;
• структурные единицы;
• и т. д.
Для проект-ориентированных компаний в состав первоочередных организационных характеристик входит реестр поддерживаемых компанией проектов.
Далее выбирается состав матриц соответствия характеристик и осуществляется их заполнение. Матрицы соответствия рассматриваются как удобный аппарат описания связей характеристик.
В принципе все характеристики могут иметь связи друг с другом, и можно строить бесконечное число матриц соответствия между ними. На практике число используемых матриц соответствия стараются по возможности уменьшить, описывая с их помощью только самые важные отношения, например: функции – звенья, задачи – звенья, документы – функции.
Еще одно важное правило применения матриц соответствия связано с группировкой характеристик. Для упрощения и наглядности моделирования рекомендуется сначала выбрать коренную характеристику бизнес-модели, например организационные звенья или процессы, а остальные проецировать на нее с помощью матриц соответствия.
Особенностью проект-ориентированных компаний является и то, что подразделения могут создаваться на период выполнения проектов, поэтому реестр в таких случаях постоянно меняется.
Наличие заполненных классификаторов характеристик компании и матриц их соответствия позволяет проводить структурный анализ, улучшать работу компании, формировать и использовать в качестве регламентирующей документации необходимые отчеты, получаемые из структурной модели.
Распространенный вариант улучшения ОРД компании может выглядеть сегодня примерно так (см. рис. 6.9.2).
• Изучение ОРД «как есть».
• Оценка соответствия ОРД стратегии компании и передовым практикам.
• Разработка проекта улучшений структуры и состава ОРД.
• Создание библиотеки электронных регламентов.
• Разработка и внедрение системы постоянных улучшений ОРД.
• Задание порядка внесения изменений в электронные регламенты (в тех случаях, когда к ситуации нужно постоянно адаптироваться, каждая конкретная организационная структура имеет ограниченный срок жизни и должна рассматриваться лишь как основа для дальнейших изменений).
Рис. 6.9.2. Алгоритм улучшения ОРД
В ходе проведения разработок:
– создается специальная проектная группа;
– проводится целевое обучение участников проекта и пользователей его результатов;
– привлекаются при необходимости независимые эксперты и внешние консультанты;
– решается вопрос об использовании специальных программных средств для моделирования и проектирования ОРД;
– определяется порядок постоянного мониторинга и совершенствования ОРД;
– обеспечивается интеграция разрабатываемых решений с другими приложениями.
Практика выполнения проектов структурного моделирования компании показывает два варианта организации проектов. С некоторой условностью их можно описать так.
В одном варианте – А) – проект от начала и до конца выполняется специально подготовленными бизнес-инженерами, имеющими необходимый практический опыт. Моделирование сразу ведется с применением специализированных программных средств с предварительной проработкой политики моделирования.
В другом варианте – Б) – предварительно осуществляется разработка «ядра модели». В осуществлении ключевую роль играют действующие менеджеры и руководители. На этой стадии применение специализированных программных средств играет вспомогательную роль. Бизнес-инженеры системно организуют исполнение проекта и обрабатывают получаемую информацию. На второй стадии разрабатываются подробные тематические детализации и приложения. Роль специализированных программных средств и участие бизнес-инженеров в разработке моделей увеличивается (рис. 6.9.3).
Рис. 6.9.3. Варианты организации рабочих групп проекта структурирования
6.10. Преимущества электронных моделей и регламентов
Рис. 6.10.1. Типология регламентов
Исторически сложились две группы форматов описания регламентов: в виде различного рода организационно-распорядительной документации (ОРД) и в виде разнообразных карт работ, или, как их еще модно сегодня называть, описаний бизнес-процессов (см. рис. 6.10.1).
При внимательном рассмотрении становится ясно, что разница между этими форматами достаточно условна. Хотя многочисленные нюансы, несомненно, есть.
Бизнес-инжиниринг использует для описания регламентов специальные компьютерные программы.
Достаточно быстро развитие этого направления привело к созданию интегрированного софта, поддерживающего как традиционные ОРД, так и классические нотации горизонтального описания бизнес-процессов, что еще сильнее размыло границу между этими форматами описания.
Сегодня вместо понятия «модель структуры» или «модель бизнес-процесса» специалисты стали применять термин «бизнес-модель» компании, рассматривая структурные и процессные модели как ее частные случаи.
Все данные о тенденциях развития говорят о том, что в самое ближайшее время электронные регламенты и электронные карты бизнес-процессов могут значительно потеснить традиционные бумажные описания регламентов и стать важнейшим инструментом организации деятельности современных компаний.
Преимущества электронных регламентов очевидны:
• современный инструмент разработки и форма хранения – компьютер;
• возможность эффективной организации через внутренние сети, Интранет, Интернет, коммуникационные сервисы пользователей;
• возможность созданий традиционных копий документов на твердых носителях;
• расширение возможностей визуализаций;
• кардинальное расширение возможностей анализа, улучшения и перепроектирования регламентов работ;
• возможность проведения сквозных выборочных изменений и больших изменений в больших массивах электронной документации.
7. Практикум. Структурирование в группе компаний
Контент
• Система управления организационными изменениями – диагностики, проектирование и реализация организационных изменений, контроллинг.
• Структура положений о компании – общие положения, цели и задачи, продукты и процессы, организация управления, права и ответственность.
• Проекция организационных характеристик на структуру – использование специальных матриц соответствия.
• Связь положений о компании с моделью процессов верхнего уровня – гармонизация структурных, процессных и функциональных характеристик.
Рис. 7.0.1. Система управления организационными изменениями
7.1. Механизм проведения организационных изменений в группе компаний «Волга – Днепр»
Рис. 7.1.1. Цикл управления организационными изменениями
Проведение организационных изменений с целью построения организационной структуры компании «как надо», обеспечивающей оптимальное сочетание совокупности таких факторов, как стратегия, окружающая среда, размер и жизненный цикл организации, технологии и корпоративная культура и так далее, включает в себя следующие этапы:
1. Сбор и анализ информации для адаптации и улучшения организационной структуры компании.
2. Проектирование изменений организационной структуры компании.
3. Утверждение и внедрение изменений организационной структуры и соответствующих положений об организационной структуре.
4. Наблюдение, контроль, анализ результатов внедрения.
5. Корректировка ранее принятых решений, мотивация персонала.
При необходимости, параллельно с изменением организационной структуры, проводится адаптация и изменения других компонент корпоративной архитектуры, в первую очередь модели исполнения процессов. Необходимость связанного проведения изменений в разных частях корпоративной архитектуры делает актуальным поддержание описания архитектуры не только как системы документов, но и как электронной модели, представляющей связанное описание различных характеристик и допускающей проведение их сквозных связанных изменений.
К основным объектам внимания при изменении корпоративной архитектуры можно отнести следующие компоненты организации:
– услуги;
– процессы;
– проекты;
– функции;
– звенья;
– системы управления;
– а также связи и взаимодействия между ними.
7.2. Адаптация положений об организации деятельности
Рис. 7.2.1. Связь стандартов и положений о компании
Изменение стратегии, появление нового направления в деятельности, реорганизация с целью повышения эффективности ведут к изменению организационной структуры. Чтобы результаты проектирования структуры компании отвечали всем предъявленным требованиям, необходимо тщательно проводить сбор и анализ информации с помощью анкетирования и интервью, анализировать предшествующий опыт. В результате сбора и анализа информации формируется материал для описания основных характеристик компании «как надо».
Структура Положения о компании
1.1. Общие положения
1.2. Миссия, цели и задачи
1.3. Продукты и процессы
1.4. Организация управления компанией
1.5. Функциональная модель
1.6. Права и ответственность
1.7. Обозначения и сокращения
1.8. Приложения
1.8.1. Задачи на год
1.8.2. Закрепление ответственности за производство основных продуктов в группе компаний
1.8.3. Роль и место компании в группе компаний на основе детализированной карты бизнес-процессов верхнего уровня.
1.8.4. Распределение функциональных обязанностей подразделений компании в процессах производства продуктов и услуг
1.8.5. Организационная структура компании
1.8.6. Виды и характеристики взаимоотношений в группе компаний
1.8.7. Принципы взаимодействия в группе компаний
Таким образом, для формирования проекта положения о компании выполняется следующий набор действий:
• описание и диагностика ситуации «как есть»;
• изучение лучших практик;
• определение миссии и стратегии группы компаний;
• определение основных стратегических задач конкретной компании и задач на год;
• определение продуктов конкретной компании и их потребителей;
• описание и распределение управленческих, основных и обеспечивающих процессов между подразделениями конкретной компании;
• описание организации взаимодействия между сотрудниками и руководителями конкретной компании;
• оформление положения.
Рис. 7.2.2. Схема гармонизации функциональных и процессных описаний
После утверждения положения о компании начинается этап внедрения организационных изменений. Содержание мероприятий внедрения зависит от объема и содержания тех изменений, которым подверглась организационная модель компании. При этом существенное изменение положения о компании влечет за собой изменение других связанных с этим положением документов, в частности положений о подразделениях и, возможно, должностных инструкций.
Следующим шагом является постоянное отслеживание соблюдения организационных изменений в повседневной деятельности. Для этого проводятся исследования, анализ и подготовка решений по корректировке существующих отклонений в организационно-функциональной модели компании.
На заключительном этапе осуществляется корректировка выявленных отклонений и мотивация персонала.
В рамках единой корпоративной архитектуры положения о компаниях группы и входящих в них подразделений интегрируются с описанием бизнес-процессов и системой менеджмента качества. С этой целью составляется классификатор функций «от положений» и детализированное описание процессов «от модели процессов верхнего уровня», после чего проводится гармонизация составленных описаний (см. рис. 7.2.2). Классификаторы процессов и функций также гармонизируются с системой менеджмента качества, где, по сути дела, поддерживаются аналогичные описания.
В итоге регламентация деятельности обеспечивается через следующий набор интегрированных между собой приложений:
– модуль процессов верхнего уровня;
– клссификация процессов и функций;
– регламенты процессов;
– регламенты проектов;
– положения о подразделениях;
– система менеджмента качества.
7.3. Учет в положении о компании основных задач
Рис. 7.3.1. Включение стратегических задач в положение о компании
Адаптация и развитие деятельности группы компаний начинается с выработки стратегии компании, которая закрепляется в древе стратегических целей.
Рис. 7.3.2. Последовательность каскадирования стратегии: компания – подразделения – должность
Используя основной принцип каскадирования целей сверху вниз, стратегические цели конкретизируются в цели и основные задачи группы компаний (отражается во втором разделе положения о компании), которые, в свою очередь, определяют цели и задачи подразделений отдельно взятой компании и закрепляются в положении о подразделении.
При формировании должностной инструкции цели и задачи подразделения учитываются при определении задач сотруднику данного подразделения на год. Таким образом учитывается вклад каждого сотрудника организации в достижение поставленных стратегических целей группы компании.
8. Моделирование бизнес-процессов
Контент
• Модель процесса – прикладное представление на специализированном языке способа исполнения деятельности.
• Модель процесса верхнего уровня – прикладное представление верхнего уровня способа исполнения деятельности.
• Направления использования моделей процессов верхнего уровня – в качестве компонент корпоративной архитектуры, при распределении зон ответственности, в качестве интегрирующей модели детальных описаний процессов и положений.
Рис. 8.0.1. Модели процессов помогают
8.1. Использование моделей процессов
Рис. 8.1.1. Вопросы, которые интересуют пользователей при моделировании процессов
Хотя в конечном счете перечень вопросов, решаемых при моделировании процессов, примерно одинаков: какие работы необходимо выполнять, кто какие работы выполняет и т. д. (см. рис. 8.1.1) – представление модели процесса и выбор языка представления существенно зависят от решаемых задач и пользователей.
Модель процесса – системное представление для решения определенных задач с использованием специализированного языка способа исполнения деятельности
Так, на верхнем уровне управления используются агрегированные модели процессов компании как компонент построения корпоративной архитектуры, а на нижнем уровне могут использоваться весьма детальные модели для автоматизации процессов (см. рис. 8.1.2).
Рис. 8.1.2. Детализация описания процессов и сферы их применения
8.2. Модель процессов верхнего уровня
Рис. 8.2.1. Направления использования модели процессов верхнего уровня
Обычно процессное описание компании начинается с построения модели процессов верхнего уровня, или, как их еще называют, ландшафта процессов [10, 11]. Такая модель позволяет (см. рис. 8.2.1):
• обобщенно представить организацию деятельности компании;
• установить соответствия процессов и компонент корпоративной архитектуры, а именно:
– увязать стратегию компании и основные исполняемые ею процессы;
– увязать показатели деятельности компании и основные исполняемые ею процессы;
– распределить зоны ответственности за исполнение процессов;
– через единое описание верхнего уровня увязать более детальные модели деятельности компании – функциональные, алгоритмические, проектные.
Соответствия процессов и компонент корпоративной архитектуры могут устанавливаться в экспресс-варианте качественным анализом, а при детальном моделировании – через разработку матриц соответствия (см. рис. 8.2.2).
В практике бизнеса и в ходе работы консалтинговых компаний сформировался целый ряд типовых моделей верхнего уровня, в том числе и по отраслям, которые пользователи могут использовать в качестве опорных решений или приспособить к деятельности своих компаний.
Пример модели верхнего уровня, включающей основные и поддерживающие процессы, процессы управления, приводился в разделе 2.6. Ряд других примеров будет приведен ниже.
Рис. 8.2.2. Соответствия процессов и компонент корпоративной архитектуры
С точки зрения конечных пользователей привлекательной стороной типовых моделей является уже то, что они есть и могут использоваться как опорные решения. Слабой стороной типовых моделей является то, что авторы моделей при их разработке действовали независимо при отсутствии каких-либо принимаемых всеми стандартов описания. Поэтому модели сделаны «в разных системах координат», плохо коррелируют друг с другом, по-разному определяют объекты детализации, по-разному определяют границы похожих процессов и все вопросы использования сильных компонент библиотеки этих моделей оставляются в итоге за конечным пользователем.
8.3. Пример. Типовая процессная модель основных и поддерживающих процессов
Рис. 8.3.1. Типовая процессная модель деятельности
Среди универсальных описаний специалисты называют типовую модель основных и поддерживающих процессов [2, 4]. Модель включает семь основных процессов и шесть поддерживающих. Процессы управления относятся к поддерживающим и специально не выделяются. Тем самым вертикальные и горизонтальные процессы исполнения в модели совмещаются.
Основные процессы модели отражают деятельность в следующих направлениях:
1) разработка стратегии, в том числе
• проведение стратегических диагностик;
• определение целевых рынков и продуктов;
• выявление конкурентных преимуществ компании;
• установка стратегических целевых показателей;
• разработка способов реализации стратегии;
2) проведение (исходя из стратегии) бизнес-планирования на краткосрочную перспективу;
3) вывод продуктов на рынок, в том числе
• уточнение требуемых потребительских свойств продуктов и услуг;
• разработка представления о позиционировании продуктов и услуг на рынке;
• разработка программы продвижения продуктов и услуг;
4) исполнение продаж;
5) исполнение поставок, в том числе построение цепочек поставок и логистики;
6) сервисное обслуживание, в том числе
• послепродажное обслуживание;
• обработка возвратов;
7) бизнес-мониторинг, в том числе
• управленческий учет;
• анализ финансово-хозяйственной деятельности;
• оценка степени достижения стратегических целевых показателей и качества реализации стратегии;
• корректировка по результатам анализа стратегии;
• корректировка вытекающих из стратегии бизнес-планов.
Аналогичным образом могут быть детализированы поддерживающие процессы модели.
8.4. Пример. Модель логистической цепочки
Рис. 8.4.1. Основные процессы SCOR-модели
К примерам универсальных моделей специалисты относят SCOR-модель (от англ. supply chain operations reference model – модель логистической цепочки). Модель фокусируется на логистике предоставления продуктов и услуг.
На первом уровне модель содержит пять процессов, каждый из которых детализируется на втором уровне:
1) планирование, в том числе:
подготовка планирования;
планирование логистической цепочки;
планирование снабжения;
планирование производства;
планирование возвратов;
2) снабжение, в том числе:
..
..
..
3) производство, в том числе:
подготовка производства;
производство на склад;
разработка на заказ;
производство на заказ;
4) поставка готовой продукции, в том числе:
..
..
..
5) обработка возвратов, в том числе:
..
..
8.5. Пример. Типовая модель процессов верхнего уровня, добавляющих стоимостьПрактикум. Доработка компонент SCOR-модели
В качестве полезного упражнения можно рекомендовать представить свою версию детализации незаполненных позиций приведенного варианта SCOR-модели
Рис. 8.5.1. Типовая модель процессов верхнего уровня, добавляющих стоимость
В специальной литературе неоднократно освещалась в качестве универсальной модель процессов, добавляющих стоимость (см. рис. 8.5.1). В одном из вариантов модель включает пять основных процессов и десять поддерживающих. Процессы управления относятся к поддерживающим и специально не выделяются. Тем самым вертикальные и горизонтальные процессы исполнения в модели совмещаются.
Верхний уровень модели соответствует диаграмме VAD (от англ. value-added-chain diagram – диаграмма цепочки добавленной стоимости). При таком подходе к основным относятся все процессы, непосредственно влияющие на добавленную стоимость предоставляемых бизнесом продуктов и услуг. К вспомогательным относятся процессы, формирующие инфраструктуру компании и обслуживающие их процессы. Строго говоря, разнесение не является строгим и зависит от принятых договоренностей по моделированию в рамках общего контекста решаемых при моделировании задач.
Примерная архитектура модели процессов верхнего уровня приведена на рис. 8.5.2. Модель формируется двумя блоками: блок основных процессов, формируемых на основе типовых этапов создания отраслевых объектов, и блок типовых поддерживающих процессов, который является вполне универсальным
