7. Практика организационного дизайна

Оргразвитие: оргдизайнеры и лидеры

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

• Оргдизайнер/оргпроектировщик — проектирует организацию (с учётом архитектурных и бизнес-решений, задаваемых архитектором организации и бизнесменом соответственно)

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

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

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

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

• Проекты организационного совершенствования не связаны с освоением новых практик, но связаны главным образом с решением задач операционного менеджмента: это оптимизации прохода и оптимизации в администрировании. Основное в них то, что людей не нужно учить новым понятиям, потому как не меняются практики, хотя могут меняться технологии. Process of ongoing improvement (POOGI)/Практика непрерывного совершенствования в теории ограничений — это цикл непрерывного ускорения прохода. Совершенствованием могут заниматься люди с менеджерской специализацией, это главным образом разбирательство с уменьшением времени пауз, а также уменьшением времени на координацию (этого мы коснёмся чуть позже: когда работу какая-нибудь Николь делает пять минут, но чтобы она этим занялась, вам нужно получить 12 виз от разных очень занятых людей — и это занимает полгода разговоров. Не нужно осваивать никаких новых практик, нужно просто прекратить собирать эти подписи в таком количестве, и жизнь существенно ускорится!).

• Проекты организационного развития связаны с освоением новых практик, которые определяются их дисциплинами, описывающими новые объекты внимания, новые domains. Организация заводит новые оргвозможности, которые позволяют сделать что-то новое (совершенствование этого не позволяет, оно позволяет только быстрее делать всё то же самое, замена одного станка старой марки на станок новой марки — это ещё не оргразвитие, это просто «гигиена», но если у нового станка новый принцип работы и нужно научить людей новой дисциплине, то да — это будет оргразвитие). Интересно, что новые практики совершенствования (практики принятия решений операционными менеджерами) — это тоже будет результатом шагов/проектов/кейсов развития. И изменение организационной культуры тоже будет результатом оргразвития, ибо это означает изменение практики думать и делать что-то согласно каким-то паттернам мышления и поведения в организации, нужно людей переучить. Не говорим «внедрение» практик — организаторы ничего не «впихивают-внедряют, а люди пищат-сопротивляются этому вторжению». Говорим про проекты развития со стороны организаторов о постановке практик, а со стороны организуемых — об освоении практик, и не забываем, что после постановки и освоения практик нужно ещё дать полномочия по тратам ресурсов на выполнение новых практик («уметь делать» — это ещё не «делать»).

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

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

Из курса «Системная инженерия» мы знаем, что разработчики:

• Руководствуясь стратегией и информацией от продвиженцев по поводу надсистем и внешних проектных ролей, а также лично общаясь с потенциальными и актуальными клиентами, делают предположение о том, что нужно от целевой системы для того, чтобы она выполнила какую-то полезную клиентам функцию в надсистеме. Отражают это в модели «концепция использования» (ConOps или OpsCon, и иногда есть нюансы в их различении, но это неважно. Главное — это описание поведения целевой системы как «чёрного ящика»). Это может быть, конечно, не вся система (скажем, MVP), но какая-то отдельная фича или набор фич, то есть речь идёт о «непрерывной модернизации имеющейся уже целевой системы».

• Находят аффордансы для реализации концепции использования, отражают в модели «концепция системы». Тут важно отметить, что ещё несколько лет назад эта модель называлась «архитектура системы», и путаница в названиях будет ещё несколько лет.

• Предлагают способы изготовления, согласованные с возможностями внутренней платформы разработчиков (design for manufacturing).

• Получают «добро» от визионера (business case — ожидание того, что создаваемая система или фича будет обходиться дешевле, чем её можно продать, иногда это design for cost).

• Проектируют систему или её фичу с точностью, достаточной для изготовления, изготавливают и тестируют, пользуясь инструментами (станками, программами) внутренней платформы разработчиков и учитывая ограничения архитектуры.

• Эксплуатируют у клиента (при изготовлении может быть изготовлен и введён в эксплуатацию и цифровой двойник), по факту могут быть и операторами, you build it, you run it. После чего могут возникать разные идеи о том, что можно сделать лучше, и идёт переход к началу цикла (подготовка новой концепции использования для новой версии, или новой фичи) или принимается решение о том, что развивать далее систему бесперспективно.

• Тратят 20% времени (в среднем) на выплаты технического/архитектурного долга (работы по реализации архитектурных решений: правильной нарезки их целевой системы на модули и реализацию правильных способов связи между модулями).

Организаторы делают то же самое, что разработчики целевой системы, но для системы-организации:

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

• Находят или проектируют аффордансы для реализации концепции оргразвития (оргзвенья из людей и оборудования — уже имеющиеся внутри, или которые нужно создать, или которые нужно законтрактовать/outsource), отражают в модели «концепция организации». Тут важно отметить, что ещё несколько лет назад эта модель называлась «архитектура системы», и путаница в названиях будет ещё несколько лет. Это тоже делают оргдизайнеры.

• Предлагают способы изготовления, согласованные с возможностями внутренней платформы разработчиков (design for manufacturing), изготовлением занимаются лидеры (управляющие организационными изменениями, в разработке «железа» это были бы технологи производства, представители завода) — оценки получаем в том числе от них.

• Получают «добро» от бизнесмена (business case — ожидание того, что создаваемая организация или её новая оргвозможность/орг-фича будет обходиться дешевле, чем её можно продать потом инвесторам, это тоже можно назвать orgdesign for cost. Помним, что на организационное развитие платят деньги инвесторы, а не клиенты — бизнесмены могут решить, что фирма бесперспективна, поэтому просто проэксплуатировать текущую клиентуру на зарабатывание в рамках текущей организации, не согласиться вложить деньги в фирму как «машинку по зарабатыванию денег», сочтут это невыгодным). Это обычно делают оргдизайнеры.

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

• Эксплуатируют созданную организацию (при изготовлении может быть изготовлен и введён в эксплуатацию и цифровой двойник), по факту это делают операционные менеджеры — они и есть «операторы организации», они заняты «настройкой» организации, которая обычно называется «непрерывным совершенствованием». Оргдизайнеры, лидеры, операционные менеджеры — это всё подроли организатора, и тут выполняется принцип you build it, you run it (в данном случае — «ты это организовал, ты этой организацией и рули», хотя «рулить» будет главным образом подроль, но в небольших организациях все три роли будет выполнять один человек, а в крупных даже и подроли будут играть множество разных людей). После чего могут возникать разные идеи о том, что можно сделать лучше, и идёт переход к началу цикла (подготовка новой модели оргразвития и новой модели целеполагания для нового шага развития) или приниматься решение о том, что развивать далее организацию бесперспективно.

• Менеджеры оргразвития (оргдизайнеры и лидеры) тратят 20% времени (в среднем) на выплаты орг-архитектурного долга (работы по реализации орг-архитектурных решений: правильной нарезки организации на оргзвенья, реализацию правильных способов взаимодействия оргзвеньев).

Упражнение

Опишите от трёх текущих проектов развития в вашей компании.

Опишите от трёх проектов развития, которые вы хотели бы провести для вашего подразделения.

Опишите от трёх проектов развития целевой системы (не замены, а именно развития — использование альтернативных принципов работы, задействования иных инженерных дисциплин).

Предположите организационное изменение, которое нужно провести в части практик, в которых вы будете задействованы. Какие рабочие продукты будут задействованы при постановке практики?

Работа оргдизайнеров

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

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

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

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

Далее внесём специфику менеджмента как инженерии организации:

Разработчик тут стал оргдизайнером (мы расщепили роль разработчика-организатора на подроли менеджера оргразвития и операционного менеджера, а менеджера развития на подроли занимающегося проектированием оргдизайнера/оргпроектировщика и лидера, оставили на диаграмме только оргдизайнера, а уж он согласует оргпроект со всеми остальными ролями, это его работа). Визионер (который смотрит, можно ли продать целевую систему клиентам) стал в организации как системе создания целевой системы бизнесменом (который смотрит, можно ли продать организацию инвесторам и использует для этого бизнес-модель). Уточнены и названия моделей. Use case при этом стали просто «сценариями» (ибо странно говорить про «сценарий использования дирекции инжиниринга», но можно говорить, например, о «сценариях взаимодействия с дирекцией инжиниринга», что то же самое с точки зрения окружения, просто перевели не двумя словами, а одним, но людям в дирекции инжиниринга это на слух много приятнее, нет оттенка «нас используют»). Юнит-тесты стали уже хорошо знакомыми нам чеклистами — организацию не принято «испытывать», хотя вполне можно «проверять», а уж чеклисты вообще не вызывают особых вопросов. Так что отношения между ролями и характер разрабатываемых моделей не изменились, но все они были уточнены для организации: это мы отразили переход от самой абстрактной мета-мета-модели системной инженерии к более конкретной метаУ-модели менеджмента как инженерии не вообще любой системы, а именно инженерии организации.

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

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

• Архитектор целевой системы предписывает ещё разбиение на какие-то модули с тщательно спроектированными интерфейсами и прописанными взаимодействиями через эти интерфейсы, это разбиение следует какому-то архитектурному стилю. Это делает архитектор, которого заботит «что будет потом» в терминах архитектурных характеристик целевой системы. Команды разработчиков по возможности независимо далее развивают каждая команда свой модуль для «что важно для клиента прямо сейчас», добавляя в него нужные для успешности надсистемы функции. При этом они могут мешать друг другу, часто ненамеренно. Грубо говоря, «мы хотим вот тут взять немножко энергии для печки, нам удобно взять 12 вольт, а рядом идёт провод 12 вольт из какого-то другого модуля, мы к нему подцепимся, то есть сделаем «неучтённый интерфейс» мимо публично объявленного той командой», и после этого в машине почему-то не срабатывает тормозная система после того, как включается печка: эти 12 вольт взяты из питания для тормозной системы, которое не было рассчитано на печку. Архитекторы целевой системы следят, чтобы такого не было, чтобы сиюминутные технические решения одной команды не влияли на характеристики системы на следующих шагах развития. Их отношение к разработчикам: сначала принятие обязательных для соблюдения разработчиками решений, затем менторство по разъяснению этих решений (не только «что надо делать», но и «почему надо делать», ибо разработчики будут придумывать хитрые способы обходить решения архитекторов — «по форме всё в порядке, а по сути — сущее безобразие»), а затем ещё и осуществлять надзор за выполнением этих решений. Разработчики и архитекторы в конфликте из-за разных межвременных предпочтений: архитекторы больше думают обычно про «потом», а разработчики про то, что клиенту нужно вот прямо сейчас: «давай реализуем грязный и быстрый способ решения текущей проблемы, а нормальную реализацию отложим на когда-нибудь». Разработчики постоянно накапливают долг по работам, нужным для выполнения архитектурных решений (на этот «технический/архитектурный долг» в среднем планируют до 20% ресурса разработчиков, задача только в том, чтобы у них обязательно было время выполнять эти планы).

• Оргдизайнер как разработчик организации должен спроектировать организацию: ровно вот те команды, которые будут выполнять работы по созданию системы, но и предусмотреть архитекторов, и визионеров, а ещё разработчиков и эксплуататоров внутреннего «конвейера» (platform engineers/DevOps). То есть он должен предложить организационную структуру (модель иерархической организационной структуры с делением организации на оргзвенья называется органиграмма), в которой будут для оргзвеньев отражены играемые ими организационные роли, о которых мы говорим — то есть транзитом он должен учесть предложения разработчиков (ибо там определяется предметное содержание модулей, важное для определения требуемых ролей — «для электронных модулей нужна роль электронщика») и архитектора целевой системы (сама нарезка на модули и принципы этой нарезки, помним о законе Конвея и обратном манёвре Конвея), чтобы отразить команды разработчиков на органиграмме, назначив им соответствующие функции в разработке. Всё ещё запутанней, ибо оргдизайнер в органиграмме должен отразить и менеджерские службы, в том числе отразить себя, а ещё тех, кто организует самого оргдизайнера, выполняющего практику оргдизайна. Оргпроектировщик/оргдизайнер тоже не «самозарождается» в организации, а его кто-то проектирует, а затем он сам будет объектом лидерства со стороны разных подролей организатора организаторов инженерных команд целевого проекта, цепочки создания обычно длинны. Ещё раз вернитесь к системной схеме инженерного проекта, представьте себе, что в организации множество проектов, которые делят между собой ресурсы — и вот эту задачу создания организационной структуры и решают архитектор организации и оргдизайнеры (которые занимаются вообще-то проектированием более-менее автономных модулей общей организационной структуры, определённых орг-архитектором). Довольно верный признак того, что вопрос должен решаться оргдизайнером — это звучащая в разговоре лексика каких-то отдельных специфических предметных практик, которыми занимается организация. Организация учится чему-то новому, для этого нужно запроектировать оргструктуру, которая будет поддерживать эту новую практику, поэтому «новая практика» тут будет ключевым. Архитектор же будет говорить самые общие слова, которые обычно говорят архитекторы: скорость, надёжность, безопасность, гибкость, масштабируемость, взаимонезависимость и т.д., только по отношению к организации, а не к целевой системе.

Упражнение

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

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

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

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

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

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

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

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

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

• Органиграмма (структура деления организации на оргзвенья, обычно неполная, ибо в ней не показываются обычно всякие научно-технические советы, комиссии, рабочие группы проекта и прочие реальные оргзвенья, но только структура «мест найма» в части официального учёта занятых — и нужны способы учёта полной оргструктуры. Но тут проблема: у генерального директора как единоличного исполнительного органа может не быть полномочий управлять каким-нибудь советом, поэтому органиграмма не может указать этот совет в структуре подчинения! Это не означает, что такого оргзвена в организации нет, и что это оргзвено не выполняет каких-то работ по каким-то практикам).

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

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

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

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

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

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

• Работники предприятия должны разбираться в экземплярах предметной области, заполняя таблички. Типы этих экземпляров (метаС-модель) должны быть прописаны в названиях колонок таблички.

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

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

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

Выбор оргмоделера

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

Для документирования используются моделеры. Вы можете сделать моделер даже из воздуха (указав на места в пространстве, где ваши собеседники будут помнить, какие объекты каких типов вы ассоциируете с этими местами в пространстве — полностью эквивалентно «пусть S — это путь, а V — это скорость», только запись не буквами на бумаге, а указанием на место в пространстве), вы можете сделать моделер из своей руки (указывая место на руке, где ваши собеседники будут помнить, какие объекты каких типов вы ассоциируете с этими «именами»), и это много лучше, чем когда вы держите модель только «в чертогах разума». Это может пригодиться в разговоре «на бегу». Но для нормальной работы у вас должно быть управление конфигурацией, а вот этого таким моделированием не добьёшься: нужно использовать компьютерное моделирование (даже не бумажное!):

• Вам нужно уменьшить число ошибок моделирования. Если у вас в модели больше пяти объектов, то человеческая память будет крайне ненадёжна. Если пройдёт всего день с момента моделирования, вы уже можете вспомнить очень немного (кривые забывания¹ работают даже в случае работ по проектированию, не только при обучении).

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

• Вам нужно легко вносить изменения, «непрерывное всё»: оргпроект будет непрерывно меняться. Компьютерные модели легко менять, модели на мокром песке и на бумаге менять трудно. В том числе вам нужно будет менять модели дистантно, поэтому стена со стикерами тоже не подойдёт, придётся всё равно сдублировать результаты моделирования стикерами на стене в компьютер, чтобы иметь возможность корректировать модель удалённо. Так что должен быть моделер, доступный через интернет.

• Вам нужно управлять конфигурацией: какая из многочисленных версий проекта/design (это набор самых разных моделей, которые тоже имеют версии!) будет воплощаться, должно быть точно известно в любой момент. Исправления, внесённые не в ту версию — не исправления. Оргизменения, сделанные по «не той версии, извините» — это будет вред, а не развитие. Это означает, что должен быть репозиторий моделей, в котором поддерживается версионирование (и тут проблема даже с моделями в отличных универсальных моделерах типа coda.io или notion.so).

Почему делается такой упор на табличное моделирование? Моделирование текстом получается совсем не наглядным, ибо очень трудно указывать типы и очень трудно показывать много похожих (например, одного типа) сущностей. Таблички тут представляют вариант много лучше, хотя у них есть определённые недостатки — но эти недостатки с лихвой перекрываются удобным визуальным представлением и доступными моделерами (редакторы таблиц повсеместны, к тому же большинство современных баз данных реляционные, то есть по факту «табличные»). Многочисленные попытки наладить редактирование в диаграммных представлениях («квадратики и стрелочки»/box and arrows) успешны только там, где удаётся выделить огромные (как выяснилось позже) совершенно ненужные ресурсы: это моделирование особо плохо в части непрерывных изменений. Ещё как-то удаётся один раз отмоделировать оргмодели диаграммами, но вот потом не удаётся постоянно корректировать эти модели и удерживать управление конфигурацией. По факту все эти «диаграммные моделеры» (иногда их называют «архитектурные моделеры», иногда «моделеры архитектуры предприятия») имеют альтернативное текстовое представление (например, XML или JSON документы, которые могут редактировать профессионалы-программисты) или табличное представление (которое могут редактировать «продвинутые пользователи»), и оказывается, что основное время модельеры-оргдизайнеры проводят в этих представлениях, а не в визуальном редакторе диаграмм. Поэтому проще оказалось сразу использовать табличные представления.

Но и тут есть несколько вариантов: электронные таблицы (например, MS Excel, Airtable) и базы данных (например, PostrgeSQL, MySQL), а также лет пять назад появившиеся универсальные редакторы, сочетающие в себе свойства редакторов текста с возможностью вёрстки, электронных таблиц и баз данных (coda.io, notion.so). И тут надо указать, что в рамках практики lean в большинстве случаев оказалось не нужным разрабатывать отдельные корпоративные приложения для поддержки новых практик работы, достаточно было использовать LowCode средства этих моделеров, если речь не идёт о сотнях и тысячах однотипных работ, для которых этих средств LowCode универсальных моделеров не хватает (обычно там проблемы масштабирования для большого числа операций: 1. лицензионная политика, делающая цену использования запредельно высокой, и своё приложение написать оказывается дешевле, 2. Отсутствие управления конфигурацией и версионирования, что заставляет прибегать к сложным ухищрениям для репликации данных где-то ещё, и своё приложение оказывается в конечном итоге проще, 3. Низкая производительность, ибо речь идёт об универсальном моделере, который платит за универсальность низкой скоростью, 4. Проблемы с безопасностью и защитой, ибо в собственных приложениях проще прописать доступ разных ролей к разной информации. Все эти проблемы, впрочем, можно в существенной мере убрать, если за универсальными моделерами оставить роль «пользовательского интерфейса», а информацию хранить в корпоративных базах данных, обеспечив какую-то интеграцию между моделером и хранилищем информации).

Оргдизайнеры помогают экспертам (владеющим метаУ-моделями и метаС-моделями) разработать таблички в универсальных моделерах, разъяснения к этим табличкам писать текстом, а дальше «автоматизацию» обеспечивать или простейшим LowCode программированием «на кнопках» (вроде как послать кому-нибудь письмо, что «Сегодня вы появились в табличке «Проект мытья полов» в колонке «Исполнитель»»), или же путём такой же необременительной в части программирования связи с другими корпоративными информационными системами. То есть оргпроекты в ходе моделирования становятся исполняемыми/actionable, в табличках могут быть кнопки. Это общий ход: редактор Lists (редактор списков, которые выражаются в табличной форме) в MS Teams прежде всего задействуется как issue tracker.

Что надо добавить в issue tracker, чтобы он отражал оргмодель? Не так много, ибо отслеживание самой работы (issue, потом task, потом notice) в issue tracker уже есть: указание на «собственника кейса/issue», обычно это сотрудник, который открыл кейс, и он же проверит, можно ли кейс закрыть. Как всегда с людьми, тут нужно знать и исполнителя роли, и роль, и должность, а часто ещё и понимать, где именно в организации находится эта должность, в каком оргзвене её искать, к какому начальнику обращаться, если встретится неожиданное «внеролевое» поведение и нужно будет его корректировать.

Если речь идёт о новом шаблоне кейса, то это и есть описание новой практики. Вот это и есть работа оргразвития: оргдизайнер сделает шаблон кейса, а лидер потом наладит работу по практике, описанной в шаблоне кейса. Так что оргдизайнер в качестве моделера часто использует сразу issue tracker как систему моделирования. Не надо одну и ту же модель отражать в issue tracker, в специальной системе моделирования оргдизайнера, в слайдах презентации для начальства красивыми картинками, в виде регламентов для сотрудников (которые никто не будет читать) и т.д. Меньше дублирования — меньше вероятности развала конфигурации.

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

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

!!! Какое организационное решение самое важное в предприятии?

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

--- централизованное или децентрализованное управление ### Нет, это не самое главное решение, хотя от него в фирме многое зависит — это архитектурное решение по архитектурному стилю. Более важным является то, какое оргзвено какие практики выполняет, концепция организации.

+++ кто что делает ### Да, это одна из формулировок концепции организации: какие конструктивные единицы (кто, оргзвенья) какие функциональные единицы, оргроли (что делают, выполняют какие деятельностные практики)

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

--- кто какие имеет полномочия по распоряжению трудом и капиталом ### Нет, знание о полномочиях не объясняет того, чем будут заняты (какие практики будут выполнять) люди с полномочиями. Важнейшим решением является основное: модульный синтез (организационная структура предприятия: разбиение на оргзвенья — как раз органиграмма, кто какие имеет полномочия), но всё-таки предварённый функциональным анализом (функциональная структура, занятая выполнением практик: разбиение на оргроли).

!!! Концепция организации должна быть публичной?

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

+++ Да, это главный способ донести до людей ответ на вопрос «кто что делает» ### Да, концепция организации — это основной рабочий продукт для коммуникации по поводу того, как устроена организация.

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

!!! Отметьте функциональные части предприятия:

+++ организационные роли, которые играются организационными звеньями ### Да, именно так, оргроли — это функциональные части организации. А организационные звенья — это конструктивные части/модули предприятия, они играют организационные роли.

--- практики, которые выполняют оргроли ### Нет, практики — это поведение организационной роли, а функциональной частью является сама оргроль.

--- подразделение предприятия ### Нет, подразделение — это один из видов организационных звеньев/модулей, конструктивных частей.

--- люди, работающие на предприятии ### Нет, люди — это оргзвенья (минимальное оргзвено состоит из одного человека, а то и части личности), это конструктивные элементы.

--- сервис ### Нет, сервис — это поведение оргзвена, конструктивной части предприятия, а не сама конструктивная часть.

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

!!! Отметьте конструктивные части предприятия

--- организационные роли, которые играются организационными звеньями ### Нет, организационные роли — это функциональные части.

--- практики, которые выполняют оргроли ### Нет, практики — это поведение организационной роли, то есть практики — это поведение функциональной части предприятия, и даже не функциональная часть.

+++ подразделение предприятия ### Да, подразделение — это один из видов организационных звеньев/модулей, конструктивных частей.

+++ люди, работающие на предприятии ### Да, люди — это оргзвенья (минимальное оргзвено состоит из одного человека, а то и части личности), это конструктивные элементы.

--- оргвозможности/capabilities ### Нет, это оргроли, для выполнения которых уже есть оргзвенья, имеющие полномочия и ресурсы выполнять практики этих оргролей — то есть функциональные части предприятия.

--- сервис ### Нет, сервис — это поведение оргзвена, поведение конструктивной части предприятия, а не сама конструктивная часть.

Конструкция организации и координация работ

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

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

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

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

Обсуждение конструкции (структуры оргзвеньев и их полномочий) предприятия, абстрагированное от обсуждения функциональной специфики, наиболее подробно даётся в книге Ian Dietz и Hans Mulder «Enterprise Ontology», 2021:

«Онтология предприятия» — это важные в предприятии объекты, о которых легко договориться. Авторы книги справедливо утверждают, что проще всего в предприятии обнаружить оргзвенья, которые они называют «акторами» (actors), и эти акторы заказывают работы (оказание сервисов) друг у друга. Если какое-то оргзвено считает, что работу у него запрашивают неправомерно, происходит «выход в дискурс», работа прекращается, начинается обсуждение того, кто прав, кто виноват (если в пиццерии заказать женские босоножки, то работа прекратится и начнётся разговор о том, кто пришёл, кого попросил, почему это нельзя сделать — тот самый «дискурс»). Главное, что книга предлагает кроме традиционного для операционного менеджмента деления на время паузы (wait time) и время обработки (touch time) вводить другое различение, тоже влияющее на скорость работы: это coordination time (время договаривания о работах, связанных с полномочиями) и production time (собственно время обработки).

«Договаривание» или по обсуждаемой книге Dietz и Mulder (общее название представленной там методологии — DEMO) «координация» относится к таким речевым актам/действиям, как просьбы, обещания, предъявления выполненной работы, акцепты результатов, отказы. Речевые акты тут упомянуты не случайно, ибо DEMO основывается на теории речевых актов. Речевые акты — это такие высказывания, которые порождают действия в реальном мире (то есть как раз просьбы, обещания, предъявления выполненной работы, акцепты результатов, отказы). В частности, делается утверждение, что надо специально договариваться о моментах, когда считаем работу выполненной (то есть кейс закрытым), и основные события в мире координации должны происходить по явным речевым актам, то есть «не сказал/не написал — не считаем, что что-нибудь произошло в обработке». При этом можно договариваться, что «если положил результат вот сюда, это означает, что я закончил работать и выдал результат по цепочке дальше», но если договорённости не было — окончание работы считаем не произошедшим, пока об этом исполнитель не скажет явно, а заказчик не получит это сообщение. Основная ошибка оргдизайнера — это пропуск стадий координации и пропуск того, что будет происходить, если на любой из стадий будет отказано в продолжении (например, что будет происходить, если поручение будет выдано, но работа не будет взята, то есть обещание выполнить работу не будет получено):

• Осознание нужности инициатором трансакции/заказчиком/поручителем какой-то работы/кейса

• Поручение/заказ/просьба выполнения работы/кейса (предъявление потенциальному исполнителю). Работа тут поручена, но не взята!

• Обещание исполнителя выполнить работу (явный приём к исполнению)

• Выполнение работы (это собственно обработка/производство/работа/труд)

• Объявление о том, что работа выполнена. Работа тут выполнена, но не принята!

• Объявление о принятии работы

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

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

Кажется, что вопрос о том, кто заказчик работ, всегда ясный. Нет. Например, кто является заказчиком работ по созданию корпоративного софта оформления командировок (кейсы создания «деловых поездок»)? У подразделения/оргзвена программистов возникает ложное впечатление, что заказчик тут бухгалтерия — это оформление нужно вроде как бухгалтерии. После чего подразделение программистов защищает интересы бухгалтерии, воюя с тысячами «пользователей системы» (людьми, которым нужны деловые поездки). Заставляем программистов точнее определить свою целевую систему: оказывается, деловые поездки нужны инженерной службе предприятия, и помогать нужно командированным, а не бухгалтерии! После этого оргзвено программистов воюет на стороне нескольких тысяч человек с несколькими сотрудниками бухгалтерии и без труда выигрывает, сотрудники получают отличный сервис оформления деловых поездок, удобный им, хотя и не такой удобный для бухгалтерии (а бухгалтерии пришлось изобретать схему, мы об этой работе юристов, финансистов и прочих администраторов уже говорили — их задача быть на стороне организации, а не на стороне разных надзоров). Так что оргдизайнеры определяют, какие именно типовые кейсы должны быть поддержаны корпоративными информационными системами (а в современной ситуации оргдизайнеры часто будут сотрудниками айтишных подразделений, хотя их можно найти практически везде — от отделов «аналитиков», до «служб обеспечения качества»).

TEST

!!! Что говорит DEMO о работах, которые делаются пять минут, но от запроса до приёмки которых проходит пять дней, при этом нет недостатка в ресурсах для выполнения работы?

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

+++ продукционный акт может быть коротким, а время съедают координационные акты ### Да, именно так: пять минут выполнение дела, а ожидания согласований занимает пять дней.

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

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

!!! Пётр сделал 3D-модель, но Анна страшно ругалась, что он ей не сказал ещё три дня назад, что модель готова. Пётр считает, что раз Анна заинтересована в этой модели, то она и должна узнавать, готова модель, или ещё не готова: если три дня она не забирала готовую 3D-модель, то эта модель ей не так уж и нужна, поэтому ругаться должен сам Пётр: он поставил работу Анны в приоритет, а мог бы спокойно отложить её на те самые три дня, ничего не изменилось бы. Кто прав?

+++ Анна ### Да, в цикле запрос-обещание-(изготовление)-сдача-приёмка исполнитель обязан сообщить о том, что работа сделана, этот координационный факт нельзя получить другим образом. Пётр должен был известить Анну, что он сдаёт работу (а Анна затем должна известить Петра, что она приняла работу).

--- Пётр ### Нет, Пётр выполнил продукционный акт (сделал 3D модель), но не выполнил связанный с этим координационный акт: не сообщил о том, что работа им сдаётся — исполнитель обязан сообщать о том, что работа им обещана, и о том, что она им сделана/сдаётся. Инициатор работы должен объявлять факт, что он запрашивает работу, и что работа принята.

Упражнение

Представьте в виде таблицы основное организационное решение вашей компании: каким образом организационные роли исполняются оргзвеньями/подразделениями вашей компании (или более мелкие подразделения вашего более крупного подразделения, если вы слишком далеки от принятия решений по всей компании в целом).

Модель органиграммы

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

• Руководитель — один из сотрудников, но «сотрудниками» у него могут быть и другие оргзвенья

• Если нет явного подначального подразделения «оргзвена», то используйте слово «направление» или «служба» и тем самым создайте его!

Вот пример для «конкретной организации» (КонкОрг):

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

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

Вот примерная «логическая» (в реальности это «непрерывная разработка», и все действия итеративны) последовательность работ оргдизайнера:

• Начинаем с основных изменяемых объектов работы (прежде всего — целевой системы!). Определяем список кейсов, готовим шаблоны этих кейсов (с экспертами предметной области смотрим на SoTA практики, учитываем ресурсы, прописываем чеклисты для определения моментов перехода предмета кейса по графу его состояний и т.д.). Делаем подкейсы (разбиения) на столько уровней, сколько представляется удобным — понимая, что на самом верхнем уровне принимать решения по кейсам нижнего уровня нельзя, там будут свои оргдизайнеры. Как-то раскладываем эти кейсы по оргролям. Это всё будет функциональная декомпозиция организации.

• Прописываем органиграмму: определяем оргзвенья, которые будут выполнять прописанные роли — учитываем при этом решения орг-архитектора.

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

• Определяем, что ещё будет надо (помещения, оборудование, разделы бюджета и т.д.), доводим концепцию предприятия до полноценного орг-проекта/design, готового к воплощению.

Итого в практике оргдизайна помните:

• Оргдизайнер — это роль, оргдизайнеров много, часто эту роль для своего звена выполняет какой-нибудь начальник оргзвена, а свободу его творчества ограничивает орг-архитектор, действующий в масштабах предприятия (архитектор предприятия/enterprise architect).

• Средства оргпроектирования/моделирования (моделеры) для оргдизайнера не так уж важны. Но стремиться нужно к моделеру, который даст вам исполняемую/actionable оргмодель. Важна не форма модели, а её содержание и то, насколько люди готовы следовать этой модели (записать вы можете любую фантастику в самом лучшем и дорогом моделере, но люди будут делать что-то совсем другое, что им кажется более полезным, в том числе ничего не делать. Содержание сначала, формат моделирования — потом).

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

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

• Не забывайте об управлении конфигурацией.

Упражнение

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

Задания

Поставьте отметку о выполнении.

1. Прочитана книга Ian Dietz и Hans Mulder «Enterprise Ontology», 2021.

2. Опубликован пост, описывающий контринтуитивные идеи книги «Enterprise Ontology».

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

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

5. Концепция организации доступна для ваших коллег, они могут использовать её в организации своей деятельности.

6. Опубликовано эссе с вашими мыслями по поводу результатов проведённой работы оргдизайнера.