что такое mdr в проектировании
master document register
Смотреть что такое «master document register» в других словарях:
Master of the Revels — The Master of the Revels was a position within the English, and later the British, royal household heading the Revels Office or Office of the Revels that originally had responsibilities for overseeing royal festivities, known as revels, and later … Wikipedia
Stationers’ Register — The Stationers Register was a record book maintained by the Stationers Company of London. The company is a trade guild given a royal charter in 1557 to regulate the various professions associated with the publishing industry, including printers,… … Wikipedia
National Register of Historic Places — This article is about the U.S. Register. For the National Register of Historic Places in Canada, see Canadian Register of Historic Places. Old Slater Mill, a historic district in Pawtucket, Rhode Island, was the first property listed in the… … Wikipedia
Naval Vessel Register — The Naval Vessel Register (NVR) is the official inventory of ships and service craft in custody of or titled by the United States Navy. It contains information on ships and service craft that make up the official inventory of the Navy from the… … Wikipedia
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
National identification number — A national identification number, national identity number, or national insurance number is used by the governments of many countries as a means of tracking their citizens, permanent residents, and temporary residents for the purposes of work,… … Wikipedia
United States — a republic in the N Western Hemisphere comprising 48 conterminous states, the District of Columbia, and Alaska in North America, and Hawaii in the N Pacific. 267,954,767; conterminous United States, 3,022,387 sq. mi. (7,827,982 sq. km); with… … Universalium
Business and Industry Review — ▪ 1999 Introduction Overview Annual Average Rates of Growth of Manufacturing Output, 1980 97, Table Pattern of Output, 1994 97, Table Index Numbers of Production, Employment, and Productivity in Manufacturing Industries, Table (For Annual… … Universalium
Notary public — An embossed foil Notary Seal from the State of New York. A notary public (or notary or public notary) in the common law world is a public officer constituted by law to serve the public in non contentious matters usually concerned with estates,… … Wikipedia
china — /chuy neuh/, n. 1. a translucent ceramic material, biscuit fired at a high temperature, its glaze fired at a low temperature. 2. any porcelain ware. 3. plates, cups, saucers, etc., collectively. 4. figurines made of porcelain or ceramic material … Universalium
Управление информацией объектов капитального строительства
Настоящий обзор основан на практике применения 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(АСУТП) тэги
Теги связанные с оборудованием – что-то, называемое «твердыми» тэгами.
Информация объекта капитального строительства включает в себя данные и документы, необходимые для эксплуатации и обслуживания этого объекта, включая, но не ограничиваясь следующими:
Планы проекта и процедуры
Результаты проектирования, включая те, что поставляются Поставщиками/Производителями
Master Deliverable Register (MDR): Following up project documents
MDR is probably one of the first acronyms we hear about, when starting a career in Document Control, and more specifically when working in a project environment.
The MDR acronym stands for “Master Document Register” or, to avoid any confusion with other registers, “Master Deliverable Register”.
The MDR is a list of all documentation deliverables
The MDR is basically a list of all the documentation deliverables for a specific project, with additional information on each of these documents, for example:
The MDR is usually an Excel Spreadsheet
It is usually an Excel spreadsheet as this widely-spread format makes it easy to share information between companies, and it also allows to easily sort, filter, highlight, process the data included in the MDR, both from the Contractor side and the Client Side.
The MDR is a communication document between Contractor(s) and Client
Though the MDR template might be that of the Client, the MDR itself is usually a document owned by the Contractor’s Document Controller.
He/she is usually in charge of updating the MDR and of regularly sending it to the Client: usually on a weekly basis, sometimes (more rarely) on a monthly basis.
In that sense, the MDR can be considered as a communication document between the Contractor(s) and the Client, about the status of project deliverables: here is the list of documents we intend to deliver to you over the course of the project, with an indication on the progress for each one of them.
Upon receipt, it is also the opportunity for the Client’s Document Controller to check the information, and to cross-check whether what is indicated by the Contractor as “issued” as actually been “received” by the Client.
Example of a Master Document Register (MDR)
The MDR helps following up on the progress of the project
The MDR is an essential tool both for the Document Control team and for the Project Management and Project Controls/Services team in general to follow up on the progress of the project and to identify any potential problems as early as possible.
The data from the MDR can be used to identify late documents from the Contractor, late comments from the Clients, lost documents, potential delays with deliverables, and therefore the impact on the project schedule and overall any documentation-related problem for the project.
It is also a document that is used during project progress meetings (both internal and Client/Contractor meetings) to follow up actions on documents and to ensure their progress.
It is one of the key documents on a project, and although it is maintained by Document Controllers, it contains information useful to many other disciplines.
This is why it is also in general a good practice to agree from the beginning of the project on the template, format and periodicity of issuance of this critical document.
Что такое «система управления мастер-данными» и зачем она нужна
Какие бывают данные
Прежде чем перейти непосредственно к системам управления мастер-данными, давайте определим, какого рода вообще бывают данные.
Ниже представлены 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 в проектировании
ГОСТ Р МЭК 61160-2006
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФОРМАЛЬНЫЙ АНАЛИЗ ПРОЕКТА
Risk management. Formal design review
Дата введения 2007-01-01
Сведения о стандарте
1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (ОАО «НИЦ КД») и Техническим комитетом по стандартизации ТК 10 «Перспективные производственные технологии, менеджмент и оценка рисков» на основе собственного аутентичного перевода стандарта, указанного в пункте 4
2 ВНЕСЕН Управлением развития, информационного обеспечения и аккредитации Федерального агентства по техническому регулированию и метрологии
4 Настоящий стандарт идентичен международному стандарту МЭК 61160:1992 «Формальный анализ проекта» (IEC 61160:1992 «Formal design review»).
В стандарт введены технические изменения 1, подготовленные техническим комитетом МЭК ТК 56 «Надежность», которые выделены двойной вертикальной линией, расположенной слева от соответствующего текста.
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (подраздел 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении А
Введение
Целью проведения анализа проекта на этапе опытно-конструкторских работ является обеспечение соответствия продукции или услуг требованиям по: безотказности, безопасности, долговечности, условиям эксплуатации, электромагнитной совместимости и быстродействию при минимальной стоимости и поставке в установленные сроки.
Анализ проекта улучшает разработку продукции или процессов путем сокращения стоимости, улучшения качества, быстродействия и повышения безопасности, совершенствования графика поставки. Анализ могут применять и поставщик, и потребитель.
Анализ проекта, независимо от частоты или глубины его проведения, не может заменить этапы определения параметров высококачественной продукции, разработки технических требований проекта, проектирования и разработки. Используемый как процесс контроля, анализ проекта может обеспечить необходимую верификацию успешного завершения работ по проектированию в установленный срок.
Не описанные в стандарте процедуры, например порядок выполнения плана мероприятий или оформление отчета о результатах анализа, предприятие разрабатывает и вводит самостоятельно.
Требования, приведенные в таблицах 3 и 4, могут быть дополнены в соответствии со спецификой предприятия.
1 Область применения
Настоящий стандарт содержит рекомендации по выполнению процедур анализа проекта в качестве средства стимулирования совершенствования продукции и процессов. Настоящий стандарт устанавливает руководство по планированию и проведению анализа проекта и дает детальное описание участия в анализе специалистов по надежности, техническому обслуживанию, ремонту и обеспечению работоспособности. Стандарт также включает положения об участии в анализе специалистов в других предметных областях, таких как качество, окружающая среда, безопасность, человеческий фактор и правовые вопросы.
В дополнение к обычному пониманию «продукции» целесообразно включить в это понятие также аппаратные средства, программное обеспечение ЭВМ; каталоги, технические требования к продукции, транспортной упаковке, установке и сборке; инструкции и руководства по эксплуатации, ярлыки и предупреждающие надписи; техническое обслуживание, перечень запасных частей, гарантийные обязательства, коммерческие брошюры и рекламную литературу.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
МЭК 60050-191:1990 Международный электротехнический словарь. Глава 191. Надежность и качество обслуживания
МЭК 60721-2-1:2002 Классификация внешних воздействующих факторов. Часть 2-1: Природные внешние воздействующие факторы. Температура и влажность
МЭК 60721-2-2:1988 Классификация внешних воздействующих факторов. Часть 2: Природные внешние воздействующие факторы. Осадки и ветер
МЭК 60721-2-3:1987 Классификация внешних воздействующих факторов. Часть 2: Природные внешние воздействующие факторы. Давление воздуха
МЭК 60721-2-4:2002 Классификация внешних воздействующих факторов. Часть 2-4: Природные внешние воздействующие факторы. Солнечное излучение и температура
МЭК 60721-2-5:1991 Классификация внешних воздействующих факторов. Часть 2. Природные внешние воздействующие факторы. Раздел 5. Пыль, песок, солевой туман
МЭК 60721-2-7:1987 Классификация внешних воздействующих факторов. Часть 2: Природные внешние воздействующие факторы. Фауна и флора
МЭК 60721-2-8:1994 Классификация внешних воздействующих факторов. Часть 2: Природные внешние воздействующие факторы. Раздел 8: Воздействие огня
МЭК 60721-3-0:2002 Классификация внешних воздействующих факторов. Часть 3. Классификация групп параметров окружающей среды и их степеней жесткости. Введение
МЭК 60721-3-1:1997 Классификация внешних воздействующих факторов. Часть 3. Классификация групп параметров окружающей среды и их степеней жесткости. Раздел 1. Хранение
МЭК 60721-3-2:1997 Классификация внешних воздействующих факторов. Часть 3. Классификация групп параметров окружающей среды и их степеней жесткости. Раздел 2. Транспортирование
МЭК 60721-3-3:1994 Классификация внешних воздействующих факторов. Часть 3. Классификация групп параметров окружающей среды и их степеней жесткости. Раздел 3. Эксплуатация в стационарных условиях в местах, защищенных от непогоды
МЭК 60721-3-4:1995 Классификация внешних воздействующих факторов. Часть 3. Классификация групп параметров окружающей среды и их степеней жесткости. Раздел 4. Эксплуатация в стационарных условиях в местах, не защищенных от непогоды
МЭК 60721-3-5:1997 Классификация внешних воздействующих факторов. Часть 3. Классификация групп параметров окружающей среды и их степеней жесткости. Раздел 5. Размещение на наземных транспортных средствах
МЭК 60721-3-6:1987 Классификация внешних воздействующих факторов. Часть 3: Классификация групп параметров окружающей среды и их степеней жесткости. Воздействующие факторы на судах
МЭК 60721-3-7:2002 Классификация внешних воздействующих факторов. Часть 3-7. Классификация групп параметров окружающей среды и их степеней жесткости. Переносной и нестационарный режим эксплуатации
МЭК 60721-3-9:1993 Классификация внешних воздействующих факторов. Часть 3. Классификация групп параметров окружающей среды и их степеней жесткости. Раздел 9. Микроклиматы внутри изделий.
3 Термины и определения
В настоящем стандарте применены термины по МЭК 60050-191, а также следующие термины с соответствующими определениями:
3.1 формальный анализ проекта (formal design review): Формальная и независимая экспертиза существующего или предлагаемого проекта для обнаружения и исправления недостатков проекта и требований к показателям безотказности, безопасности, долговечности и ремонтопригодности, средствам технического обслуживания и направленная на выявление потенциальных возможностей для улучшения.
3.2 пункт плана мероприятий (action item): Вопрос, который должен быть решен до завершения анализа проекта.
3.3 рекомендация (recommendation): Предложение по изменению продукции, процесса или графика работ, которое должно быть выполнено или формально отклонено до завершения анализа проекта. Проект может касаться продукции, процесса или процедуры.
4 Применение формального анализа проекта
Организация должна принять всестороннюю программу анализа проекта в соответствии с настоящим стандартом или разработать сокращенную программу, отвечающую потребностям организации.
Анализ проекта должен быть включен в действующие процедуры и программы по обеспечению безопасности продукции, электромагнитной совместимости, качества и надежности.
На процессы анализа влияют размеры и ресурсы организации, особенности проекта, доходы от продукции, риски и сложность продукции. В небольших организациях целесообразно привлекать к работе персонал поставщиков, консультантов и других внешних специалистов.
5 Менеджмент процесса
Организация (объединение, организация, подразделение и т.п.) должна разработать политику анализа проекта, регламентирующую выполнение, которую утверждает уполномоченное лицо организации.
Политика анализа проекта должна соответствовать следующим требованиям:
— анализ проекта должен проводиться по всей новой продукции, процессам и их применению, а также при внесении изменений в существующую продукцию и производственные процессы, затрагивающие показатели функционирования, физические характеристики, показатели безопасности, надежности, электромагнитной совместимости, стоимости или другие характеристики, влияющие на продукцию или процесс, пользователей, взаимодействующие стороны или население в целом;
— анализ проекта должен проводиться (через соответствующие интервалы времени) для рассмотрения изменений в технологии, которые могут затронуть перечисленные выше характеристики.
Руководитель группы анализа проекта должен нести ответственность за разработку и выполнение политики анализа проекта, необходимых процедур и методов в соответствии с требованиями настоящего стандарта.
Процедуры анализа проекта не должны диктовать разработчикам окончательный вариант проекта через управление деталями выполнения работ. Ежедневно принимаемые решения должны опираться на анализ продукции или процессов. Если бы каждое решение было подвергнуто независимому анализу, группа анализа, в сущности, проектировала бы продукцию, что требует слишком много времени. Наоборот, если бы первоначальный анализ проекта выполнялся только перед началом производства, выгода от анализа была бы сомнительна. Непосредственно перед началом производства не должны выполняться никакие корректирующие действия за исключением остановки проекта из-за какой-либо критической проблемы, имеющей потенциально катастрофические последствия.
6 Анализ проекта на стадиях жизненного цикла
Настоящий стандарт устанавливает подход, при котором соответствующий тип анализа проекта должен проводиться перед принятием любых серьезных решений.
Для достижения поставленных целей анализ проекта должен проводиться в точках принятия решений или контрольных точках на стадиях жизненного цикла продукции. Различные типы анализа представлены в таблице 1.