Структура программы организационного развития

Перевод статьи What is Organizational Development? A Complete Guide нашего проекта переводы статей по hr-аналитике на английском. Автор Eric van Vulpen, на сегодня самый читаемый автор нашего блога- о нем достаточно сказать, что его статья стала лидером чтений в нашем блоге в 2019 году
KPI HR: подробное объяснение с метриками и примерами

Что такое Организационное Развитие? Полный гид

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

Что такое организационное развитие?

Организационное развитие — это важный научнообоснованный (science-based) процесс, который помогает организациям наращивать способности к изменениям и достигать большей эффективности. Это достигается путем разработки, совершенствования и укрепления стратегий, структур и процессов.

Отдел организационного развития. Его организационная структура и пример работы с изменениями

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

Для диагностики используются разные модели. Ниже вы увидите образец, который поможет структурировать различные компоненты дизайна организации (обратите внимание на сходство Galbraith’s star model). Эта модель четко показывает различные компоненты, которые играют роль на разных уровнях (организационном, групповом и индивидуальном).

Источник: edwvb.blogspot.com

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

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

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

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

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

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

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.

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