Как строить и перестраивать компанию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример бизнес-модели компании Daimler

Источник: книга Александра Остервальдера и Ива Пинье «Построение бизнес-моделей»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В уже существующей компании на этом этапе перестраиваются только некоторые ее фрагменты. В новой компании все строится с нуля.

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

Три важных замечания

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

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

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

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

Возвращаясь к тезису, что каждая компания должна меняться, возникает вопрос – а как часто? В современной среде компания должна меняться постоянно. Это не означает, конечно же, что изменения должны происходить ежедневно, или перестраиваться должна обязательно вся компания целиком. Это было бы здорово, но сотрудники компании, скорее всего, этого не вынесут. Имеет смысл накапливать требования, периодически формировать из них пакеты и реализовывать их. Какие-то пакеты будут более глобальными – с длительным сроком реализации, какие-то будут носить оперативный характер.

Примеры глобальные пакетов: создание новых продуктов, изменение каналов сбыта, выход на новые потребительские сегменты.

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

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

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

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

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

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

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

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

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

Архитекторы организационного развития

Мы закончили рассмотрение структуры деятельности по организационному развитию и возможной ее реализации в компании. Как стало видно, организационное развитие – вполне понятная осязаемая деятельность с четкими границами. А значит, может быть реализована в каждой компании даже без привлечения «супергероев».

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

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