Концепция организации и оргпроект

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

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

Какие принципы разбиения организации на модули в различных орг-архитектурных стилях, по каким принципам взаимодействуют оргзвенья в этих разных архитектурных стилях, будет обсуждаться в разделе по архитектуре организации/предприятия. Но в этом архитектурном разговоре ничего не будет говориться о самих оргвозможностях в части необходимых к исполнению практик, то есть умению оргзвеньев выполнять работы определёнными способами (работать по каким-то практикам), при этом ещё и быть обеспеченным для этого ресурсами и иметь административное позволение выполнять работы по нужным практикам — про роли и практики думают не столько орг-архитекторы, сколько орг-дизайнеры. Архитекторы думают про архитектурные характеристики, организационные -ilities.

В стратегии, конечно, будет указана какая-то высокоспецифичная для данной организации практика работы в какой-то предметной области, которую должна уметь выполнять организация, причём указана на минимум уровне метаУ-модели, а не мета-мета-модели. Оргдизайнеру надо как-то разбираться в разных предметных областях, чтобы разрабатывать специфические для организации модели в составе стратегии. Если оргдизайнер в моделях стратегии будет просто цитировать общие места из курса системного мышления или даже менеджмента — это не будет стратегией, это все и без стратегии понимают, что «так устроен мир», такое обычно называют «гигиеной», «все так делают, не стоит особого внимания». Недостаточно в стратегии написать «мы должны быть гибкими, богатыми, быстро расти, а нашей отличительной чертой будет клиентоориентированность». Оргдизайнеру (самому или при помощи приглашаемого им для работы эксперта предметной области/subject matter expert) нужно разбираться в практике на уровне учебников самых разных практик, которые лежат в основе работы его организации, то есть работать на уровне метаУ-модели. Далее эту практику оргдизайнер (часто при помощи эксперта по предметной области практики) должен представить как метаС-модель, адаптировав к местной производственной культуре, чтобы у лидера могла быть возможность как-то объяснить сотрудникам, которые будут выполнять эту практику, что им надо будет делать во время работы по этой практике.

Мы тут говорим о мета-модели, а не об операционной модели, ибо проектирование ведётся всегда в типах, работа оргпроектировщика — это работа с мета-моделями! Организация при этом как раз попадает под ситуацию, описанную ещё в «Системном мышлении» как «если у вас проект Эйфелевой башни, единственной в мире, то её проект — это всё равно описание не отдельных деталей, а типов деталей. Потом эти детали будут изготовлены как экземпляры, и учтены в модели конкретной физической Эйфелевой башни. И при необходимости по этим же описаниям они будут изготовлены снова и снова, ибо это описание множества деталей, которое потенциально может быть изготовлено». А вот операционные менеджеры и рабочие сборки будут работать с экземплярами и их модели будут содержать не описания типов как тегов/tags/кодов отдельных частей конструкции, а серийные номера экземпляров этих частей, которые типизированы этими тегами. Так что в мета-мета-моделях не будет слов предметных областей, а в мета-моделях они будут, в то же время в мета-моделях не будет конкретных имён людей, инвентарных номеров оборудования, но будут только их типы (скажем, должности как оргместа будут, но что на этой должности «Иван Иванович» — этого не будет, это решится потом, в ходе «изготовления», то есть в ходе проведения оргизменений/лидерства).

Итак, в моделях оргдизайнеров сначала появляются вот эти предметные практики, которые должны быть поставлены в организации. Большинство из этих практик — это целевые практики, которыми занимаются инженеры целевой системы (если это университет, то практики создания мастерства, практики организации абитуры/клиентуры). Конечно, там будут и практики администрирования (ведение бухучёта, офис-менеджмент, работа с кадрами), а иногда и практики собственно менеджмента (скажем, переход на методы beyond budgeting, если по каким-то причинам этого ещё не произошло). Но эти практики администрирования и менеджмента — это не главное в стратегиях. Если вы красите заборы плохой краской, забываете их почистить, эти заборы облезают после первого дождя, то никакой современный менеджмент и как часики работающий финансовый учёт вашей организации не поможет. Впрочем, поможет: инженеры узнают от клиентов, что «так жить нельзя, не хотим вам за это давать денег», предложат способы устранения ошибок в практиках работы, а оргдизайнеры как раз должны запроектировать организационные изменения (изменения практик) и провести их в жизнь. Конечно, оргдизайнеров может быть тоже несколько команд, какие-то из них могут заниматься чисткой-блисткой менеджмента, но большинство команд таки должны заниматься инженерными практиками и практиками маркетинга.

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

• Органиграмма (структура деления организации на оргзвенья, обычно неполная, ибо в ней не показываются обычно всякие научно-технические советы, комиссии, рабочие группы проекта и прочие реальные оргзвенья, но только структура «мест найма» в части официального учёта занятых — и нужны способы учёта полной оргструктуры. Но тут проблема: у генерального директора как единоличного исполнительного органа может не быть полномочий управлять каким-нибудь советом, поэтому органиграмма не может указать этот совет в структуре подчинения! Это не означает, что такого оргзвена в организации нет, и что это оргзвено не выполняет каких-то работ по каким-то практикам).
• Каталог сервисов: это перечень работ, которые могут быть выполнены оргзвеньями в организации на оргинтерфейсах этих оргзвеньев. Обсуждаются обычно в терминах кейсов (что предмет кейса, какое состояние его до задействования сервиса, какое состояние после сервиса). При оргпроектировании назначаем эти сервисы на конкретные оргзвенья.
• Оргфункциональная структура/модель, это модель практик (часто дающаяся в тех же терминах «типовых кейсов», что и каталог сервисов»). Но тут уже функции оргролей и порты, описывающие потоки чего-то, что течёт через организацию. И вот эти оргфункции становятся потом сервисами, которые оказываются оргзвеньями. Помним, что в инженерии в 9 случаях из 10 функциональные части и конструктивные совпадают друг с другом полностью, но в одном из десяти случаев возникает ситуация типа «ножницы» или «чайник», это же приложимо к концепциям организационных систем: оргроли и практики могут соответствовать оргзвеньям и оргсервисам 1:1 в девяти случаях из десяти, но в десятом случае могут и не соответствовать — и будут тщетные попытки лидеров разобраться, что же им нужно изготавливать (помним, как завод пытался поручить изготовить вместо половинок ножниц и винтика отдельно «ручку», отдельно «ножевой блок» на разных заводах, или пример компрессора с попыткой отдельного изготовления «двигателя» и «турбины» из «Системного мышления»). Вот эта оргфункциональная модель получается из содержательного рассмотрения происходящего в рабочих процессах. В оргфункциональной модели чаще всего дело не доводится до практик в их привычном виде шаблонов кейсов, ибо шаблоны кейсов с их предметами работ — это всё-таки типизация работ/сервисов с их рабочими продуктами, а практики — это типы работ, работающие с альфами. Конечно, соответствие (и термины, выбранные для названий) будут также в большинстве случаев 1:1, но потом вдруг окажется, что какая-нибудь «модель» как альфа будет отражена в нескольких «документах»/«отчётах» как рабочих продуктах. Это всё опять, было обсуждено в курсе «Методология», и нужно только это общее знание использовать в работе оргдизайнера.

Дальше это всё доводится до оргпроекта, но это чаще всего не up-front design, а вполне обычный процесс создания MVP реализующей новую практику организации (MVP — это с точки зрения бизнесмена, как он определит её «продаваемость»), а затем бесконечное развитие (выкидывание лишних функций, добавка гипотетически полезных — и тут акцент на «гипотетически» полезных, это всё такая же работа с догадками-гипотезами, как и любая другая инженерная работа. Техно-эволюция быстрее эволюции, но каждая мутация всё одно должна проверяться жизнью, в том числе она может быть полезна «вчера» или «завтра», но не «сегодня» — и это тоже надо учитывать, жизнь ведь изменчива). Таким образом оргпроектирование тоже непрерывно, а не разово, нет никакого «жизненного цикла организации», а есть создание и последующее (по возможности бесконечное) развитие.

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

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

У этого моделирования есть принципы непубличности работы с мета-мета-моделью:

• Работники предприятия должны разбираться в экземплярах предметной области, заполняя таблички. Типы этих экземпляров (метаС-модель) должны быть прописаны в названиях колонок таблички.
• Эксперты предметной области (владеющие метаУ-моделью, «образованные специалисты») вместе с оргпроектировщиком должны приготовить табличку, проставив заголовки таблички в терминах метаС-модели. Типы этих элементов (мета-мета-модель) должны быть в голове у оргдизайнера, и он должен задавать вопросы эксперту предметной области, если обнаружит, что эксперт забыл отразить в табличке какие-то важные объекты. Эту работу исполнители ролей эксперта предметной области (subject matter expert) и оргдизайнера выполняют вместе! Идеально, когда эксперт предметной области и оргдизайнер (помним, что это половинка менеджера по развитию) совмещены в одном человеке, но это обычно нереально: разных предметных областей много, а ещё оргдизайнер должен получить образование в части мета-моделирования (например, пройти курсы ШСМ, начиная от «Моделирования и собранности» до «Системного менеджмента» включительно, чтобы понимать, о чём говорится в текущем абзаце и что именно он делает, когда проектирует эти таблички. Это ровно та работа, которую он делал уже много раз, когда выполнял упражнения этих курсов). Важно, что оргдизайнер всю типизацию мета-мета-модели и рассуждения по мета-мета-модели проводит в голове. Он не говорит «система микроволновка», он говорит «микроволновка», если речь идёт о микроволновке (а в голове у него микроволновка::система). Но если у него подозрение, что «микроволновка» в словах эксперта предметной области означает описание микроволновки в проектирующем микроволновку конструкторском бюро, а не саму микроволновку как физический объект, то он должен уточнять — и в табличке потом всё должно быть однозначно (например, «3D-модель микроволновки», а не «микроволновка»). Если не соблюдать этот принцип, то разговора не получится: эксперт будет спотыкаться о каждое слово из мета-мета-модели, поэтому в обсуждениях заголовков таблички эти слова про типы не должны звучать, но должны звучать слова из предметной области эксперта. В обсуждении с экспертами эти термины типов мета-мета-модели оргдизайнером табуируются.
• Оргдизайнер обязан владеть мета-мета-моделью, чтобы в таблицах оргмодели не было нетипизированных сущностей. Но типизация эта должна быть только у него в голове, в таблице её указывать не надо! Хотя для себя он может и делать заметки по отображению типов из мета-мета-модели в явном виде. Исполнитель роли оргдизайнера ведь «не гроссмейстер», чтобы такие сложные мыслительные действия делать «в уме», как шахматисты-гроссмейстеры. Нет, используем экзокортекс, всё пишем — «мышление моделированием». Но не говорим и не показываем эти типы эксперту!

Другими словами, кто не проектирует таблички, а только их заполняет, может не изучать системного мышления и не знать мета-мета-модели, а кто проектирует таблички**—** он должен владеть системным мышлением, пройти курсы системной инженерии и менеджмента. Тем самым менеджеры оргразвития должны пройти курсы всей линейки от «Моделирования и собранности» до «Системного менеджмента», а основная их работа будет в оргдизайне (моделировании табличек оргмодели вместе с экспертами по практике, которую они хотят превратить в оргвозможность) и лидерстве (уговорить людей сотрудничать в воплощении в жизнь этой модели, выраженной в табличках**—** люди должны выполнять описанные в табличках практики, играя описанные в табличках роли и передавая друг другу рабочие продукты предметов их кейсов).