Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Гармонизация русскоязычной терминологии, разные информационные модели, отображение их данных

Ключевые темы для размышлений:

1. Русскоязычная терминология информационного моделирования жизненного цикла, адаптированная к текущей российской терминологии, а также отображенная на основные терминологические системы (по списку второго пункта http://ailev.livejournal.com/606636.html, плюс сюда нужно подключить терминологию конкретного софта -- INGR SmartPlant, Bentley OpenPlant, AVEVA VNet и т.д.). Общий глоссарий для всех этих information entity, document, OIM, schema, knowledge model, interface, integrated repository, product model, project model и т.д.. Так сказать, вписать русский мат в международную культуру, причем во все ее варианты сразу.

2. Структура информационных моделей, использующихся в жизненном цикле. Общемировое разделение -- product model и project model. Product model примерно соответствует информационным результатам технических процессов SE, а project model -- результатам организационных и проектных процессов. Но дело в том, что SE предлагает отдельно обсуждать модель жизненного цикла (точно не проектную), и вообще ставит вопрос о наличии организационной действительности. С другой стороны, некоторые техники проектного управления (Голдратовская, например) ставят вопрос о невозможности проектного управления в рамках одного проекта и требуют логистику относить не к проекту, а к организационному уровню (управлять ресурсами сразу только для портфеля проектов). И мы тут же натыкаемся на факт, что все еще сложнее: расширенная организация проекта с многочисленными контракторами, конечно, не эквивалентна (в том числе в своем определении глобального максимума) "просто организации", но включает в себя, конечно, все основные половые признаки организации по ISO 15288 -- наличие группы людей, их ответственности, полномочий и отношений. Для этой "контрактной" организации вполне можно построить конструктивную модель DEMO, и еще не факт, что все транзакции в этой модели за время проекта отработают только один раз. Но я не уверен, что в ISO 15288 имеют ввиду именно "расширенную организацию проекта", ибо тогда в списке орг.процессов не было бы управления портфелем проекта. Пока нет решения этих вопросов соотношения программы (портфеля проектов) и проекта, проектной организации (расширенной организации проекта) и конкретных участвующих организаций, ничего путного сказать про структуру информационных моделей нельзя. Тут, конечно, можно обратиться к контрактным процессам и предложить поддерживать отдельную контрактную организационную модель как гибридную "проектно-организационную" -- со всеми вытекающими. Прикидки (без учета всех описанных сложностей): http://ailev.livejournal.com/605489.html

3. Разобраться, как будет устроен мэппинг данных организационной и проектной модели (кому и зачем из технологического софта потребуется доступ к организационным и проектным данным проектного и организационного софта, и наоборот -- кому и зачем из проектного и организационного софта потребуются данные софта технологического. Какие при этом обмены данными придется организовывать, и какую из трех онтологических схем -- родного репозитория, ISO 15926-2, Gellish -- нужно будет организовывать через шаблоны). При этом не исключено, что аналогичные организационные функции захочется иметь для всех частей проекта, который неожиданно будет выполняться по 30% в репозиториях каждого из ведущих брэндов (а еще 10% в условиях отсутствия подобного репозитория). Собственно, с этого пункта все и начиналось, но последовательное разбирательство привело к появлению первых двух пунктов как более важных.

Направлением основного размышления на этих днях объявляется пункт 2.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 4 comments