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

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

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

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

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

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

• Проекты организационного совершенствования не связаны с освоением новых практик, но связаны главным образом с решением задач операционного менеджмента: это оптимизации прохода и оптимизации в администрировании. Основное в них то, что людей не нужно учить новым понятиям, потому как не меняются практики, хотя могут меняться технологии. Processofongoing****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% времени (в среднем) на выплаты орг-архитектурного долга (работы по реализации орг-архитектурных решений: правильной нарезки организации на оргзвенья, реализацию правильных способов взаимодействия оргзвеньев).