Как создать систему развития организации

Механика бизнеса: с чего начать, чтобы построить эффективную бизнес-систему

Андрей Недолужко

Управляющий партнёр компании Experts2biz

Эксперт по проектированию архитектуры бизнес и ИТ-систем

Консультант по бизнес-процессам девелопмента и управления недвижимостью

Взлетит или нет? Типичные ошибки управления и ключ к их решению

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

Приведу некоторые типичные примеры, с которыми я сталкивался в своей практике:

1. Крупная компания, представители которой заявляют, что у них внедрены процессы управления проектами: «Проектный офис, PMBOK, консультанты написали процедуры, Микрософт Проджект. », но есть проблемы: проекты не идут так как хотелось бы, руководитель проектного офиса меняется каждые 3-5 месяцев. В результате диагностики и анализа текущей бизнес-ситуации возникает краткий вывод: «Процессы стратегического управления не поставлены, нет связи между стратегией и проектами компании, поэтому проектный офис, как мёртвому припарка». Всё просто — у владельца, менеджмента и ключевых сотрудников нет единой картины того, как выполнение запланированных проектов помогает компании двигаться в направлении реализации её долгосрочной стратегии и помогает ли вообще?
2. В компании развёрнута CRM-система: персонал ведёт клиентские базы, регистрирует заказы, централизованно обрабатывает документы, только вот продажи хоть и первоначально подросли (не сразу, а через некоторое время после внедрения и стабилизации системы), но дальше рост затормозился и не соответствует ожиданиям. У владельца бизнеса закономерный вопрос: зачем инвестировали в систему? В результате исследования и анализа текущей бизнес-ситуации оказывается, что у компании не поставлены процессы маркетинга и процессы развития услуг, а при внедрении CRM-системы компания фокусировалась исключительно на процессе продаж и поставке услуг заказчикам. То есть активности, имеющие отношение к процессам маркетинга и развития услуг, есть, но это скорее эпизодические импровизации, а системные операции на основе разработанных и внедрённых методик управления отсутствуют. В результате компания упускает массу возможностей и недополучает прибыль;
3. В логистической компании внедряют комплексную информационную систему, где ключевая функция — это диспетчеризация подвижного состава. Проект развивается вяло и уже превысил запланированные срок и бюджет. При этом руководитель группы разработчиков формулирует: «Мы сначала напишем софт, а потом будем на него натягивать процессы компании». Т.е. люди хотят автоматизировать бизнес, внедрив информационную систему, при этом процесс управления жизненным циклом данной системы отсутствует, равно как и увязка этого процесса с процессами разработки модели деятельности компании. Соответственно, не только превышение сроков и бюджета имеют место, но и возникают вопросы: поможет ли полученная система улучшить финансовые результаты компании, и какая цель преследуются вообще?
4. Другая типичная категория ошибок: существующие бизнес-процессы «как есть» описаны, текущая картина владельцам/топ-менеджерам компания ясна, на стратегической сессии обсуждаются вопросы на тему «что делать». Все хотят улучшать там, где, как им кажется, больше всего болит, у одних — это продажи, у других — производство, у третьих — «. нужно вспомогательные отделы сократить, давайте избавимся от балласта». На деле все эти планируемые инициативы обособлены и дают лишь кратковременный и незначительный эффект и ни на шаг не приближают компанию к построению той самой необходимой бизнес-системы. Поэтому хочется им сказать: «Эээ. ребята! Вы не туда смотрите.».

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

Подход к построению и развитию эффективных бизнес-систем

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

Рисунок 1 — Концептуальное изображение процессов управления компанией

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

Структура процессов верхнего уровня, где отражаются группы всех бизнес-процессов компании, представлена в виде диаграммы IDEF0 (так как именно данная нотация наиболее подходит для формализации высокоуровневых бизнес-процессов) и выглядит следующим образом — Рисунок 2.

Рисунок 2 — Диаграмма IDEF0 процессов верхнего уровня типичной транспортно-логистической компании

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

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

В свою очередь, группа процессов «Управление компанией» представленная в виде диаграммы IDEF0, будет иметь следующий вид (Рисунок 3):

Рисунок 3 — Группа процессов «Управление компанией»

Каждая группа бизнес-процессов, изображённая на Рисунке 3 имеет подробные и детальные диаграммы подпроцессов, на базе которых формируются соответствующие методики управления, однако их демонстрация выходит за формат данной статьи. Я лишь приведу краткую характеристику процессов, входящих в группу «Управление компанией», для того чтобы объяснить механизм их функционирования (таблица 1):

Группа процессов	Краткое описание содержания процессов	Входы	Выходы
Анализ внутренней и внешней среды компании (бизнес-анализ)	Анализ и определение текущего состояния компании, относительно внешней среды и стратегических целей; Подготовка наглядных отчётов и выработка рекомендаций для высшего руководства компании.	Информация о рынке и внешней среде, отчёты управления проектами, отчёты операционной деятельности, внутренняя финансовая отчётность и другие внутренние отчёты компании	Отчёты и рекомендации, служат также входами для других процессов управления компанией
Стратегическое управление	Определение и развитие видения, миссии, стратегии и других элементов стратегического управления компании; Стратегическое планирование; Мониторинг и контроль выполнения стратегических планов; Измерение и анализ выполнения стратегических планов.	Отчёты и рекомендации процессов анализа, данные внутренней финансовой отчётности	Отчёты стратегического управления, стратегические решения, стратегический план компании.
Развитие бизнес-системы (системы управления компании)	Анализ текущего состояния, определение необходимости развития и технико-экономическое обоснование выполнения работ по развитию системы управления; Выполнение проектов по развитию бизнес-системы: проектирование, разработка, ввод в действие; Поддержка элементов бизнес-системы в актуальном состоянии (получение обратной связи от персонала компании, внесение изменений в документацию бизнес-системы, сбор и документирование запросов на усовершенствование бизнес-системы).	Отчёты и рекомендации бизнес-анализа, стратегический план компании, отчёты, прогнозы, запросы, предложения и рекомендации, поступающие из других процессов компании	Документация системы управления. Как правило, включает регламенты процессов и процедур, положения о подразделениях, должностные инструкции, структуру и описание функционирования информационных систем и т.д.
Управление проектами компании	Планирование портфелей проектов на основе утвержденных стратегических планов; Авторизация и запуск проектов и программ компании; Мониторинг и контроль выполнения; Измерение и анализ выполнения проектов компании.	Отчёты и рекомендации бизнес-анализа, стратегический план компании, отчёты, прогнозы, запросы, предложения и рекомендации, поступающие из других процессов компании, внутренняя финансовая отчётность	Отчёты портфеля (-ей) проектов, планы портфеля(ей) проектов, управленческие решения, которые принимаются для текущих проектов компании
Операционное управление	Планирование операционной деятельности в разрезе показателей и требуемых ресурсов (материальных, человеческих и финансовых); Мониторинг и контроль операционной деятельности; Измерение и анализ результатов операционной деятельности.	Отчёты и рекомендации бизнес-анализа, стратегический план компании, проектные планы компании, отчёты, прогнозы, запросы, предложения и рекомендации, поступающие из других процессов компании, внутренняя финансовая отчётность	Управленческие решения, применяемые к другим бизнес-процессам компании, сводный план деятельности компании, на основе которого выполняются операции в остальных бизнес-процессах компании, отчёты операционной деятельности

Таблица 1 — Группы процессов блока «Управление компанией»

Резюме

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

1. Собственник и менеджмент компании будут лучше понимать, где находится в данный момент времени компания относительно долгосрочных целей и в правильном ли направлении она движется;
2. Будет больше уверенности в принимаемых решениях, так как благодаря подобному механизму организации процессов управления, руководство компании будет иметь полное обоснование предпринимаемых шагов, действий и выделяемых инвестиций;
3. Проекты, инициированные в компании, направленные как на внешнее, так и на внутреннее развитие, будут увязаны и сбалансированы между собой и с планами операционной деятельности.

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

Источник

Суть организационного развития

Дмитрий Пинаев

Генеральный директор ГК «Современные технологии управления»

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

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

Компания является сложной системой, включающей в себя три основные системы:

1. Операционную систему, целью которой является производство, продажа и доставка продукта до потребителя;
2. Обслуживающую систему, целью которой является поддержание работоспособности операционной системы;
3. Систему развития, целью которой является проектирование продуктов и создание операционной и обслуживающей систем или, иными словами, собственно организационное развитие.

Рисунок 1. Структура компании как сложной системы

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

Организационное развитие

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

1. Разработка требований;
2. Разработка и плана развития;
3. Разработка продукта;
4. Проектирование ;
5. Создание или изменение операционной и обслуживающей систем.

Разберем подробнее каждую из них.

1. Разработка требований

Стейкхо́лдер (англ. stákeholder), заинтересованная сторона, причастная сторона — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям.

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

Приведу несколько примеров стейкхолдеров:

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

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

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

Еще одна часть требований к операционной и обслуживающей системам появляется в результате Анализа эффективности внутренней деятельности. В нем:

• Делается вывод — достигает ли операционная и обслуживающая система необходимых показателей деятельности;
• Проводится бенчмаркинг с другими компаниями;
• Собираются замечания и предложения персонала (соответствует практике вовлечения персонала в методологии Lean — Бережливое производство).

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

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

2. Разработка бизнес-модели и плана развития

на концептуальном уровне показывает, как бизнес собирается «зарабатывать деньги». Хорошим примером простой формализации является канвас Остервальдера («канвас» в русском варианте переводится как «шаблон»). Он фиксирует потребительские сегменты (ПС), каналы сбыта (КС), ценностные предложения (ЦП), ключевые виды деятельности (КД), ключевые ресурсы (КС) и другие компоненты.

Рисунок 2. Пример компании Daimler из книги «Построение », А.Остервальдер и Ив Пинье

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

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

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

Если вам пришлось поменять или скорректировать , то с большой долей вероятности компанию ждут большие изменения. Они могут включать в себя и проектирование новых продуктов, и перепроектирование , и, конечно же, реализацию изменений в реальности. Это может занять длительный период времени, например, 2–3 года. Для синхронизации перечисленных работ во времени служит разработанный План развития.

3. Разработка продукта

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

В рамках этой функции существует две «разработки». Одна — это текущие улучшения существующих продуктов. Другая — разработка новых продуктов на основе их концепции и требований к новым продуктам.

4. Проектирование бизнес-архитектуры

Проектирование — деятельность, направленная на создание проекта (описания) операционной и обслуживающей систем. Проект описывает компанию с той точностью, которая необходима для последующего ее воплощения в реальности. Он включает в себя разнообразные модели деятельности (модели функций, ), модели организационной структуры, объектов деятельности, средств производства и информационных систем. Это самый трудоемкий этап организационного развития. Но он с лихвой позволяет окупить все трудозатраты за счет устранения огромного количества разнообразных ошибок в организации деятельности, которые иначе приходится устранять уже по факту. Нужно отметить, проектирование — это функция, к которой некоторые руководители относятся пренебрежительно. На практике большинство руководителей считают, что достаточно определить цель, а далее сотрудники сами организуются и в силу своих способностей придумают необходимую технологию деятельности и формализуют ее. Да, случается, что это работает. Но в ограниченном классе ситуаций: в небольших компаниях, сотрудники которых обладают достаточным интеллектом и знаниями. Второе распространенное заблуждение, что путем «проб и ошибок» нужная технология рано или поздно выработается «сама». Чаще всего этого не происходит, а если и происходит, затраты ресурсов «на ошибки» оказываются чрезмерно большими.

5. Создание или изменение операционной и обслуживающей систем

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

1. Подбор или ротация, обучение персонала;
2. Закупка или изготовление средств производства;
3. Внедрение информационных систем;
4. Сборка всех компонентов в единую систему.

Для существующей компании в рамках этого этапа перестраиваются только некоторые ее фрагменты. Для новой компании происходит ее строительство с «нуля».

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

Замечание 1

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

Замечание 2

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

Замечание 3

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

Как часто нужно заниматься организационным развитием?

Возвращаясь к тезису, что каждая компания должна меняться, возникает вопрос — а как часто? Я считаю, что в современной среде компания должна меняться постоянно. Это не означает, конечно же, что изменения должны происходить ежедневно или что перестраиваться должна обязательно вся компания целиком. Это было бы здорово, но сотрудники компании, скорее всего, этого не вынесут. Имеет смысл накапливать требования, периодически формировать из них пакеты и реализовывать их (практика ведения Backlog в SCRUM). пакеты будут более глобальными — с длительным сроком реализации, будут носить оперативный характер. Примеры глобальные пакетов: создание новых продуктов, изменение каналов сбыта, выход на новые потребительские сегменты. Примеры оперативных пакетов: текущая доработка продукта, не приводящая к изменению , совершенствование операционной и обслуживающей систем. Приведенный подход в части оперативных пакетов имеет определенное сходство с концепцией постоянных небольших изменений методологии разработки систем Agile.

Кто должен заниматься организационным развитием?

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

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

1. Ежедневно определенный процент времени руководитель должен выступать в роли ;
2. В компании должна быть долгосрочная система мотивации для руководителей, нацеленная на развитие.

Для координации деятельности по организационному развитию в компании, тем не менее, должно существовать подразделение организационного развития (в зависимости от размера компании — департамент, управление или отдел), директор которого выполняет, как минимум, две роли:

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

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

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

Рисунок 3. Организация организационного развития

Мы закончили рассмотрение структуры деятельности по организационному развитию и возможной ее реализации в компании. Как стало видно, организационное развитие — вполне понятная осязаемая деятельность с четкими границами. А значит может быть реализована в каждой компании даже без привлечения «супергероев». В заключение хочется заметить: к сожалению, время на понимание менеджерами сути организационного развития сильно ограничено того, что сегодня в экономике есть конкуренция и есть кризисы. У всех перед глазами есть примеры, как разоряются и закрываются компании, как неуспешные компании поглощаются более успешными. А в тяжелые экономические периоды это приобретает массовый характер, у многих компаний отсутствует хотя бы минимальный запас прочности.

Источник