Skip to content

Модель оргразвития

Ещё одна модель, используемая для стратегирования, условно может быть названа моделью оргразвития**😗* какие новые практики работы, основанные на каких принципах и упомянутых в них объектах (дисциплина практики) нужно освоить организации, чтобы в изменяющихся условиях у неё появились новые оргвозможности. Одна из самых наработанных практик подобного моделирования стратегии была разработана Eli Goldratt в 2002 году, она получила название strategy and tactic tree (SnT)[1] и вошла как отдельный процесс в состав TOC thinking processes. Сам Eli Goldratt подходил к типизации предложенной им метаУ-модели не слишком строго. Он придумал интересный ход: предложил типовые модели стратегии развития для машиностроительного производства под заказ и розничной торговли со складами. Стратегия для него — это ответ на вопрос «какой результат хотим получить», а тактика — это «какой практикой хотим получить этот результат». Мы под стратегией понимаем набор моделей (а не результат применения практики), а слова «тактика» у нас вообще нет (табуировано, ибо если про стратегию ещё хоть как-то можно договариваться, то про тактику договариваться обычно бесполезно, все понимают под ней что-то своё), так что мы будем «голдраттовскую стратегию» называть «целевым состоянием мира» (в 4D — это важно! Доводить описания до изменений в физическом мире!), а приводящее к этому состоянию мира действие будем называть целевой практикой. По-другому мы переводим и другие термины предложенной Eli Goldratt метаУ-модели, чтобы меньше путаться. Вот эта метаУ-модель в виде диаграммы:

В этом способе моделирования ключевым является абсолютно традиционный для инженерии ход на отделение (1) результата работ от (3) метода его получения, функционального описания от аффордансов конструктивного описания, хотя тут есть тонкости: функциональное описание дано как состояние мира, в котором выполнимы необходимые целевые функции, а аффордансы даны как оргвозможности в виде сервисов, способных выполнить какие-то оргпрактики. Верхний уровень такой стратегии в части описания будущего мира, в котором стратегия реализована — это vision/видение/вижн организации. А верхний уровень практики, которая должна быть реализована, чтобы получить целевое состояние мира — это миссия/mission. «Найдётся всё::vision, так как «будем программировать самый крутой поисковик в интернете»::mission». Главное — это различение практики и её результатов, не такая тривиальная задача для очень и очень многих не-инженеров. В этом варианте моделирования категорически запрещается формулировать практику через глаголы «получить», «сделать» и прочие подобные способы. Помним: если у вас нет понимания affordances**, то есть концепции системы, в проект нельзя ввязываться!** Вы легко себя обманете, если напишете «мир во всём мире»::vision, а дальше «обеспечить/получить/сделать/воплотить мир во всём мире»::mission. Нет, вам придётся прямо назвать практику какого-то domain, которой вы хотите это сделать, ибо ваше оргразвитие будет реализацией этой практики. Если практика содержательно непонятна, то стратегия просто не будет воплощаться — утопиями никто не занимается.

Защита от утопий в этом методе моделирования/viewpoint/meta-model двойная:

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

Дальше вы делаете предположение о том, что эта стратегия начинает выполняться, и в явном виде выписываете, что перестаёт выполняться в организации, что не соответствует этой стратегии, (5) — это практики-жертвы. Вы честно описываете последствия принятия стратегии.

Дальше вы декомпозируете состояние мира и практику его получения на части, которые достаточны для реализации стратегии (6) — и для каждой части выполняете все нужные описания, и так где-то три уровня, пока состояния мира и приводящие к ним практики не будут абсолютно очевидными и не будут требовать каких-то обоснований. Конечно, нужно позаботиться о полноте этих практик. Обычно полезен такой приём: «много было организаций, которые реализовывали видение X практикой Y, но у них не получилось. Мы понимаем трудности и риски, поэтому нам будут нужны вот такие особенности в их реализации: X1-Y1, X2-Y2, и т.д.» (всё, конечно, с обоснованиями и выписыванием «жертв» того, что делаем всё теперь по-новому, а по-старому не делаем).

Если посмотреть на важность обоснований в этой метаУ-модели организационного развития, то можно дать ей название strategy case/«стратегическое дело», по аналогии с assurance case/«дело инженерного обоснования». Помним материал по инженерным обоснованиям из курсе «Системной инженерии»: папка «Дело №___» заводится в первый день существования инженерного проекта, и ведётся непрерывно до момента окончания проекта. То же самое можно сказать про организационное развитие, которое является таким же инженерным проектом, требующим обоснования. Такого сорта модель может быть документирована как «стратегическое дело», представляющее собой актуальное состояние обоснованных видения и миссии организации, а также обоснованную их декомпозицию.

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

Это только маленький кусочек, выполненный в моделере FlyingLogic. Вот верхушка этой части стратегии «крупным планом»:

Цель тут — связка с остальными элементами стратегии, стратегия тут была весьма детальной и включала много элементов оргразвития для министерства транспорта области. Типы мета-модели были названы по-другому: «результат» тут состояние мира в результате применения практики, «действие» — это целевая практика, «обстоятельства» это обоснование того, почему хотим такого состояния мира, а «аргументы» (rationale, помним рассказ про обоснования — в ходе выполнения стратегии там должны бы появиться и свидетельства/evidence, а «результат» будет пониматься как претензия/claim) — это почему предложенная практика («действие») принесёт желаемое состояние физического мира («результат»). Контраргумент — это обоснование того, что требуется пояснение в реализации какой-то части практики, ибо много что может пойти не так.

Пример от самого Eli Goldratt — это колода слайдов, где один слайд представляет собой узел дерева[3]:

Nessesary assumptions — это обоснование целевого состояния мира, parallel assumptions — это обоснование действий («параллельные» — это «параллельные две стороны одной медали», как пояснил Eli Goldratt в одном из своих интервью, мы уже говорили, что язык у него довольно поэтичен), sufficient assumption это как раз выход на декомпозицию. И ещё заметим, что сам Eli Goldratt очень «творчески» относился к типизации, и не очень точно соблюдал предложенные им же самим типы. Его примеры работают с типизацией так же творчески, как предлагался термин «параллельный» на основе выражения «две стороны одной медали».

Ещё одна интересная параллель этой модели с материалом «Системной инженерии» — это похожесть стратегии на язык паттернов/pattern language. Стратегия задаёт паттерн деятельности компании, поэтому язык паттернов вполне может быть той формой, в которой излагается эта модель:

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

Понятно, что такая «слайдовая» форма моделирования с табличкой на каждом слайде довольно легко представима в универсальных моделерах (типа notion.so, coda.io и т.д.).


  1. Много материалов в https://www.tocico.org/page/strat_tact_portal, перевод варианта методики 2006 года на русский — http://www.deming.ru/TehnUpr/PostrDerStrTak.htm ↩︎

  2. http://techinvestlab.ru/files/394450/Org_Preobr.pdf ↩︎

  3. http://www.slideshare.net/utkanuluay/rapid-replenishment-st-tree ↩︎