Управление по обстоятельствам

Управление по обстоятельствам
в организационных системах

Виталий Лозовский

Введение

Давным-давно, когда еще царила эйфория по поводу возможностей кибернетики, искусственного интеллекта, систем поддержки принятия решений, АСУ, бытовало «кнопочное» представление о работе руководителя, менеджера, в общем, «человеческой компоненты» организационно-технических систем. Согласно этому представлению, конечный пользователь – специалист в своей предметной области (ПОб) – не имеющий ни времени, ни квалификации, ни желания вникать во внутреннюю кухню систем автоматизации, желая получить ответ на интересующий его вопрос (о ситуации на объекте, о тех или иных критических параметрах, о результатах мысленного эксперимента и т.п.), нажимает одну из кнопочек на пульте управления и получает требуемый ответ, осмысливает его и так же просто вводит в систему свое решение или уточняющий вопрос… Очень скоро выяснилось, что по целому ряду причин подобная схема не работает и, что еще хуже, не будет работать, в принципе. Так, стало понятно, что при создании человеко-машинных систем нереально надеяться на то, что средства автоматизации сумеют приблизиться к человеку-оператору настолько, чтобы тому только и осталось легко и просто воспользоваться ниспосланными ему услугами системы. Гора не придет к Магомету… Одновременно, с развитием систем ИИ, экспертных систем, стало очевидно, что системы управления, поддержки принятия решений, имеют неуклонную тенденцию к усложнению на всех этапах своего жизненного цикла. И многие поняли, что Магомету таки придется, в основном, самому идти к горе.

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

Организационные системы

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

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

Научно обоснованный подход к задачам управления в подобных областях требует, прежде всего, выработки парадигмы представления знаний о заданной предметной области (ПОб), а также методов работы с этим знанием: накопление, интеграция, верификация. Однако практически нет фундаментальных результатов по разработке языковых средств адекватных поставленной задаче. Сложность работы с подобными системами осложняется их пограничным характером: с одной стороны, они функционируют в реальном физическом мире и имеют дело с физическими объектами, а с другой – требуют непосредственного включения в сферу рассмотрения, моделирования и управления «объективно» идеальных сущностей: концептов и структур, относящихся к мышлению отдельных людей и к уровню цивилизации – культуры всего человеческого сообщества. В разрабатываемом нами подходе [1] предложено при создании ОС специфицировать ноосферные статусы рассматриваемых сущностей, относя их к физическим, ментальным или культуральным объектам. При этом мы отходим от жестких философских канонов, исключавших одновременное рассмотрение материальных и идеальных объектов, уравнивая их в правах на уровне семиотики и систем моделирования.

Обстоятельства

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

- Командир! Кончились патроны!
- Ты коммунист?
- Коммунист! И пулемет застрочил с новой силой…

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

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

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

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

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

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

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

Система управления по обстоятельствам (СУО). Принципы построения

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

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

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

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

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

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

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

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

Пусть {S_i} (i = 1, … , n) – множество из n аспектов, выделенных специалистами для данной ПОб. Для каждого аспекта могжет быть предусмотрен набор признаков из общего их множества: {A_ij} (i = 1, … , n, j = 1, … , m_Si). Локализация признаков по аспектам удобней формирования общего их списка, поскольку позволяет назначать их автономно для каждого аспекта, не заботясь о возможных коллизиях по всей ПОб.

Фасетами мы будем называть множество вида <аспект>.<признак>: {S_i.A_ij} (i = 1, … , n, j = 1, … , m_Si). Фасеты приписываются каждому обстоятельству специалистами, которые их формируют или уполномочены вносить изменения в процессе отработки обстоятельств. Содержательно, фасеты задают набор характеристических признаков обстоятельств и могут использоваться при составлении поисковых запросов при выборке релевантных обстоятельств в процессе работы.

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

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

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

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

Формулировка обстоятельства. Помимо классификации вводимого в систему обстоятельства, его автор должен сформулировать его краткое содержание, например: «При приеме некоторых заказов некорректно назначаются плановые сроки их выполнения», «Количество машин на маршруте 148 в часы пик недостаточно» и т.п.

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

Автор обстоятельства. Автором может быть один из разработчиков ОС, ее участник – прикладной специалист, а также пользователь системы, клиент, заказчик – человек со стороны. В последнем случае, работа с обстоятельствами начинает напоминать работу с жалобами и предложениями трудящихся – правда, в условиях более строгого и регламентированного информационного взаимодействия в рамках автоматизированной системы. Формируя конкретное обстоятельство, автор идентифицирует себя, указывая никнейм – для зарегистрированного пользователя – либо имеющиеся координаты для связи. Лица, которые более одного раза входят в систему, должны регистрироваться, указав свое ФИО, электронные адреса, телефоны и т.д. Эта информация используется при возникновении каких-либо вопросов к автору в процессе работы с данным обстоятельством.

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

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

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

«Катастрофа» - отказ в выполнении важнейших функций, возможность необратимых последствий, серьезные человеческие и материальные потери (например, разрушение ядерного реактора);
«Авария» - то же, но с меньшим уровнем потерь (например, вышла из строя трансформаторная подстанция);
«Отказ» - невозможность выполнить функциональную задачу, не связанная с потерями (например, не работает система контроля давления масла правого двигателя);
«Аномалия» - ухудшение функциональности, рабочих характеристик (например, двигатель не развивает нужного крутящего момента);
«Рацпредложение» - предложение, направленное на улучшение характеристик, изменение технологии, повышение экономической эффективности, совершенствование эргономики (например, сокращение маршрута движения внутризаводского транспорта);
«Новая возможность» - предложение о расширении спектра функциональных возможностей, перечня предоставляемых сервисных услуг, расширение номенклатуры продукции, существенное изменение структуры организации или принципов ее функционирования (например, организация малярного участка на СТО);
«Улучшение» - предложение, реализация которого не требует каких-либо принципиальных переделок, изменений структур и/или процессов, но обещает некоторый положительный эффект (например, исправление синтаксических ошибок в документации).

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

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

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

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

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

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

«Заявлено». Статус «Заявлено» присваивается вновь созданному обстоятельству автоматически. Данный статус фиксирует и отображает точку зрения его автора, которая, естественно, требует проверки и/или апробации, прежде чем будут предприниматься какие-либо действия по отработке данного обстоятельства – устранение ошибок, доработки, расширение функциональных возможностей системы и т.п.
«Подтверждено». Заявленное обстоятельство проходит контроль и проверку. Если указанная в нем ошибка действительно имеет место, либо предлагаемая доработка полезна, уместна и своевременна, не противоречит «генеральной линии» развития системы, рассматриваемое обстоятельство получает статус «Подтверждено» и с этого момента должно служить руководством к действию по его реализации.
«Выполнено». Этот статус присваивается обстоятельству исполнителями после того, как, по их мнению, все необходимые действия по реализации данного обстоятельства произведены, т.е. ошибка устранена, доработка сделана, а положительный эффект отработки рассматриваемого обстоятельства подтвержден соответствующими проверками. Нельзя исключить ситуации, когда в процессе отработки данного обстоятельства его исполнители могут встретиться с необходимостью ввести новые обстоятельства, возникновение которых является следствием отработки данного обстоятельства. Эту причинно-следственную связь следует зафиксировать – в интересах последующего анализа и контроля динамики развития данной ОС.
«Проверено». Это – статус обстоятельства, работа с которым завершена. Он присваивается обстоятельству лицом, уполномоченным контролировать выполнение работ с обстоятельствами.

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

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

Работа с обстоятельствами

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

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

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

Заключение

Ранее мы отмечали отрицательные характеристики человеческого фактора в управлении ОС, которые мешают оптимизации процессов управления и осложняют построение адекватных и надежных моделей. Но, наряду с этим, приходится признать, что тому же человеческому фактору мы обязаны тем, что, несмотря на множество отягчающих обстоятельств, хотя бы удовлетворительное решение по управлению все-таки находится. К сожалению, объем наших знаний об этой стороне деятельности человеческого интеллекта крайне ограничен, и мы совершенно не готовы смоделировать эти процессы в системах ИИ. Не готовы мы и к тому, чтобы с пользой для дела воспользоваться даже той информацией, которую удается получить от специалистов в конкретных прикладных областях. Причина этого ясна: мы получаем, в основе своей, неформальную антропоморфную, как правило, текстовую информацию, для фиксации которой у нас нет и не может быть подходящих строгих моделей. Видится единственный разумный выход из этой ситуации – постараться хоть как-то структурировать и упорядочить подобную информацию, а в качестве активных субъектов – сейчас говорят «агентов» - привлечь тех же людей, поскольку никто лучше людей, наделенных естественным интеллектом в подобной неопределенной среде не разберется. Одному из подходов к решению этой задачи и посвящена данная работа.

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

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

Нами полностью обойден вниманием один из важнейших вопросов, на настоятельную необходимость решения которого указывает уже целый ряд исследователей (см., например, Бронников). Его недооценка может привести к тому, что в течение нескольких десятилетий не только системы оргуправления перестанут выполнять свои функции, но и вся наша технократическая цивилизация может загнать себя в глухой тупик. Речь идет вот о чем. Во всех сферах жизни общества налицо гигантский скачок сложности окружающих нас систем и процессов. Достаточно сравнить технические показатели современных компьютеров и вычислительных машин 70-х годов прошлого века. Одновременно гигантски возросла информационная база человечества, сложность процессов поиска нужной информации и принятия хотя бы рациональных решений по управлению. Интернет, являющий собой в настоящее время глобальную нервную систему международного сообщества, сам по себе стал источников громадного числа сложных и неожиданных проблем (вирусы, спам, информационный терроризм и т.п.). В то же время, по свидетельству естествоиспытателей, человек почти не изменился за последние сотни тысяч лет. По различным данным, возможности мозга используются на 4-5 – до 12%. Мы по-прежнему пользуемся примитивными медленными каналами ввода-вывода информации в человеческий мозг. Не хочется думать о потенциальных перспективах, при которых возможности роботов одного из новых поколений в этом плане превысят возможности человека, в результате чего человечество само подпишет себе приговор и рискует исчезнуть с лица Земли еще до того, как будут исчерпаны ее природные ресурсы. Нереально и несимпатично выглядят призывы экстремистов покончить с технократической линией развития и вернуться… куда? В пещеры? Таким образом, видится единственная альтернатива, которая может вернуть человеку достойное положение в структуре глобальных экосистем, без катастроф для всей цивилизации. Для решения этой задачи необходимо достичь следующих целей.

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

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

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

Литература

V.Lozovskiy, Towards the semiotics of Noosphere, International Journal “Information Theories & Applications”, ISSN 1310-0513, Ed. in chief Krassimir Markov, 2003, Vol. 10, # 1, http://www.foibg.com, p. 29-36
В.С.Лозовский, Сетевые модели, pазд. 1.3 в кн.: Искусственный интеллект, в 3-х кн., Кн. 2: Модели и методы. Спpавочник, п/p Д.А.Поспелова, М., "Pадио и связь", 1990, стp. 28 - 49
Y.Satprem, La Genese du Surhomme. Essai d'Evolution Experimentale, 1974, Editions Buchet/Chastel, Paris, ISSBN 2-7020-1383-X - Cатпрем, На пути к сверхчеловечеству. Эссе экспериментальной эволюции, И.Савенков. Перевод с французского. Москва, 1999-2000