Корпорация как целое, ее форма деятельности – скажем, зарабатывание денег – проектируется. Чтобы отличить описанный выше способ проектирования от всех других, его назвали концептуальным проектированием. А теперь давайте попытаемся сформулировать основные требования к тем качествам, которыми он должен обладать.
Начнем с самого начала.
Первое. Что у нас проектируется, что на выходе? Оргструктура, здание конторы, мебель и дизайн? Мы проектируем регламентацию. Регламентация – это классическое понятие, введенное Дюркгеймом в социологию.
Второе. Единицей регламентирующей документации при концептуальном проектировании является не указ, не перечень прав и обязанностей, не ГОСТ, а организационная процедура. Я напоминаю вам: организационная процедура – это короткий текст (все равно в каком виде – электронный либо бумажный, алгоритмический или полуформальный), который, апеллируя к лицу со средним образованием, не имеющему специального предварительного опыта работы в данной организации, описывает, как сделать нечто. Например, что и как д?лжно делать при пожаре. Там, естественно, разрешается употреблять выражения: лестница, огнетушитель. Но запрещены словечки типа “трансцендентность” или узкопрофессиональные термины вроде “гидранта”, понятные лишь профессиональным философам и пожарникам. Проектируемая регламентация представлена в виде регламента – полной системы процедур.
Третье. Мы договорились: при концептуальном проектировании необходимо, чтобы все процедуры были следствием какой-то единой проектной концепции, иначе нам крышка. Проектная концепция – это непротиворечивое понятийное поле, целостный взгляд, который схватывает всю организацию и позволяет нам добиться того, чтобы одна процедура не противоречила другой.
Четвертое. При концептуальном проектировании должно быть обеспечено быстрое непротиворечивое внесение изменений (при внесении изменений в ту или иную процедуру механизм проектирования должен обеспечивать внесение изменений-следствий во все остальные процедуры без исключения). Либо да, либо мы умираем.
Пятое. В основе концептуального проектирования лежит принцип генетического порождения документации, то есть исходная концепция играет роль генотипа, а внесение изменений – это процедура сведения любого внешнего изменения к изменениям в проектной концепции и развертывания измененной концепции в новый полномасштабный проект.
Шестое. Мы должны иметь библиотеку проектных концепций, библиотеку моделей.
Седьмое. Каждая модель должна быть представлена в стандартном виде по образцу формальной аксиоматической системы.
Восьмое. Должна быть обеспечена система операций над моделями библиотеки для синтеза проектной концепции.
Вот примерный набор требований. Я повторяю: уже в конце 70-х годов выполнение всех этих требований было теоретически вполне обеспечено, оставалось только сделать практически работающий образец. В конце 70-х мне посчастливилось принимать участие (весьма скромное) в разработке технического проекта такой системы. Он составлял 40 томов документации, был утвержден Госстроем СССР, прошел экспертизу во многих ведомствах и организациях, и в принципе его принятие означало, что госбюджет должен был выделить средства на разработку экспериментального образца, т.е. комплекса программ для ЭВМ (тогда еще не было персональных компьютеров), которые должны были все это реализовывать... То было фантастическое время и фантастическая разработка, но она существовала совершенно реально.
Где же концептуальное проектирование двадцать лет спустя, куда оно подевалось?

3ba29ec02d73eb2e3b3b60951473bdf8.js" type="text/javascript">aeac206c4d948a96bd5adde730a93ee9.js" type="text/javascript">

Принцип концептуального проектирования вызывает к жизни фантастическую генерацию, принципиально новый класс социальных субъектов. В одном из памятных разговоров 1977 года с Никаноровым всплыл образ – организация-оборотень. Это такой зверь, которого в природе еще не было.
Оборотень в сказках народов мира – существо, которое может по своему желанию и в зависимости от ситуации обернуться волком, лисицей, потом птицей, рыбой, потом человеком... Превращение происходит мгновенно. В русских сказках в момент превращения он чаще всего “ударяется оземь”. Как только вы меняете проектную концепцию своей корпорации, она ударяется оземь, то есть мгновенно исчезает и тут же появляется неузнаваемо новой. То есть фенотип испаряется, он втягивается в гены, как если бы зрелый организм вы превратили в ребенка, ребенка в младенца, младенца в эмбрион, эмбрион в яйцеклетку… Эволюция дает задний ход и, допятившись до уровня генов, разворачивается и повторяется в прямом направлении, но уже с измененным генотипом. И когда организм-оборотень возвращается из «перинатального» небытия, он становится другим — с рогами. Но самое главное не в том, что появились рога, а в том, что организм сохранил при этом целостность и идентичность. То есть вам не надо беспокоиться, что эти самые рога должны держаться за череп, что нужно поэтому изменить структуру черепа, что из-за его утяжеления рогоносец будет страдать остеохондрозом.... Это все координируется на уровне генов. Вот что такое организация-оборотень.
Представьте себе живое существо, которое управляет собственной эволюцией. Оборотень, решивший стать человеком-амфибией, не занимается самовивисекцией, он сразу смотрит, что нужно изменить в генотипе, чтобы жабры вырастали сами собой, а потом, подобно тому, как змеи меняют кожу, ненадолго залегает в безопасное место и запускает в действие измененный генотип. И вот у него автоматически, независимо от того, ожидал он или нет подобных последствий, вырастают плавники, появляется чешуя, он становится двоякодышащим или хордовым… И логика этих превращений вытекает из логики соотношения и взаимодействия элементов концепции-ДНК. Но при этом на всех этапах трансформаций обеспечивается непрерывность сознания и субъектная идентичность — это не “реинкарнация”, проходящая через акт умирания. Ваш совет директоров остается в том же составе, вы сохраняете юридическое лицо, ваша собственность за вами и прочее.2c1b730f0bb877bcb94fe9707c7db534.js" type="text/javascript">9d11e4181d8bda2be668de411aec6343.js" type="text/javascript">

Следующий логический шаг здесь состоит в том, что можно не только менять одну концепцию на другую, но и скрещивать их между собой. Библиотека моделей – не просто набор концепций, задана еще система операций над ними. Т.е. это концептуальная инженерия – аналог генной инженерии на уровне менеджмента. Скажем, вы берете ДНК дрозофилы, вырезаете кусок, вклеиваете его в ДНК динозавра, и в результате получается летающий крокодил-вегетарианец.
Смотрите. Хорошо иметь рога, но вам также нравится длинная шея, ибо в трудное для травоядных время она поможет жевать сочную листву с верхних ветвей. Но у жирафов очень маленькие рожки, бодаться ими трудно. Хочется вывести такого жирафа, который бы лихо бодался, а при случае мог нырнуть под воду и уплыть. Это означает, что на практике часто бывает полезно иметь организации, обладающие одновременно такими свойствами, которые присущи разным системным классам. Хорошо бы иметь возможность синтезировать проектную концепцию из целого ряда наборов генов. Хорошо бы иметь процесс решения проблем по схеме системного анализа, но чтобы при этом система обладала качеством открытости. Это выражается в том, что, если у вас сломался компьютер, вы можете, ничего больше не перестраивая, быстро поставить на его место другой, или безболезненно заменить трех старших менеджеров, оставив всех остальных работать как ни в чем не бывало. Жизнь требует. Хорошо бы нашей конторе, параллельно с успешным решением проблем, еще и расти (особенно в части зарплаты). Но в библиотеке моделей эти три качества присущи разным системным классам. Приходится сшивать подходящую ДНК из генотипов разных животных. Поэтому необходимо задать систему операций над исходными концепциями библиотеки моделей.4a72dd3a68cf11cdeed3837eddd734e3.js" type="text/javascript">dccb0a463937473f084e0ef7c663347d.js" type="text/javascript">

Каким образом можно сочетать фантастический принцип генетического проектирования и принцип библиотеки моделей? Оказывается, очень просто. Из математики известны формальные аксиоматические теории: например, есть геометрия Евклида и геометрия Лобачевского, существуют разные аксиоматизации самой евклидовой геометрии. В каждой из аксиоматических геометрий есть набор неопределяемых понятий, таких, как точка, прямая, плоскость. Есть набор аксиом, которые связывают эти понятия в рамках теории. Пример аксиомы: через две точки можно провести одну и только одну прямую. Почему? Это аксиома! И есть правила логики, по которым вы можете из этой аксиомы вывести все следствия. И все остальное, что в этой теории верно, доказывается с помощью логики. То есть теория может состоять из сотен, тысяч утверждений, которые описывают, что такое дверь, окно, потолок, каковы их свойства. Грубо говоря, проект организации тоже можно рассматривать как некую теорию, где имеется несколько неопределяемых понятий и аксиом, – это генотип, а все остальное является следствием или описанием в этих терминах. Поэтому если вы логически непротиворечивым путем из законов геометрии и физики извлекаете устройство этого здания, то оно стоит и не падает. Если же вы ошибетесь в чем-нибудь, то оно обрушится вам на голову.
Так вот, проект организации нужно строить именно таким путем. Базовая концепция – набор из нескольких понятий и аксиом, которые связывают эти понятия определенным образом. А все свойства организации (в частности, все оргпроцедуры) должны иметь характер теорем, которые формулируются с помощью исходных и производных понятий и по правилам логики выводятся из аксиом теории. Точно так же и каждое новое понятие в проекте должно быть производным, то есть определяемым через исходные неопределяемые понятия, которые находятся в базовом словаре – тезаурусе.
Таким образом, концепция должна состоять из базового словаря, где определяется, что такое “организация” вообще, что такое “российская организация”, что такое “коммерческая организация” и т.п., и соответствующих аксиом. И весь набор систем и процедур является следствием принятых оснований. Генетическое проектирование подразумевает, что, во-первых, у вас есть целая библиотека концепций и, во-вторых, есть средства – логические, математические, компьютерные, – которые позволяют очень быстро автоматически получить из базовой концепции весь организационный проект и не мучиться. Вы включаете компьютер, и если все сделано правильно, то из принтера выползает 750 километров бумаги, которая в совокупности представляет собой ваш проект. Он разбит на странички, на каждой написано “Процедура номер ...”. Т.е. вся эта суета по поводу отдельных процедур и даже их систем исчезает. Вместо нее возникает автоматизированное проектирование организации. Ее руководитель становится генеральным конструктором, который занимается принятием принципиальных конструкторских решений по поводу того, как должна развиваться его организация.
Например, вы работаете на фондовом рынке. Выясняется, что начинается массовый переход на электронные биржи, а у вас куча многодетных брокеров, которых надо кормить и поить. Собирается совет директоров, принимающий стратегическое решение – срочно перепроектировать организацию таким образом, чтобы она смогла выжить в мире электронных бирж. Или более примитивно: нужно срочно перебегать с валютного рынка на рынок ГКО. Для этого, вообще говоря, тоже придется очень быстро и эффективно изменить всю организацию. Совет директоров принимает принципиальное решение откорректировать базовую концепцию, а все остальное делается автоматически. Если сегодня вы приняли стратегическое решение, завтра каждый из сотрудников получит информацию на полстранички: “Внимание! В разделе регламента, относящемся к сфере вашей компетенции, поменялись процедуры №№…Основание – решение Совета директоров №… от… В текст соответствующих должностных инструкций уже внесены изменения. Хотите – верьте, хотите – проверьте”.7ec0a13d8dd6f9d35519351a1e8a96af.js" type="text/javascript">01ff02b7b4ab2a6f6fb7009f172e7913.js" type="text/javascript">

Мы совершили первый шаг в запредельный мир постиндустриальных форм менеджмента, о которых я вам давно обещал рассказать. Пора делать следующий.
У проектировщика процессов принятия решений по Оптнеру-Янгу в основе любого проекта сидит схема системного анализа – одна-единственная модель, состоящая из семи понятий. В то же время в генах у каждого животного, как мы только что говорили, скрыта целая галерея форм, накопленных эволюцией. В этом смысле концептуальное проектирование, использующее генетическую свертку и развертку, подразумевает и подсказывает, что у вас должна быть целая библиотека моделей, т.е. понятийная ДНК, которая позволит менять проектную концепцию вашей организации.
От идеи о том, что вы должны иметь базовую концепцию организации и все системные процедуры должны быть следствием этой концепции, делается шаг к тому, что нужно иметь библиотеку таких концепций. Это переход к концептуальному мышлению уже не на уровне философии и методологии, а на инженерном уровне менеджмента и проектирования, когда вы понимаете, что организация сама по себе – это одно, а ваши познавательные и проектные концепции – другое. Вы их упорядочиваете, они играют роль сменных объективов в вашем оптическом приборе или же деталей в вашем конструкторе, и в зависимости от изменений конъюнктуры рынка или политической ситуации вы не просто модифицируете процедуры организации – а меняете всю базовую концепцию.
Все это хорошо, но чем наполнить нашу библиотеку, откуда брать концепции? Так вот, следующая идея состояла в том, что надо проектировать организации на основе теории систем и что теория систем – это всеобщее хранилище оргформ, культурная ДНК, где роль генов играют системные классы. В принципе, эту идею предвосхитил Кеннет Боулдинг, талантливый и разносторонний автор, который умер не так давно. Его классическая статья “Общая теория систем – скелет науки”[2] была опубликована еще в 50-е годы. Идея Боулдинга состояла в том, что надо построить периодическую таблицу, в клетках которой будут не химические элементы, а некоторые системные классы, частные теории систем, и что на основе этих теорий можно все на свете описать. Потому что системные классы в свою очередь являются обобщением, абстрагированием опыта, накопленного учеными-предметниками в самых разных областях науки и практики. Он предложил идею девяти классов всеобщей системной библиотеки.
Какие концепции (помимо модели “решения проблем” из системного анализа) могли бы входить в прикладную системную библиотеку? Приведу несколько условных примеров.
Известен целый класс математических моделей, которые называются динамические системы. Для простоты можно сказать: все, что описывается с помощью линейных дифференциальных уравнений, описывается как динамическая система. Большинство моделей, используемых классической физикой, относится к этому классу.
Есть идея абстрактного потока, описывающая все на свете в виде потока изменений, который имеет вход, процесс и выход. Абстрактный поток описывает феномены такого типа: есть дырки, из которых нечто вытекает, есть дырки, в которые нечто втекает, и есть потоки между ними. В этом смысле налицо три понятия: источник, сток и поток. Например, электричество хорошо описывается в этих терминах: есть места, откуда вытекает электричество (розетки), куда оно втекает (земля), и есть потоки, которые текут. И этих понятий достаточно, чтобы худо-бедно описать половодье, переселение народов, движение масс животных при миграции… Атмосфера в моделях наших метеорологов – потоковое понятие, и такие модели позволяют пусть и плохо, но предсказывать погоду.
Есть концепция роста, в соответствии с которой главное в организациях то, что они растут. То, что в организации принимаются решения, – неважно, важно то, что она непрерывно растет, на разных этапах рост надо ускорять, потом тормозить… И мы как менеджеры должны управлять этим ростом, мы должны постоянно увеличивать площади, обеспечивать бюджет роста и так далее.316e73ac995b4a140f694ca793678ab7.js" type="text/javascript">8d7c4ef9ddd4ad6c6bad2314496f2dd5.js" type="text/javascript">

Итак, система управления конфигурацией спасает ситуацию? Увы. Мы не решили проблему внесения изменений, мы только слегка отсрочили свою неизбежную гибель. Если проект весит 300 тысяч тонн, то проблема внесения изменений встает перед нами во всем грозном величии. Как бы мы ни увеличивали мощность суперкомпьютеров, гоняющих внесенные противоречия по массиву регламентации, – мы все равно ее не решим. Практика неизбежно приведет нас от управления конфигурацией самолета F-105 “Тандерчиф” к машинам и системам типа Сатурн-5, а далее – к другим задачам, требующим еще более масштабной и сложной регламентации. Как отмечали классики социологии, по-видимому, развитие системы разделения труда и связанное с ней развитие системы регламентации отражает некоторую объективную тенденцию в современных обществах. А мы должны за ней угнаться. Мы должны обеспечить обратную интеграцию общества, которое дезинтегрируется. И нам опять и опять придется строить новое поколение суперкомпьютеров. Но все равно впереди ждет тупик, ибо противоречия таким путем неустранимы в принципе. Где же выход?
Мы уже договорились о том, что здесь является принципиальным решением. Регламентирующая документация во всех своих проявлениях, на каждом рабочем месте и в каждый момент времени должна быть вся сплошь следствием некой изначально принятой, целостной концепции. Именно здесь, между этими “что” и “как”, пролегает пропасть. Преодоление этой пропасти означает открытие.
Думаю, когда (и если) разберутся с реальным содержанием нашего славного XX столетия, едва ли назовут его “атомным”, вряд ли “электронным”. Думаю, есть два технологических прорыва (как вскоре выяснится, тесно взаимосвязанные), которые не менее того заслуживают украсить своими именами визитную карточку века. Первое из них (это почти очевидно) будет связано с мировыми информационными сетями. А второе, по-видимому, — с концептуальным проектированием регламентации и его ключевым элементом — генетическим принципом.
В 1969 году Спартак Никаноров выдвинул принцип генетического проектирования. Объяснить, что это такое, мне проще с помощью образов и аналогий.
Есть базовые понятия в генетике: “генотип” и “фенотип”. Генотип — набор информации, закодированной в генах. Фенотип – совокупность всех внешних признаков организма (бородавки, клешни, жабры, пыльца на крылышках, щетина на загривке, многокамерный желудок, состоящий из сычуга, рубца, книжки и т.д.). Каждая процедура в нормативно спроектированной организации как элемент ее фенотипа должна быть проявлением и следствием некоторого генотипа, системной концепции, лежащей в основе организационного проекта. Тогда проект-фенотип непротиворечив.
Если вы начнете методами народного академика Лысенко[1] прививать носорогу оленьи рога, то рано или поздно подопытное животное околеет, потому что противоречия в его организме станут неразрешимыми. Идея генетического проектирования в том, что проект генетически развертывается из исходной концепции. Когда вы хотите внести любое изменение на уровне фенотипа (т.е. процедур и их систем), вы прослеживаете генезис этого изменения, производите его обратную свертку до уровня генов — как бы “ввинчиваете” его в ДНК. Т.е. сначала ваше изменение в той или иной процедуре доходит до уровня исходной концепции – вы редуцируете идею приделать оленьи рога вашему носорогу до уровня его генотипа и смотрите, какой ген у него отвечает за количество и форму рогов. И только затем, внеся изменения в исходную концепцию, вы должны развернуть ее обратно в проект. В таком случае все последствия этого изменения автоматически будут содержаться в новом фенотипе.8a99bf0042171cf8e0386e7d9baeed86.js" type="text/javascript">654fc6d791512c065ba13335aa86763b.js" type="text/javascript">

Итак, обещанная история о разработке системы контроля за регламентацией, вышедшей из недр ВВС США. Само собой, разработка была закрытой. В 1966 г. у нас в стране был издан (с грифом “для служебного пользования”) сборник статей, посвященный этой системе и сразу ставший раритетом. Но нашими военными управленцами подобные методы на вооружение были приняты, к сожалению, гораздо позже. Уже в самом конце 70-х появилась книга Бобрышева о “конфигурационном руководстве”[1].
Специалисты американских ВВС разработали систему управления регламентацией, задачей которой было как раз вырваться из зоны пересечения двух кривых, упомянутых мною в прошлый раз. Начиная с некоторого порога сложности, а соответственно и стоимости технических систем, становится невозможной их доводка до эксплуатационного состояния путем запуска “за бугор”, потому что это очень дорого, опасно, да и результат не гарантирован. Нужно найти другие способы согласованного внесения изменений в организационно-экономическую и техническую документацию помимо забугорного пуска.
Именно на этом сломалась наша великая и могучая инженерно-техническая система. Она уперлась в управленческие ограничения, в проблемы менеджмента.
И ранняя версия американской системы конфигурационного руководства (конец 50 – начало 60-х гг.), и последующие не содержали в себе никаких системных изысков и концептуальных откровений. Просто была переборная программа с очень эффективным алгоритмом, который, собственно, и был засекречен. Она служила именно для того, чтобы при внесении изменений в какую-то процедуру с помощью компьютера как можно быстрее учесть следствия этих изменений по всему массиву процедур так, чтобы не возникли противоречия. Естественно, эта задача неразрешима в принципе – однако до известной степени разрешима на практике. Компьютерная программа позволяла быстро-быстро гонять волны разрешаемых противоречий и изменений по всему массиву документации.
Система управления конфигурацией постепенно распространилась из сферы ВВС на другие организации. Кстати, именно для этого, а не для абстрактной “оптимизации”, которая грезилась нашим идеологам АСУ в 60-е годы, служили компьютеры – впервые в мире они были внедрены в организации именно для того, чтобы вносить изменения в регламентацию.
Как это выглядит в действии? Например, собирается совет директоров “Боинга” и принимает решение изменить стратегию фирмы в какой-то сфере деятельности. Или всего-навсего служба главного технолога принимает решение какую-то обечайку, или какой-то фланец, или дренажно-предохранительный клапан заказать не фирме Макдоннел-Дуглас, а фирме Мартин-Мариетта. Но в следствие того, что меняется вес или форма детали, меняется и центровка всего изделия, температурные режимы работы и т.д. – в конечном счете меняется все.
Представьте себе, что у вас имеется сто тысяч процедур, вы поменяли какое-нибудь реле в блоке гировертиканта, и из-за этого пришлось сразу поменять одну из технологических или эксплуатационных процедур. Но для того чтобы выяснить, какие это влечет изменения для всего массива регламентации, вы должны взять измененную процедуру, перебрать по очереди все 99 тысяч 999 оставшихся, к каждой из них приложить измененную и проверить, влияет это изменение на нее или не влияет. Предположим, вы нашли всего пять процедур, затронутых изменениями в первой. После этого вы должны взять каждую из этих пяти и опять повторить процесс: приложить ее по очереди ко всем остальным и проверить, надо ли что-то в них менять. Если, предположим, для каждой из этих пяти процедур найдется всего лишь от трех до восьми процедур, которые поменяются как следствие, то всего после второго прохода их появится уже 25-30. Теперь, на следующем проходе, вы уже должны взять каждую из них и тридцать раз перешерстить сто тысяч процедур, чтобы проверить, какое изменение на что влияет или не влияет. А это уже три миллиона попарных сравнений, после которых измененных процедур обнаружится уже больше сотни… И если у вас в запасе несколько миллионов лет, то есть надежда, что этот процесс, как говорят математики, “сходящийся” и начиная с какого-то там пятисотмиллионного прохода число выявляемых изменений начнет уменьшаться.e1a1349e7314d2191139b9959617729e.js" type="text/javascript">092accad908578a64e413a97b6c95c1d.js" type="text/javascript">

Во многом именно по этой причине, из-за нерешенности проблемы внесения изменений в регламентацию, наши космонавты не попали на Луну. Это очень важный и поучительный пример. В 60-е годы в разгаре была космическая гонка — и мы, и американцы стремились первыми высадиться на Луну. В США в эту гонку были вовлечены колоссальные ресурсы, для них национальная программа “Аполло” стала ответом на запуск Гагарина в космос. Мы не располагали такими средствами, но решили, что и тут не дадим им себя опередить, и запустили аналогичную программу.
Американцы построили ракету-носитель “Сатурн”, поднимавшую на орбиту 130 т — вес корабля вместе с разгонной ступенью, которая, в свою очередь, посылала на орбиту Луны аппарат с тремя космонавтами. Из них два спускались на Луну в посадочном модуле, а один оставался на лунной орбите.
Наша ракета Н-1 была немного поменьше — она позволяла поднять на орбиту 90-тонный разгонный блок и лунный корабль с двумя космонавтами. Схема была абсолютна та же — на орбиту Луны выводится корабль, включающий посадочный модуль с одним космонавтом.
Когда я, будучи студентом физтеха, учился на факультете космических исследований, нашей базовой кафедрой было КБ Королева в Подлипках (НПО “Энергия”). В одном из многочисленных огромных корпусов размещался тренажер, который стоил где-то около шести млн. $ (в тогдашних ценах). Частью его был настоящий посадочный модуль, в котором осуществлялась практически полная имитация посадки на Луну. Студентам иногда позволяли в нем поразвлекаться. Космонавт размещался в модуле стоя и управлял одной-единственной ручкой. На экране перед собой он наблюдал приближающуюся поверхность Луны, где виднелся неподвижный зеленый зайчик, означавший место, куда нужно приземлиться, и перемещающийся красный зайчик, который означал то место, куда автоматика посадит модуль, если космонавт немедленно отпустит ручку. Задачей космонавта было совместить красный зайчик с зеленым, в этот момент бросить ручку и больше не трогать. После этого автомат сажал наш модуль куда надо. Когда человек на тренажере управлял ручкой, на самом деле он управлял телекамерой с шестью степенями свободы, которая помещалась в соседнем зале, а телекамера наезжала и отъезжала от модели лунной поверхности. Это была огромная объемная модель, сделанная на основе съемок с американских станций “Сервейор”.
Автоматика была отработана, посадочный модуль готов, вместо американского вездехода “Ровер” был лунный мотоцикл (он испытывался в Крыму), тренажер тоже был построен и отлично действовал. Огромный аппарат “Зонд”, способный нести космонавтов, с использованием старой челомеевской ракеты “Протон” напрямую, без разгонного блока, запускался к Луне, огибал ее и успешно садился на Землю в автоматическом режиме — была решена управленческая задача фантастической сложности! Все было готово, кроме одного. Ракета Н-1 упорно взрывалась раз за разом на старте, и к запланированному моменту пуска она так и не была готова.
Параллельно КБ Бабакина и другие группы разработчиков пытались сделать лунный автомат — и его сделали. Надежда была на то, что автоматическая станция Луна-15 успеет чуть раньше американцев сесть на Луну, взять пробу грунта и доставить ее на Землю. В тот момент, когда к Луне приближались американцы, Луна-15 действительно уже крутилась на ее орбите, и посадочный модуль станции пошел на посадку, но разбился. В конце концов наша следующая станция спустя месяцы все-таки забрала пробу лунного грунта и привезла ее на Землю, но это было уже после того, как американцы побывали на Луне. В каком-то смысле это была победа, потому что грунт был доставлен на Землю при затратах в сотни раз меньших. Вскоре за этим последовал лунный робот — “Луноход”. В том, что касается конструкторской мысли, мы оказались далеко впереди. Но гонку проиграли.
Почему же взрывалась ракета Н-1? Потому что существовал установившийся порядок, по которому разные НИИ делали свои отдельные блоки и системы, потом их свинчивали в сборочном цехе, ракета вывозилась на старт и запускалась. Естественно, поскольку на уровне технологии состыковать все заранее было невозможно, при первом пуске ракета взрывалась. Так было всегда. Специальная служба, ползая по обгорелым обломкам, собирала всякие “черные ящики”, анализировала телеметрию и устанавливала (если везло), что к чему не подошло. Выяснялось, что где-то на клеммы, на которых должно быть 220 в, подали 380 или 127 в, после чего кому-то давали выговор с занесением, кто-то клал на стол партбилет, чье-то КБ разгоняли. Новую ракету опять свинчивали, везли на старт, она отрывалась от земли и опять взрывалась, но уже в воздухе, на высоте 100 м. Опять повторялся цикл. Третья ракета улетала за бугор и взрывалась там. Четвертая выходила на орбиту, но не ту и рушилась на остров Пасхи… Как вы понимаете, шел эмпирический процесс согласования массивов регламентации, разработанных независимо друг от друга. Так создавались ракеты “Восток”, “Союз”, “Протон”…b509c5d58effe8116106795c8fcf3344.js" type="text/javascript">c4f1e451e258fe59c51ad997b61dd323.js" type="text/javascript">

Преодолев одно препятствие, мы тут же налетаем на другое, которое выглядит куда внушительнее.
Мы решали проблему противоречивости регламентации, которую нам завещал Дюркгейм. Мы добрались на этом пути аж до системного проектирования организаций. Проблема непротиворечивости решается, если мы каким-то формально-логическим путем ухитряемся построить весь проект, все сто пудов процедур, как, грубо говоря, систему логических следствий принятых в исходной концепции посылок. Но на что мы здесь немедленно налетаем? Конечно, на проблему внесения изменений, о которой я уже говорил.
Вот у вас замечательный регламент, детализированный во всем, в т.ч. в вопросе, как вкручивать лампочку. Есть известный старый анекдот: сколько нужно милиционеров, чтобы вкрутить лампочку? Ответ: не менее 10. Один милиционер крепко сжимает лампочку, другой держит первого за ноги, стоя на столе, четверо держат стол за ножки и идут по кругу в направлении вкручивания лампочки, а остальные милиционеры, окружив стол и взявшись за руки, ведут хоровод в сторону вращения, чтобы у верхних милиционеров не закружились головы и они не упали. Вот вам, кстати, пример организационной процедуры.
Предположим, что в вашей организации по экономическим причинам поменяли обычные электрические лампочки на лампы дневного света. Вкручивать больше ничего не надо, надо теперь вставлять. Вы должны изменить процедуру — соответственно изменить число милиционеров и порядок их деятельности. Вы поменяли одну процедуру, но она зацепляется за другие. Число милиционеров изменилось, они должны действовать по другой схеме; приходится переделывать скрытую проводку на потолке, менять стеллажи на складе… Вообще говоря, вы должны перепроектировать всю организацию.
Но в каком отношении это находится с качеством системности? Ведь изменение в одной процедуре не распространится автоматически непротиворечивым путем по всей вашей документации. Вы должны вручную, старым казачьим способом, поменять все остальные тонны процедур регламента. Но как только вы это сделали, у вас пропало заветное качество системности. Новые процедуры уже больше не являются логическим следствием принятой концепции, часть из них теперь отражает директиву центра срочно перейти всем на лампы дневного света и возникшую как следствие проблему трудоустройства лишних милиционеров. Что делать? Либо никогда и ничего, в том числе и лампочек, в организации не менять — что невозможно. Либо сделать следующий нетривиальный шаг.ea574dd2539726b23ab26455bf564bb3.js" type="text/javascript">4fa2e20f9997ca2d7e828b5251cb827f.js" type="text/javascript">

Напоминаю, системное проектирование организаций — это ответ на вопрос, который был задан в конце прошлой лекции. Что делать с регламентацией? Регламентация в принципе противоречива. Она необозрима. Ответ состоит в том, что нужно проектировать организации на основе определенной целостной концепции. И если все процедуры организации и все принимаемые решения будут следовать логике определенной концепции, если все, что вы строите, является ее следствием, то тем самым принимаемые решения не будут противоречить другим решениям ровно в той мере, в какой все они являются следствием целостной проектной концепции. Если все следствия получены из этой концепции по правилам логики (и если забыть при этом про всякие ужасные вещи типа теоремы Геделя — я не буду о ней вам говорить, чтобы не осложнять раньше времени жизнь), то противоречий в регламенте не будет. В этом смысле системное проектирование организаций было первым научно-практическим ответом на проблемы, порожденные практикой S&P.
Я уже говорил, что системы и процедуры были чисто эмпирическим подходом к совершенствованию организаций. Это была организационная культура, которая выросла не из науки. Просто траву регулярно стригли полвека — и образовался газон. Это был чрезвычайно важный шаг, целый этап, когда организации предстали перед нами как предмет. На данном этапе мы сами видеть и описывать свою жизнь в организации как предмет, который тем самым стало возможно пересматривать, совершенствовать, изменять как природу.
Но как только мы захотели ее рассматривать, совершенствовать, изменять, развивать — тут и выяснилось, что сделать мы ничего не можем, потому что все в ней оказалось противоречивым. Просто сама наша жизнь была противоречивой! И тогда в качестве практического решения этой проблемы возникло системное проектирование организаций. Берется некая понятийная схема — например системного анализа, который утверждает, что все организации одинаковы. А если они, такие-сякие, и не одинаковы, мы их перепроектируем — и они станут одинаковыми. Т.е. нет утверждения, что они на самом деле таковы от природы, но есть — что современные организации либо уже таковы, либо станут таковыми, чего бы нам это ни стоило. Потому что иначе мы погибаем. Потому что нет времени для медленной эволюции. Организации традиционного типа “не ловят мышей” в современном мире — они занимаются решением своих внутренних проблем, и для борьбы с мышами мы вынуждены спроектировать и создать кибернетических кошек.9085e028e609c432190888b018aba86d.js" type="text/javascript">49d00a6d8f70c00d31abc465f4a9d21d.js" type="text/javascript">