Обсуждение

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

У меня про кейс менеджмент в других постингах написано много. А еще я много раз писал, что любая PLM -- это репозиторий плюс issue tracker. Кстати, по вашему стилю комментов, если бы я написал про "оборот", вы бы меня спрашивали в комментах к этому про какие-нибудь отвлеченные от этого "оборота" вещи -- про какую-нибудь "онтологию методологии" в лучшем случае, или типологию языков, или нотации для речи, или еще что-то другое -- но уж точно не про "оборот".

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

Разные группы используют разную терминологию. Так, сообщество ISO 15926 четко различает information exchange и information integration, а другие люди используют слова про "оборот", третьи про еще что-то. Системы инженерного документооборота по факту все содержат issue tracker (поддерживающий "запрос на изменение"), другое дело насколько жестко может быть затем задан маршрут согласования. Там есть еще тонкости с проектным подходом (диаграммами Гантта), но обычно оговаривается в таких случаях, что это "проектно-процессный подход" (т.е. "мы тут не по учебникам, а по жизни"). Поэтому я обсуждаю представление информационных объектов, и лишь потом готов обсуждать работу по поддержке операций с ними. Кстати, напомню: http://ailev.livejournal.com/867599.html (но тут я опять боюсь, что вместо поколений систем инженерного документооборота мы тут же начнем обсуждать "языкоподобность структуры процессов" или еще что-то такое -- и опять будет сплошной оффтоп).

Под вышеуказанное определение "3. Гибридные системы" попадают практически все современные Enterprise Content Management системы. Потому что, у них в основе какая-никакая структурированная SQL-подобная "базка данных" (object store), а уж потом только ссылка на хранилише FileStore. Основная база и является (представляется через интерфейс) нам в виде информационной модели, которая иной раз может быть визуализирована достаточно разнообразно, например, в виде объектов какой-либо гео-карты или мнемосхемы. В более совершенных системах, возможность атрибутивного расширения модели Object Store (например атрибутами, распознанными, верифицированными, в том числе с системами эталонных справочников, классифицированными, взятыми из коллекций эталонных аттрибутов) позволяет нам поддержать процесс постоянной структуризации неструктурированного. Теперь вернемся к вопросу модели основной базы. Могут ли её объекты соотвествовать ISO 15926? Целиком вряд ли (не знаю полноты стандарта), но классы данной базы могут опираться на классы указанного стандарта. Более того, объектом данной базы может быть вовсе не документ, а объект реального мира, системы и пр. И аттрибут данного объекта может иметь свойство типа "ссылка" и отаправлять нас на файл в файловом (или другом) хранилище. Таким образом, есть гипотеза, что концептуально, возможно решение перманентной структуризации нашего информационного поля, которое может иметь входы как неструктурированной (видео, tiff), слабоструктурированной (e-forms,e-docs,files with data), хорошо структурированной (databases), семантически структурированной информации (?RDF) и т.д. Определение "2.Электронный инженерный документооборот" возможно тоже стоит обобщить на "2.Электронный документооборот", чтобы не говорить про узкую предметную область (хотя счет-фактура,закон,сейсмическая модель, наверное тоже имеет свою "инженерию" или "конструкцию").

Нет, enterprise content management -- это у меня второй пункт, это документооборот (а документы называют "контентом", подразумевая, что эти документы провязаны гиперссылками и документы имеют разные типы). Я специально подчёркиваю "инженерный" документооборот, чтобы показать необычные типы медиа -- P&ID, векторную графику с атрибутами из CAD систем и т.д.. В обычных же ECM системах (не-инженерных) чаще всего имеют ввиду только "фотографии, видео и любые другие файлы", но приходят в ужас от разнообразия инженерных типов данных. В этих ECM системах второго поколения обычно или SQL, или объектная база данных, но там обычно не информационная модель предметной области (очень-очень редко накладываемая на GIS), но просто расширенные наборы мета-информации документов (разные варианты "карточки документа", часто привязанные составом атрибутов к issue tracker или BMP-движку). Про гибридные системы я бы настаивал, что в основе этих гибридных систем не SQL-база данных, а всегда очень кучерявая объектная база данных с представлением объектов предметной области (то есть отражающая кусок информации из "парсированных в нее" документов). То есть в гибридной системе с геометрией из CAD-систем в базе данных хранится более-менее упрощенная и с каким-то количеством атрибутов геометрия целого объекта -- по этой модели осуществляется беглый просмотр и навигация, а затем подтягивается исходный документ для более детального просмотра. Что касается формата представления информации (ER-модель, объект-атрибутная модель, семантика с триплами или квадами), то это тут всё одно. ISO 15926 это семантическая модель, но я как раз поминаю, что не стоит говорить о семантических моделях для каталога файлов (даже очень навороченного и с рядом классификаторов), если вы просто храните в этих каталогах файлы.

Каталог файлов (правильнее сказать хранилище файлов) не виден из ECM-системы. А видны объекты ("объект" не тождественно "документ"), которые множественным образом могут быть привязаны к классификаторам (в зависимости от проблемной области) и ссылкой к хранилищу файлов. Классификаторы, тоже в свою очередь могут быть связаны друг с другом. Документы (в понимании "файл") в ECM друг с другом не связаны, а связанны именно с объектом, который может быть как "подшивкой документов", так и "описанием объекта физической природы" (узел крана). Задача ECM не столько хранить в себе все файлы, сколько привязывать к объектам бизнеса ссылки на информационные источники (в том числе и объекты PDM систем). В последнем случае мы говорим Federated Services. ECM в текущем исполнении не способен заменить PDM систему, но... это может быть вопросом времени. Ибо открытость и универсализм ECM-платформ позволяет писать addons для различных предметных областей. И практика показала, что от более абстрактной области спуск в более предметную область проще (мне известны примеры более 50-ти проблемных addons), чем из предметной области пытаться охватить все смежные (для примера, сегодня в Ильюшине сказали что договора с проектными организациями они ведут в PDM - это же удобно с точки зрения конструктора :) Геометрию объекта информационная модель ECM безусловно не передаст, хотя стоило бы подумать над этим (геометрия для меня это визуализация алгебры). Повторюсь, что сложность CAD-документов не сложнее геологических моделей. При этом хранить кусок геологической модели в структурированном виде это надо еще подумать зачем, возможно кусок структурированной информации нужен для привязки к пространственным координатам (?). Проблемный взгляд со стороны главы предприятия - ECM это надмножество инженерных ECM(PDM), финансово-юридических ХД, геологических ХД, нормативных ХД, медиа ХД итд. Простой пример накладывания на ГИС можно глянуть на ролике: http://www.youtube.com/watch?v=UminNh0mcAU . Есть более сложные примеры. Можете дать ссылки на классификацию представления информации? Что-то по примерам квад?

Вы сами как раз и пишете про то, что ECM пока не дотягивают до PDM, а вот PDM с лёгкостью могут быть использованы как ECM. Фишка у них как раз в кучерявости модели данных: у ECM базовая модель данных всё-таки "дерево папок" с робкими расширениями в объектную сторону, а вот в PDM (PLM) полноценная объектная модель -- да еще и с какой-то онтологией в самом верху, чтобы хоть как-то гарантировать общность картины мира для множества профессиональных предметных представлений. Я и говорю: большинство "документарных" ECM не дотягивают до "гибридных" -- они суть разные поколения, при всей размытости границ. Обратите внимание, меня тут опять же меньше волнуют "файлы", привязанные к файлам объекты и ссылки на эти файлы. Гибридная PLM рассматривает свои "электронные документы" не хуже чем части гипертекста, и позволяет работать ссылкам даже между документами. А вот в датацентричной PLM уже понятие "ссылки" опять восстанавливается: из объектной базы к документам. Классификация представления у меня проста: реляционная модель, объект-атрибутная (объект-ориентированная модель), факт-ориентированная (семантическая) модель. Все эти SQL, SPARQL и прочее тут неважны, важна парадигма.

По замыслу ECM обязана не дотягивать, ибо сервисы ECM сейчас переходят в область Middleware, то есть получают свой уровень в стеке программных сред: ОС, СУБД, Application Server,...,ECM, и только далее предметные приложения (addons). PDM, как и другие подобные классы систем других предметных областей технологически могли бы абстрагиваться, но идея (ядро, концепт) у них идет из предметной области, а не из философии. Мне трудно представить себе что какой-либо производитель PLM будет работать с системи класса - Middleware (старый, но очень точный термин). Для этого они должны поменять как минимум миссию, как максимум, широту своего маркетинга. Ибо нишевой игрок не может диктовать макротехнологический мейнстрим. Кстати, очевидная фактическа ошибка считать, что у ECM базовая модель это "дерево папок". Ключевые домены у них "item" (он же "объект", "запись"), которые объединяются в каталоги (они же "списки", "реестры"), а реестры могут быть связаны "классификаторами" (включение ко многим), при этом классификатор несет в себе всего лишь вторичные признаки, которые "объектом" уже не наследуются. http://pics.livejournal.com/ttfna/pic/0000sffc/ Файлы это не центр вселенной в ECM. Центр есть - объект, который может жить даже без своего "файла". Типовая объект-атрибутная модель. Все-таки на квады дайте ссылочки.

Ответ тут: http://ailev.livejournal.com/965564.html Вот про факт-ориентированную модель: http://ailev.livejournal.com/699549.html Вот про квады: http://en.wikipedia.org/wiki/Resource_Description_Framework -- и там указание про quad stores как triple stores, хранящих для каждого трипла еще и контекст (именованный граф). Пример quad store: http://virtuoso.openlinksw.com/rdf-quad-store/ Нужно отметить, что пока нет ни одной PLM, где использовалась бы факт-ориентированная модель. Но примеры использования этой модели в инжиниринге уже появляются для отдельных приложений интеграции данных (например, www.topquadrant.com/docs/pr/11-08-12%20_TQ_%20EPIM_ReportingHub.pdf).

Я не знаю что дает это различение "information exchange и information integration", может какую то фитюльку и дает, но я о другом. Посмотрим на ситуацию, в которой приходится нечто различить. Идет инженерный проект. Инженеры в нем работают и для этого используют: 1. системы информационной поддержки коммуникации (эл почта, скайп и пр.), 2)всякие рисовалки, не буду перечислять, 3)всякие базы данных документов (текстов, чертежей, нормативов и пр), 4) руководитель проекта использует некую систему управления инженерным проектом (там задачи, сроки, ресурсы, деньги и пр.)5)используется некая общая для всех инженеров система моделирования проектируемого объекта, например, атомного реактора (пусть она будет многопользовательская, а значит, каждый инженер по мере своей разработки добавляет самостоятельно туда свой кусок "объекта"), 6)общая база данных конструктивных и проектных элементов (примитивов), каталоги материалов (болты, гайки, узлы, балки, фермы, блоки,и пр. ) 7) общие каталоги строительных и прочих работ (земляные работы, сборочные работы, работ по технологической обработке материалов, например, фрезеровка, токарное точение, сварка, работы по испытаниям, тестированию и пр), 8) транзакционная система (учитываются все затраты проекта, использованные материалы, полученная выручка и пр.)9) аналитические системы (со встроенными базами знаний и пр)10) системы визуализации хода проекта для заказчика (всякие BW системы с красимыми отчетами, светофорами и пр.) Теперь, добавьте те системы, которые я не перечислил и потом скажите, о каких системах вы написали и которые как то там развивались от простых к сложным?

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

А разве системы не есть набор функций, для исполнения которых они сделаны? Разберемя с функциями, - разберемя с системами. Кстати, ваш диалог с другим человеком в этой ветке идет похожим образом. Он вам тоже рассказывает о неком функциональном пуле (при этом упоминая опредленый клас систем), но мог бы его и не упоминать. Вы уже там и до слова "философия" дошли и до слова "парадигма", про системы уже и забыли. И это правильно. Еще немного и до моих слов дойдете, которые вы ругаете.

"факт-ориентированная (семантическая) модель?" - а здесь нет противоречия?

Нет, я отдельно рассматриваю множество функций -- а затем раскладываю группы функций по разным системам. Ибо системы имеют границы. Кстати, умение рассматривать "свойства" (например, "красный") в отрыве от любых объектов (т.е. отход от субстанциальной парадигмы) является сильной стороной предлагаемого нами варианта моделирования мира. Это же относится к функциям, которые можно рассматривать и без систем -- а потом ассоциировать с теми или иными системами. В соседней ветке идет архитектурный диалог, он рассказывает не о функциональном пуле, а о классе систем с определенной архитектурой, а я ему отвечаю ограничениями на то, какие функции можно возлагать на системы с той или иной архитектурой. До слов "парадигма" и "философия" я дошел несколько десятков лет назад. Фишка в том, чтобы пойти дальше этих слов, а не застревать на них намертво, как это делают СМД-методологи. Я вот себя регулярно ловлю, что перебарщиваю с этими философствованиями (см, например, http://ailev.livejournal.com/867290.html). А вы наоборот, этим пока хвастаетесь. Ничего, со временем пройдёт, как и у меня прошло ;-)

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

"умение рассматривать "свойства" (например, "красный")", - вы на самом деле считаете, что красный - это свойство?

Я тут не при чем. Читайте книжку BORO. Уже многие читатели моего блога прочли эту книжку, и мне сказали спасибо за то, что я их в неё ткнул. Вот и вы читайте, не тратьте моё время на пустопорожние разговоры.

5 лет прошло, а в инженерных проектах воз все там же.

Если понимать, что "практика = дисциплина + технология", при этом дисциплина меняется раз в 20 лет, а технология от вендоров раз в четыре года, то это постоянство неудивительно: я тут про дисциплину пишу.