?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Процессы, проекты, программы, реформы. Реформы как циклы ассиммиляции-кодирования-инсталляции. [04 Nov 2005|01:29am]
Сегодня мне задавали вопросы:

Чем программа административного реинжиниринга отличается от реформы? Ответ: ничем. Равно как и административный инженер (http://www.elrussia.ru/54150) ничем не отличается от профессионального реформатора. Ну, возможно масштабы чуть другие: но количественная разница тут в расчет не идет.

Чем реформы, учитываемые по Постановлению Правительства РФ от 27 апреля 2005 г. N 259 "Об утверждении Положения о разработке сводного доклада о результатах и основных направлениях деятельности Правительства Российской Федерации на 2005-2008 годы" ("сводный доклад содержит ... перечень планируемых реформ",
"Раздел "Комплекс мер по достижению целей деятельности Правительства Российской Федерации и субъектов бюджетного планирования" содержит ... планируемые реформы, проекты развития",
"По каждой планируемой реформе и проекту развития указываются:
а) цели и задачи планируемой реформы и проекта развития, промежуточные и конечные результаты, включая количественно измеримые показатели и их планируемые значения;
б) меры и механизмы реализации планируемой реформы и проекта развития;
в) комплекс взаимоувязанных мероприятий, направленных на реализацию планируемой реформы и проекта развития;
г) анализ последствий осуществления преобразований для населения и субъектов экономической деятельности;
д) качественная и количественная оценка влияния результатов планируемой реформы и проекта развития на достижение целей деятельности Правительства Российской Федерации в плановом периоде и на перспективу;
е) сводная оценка ресурсов, необходимых для осуществления планируемой реформы и проекта развития, с указанием их источников и объемов;
ж) анализ факторов, препятствующих решению поставленных задач.",
"субъекты бюджетного планирования осуществляют... подготовку предложений в пределах своей компетенции об осуществлении планируемых реформ и проектов развития")
отличаются от реформ, инициируемых в рамках административной реформы (которая в сама является эдакой реформаторской матрешкой, внутри которой находится заранее неизвестное число реформ)? Ответ: ничем.

Чем реформирование отличается от "простого нормотворчества". Ответ: нормотворчество является только одной из составляющих реформирования. Тут нужно пояснить, что ответ становится понятным, если учесть Симултрек: одновременное удерживание принципиально разных точек зрения на реальность (http://www.livejournal.com/users/ailev/329646.html). Ранее я обсуждал реформирование как "продажу решения" (по этапам модели "больших продаж" Рэкхема или модели шести уровней снятия сопротивления Голдратта -- http://www.livejournal.com/users/ailev/335435.html). Но это только один из возможных взглядов, показывающий содержательную и коммуникативную организацию материала для административных инженеров.

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

1. Административный инженер должен ассимилировать ту сферу, которую он собирается реформировать (тут я использую паттерн НЛП-моделирования, описанный Джоном Гриндером в его свежей сверхкраткой статье http://www.newcode.ru/site/index.php?option=com_content&task=view&id=37&Itemid=38). Грубым критерием успеха в этом изучении является демонстрация административным инженером умения поддержать сущностный профессиональный разговор с лучшими инсайдерами-стейкхолдерами из реформируемой сферы так, чтобы непрофессионализм административного инженера не выпирал через каждые три минуты, и время разговора тратилось на обсуждение трудных вопросов, а не обучение инженера. Скажем, если реформа энергетики, то административный инженер должен признаваться компетентным энергетиками, если реформа паспортно-визовой службы, то административный инженер должен выглядеть "своим" для специалистов паспортно-визовой службы. Опыт показывает, что профессиональному консультанту обычно достаточно трех-четырех месяцев "погружения", чтобы достичь такой стадии (а если речь идет об обычном "непрофессиональном" погружении -- то это пять-шесть лет работы в реформируемом секторе). Если эта стадия ассимилирования не пройдена, то речь пойдет об "аналитических реформах" (я тут следую в терминологии за Гриндером) и не хочу обсуждать их качество (оно может быть и хорошим, конечно, но это ничем не гарантировано ;) На этом этапе административный инженер пишет и (и читает) такие документы реформы, как Обзоры (http://www.livejournal.com/users/ailev/239600.html). Ведущая квалификация -- то самое умение ассимилирования, но особого сорта, ближе всего это к knowledge aquisiton в программировании (некоторые -- http://vitebsk.hut1.ru/progstone/index.html -- даже считают это не квалификацией, а вообще свойством особого типа людей -- мэпперов, в отличие от пэкеров, но оставим это на их совести. Я считаю, что подобное ассимилирование именно квалификация, вполне научаемое умение, хотя способности тут явно не помешают, как и в любом другом деле).

2. После того, как административный иженер (не один, конечно -- команда таковых. Но я тут пишу в терминах ролей, до оргдизайна команды реформаторов нам еще как до Луны) демонстрирует полное понимание проблем разных стейкхолдеров и способен воспроизводить их ценностные рассуждения и отношение к разным вариантам решения проблемы, можно приступать к написанию нормативных актов (этап кодирования). Нормативные акты пишутся по-разному: либо непосредственно (реже), либо начиная с Концепции, после которой идет пакет нормативных актов, либо сначала таки идет Доклад, только затем Концепция (принятие Концепции является формальным пунктом, после которого можно считать, что реформа пошла), и только потом -- нормативные акты. Этот этап -- кодирование, нормативная работа. Поиск основных решений проблем я включаю именно в эту стадию -- кодирование, которое предполагает высокорефлексивную позицию, существенно отличающуюся от позиции при ассимилировании. Ведущая квалификация тут -- правоведение, философия права. И умение удерживать симултрек (т.е. быть максимально сознательным и интегральным -- это уж я совсем по Кену Уилберу ;).

3. Мало того, что Концепция и даже сами нормативные акты будут приняты. Нужно, чтобы жизнь пошла по-новому, чтобы как можно более безболезненно рассосались старые общественные институты и как можно более беспроблемно появились новые. "Само" это обычно не происходит даже в случае полностью готовой нормативной базы. Поэтому этот этап требует тщательного планирования и не менее тщательного исполнения: инсталляция общественных институтов. Особо нужно обратить внимание, что инсталляция может включать много чего такого, что совершенно не прописано в нормативных актах (особенно в тех случаях, когда суть реформы как раз отмена нормативных актов). Заметим также, что убедительное сценирование инсталляции как минимум и уверенность в том, что инсталляция будет проведена в реальности как максимум является сильным аргументов на этапе принятия нормативных актов.

4. Реформы не являются ни проектами, ни программами в смысле проектного управления (хотя я и предпочитаю писать "программы административного реинжиниринга", за неимением других слов -- но хотя бы подчеркивая, что реформа уж никак не проект). И уж совсем не процесс, в смысле управления процессами. Русских слов для этого нет (хотя в СМД-методологии используется слово "программа" в совершенно другом значении "движения в расходящейся от здесь и сейчас воронке возможностей" в противоположность к сходящейся воронке проекта -- но использовать эти слова в их СМД-значении неправильно, операционные менеджеры их просто не будут понимать). Поэтому я предлагаю оставить за типом реформы именно это слово -- реформа. То бишь в административном/операционном менеджменте нужно будет изучать управление (административными) процессами, проектами, программами и реформами. В любом случае реформам как форме деятельности присущи этапы, итеративность шагов ассимилирования-кодирования-инсталляции-ассимилирования(деятельность изменилась после предыдущих кодирования-инсталляции! ее снова нужно изучить!)-кодирования-инсталляции...
post comment

Нет интересных теорий, есть интересные люди, и они читают друг друга [04 Nov 2005|03:24pm]
Все чаще и чаще я делаю поиск таким образом: есть интересная мысль -- находится человек, у которого была эта интересная мысль -- находятся еще более интересные мысли, которые есть у этого человека. Чуть-чуть времени я потратил на Colston Sanger, одного из соавторов культового Программистского Камня (не то чтобы я был с Программистским Камнем во всем согласен, но это не совсем заурядный текст). Я чуть-чуть поинтересовался, что там еще Coslton Sanger делает. Он оказался аналитиком по риск-менеджменту и одним из лидеров лондонского Демингского общества, цитадели TQM -- и даже интересовался связью TQM с NLP -- в мае 1997 он познакомился на заседании British Deming Association с the map is not the territory, http://deming.ces.clemson.edu/pub/den/archive/old/DENMF022.HTM (вот его заметки по этому поводу: -- The map is not the territory: everyone has their own unique view of the world. Is this not in accord with Deming's `Any two people may have different ideas about what is important to know about any event'? -- More maps are better than fewer maps. Yes! The argument for flexibility and for multiple perspectives. Hence the interrelationship and interdependence of all the aspects of Deming's system of profound knowledge.), и в том же году летом-осенью совместно с Алан Картером у него появился промэпперский "Программиский камень" http://www.reciprocality.org/Reciprocality/r0/index.html по-английски, http://vitebsk.hut1.ru/progstone/index.html по-русски. Но различие картостроителей и паковщиков появилось, думаю, много раньше -- они в 1997 году заявляли, что работа над Программистским камнем у них заняла 6 лет ;)

Потом Alan Carter пошел в свои углубленные (весьма сомнительные для меня) допаминовые изыскания Reciprocality, но это уже много менее интересно.

Вот список литературы для Программистского камня: http://www.reciprocality.org/books/acuk/books-ps.html -- обратите внимание, что в нем пара книжек Голдратта (Цель и Это не везенье), с комментарием Алана Картера Fairy stories about how our heros manage to think around M0 and solve problems, instead of being driven off site with their stuff in binliners, which is what would really happen. Вот он, фанатичный мэпперизм, когда карта надолго становится территорией ;) Впрочем, ТРИЗ у него там тоже в источниках, и даже автоформализация знаний от abcdefgh. Все мы в одну сторону глядим...

Вот еще несколько заметок по ходу дела:

История, как в суде было доказано, что ISO9001 и ISO9000 не улучшают бизнес -- http://www.buildfreedom.com/content/reciprocality/r1/example.html (ибо нет никаких метрик, которые могли бы показать это улучшение). Я думаю, что в случае качества государственного управления можно было бы смело так же выигрывать суды (если признать, что выступления политиков являются рекламой, т.е. публичным призывом предпринять тот или иной затратный для налогоплательщиков проект ;)

Action Learning (developed by Reg Revans): ...in true action learning ... men start to learn with and from each other only when they discover that no-one knows the answer but all are obliged to find it.. То есть критическим пунктом начала обучения по этой теории является отсутствие людей, которые разбираются в проблеме, но есть тем не менее необходимость получить результат. В этот момент ты начинаешь думать: синтезировать свои знания, имеющиеся знания других людей, понимание проблемной ситуации и т.д. Отсюда немедленно приходишь к action research -- семейству исследовательских методологий, которые одновременно предполагают действия (или изменения) и исследования (или понимание). "В большинстве своих форм это делается через циклический или спиральный процесс, который переключается между деятельностью и критической рефлексией и, в более поздних циклах, постоянно очищает методы, данные и интерпретации в свете понимания, случившегося на более ранних циклах. Тем самым это эмерджентный процесс, который приобретает форму по мере роста понимания, и это итеративный процесс, который дрейфует к лучшему пониманию того, что происходит. В большинстве случаев это качественный и партисипативный процесс." Узнаете реформы? ;)

А вот и рефакторинг (понимаемый как постоянное приведение кода в более сопровождаемое состояние), применяемый не к софту, а к бизнесу: http://www.spaconference.org/cgi-bin/wiki.pl/ot2002/?KkbaabbefjhdthgtbegbfepooldirconcoukKk -- отсюда уже полшага до eXtreme Business (идеи extreme programming, применяемые к бизнесу) а дальше Гугль радует россыпью всяческих находок на "extreme business", и опять-таки для реформатора (да, я все продолжаю тему ;) множество подсказок (впрочем, это уже общие места для множества философий деятельности):
1. Кодирование. В конце дня, если нет работающего нового кода (читай: законодательства, которое используется и приносит пользу обществу -- в том числе законодательства, которое отменяет другое законодательство и тем приносит пользу обществу ;) считай, что ничего не сделал.
2. Тестирование. Ты должен знать, когда твой код работает. Это могут сказать только измерения. Поэтому сначала позаботься об измерениях.
3. Слушание. Нужно узнать, в чем проблема, и как ухватить проблему в тестах. Как правило, это знание не находится в тебе самом. Поэтому нужно много слушать пользователей, которым хлебать твои решения. Кстати, этот пункт наиболее часто недопонимается в XP. А это ключевой пункт: при его игнорировании великолепный код не будет решать нужные проблемы, но будет решать много ненужных!
4. Дизайн ("проектирование" уж как-то больно сухо, без оттенка искусства).
Ссылок миллион, Colston весьма продуктивен -- но идет по lean & TQM линии, а не по Голдраттовской ветке (для меня главное различие -- lean думает о как можно большем списке дел, а Годлратт -- о как можно меньшем, т.е. Годлратта сильно заботит явное нахождение корня зла, а "качественников" нахождение корня зла заботит, но неявно, а как "само собой разумеющееся", что чревато забывчивостью делать это "само собой разумеющееся"): http://xpday.xpdeveloper.com/slides/eXtremeBusiness_genericfont.ppt с вариантом смеси с Демингом http://xpday2.xpday.org/ColstonSlides.ppt, http://www.users.globalnet.co.uk/~rxv/business/xb.htm

На мой взгляд, все эти XB (extreme business) или даже XA (extreme administration) совершенно не противоречат Голдраттовским методам, но дополняют их. Все это про одно и то же. Нужно делать рефакторинг, удалять дублирование ;)
4 comments|post comment

navigation
[ viewing | November 4th, 2005 ]
[ go | previous day|next day ]