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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии
Директор по производству, Украина

"канвас Остервальдера" -- Впечатляет.

А книга Гэлловэй Л. "Операционный менеджмент" -- Не впечатляет.

:)

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

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

Это в противовес лёгкого в использовании шаблона -> Канвас Остервальдера, с которым может работать один специалист - и к чему был этот пример, если он оказался именно "том" месте статьи осталось неясным - логичнее с этого начинать,

И почему анализ внешней среды так сложен и на каком уровне сложен, если это под силу студентам ВУЗов? :)

Автор пишет: В отличие от анализа внешней среды, который, возможно, могут позволить себе не все компании ...
Слушатель MBA, EMBA, Москва

Все, что написано в статье, регулярно выполняет, в той или иной степени, аттестованный (PMP) Руководитель Проектов, в КАЖДОМ(!) проекте. На оргсхеме "Архитекторы ...." элемент "Директор по Организационному Развитию" - это лишнее, никчемное и неоправданно дорогое звено.

Менеджер по персоналу, Москва

В данном подходе все замкнуто на технологию. Но отмечено, что организация - это социо-техническая система. Однако о роли социума и личного в подходе даже не упоминается. Получается, что организация существует сама по себе, исключительно за счет своих структур. НО, СТРУКТУРА МЕРТВА, ЕЕ ПРОСТО НЕТ, ЕСЛИ В НЕЙ ОТСУТСТВУЕТ ЧЕЛОВЕК. Надо понимать суть оргсистем!

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

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

Александр Федотов пишет:НО, СТРУКТУРА МЕРТВА, ЕЕ ПРОСТО НЕТ, ЕСЛИ В НЕЙ ОТСУТСТВУЕТ ЧЕЛОВЕК. Надо понимать суть оргсистем!

Совершенно верно! Если Вам что-то нужно предложить по совершенствованию работы, а на пути стоит такая "СТРУКТУРА" - то это явно не полезно для компании.

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

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

Нач. отдела, зам. руководителя, Москва
Автор пишет в статье: От сотрудников, которые будут заниматься приоритезацией ...

У нас очень любят строить сложные Бюрократические Структуры. Опытный Руководитель имеет все основания не верить, что ложные идеи о Структуре сами по себе решат все проблемы, и создаст соответствующую Инфраструктуру, чтобы продвигать инициативы работников.

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

Многим становится смешно, когда говорят о японских кружках качества :) Да!!! - эта идея проваливалась не один раз в наших условиях ..., но только в Силу Непонимания принципов работы. Если у рабочего есть идеи, а мастер может зарубить любую - ему нужен план в первую очередь ->

только соответствующая Инфраструктура может помочь продвижению инициатив работников.

Генеральный директор, Самара

К сожалению, многие негативные смыслы, которые коллеги находят в статье, на самом деле в ней не содержатся. А содержатся ровно обратные.

Прокомментирую часть , насчет СТРУКТУР и РУКОВОДИТЕЛЕЙ.

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

По части рассмотрения инициатив по развитию бывают три ситуации:

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

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

3.
3.1 Изменения выйдут за рамки деятельности, за которую отвечает руководитель. 3.2 Предлагаемые разными руководителями изменения противоречат друг другу.

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

Нач. отдела, зам. руководителя, Москва

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

Дмитрий, я не придираюсь, но в другой статье Вы писали:

Следствием вышесказанного является то, что в компании должна быть когорта бизнес-архитекторов и регулярно осуществляемая деятельность по организационному проектированию. http://www.e-xecutive.ru/management/practices/1985...
целая Когорта архитекторов - это ведь и руководители -> у которых нет времени - без тени сомнения понятно, что их заменят специалисты по бизнес процессам, и они уж точно не пропустит никого кроме себя -> это видно в т.ч. по нежеланию обсуждать принципы работы -> типа -> и так всё ясно: схему нарисовали, требования собрали, всё ненужное отсеяли, ещё одну схему нарисовали - структуру, потом ещё одну .... Попробуем с другой стороны подойти: Кто занимается отсеиванием самых плодотворных идей и выделением бюджета?

Это не только моё мнение - если запустить перед внедрением информационной системы группу специалистов по бизнес процессам, то в большинстве случаев до внедрения дело не дойдёт - на этом проект и закончится :)

Генеральный директор, Самара

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

>>Кто занимается отсеиванием самых плодотворных идей и выделением бюджета?

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

Остальные ваши смыслы не понял. О них в статье не писал.


Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии