что такое mdr в проектировании
Управление информацией объектов капитального строительства
Настоящий обзор основан на практике применения ISO 15926 и CFIHOS для объектов нефтегазового и нефтехимического хозяйства. Рекомендовано для объектов, схожих по объему и типу проектных решений, из других отраслей.
Введение
CFIHOS – Capital Facilities HandOver Specification. Дословно переводится как инструкция или стандарт по передаче данных объектов капитального строительства. Это промышленный стандарт, разработанный для улучшения того, как информация передается между компаниями, которые владеют, эксплуатируют, возводят установки для перерабатывающей (непрерывное производство) и энергетической отраслей. Является практическим применением ISO15926-4.
Разработка стандарта начиналась с классификации наименования оборудования и вспомогательных спецификаций. В итоге целью стало создание общего языка обмена информацией в указанных выше секторах.
Актуальная версия стандарта 1.4. Разработчик – организация USPI, учрежденная компанией Shell в 2012 году. В состав USPI входит более 70 международных инжиниринговых и софтверных компаний.
В основе CFIHOS лежит так называемая библиотека справочных данных – RDL, определяющая в качестве стандарта правила наименования оборудования, его атрибутов, дисциплин и документов. Версия 1.4 включает:
Перечень классов для тэгов и оборудования (что оборудование из себя представляет и что осуществляет)
Перечень свойств (атрибуты, характеристики, измерения)
Перечень требований по классам (требования к данным и документам)
Стандарт уникальной кодификации данных для облегчения цифрового проектирования и других работ
Перечень типов документов
В настоящее время CFIHOS покрывает только обмен структурированной информацией и документами.
Концепция
В CFIHOS принят следующий цветовой стандарт для определения источника данных:
Оборудование представляет физический производственный фонд или актив (asset), удовлетворяющий конкретной функции, представленной тегом. Таким образом, свойства оборудования относятся к свойствам актива, такие как серийный номер, производитель и фактическая дата покупки.
Типы тэгов могут быть категоризированы,
Тэги без оборудования – что-то, называемое «мягкими» тэгами, например, DCS(АСУТП) тэги
Теги связанные с оборудованием – что-то, называемое «твердыми» тэгами.
Информация объекта капитального строительства включает в себя данные и документы, необходимые для эксплуатации и обслуживания этого объекта, включая, но не ограничиваясь следующими:
Планы проекта и процедуры
Результаты проектирования, включая те, что поставляются Поставщиками/Производителями
Что такое «система управления мастер-данными» и зачем она нужна
Какие бывают данные
Прежде чем перейти непосредственно к системам управления мастер-данными, давайте определим, какого рода вообще бывают данные.
Ниже представлены 5 ключевых типов:
1. Метаданные (Metadata);
2. Референс-данные (Reference data);
3. Мастер-данные (Master data);
4. Транзакционные данные (Transactional data);
5. Исторические данные (Historical data).
Метаданные – это данные о данных. Они нужны для понимания и определения, какими данными оперирует предприятие. Метаданные определяют структуры, типы данных, доступы к ним и т.д. Существуют различные схемы для описания метаданных. Например, для описания структуры XML-документа может применяться XSD-схема, для описания веб-сервиса – WSDL-схема.
Референс-данные – это относительно редко меняющиеся данные, которые определяют значения конкретных сущностей, используемых при выполнении операций в рамках всего предприятия. К таким сущностям чаще всего относятся: валюты, страны, единицы измерения, типы договоров/счетов и т.д.
Мастер-данные – это базовые данные, которые определяют бизнес-сущности, с которыми имеет дело предприятие. К таким бизнес-сущностям обычно относятся (в зависимости от предметной отраслевой направленности предприятия) клиенты, поставщики, продукция, услуги, договора, счета, пациенты, граждане и т.п. Кроме информации непосредственно о той или иной мастер-сущности, в мастер-данные входят взаимосвязи между этими сущностями и иерархии. Например, с точки зрения поиска дополнительных возможностей продаж, может быть очень важно выявлять явные и неявные взаимосвязи между физическими лицами. Мастер-данные распространяются по всему предприятию и участвуют во всех бизнес-процессах. Обычно мастер-данные воспринимаются как ключевой нематериальный актив предприятия, т.к. от их качества и полноты зависит эффективность его работы. В России часто вместо термина «мастер-данные» используют термин «нормативно-справочная информация».
Транзакционные данные – это данные, которые образовались в результаты выполнения предприятием каких-либо бизнес-транзакций. Например, для коммерческого предприятия: продажи продуктов и услуг, закупки, поступления/списания денежных средств, поступления на склад и т.п. Обычно такие данные базируются в системе управления ресурсами предприятия (ERP) или других отраслевых системах. Естественно, транзакционные системы широко используют мастер-данные при выполнении транзакций.
Исторические данные – это данные, которые включают в себя исторические транзакционные и мастер-данные. Чаще всего такие данные аккумулируются в ODS и DWH системах и служат для решения различных аналитических задач и поддержки принятия управленческих решений.
Cистемы управления мастер-данными
Прежде чем перейти к системе управления мастер-данными, определим, что такое управление мастер-данными вообще.
Управление мастер-данными (Master Data Management, MDM) – дисциплина, которая работает с мастер-данными в целях создания «золотой записи», то есть целостного и всестороннего представления о мастер-сущности и взаимосвязях, эталона мастер-данных, который используются всем предприятием, а иногда и между предприятиями для упрощения обмена информацией.
Специализированные системы управления мастер данными (MDM-системы) автоматизируют все аспекты этого процесса и являются «авторитетным» источником мастер-данных масштаба предприятия. Часто MDM-системы управляют также и референс-данными.
Ситуация, когда MDM-система является единственным источником мастер-данных, все изменения вносятся в MDM-систему и только потом передаются в системы-потребители, называется «системой записей». Это идеальная ситуация для управления мастер-данными. Однако в реальной жизни все не так просто: MDM-система не всегда будет являться «системой записей». Из-за особенностей бизнес-процессов конкретного предприятия, технических сложностей конкретных систем и т.д., приходится создавать «копии» мастер-записей. Система, в которой содержится копия мастер-данных, называется «системой ссылок». Чтобы не терять управляемости, «система ссылок» обязательно должна находиться под управлением и синхронизироваться с «системой записей».
Три измерения MDM-систем
Рассмотрим MDM–систему в трех измерениях:
Обычно MDM-системы не внедряются «с наскоку», т.к. их внедрение – это сложный процесс последовательных преобразований масштаба всего предприятия, от ведения разрозненных данных до создания целостного всестороннего представления о мастер-сущности. Поэтому внедрение MDM-систем выполняется последовательно с постепенным приближением к целевому результату в трех указанных измерениях.
Рассмотрим подробнее эти измерения.
Домены
В контексте управления мастер-данными под доменом понимается конкретная область мастер-данных. Самые распространённые домены мастер-данных – это домен клиентов и домен продуктов. В западной литературе сложились устоявшиеся термины для управления мастер-данными в рамках этих доменов: Customer Data Integration (CDI) – для домена клиентов и Product Information Management (PIM) – для домена продуктов.
К CDI традиционно относятся не только клиенты, но и организации или физические лица, которые могут называться по-разному в зависимости от отрасли предприятия: клиенты, поставщики, банки, фонды, пациенты, граждане и т.д.
К PIM традиционно относятся: продукция, товары, материалы, услуги, работы и т.д.
Есть много общего в подходах к управлению мастер-данными CDI и PIM, но есть также и много отличий. Например, при дедубликации клиентских сущностей в большинстве случаев выполняется простой синтаксический анализ атрибутов сущностей и их сопоставление на основе вероятностных алгоритмов, в то время как в продуктовом домене проводится семантический/онтологический анализ атрибутов с подключением механизмов самообучения. Кроме того, в продуктовом домене у сущностей в зависимости от выбранной категории могут сильно различаться атрибуты (например, у ноутбуков свой набор атрибутов, а у стиральных машинок – свой). Все эти особенности различных доменов должны поддерживаться MDM-системами.
В последнее время имеет место тенденция создания мультидоменных MDM¬-систем с возможностью гибкой настройки структуры метаданных. Такая гибкость дает предприятию возможность описать мастер-данные конкретно под себя с учетом всех особенностей и нюансов, но при этом требует немалого времени и знаний, чтобы грамотно спроектировать и настроить такую систему. Также на рынке присутствуют системы с «жесткой» структурой мастер-сущностей, которые имеют уже корректно настроенные механизмы, но использование такой системы возможно только теми предприятиями, которые смогут подстроиться под нее. Обычно такие системы хорошо применимы для решения задачи управления мастер-данными в рамках какой-то узкой отрасли. По моему мнению, наиболее перспективными являются системы с гибкой моделью метаданных, но имеющие при этом преднастроенные для предприятий разных отраслей модели, которые можно быстро перенастраивать.
Методы использования
Методы использования MDM (Method of use) определяют то, для чего MDM система будет использоваться на предприятии. Иными словами, кто будет потребителем мастер-данных (естественно, их может быть несколько).
Основных методов использования три:
1. Аналитический (Analytical)
2. Операционный (Operational)
3. Коллективный (Collaborative)
Аналитический метод использования поддерживает бизнес-процессы и приложения, которые используют мастер-данные преимущественно для анализа эффективности бизнеса, предоставляют необходимые отчеты и выполняют аналитические функции. Часто это происходит посредством взаимодействия MDM с инструментами и продуктами BI. Обычно аналитическая MDM-система работает с данными только в режиме чтения, она не изменяет данные в системах-источниках, но занимается их очисткой и обогащением.
Операционный метод использования позволяет собирать, изменять и использовать мастер-данные в процессе выполнения бизнес-транзакций (операций) и служит для поддержки семантической согласованности мастер-данных в рамках этих операций внутри всех операционных приложений. Фактически, в этом случае MDM функционирует как OLTP-система, которая отрабатывает запросы от других операционных приложений или пользователей. Работа в таком режиме зачастую требует построения единого интеграционного ландшафта с использованием принципов сервис-ориентированной архитектуры (SOA) и применением инструментария сервисной шины предприятия (ESB). Идеально, если такие инструменты или входят непосредственно в MDM-систему, или являются ее продолжением (есть вендоры, которые имеют в своей линейке и MDM и ESB-решения, глубоко интегрированные между собой).
Коллективный метод использования позволяет создавать мастер-сущности в случаях, когда требуется коллективное взаимодействие между различными группами пользователей в процессе этого создания. Такое согласование обычно имеет сложные «ветвящиеся» бизнес-процессы, состоящие из различных автоматических и ручных задач. Ручные задачи выполняются различными специалистами по работе с данными (дата-стюардами) в порядке, определенном бизнес-процессом. Чаще всего коллективный метод использования применяется в продуктовом домене. Например, при создании нового продукта, когда существуют несколько ответственных за ввод разных данных, много ручной работы и финальное согласование. Важно, чтобы MDM-система позволяла настраивать произвольные бизнес-процессы для быстрой поддержки бизнес-процессов конкретного предприятия.
Стили внедрения
Обычно выделяют три основных стиля внедрения (implementation style):
1. Реестровый (registry);
2. Сосуществующий (coexistence);
3. Транзакционный (transactional).
Реестровый стиль внедрения предполагает создание источника мастер-данных как «системы ссылок» на нижестоящие источники данных. Реестровая MDM содержит только ключевые атрибуты, необходимые для идентификации и сопоставления сущностей. Реестровая MDM работает в режиме «только чтение», данные вводятся в системах-источниках и передаются в MDM для разрешения сущностей. Также в реестровой MDM могут храниться ссылки на источники неключевых данных, но сами эти данные обычно в MDM не передаются. Реестровый стиль внедрения обычно применяется в случае выбора операционного метода использования MDM (см. выше).
Сосуществующий стиль внедрения предполагает наличие распределенного ввода данных в нескольких источниках (бизнес-приложениях и MDM-системе). MDM-система в данном случае может являться «системой записей» только для части атрибутов. Тем не менее, в MDM-системе формируется полноценная мастер-сущность, изменения которой транслируются в другие системы (возможно, не все). Сосуществующий стиль внедрения довольно прост и часто применяется как первый шаг к следующему — транзакционному стилю, т.к. не требует глубокой переработки систем, взаимодействующих с MDM-системой.
Транзакционный стиль внедрения предполагает создание полноценной «системы записей», в которой хранятся все данные по мастер-сущностям. MDM-система в этом случае является «единственным источником правды» для всех систем-потребителей. Все операции по созданию и обработке данных выполняется на уровне MDM-системы. Ввод данных на уровне систем-потребителей запрещен. Такой подход обычно довольно сложен для внедрения, т.к. требует существенного изменения бизнес-процессов и систем-подписчиков.
Заключение
На практике, выбор той или иной стратегии внедрения MDM определяется многими факторами: целями предприятия в области управления мастер-данными, степенью зрелости предприятия, степенью готовности IT-инфраструктуры, наличием инвестиций на реализацию проекта и многими другими параметрами. Чтобы определиться со стратегией внедрения, нужно провести тщательный анализ всех этих факторов и составить подробное технико-экономическое обоснование проекта и детальный план-график с указанием фаз развития проекта. Но это уже другая обширная тема, требующая отдельного рассмотрения.
Одно можно сказать точно, что к внедрению MDM-системы нужно подходить очень взвешенно и поступательно. Большинство проектов внедрения MDM-систем проваливаются именно из-за недооценки сложности и объема изменений, с которыми приходится сталкиваться в MDM-проектах.
Что такое mdr в проектировании
Смотреть что такое «MDR» в других словарях:
MDR — or mdr may refer to: MDR is abbreviation of Master Document Register. MDR is abbreviation of Mort de rire in french (LOL equivalent). Mammalian diving reflex Mandar language Marina del Rey, California Management Data Repository, the relationship… … Wikipedia
MDR — MDR, der; = Mitteldeutscher Rundfunk … Die deutsche Rechtschreibung
Mdr — Mitteldeutscher Rundfunk Unternehmensform Anstalt öffentl. Rechts Gründung 1991 Unternehmenssitz … Deutsch Wikipedia
MDR — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français
Mdr — Liste de termes d argot Internet Article principal : Argot Internet. Cet article propose une liste de termes d argot (abréviations, onomatopées, acronymes, autres mots…) utilisés sur Internet. Elle ne peut lister que les plus courantes. Sauf … Wikipédia en Français
MDR 1 — Die Abkürzung MDR 1 steht für: MDR 1 Radio Sachsen, das Hörfunk Landesprogramm des Mitteldeutschen Rundfunks für Sachsen MDR 1 Radio Sachsen Anhalt, das Hörfunk Landesprogramm des Mitteldeutschen Rundfunks für Sachsen Anhalt MDR 1 Radio Thüringen … Deutsch Wikipedia
MDR — Mitteldeutscher Rundfunk * * * MDR = Mitteldeutscher Rundfunk. * * * MDR, Abkürzung für Mitteldeutscher Rundfunk. * * * MDR = Mitteldeutscher Rundfunk … Universal-Lexikon
MDR — Die Abkürzung MDR steht für: Mitteldeutscher Rundfunk, eine der neun deutschen Landesrundfunkanstalten Multiple Drug Resistance, bei Infektions und Tumorerkrankungen die Wirkungslosigkeit mehrerer vorher/früher gebräuchlicher und wirksamer… … Deutsch Wikipedia
MdR — Mitglied des Reichstages (MdR) bezeichnet sowohl einen Abgeordneten des Reichstages im Deutschen Kaiserreich als auch Abgeordnete des Reichstages in der Weimarer Republik. Beide Institutionen tagten im Reichstagsgebäude in Berlin. Formal werden… … Deutsch Wikipedia
mdr — ISO 639 3 Code of Language ISO 639 2/B Code : mdr ISO 639 2/T Code : mdr ISO 639 1 Code : Scope : Individual Language Type : Living Language Name : Mandar … Names of Languages ISO 639-3
MDR-TB — Klassifikation nach ICD 10 A15 Tuberkulose der Atmungsorgane, bakteriologisch oder histologisch gesichert A16 Tuberkulose der Atmungsorgane, weder bakteriologisch noch histologisch gesichert … Deutsch Wikipedia
Всё что вы хотели узнать об XDR в одном посте
На днях мне посчастливилось поучаствовать тут (обойдемся ссылкой на запись, без прямой рекламы), где обсуждалась такая новая тема на рынке ИБ, как XDR.
По горячим следам эфира зафиксирую основные тезисы: мои собственные мысли и факты относительно XDR и, в целом, отвечу на два важных вопроса: что такое XDR? зачем он стал нужен?
Что такое XDR?
XDR (Extended Detection and Response) – это расширенное обнаружение и реагирование на сложные угрозы и целевые атаки. В основе решения данного класса лежат продукты от одного вендора, то есть, это, в большей степени, моновендорная история.
EDR (Endpoint Detection and Response) – это ключевой элемент XDR. Без EDR не может быть XDR.
XDR должен строиться на сильном EDR, который сам по себе в рамках конечных точек должен охватывать большое количество источников данных: ПК, ноутбуки, виртуальные машины, мобильные устройства, плюс различные операционные системы (Windows, Linux, MacOS, Android, iOS, пр.).
XDR не равно EDR. XDR основан на расширении технологии EDR.
Буква “X” в начале сокращенного варианта названия “XDR” означает количество подключаемых источников/продуктов, которые участвуют в процессе обнаружения, расследования и реагирования. Количество подключаемых “X” зависит от потребностей заказчика, от уже внедренных решений от одного вендора, а также от выбранного поставщика XDR, то есть от его поддерживаемых источников (классов продуктов).
XDR – это, в большей степени, концепция, которая представляет собой кросс-продуктовую историю, обогащенную поверх дополнительными значимыми функциональными возможностями по реагированию на инциденты. Это единый центр сбора, нормализации, анализа, корреляции данных, расширенного расследования и реагирования с применением максимально возможной автоматизации. В составе также единая база данных, единая консоль, единая видимость того, что происходит в инфраструктуре, единый инструментарий по анализу первопричин и проактивному поиску угроз, единый улучшенный процесс приоритезации инцидентов, одна точка взаимодействия с Threat Intelligence и пр.
XDR подразумевает постоянную доставку обновлений, новых правил, плейбуков и т д. Это не просто отгружаемая коробка – это живой и растущий организм, актуализируемый с каждым изменением в ландшафте угроз.
Защитные средства, такие, как EPP+EDR, шлюзы (почтовый и веб), NTA/NTDR, CASB, IDM и ряд других (зависит от конкретного вендора), а также решения по защите индустриально-специфичных систем (банкоматы, АСУ ТП, IoT, пр.) выступают сенсорами для XDR и, в том числе, элементами, через которые возможно проводить действия по реагированию.
Минимальный комплект XDR – это охват конечных точек и сети, почтового и веб трафика, то есть, наиболее популярные и важные точки проникновения злоумышленников, которые следует контролировать в первую очередь. И, конечно, этот комплект должен быть обогащён актуальными данными об угрозах – Threat Intelligence.
Несмотря на заложенную изначально моновендорную историю, XDR не исключает взаимодействие со сторонними поставщиками, обработки данных от них и, в том числе, включения базовых SOAR возможностей, в большей степени связанных с реагированием. Вендоры, которые имеют в своем портфеле SIEM получать дополнительный бонус по быстрому подключению сторонних решений в общую концепцию XDR.
XDR – это, в первую очередь, облачная история, но XDR on-premise возможен как одна из опций. Это актуально для России, но не все вендоры на рынке это cмогут обеспечить. Если вендор исторически был и есть с on-premise решениями – он поддержит историю с on-premise XDR, при этом, что логично, в том числе уйдет и в облако.
XDR концепция может лежать в основе предоставляемых сервисов со стороны MSSP провайдеров, оказываемого сервиса MDR, например.
Про основные отличия XDR и SOAR можно почитать в моей отдельной статье тут
Зачем стал нужен XDR?
В настоящее время для противостояния более сложным угрозам, целенаправленным атакам и угрозам типа APT организациям необходимо уделять особое внимание не только уровню конечных точек, но и другим потенциальным точкам проникновения злоумышленника в инфраструктуру и, самое главное, на взаимосвязи между ними. Почему? Потому что профессиональные киберпреступники сегодня предпочитают многовекторный подход к проникновению в корпоративную сеть, атакуют как можно больше элементов инфраструктуры и часто объединяют множество различных методов в одну запланированную атаку. Организации должны обладать пониманием того, что происходит у них в рамках всей инфраструктуры, контролировать ключевые точки проникновения и получать полную картину атаки, иметь возможность быстро анализировать первопричины, проводить глубокие расследование сложных инцидентов и реагирования на них в рамках всей инфраструктуры, а не отдельных элементов.
Сегодняшняя ситуация с большим количеством разрозненных не интегрированных решений, отсутствием достаточного количества ресурсов и знаний для работы с этим зоопарком решений и невозможностью получить оперативно из этого всего полную картину происходящего. А также, недостаток автоматизации, необходимой в процессе обнаружения, расследования и реагирования, отсутствие кросс-продуктовых сценариев, наличие огромного числа ложно-положительных срабатываний, низкий уровень приоритезации, не самые лучшие показатели MTTD/MTTR – весь этот набор проблем требует поиска какого-то решения.
Благодаря XDR различные продукты от одного вендора обретают единую среду обмена данными и получения единой картины происходящего в инфраструктуре. Единая консоль управления для удобства работы аналитика, предоставляемый высокий уровень автоматизации действий в рамках расследования и реагирования, усовершенствованный процесс приоритезации инцидентов, улучшенные показатели MTTD и MTTR, сокращение числа ложно-положительных срабатываний и времени, которое аналитики тратят на процесс расследования и реагирования на инциденты делает сегодня XDR очень привлекательным.
На этом у меня всё! Дополняйте своими мыслями! До встречи!
TDMS Фарватер. Методики PMBOK и российские проектные организации
TDMS — известная объектно-ориентированная среда для хранения и управления разнообразными данными и процессами. После настройки объектов и бизнес-процессов можно применять систему TDMS практически в любой предметной области. Настройка – это описание на языке TDMS объектов предметной области, их статусов и правил управления этими объектами. Далее формируем структуру предприятия, назначаем права доступа и роли и в результате получаем уникальную Конфигурацию.
Мы начинаем публикации, посвященные TDMS Фарватер — конфигурации для проектировщиков и руководителей проектных компаний. Бизнес-процессы TDMS Фарватер базируется на PMBOK, как на эталонном своде правил по управлению проектами, и поддерживает традиционные процессы разработки проектно-сметной документации по российским ГОСТ.
Управление проектами
Управление проектами в современном мире признается как научная дисциплина. На изучение методов управления затрачивают свое время и ресурсы государственные и частные учреждения во многих странах. Создаются разнообразные международные и региональные организации и сообщества специалистов по управлению. В мире накапливается большой опыт практического применения знаний по управлению проектами, а бурное развитие информационных технологий в последние годы положительно влияет на распространение этих знаний.
Существует много стандартов и руководств по управлению проектами. Наиболее известен, пожалуй, свод правил (или еще его называют «свод лучших практик») PMBOK, Project Management Body Of Knowledge, в действующей 5-й редакции от 2013 года. Этот фундаментальный стандарт лежит в основе аналогичных руководств разных стран. Он издается американским институтом PMI.
Применение PMBOK является добровольным, но в развитых странах практически все проектные и инжиниринговые организации признают ценность и важность методик и подходов к организации управления проектами по этому стандарту. Существуют специальные курсы и сертификационные экзамены на знание PMBOK.
Инженер, владеющий сертификатом от PMI, является общепризнанным специалистом в области проектного управления. Затраты на получение такого сертификата с лихвой окупаются высоким уровнем компетенций по управлению проектами, эффективными принятыми решениями, умелой организацией проектной деятельности в любой области бизнеса. Именно поэтому в управленческой среде ценится знание одного из стандартов по управлению проектами и особенно PMBOK.
Организации также стремятся в своей работе использовать лучшие практики по управлению проектами – это в перспективе повышает их конкурентоспособность, эффективность деятельности.
Но в области архитектурно-строительного проектирования, особенно в отечественных организациях, проблемы управления проектами имеют особенности, главным образом связанные с опытом планирования в предыдущих экономических условиях: сначала плановой экономики, потом переходного периода. Многие крупные проектные организации имеют в России более чем полувековую историю. Их процессы управления опираются на опыт возрастного поколения специалистов. Как правило, в каждой крупной организации существовал свой вычислительный центр, и основной его работой было обслуживание календарно-сетевого планирования. А при имеющейся тогда ситуации плановой загрузки деятельность многих предприятий была практически идентичной деятельности завода по производству документации.
Главной была задача эффективной загрузки ресурсов. Развитие глобальной экономики привело к тому, что эффективность работы таких крупных проектных организаций снизилась до неприемлемого уровня из-за катастрофически низкой скорости реагирования на изменяющиеся потребности рынка.
Другая проблема таких крупных организаций – свои уникальные процессы прохождения документации. Попытка автоматизации этих процессов приводит к тому, что в организациях создаются свои группы программистов разной степени квалификации. Получаемые решения, как правило, удовлетворяют потребности проектных организаций, но лишь до поры до времени.
Меняются технологии САПР, приходят технологии BIM, программисты вынуждены постоянно доделывать программные комплексы. Такие системы держатся на одном-двух ведущих программистах и со временем «морально» устаревают. Обращаем внимание, что сейчас мы не рассматриваем ситуацию, когда над созданием уникальной системы работают системные интеграторы (компании с многолетней историей и опытом)
Еще одна проблема уникальных систем – трудность обмена данными с другими организациями. Разные схемы организации хранения данных приводят к тому, что при передаче данных задействуются дополнительные ресурсы и тратится время на преобразования данных, объяснение или документирование способов обмена данными, оформление различных «одноразовых» регламентов обмена данными.
В целом анализ подхода крупных проектных организаций к управлению проектированием позволяет сделать вывод, что для поддержки процессов управления проектированием требуются высокие накладные расходы
Рассмотрим организации другого масштаба – проектные бюро малых и средних размеров (до 40 рабочих мест). Экономические реалии и наблюдаемый тренд говорят нам, что будущее именно за такими предприятиями – быстро и эффективно осваивающими все новые и новые технологии как в управлении, так и в проектировании.
Такие организации обычно не используют дорогие решения уровня Primavera или SAP. Они ищут бюджетные аналоги, но в любом случае им приходится подстраивать найденные решения под отечественные нормы.
К тому же такие организации образуются как раз вследствие того, что крупные проектные организации становятся малоэффективными. Инициативные, молодые проектировщики не видят перспектив получения дополнительных доходов при традиционных методах ведения проектного дела, и… создают новые организации, свободные от устаревших методов.
В таких новых организациях руководители изначально ориентированы на проектный подход, как раз описываемый в PMBOK. Они стараются изучать и применять современные методы управления проектной деятельности. Такие прогрессивные руководители организаций не готовы и не хотят тратить время (причем значительное) на какие-либо доработки уникальных программ, не связанных с получением прибыли по основной деятельности.
В описанной ситуации отраслевые решения для управления проектами, реализующие принципы PMBOK и учитывающие современные российские требования к документации и к проектам будут востребованы на рынке систем управления проектами. Особенно если они имеют привлекательную цену.
Создание программы TDMS Фарватер
В настоящее время многие российские организации широко используют отечественную платформу TDMS в качестве системы электронного документооборота.
TDMS является объектно-ориентированной средой хранения информации о данных, о процессах.
Это позволяет применять систему TDMS практически в любой предметной области после так называемой настройки. Настройка – это описание на языке TDMS объектов предметной области, статусов этих объектов и правил, на основании которых объекты могут изменять свои статусы. В данную концепцию включается также управление правами доступа, ролями пользователей, бизнес-ролями в организации. В комплексе получается некоторая, так называемая, Конфигурация. Конфигурация TDMS – программная надстройка на платформе TDMS, которая разрабатывается для конкретного предприятия, максимально широко охватывает существующие бизнес-процессы этого предприятия. Поэтому для разработки Конфигурации нужно привлекають опытных специалистов: постановщики задач, системные архитекторы, аналитики, программисты.
В процессе работ по разнообразным техническим заданиям возникла идея взять общие требования, которые предъявлялись к системе TDMS крупными проектными организациями, и объединить их в некое стандартное решение.
В процессе работы над разными конфигурациями наши специалисты опирались на методологию PMBOK, общеизвестный свод правил и лучших практик по управлению проектами. Возникла плодотворная идея: создавать конфигурацию TDMS изначально в соответствии с принципами PMBOK. В этом случае программное решение будет соответствовать уже описанным, принятым в среде профессионалов управления проектами, процессам.
Главное, что требовалось при разработке программы TDMS Фарватер – соответствие российским нормам и правилам. За основу был взят стандарт ГОСТ Р 21.1101-2013 «Основные требования к проектной и рабочей документации» и Постановление № 87 «О составе разделов проектной документации и требованиях к их содержанию».
Как работает TDMS Фарватер
TDMS Фарватер – это конфигурация TDMS, настроенная на поддержку самых востребованных процессов создания проектной документации для стадий проектирования П и Р.
Основой системы являются информационные объекты: Документ, Задание, Часть проекта, Том, Входящий документ, Приказ и многие другие.
У каждого информационного объекта есть свойства (атрибуты), и действия. Одно из свойств – статус информационного объекта. Именно статус определяет права доступа разных сотрудников к объекту, а также список возможных действий с объектом. У некоторых информационных объектов имеются возможность создавать и хранить версии этих объектов. Например, документ, содержащий альбом ООС «Охрана окружающей среды» на выдачу, может иметь активную версию 24. Но у вас есть возможность посмотреть, или даже сделать активной, любую из предыдущих версий. В ряде случаев: работа над замечаниями, внесение изменений, различные споры с заказчиками и подрядчиками, — это очень нужная функция.
Возможно, вы заметите, что так работает и большинство других систем управления данными. Это, действительно, так. Но у TDMS Фарватер есть существенное отличие.
В эту систему управления проектированием дополнительно заложены шаблоны типовых действий, названия частей, структуры проекта, которые необходимы российским проектировщикам – именно это выгодно выделяет TDMS Фарватер на фоне других программ. Вместе с TDMS Фарватер проектировщики получают также и рекомендации (методики) разработки документации, выполнения типовых задач, поддержки самых нужных процессов.
В TDMS Фарватер выделяются три подсистемы:
1. Организационно-распорядительный документооборот (ОРД);
2. Технический документооборот;
3. Электронный архив.
Модуль ОРД поддерживает, как и в других подобных системах, основные процессы по созданию, учету и хранению следующих видов документов:
• Приказы, Распоряжения;
• Входящие документы;
• Исходящие документы;
• Служебные и докладные записки;
• Договоры.
Модуль технического документооборота управляет такими типами документов:
• Проектный документ;
• Задание на выполнение различных действий по проектированию;
• Протокол технического совещания;
• Разрешение на внесение изменений;
• Проект, часть проекта;
• Накладная.
Электронный архив накапливает все документы, созданные в модуле технического документооборота, а также все документы, которые организация хочет сохранить в электронном архиве на будущее. Например, отсканированные старые бумажные архивы, или архивы в электронном виде, накопленные в предыдущие годы и располагающиеся на различных файловых серверах, или, в наихудшем случае, на компакт-дисках.
Для обеспечения работы всех проектировщиков и сотрудников организации с нужными объектами в TMDS Фарватер сделана подсистема работы со штатным расписанием.
Ответственные за управление персоналом могут учитывать все должности, перемещения, замещения, табели каждого сотрудника.
Еще одна особенность системы TMDS Фарватер – интеграция с AutoCAD, nanoCAD, КОМПАС, et cetera. В системе TMDS Фарватер есть команды для использования механизма внешних ссылок, чтобы было удобно передавать задания между смежниками, и чтобы все проектировщики могли использовать в работе только актуальные версии документов, чертежей, подложек. Есть также дополнительные модули к TMDS – так называемые интерфейсы: Addins для AutoCAD и nanoCAD, делающие работу с внешними ссылками более удобной.
Работа с файлами-чертежами построена следующим образом. Чертежи хранятся в информационных объектах – проектных документах, как в контейнерах. Если документ находится в статусе, допускающем редактирование, и права пользователя разрешают редактировать документы, то чертеж из базы данных копируется по локальной сети с сервера баз данных (или из файлового сервера) на компьютер пользователя.
Документ в базе данных блокируется для остальных. С этого момента чертеж открывается на редактирование в необходимой программе.
После внесения изменений и сохранения файла на локальном компьютере пользователь сохраняет изменения в базе данных. Информационный объект в этот момент освобождается (check-out) и с ним могут работать все остальные согласно процессам и правам доступа. Надо понимать также, что пока объект заблокирован, все остальные все равно могут читать файлы заблокированного документа, например, когда используют эти файлы в качестве внешних ссылок.
Информационные объекты – документы, как уже сказано выше, являются контейнерами для файлов любых типов. Не только чертежей, но и графических файлов, фотографий, текстовых документов WORD, таблиц EXCEL, и т. п. После того, как файл извлечен из базы данных на компьютер пользователя (эта операция также известна под названиями «check-in / check-out», «извлечение / возврат») он открывается на редактирование в нужной программе. Такой механизм позволяет хранить в контейнерах-документах файлы любых типов. DWG и DOC для разработки документации, XLS – для проведения расчетов, PDF – для формирования томов выпуска документации, файлы расчетных схем, сметные исходные данные и т. п.
Можно попытаться воспринимать структуру проекта по-другому: как систему файлового хранилища с «умными» папками. Роль папок играют документы-контейнеры, каждый со своими атрибутами. Возможно, такая интерпретация механизма работы TDMS Фарватер поможет быстрее понять суть работы системы и принять решение о внедрении системы в организации.
В заключение давайте рассмотрим несколько важных для проектировщиков процессов, для которых можно использовать программу управления процессами проектирования TDMS Фарватер.
Примеры процессов
Процесс подготовки проектной документации
Это один из основных процессов, ради которых и создавался TDMS Фарватер. Для проектирования объектов капитального строительства непроизводственного назначения в поставку TDMS Фарватер включена технологическая схема разработки документации. На рисунке приведен фрагмент этой схемы, включающей свыше ста отдельных элементов.
Общий процесс работы выглядит следующим образом.
Формат обзорной статьи не позволяет углубленно рассмотреть разнообразные методы разработки документов, последовательность выдачи заданий для эффективной разработки проекта, процессы нормоконтроля документации. Более подробно эти процессы будет рассматриваться в последующих статьях о TDMS Фарватер и на вебинарах о продукте.
Сейчас мы рассмотрим несколько сценариев применения системы TDMS Фарватер в организациях.
Ведение переписки с заказчиками
Существуют организации, не занимающиеся непосредственно разработкой документации, но активно ее использующие. Они специализируются, например, на услугах в проектно-строительной отрасли: технический заказчик, авторский надзор, инжиниринговая деятельность и т.п.
В таких организациях необходимо, как правило, активно общаться с различными заказчиками и подрядчиками. TDMS Фарватер можно использовать для обработки данных по контрагентам и для обработки и хранения входящей и исходящей корреспонденции и договоров.
Работу с входящей и исходящей корреспонденцией поддерживают практически все системы документооборота, от бесплатных до дорогих. Но TDMS Фарватер выгодно отличает то обстоятельство, что в нем можно удобно хранить еще и проектно-конструкторскую, рабочую документацию, и очень легко можно связывать проект, и переписку по нему.
Рассмотрим, как можно использовать TDMS Фарватер в таких организациях для работы с корреспонденцией.
Перенос документации в электронный архив
Рассмотрим теперь организации, которые не разрабатывают все комплекты документации, а используют документацию, накопленную за много лет, в своей текущей работе. Это могут быть проектные бюро при заводах, технические кабинеты в больших компаниях, организации, обслуживающие объекты недвижимости. Такие организации также могут применять TDMS Фарватер для организации электронного архива и переноса накопленных документов из структурированных файловых хранилищ в электронный архив.
Типичные действия в этом случае такие:
1. Подготовка архива документов к переносу в архив:
a. Упорядочивание по разделам проекта.
b. Очистка от временных файлов, определение минимально необходимого состава по файлам, по типам файлов.
c. Принятие решения, хранить ли DWG и PDF в одном или в разных документах.
d. Для бумажных архивов принятие решения сохранять все листы раздела в один многостраничные PDF или TIFF, или же использовать отдельные PDF для каждого листа.
2. Подготовка TDMS Фарватер:
a. Определение специалистов, занимающихся формированием электронного архива, включение их в рабочую группу ГИПов и Архивистов.
b. Создание шаблона проекта, включающего наибольшее количество частей, книг. Это поможет легко создавать новые проекты и удалять ненужные подразделы части и книги.
c. Создание шаблона задания от ГИПа на формирование архива – «Задание А».
3. Создание для каждого проекта карточки с атрибутами: Заказчик, Шифр, Наименование, состав проекта:
a. В одной из частей проекта создать «задание А» самому себе и перевести объект в работу.
b. В каждом разделе (подразделе, части, книге, комплекте) создать документ с нужным шифром и перенести в него файлы из старого файлового хранилища. Количество документов зависит от решений, принятых на первом шаге процесса.
4. Закрыть «Задание А», принять работу, и выполнить команду переноса в архив.
5. Повторить пункты 3 и 4 пока не будут занесены все старые проекты в архив.
Заключение
Мы будем продолжать рассказывать о возможностях TDMS Фарватер для решения практических задач российских проектировщиков. В частности, все более четкими становятся требования по передаче документации в электронном виде на экспертизу, вырисовываются контуры стандартных подходов к технологиям информационного моделирования в России. Такие и подобные темы ставят перед нами, как разработчиками, очень интересные и сложные задачи. Будем решать их и развиваться вместе.
Дмитрий Маслов, руководитель проектов комплексной автоматизации ООО «Магма-Компьютер»