Функциональная организационная структура против дивизиональной. Часть 1

%d0%b7%d0%b0%d0%b3%d1%80%d1%83%d0%b6%d0%b5%d0%bd%d0%be_10-12-2016_%d0%b2_01_57_19

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

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

В недавней публикации Мэттью Йглсайас Apple may have finally gotten too big for its unusual corporate structure («Компания Apple, наконец, стала слишком крупной для своей необычной корпоративной структуры») описал два основных типа организационной структуры и объяснил, как новая структура решит некоторые очевидные проблемы компании Apple. Ранее в этом году об этом писал Бен Томпсон из Stratechery в статье Apple’s Organizational Crossroads («Организационные пути Apple»). Я бы хотел, чтобы все было так же просто, как это преподносится в данных публикациях. Если вы не знаете, что такое организация по функциям или подразделениям (иногда их называют дивизионами), тогда сначала прочитайте эти две публикации.

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

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

Эта статья будет длинной! Но тема действительно сложная. В компаниях, ориентированных на людей, организационная структура так же важна, как инновации Генри Форда на предприятиях. При создании чего-либо масштабного организация влияет и даже определяет многое из того, что получится. Если вы генеральный директор или руководитель крупной компании, организация — одна из тех немногих вещей, которая является всецело вашей обязанностью. А дальше будет много текста.

«Переход к функциональной структуре»

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

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

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

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

Команда Office в Microsoft долгое время была известна, как место, где большое внимание уделялось структуре управления (за это стоит отдать должное легендарному Майку Мэйплсу ст., который за свою карьеру в IBM, до Microsoft, испробовал все, что можно вообразить в плане организационных структур). Его внимательность и знания влияли на эволюцию организационной структуры даже спустя годы после его непосредственного пребывания в должности.

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

Благодаря руководству Майка организационная структура стала дивизиональной (с длинным рядом хитроумных названий, например ABU, EBU, OBU, GBU, DABU и т. д. BU означало подразделение, а первые буквы — Analysis, Entry, Office, Graphics, Data Access и т. д. соответственно для Excel, Works, Word, PowerPoint, Access и т. п.). Эти команды были «подразделениями», так как могли проводить все научно-исследовательские и опытно-конструкторские работы и маркетинговые мероприятия, необходимые для управления предприятием. Почти все. Некоторые вещи было сложно реализовать, например организацию международного сбыта.

Стоит отметить, что после внедрения такой структуры Майк оставался ярым сторонником минимизации значения отчетов о доходах и расходах в этих группах. Его (и с этим невозможно поспорить) логика была простой: нельзя должным образом составить отчет по расходам, так как а) большую их часть подразделение не контролирует и б) подразделения во многом полагаются друг на друга для достижения коммерческого успеха. Последний пункт можно проиллюстрировать знаменитым высказыванием руководителя команды Word: «Наше главное преимущество перед WordPerfect — это Excel».

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

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

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

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

После дюжины лет и 6 продуктовых циклов Office я перешел в команду Windows. Культурные различия, за которыми я долго наблюдал (или с которыми сталкивался лично), для меня встали на первое место. В то время в команде Windows работали тысячи людей, в организации которых уже многие годы преобладали Systems («системы») (так называли другую часть Microsoft), где должно быть много подразделений. Эти подразделения были более раздробленными, чем, например, Word в Office. В Windows такая дивизиональная организация была предпочтительной по многим причинам, которые я укажу ниже.

В Windows были подразделения для каждой подсистемы, которую можно назвать при описании продукта: файловая система, ядро, оболочка, сетевая конфигурация, графические средства; и даже более мелкие подсистемы, например CODEC, FAX/Scan, DRM и т. д. Я попытался каталогизировать все множество продуктовых подразделений, и 142 из них относились к Windows и соответствующим онлайн-сервисам. Каждое из этих подразделений состояло из главного руководителя (или руководителя продуктового подразделения), некоторого количества инженеров (их называют инженерами ПО), тестировщиков и менеджеров по продукции (их называют администраторами проекта). Если все выразить в числах, то большинство этих команд включали не больше 15 инженеров и насчитывали в среднем 30 человек.

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

В 2006 году было документально подтверждено, что разработка следующей версии Windows проходила со сложностями. Поэтому разумно спросить, была ли проблема в организации, руководстве/управлении или в каком-либо технологическом процессе. При решении проблем с точки зрения организации всегда возникают сложности. Дело в физической структуре организации, логическом представлении, стратегии или людях — где именно скрывается проблема? В книгах по бизнесу и консалтингу авторы обычно сразу обрисовывают причинные связи и ведут к решению; и часто, если вы уже заменили некоторых людей, далее следует реорганизация. На эту тему можно посмотреть комиксы от Dilbert.

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

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

Изменение назвали «переходом к функциональной структуре». Переход был масштабным и тяжелым, так как затрагивал существовавшую почти 20 лет дивизиональную организацию и замещал многих главных руководителей. Я думаю, что в этой статье обойду стороной жуткие подробности об управлении изменениями. Работа, проделанная для подготовки к этому переходу, была сосредоточена на нескольких проблемах, которые были четко сформулированы для всей команды и на каждом уровне:

  • отсутствие четкости в постановке задач по созданию продукта и распределении ответственности за выполнение этих задач;
  • снижение качества работы инженеров;
  • недостаток сотрудничества между командами;
  • строгое распределение ресурсов;
  • недостаток оперативности в разработке продукта;
  • неэффективность основных технических процессов.

Такие проблемы можно встретить везде, где что-то идет не так, но это совокупность тех сложностей, которые ощущали многие в команде Windows. Для начала нужно понять, что ОС Windows — один продукт, с одной датой выпуска, ограниченным количеством клиентов (производителей ПК), очень широкой базой конечных пользователей и т. д. Учитывая это, использовать дивизиональную организацию, вероятно, не стоило. Ниже я покажу, почему дивизиональные организации могут подходить для быстрорастущей и комплексной продуктовой линейки. Указанные проблемы отлично описывают продукт, который поставлялся примерно в это время.

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

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

Во время этого преобразования я познал много уроков, но особенно мне запомнилось то, как организационная структура может влиять на общее развитие кадров в команде. Если у вас есть крупная организация, где лучших исполнителей убирают из управления линией/отделом и ставят в управление несколькими функциональными обязанностями, то возникает определенное, при этом постепенное, ухудшение качества навыков в основных отделах. Во время изменений больше всего мне запомнился тот факт, что у нас было 100+ главных руководителей, но не хватало руководящего персонала в основных отделах (например, управление продукцией, разработка ПО и тестирование). Тех, кто в будущем мог руководить 30, 40 или 60 инженерами, привлекли для управления более маленькими командами по 20-30 человек с 10-15 инженерами (еще тестировщиками и менеджерами по продукции).

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

Золотые правила

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

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

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

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

Золотое правило организации: не поставляйте организационную структуру с продуктом. Об этом много писали до меня, поэтому я не утверждаю, что сам сформулировал правило. Когда вы создаете организационную структуру, вы создаете продукт, поэтому проблемы в организации отражаются на продукте: глубина проработки функций отражает распределение ресурсов, координирование по отделам соответствует выбранным вами руководителям и т. д. Когда команда Office хотела создать пакет, мы организовали команду для создания пакета. Когда команде Windows понадобилось вовремя поставить один продукт Windows, мы убрали продуктовые подразделения и перешли к функциональной структуре; а когда мы хотели улучшить дизайн продукта и его качество, мы готовили руководителей тестирования, управления продукцией и дизайна. Когда мы захотели собрать компьютер, мы создали организацию с руководителем, полностью сосредоточенную на достижении этой цели, и т. д.

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

Продолжение следует…

Источник: medium.learningbyshipping.com



Рубрики:Анализ, Мнение, Теория

Метки: , ,

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s