Фактически вся описанная там интеграция сводится к созданию вспомогательного механизма, который (если все будут обращаться с ним правильно и не пытаться его обманывать уже на этапе ввода данных) явится не более чем “ускорителем” получения сводных результатов после долгого процесса ввода в машину исходных и конечных записей в согласованном формате. Однако ручной ввод данных в специализированном подразделении или даже просто отделенный от процесса реальной работы вообще не может быть приемлемым для любой организации по отечественному опыту оценки отношения к своей работе и исполнителей, и руководителей.

Это означает, что для успешного создания управляющих систем необходимо обеспечить сбор всех сведений обо всех работах и реальной деятельности всех работников, связанных с текущим выполнением той или иной производственной задачи.

Концепция сбора всех, подчеркиваем, всех сведений обо всех работах, проводящихся на современном предприятии, без какого бы то ни было специального ввода данных, сбора сведений, которые нельзя исказить иначе как путем целенаправленного вредительства (которое откроется очень быстро), сведений из которых можно в реальном времени иметь полную информацию (именно информацию, как результат контекстного выбора (Просим читателя вспомнить определение информации из гл. 5 и реальное соотношение этого термина с понятием сообщения.)) давно разработана и опробована [6].

Эта та самая концепция обеспечения выполнения руководителем своей руководящей и контролирующей роли в организационном управлении, о которой мы говорили еще во введении, концепция выработки информационного обеспечения для тяжелой повседневной работы. Это обеспечение работы, требующей, по мере необходимости, знания “всего” что происходит в организации, в каждой ее точке, и на каждом рабочем месте. “Информинг” в самом прямом смысле – выработка для руководителя информации, того, что впрямую не содержится в сообщениях, автоматически получаемых со всех рабочих мест.

Почему в названии раздела употреблено слово “назад”?

С чего же необходимо начинать организацию управления в концепции информинга? Как вообще можно представить себе организацию полностью контролируемого индивидуального рабочего места в любой организации или совокупности организаций интересующего нас проектно-производственного профиля, к которому в равной степени можно отнести и любое предприятие холдинга, и сам холдинг?

В одном варианте можно провести огромные затраты, предоставить максимальные (но, конечно, разумно пропорциональные потребностям работы) программные и технические удобства деятельности, обеспечить всю мыслимую эргономику и психологический комфорт и ожидать результатов, т.е. начать с создания САПР. Если организация очень богатая – можно автоматизировать каждого. Если еще богаче – потом купить сеть и центральную машину, а в результате всего получать от исполнителей постоянные требования по модернизации устаревшей техники и закупке нового программного обеспечения.

Это так называемый вариант островной автоматизации “снизу”. Он хорош для всех, кроме руководителя, ибо не дает ему ничего для управления. Что “внизу” делают исполнители, становится непонятным не только ему, но и непосредственным руководителям на местах, ибо для того, чтобы понять работу сотрудника, посмотрев, что именно он делает в данный момент, в случае с САПР требуется более чем высокая квалификация. Профессионалы системного уровня назовут еще множество проблем – узость возможностей любой САПР, дороговизну ее базы данных, быстроту моральной смерти и проч.

Но вывод в таком случае всегда один – автоматизация снизу удобна для развлечения сотрудников и приобщения их к культуре работы. Она быстро исчерпывает свои возможности, а для управления не дает абсолютно ничего.

В другом варианте можно начинать подобные работы “сверху”. Это вариант компьютеров на столах начальников, с дисплеями, на которых принципиально нечего смотреть. Кстати, это вариант более дешевый – компьютеры без САПРовских возможностей, достаточно долго не устаревают даже морально.

Для реальной работы таких систем приходится начинать с чего-нибудь типа планирования и контроля, с созданием штата машинисток для ввода информации и программистов, которые что-то с ней делают – с организации управления на любых рассмотренных выше принципах от административно-директивного до контроллинга. В конечном итоге руководитель глубокомысленно смотрит на конечные показатели расчетов и принимает решения по данным, смысл формирования которых ему остается недоступен.

Ситуация полностью аналогична многократно описанной для научных исследований: когда один исследователь получает данные, а другой их обрабатывает, то результаты можно интерпретировать как угодно, желательно только знать, что является приемлемым вариантом.

Реальный опыт работы [6] показал, что начинать надо с организации работы всех исполнителей таким образом, чтобы ни один документ, ни один результат любого вида деятельности, связанной с основным проектно-производственным процессом, не мог быть выполнен, получен или передан на следующий этап работ иначе, чем с применением компьютеров и сети их связи. Только электронный документ должен считаться подлинником.

Необходимым условием такой организации является полное исключение возможности предварительного выполнения работы с последующим ее вводом в машину, жесткий синтаксический и возможно жесткий семантический контроль (И синтаксис и семантика здесь относятся не только к текстовым документам, но к любым другим – чертежным конструкторским, технологическим, нормативным, плановым и т.п.) всех разрабатываемых документов непосредственно в самой обеспечивающей разработку компьютерной сети.

Все сказанное вполне реализуемо на современном уровне развития вычислительной техники. Практически это эквивалентно встраиванию вычислительной сети в управляемую организацию как ее абсолютно неотъемлемой части. Обращаем внимание читателя, что тем самым мы добиваемся реализации важнейшего для нас принципа – отказа от понятия или требования наличия модели организации в компьютере.

Все, что есть в компьютерной сети, в нашем случае является самой организацией, ее даже не точным представлением, а единственной реалией на уровне потоков сообщений. Ничего более для организации управления такой организацией нет и быть не может. Реализация же управления, как и во всех других случаях, связана с материальными, территориальными и другими перемещениями, наказаниями и поощрением персонала, причем результаты всех этих действий неизбежно отразятся в изменении конфигурации и объемов потоков сообщений в сети.

Тем самым исключается необходимость вникать при решении управленческих задач в их внутреннюю сущность иначе, чем на уровне выбора предложенных альтернатив. Плановый отдел самостоятельно выбирает все необходимые методы своей работы от чисто ручного и умозрительного до алгоритмически-оптимизационного и несет ответственность за качество и результат предложенных решений. В такой постановке работ достаточно быстро решаются все проблемы выбора оптимизационного, модельного или иного подхода к планированию.

Для сокращения объема публикации перечислим ряд дополнительных организационных моментов, рассмотрение которых частично проведем в других разделах этой главы или оставим для последующего издания:

Теперь можно провести несколько сравнений реализации организационного управления на основе предлагаемого подхода и контроллинга.

В соответствии с [5]

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

Далее:

…Система раннего предупреждения на базе компьютерной техники может быть прямо или косвенно связана с компьютеризованной системой, что позволяет посредством альтернативных расчетов определять воздействие неожиданно наступившего события или ставшего вероятным развития процесса на отдельные планы и цели всего предприятия...

Вся концепция информинга, как обеспечения организационного управления направлена именно на первичность и целостность сетевых связей. Указанная выше терминология раннего предупреждения говорит о ее реализации в концепции “островной автоматизации”, отвергнутой в нашей стране лет 15-20 назад. Хотя ее альтернатива не реализована до сих пор, это еще не повод для пропаганды возврата к концепции создания отдельных подсистем.

Или, например, следующее утверждение:

…Для такой внутренней области наблюдения, как производство, это можно сделать посредством сбора, анализа, интеграции и передачи данных о производственных процессах, получаемых при помощи внутрипроизводственных автоматизированных систем, в которых данные об объемах, качестве, сроках производства продукции трансформируются в показатели издержек, и их воздействие отражается в калькуляциях по заказам, в расчетах прибыли за период и жизненного цикла продуктов…

Для этого в концепции информинга достаточно иметь полноценные технологические маршрутные карты с отметкой ОТК вместе с готовыми изделиями, а не самодельные “маршрутки”. Отражать же реальные издержки в калькуляциях по заказам является действием некорректным – расчетная цена меняться не должна. В концепции информинга речь здесь может идти только о сборе сообщений для выработки информации о потерях или низком качестве ценового планирования на том или ином этапе.

Возможны и многие другие примеры, но главное практическое отличие информинга от контроллинга по-видимому уже иллюстрировано.

В принципе, все сказанное выше об информинге является составной частью давно известной теории ИСУ [13, 14], которая в своей прикладной формулировке обеспечивает конструктивное, инженерное понимание процедуры создания организационного управления.

Как указано в [14] наличие в сети предприятия всех возможных сообщений и получение на их основе информации, впрямую в этих сообщениях не содержащейся, обеспечивает предпосылки создания интеллектуальной управляющей системы, т.е. перспективу порождения некоторого “аналитического помощника” для управляющего.

Пока это еще только одно из направлений научных исследований, но уже сегодня можно указать, что согласно положениям прикладной теории ИСУ, интеллектуальная система управления сложным объектом имеет смысл, когда она является автоматической, т.е. способной принимать решение быстрее и/или лучше человека в сфере своего существования.

В [14], говоря об ИСУ, мы упоминали о некорректности постановки вопроса о создании больших автоматизированных систем управления, в которых человек используется как лицо, принимающее окончательные решения, ибо системы управления высокого уровня целесообразны только там, где человек и так уже не справляется с обязанностями управителя. Действительно, либо мы создаем систему, принимающую решения быстрее и лучше нас, либо систему, слишком примитивную, чтобы доверить ей управление, и контролируем все ее решения на уровне собственной интуиции. Тем самым управляющая система переводится в разряд “информационно – советующих” разработок, рекомендации которых обычно не пригодны к использованию без перепроверки, которую, в общем случае, невозможно организовать.

В настоящем разделе мы рассматриваем основу для создания обоих упомянутых вариантов управляющих систем – “информационно-порождающую” основу обеспечения управленческих решений. Эта основа равно пригодна для перспективного создания системы как обеспечивающей управление организацией для некоторого руководителя, так и автоматической, ибо просто более не существует никаких сведений о состоянии организации, нужных для управления ею, кроме тех, что автоматически возникают в ее сетевом варианте.

Это положение тем более справедливо, что наиболее сложным для компенсации за счет управления возмущением является возмущение со стороны внешнего мира, а оно проявляется через изменение динамики потоков сообщений в управляемом объекте.

Отсюда следует логический вывод о том, что компенсация возмущающих воздействий внешнего мира возможна, в основном, только за счет разомкнутой системы управления. Действительно, восстановление динамики потока сообщений в сети, необходимое для возвращения объекта в устойчивое состояние, возможно за счет перестройки его структуры, изменения внутренних отношений между подсистемами и, уже только в последнюю очередь, - за счет воздействия на внешний мир. Отметим, что под устойчивостью здесь понимается то состояние, в котором мы видим объект, когда он справляется с возложенными на него функциями, в том числе и функциями своего развития – изменением функции расстановки (Здесь функцией расстановки мы называем способ указания взаимосвязей между записями в базе данных.) в своих базах данных.

Управление на основе анализа динамики движения сообщений, т.е. управление по изменению объемов пересылок внутри и между подсистемами в единицу времени, предполагает непрерывный контроль этих пересылок как по синтаксису сообщений, так и по темпам их порождения и обработки.

Такой контроль является необходимой составной частью семантического анализа сообщений при их использовании для порождения информации, обеспечивающей принятие управляющих решений. Без него основная часть семантики (как информации порожденной из сообщения) будет безвозвратно утеряна и направленность управляющих решений может не соответствовать цели управления.

Для широкого класса сложных систем, представимых семантическими конструкциями, а таковыми являются все системы интересующего нас уровня социального института, прикладная теория ИСУ предлагает использование указанной выше технологии как “метода организации структуры управляемого объекта, ориентированной на поддержание семантического уровня общения”.

Изложение метода начнем с рассмотрения иллюстративной схемы потоков сообщений между выделенным набором подсистем (рис.8.1). Подсистемы A,B,C,D в общем случае имеют взаимосвязь в составе шести двунаправленных потоков F с соответствующей индексацией.

Рис.8.1. Иллюстративная схема потоков сообщений в наборе подсистем.

Такой обмен осуществляется, в общем случае, на уровне функционирования взаимосвязанных “автоматизированных рабочих мест” или иных обрабатывающих и производящих подсистем. Эти подсистемы связанны с некоторым сервером или центральным вычислителем, его базами, и пользуются его вычислительными мощностями. Более того, они могут использовать сервер как промежуточный буфер или базу для хранения массивов выработанных данных в той или иной структуре.

При общей приемлемости и кажущейся достаточности такой схемы организации работ и обработки сообщений, в ней теряется составляющая, необходимая для принятия управляющих решений – семантика “второго порядка”. В нашей терминологии можно сказать, что теряется возможность выработки информации на основе получаемых сообщений, в том числе и информации, характеризующей динамику потока сообщений, динамику взаимодействия. Здесь нам пока достаточно понятийного осмысления динамики потока сообщений, как процесса его изменения во времени и, соответственно, “процесса изменения процесса его изменения”.

Следовательно, для управления системно-сложным объектом требуется создание схемы организации работы с сообщениями и получения информации. Здесь нас должно интересовать взаимодействие управляющей системы с объектом управления, некоторая структура, обеспечивающая возможность накопления и использования выработанной информации для достижения возможности принятия информационно-обеспеченных управляющих решений.

Такого рода структура должна быть ориентирована на встраивание вычислительной среды в состав управляемого объекта или, другими словами, на адресный перехват потоков сообщений с возможностью определения их динамических характеристик.

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

Это означает, что в компьютере постоянно работает программа адресного сбора динамических характеристик потоков сообщений для выработки управляющей информации (рис.8.2). Каждое рабочее место, вернее каждое сообщение между ними, полностью и постоянно отслеживается по этим характеристикам. Любое изменение динамики потоков сообщений, непредусмотренное соответствующей технологией работ (Здесь речь идет уже о необходимости иметь в составе традиционной технологии еще и технологию, связанную с временными характеристиками работ, их обеспечением справочным материалом, консультациями и проч. Все это все равно принципиально существует в любом предприятии (в частности, классификатор ЕСКД), но обычно совсем не в полной мере используется для организационного управления. Экономия на мелочах ведет к потере управляемости предприятием.), является сигналом для начала выработки управляющих решений.

Рис. 8.2. Фрагмент схемы сбора динамической информации

Затраты на дополнительную обработку сообщений могут быть довольно значительными, однако только они и дают контекстную информацию, существенно необходимую для достижения “информационно-обеспеченного” управления. Фактически, при такой постановке наличествует практически вся информация, которая может быть собрана и использована при автоматическом принятии управляющих решений, что является неотъемлемым компонентом автоматической системы, имеющей право после ее создания называться интеллектуальной.

Действительно “семантика динамики”, семантика “второго порядка” дает наблюдаемость системы, недостижимую никаким другим способом. Семантика “первого порядка”, все, что может быть известно не о процессе выработки, но о самом продукте также полностью наличествует в компьютере с достоверностью в точности равной документу, сопровождающему продукт, а большего достигнуть уже нельзя, вернее нужно уже не управляющему, а, например, главному конструктору.

Достаточно очевидно, что реализация любой системы начинается не в полном объеме ее подсистем, а с некоторого выбранного их количественно-качественного состава. Основным критерием такого выбора вполне естественно является желание обеспечить максимальное обеспечение подсистем внутренними пересылками сообщений при возможной минимизации их связей с внешним миром. В контексте поставленной цели предлагается подход к декомпозиции системы на подсистемы, выбор которых можно описать следующей задачей.

Пусть объект, как система, представляется сетью U, состоящей из узлов (подсистем) P, так, что:

,

Для некоторого подмножества подсистем:

,

необходимо найти матрицу ?’ такую, что взаимный обмен сообщениями между входящими в нее объектами максимален и, следовательно, удовлетворяющую эффективному, относительно задачи, сочетанию двух критериев:

Из физических соображений указанное выше требование можно сформулировать в следующем эквивалентном виде: обмен со средой, окружающей выбранный набор подсистем, должен быть минимален, т.е. необходимо найти подмножество подсистем X, содержащееся в U, такое, что:

Практическое решение такой задачи весьма затруднительно и, в общем случае, возможно только полным перебором. В ряде случаев, используя те или иные особенности системы, этот перебор можно сократить.

Итак, если граница сформированного набора подсистем изучаемого объекта разрывает минимум связей подсистем, то мы можем надеяться провести выбор стартового набора подсистем так, чтобы обеспечить наилучшее возможное по предложенному критерию приближение к системно - открытой модели.

При правильном выборе границ объекта обеспечивается принятие решений, минимально зависящих от изменения окружения объекта.

Дополнительное условие на сложность и решение основной задачи не влияет, однако оно формирует структуру взаимодействия с этими потоками, которая, будучи реализована как вычислительная среда, может стать устройством, встроенным в объект и обеспечивающим активное взаимодействие с потоками сообщений через контроль их динамики:

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

В начале 80-х годов в НИИ Электрофизической аппаратуры была начата разработка прикладной системы Текрам [6,7] из разряда “очень больших систем” (Разработка основывалась на использовании мало известной тогда ОС MUMPS – предшественницы нынешней Cache’-технологии. С точки зрения реализации это был рискованный, но положительно завершившийся эксперимент – проектирование крупной информационной системы на базе тогда еще не сформировавшейся практики использования подхода, лучше всего выражаемого в терминологии “теории открытых систем”, в условиях формирования самой этой теории и практики в процессе создания системы.). Это утверждение справедливо, если взять в расчет уникальную динамику предметной области – конструкторско-технологическая подготовка производства крупнейшего предприятия, производящего единичные экземпляры продукции высшего уровня сложности.

Можно представить себе, как изменяются такие объекты, их конечный облик относительно начального замысла (и собственные структуры предприятия и организации работы в нем), но технологию самой системы Текрам менять не потребовалось никогда. Несколько раз сменилась аппаратная база, новые архитектуры (типы) компьютеров подключались даже без остановки системы.

Текрам (рис.8.3) в прикладной постановке был ориентирован на решение задачи обеспечения инженерного варианта управления предприятием, как сложной системой высокого уровня. В соответствии с теорией, прежде всего для поддержки и переработки потоков сообщений был выделен стартовый комплекс взаимосвязанных подсистем, практически реализующий собой минимаксный критерий их выбора.

Тем самым были выделены основные потоки сообщений, подлежащие первоочередному переводу под контроль компьютера с учетом сетевой структуры их взаимодействия (взаимного технологически связанного обеспечения):

• сведения о планируемых работах (портфель заказов);
• сведения о структуре состава изделий, содержащиеся в конструкторских спецификациях;
• сведения об используемых материалах и покупных изделиях;
• данные об организации производственного процесса, получаемые из технологических маршрутных карт.

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

Положительный результат мог быть достигнут только при реализации всех необходимых подсистем такой основы интегрирования в постановке, позволяющей проектировать комплекс инвариантным к конкретной структуре объекта автоматизации.

Как следует из теории, необходимым условием решения этой задачи является такая организация работ, при которой комплексная система не только обеспечивает инструментальную возможность проведения работ, передачу и хранение сообщений, но и понимает их, проводит не только синтаксический, но и семантический контроль первого и второго уровня. Только в этом случае объединение подсистем могло быть проведено на уровне обмена “информацией, а не данными” (Выражение “обмен информацией, а не данными” много лет использовалось практиками как утверждение о “более высокой степени анализа сообщения, сохранении его семантической начинки”. Конечно, без конструктивного определения информации придумать что-нибудь более вразумительное было просто невозможно. Мы рассмотрели этот вопрос во второй части настоящей работы.), вернее сообщениями, из которых можно получить информацию.

Принятые проектные решения показали в опытной эксплуатации правильность выбора исходных принципов организации функционирования и общей идеологии построения системы управления.

Особое внимание пришлось обратить на вопросы синхронизации функционирования отдельных подсистем, их операционной поддержки, т.е. на вопросы системного функционирования интегрированного комплекса.

Основным выводом из результатов опытного функционирования разработанного комплекса подсистем, явился вывод о необходимости создания параллельно с набором выделенных подсистем еще и управляющей системы комплексирования, берущей на себя все системные функции, подобно операционной системе компьютера. Можно утверждать, что в известном смысле различие между такими операционными системами минимально.

Здесь уже на инженерном уровне становится очевидным положение теории о том, что, если мы хотим создать действительно управляющую систему, то должны в качестве датчиков использовать подсистемы автоматизации, поставляющие первичные документы, а в качестве исполнительных механизмов - подсистемы, влияющие на объемы и динамику потоков сообщений объекта управления.

Итак, опыт разработчиков, накопленный при техническом проектировании и эксплуатации комплекса, свидетельствовал о необходимости выделения операционной основы комплексной автоматизации в самостоятельный объект. На этапе рабочего проектирования такая основа была создана и получила название Специализированной Распределенной Производственной Операционной Системы (СРПОС) для комплекса Текрам.

Основная версия Текрам обеспечивала функционально полную автоматизацию ряда работ с выполнением их пользователями в режиме безбумажной технологии на удаленных рабочих местах:

• выдачу и учет номеров разрабатываемых документов по классификатору ЕСКД с сохранением необходимого объема сведений обо всех разработанных документах и обеспечением ведения собственно классификатора ЕСКД;
• ведение ограничительных стандартов предприятия по материалам и покупным изделиям в виде перечней разрешенных записей без необходимости использования кодовых обозначений;
• разработку под синтаксическим и семантическим контролем, а также хранение в базе данных конструкторских спецификаций, перечней элементов, технологических маршрутных карт и других текстовых документов, включая автоматическое получение по ним необходимых сводных документов;
• нормоконтроль исполненных документов в соответствии с предписаниями на функционирование службы нормоконтроля;
• учет и контроль реализации изменений по всем хранящимся конструкторским и технологическим документам;
• учет фактической трудоемкости всех видов выполняемых работ для создания нормативной базы или коррекции имеющейся;
• нормирование по технологической документации всех видов работ для последующего планирования загрузки цехов, оборудования и другое.

Спроектированная СРПОС выполняла целый ряд функций, которые можно разделить на функции организации ведения собственно работ и ведения базы необходимых данных на рабочих местах пользователей Текрам (т.н. внешние функции) и функции поддержки работоспособности самого комплекса (т.н. внутренние функции).

СРПОС была реализована так, чтобы внешние функции выполнялись с участием пользователей с применением различных форм диалога (человек включен в состав подсистем как необходимый исполнительный элемент), а внутренние функции выполнялись с минимальным участием пользователей. Решения разрабатывались вплоть до автоматического функционирования системы в пределах сгенерированной конфигурации технических средств и требуемых возможностей, при условии обеспечения управляемости всех процедур от программного администратора Текрама (человек исключен из управления – здесь фактическим “управителем” может являться план и портфель заказов).

К внешним функциям СРПОС было отнесено обеспечение функционирования рабочих мест Текрама, предоставление средств создания новых подсистем автоматизации. В СРПОС предусматривалась возможность создания новых или изменения назначения сгенерированных ранее рабочих мест, что обеспечивало высокую адаптивность и расширяемость Текрама.

Для организации взаимодействия пользователя с разработанной системой интегрированной автоматизации была выработана концепция, согласно которой набор разрешенных синтаксических и семантических конструкций входных языков пользователей формиррвался на основе подробного анализа их профессионального тезауруса. Учитывая тот факт, что указанный тезаурус не является стабильным множеством дескрипторов, были предусмотрены и средства расширения пользовательских языков в составе СРПОС.

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

Для ведения диалога в состав СРПОС был включен универсальный интерпретатор входных языков пользователей, который использовал расширяемый набор таблиц дескрипторов. Каждая таблица интерпретатора содержала определенный набор дескрипторов, описывающих в своей совокупности профессиональный тезаурус разработчиков заданных документов, классификаторов, словарей или иных подмножеств данных. Предусматривались средства расширения набора таблиц интерпретатора и дескрипторов.

Используя дескрипторы входных языков, пользователи могли вести диалог в командном и программном режимах. Командный режим обеспечивал ввод и немедленное исполнение введенных команд языка с одновременной проверкой синтаксиса и семантики. Программный режим позволял описать повторяющиеся проектировочные процедуры в виде программы специального вида, хранить эти программы в базе и исполнять их по запросам. Проектировочные программы подразделялись на рабочие и библиотечные:

• рабочие программы создавались для однократного выполнения уникальной или единичной проектировочной процедуры и не подлежали хранению;
• библиотечные программы реализовывали универсальные алгоритмы проектирования и часто повторяющиеся последовательности; они были эквивалентны подпрограммам или макросам и хранились в базе длительное время.

Как отмечалось выше, функции всех рабочих мест были реализованы с применением единого универсального интерпретатора входных языков пользователей. Такая универсальность обеспечивалась благодаря наличию программного механизма трехуровневой настройки ядра СРПОС.

На этапе генерации системы при установлении взаимосвязей всех подсистем выполнялась статическая настройка.

Индивидуальная настройка выполнялась на этапе регистрации указанного пользователем рабочего места путем выбора разрешенного состояния ядра.

Наконец, динамическая настройка выполнялась в процессе работы пользователя при выполнении инициирующих действий, таких как изменение режимов работы, переход к работе с новым документом и др.

Ясно, что таким образом поддерживалась на организационном уровне эффективная настройка комплекса на необходимое сочетание терминальных средств и видов работ.

Новые подсистемы, разрабатываемые в составе СРПОС, автоматически интегрировались с имеющимися программными комплексами. Эта возможность обеспечивалась, в том числе и тем, что взаимодействие подсистем в СРПОС достигалось не за счет общепринятых программ обмена данными, входящими в состав программных комплексов, а за счет программного обеспечения ядра системы, которое остается неизменным при подключении к комплексу любых новых подсистем.

Внутренние функции СРПОС можно представить в виде основных классов задач:

• обеспечение функционирования компьютеров и вычислительной сети комплекса Текрам;
• организация распределенной базы данных, создаваемой и поддерживаемой в актуальном состоянии средствами СРПОС;
• системная поддержка всех задач СРПОС, включающая в себя задачи сохранения и восстановления данных, автоматический запуск специальных фоновых задач, контроль состояния технических средств, вычислительной сети и другие функции;
• собственно управление как выработка управляющей информации.

Подчеркнем, что как прообраз ИСУ, Текрам отнюдь не был ориентирован на решение полной задачи автоматического управления. Тем не менее, на его основе были получены (как бы “автоматически”, просто за счет соблюдения “не замыкаемости” его подсистем) все необходимые решения для создания ИСУ объектами класса “общественного института”.

Текрам существовал как система, подлинного объема которой не мог оценить ни один пользователь. Для каждого из них он представлялся лишь технологическим изменением повседневной организации работ – вчера пишем на бумаге, сегодня на экране и только то, что является новым, типовые решения, рамки в спецификациях и прочее компьютер и сам рисовать умеет, так же, как и, например, записывать ГОСТовские обозначения покупных изделий. Аналогично: “вчера ничего не делал и этого никто не заметил – сегодня компьютер учел мое реальное, а не высиженное рабочее время с немыслимой точностью”. Все такие психологические проблемы требовали решения и постепенно решались. Был преодолен критический стартовый порог начального объема необходимой информации – Текрам находился в рабочей эксплуатации.

“Смертельным” обстоятельством для Текрама стала его остановка по обстоятельствам “перестроечного характера”. Системы такого уровня останавливать в получении сообщений (разрешать их прохождение помимо компьютерной сети), ограничивать в выработке информационного обеспечения для управления работами невозможно – они незамедлительно заканчивают цикл своего полезного существования.

В заключение “повести о Текраме”, среди множества его особенностей отметим еще одну – уникальную, как выяснилось в процессе эксплуатации, приспособляемость к изменениям проблемной среды, способность к самосовершенствованию (Как показал опыт, приспособиться нельзя только при прекращении потребности в системе (при прекращении процесса информационного обмена), так как это произошло с Текрамом при перестройке – не смена экономической формации страшна, а развал экономики. И это равно плохо для всех интеллектуальных систем всех уровней, и даже для таких, как Текрам, еще только приближающихся к интеллектуальности.). Так сказать “встроенную способность к имитационному моделированию самого себя”. Но сделаем это уже применительно к обобщенному понятию ИСУ, т.е. считая, что каждое рабочее место вырабатывает, в том числе, и информацию для анализа и формирования сообщений. Поэтому мы имеем терминологическое право излагать последующий материал с использованием термина “информация”.

Для обеспечения постоянного совершенствования сбора и интеграции (обработки) первичных сообщений необходимо предусмотреть наличие некоторого специального аппарата. Учитывая тот факт, что наше понимание инфороминга предполагает организацию обработки сообщений в автоматическом режиме, единственным приемлемым вариантом здесь может явиться создание некоторого программного испытательного стенда.

Представляется вполне возможным, пользуясь упомянутыми выше свойствами организации объекта, заняться “внутренним имитационным моделированием”, разработать систему имитаторов (демонов), управляемых по темпу и объему порождаемых сообщений (документов) от некоторых независимых генераторов, имитирующих собой различные режимы функционирования рабочих мест. Высокая степень организации системы позволяет построить демонов, генерирующих синтаксически достоверные и семантически правдоподобные сообщения.

Таким образом, мы приходим к постановке переборной задачи, имеющей на входе всевозможные сочетания темпов поступления и семантического содержания сообщений от достаточно произвольного числа демонов, а на выходе – зоны устойчивости, оцениваемые по минимуму изменения динамики потоков сообщений внутри объекта управления. В известной степени эти зоны эквивалентны понятию гомеокинетического плато.

Решение указанной задачи возможно только полным, или, в лучшем случае, направленным перебором. Нашим преимуществом, дающим надежду на успех, является временное масштабирование, позволяющее моделировать предполагаемые изменения входных величин, т.е. заниматься исследованиями информационно-динамических свойств объекта.

Реализация таких демонов вместе с изменяющим характер их деятельности генератором является реальной задачей и может быть выполнена следующим образом.

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

Имитация активности пользователя - демона возможна путем запуска в фоновом режиме программного комплекса с измененными программами обмена информацией. Таким образом, пользователь - демон с точки зрения компьютера и операционной системы является не отдельной активной задачей, а всего лишь набором программ.

Унифицированное построение обрабатывающих подпрограмм рабочего места, например, на базе таблиц интерпретации команд, позволяет строить демонов практически с той же степенью унификации. Имея доступ к системным таблицам, демоны могут быть избавлены от необходимости генерировать входную информацию на уровне случайных последовательностей символов, создавая случайным образом сразу целые команды или даже группы команд.

Чем выше сложность программного обеспечения рабочего места, тем проще может быть устроен соответствующий демон при сохранении уровня правдоподобия результирующей информации.

Моделирование течения времени требует, чтобы демоны перед запуском получали задание на разработку некоторого количества документов, а после его выполнения сообщали об этом факте и освобождали машину. При этом самим демонам не требуется оперировать понятием продолжительности и темпа работы, это за них делает единственный центральный супердемон – распределитель работ и синхронизатор времени. Задаваясь некоторым временным интервалом и набором темпов для различных видов работ, супердемон активизирует демонов, указывает им требуемые объемы работ и считает очередной временной интервал завершенным, когда закончены работы всех подчиненных ему исполнителей.

Такая организация работ позволяет максимально уплотнить внутреннее время системы, получить хорошо управляемый ансамбль демонов и выделить моменты, в которых наиболее удобно производить оценку информации. Алгоритм функционирования супердемона может быть задан в различных формах в зависимости от того, требуется ли однократная оценка конкретного варианта соотношения параметров внешнего мира или решения поисковой задачи в некоторой области изменения параметров с заданными вероятностями распределения внутри области.

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

Результатом такого симбиоза является прогнозирование состояния системы в соответствии с предполагаемым планом работ, перераспределение загрузки рабочих мест и множество других превентивных решений, составляющих сущность управления, показ собственных интеллектуальных возможностей автоматической системы и изучение роста этих возможностей по мере ее развития.

Остается еще раз отметить здесь замечательный факт, наблюдавшийся и экспериментально, в реальной функционирующей системе – для функционирования механизма саморазвития (Задача “саморазвития” изначально не ставилась. Возможность ее постановки и решения выяснилась “по ходу дела”, просто системный охват источников и потоков информации предоставил эти и другие аналогичные (системные) возможности.) системы решающей оказывается динамика потоков информации.

Как уже отметил внимательный читатель, пример реализации приведен на основе рассмотрения структуры проектно-производственного типа. Для холдинга, как специфической структуры совместной работы предприятий, такого примера мы не привели. Этому есть несколько причин.

Во-первых, то, что здесь мы назвали информингом, опробовано нами именно для крупного предприятия. Во-вторых, такой шаг является для любого подхода первичным и никакой подход, если он претендует на интегральность, не может быть начат сразу с уровня холдинга. Вспомним уже цитированную нами работу [5], где контроллинг фактически рассматривается именно на уровне предприятия с его распространением (как возможности) на некоторые большие структуры. Ну и, в-третьих, нам хотелось обсудить новую концепцию информинга в ее “исходном” приложении, оставив “объединенный информинг”, концепцию информинга в условиях объединения информационно-обеспеченных предприятий для будущей, более полной книги. Тем не менее, мы показали, в каком-то смысле аналогично публикации [5] с ее пониманием контроллинга, что и для предприятий, и для холдингов новая концепция информинга суть не разное, а единое понимание задачи организационного управления.