(Операционное) управление знаниями, НСИ, (справочными и мастер, а также проектными) данными
1. Инженерия и операции в предпринятиях-киборгах.
Любое предпринятие занято инженерией и операциями (операционным управлением): преобразует свои объекты работы (выполняет правильные операции с правильными объектами), и двигает их от одного выполнителя к другому (организует максимальный проход объектов работы через предпринятие). Инженерия -- это работы по обработке, трансформации, изменению объектов работы выполнителями. Операции (нарезка на перемещаемые объекты работы -- управление конфигурацией, и логистика) -- это перемещение объектов работы между выполнителями, занимающимися инженерией. Разделение деятельностей предпринятия на инженерную, операционную (стратегирование, развитие и т.д.) описывалось в http://praxos.livejournal.com/14627.html, и детализировалось далее в http://praxos.livejournal.com/14905.html.
Если речь идёт о материальных объектах работы (а хоть и о бумажных документах, или даже неструктурированных электронных документах), то никаких проблем для описания работы инженерии и операций нет. Но ситуация резко меняется, когда у нас в предпринятии появляется большой объем работы с:
-- информацией (фактами, сведениями, приказами, требованиями, мнениями). Обсуждение информации затрагивает содержательные вопросы - значение информации в контексте ее использования («смысл»). Что эта информация означает для нашего инженерного проекта, что из этой информации следует? В чем смысл именно такой информации, а не другой? Какой ситуации в реальном мире соответствует эта информация? Содержательное рассмотрение обычно никак не связано с обсуждением способа записи, соглашениями об именах, синтаксисом, особенностями представления информации на носителе. Это именно содержание, а не форма. Информация о том, что 2*2=4 обсуждается содержательно (что это именно 4, не 3 и не 7), а не с точки зрения ее представления (например, использованной системы счисления для записи цифр), или на каком носителе она записана.
-- данными (представлением информации с использованием какого-то формализма. Например, при обсуждении данных 2*2=4 можно обсуждать формализм - арабские цифры или римские). Данные абстрактны, т.е. не существуют в материальном мире. Действительно, одни и те же данные (например, текстовая строка «труба» в кодировке UNICODE или даже большая база данных со сложной схемой) могут быть представлены на самых разных экземплярах носителя, в том числе и резервных (бэкапы). На всех этих экземплярах носителей данные остаются одними и теми же, и обсуждаются именно как данные.
-- информационными объектами, т.е. чертежами, отчётами (бумажными и даже электронными - файлы), хранилищами данных на компьютерах (предназначенные для хранения данных в структурированном виде, без повторений и с возможностью однозначного нахождения нужных данных) и любые другие физические объекты, содержащие данные. На разных информационных объектах/носителях информации (например, в газете и в хранилище данных) могут находиться одни и те же данные (например, текстовая строка «труба»).
Данные не живут без носителя. Так, «файл» - это обычно маленькие магнитные частички, специальным образом ориентированные, расположенные во множестве разных мест диска из немагнитного материала. Данные из файла могут затем попасть в оперативную память - и стать там уже не магнитными частичками с разной ориентацией в пространстве, а участками полупроводниковой микросхемы с разными напряжениями.
Современное предприятие представляет из себя киборга, в котором коммуникация (логистика информации) между людьми опосредуется информационными системами, а объекты работы (объекты стратегирования, инженерии, операций и т.д.) во всё большей степени представляют собой информационные объекты, логистика которой идёт в форме данных. Вместо слесарей и обкатчиков клюквы у нас появляется огромное число работников, для которых очень трудно представить Toyota production system с её тележками и минимизацией входящих очередей болтов и клюквы к отдельным рабочим местам. Операции для информационных работников трудно описать не только потому, что трудно описывать работы "думания" и "творческой коммуникации", но и потому как в эти практики входят паттерны нечеловеческой работы -- паттерны "думания" и "коммуникации" компьютеров, которые оперируют данными (т.е. представлением информации с использованием какого-то не слишком связанного с содержанием этих данных более-менее универсального формализма).
Но это не означает, что мы не можем попытаться попробовать говорить об операциях киборгов (у которых есть кортекс и экзокортекс) так же, как мы говорим об операциях "просто людей". В головах (кортексах) и экзокортексах (личных и корпоративных компьютерах, забудем о далёком прошлом со шкафами бумажных документов, а также бумажных записных книжках) людей идут какие-то инженерные работы с информацией/данными, и информация/данные передаются между ними и хранится где-то между обработками. Важно ведь не просто сработать с информацией, чтобы извлечь из неё что-то интересное силами одного выполнителя-гения (будь то человек или компьютер), но и научиться выстраивать информационный конвейер предпринятия-киборга, самого состоящего из имеющих разные компетенции и по-разному загруженных работой киборгов-выполнителей так же, как сначала Форд, а затем люди в Toyota научились выстраивать свой автомобильный конвейер. И в этом информационном конвейере предпринятия данные могут быть порождены пару лет, или даже пару сотен лет назад, и попадут на него не только из голов работников-людей через клавиатуру или распознаванием речи, но и в виде справочных данных из уже давно существующих текстов, баз данных и т.д..
2. Инженерия знаний и управление знаниями.
Мы будем пытаться единообразно говорить об организации как работы с информацией/данными, так работы с физическими объектами. Сегодня мы рассмотрим дисциплины/практики операционной работы с информацией/данными, которая используется во множестве проектов/предпринятий, на нескольких стадиях жизненного цикла, и/или интересует множество выполнителей. Такая информация/данные называется:
-- знаниями (если акцент делается на кортекс и том, что "внутри головы", а также обсуждения потребностей в этом знании. О формате представления умолчим, ибо употребляющие слово "знания" избегают разговора про форматы и формализмы).
-- нормативно-справочной информацией (если акцент делается на эксплицитно представленном знании в любой их форме -- неструктурированной/полнотекстовой, равно как структурированной в виде объектных или реляционных баз данных, файлов данных компьютерного моделирования и т.д.)
-- справочными данными (если акцент делается на структурированной части НСИ, представленной единообразно, а рассмотрение не столько содержательное-инженерное, сколько менеджерское-логистическое)
-- мастер-данными (если акцент делается на справочных данных, подвластных единому центру администрирования)
С этими объектами работы идёт как инженерная/информационная работа (преобразование в соответствии с технологией получения целевой системы), так и операционная ("управление" в его учётном/конфигурационном и логистическом/маршрутизационном смысле, акцент на формирование данных, их учёт и их передачу).
Инженерии тут аж две:
-- инженерия знаний (в части формы представления): инженерия знаний/НСИ/справочных данных/мастер-данных -- это преобразование из менее формальных представлений в более формальные. "Инженерия знаний" традиционно относится к трансформации человечьего знания в нечеловечье/компьютерное (http://en.wikipedia.org/wiki/Knowledge_engineering). То есть это выковыривание знаний (как explicit, так и tacit) из человечьей головы (кортекса), текстов на естественном языке (находящихся в "экзокортексе") и кодирование его в формальные структуры, понятные компьютерным программам. Это программирование/моделирование/онтологизирование, которые всё суть одно. Инженерия знаний при этом включает инженерию НСИ, инженерия НСИ включает инженерию справочных данных, а инженерия справочных данных включает инженерию мастер данных. Чем менее формально представление, тем больше обсуждение информационной составляющей, а чем более формально представление, тем больше обсуждение составляющей данных.
-- дисциплинарная, т.е. целевая для деятельности предприятия инженерия (в части информации о целевой системе предпринятия, содержания/предмета работы выполнителей-инженеров): системная инженерия и инженерия по специальности, в том числе порождающее проектирование (generative design) и прочие содержательные обработки знаний/справочных данных, вплоть до "думания" при помощи инженерных программ искусственного интеллекта. Эта инженерная содержательная часть работы со знанием остаётся вне предмета нашего рассмотрения. Когда говорят об "инженерии знаний", вовсе не имеют ввиду какую-то конкретную последующую работу с этими знаниями (придумывание новых знаний при помощи компьютера, использование текущих знаний, использование "настоящего искусственного интеллекта" и т.д.), речь идёт главным образом о формировании адекватного для использования в этой последующей работе представления знаний в каком-то компьютерном формализме.
Традиционно "управление знаниями" относится к операциям -- как и любое "управление". Оно включает управление конфигурацией и управление изменениями (учёт), а также логистику (поиску и доставку по потребности) знаний, находящихся в (http://ailev.livejournal.com/631926.html, 2008):
-- человечьей голове (байки про важность tacit knowledge и незаменимость человеческой интуиции). Вотчина психологов, управленцев персоналом, когнитологов (когда нужно выковырять это знание, сделав его explicit).
-- текстах на естественном языке (нормах и стандартах, переписке, учебниках -- все эти "просто поиски", "семантические поиски", "автоматическое аннотирование" и пр.). Вотчина компьютерных лингвистов, программистов и администраторов "систем управления контентом" (ах, опять это "управление" -- учёт и логистика "контента", полностью абстрагированного от его содержания!).
-- нечеловечьих/компьютерных структурах данных, подчиняющихся различным формализмам (базах данных, инженерных моделях и т.д. -- федерирование и интеграция данных, корпоративные шины предприятий, сервис-ориентированные архитектуры и пр.). Вотчина айтишников-системщиков, которые от железа уже ушли, а к инженерно-дисциплинарной работе с информационным содержанием данных ещё не пришли.
"Управление знаниями" сегодня используют так же бездумно, как "управление требованиями": большинство менеджеров считают, что требования появляются не в результате инженерии требований (инженерной дисциплины), а в результате управления требованиями (операционной дисциплины: учёт/управление конфигурацией и изменениями требований и логистика/маршрутизация/доставка требований и их полуфабрикатов туда и тогда, где и когда они нужны). Ну да, булки растут даже не на деревьях, а прямо в машинах по развозке хлеба. Производителем сообщения (инженером) является принесший его гонец (операционный работник). Увы, жизнь устроена сложней: для знаний нужны и инженеры-придумщики-изготовители, и операционисты-менеджеры с их учётом и логистикой.
Как и в случае инженерии знаний, управление знаниями включает в себя управление НСИ, управление НСИ включает в себя управление справочными данными, управление справочными данными включает управление мастер-данными. Другое дело, что дисциплина (набор практик) "управление знаниями" включает в себя также и практику управления доступом одних людей к tacit knowledge других людей, хотя мало кому удалось понять, в чём же именно заключается такая практика.
Эту "матрёшку" будет довольно трудно различать в живой речи на производстве -- люди очень любят метонимию в варианте синекдохи: называя целое именем части, да и наоборот тоже. Ну, и никаких "операций со знаниями", "операционного менеджмента знаний", а только "управление знаниями". Даже "операции с данными", скорее всего, будут означать инженерные преобразования данных, так что не ждите какой-то консистентности использования предлагаемой терминологии. Ничего, мы будем к этому толерантны, а наши лингвистические программы и онтологические к ним настройки будут это учитывать.
Инженерия знаний -- это порождение и документирование/постановка на учёт тех объектов знаний (данных!), которые потом будут путешествовать по логистической сети между выполнителями-"думателями"-компьютерами. Поэтому её можно включать в управление знаниями примерно на тех же основаниях, на каких управление конфигурацией включают в инженерный менеджмент/управление операциями, и считать "менеджерской дисциплиной" (не зависящей от предметной области, к которой относятся знания по их содержанию).
С другой стороны, инженерия знаний много сложней, чем управление конфигурацией и управление изменениями материальных компонент целевой системы. Это не просто нарезка знания на содержательные куски, удобные для коммуникации и учёт этих знаниевых конфигурационных единиц и их изменений, как материальную систему нарезают на конфигурационные единицы и затем ведут их учёт. Нет, там много особенностей по тому, как "выковыривать" знание из одних форматов и кодировать в других без потери информации/содержания: в материальном мире обычно такие задачи не требуют специальных методов, разобрать часы на детальки может и маленький дитёнка (в отличие от разборки смутных представлений специалиста о его способах работы и представление их в виде текста, или разборки пяти мутных текстов в семантическую сетку). Есть и иная традиция, в которой управление знаниями затягивают внутрь инженерии знаний (это часто: управление требованиями затягивают внутрь инженерии требований -- а ведь управление требованиями это управление знаниями в части требований, инженерия требований -- инженерия знаний в части требований, хотя и приправленная содержательной инженерией для формулирования содержания требований).
Мы не будем в этом разбираться, а просто припишем инженерию знаний (и все эти "инженерии НСИ", "инженерии справочных данных", "инженерии мастер-данных") к операционной деятельности, рядом с управлением конфигурацией и управлением изменениями -- это всё очень рядом с PLM (хотя поставщики PLM-систем этого и не осознают, и не дают такого инструментария. Ну, разве что Dassault Systemes прикупила Exalead, но это всё-таки не совсем то). Вот такой вот операционный шовинизм по отношению к инженерии знаний, ибо у этих "инженеров по знаниям" основное -- это "знание о знании", от них не требуется инженерного "знания о целевой системе и способам её получения", знания о железе и софте, химии и прочностных расчётах. А "настоящие инженеры" (системные и инженеры по специальностям) у нас в предпринятии будут заниматься не формализацией-деформализацией знаний/данных как таковых, а содержательной инженерной работой с информацией по созданию целевой системы -- добычей и использованием справочной информации, решением традиционных инженерных задач. И будут поэтому формализовывать/деформализовывать знания только по сопричастности к их содержательной инженерной деятельности.
Помним, что все приведённые разведения (прежде всего инженерии и операций) очень условны. Так, Ассоциация инженерного менеджмента предпочитает говорить о непрерывном спектре инженерных и менеджерских дисциплин (где "чистая инженерия про железо" и "чистый менеджмент про людей" находятся на краях, а "инженерный менеджмент" где-то посерединке, и включает в себя как раз главным образом "операционный менеджмент" в самых разных его вариантах -- проектное управление, управление цепочками поставок и т.д.). Условность отнесения рассматриваемых вопросов инженерии и управления знаниями, равно как сближения управления конфигурацией и данными (помним про одноимённую ассоциацию -- http://www.acdm.org/), и замешивания их в одну кучу в части "операционного управления" должна быть предельно ясна.
3. Пример: верификация с использованием лингвистических технологий.
Вот тут я рассказывал об использовании лингвистических технологий в инжиниринговых компаниях: http://ailev.livejournal.com/1012295.html. Если кратко, то мы хотим вытаскивать информацию из неформальных текстов, и превращать эту информацию в данные (то есть представлять в формализме, удобном для непосредственного использования в CAD системах) для последующей компьютерной обработки инженерными алгоритмами.
Если мы хотим автоматизировать (сначала чуть-чуть, потом побольше, а потом и вовсе сделать автоматической) верификацию данных проекта на соответствие данных требований проекта, а также справочных данных стандартов (неважно, добровольно используемых, или вменённых органами технического регулирования), то нам нужно:
а) преобразовать тексты в инженерные данные (или вернуть на доработку, если тексты мутны -- при сегодняшнем уровне развития лингвистических технологий есть огромная вероятность, что при возможностях разночтений или пропусках информации там, где будет спотыкаться лингвистический софт, там и люди будут спотыкаться -- см. в Гугле ' "Text Analysis" "Requirements Engineering" ', обращая внимание на даты публикаций и учитывая достижения компьютерной лингвистики последних двух-трёх лет).
В компьютерной лингвистике об этом преобразовании говорят как об извлечении фактов, это непосредственно практики инженерии знаний (перевод знаний из менее формального представления в более формальное).
В нашем конкретном случае факты мы будем извлекать сразу в формате справочных данных ISO 15926 (Почему? Ответ есть в первых текстах из последовательности чтения в http://dot15926.livejournal.com/27293.html). Это означает, что к используемым системам компьютерной лингвистики (Compreno, GATE, NLTK, UUIMA и т.д.) нужно сделать адаптеры ISO 15926, чтобы результаты их работы были единообразно представлены.
Начальный наш заход мы делали на полностью "ручную" практику инженерии справочных данных ISO 15926 (версия 2 этой технологии опубликована полтора года назад в http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc) и использование в ней также полностью "ручной" практики характеризации текстовых документов (см. нашу полугодичной давности технологию семантического моделирования инженерных документов TabLan -- http://techinvestlab.ru/files/TabLan/TabLan.rar), но сейчас думаем о возможностях автоматизации этих практик при помощи совершившегося в последние два-три года прорыва в технологиях компьютерной лингвистики (см. эксперименты в http://dot15926.livejournal.com/33691.html). Конечно, это будет по сравнению с ручной работой примерно так же, как работали первые системы генерации кода по высокоуровневым моделям: генерировался костяк кода со множеством ошибок, а затем он долго-долго "дорабатывался напильником" до качественного результата. Сейчас ситуация много лучше, и генерация кода по моделям проходит уже без того, чтобы лезть руками в получившийся код. Конечно, ISO 15926 код, сгенерированный в результате "автоматической характеризации инженерных текстов" придётся "дорабатывать напильником".
Мы в TechInvestLab на первых порах эту "доработку напильником" будем делать с использованием нашего .15926 Editor. Недаром он не только "мэппер", но и "редактор" -- причём эту "доработку напильником" в типовых случаях мы сможем автоматизировать, написав для соответствующих обработок код на Питоне. В итоге мы получим автоматизацию не только лингвистического парсинга "читателя на естественном языке", но и автоматизацию характеризационной работы инженера (различающего классы и индивиды, склеивающие по-разному названные объекты в один на основании своих инженерных знаний об описываемой предметной области) -- то есть постепенно мы получим "экспертную систему по характеризации инженерных текстов".
б) положить справочные данные в PLM (SPF, ENOVIA, SmarTeam, и т.д.), к которым имеют доступ выполняющие верификацию САПРы. Для этого должны быть адаптеры данных ISO 15926 для используемых PLM. Выпускаемая в сентябре 2012 г. версия 1.0 нашей платформы .15926 как раз поможет разрабатывать эти адаптеры.
Пункты а) и б) тем самым вполне укладываются в традиционную проблематику PLM, "систем управления жизненным циклом", систем поддержки операционной деятельности в части проектной инженерной информации (а дальше по жизненному циклу -- в проблематику ERP и EAM систем, см. слайд 5 в http://www.slideshare.net/ailev/plm-principles-ailevjun12). Цель -- исключить инженерные коллизии на как можно более ранней стадии, т.е. не при сборке или даже эксплуатации целевой инженерной системы, а пока эта система ещё находится в компьютере, проектной стадии. Куски информации, по которым можно определить коллизию, должны смаршрутизироваться тому выполнителю, который сможет эту коллизию обнаружить содержательно. Это задача операционного управления, управления конфигурацией и логистики. И в рамках этой операционной задачи мы просто выделяем инженерию знаний и управление знаниями (обобщая с инженерии справочных данных и управления справочными данными за счёт задействования автоматизированных и "ручных" характеризационных технологий, т.е. технологий, формализующих неформально выраженное в чьих-то мозгах и текстах на естественном языке знание).
в) выполнить верификацию средствами САПР и систем инженерного моделирования, ибо содержательная/инженерная работа с тем или иным видом информации происходит именно в предметно-ориентированных САПР и системах инженерного моделирования, а не в относящейся к управлению операциями "учётной и логистической" СУЖЦ aka PLM (грубо говоря, электрические стандарты проверять средствами электрического САПР, взрывоопасность -- средствами моделирования взрывов, габариты -- средствами 3D САПР, и т.д. -- ибо в PLM идёт только операционная работа). Вот тут-то и происходит "инженерное творчество", "думание", тут-то и нужен искусственный интеллект, инженерные расчёты, инженерное моделирование и прочие хитрые методы задействия формализованного уже знания. Это инженерная деятельность, ей должны заниматься инженеры по специальностям, а также системные инженеры.
Когда я в своих постингах говорю о том, что хотел бы двигаться в сторону систем искусственного интеллекта, я вовсе не имею ввиду, что сделаю тот самый алгоритм GPS (general problem solver) -- статистический на базе machine learning, или какой-то хитрый логический, программируемый вручную наподобие древних экспертных систем (чур меня, все почему-то предполагают, что я всенепременно повторю какую-то допотопную архитектуру середины семидесятых, опираясь на мои постинги про ISO 15926, имеющие отношение к логистике, а не к вычислениям над знаниями! Нет! Я не такой!). Нет, я пока не хочу залезать в "компьютерное думание" с использованием формально представленных знаний. Я хочу только обеспечить операционное управление знаниями, инфраструктуру, в которой "думатели/вычислители" (человеческие и компьютерные, а также их симбизы -- киборги) будут получать знания/данные в понятных для них формализмах, в готовом для употребления в думку/вычисление виде.
Алгоритмы для проектирования киберфизических систем должны писать знатоки этих киберфизических систем: для проектирования электроники -- знатоки этой электроники, для проектирования химических реакторов -- знатоки химии, и вообще -- думанием должны заниматься спецы-предметники и спецы-модельеры. Моделеориентированной системной инженерии никто не отменял, и там будут рулить математические модели (в том числе и дискретные математические модели, но и модели численной математики -- куда ж без неё!). Я думаю, что роль "общих решателей проблем" с каким-то "статистически обученным искусственным интеллектом" в инженерных задачах ограничена. Естественные интеллекты продвигались в инженерии именно путём формализации и точных расчётов. Если же полагаться на "статистические алгоритмы", то какой-то не в меру бодрый искусственный интеллект, обучаясь, примет значение косинуса для военного проекта равным 3, потому как ему статистически достоверно встречалась фраза "во время войны косинус вообще до трёх доходил". В этом месте сегодня столько разных спекуляций, и люди так возбуждаются в разговорах, что я бы пока ввёл мораторий на обсуждение "искусственно интеллектуальных алгоритмов инженерной работы".
А вот операционное управление справочными (да и проектными) данными, чтобы все эти разной степени интеллектуальности и автоматичности одни инженерные системы на входе получали нужные им данные, а результаты их работы затем попадали дальше как входные данные в какие-то другие инженерные системы -- вот этим и нужно заняться, это инфраструктура для "думательных" алгоритмов, управление жизненным циклом инженерного проекта, операционное управление предпринятием.
Заметим, что если речь идёт не о верификации, а о generative design, то связанные с операциями/PLM пункты a) и б) не меняются -- задача добычи информации и предоставления её выполнителю-инженеру (киборгу -- человеку, укомплектованному инженерным софтом по самое не балуйся) остаётся. Но этот инженерный софт тогда вместо (или вместе с верификацией) производит порождение инженерного артефакта -- чертежей, инженерного решения, архитектурных описаний или ещё чего-то такого, что раньше САПР выполняли исключительно в режиме "редактора текстов", не производя более интеллектуальных действий, чем перевод одних единиц измерения в другие, или протягивание прямой между двумя указанными инженером точками.
Если вдруг выяснится, что к нам пришёл настоящий САПР с искусственным интеллектом, который что-то хочет сделать с использованием блендинга, прототипов и прочих изысков современных когнитивных архитектур, подсмотренных у человека (ср. с последним абзацем в http://ailev.livejournal.com/1012295.html -- про коммуникацию с людьми, а не САПР), то нам придётся полностью пересмотреть всю цепочку практик инженерии знаний (выкинуть ISO 15926, а также значительную часть в системах компьютерной лингвистики), чтобы извлекать из текста данные, представленные в особо удобной для употребления в этих (пока мне неизвестных) супер-пупер-когнитивных программах. Пока же все мне известные инженерные программы юзают объект-ориентированное представление, для которого логическое представление данных компьютерной лингвистики (они сейчас все полюбили RDF) и онтологическое представление ISO 15926 вполне адекватно и даже представляет собой огромный шаг вперёд по сравнению с предыдущими попытками (см. эволюцию практики интеграции данных жизненного цикла в http://ailev.livejournal.com/929451.html). Так что тут внимательно наблюдаем и даже ведём какие-то исследования, но клиентам предлагать ещё совсем нечего -- поэтому "за неимением гербовой пишем на простой".
Любое предпринятие занято инженерией и операциями (операционным управлением): преобразует свои объекты работы (выполняет правильные операции с правильными объектами), и двигает их от одного выполнителя к другому (организует максимальный проход объектов работы через предпринятие). Инженерия -- это работы по обработке, трансформации, изменению объектов работы выполнителями. Операции (нарезка на перемещаемые объекты работы -- управление конфигурацией, и логистика) -- это перемещение объектов работы между выполнителями, занимающимися инженерией. Разделение деятельностей предпринятия на инженерную, операционную (стратегирование, развитие и т.д.) описывалось в http://praxos.livejournal.com/14627.html, и детализировалось далее в http://praxos.livejournal.com/14905.html.
Если речь идёт о материальных объектах работы (а хоть и о бумажных документах, или даже неструктурированных электронных документах), то никаких проблем для описания работы инженерии и операций нет. Но ситуация резко меняется, когда у нас в предпринятии появляется большой объем работы с:
-- информацией (фактами, сведениями, приказами, требованиями, мнениями). Обсуждение информации затрагивает содержательные вопросы - значение информации в контексте ее использования («смысл»). Что эта информация означает для нашего инженерного проекта, что из этой информации следует? В чем смысл именно такой информации, а не другой? Какой ситуации в реальном мире соответствует эта информация? Содержательное рассмотрение обычно никак не связано с обсуждением способа записи, соглашениями об именах, синтаксисом, особенностями представления информации на носителе. Это именно содержание, а не форма. Информация о том, что 2*2=4 обсуждается содержательно (что это именно 4, не 3 и не 7), а не с точки зрения ее представления (например, использованной системы счисления для записи цифр), или на каком носителе она записана.
-- данными (представлением информации с использованием какого-то формализма. Например, при обсуждении данных 2*2=4 можно обсуждать формализм - арабские цифры или римские). Данные абстрактны, т.е. не существуют в материальном мире. Действительно, одни и те же данные (например, текстовая строка «труба» в кодировке UNICODE или даже большая база данных со сложной схемой) могут быть представлены на самых разных экземплярах носителя, в том числе и резервных (бэкапы). На всех этих экземплярах носителей данные остаются одними и теми же, и обсуждаются именно как данные.
-- информационными объектами, т.е. чертежами, отчётами (бумажными и даже электронными - файлы), хранилищами данных на компьютерах (предназначенные для хранения данных в структурированном виде, без повторений и с возможностью однозначного нахождения нужных данных) и любые другие физические объекты, содержащие данные. На разных информационных объектах/носителях информации (например, в газете и в хранилище данных) могут находиться одни и те же данные (например, текстовая строка «труба»).
Данные не живут без носителя. Так, «файл» - это обычно маленькие магнитные частички, специальным образом ориентированные, расположенные во множестве разных мест диска из немагнитного материала. Данные из файла могут затем попасть в оперативную память - и стать там уже не магнитными частичками с разной ориентацией в пространстве, а участками полупроводниковой микросхемы с разными напряжениями.
Современное предприятие представляет из себя киборга, в котором коммуникация (логистика информации) между людьми опосредуется информационными системами, а объекты работы (объекты стратегирования, инженерии, операций и т.д.) во всё большей степени представляют собой информационные объекты, логистика которой идёт в форме данных. Вместо слесарей и обкатчиков клюквы у нас появляется огромное число работников, для которых очень трудно представить Toyota production system с её тележками и минимизацией входящих очередей болтов и клюквы к отдельным рабочим местам. Операции для информационных работников трудно описать не только потому, что трудно описывать работы "думания" и "творческой коммуникации", но и потому как в эти практики входят паттерны нечеловеческой работы -- паттерны "думания" и "коммуникации" компьютеров, которые оперируют данными (т.е. представлением информации с использованием какого-то не слишком связанного с содержанием этих данных более-менее универсального формализма).
Но это не означает, что мы не можем попытаться попробовать говорить об операциях киборгов (у которых есть кортекс и экзокортекс) так же, как мы говорим об операциях "просто людей". В головах (кортексах) и экзокортексах (личных и корпоративных компьютерах, забудем о далёком прошлом со шкафами бумажных документов, а также бумажных записных книжках) людей идут какие-то инженерные работы с информацией/данными, и информация/данные передаются между ними и хранится где-то между обработками. Важно ведь не просто сработать с информацией, чтобы извлечь из неё что-то интересное силами одного выполнителя-гения (будь то человек или компьютер), но и научиться выстраивать информационный конвейер предпринятия-киборга, самого состоящего из имеющих разные компетенции и по-разному загруженных работой киборгов-выполнителей так же, как сначала Форд, а затем люди в Toyota научились выстраивать свой автомобильный конвейер. И в этом информационном конвейере предпринятия данные могут быть порождены пару лет, или даже пару сотен лет назад, и попадут на него не только из голов работников-людей через клавиатуру или распознаванием речи, но и в виде справочных данных из уже давно существующих текстов, баз данных и т.д..
2. Инженерия знаний и управление знаниями.
Мы будем пытаться единообразно говорить об организации как работы с информацией/данными, так работы с физическими объектами. Сегодня мы рассмотрим дисциплины/практики операционной работы с информацией/данными, которая используется во множестве проектов/предпринятий, на нескольких стадиях жизненного цикла, и/или интересует множество выполнителей. Такая информация/данные называется:
-- знаниями (если акцент делается на кортекс и том, что "внутри головы", а также обсуждения потребностей в этом знании. О формате представления умолчим, ибо употребляющие слово "знания" избегают разговора про форматы и формализмы).
-- нормативно-справочной информацией (если акцент делается на эксплицитно представленном знании в любой их форме -- неструктурированной/полнотекстовой, равно как структурированной в виде объектных или реляционных баз данных, файлов данных компьютерного моделирования и т.д.)
-- справочными данными (если акцент делается на структурированной части НСИ, представленной единообразно, а рассмотрение не столько содержательное-инженерное, сколько менеджерское-логистическое)
-- мастер-данными (если акцент делается на справочных данных, подвластных единому центру администрирования)
С этими объектами работы идёт как инженерная/информационная работа (преобразование в соответствии с технологией получения целевой системы), так и операционная ("управление" в его учётном/конфигурационном и логистическом/маршрутизационном смысле, акцент на формирование данных, их учёт и их передачу).
Инженерии тут аж две:
-- инженерия знаний (в части формы представления): инженерия знаний/НСИ/справочных данных/мастер-данных -- это преобразование из менее формальных представлений в более формальные. "Инженерия знаний" традиционно относится к трансформации человечьего знания в нечеловечье/компьютерное (http://en.wikipedia.org/wiki/Knowledge_engineering). То есть это выковыривание знаний (как explicit, так и tacit) из человечьей головы (кортекса), текстов на естественном языке (находящихся в "экзокортексе") и кодирование его в формальные структуры, понятные компьютерным программам. Это программирование/моделирование/онтологизирование, которые всё суть одно. Инженерия знаний при этом включает инженерию НСИ, инженерия НСИ включает инженерию справочных данных, а инженерия справочных данных включает инженерию мастер данных. Чем менее формально представление, тем больше обсуждение информационной составляющей, а чем более формально представление, тем больше обсуждение составляющей данных.
-- дисциплинарная, т.е. целевая для деятельности предприятия инженерия (в части информации о целевой системе предпринятия, содержания/предмета работы выполнителей-инженеров): системная инженерия и инженерия по специальности, в том числе порождающее проектирование (generative design) и прочие содержательные обработки знаний/справочных данных, вплоть до "думания" при помощи инженерных программ искусственного интеллекта. Эта инженерная содержательная часть работы со знанием остаётся вне предмета нашего рассмотрения. Когда говорят об "инженерии знаний", вовсе не имеют ввиду какую-то конкретную последующую работу с этими знаниями (придумывание новых знаний при помощи компьютера, использование текущих знаний, использование "настоящего искусственного интеллекта" и т.д.), речь идёт главным образом о формировании адекватного для использования в этой последующей работе представления знаний в каком-то компьютерном формализме.
Традиционно "управление знаниями" относится к операциям -- как и любое "управление". Оно включает управление конфигурацией и управление изменениями (учёт), а также логистику (поиску и доставку по потребности) знаний, находящихся в (http://ailev.livejournal.com/631926.html, 2008):
-- человечьей голове (байки про важность tacit knowledge и незаменимость человеческой интуиции). Вотчина психологов, управленцев персоналом, когнитологов (когда нужно выковырять это знание, сделав его explicit).
-- текстах на естественном языке (нормах и стандартах, переписке, учебниках -- все эти "просто поиски", "семантические поиски", "автоматическое аннотирование" и пр.). Вотчина компьютерных лингвистов, программистов и администраторов "систем управления контентом" (ах, опять это "управление" -- учёт и логистика "контента", полностью абстрагированного от его содержания!).
-- нечеловечьих/компьютерных структурах данных, подчиняющихся различным формализмам (базах данных, инженерных моделях и т.д. -- федерирование и интеграция данных, корпоративные шины предприятий, сервис-ориентированные архитектуры и пр.). Вотчина айтишников-системщиков, которые от железа уже ушли, а к инженерно-дисциплинарной работе с информационным содержанием данных ещё не пришли.
"Управление знаниями" сегодня используют так же бездумно, как "управление требованиями": большинство менеджеров считают, что требования появляются не в результате инженерии требований (инженерной дисциплины), а в результате управления требованиями (операционной дисциплины: учёт/управление конфигурацией и изменениями требований и логистика/маршрутизация/доставка требований и их полуфабрикатов туда и тогда, где и когда они нужны). Ну да, булки растут даже не на деревьях, а прямо в машинах по развозке хлеба. Производителем сообщения (инженером) является принесший его гонец (операционный работник). Увы, жизнь устроена сложней: для знаний нужны и инженеры-придумщики-изготовители, и операционисты-менеджеры с их учётом и логистикой.
Как и в случае инженерии знаний, управление знаниями включает в себя управление НСИ, управление НСИ включает в себя управление справочными данными, управление справочными данными включает управление мастер-данными. Другое дело, что дисциплина (набор практик) "управление знаниями" включает в себя также и практику управления доступом одних людей к tacit knowledge других людей, хотя мало кому удалось понять, в чём же именно заключается такая практика.
Эту "матрёшку" будет довольно трудно различать в живой речи на производстве -- люди очень любят метонимию в варианте синекдохи: называя целое именем части, да и наоборот тоже. Ну, и никаких "операций со знаниями", "операционного менеджмента знаний", а только "управление знаниями". Даже "операции с данными", скорее всего, будут означать инженерные преобразования данных, так что не ждите какой-то консистентности использования предлагаемой терминологии. Ничего, мы будем к этому толерантны, а наши лингвистические программы и онтологические к ним настройки будут это учитывать.
Инженерия знаний -- это порождение и документирование/постановка на учёт тех объектов знаний (данных!), которые потом будут путешествовать по логистической сети между выполнителями-"думателями"-компьютерами. Поэтому её можно включать в управление знаниями примерно на тех же основаниях, на каких управление конфигурацией включают в инженерный менеджмент/управление операциями, и считать "менеджерской дисциплиной" (не зависящей от предметной области, к которой относятся знания по их содержанию).
С другой стороны, инженерия знаний много сложней, чем управление конфигурацией и управление изменениями материальных компонент целевой системы. Это не просто нарезка знания на содержательные куски, удобные для коммуникации и учёт этих знаниевых конфигурационных единиц и их изменений, как материальную систему нарезают на конфигурационные единицы и затем ведут их учёт. Нет, там много особенностей по тому, как "выковыривать" знание из одних форматов и кодировать в других без потери информации/содержания: в материальном мире обычно такие задачи не требуют специальных методов, разобрать часы на детальки может и маленький дитёнка (в отличие от разборки смутных представлений специалиста о его способах работы и представление их в виде текста, или разборки пяти мутных текстов в семантическую сетку). Есть и иная традиция, в которой управление знаниями затягивают внутрь инженерии знаний (это часто: управление требованиями затягивают внутрь инженерии требований -- а ведь управление требованиями это управление знаниями в части требований, инженерия требований -- инженерия знаний в части требований, хотя и приправленная содержательной инженерией для формулирования содержания требований).
Мы не будем в этом разбираться, а просто припишем инженерию знаний (и все эти "инженерии НСИ", "инженерии справочных данных", "инженерии мастер-данных") к операционной деятельности, рядом с управлением конфигурацией и управлением изменениями -- это всё очень рядом с PLM (хотя поставщики PLM-систем этого и не осознают, и не дают такого инструментария. Ну, разве что Dassault Systemes прикупила Exalead, но это всё-таки не совсем то). Вот такой вот операционный шовинизм по отношению к инженерии знаний, ибо у этих "инженеров по знаниям" основное -- это "знание о знании", от них не требуется инженерного "знания о целевой системе и способам её получения", знания о железе и софте, химии и прочностных расчётах. А "настоящие инженеры" (системные и инженеры по специальностям) у нас в предпринятии будут заниматься не формализацией-деформализацией знаний/данных как таковых, а содержательной инженерной работой с информацией по созданию целевой системы -- добычей и использованием справочной информации, решением традиционных инженерных задач. И будут поэтому формализовывать/деформализовывать знания только по сопричастности к их содержательной инженерной деятельности.
Помним, что все приведённые разведения (прежде всего инженерии и операций) очень условны. Так, Ассоциация инженерного менеджмента предпочитает говорить о непрерывном спектре инженерных и менеджерских дисциплин (где "чистая инженерия про железо" и "чистый менеджмент про людей" находятся на краях, а "инженерный менеджмент" где-то посерединке, и включает в себя как раз главным образом "операционный менеджмент" в самых разных его вариантах -- проектное управление, управление цепочками поставок и т.д.). Условность отнесения рассматриваемых вопросов инженерии и управления знаниями, равно как сближения управления конфигурацией и данными (помним про одноимённую ассоциацию -- http://www.acdm.org/), и замешивания их в одну кучу в части "операционного управления" должна быть предельно ясна.
3. Пример: верификация с использованием лингвистических технологий.
Вот тут я рассказывал об использовании лингвистических технологий в инжиниринговых компаниях: http://ailev.livejournal.com/1012295.html. Если кратко, то мы хотим вытаскивать информацию из неформальных текстов, и превращать эту информацию в данные (то есть представлять в формализме, удобном для непосредственного использования в CAD системах) для последующей компьютерной обработки инженерными алгоритмами.
Если мы хотим автоматизировать (сначала чуть-чуть, потом побольше, а потом и вовсе сделать автоматической) верификацию данных проекта на соответствие данных требований проекта, а также справочных данных стандартов (неважно, добровольно используемых, или вменённых органами технического регулирования), то нам нужно:
а) преобразовать тексты в инженерные данные (или вернуть на доработку, если тексты мутны -- при сегодняшнем уровне развития лингвистических технологий есть огромная вероятность, что при возможностях разночтений или пропусках информации там, где будет спотыкаться лингвистический софт, там и люди будут спотыкаться -- см. в Гугле ' "Text Analysis" "Requirements Engineering" ', обращая внимание на даты публикаций и учитывая достижения компьютерной лингвистики последних двух-трёх лет).
В компьютерной лингвистике об этом преобразовании говорят как об извлечении фактов, это непосредственно практики инженерии знаний (перевод знаний из менее формального представления в более формальное).
В нашем конкретном случае факты мы будем извлекать сразу в формате справочных данных ISO 15926 (Почему? Ответ есть в первых текстах из последовательности чтения в http://dot15926.livejournal.com/27293.html). Это означает, что к используемым системам компьютерной лингвистики (Compreno, GATE, NLTK, UUIMA и т.д.) нужно сделать адаптеры ISO 15926, чтобы результаты их работы были единообразно представлены.
Начальный наш заход мы делали на полностью "ручную" практику инженерии справочных данных ISO 15926 (версия 2 этой технологии опубликована полтора года назад в http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc) и использование в ней также полностью "ручной" практики характеризации текстовых документов (см. нашу полугодичной давности технологию семантического моделирования инженерных документов TabLan -- http://techinvestlab.ru/files/TabLan/TabLan.rar), но сейчас думаем о возможностях автоматизации этих практик при помощи совершившегося в последние два-три года прорыва в технологиях компьютерной лингвистики (см. эксперименты в http://dot15926.livejournal.com/33691.html). Конечно, это будет по сравнению с ручной работой примерно так же, как работали первые системы генерации кода по высокоуровневым моделям: генерировался костяк кода со множеством ошибок, а затем он долго-долго "дорабатывался напильником" до качественного результата. Сейчас ситуация много лучше, и генерация кода по моделям проходит уже без того, чтобы лезть руками в получившийся код. Конечно, ISO 15926 код, сгенерированный в результате "автоматической характеризации инженерных текстов" придётся "дорабатывать напильником".
Мы в TechInvestLab на первых порах эту "доработку напильником" будем делать с использованием нашего .15926 Editor. Недаром он не только "мэппер", но и "редактор" -- причём эту "доработку напильником" в типовых случаях мы сможем автоматизировать, написав для соответствующих обработок код на Питоне. В итоге мы получим автоматизацию не только лингвистического парсинга "читателя на естественном языке", но и автоматизацию характеризационной работы инженера (различающего классы и индивиды, склеивающие по-разному названные объекты в один на основании своих инженерных знаний об описываемой предметной области) -- то есть постепенно мы получим "экспертную систему по характеризации инженерных текстов".
б) положить справочные данные в PLM (SPF, ENOVIA, SmarTeam, и т.д.), к которым имеют доступ выполняющие верификацию САПРы. Для этого должны быть адаптеры данных ISO 15926 для используемых PLM. Выпускаемая в сентябре 2012 г. версия 1.0 нашей платформы .15926 как раз поможет разрабатывать эти адаптеры.
Пункты а) и б) тем самым вполне укладываются в традиционную проблематику PLM, "систем управления жизненным циклом", систем поддержки операционной деятельности в части проектной инженерной информации (а дальше по жизненному циклу -- в проблематику ERP и EAM систем, см. слайд 5 в http://www.slideshare.net/ailev/plm-principles-ailevjun12). Цель -- исключить инженерные коллизии на как можно более ранней стадии, т.е. не при сборке или даже эксплуатации целевой инженерной системы, а пока эта система ещё находится в компьютере, проектной стадии. Куски информации, по которым можно определить коллизию, должны смаршрутизироваться тому выполнителю, который сможет эту коллизию обнаружить содержательно. Это задача операционного управления, управления конфигурацией и логистики. И в рамках этой операционной задачи мы просто выделяем инженерию знаний и управление знаниями (обобщая с инженерии справочных данных и управления справочными данными за счёт задействования автоматизированных и "ручных" характеризационных технологий, т.е. технологий, формализующих неформально выраженное в чьих-то мозгах и текстах на естественном языке знание).
в) выполнить верификацию средствами САПР и систем инженерного моделирования, ибо содержательная/инженерная работа с тем или иным видом информации происходит именно в предметно-ориентированных САПР и системах инженерного моделирования, а не в относящейся к управлению операциями "учётной и логистической" СУЖЦ aka PLM (грубо говоря, электрические стандарты проверять средствами электрического САПР, взрывоопасность -- средствами моделирования взрывов, габариты -- средствами 3D САПР, и т.д. -- ибо в PLM идёт только операционная работа). Вот тут-то и происходит "инженерное творчество", "думание", тут-то и нужен искусственный интеллект, инженерные расчёты, инженерное моделирование и прочие хитрые методы задействия формализованного уже знания. Это инженерная деятельность, ей должны заниматься инженеры по специальностям, а также системные инженеры.
Когда я в своих постингах говорю о том, что хотел бы двигаться в сторону систем искусственного интеллекта, я вовсе не имею ввиду, что сделаю тот самый алгоритм GPS (general problem solver) -- статистический на базе machine learning, или какой-то хитрый логический, программируемый вручную наподобие древних экспертных систем (чур меня, все почему-то предполагают, что я всенепременно повторю какую-то допотопную архитектуру середины семидесятых, опираясь на мои постинги про ISO 15926, имеющие отношение к логистике, а не к вычислениям над знаниями! Нет! Я не такой!). Нет, я пока не хочу залезать в "компьютерное думание" с использованием формально представленных знаний. Я хочу только обеспечить операционное управление знаниями, инфраструктуру, в которой "думатели/вычислители" (человеческие и компьютерные, а также их симбизы -- киборги) будут получать знания/данные в понятных для них формализмах, в готовом для употребления в думку/вычисление виде.
Алгоритмы для проектирования киберфизических систем должны писать знатоки этих киберфизических систем: для проектирования электроники -- знатоки этой электроники, для проектирования химических реакторов -- знатоки химии, и вообще -- думанием должны заниматься спецы-предметники и спецы-модельеры. Моделеориентированной системной инженерии никто не отменял, и там будут рулить математические модели (в том числе и дискретные математические модели, но и модели численной математики -- куда ж без неё!). Я думаю, что роль "общих решателей проблем" с каким-то "статистически обученным искусственным интеллектом" в инженерных задачах ограничена. Естественные интеллекты продвигались в инженерии именно путём формализации и точных расчётов. Если же полагаться на "статистические алгоритмы", то какой-то не в меру бодрый искусственный интеллект, обучаясь, примет значение косинуса для военного проекта равным 3, потому как ему статистически достоверно встречалась фраза "во время войны косинус вообще до трёх доходил". В этом месте сегодня столько разных спекуляций, и люди так возбуждаются в разговорах, что я бы пока ввёл мораторий на обсуждение "искусственно интеллектуальных алгоритмов инженерной работы".
А вот операционное управление справочными (да и проектными) данными, чтобы все эти разной степени интеллектуальности и автоматичности одни инженерные системы на входе получали нужные им данные, а результаты их работы затем попадали дальше как входные данные в какие-то другие инженерные системы -- вот этим и нужно заняться, это инфраструктура для "думательных" алгоритмов, управление жизненным циклом инженерного проекта, операционное управление предпринятием.
Заметим, что если речь идёт не о верификации, а о generative design, то связанные с операциями/PLM пункты a) и б) не меняются -- задача добычи информации и предоставления её выполнителю-инженеру (киборгу -- человеку, укомплектованному инженерным софтом по самое не балуйся) остаётся. Но этот инженерный софт тогда вместо (или вместе с верификацией) производит порождение инженерного артефакта -- чертежей, инженерного решения, архитектурных описаний или ещё чего-то такого, что раньше САПР выполняли исключительно в режиме "редактора текстов", не производя более интеллектуальных действий, чем перевод одних единиц измерения в другие, или протягивание прямой между двумя указанными инженером точками.
Если вдруг выяснится, что к нам пришёл настоящий САПР с искусственным интеллектом, который что-то хочет сделать с использованием блендинга, прототипов и прочих изысков современных когнитивных архитектур, подсмотренных у человека (ср. с последним абзацем в http://ailev.livejournal.com/1012295.html -- про коммуникацию с людьми, а не САПР), то нам придётся полностью пересмотреть всю цепочку практик инженерии знаний (выкинуть ISO 15926, а также значительную часть в системах компьютерной лингвистики), чтобы извлекать из текста данные, представленные в особо удобной для употребления в этих (пока мне неизвестных) супер-пупер-когнитивных программах. Пока же все мне известные инженерные программы юзают объект-ориентированное представление, для которого логическое представление данных компьютерной лингвистики (они сейчас все полюбили RDF) и онтологическое представление ISO 15926 вполне адекватно и даже представляет собой огромный шаг вперёд по сравнению с предыдущими попытками (см. эволюцию практики интеграции данных жизненного цикла в http://ailev.livejournal.com/929451.html). Так что тут внимательно наблюдаем и даже ведём какие-то исследования, но клиентам предлагать ещё совсем нечего -- поэтому "за неимением гербовой пишем на простой".