Мы уже говорили о том, что организационный дизайн уже

существующего предприятия и нового предприятия отличается.

Если для нового предприятия мы должны ориентироваться на лучшие практики,

на стратегию, на видение того, как будет,

и под это подстраивать процессы и организацию деятельности,

то для существующего предприятия мы должны отталкиваться от той ситуации и оценивать

ту ситуацию, какая уже сложилась на предприятии,

оценивать практику ее деятельности, проводить аудит этой практики.

Ну давайте начнем для простоты с нового предприятия.

Когда я проектирую новое предприятие,

когда вы проектируете новое предприятие или еще кто-либо,

ему приходится отвечать на следующие вопросы.

Каковы продукты и услуги этого предприятия?

Как продукты и услуги будут развиваться во времени?

Если мы задали продукты и услуги,

если мы задали стратегию развития продуктов и услуг во времени и стратегию

развития во времени бизнес-модели деятельности предприятия,

то из этой информации мы можем сформировать требования к

составу процессов и к организации деятельности.

Продукты и услуги задают нам требования к основным процессам,

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

Таким образом мы определяем модель,

выход, вход, основные процессы.

Основные процессы мы дополняем всеми процессами деятельности предприятия,

которые создают прибавочную стоимость,

то есть мы строим корневую модель бизнес-процессов.

И эту корневую модель детализируем либо на процедуры,

либо на функции, либо одновременно и на процедуры и на функции.

Определяем состав участников.

Обратите внимание,

что состав участников — это другой вход в это организационное проектирование.

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

необходимые для их производства и для их продвижения,

а другой вход задает информация о том,

кто эти процессы будет исполнять, какой состав участников,

которые будут принимать участие в деятельности нашего предприятия.

И вот соединение процессов с одной стороны и участников с другой стороны

позволяет строить матрицы соответствия между процессами и участниками,

определять ответственность участников за исполнение бизнес-процессов.

И эта композиция этих моделей, их довольно много, хотя каждая из этих моделей,

если правильно поступать в заданном типовом формате,

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

Вот этот набор моделей, собственно, и определяет исходные данные,

исходные представления, которые помогают нам задать положение

о подразделении предприятия.

Задать то, как предприятие работает, как оно описано, какие модели использует,

какие регламенты могут быть построены и как они

строятся для предприятия на верхнем уровне.

Дальше аналогичным образом, если у нас задано верхнеуровневое

описание предприятия, верхнеуровневая модель предприятия и регламенты

деятельности предприятия на верхнем уровне, то мы можем уже по известным

схемам детализировать эти описания на уровень подразделений,

а дальше на уровень должностей или сотрудников.

Таким образом, мы осуществляем проект дизайна сверху вниз,

причем число моделей и разнообразие этих моделей по участникам, по

видам процессов увеличивается сначала на втором уровне, а потом на третьем уровне.

Модель имеет форму пирамиды.

Сверху агрегированное описание, дальше эти описания расширяются,

и число этих описаний расширяется.

И наконец, на нижнем уровне эти описания дополняются и доводятся

до такой степени детализации, что в них уже видны действия каждого сотрудника,

каждой должности, которая участвует в деятельности этого предприятия.

Когда мы переходим с уровня на уровень, мы задаем участников

деятельности на каждом уровне организационной структуры,

и состав этих участников может быть однозначно не определен,

то есть он задается как управляемая часть при

проектировании организационной структуры.

Обычно на практике задаются нормы подчинения,

скажем, одному руководителю подчиняются три сотрудника,

одному руководителю подчиняются семь сотрудников,

одному руководителю подчиняются до 15 сотрудников.

И вот при таких ограничениях строится организационная иерархия.

Ее нужно, конечно, рассчитать.

Для больших предприятий для этого применяются специализированные

организационные инженерные калькуляторы,

которые рассчитывают эту иерархию в зависимости от тех норм и тех ограничений,

которые мы принимаем в отношении каждого подразделения и в отношении

каждого уровня сотрудника и в отношении норм управляемости.

Ну и по практике ситуация выглядит так: во-первых,

все организационные структуры в соответствии с правилами,

известными законами бюрократизации, они стараются вырастать вверх,

в высоту, то есть уровней управления становится все больше,

а на каждом уровне управления они стремятся куститься,

то есть число объектов управления становится все больше.

И организационная структура, первоначально появляясь как рационально

продуманная, экономная, рационально спроектированная,

начинает прирастать лишними веточками, лишними уровнями, становится

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

Но это неизбежный закон таких организационных систем,

их жизни в процессе деятельности.

И эти законы заставляют нас проводить время от

времени аудиты организационной структуры,

аудиты организации деятельности с тем, чтобы убрать лишние уровни,

лишние ветки и сделать эту организационную

структуру целесообразной, и я бы сказал даже, красивой.

Теперь посмотрим еще на одну задачу,

которая возникает при переходе с

уровня на уровень при организационном проектировании.

Рассмотрим первый уровень иерархии.

Есть участник, который исполняет

или участвует в исполнении какого-либо корневого процесса.

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

мы можем детализировать описание самого корневого процесса в виде потоковой

диаграммы и определить те места, в которых участвуют те подпроцессы,

в которых участвует этот участник.

Или другой традиционный подход, он еще сформировался в начале прошлого

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

а потом задаем функции, которые необходимы для решения задач.

Поэтому описание получается таким — процесс; участник,

который в нем задействован; задачи

участника; функции участника.

И вот такое описание — процесс, задачи,

функции — обычно входит в положение о том или ином участнике процесса.

Теперь, участник — давайте встанем на его позицию.

Участник исполняет процесс и отвечает за исполнение задач и функций.

И эти задачи и функции довольно трудоемкие.

Значит, надо передать часть ответственности

за исполнение задач и функций вниз.

Иерархическая организационная структура — это именно та структура,

это то образование, которое позволяет реализовать это право.

И это право, собственно, и есть одно из прав системы управления.

Верхний уровень имеет преимущественное право по отношению к нижестоящим уровням.

Поэтому передача ответственности происходит следующим образом.

Участник один формулирует декомпозирует

свои задачи на субзадачи и часть этих субзадач

передает на уровень вниз, подчиненному подразделению.

Подчиненное подразделение, получив субзадачи,

детализирует описание функции,

уточняет описание функции, которая необходима для решения этих субзадач.

В результате ответственность за исполнение процесса у нас привязана и к первому,

и ко второму уровню иерархии.

Вот такая модель,

такая схема действий называется «передача ответственности сверху вниз».

Хорошо.

То есть в этой схеме часть...

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

к участникам привязаны задачи, которые привязаны...

обеспечивают реализацию этих бизнес-процессов.

Эти задачи декомпозируем в детализированных функциях.

Функции передаются частично, так сказать, на уровень вниз в виде задач.

То, что было функцией на уровне 1,

становится задачей, субзадачей на уровне 2.

Участники уровня 2 детализируют задачи,

то есть функцию верхнего уровня, которую они получили,

как субзадачу, на свои субфункции.

И таким образом мы выстраиваем иерархическое дерево функций,

которое передает ответственность за выполнение процессов по иерархии.

То есть у нас два вида ответственности: ответственность за исполнение

процессов на одном уровне организационной схемы,

это матрица соответствий «участники деятельности — процессы»,

и второй уровень ответственности, когда мы передаем ответственность за исполнение

функций с одного уровня управления на другой, нижестоящий уровень управления.

Организационное проектирование на уровне предприятия.

Ну, теперь схема уже становится примерно понятной.

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

один вход в проектирование,

сформировать организационную структуру, состав участников деятельности,

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

Определить задачи звеньев верхнего уровня в исполняемых

ими бизнес-процессах, декомпозировать эти задачи на функции,

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

и в результате получить функциональное

описание деятельности предприятия на верхнем уровне.

Это функциональное описание можно разделить по блокам, которые закреплены

по функциональной ответственности за каждым участником деятельности,

а мы получим положения о подразделении методом выделения

этих положений от корневой модели бизнес-процессов предприятия.

Организационное проектирование на уровне подразделений.

Входная информация — это информация о задачах и функциях,

а точнее сказать, о субзадачах и субфункциях этих

подразделений в исполнении процесса.

Задачи подразделения декомпозируются на функции, организационная

структура предприятия детализируется до уровня подразделений, устанавливается,

для каждого подразделения устанавливается соответствие функций и исполнителей.

И вот вся эта информация собирается компактно в виде

положения о подразделении.

Ну а состав этого положения о подразделении выбирается...

или состав атрибутов, состав характеристик, состав разделов положения о

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

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

Одним из элементов этой архитектуры являются вот эти положения о

подразделениях.

Теперь переходим на уровень организационного проектирования на уровне

должностей и сотрудников.

Мы получаем в качестве входного описания задачи,

которые исполняются на уровне должности, на уровне сотрудников.

Эти задачи детализируются на функции, закрепляются за сотрудниками

и с дополнительными атрибутами, с дополнительными характеристиками

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

Пример схемы организационного проектирования

Бизнес-процессы, организационное проектирование, механизмы и системы управления

Meet the Instructors