Управление организационными паттернами
Текст для "общеметодологов": какую нужно писать книжку
Этот пост я пишу для "общеметодологов" (в смысле http://ailev.livejournal.com/480843.html -- "общеметодологи: те, кто фиксирует средства выражения оргонтологий и оргмодели, объясняет про различия между оргонтологией и оргмоделью и т.д.. Сотрудникам и администраторам на эту тему мало что нужно знать, а методологам организации нужно воспринять результаты общеметодологической работы как основания для их работы"). В который уже раз речь идет о "нужно ли писать книгу", или о форме отчуждения организационного знания. Повторю ранее рассматривавшиеся варианты:
-- написать волнительный бизнес-роман (как это сделал Голдратт или Том ДеМарко);
-- написать пламенную "монографию" (как делают большинство бизнес-гуру);
-- сделать онлайн-гипертекст (wiki) типа "энциклопедии", не предусматривающий никакого нарратива;
-- написать набор коротких эссе (как я поминал 22 мая в посте "Книжный формат: рецептурный справочник" http://ailev.livejournal.com/485637.html). Этот недавний пост заканчивается фразой "минимализм рулит". И я склонялся именно к этому варианту.
Языки/системы паттернов
И тут я вспомнил про то, чем развлекались в самой-самой первой wiki: изобретатель WikiWikiWeb Ward Cunningham (http://en.wikipedia.org/wiki/Ward_Cunningham), активный деятель все той же smalltalk-тусовки, описывал сотоварищи в первой на свете wiki дизайн-паттерны бурно развивающегося объект-ориентированного подхода и орг-паттерны рождающегося экстремального программирования. Ибо "процедурный стиль мышления" существенно отличался от "объект-ориентированного стиля мышления", описать эти различия для широкой публики было непонятно как. И методы экстремального программирования отличались от привычных водопадных моделей разработки не меньше. Мне подумалось, что ситуация в софтверной отрасли на тот момент была такая же, как при сегодняшней попытке перехода от "мира себестоимости" в "мир валовой прибыли" при внедрении теории ограничений. Как тогда все тогда писали на языке Си или дельфийском паскале, кроме очень узкой смоллтоковской тусовки, распространяющей идеи объект-ориентированного подхода и agile-методов -- и при попытках использовать новое знание использовалось не столько новые принципы работы, сколько новые слова -- а делали все "процедурно" и "по плану", так и сегодня книжку Голдрата "Цель" все прочли, слова используют уже все новые, а делают все по-старому, опираясь на "рентабельность". Тогда (как и мне сейчас) нужен был формат, в котором быстро и эффективно передается know-how -- способ, в котором можно пытаться передать стиль мышления.
Этим форматом на тот момент (середина 90-х) оказались "языки паттернов" ("языки", ибо паттерны тут уподобляются словам: они используются в самых разных сочетаниях, как слова в предложениях), также называемые "системами паттернов". Знакомство с теми или иными проверенными решениями типовых проблем объект-ориентированного стиля в написании программ (прежде всего архитектурными паттернами для самых общих решений, типа "клиент-сервер", или дизайн-паттернами типа появившегося в Смоллтоке Model-View-Controller) стало тем способом, которым люди для себя открывали отличие объект-ориентированного стиля программирования от процедурного стиля. Книжка отмоделированных (в смысле НЛП-моделирования, т.е. "увиденных зорким глазом повторяющихся в жизни образцов", паттернов-по-Бейтсону -- discovery, а не invent) "рецептов успеха" aka best practices, причем книга гипертекстовая, с предписанной структурой, как правило еще и коллективно написанная -- вот каким оказался способ передачи знания в тех случаях, когда все понятия уже есть, а как ими пользоваться никто не знает, кроме нескольких умельцев. Берем работу умельцев, пытаемся обнаружить в этой работе повторения -- паттерны, которые ведут к успеху. Моделирование (как в НЛП) в чистом виде, результат моделирования оформляется в специальной письменной форме. Паттерны всегда идут в системе из десятков или даже сотен паттернов, а паттерн из системы выглядит примерно так (только обычно вдумчивое описание одного паттерна занимает десяток страниц):Система паттернов: Теория ограничений
Нарратив: ... Каждая организация должна иметь Цель. Эта Цель должна быть измеримой, и система оценки работы (и тем самым мотивация работников) должна быть привязана к ее достижению. ... Выпуск целевого продукта организации измеряется Проходом (Throughput), измеряемым в выпускаемом количестве целевого продукта за период. Так, целевым продуктом фирмы являются деньги, а выпуск денег организацией измеряется как валовая прибыль (throughput) за период ...
...
Название: Цель
Ситуация: высшее руководство пытается добиться эффективности совместной работы нескольких подразделений
Проблема: подразделения грызутся между собой, каждое подразделение "тянет одеяло на себя", систематически страдает "общее дело"
Сила-1: руководитель каждого ругающегося подразделения говорит, что действует исключительно в меру своих полномочий и отвечает за вверенный ему участок. Все показатели каждого из них в полном порядке: формально никто из них уступить друг другу не может без ухудшения своих показателей.
Сила-2: высшее руководство понимает, что какому-то подразделению "в интересах общего дела" придется уступить -- но каждый раз это оказывается разное подразделение, и руководители "стоят до последнего", отстаивая свои интересы. В итоге высшее руководство вынуждено решать каждый вопрос, затрагивающий два подразделения и становится бутылочным горлышком. К тому же высшие руководители сами ставили конфликтующим руководителям показатели и не могут их наказывать за рвение по их достижению.
Поэтому: Высшие руководители должны объявить общую для конфликтующих подразделений Цель (потенциально -- общую для всех подразделений организации Цель, цель Организации), установить показатели достижения этой Цели организацией и потребовать от всех руководителей действий, двигающих организацию к ее Цели (т.е. потребовать действий по достижению общеорганизационных показателей). Любой конфликт подразделений решается тем, что проверяется действие каждого подразделения на достижение показателей достижения общей Цели, а не на достижения отвязанных от общеорганизационной Цели показателей этих подразделений.
Примеры использования: организации, которые используют Теорию ограничений Голдратта
Связанные паттерны: Система показателей достижения цели, система мотивации
Предполагается, что в разных паттернах описываются разные "силы" ("инкапсуляция сил"), что и делает паттерны относительно независимыми друг от друга.
Создание и публикация систем паттернов как исследовательско-педагогический прием (эти паттерны сначала нужно открыть, назвать и описать -- это исследование, а затем использовать для обучения новичков "хорошему стилю", не поддающемуся строгому теоретическому представлению) распространился теми же смоллтоковцами-экстремальщиками-викистами и на смежные дисциплины. Кроме всевозможных систем паттернов ОО-архитектуры и дизайна (software patterns), паттернов agile-методов разработки (organizational patterns) появилсь также системы педагогических паттернов, и даже юмор типа системы паттернов свиданий, написанных специально для программистов. Подробности движения по разработке систем паттернов (pattern movement) см. в http://ailev.livejournal.com/487783.html).
Система паттернов:
-- нацелена на содействие "сдвигу в мозгах", это образовательная практика прежде всего. Так что паттерны вполне могут быть инструментом методологов организации.
-- включает обычно две части: 1. нарратив/пролог/учебник, задающий целостность системы, показывающей связь контекстов и используемых в них паттернов, часто это около 20% (http://www.theserverside.com/news/thread.tss?thread_id=28365) от всего текста 2. "справочник" по отдельным паттернам, подробно их описывающий -- 80% текста.
-- это сборник удачных типовых решений для типовых затыков, получаемых при попытках деятельности. Каждый паттерн может быть выражен сверхкратко (thumbnail для паттерна -- это фраза типа "Акционер у вас странный -- ориентируйтесь на "идеального акционера"" или "Достали непродуктивные кофликты подразделений -- сделайте критерием их разрешения ориентацию на достижение ими глобального максимума (показателей Цели)") или подробно разжеван на паре десятков страниц.
-- это "сократический метод" в специально организованной форме, каждый раздел формы паттерна заставляет отвечать на ее специфический вопрос, задавая постепенное разворачивание содержания.
-- это способ структурирования know-how для слабо проработанных предметных областей. Паттерны получают имена, и дальше можно обсуждать их применимость в той или иной ситуации.
-- это способ рефлексии деятельности (идентификация типовых затыков и удачных типовых решений, в нашем случае это инструмент общения методологов организации и организаторов).
Эволюционный дизайн организации: рефакторинг согласно паттернам
С точки зрения деятельностного подхода, мы хотим влиять на то, как устроены организации (системы эффективного разделения труда), мы хотим изменять эти системы, а не просто глазеть на них и умствовать по этому поводу. С позиции организатора бесперспективно рассматривать "организационную структуру и функции" на данный момент времени, а осмысленно только рассматривать предполагаемые изменения в организации (маржинальный подход, http://ailev.livejournal.com/449217.html) -- как намеренно вводимые организатором-деятелем, так и возникающие помимо его желаний воли.
Это приводит нас к принципу evolutionary design (http://www.martinfowler.com/articles/designDead.html, который активно используется в eXtreme programming). В отличие от planned design (где организаторы думают о "проектировании организации" как целого, а не о том, как бы что организовать -- что подразумевает какую-то последовательность реализации замыслов), в эволюционном оргдизайне конкретные дизайн-решения фокусируются вокруг решения конкретных проблем, а не одномоментно определяют все аспекты организации. Это как нельзя лучше подходит к процессу постоянных организационных изменений, задаваемых теорией ограничений, оргфилософией agile manufacturing и многими другими интересующими нас системами.
По факту организационное развитие должно сопровождаться безжалостным рефакторингом (http://en.wikipedia.org/wiki/Refactoring -- в нашем случае это соответствует реорганизации, сохраняющей внешнее поведение организации, но облегчающей дальнейшее развитие). А вот осмысленный рефакторинг должен направляться паттернами -- об этом говорят работы классиков рефакторинга. Осмысленная реорганизация тоже должна направляться паттернами. Система организационных паттернов структурирует идеи о том, что можно было бы сделать в плане улучшения организации на каждом отдельном шаге.
Управление организационными паттернами
Сама предметная область "языков паттернов" ужасна в своей терминологии (занимались этим яйцеголовые архитекторы и программисты, простым людям этого с наскоку не понять), поэтому нам придется менять терминологию. Но менять сильно мы ее не будем: ибо
-- слово "паттерн" пока в менеджерских науках не очень занято, и поэтому для большинства людей не будет тащить за собой разные другие смыслы
-- хочется оставить параллель между организовыванием и программированием, и сохранить преемственность между этими двумя видами образования. ОО-дизайн, основанный на паттернах и оргдизайн, основанный на паттернах -- очень интересная форма образования.
Тут нужно вспомнить, что я писал про "управление идеями" (http://ailev.livejournal.com/484203.html). Ошибочно может показаться, что слова "система паттернов" и "бизнес-идея" взаимозаменяемы. Действительно, "языки организационных паттернов" и "управление бизнес-идеями" весьма похожи -- но обращают внимание на разные стороны реальности.
В "управлении идеями" акцентируется, что хорошие бизнес-идеи придумываются -- а затем описанные в них методы работы постепенными становятся best practices. В "языках паттернов" прежде всего ищутся паттерны -- общее в уже имеющейся практике, часто не имеющее даже собственного названия на момент обнаружения. То есть "паттерны" чаще всего "открывают" (discover), а "идеи" -- изобретают (invent). "Управление идеями" само по себе рассказывается намеренно простым языком и предполагает прежде всего процедуру их внедрения, "языки паттернов" предназначены для понимания нердами и гиками и акцентируются не столько на внедрении паттернов в практику, сколько на нахождении и внятном описании этих паттернов. Впрочем и первое и второе не слишком внятны сами по себе, когда начинаешь изучать -- нужна какая-то смешанная дисциплина: управление орг-паттернами.
Язык паттернов, конечно, подразумевает два вида инструментальной поддержки: а) софтверную среду фиксации, редактирования и хранения самих паттернов из какого-то определенного языка (обычно это разные варианты wiki), б) среды, которая поддерживает реализацию данного паттерна (например, учетный софт для поддержки паттернов throughput accounting). Учебно-промышленный организационный софт должен поддерживать ведение системы используемых организационных паттернов, а также обеспечивать поддержку решений, предлагаемых этими паттернами. Тем самым, необходимой компонентой организационного софта становится "управление паттернами".
Управление орг-паттернами должно взять простоту изложения и акцент на процедуры внедрения из "управления идеями", а структурную подачу материала и разработанность терминологии из "движения паттернов" -- и применить это все к организационным философиям и идеологиям. И поддержать это все софтом и внедренными собственными орг-паттернами управления орг-паттернами.
От организационных паттернов к организационным идеологиям
На каждый организационный паттерн (в том числе даже такой базовый, как "Цель") нужен еще десяток оргпаттернов: как их внедрить. К счастью, сам формат паттернов уже частично содержит в себе ответ на вопрос о внедрении -- он говорит о контексте, в котором обычно используется паттерн, в нем подробно обсуждается, какие различные силы задействованы и предлагается не просто решение, а решение, позволяющее сбалансировать эти силы. Поэтому сопротивление внедрению паттерна можно ожидать меньшее, нежели сопротивление внедрению просто "бизнес-идеи".
С другой стороны, необходимо иметь набор "консалтинговых/педагогических паттернов", которые должны обеспечить понимание внедряемых организационных паттернов сотрудиками (а на первых порах -- и организаторами тоже). Эти паттерны только предстоит извлечь из многочисленных книжек по change management. И тут наблюдается дурная бесконечность: для внедрения системы организационных паттернов change management тоже нужна система организационных паттернов change management...
От организационных идеологий к системам организационных паттернов
А пока мы можем наблюдать (discover) самые разные тексты, потенциально содержащие организационных паттерны разного уровня охвата, но по большей части представляющих собрание именно что идей и принципов:
-- теория ограничений -- constraints accounting -- строгое разделение постоянных и переменных издержек -- enabling role of IT;
-- аgile manufacturing -- экстремальное программирование -- эволюционный дизайн -- enabling role of IT (unit testing, refactoring browsers, intergration suits)
-- бизнес реинжиниринг -- "процессный подход" -- enabling role of IT;
Конечно, отдельная оргидея "использование IT как enabler для нового способа работы" не является прерогативой только бизнес-реинжиниринга! Так, адепты теории ограничений также прямо советуют использовать IT для вычисления (по предложенным ими алгоритмам) производственных расписаний -- причем даже не описывают это как отдельный принцип (ибо на коленке большие расписания не посчитаешь, так зачем говорить банальности про "используйте компьютер, чтобы начать работать по нашим технологиям"?). Но это именно идея, а не оргпаттерн, для паттерна нужна много большая специфичность и совсем другая структура.
Разложение бизнес-идеологий (совместимых наборов бизнес-идей) или бизнес-философий (всеобъемлющих подходов к ведению бизнеса) на паттерны будет проходить трудно и печально. Так, бизнес-реинжиниринг (в авторской редакции, страница 157) содержит четыре относительно независимые идеи:
-- радикальный редизайн и улучшение работы (в оппозицию "постепенным улучшениям");
-- атака на широкие, кросс-функциональные бизнес-процессы (независимость от границ подразделений);
-- цель -- получить улучшения на порядок величины;
-- использование IT как enabler для нового способа работы.
Эти четыре относительно независимые бизнес-идеи нелегко превратить в паттерны. Тем не менее, тексты по бизнес-реинжинирингу содержат множество более-менее мелких паттернов, сформулированных почти в канонической их форме (например, "чтобы отмоделировать процесс, двигайтесь от его конца по направлению к началу, а не от начала к концу") -- другое дело, что извлечь из этих книг целостную систему (с инкапсулированными в каждом паттерне борющимися "силами", которые должно согласовать между собой предлагаемое в этом паттерне решение) является отдельным трудным упражнением. Может, именно поэтому реинжиниринг и стал существенно извращаться (как об этом всегда сожалеет его автор Davenport) -- слова люди используют новые, а действуют по-старому. "Просто идей" недостаточно, нужны паттерны их использования -- точно так же, как "просто идеи объект-ориентированности" оказалось недостаточно для внедрения в практику объект-ориентированного подхода, нужны были паттерны его использования.
Одни и те же идеи повторяются многократно, становятся общим местом. Так, наблюдается глубокое соответствие между различными методами структурирования дизайна -- даже между такими, как ТРИЗ и языки паттернов. Вот, полюбуйтесь (http://www.aitriz.org/ai/index.php?page=2007/trizcon2007&article=abstracts): "Christopher Alexander's concept of patterns in architecture, found in his book "A Pattern Language," have been successfully used as the fundamental communication mechanism to describe reusable solutions to computer programming problems (Design Patterns). In his more recent work, "The Nature of Order," Alexander describes a set of Fifteen Fundamental Properties that are found in systems, such as buildings, constructed of centers that help and support each other. Systems composed of such coherent centers give rise to the quality of "life." Alexander's Fifteen Properties include: 1. Levels of Scale; 2. Strong Centers; 3. Boundaries; 4. Alternating Repetition; 5. Positive Space; 6. Good Shape; 7. Local Symmetries; 8. Deep Interlock and Ambiguity; 9. Contrast; 10. Gradients; 11. Roughness; 12. Echoes; 14. Simplicity and Inner Calm; and, 15. Non- Separateness. We show the relationship between Alexander's Properties and Altshuller's 40 TRIZ Principles, whereby Alexander's Fifteen Properties describe a way of grouping Altshuller's Forty Principles". И это неудивительно -- многие методы экспликации интуиции говорят об одном и том же:
-- thinking process (http://www.dbrmfg.co.nz/Thinking%20Process.htm)
-- ТРИЗ (http://www.altshuller.ru/)
-- architecture patterns/design patterns/patterns of software (http://en.wikipedia.org/wiki/Pattern_language).
-- другие техники стимулирования креативности (http://en.wikipedia.org/wiki/Creativity_techniques).
Паттерны заставляют задуматься не только на тему "что делать", но и "для чего делать" -- чтобы предлагаемые действия решали проблему, а не были просто мартышкиным копированием действий умных людей. Вот, например, способы планирования загрузки производственных ресурсов (http://www.dbrmfg.co.nz/Production.htm), все они пытаются защититься от неминуемого разброса во времени выполнения отдельных операций:
-- MRP, MRP II, APS, которые "просто не работают по совокупности причин".
-- конвейер, где синхронизация производственного расписания жесткая: через скорость конвейера, локальный буфер обеспечивается "аппаратно" лентой.
-- "массовое производство", "точно вовремя", где принята идея локальной буферизации около каждого рабочего места.
-- барабан-буфер-веревка, где принята идея глобального буфера времени и компьютерно выполняемой (расчетной) синхронизации рабочих расписаний самого малопроизводительного места (ограничения), начала конвейера (вброс материалов) и выхода конвейера.
В свою очередь, отдельная идея "барабан-буфер-веревка" может быть описана в принципах "синхронного производства" (там же, http://www.dbrmfg.co.nz/Production.htm):
1. Не фокусируйтесь на балансировке мощностей отдельных ресурсов, фокусируйтесь на синхронизации потока;
2. Мажинальная стоимость времени работы самого малопроизводительного (bottleneck) ресурса равна валовой прибыли от конечной продукции, чей производственный процесс проходит через этот ресурс.
3. Маржинальная стоимость времени на не самом малопроизводительном (non-bottleneck) ресурсе пренебрежимо мала.
5. Ресурсы должны использоваться (utilized), а не просто задействоваться (activated).
6. Транспортируемую партию необязательно, а во многих случаях обязательно не делать равной обрабатываемой партии.
7. Обрабатываемая партия может отличия как по своему маршруту, так и по времени.
Конечно, если попытаться понять, какие именно более мелкие идеи, обоснования, рассуждения, предложения, концепты лежат за условным именем "барабан-буфер-веревка", нужно будет погрузиться в омут огромного числа описаний (начав, например, с http://www.dbrmfg.co.nz/Production%20DBR.htm, а затем погрузившись в самую разную литературу из http://ailev.livejournal.com/458701.html).
Что мы будем делать
Сделать систему паттернов "барабан-буфер-веревка" -- нелегкая задача, несмотря на обилие литературы по этому поводу. Создать систему паттернов теории ограничений -- еще более трудная задача. Создать систему паттернов agile manufacturing, совместимую с системой паттернов теории ограничений -- совсем уж запредельно по трудности. Добавить к этой системе паттернов действенные "паттерны внедрения паттернов" -- существенно расширяет эту и без того запредельно трудную задачу.
Именно этим мы и собираемся заняться.
Этот пост я пишу для "общеметодологов" (в смысле http://ailev.livejournal.com/480843.html -- "общеметодологи: те, кто фиксирует средства выражения оргонтологий и оргмодели, объясняет про различия между оргонтологией и оргмоделью и т.д.. Сотрудникам и администраторам на эту тему мало что нужно знать, а методологам организации нужно воспринять результаты общеметодологической работы как основания для их работы"). В который уже раз речь идет о "нужно ли писать книгу", или о форме отчуждения организационного знания. Повторю ранее рассматривавшиеся варианты:
-- написать волнительный бизнес-роман (как это сделал Голдратт или Том ДеМарко);
-- написать пламенную "монографию" (как делают большинство бизнес-гуру);
-- сделать онлайн-гипертекст (wiki) типа "энциклопедии", не предусматривающий никакого нарратива;
-- написать набор коротких эссе (как я поминал 22 мая в посте "Книжный формат: рецептурный справочник" http://ailev.livejournal.com/485637.html). Этот недавний пост заканчивается фразой "минимализм рулит". И я склонялся именно к этому варианту.
Языки/системы паттернов
И тут я вспомнил про то, чем развлекались в самой-самой первой wiki: изобретатель WikiWikiWeb Ward Cunningham (http://en.wikipedia.org/wiki/Ward_Cunningham), активный деятель все той же smalltalk-тусовки, описывал сотоварищи в первой на свете wiki дизайн-паттерны бурно развивающегося объект-ориентированного подхода и орг-паттерны рождающегося экстремального программирования. Ибо "процедурный стиль мышления" существенно отличался от "объект-ориентированного стиля мышления", описать эти различия для широкой публики было непонятно как. И методы экстремального программирования отличались от привычных водопадных моделей разработки не меньше. Мне подумалось, что ситуация в софтверной отрасли на тот момент была такая же, как при сегодняшней попытке перехода от "мира себестоимости" в "мир валовой прибыли" при внедрении теории ограничений. Как тогда все тогда писали на языке Си или дельфийском паскале, кроме очень узкой смоллтоковской тусовки, распространяющей идеи объект-ориентированного подхода и agile-методов -- и при попытках использовать новое знание использовалось не столько новые принципы работы, сколько новые слова -- а делали все "процедурно" и "по плану", так и сегодня книжку Голдрата "Цель" все прочли, слова используют уже все новые, а делают все по-старому, опираясь на "рентабельность". Тогда (как и мне сейчас) нужен был формат, в котором быстро и эффективно передается know-how -- способ, в котором можно пытаться передать стиль мышления.
Этим форматом на тот момент (середина 90-х) оказались "языки паттернов" ("языки", ибо паттерны тут уподобляются словам: они используются в самых разных сочетаниях, как слова в предложениях), также называемые "системами паттернов". Знакомство с теми или иными проверенными решениями типовых проблем объект-ориентированного стиля в написании программ (прежде всего архитектурными паттернами для самых общих решений, типа "клиент-сервер", или дизайн-паттернами типа появившегося в Смоллтоке Model-View-Controller) стало тем способом, которым люди для себя открывали отличие объект-ориентированного стиля программирования от процедурного стиля. Книжка отмоделированных (в смысле НЛП-моделирования, т.е. "увиденных зорким глазом повторяющихся в жизни образцов", паттернов-по-Бейтсону -- discovery, а не invent) "рецептов успеха" aka best practices, причем книга гипертекстовая, с предписанной структурой, как правило еще и коллективно написанная -- вот каким оказался способ передачи знания в тех случаях, когда все понятия уже есть, а как ими пользоваться никто не знает, кроме нескольких умельцев. Берем работу умельцев, пытаемся обнаружить в этой работе повторения -- паттерны, которые ведут к успеху. Моделирование (как в НЛП) в чистом виде, результат моделирования оформляется в специальной письменной форме. Паттерны всегда идут в системе из десятков или даже сотен паттернов, а паттерн из системы выглядит примерно так (только обычно вдумчивое описание одного паттерна занимает десяток страниц):Система паттернов: Теория ограничений
Нарратив: ... Каждая организация должна иметь Цель. Эта Цель должна быть измеримой, и система оценки работы (и тем самым мотивация работников) должна быть привязана к ее достижению. ... Выпуск целевого продукта организации измеряется Проходом (Throughput), измеряемым в выпускаемом количестве целевого продукта за период. Так, целевым продуктом фирмы являются деньги, а выпуск денег организацией измеряется как валовая прибыль (throughput) за период ...
...
Название: Цель
Ситуация: высшее руководство пытается добиться эффективности совместной работы нескольких подразделений
Проблема: подразделения грызутся между собой, каждое подразделение "тянет одеяло на себя", систематически страдает "общее дело"
Сила-1: руководитель каждого ругающегося подразделения говорит, что действует исключительно в меру своих полномочий и отвечает за вверенный ему участок. Все показатели каждого из них в полном порядке: формально никто из них уступить друг другу не может без ухудшения своих показателей.
Сила-2: высшее руководство понимает, что какому-то подразделению "в интересах общего дела" придется уступить -- но каждый раз это оказывается разное подразделение, и руководители "стоят до последнего", отстаивая свои интересы. В итоге высшее руководство вынуждено решать каждый вопрос, затрагивающий два подразделения и становится бутылочным горлышком. К тому же высшие руководители сами ставили конфликтующим руководителям показатели и не могут их наказывать за рвение по их достижению.
Поэтому: Высшие руководители должны объявить общую для конфликтующих подразделений Цель (потенциально -- общую для всех подразделений организации Цель, цель Организации), установить показатели достижения этой Цели организацией и потребовать от всех руководителей действий, двигающих организацию к ее Цели (т.е. потребовать действий по достижению общеорганизационных показателей). Любой конфликт подразделений решается тем, что проверяется действие каждого подразделения на достижение показателей достижения общей Цели, а не на достижения отвязанных от общеорганизационной Цели показателей этих подразделений.
Примеры использования: организации, которые используют Теорию ограничений Голдратта
Связанные паттерны: Система показателей достижения цели, система мотивации
Предполагается, что в разных паттернах описываются разные "силы" ("инкапсуляция сил"), что и делает паттерны относительно независимыми друг от друга.
Создание и публикация систем паттернов как исследовательско-педагогический прием (эти паттерны сначала нужно открыть, назвать и описать -- это исследование, а затем использовать для обучения новичков "хорошему стилю", не поддающемуся строгому теоретическому представлению) распространился теми же смоллтоковцами-экстремальщиками-викистами и на смежные дисциплины. Кроме всевозможных систем паттернов ОО-архитектуры и дизайна (software patterns), паттернов agile-методов разработки (organizational patterns) появилсь также системы педагогических паттернов, и даже юмор типа системы паттернов свиданий, написанных специально для программистов. Подробности движения по разработке систем паттернов (pattern movement) см. в http://ailev.livejournal.com/487783.html).
Система паттернов:
-- нацелена на содействие "сдвигу в мозгах", это образовательная практика прежде всего. Так что паттерны вполне могут быть инструментом методологов организации.
-- включает обычно две части: 1. нарратив/пролог/учебник, задающий целостность системы, показывающей связь контекстов и используемых в них паттернов, часто это около 20% (http://www.theserverside.com/news/thread.tss?thread_id=28365) от всего текста 2. "справочник" по отдельным паттернам, подробно их описывающий -- 80% текста.
-- это сборник удачных типовых решений для типовых затыков, получаемых при попытках деятельности. Каждый паттерн может быть выражен сверхкратко (thumbnail для паттерна -- это фраза типа "Акционер у вас странный -- ориентируйтесь на "идеального акционера"" или "Достали непродуктивные кофликты подразделений -- сделайте критерием их разрешения ориентацию на достижение ими глобального максимума (показателей Цели)") или подробно разжеван на паре десятков страниц.
-- это "сократический метод" в специально организованной форме, каждый раздел формы паттерна заставляет отвечать на ее специфический вопрос, задавая постепенное разворачивание содержания.
-- это способ структурирования know-how для слабо проработанных предметных областей. Паттерны получают имена, и дальше можно обсуждать их применимость в той или иной ситуации.
-- это способ рефлексии деятельности (идентификация типовых затыков и удачных типовых решений, в нашем случае это инструмент общения методологов организации и организаторов).
Эволюционный дизайн организации: рефакторинг согласно паттернам
С точки зрения деятельностного подхода, мы хотим влиять на то, как устроены организации (системы эффективного разделения труда), мы хотим изменять эти системы, а не просто глазеть на них и умствовать по этому поводу. С позиции организатора бесперспективно рассматривать "организационную структуру и функции" на данный момент времени, а осмысленно только рассматривать предполагаемые изменения в организации (маржинальный подход, http://ailev.livejournal.com/449217.html) -- как намеренно вводимые организатором-деятелем, так и возникающие помимо его желаний воли.
Это приводит нас к принципу evolutionary design (http://www.martinfowler.com/articles/designDead.html, который активно используется в eXtreme programming). В отличие от planned design (где организаторы думают о "проектировании организации" как целого, а не о том, как бы что организовать -- что подразумевает какую-то последовательность реализации замыслов), в эволюционном оргдизайне конкретные дизайн-решения фокусируются вокруг решения конкретных проблем, а не одномоментно определяют все аспекты организации. Это как нельзя лучше подходит к процессу постоянных организационных изменений, задаваемых теорией ограничений, оргфилософией agile manufacturing и многими другими интересующими нас системами.
По факту организационное развитие должно сопровождаться безжалостным рефакторингом (http://en.wikipedia.org/wiki/Refactoring -- в нашем случае это соответствует реорганизации, сохраняющей внешнее поведение организации, но облегчающей дальнейшее развитие). А вот осмысленный рефакторинг должен направляться паттернами -- об этом говорят работы классиков рефакторинга. Осмысленная реорганизация тоже должна направляться паттернами. Система организационных паттернов структурирует идеи о том, что можно было бы сделать в плане улучшения организации на каждом отдельном шаге.
Управление организационными паттернами
Сама предметная область "языков паттернов" ужасна в своей терминологии (занимались этим яйцеголовые архитекторы и программисты, простым людям этого с наскоку не понять), поэтому нам придется менять терминологию. Но менять сильно мы ее не будем: ибо
-- слово "паттерн" пока в менеджерских науках не очень занято, и поэтому для большинства людей не будет тащить за собой разные другие смыслы
-- хочется оставить параллель между организовыванием и программированием, и сохранить преемственность между этими двумя видами образования. ОО-дизайн, основанный на паттернах и оргдизайн, основанный на паттернах -- очень интересная форма образования.
Тут нужно вспомнить, что я писал про "управление идеями" (http://ailev.livejournal.com/484203.html). Ошибочно может показаться, что слова "система паттернов" и "бизнес-идея" взаимозаменяемы. Действительно, "языки организационных паттернов" и "управление бизнес-идеями" весьма похожи -- но обращают внимание на разные стороны реальности.
В "управлении идеями" акцентируется, что хорошие бизнес-идеи придумываются -- а затем описанные в них методы работы постепенными становятся best practices. В "языках паттернов" прежде всего ищутся паттерны -- общее в уже имеющейся практике, часто не имеющее даже собственного названия на момент обнаружения. То есть "паттерны" чаще всего "открывают" (discover), а "идеи" -- изобретают (invent). "Управление идеями" само по себе рассказывается намеренно простым языком и предполагает прежде всего процедуру их внедрения, "языки паттернов" предназначены для понимания нердами и гиками и акцентируются не столько на внедрении паттернов в практику, сколько на нахождении и внятном описании этих паттернов. Впрочем и первое и второе не слишком внятны сами по себе, когда начинаешь изучать -- нужна какая-то смешанная дисциплина: управление орг-паттернами.
Язык паттернов, конечно, подразумевает два вида инструментальной поддержки: а) софтверную среду фиксации, редактирования и хранения самих паттернов из какого-то определенного языка (обычно это разные варианты wiki), б) среды, которая поддерживает реализацию данного паттерна (например, учетный софт для поддержки паттернов throughput accounting). Учебно-промышленный организационный софт должен поддерживать ведение системы используемых организационных паттернов, а также обеспечивать поддержку решений, предлагаемых этими паттернами. Тем самым, необходимой компонентой организационного софта становится "управление паттернами".
Управление орг-паттернами должно взять простоту изложения и акцент на процедуры внедрения из "управления идеями", а структурную подачу материала и разработанность терминологии из "движения паттернов" -- и применить это все к организационным философиям и идеологиям. И поддержать это все софтом и внедренными собственными орг-паттернами управления орг-паттернами.
От организационных паттернов к организационным идеологиям
На каждый организационный паттерн (в том числе даже такой базовый, как "Цель") нужен еще десяток оргпаттернов: как их внедрить. К счастью, сам формат паттернов уже частично содержит в себе ответ на вопрос о внедрении -- он говорит о контексте, в котором обычно используется паттерн, в нем подробно обсуждается, какие различные силы задействованы и предлагается не просто решение, а решение, позволяющее сбалансировать эти силы. Поэтому сопротивление внедрению паттерна можно ожидать меньшее, нежели сопротивление внедрению просто "бизнес-идеи".
С другой стороны, необходимо иметь набор "консалтинговых/педагогических паттернов", которые должны обеспечить понимание внедряемых организационных паттернов сотрудиками (а на первых порах -- и организаторами тоже). Эти паттерны только предстоит извлечь из многочисленных книжек по change management. И тут наблюдается дурная бесконечность: для внедрения системы организационных паттернов change management тоже нужна система организационных паттернов change management...
От организационных идеологий к системам организационных паттернов
А пока мы можем наблюдать (discover) самые разные тексты, потенциально содержащие организационных паттерны разного уровня охвата, но по большей части представляющих собрание именно что идей и принципов:
-- теория ограничений -- constraints accounting -- строгое разделение постоянных и переменных издержек -- enabling role of IT;
-- аgile manufacturing -- экстремальное программирование -- эволюционный дизайн -- enabling role of IT (unit testing, refactoring browsers, intergration suits)
-- бизнес реинжиниринг -- "процессный подход" -- enabling role of IT;
Конечно, отдельная оргидея "использование IT как enabler для нового способа работы" не является прерогативой только бизнес-реинжиниринга! Так, адепты теории ограничений также прямо советуют использовать IT для вычисления (по предложенным ими алгоритмам) производственных расписаний -- причем даже не описывают это как отдельный принцип (ибо на коленке большие расписания не посчитаешь, так зачем говорить банальности про "используйте компьютер, чтобы начать работать по нашим технологиям"?). Но это именно идея, а не оргпаттерн, для паттерна нужна много большая специфичность и совсем другая структура.
Разложение бизнес-идеологий (совместимых наборов бизнес-идей) или бизнес-философий (всеобъемлющих подходов к ведению бизнеса) на паттерны будет проходить трудно и печально. Так, бизнес-реинжиниринг (в авторской редакции, страница 157) содержит четыре относительно независимые идеи:
-- радикальный редизайн и улучшение работы (в оппозицию "постепенным улучшениям");
-- атака на широкие, кросс-функциональные бизнес-процессы (независимость от границ подразделений);
-- цель -- получить улучшения на порядок величины;
-- использование IT как enabler для нового способа работы.
Эти четыре относительно независимые бизнес-идеи нелегко превратить в паттерны. Тем не менее, тексты по бизнес-реинжинирингу содержат множество более-менее мелких паттернов, сформулированных почти в канонической их форме (например, "чтобы отмоделировать процесс, двигайтесь от его конца по направлению к началу, а не от начала к концу") -- другое дело, что извлечь из этих книг целостную систему (с инкапсулированными в каждом паттерне борющимися "силами", которые должно согласовать между собой предлагаемое в этом паттерне решение) является отдельным трудным упражнением. Может, именно поэтому реинжиниринг и стал существенно извращаться (как об этом всегда сожалеет его автор Davenport) -- слова люди используют новые, а действуют по-старому. "Просто идей" недостаточно, нужны паттерны их использования -- точно так же, как "просто идеи объект-ориентированности" оказалось недостаточно для внедрения в практику объект-ориентированного подхода, нужны были паттерны его использования.
Одни и те же идеи повторяются многократно, становятся общим местом. Так, наблюдается глубокое соответствие между различными методами структурирования дизайна -- даже между такими, как ТРИЗ и языки паттернов. Вот, полюбуйтесь (http://www.aitriz.org/ai/index.php?page=2007/trizcon2007&article=abstracts): "Christopher Alexander's concept of patterns in architecture, found in his book "A Pattern Language," have been successfully used as the fundamental communication mechanism to describe reusable solutions to computer programming problems (Design Patterns). In his more recent work, "The Nature of Order," Alexander describes a set of Fifteen Fundamental Properties that are found in systems, such as buildings, constructed of centers that help and support each other. Systems composed of such coherent centers give rise to the quality of "life." Alexander's Fifteen Properties include: 1. Levels of Scale; 2. Strong Centers; 3. Boundaries; 4. Alternating Repetition; 5. Positive Space; 6. Good Shape; 7. Local Symmetries; 8. Deep Interlock and Ambiguity; 9. Contrast; 10. Gradients; 11. Roughness; 12. Echoes; 14. Simplicity and Inner Calm; and, 15. Non- Separateness. We show the relationship between Alexander's Properties and Altshuller's 40 TRIZ Principles, whereby Alexander's Fifteen Properties describe a way of grouping Altshuller's Forty Principles". И это неудивительно -- многие методы экспликации интуиции говорят об одном и том же:
-- thinking process (http://www.dbrmfg.co.nz/Thinking%20Process.htm)
-- ТРИЗ (http://www.altshuller.ru/)
-- architecture patterns/design patterns/patterns of software (http://en.wikipedia.org/wiki/Pattern_language).
-- другие техники стимулирования креативности (http://en.wikipedia.org/wiki/Creativity_techniques).
Паттерны заставляют задуматься не только на тему "что делать", но и "для чего делать" -- чтобы предлагаемые действия решали проблему, а не были просто мартышкиным копированием действий умных людей. Вот, например, способы планирования загрузки производственных ресурсов (http://www.dbrmfg.co.nz/Production.htm), все они пытаются защититься от неминуемого разброса во времени выполнения отдельных операций:
-- MRP, MRP II, APS, которые "просто не работают по совокупности причин".
-- конвейер, где синхронизация производственного расписания жесткая: через скорость конвейера, локальный буфер обеспечивается "аппаратно" лентой.
-- "массовое производство", "точно вовремя", где принята идея локальной буферизации около каждого рабочего места.
-- барабан-буфер-веревка, где принята идея глобального буфера времени и компьютерно выполняемой (расчетной) синхронизации рабочих расписаний самого малопроизводительного места (ограничения), начала конвейера (вброс материалов) и выхода конвейера.
В свою очередь, отдельная идея "барабан-буфер-веревка" может быть описана в принципах "синхронного производства" (там же, http://www.dbrmfg.co.nz/Production.htm):
1. Не фокусируйтесь на балансировке мощностей отдельных ресурсов, фокусируйтесь на синхронизации потока;
2. Мажинальная стоимость времени работы самого малопроизводительного (bottleneck) ресурса равна валовой прибыли от конечной продукции, чей производственный процесс проходит через этот ресурс.
3. Маржинальная стоимость времени на не самом малопроизводительном (non-bottleneck) ресурсе пренебрежимо мала.
5. Ресурсы должны использоваться (utilized), а не просто задействоваться (activated).
6. Транспортируемую партию необязательно, а во многих случаях обязательно не делать равной обрабатываемой партии.
7. Обрабатываемая партия может отличия как по своему маршруту, так и по времени.
Конечно, если попытаться понять, какие именно более мелкие идеи, обоснования, рассуждения, предложения, концепты лежат за условным именем "барабан-буфер-веревка", нужно будет погрузиться в омут огромного числа описаний (начав, например, с http://www.dbrmfg.co.nz/Production%20DBR.htm, а затем погрузившись в самую разную литературу из http://ailev.livejournal.com/458701.html).
Что мы будем делать
Сделать систему паттернов "барабан-буфер-веревка" -- нелегкая задача, несмотря на обилие литературы по этому поводу. Создать систему паттернов теории ограничений -- еще более трудная задача. Создать систему паттернов agile manufacturing, совместимую с системой паттернов теории ограничений -- совсем уж запредельно по трудности. Добавить к этой системе паттернов действенные "паттерны внедрения паттернов" -- существенно расширяет эту и без того запредельно трудную задачу.
Именно этим мы и собираемся заняться.