1 ПОДГОТОВЛЕН Автономной некоммерческой организацией "Международная академия менеджмента и качества бизнеса" (АНО "Международная академия качества бизнеса") на основе собственного перевода на русский язык немецкоязычной версии стандарта, указанного в пункте 4, совместно с Закрытым акционерным обществом "Проектная ПРАКТИКА" (ЗАО "Проектная ПРАКТИКА") при участии Открытого акционерного общества "Научно-исследовательский центр контроля и диагностики технических систем" (АО "НИЦ КД")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 17 ноября 2015 г. N 1827-ст

4 Настоящий стандарт идентичен стандарту DIN 69901-4:2009 "Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных" ("Project management - Project management systems - Part 4: Data, data model", IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации и межгосударственный стандарт, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

Настоящий стандарт разработан рабочим комитетом NA 147-00-04 AA "Техника сетевого планирования и проектный менеджмент" NA 147 (NQSZ).

Комплекс национальных стандартов DIN 69901 имеет общий заголовок "Проектный менеджмент - Системы проектного менеджмента" и состоит из следующих частей:

- Часть 1: Основные положения;

- Часть 2: Процессы и процессная модель;

- Часть 3: Методы;

- Часть 4: Данные и модель данных;

- Часть 5: Термины и определения.

Разработанные на основе техники сетевого планирования и неоднократно переизданные национальные стандарты по проектному менеджменту DIN 69901, DIN 69902, DIN 69903, DIN 69904 и 69905 прошли этапы обобщения, реструктуризации и обновления в соответствии с актуальными условиями и существенными деталями и нашли свое отражение в частях комплекса стандартов DIN 69901. Ядром новой системы стандартов является процессная модель системы проектного менеджмента. Комплекс стандартов по проектному менеджменту содержит терминологию из различных стандартов в данной области и устанавливает соответствующую модель данных. Рисунок 1 показывает взаимосвязи между отдельными частями комплекса стандартов DIN 69901.

Настоящий стандарт представлен в форме, удобной для пользования всеми заинтересованными сторонами на международном, региональном, национальном или муниципальном уровнях. Настоящий стандарт предназначен для использования вместе с национальными, международными стандартами или руководствами, касающимися деятельности организации в области проектного менеджмента, или в процессе их подготовки.

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

Информация, представленная в настоящем стандарте, предназначена исключительно для ознакомления пользователей с другими альтернативными процессами в области проектного менеджмента. Настоящий стандарт может использоваться в качестве дополнения к основополагающим национальным стандартам в области проектного менеджмента <*> и не предназначен для целей сертификации.

--------------------------------

<*> К основополагающим национальным стандартам Российской Федерации в области проектного менеджмента относятся ГОСТ Р ИСО 21500-2014 "Руководство по проектному менеджменту"; ГОСТ Р 54869-2011 "Проектный менеджмент. Требования к управлению проектом"; ГОСТ Р 54871-2011 "Проектный менеджмент. Требования к управлению программой"; ГОСТ Р 54870-2011 "Проектный менеджмент. Требования к управлению портфелем проектов".

Настоящий стандарт устанавливает модель данных программного обеспечения, применяемого в области проектного менеджмента и может использоваться совместно с DIN 69901-1, DIN 69901-2, DIN 69901-3 и DIN 69901-5:

a) разработчиками программного обеспечения в области проектного менеджмента;

b) разработчиками программного обеспечения, применяемого для обмена данными с другими системами в области проектного менеджмента;

c) организациями, которые хотят внедрить, поддерживать и улучшить свое программное обеспечение в области проектного менеджмента;

d) всеми лицами, в составе организации и/или вне ее, кто проводит консультации в отношении выбора подходящего программного обеспечения для системы проектного менеджмента.

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

DIN 69900 Project management. Project network techniques. Descriptions and concepts (Проектный менеджмент. Техника сетевого планирования. Термины и определения)

DIN 69901-1 Project management. Project management systems. Part 1. Fundamentals (Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения)

DIN 69901-2 Project management. Project management systems. Part 2. Processes, process model (Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель)

DIN 69901-3 Project management. Project management systems. Part 3. Methods (Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы)

DIN 69901-5 Project management. Project management systems. Part 5. Concepts (Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения)

ISO 9000-2005 Quality management systems. Fundamentals and vocabulary (Системы менеджмента качества. Основные положения и словарь)

ISO/IEC 19501:2005 Information technology. Open Distributed Processing. Unified Modeling Language (UML) Version 1.4.2 [Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2]

В настоящем стандарте использованы термины по DIN 69900 и DIN 69901-5, в том числе следующие термины с соответствующими определениями:

3.1 многоязычный (Multi Language, ML): Текстовый атрибут, для которого в XML-представлении должна существовать возможность ввода значений на нескольких языках.

3.2 глобальный уникальный идентификатор (Global Unique Identifier, GUID): Информационный объект, который можно однозначно идентифицировать с помощью кода.

Примечание - При этом код является однозначным не только для всех объектов одного типа, но и для всех объектов всех типов.

3.3 первичная ассоциация (Primary Association, PA): Ассоциация, которая используется в процессе генерации схемы для построения иерархической структуры XML-элементов.

3.4 совокупное значение (Aggregated Value, AGG): Атрибут, который применяется в структуре проекта.

Примечание - Его значение либо абсолютно точно ссылается на структурный элемент, либо включает в себя в качестве агрегированного значения все значения подчиненных структурных элементов.

Представленная в настоящем стандарте модель данных описывает на профессиональном уровне элементарные структуры данных проектного менеджмента. Модель данных можно использовать для:

a) архивирования данных проектного менеджмента;

b) обмена данными проектного менеджмента между организациями и различными системами программного обеспечения;

c) спецификации требований к программному обеспечению проектного менеджмента (в качестве исходных данных).

Представление модели данных осуществляется вербально и дополняется диаграммами (немецкие соответствия английских текстов см. в таблицах А.1 - А.12). Названия элементов и их описание находятся в таблицах 1 - 12. Диаграммы соответствуют положениям ИСО/МЭК 19501 "Унифицированный язык моделирования (UML)". Они представляют собой базовые элементы данных (классы) и выражают их с помощью соответствующих подэлементов (атрибутов), которые сами не являются объектами стандартизации. Специфичные для отрасли, предприятия или проекта расширения возможны путем добавления других классов и/или атрибутов.

Из 13 типов UML диаграмм (см. рисунки 2 - 13) для создания модели данных используются только диаграммы классов. К применяемым языковым конструкциям относятся пакеты, классы, атрибуты, ассоциации, специализации и параметры. Все конструкции используются в соответствии со стандартом. Тем не менее используются некоторые специфичные параметры:

- ML (англ.: Multi Language).

Этот параметр характеризует текстовые атрибуты, для которых в XML-представлении должно быть разрешено занесение в память значений на нескольких языках. Так, например, станет возможным указывать имя проекта более чем на одном языке;

- GUID (англ.: Global Unique Identifier).

Этот параметр характеризует классы, которые представляют собой специализации класса GUID-Object. Класс GUID описывает информационный объект, который можно однозначно идентифицировать с помощью кода.

Примечание - При этом код является однозначным не только для всех объектов одного типа, но и для всех объектов всех типов;

- PA (англ.: Primary Association).

Этот параметр используется для обозначения ассоциаций, которые в рамках генерации схемы используются для построения иерархической структуры XML-элементов;

- AGG (англ.: Aggregated Value).

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

Элементам данных присваиваются английские и русские названия. Однозначные согласованные названия приведены ниже.

Элементы данных называются существительными и всегда используются в единственном числе. Элементы данных могут называться также двумя существительными, при этом, если возможно, для определения иерархии понятий используется позиция (порядок следования) существительного. Так, существует, например, иерархическое отношение между элементами данных Initiative (объект управления) и InitiativeGroup (группа объектов управления). Это отношение можно определить только по одному названию элементов. Для лучшего понимания присвоение имени из нескольких существительных происходит с использованием дефисов.

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

В модели данных с различной степенью детализации представлены результаты моделирования единиц исполнения задания с помощью элемента Initiative (объект управления). Для построения структурного плана проекта объекты могут располагаться в виде иерархии. Кроме того, иерархия предназначена для распределения проектов по программам и портфелям проектов.

Благодаря распределению объектов по типам объектов можно определить, о каких единицах исполнения задания идет речь. Так, например, могут различаться программы, проекты, пакеты работ и процессы.

Элемент InitiativeStatusType (тип статуса объекта) выражает, в каком состоянии или статусе находится объект. Для отдельных типов объектов могут быть определены различные типы статуса объекта. Если переход между состояниями (например, смена фаз проекта) требует определенного разрешения, то это устанавливается типом элемента InitiativeStatusApproval (одобрение статуса объекта). Он представляет собой специализацию элемента GenericApproval (одобрение общее). Одобрение может сопровождаться соответствующими документами [элемент Document (документ)].

Элемент InitiativeGroup (группа объектов управления) предназначен для объединения объектов в специальные группы. При этом следует учитывать, что каждая группа может охватывать несколько объектов. И наоборот, каждый объект может охватывать (принадлежать) нескольким группам.

В модели данных результат проекта может храниться в форме структуры продукта. Структура продукта состоит из элементов продукта (ProductElement), которые могут быть организованы в виде иерархии с помощью подэлементов (SubElement). Дополнительно могут учитываться зависимости между элементами продукта. У каждого элемента продукта могут быть различные версии элемента продукта (ProductElementVersion). Как для элементов продукта, так и для версии элемента продукта назначаются ответственные сотрудники (Staff).

По каждому объекту может регистрироваться любое количество запросов на изменение (ChangeRequest), между ними могут иметься зависимости. Запросы на изменение могут касаться элементов продукта или версии элемента продукта. Одновременно они соотносятся с одним объектом (Initiative), как правило, проектом. Если запрос на изменение рассматривается как единица исполнения задачи (например, если проводится соответствующий учет затрат), то может быть прикреплен соответствующий объект.

В модели данных сохраняются основные данные выполнения заказа. Элемент InitiativeContractData (данные договора объекта) предназначен для сохранения важнейших данных по коммерческим предложениям, заказам и счетам соответствующего Initiative (объекта управления). Кроме того, может учитываться соответствующая информация о счетах [элемент InitiativeInvoice (счет объекта)]. К счету, в свою очередь, могут прикрепляться отдельные TransactionItem (позиции бухгалтерской проводки), которые вытекают из счета.

Для каждого объекта заказчик и подрядчик устанавливают соответствие с конкретным Resource (ресурсом), т.е. могут быть определены ресурсы, которые рассматриваются в качестве заказчика или подрядчика.

Построение сети процессов представляется в модели данных с помощью элемента Initiative (объект) и указания предшествующих и последующих процессов. При этом элемент InitiativePrecedence (отношения взаимозависимости объекта) используется для того, чтобы более подробно специфицировать взаимозависимости (например, здесь можно ввести интервалы времени). Отношения взаимозависимостей объекта можно дополнить календарем, который содержит информацию о том, как следует интерпретировать возможные интервалы времени. Такой календарь можно определить для объекта управления, в этом случае он определяет, как следует рассчитывать продолжительность существования объекта в целом.

Связанные процессы представляются путем ссылки/ссылкой объекта управления (связанного процесса) на другие объекты управления. Они являются объектами, которые определяют другие связанные процессы и устанавливают их продолжительность.

Результат планирования сроков учитывается с помощью элемента InitiativeSchedulingData (данные сроков объекта). Кроме того, этот элемент содержит касающуюся объекта информацию по управлению процессом планирования сроков.

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

Каждый ресурс может быть отнесен к одному или нескольким ResourceType (типам ресурсов), которые объединяют ресурсы в массивы ресурсов одного вида. Типы ресурсов можно расположить в виде иерархии. В этом случае иерархия представляет собой конкретизацию критериев, по которым осуществляется группировка ресурсов.

Каждый ресурс может в зависимости от времени (сроков) привязываться к календарю (Calendar) [элемент ResourceCalendarAssignment (привязка ресурсов к календарю)]. Календарь состоит из нескольких календарных записей (CalendarEntry), которые относятся к типам CalendarEntryType (тип записи в календаре). С помощью типа записи в календаре определяется, как календарная запись должна интерпретироваться в части содержания.

Распределение ресурсов (взаимное соответствие задач и ресурсов) может осуществляться с помощью элементов ResourceAssignmentProfile (профиль распределения ресурсов). Они определяют, как запланированные расходы должны быть распределены по ходу реализации проекта. Каждый ресурс проекта может быть связан с конкретным профилем. Профиль распределения ресурсов состоит из множества элементов ResourceAssignmentProfileDiscreteValue (значения профиля распределения ресурсов).

Если в контексте ресурса речь идет о Staff (сотруднике), то происходит соответствующее распределение.

Ресурсы используются также для указания организационных единиц. Организационная структура может реализовываться элементом OrganisationSubUnit (организационная подъединица). С его помощью строится иерархическая структура ресурсов.

Для целей отчетности нужны многократно агрегированные данные по использованию ресурсов. Они могут быть заложены с помощью элемента ResourceUsage (использование ресурсов).

Распределение ресурсов по Initiative (объектам управления) (сопоставление с конкретными объектами управления) происходит с помощью элемента InitiativeResourceAssignment (распределение ресурсов объекта). Данный элемент с одной стороны связан с элементом Initiative (объект управления), а с другой стороны - с элементом Resource (ресурс). Кроме того, распределение ресурсов объекта может ссылаться на элемент Account (счет), вследствие чего устанавливается связь со счетом, который используется для бухгалтерской проводки. При определенных условиях спецификация потребности в ресурсах может составляться без ссылки на конкретный ресурс. В таких случаях потребность в ресурсах определяется с помощью специальных свойств. Это возможно с помощью сопоставления с элементом ResourceType (тип ресурсов) и ClassificationCriteria (критерий классификации). Если речь идет о ресурсах (персонале), то с помощью элемента Role (роль) можно определить, какие задачи выполняются персоналом в контексте объекта управления и какие права пользователей им определены. В некоторых случаях распределение ресурсов объекта проходит в несколько этапов. Это происходит с помощью многократного соотнесения с элементом ResourceAssignmentStatusType (тип статуса распределения ресурса). Элемент ResourceAssignmentStatusApproval (одобрение статуса распределения ресурса) позволяет внести соответствующую информацию об одобрении. Он наследуется от родового элемента GenericApproval (одобрение общее).

Элемент InitiativeResourceAssignment (распределение ресурсов объекта) описывает только логическое распределение ресурсов по объектам. Количественное планирование распределения ресурсов возможно с помощью элемента InitiativeResourceAssignment Quantity (количественное распределение ресурсов объекта).

Фактическое использование ресурсов можно учитывать с помощью элемента Timesheet (табель учета времени). Табель учета времени в каждом случае ссылается на Resource (ресурс), информацию о котором он содержит. Кроме того, в зависимости от времени он может быть отнесен к различным типам статуса табеля учета времени (TimesheetStatusType), которые показывают, на каком этапе обработки он находится. Это, в частности, имеет значение, если табели учета времени проверяются и одобряются соответствующими службами. Далее соответствующая информация о получении одобрения может регистрироваться с помощью элемента TimesheetApproval (одобрение табеля учета времени). Он представляет собой специализацию элемента GenericApproval (одобрение общее).

Каждый табель учета времени имеет несколько элементов TimesheetEntry (позиций табеля учета времени), которые в каждом случае описывают касающееся определенного периода времени использование ресурсов объектом управления (Initiative). Если необходимо, классификация может происходить по одной или нескольким нормам затрат (CostRate), которые определяют, как позиции табеля учета времени следует оценивать в денежном выражении. Кроме того, с помощью установления CalendarEntryType (типов календарной записи) можно определить, как позицию табеля учета времени следует интерпретировать по содержанию. Если, например, отсутствие также определяется с помощью табеля учета времени, это может быть показано здесь. Классификация CostCenter (статьи затрат) управляет процессом расчета фактических издержек.

Элемент InitiativeEVAData (данные анализа стоимости завершения объекта управления) предназначен для сохранения результатов анализа затрат (стоимости), необходимых для завершения Initiative (объекта управления).

Элемент InitiativeStatusReport (отчет о состоянии объекта) содержит качественную информацию о состоянии объекта. Отчет может содержать специальную плановую версию (PlanVersion), т.е. состав плановых и фактических данных, и составляться одним или несколькими сотрудниками (Staff), которые распределяются соответствующим образом.

Элемент InitiativeStatusReportStatusType (тип статуса отчета о состоянии объекта) применяется для того, чтобы показать, в каком статусе обработки и одобрения находится отчет о состоянии объекта (элемент InitiativeStatusReport). С помощью элемента InitiativeStatusReportStatus (статус отчета о состоянии объекта) происходит соответствующее распределение, позволяющее считывать информацию о полученных разрешениях и одобрениях, так как этот элемент является производным от элемента GenericApproval (одобрение общее).

Для управления затратами в модели данных используется элемент Account (счет), который позволяет вести структурированный учет затрат и доходов (для расчета издержек), поступлений и выплат (для расчета рентабельности и ликвидности). Счет можно интерпретировать как вид затрат или бухгалтерский счет. Счета могут иметь иерархическую структуру и образовывать номенклатуру или план счетов. Для каждого ресурса (Resource) может быть подготовлен счет. Таким образом, определяется, как будут проводиться по бухгалтерским книгам затраты, вытекающие из использования ресурсов.

Размер затрат, являющихся результатом использования ресурсов, специфицируется с помощью элемента CostRate (нормы затрат). Норма затрат может быть соотнесена с элементом CalendarEntryType (типом записи в календарь), с целью показать для какого вида использования ресурсов она (норма затрат) установлена.

В зависимости от времени нормы затрат могут относиться либо к типам ресурсов [элемент CostRateResourceTypeAssignment (соотнесение нормы затрат и типа ресурсов)] или к ресурсам [элемент CostRateResourceAssignment (соотнесение норм затрат и ресурсов)].

Статьи затрат (CostCenter) служат для расчета затрат в части организации структуры. Они могут располагаться в форме иерархии. Кроме того, в зависимости от времени происходит распределение сотрудников (Staff) по статьям затрат [элемент CostCenterStaffAssignment (соотнесение статей затрат и сотрудников)]. Статьи затрат могут, но не должны быть идентичны организационным единицам. Чтобы показать взаимосвязь между статьями затрат и организационными единицами, имеется соответствующая классификация [элемент Resource (ресурс), который представляет также организационные единицы].

Чтобы сделать возможными эффективный учет и обработку затрат и доходов, поступлений платежей и выплат, предварительно могут быть определены профили бухгалтерских проводок (элемент TransactionProfile), ставки НДС (элемент VATRate) и фиксированная ставка (элемент FlatRate).

Профили бухгалтерских проводок предназначены для обработки бухгалтерских проводок по издержкам. Ставки НДС определяют установленные законом ставки НДС для различных групп продукции и услуг. Фиксированные ставки используются, в частности, для эффективного ввода и обработки командировочных и накладных расходов.

Движение (увеличение) стоимости в денежном выражении представляется в модели данных с помощью элемента Transaction (бухгалтерские проводки). Бухгалтерская проводка может представлять (определять) издержки, доходы или поступающие платежи и выплаты. В модели данных она соотносится с валютой (Currency) и состоит из отдельных позиций бухгалтерской проводки (TransactionItem). Если позиция бухгалтерской проводки применяется для целей калькуляции продукта, то ей может быть подчинен элемент продукта (ProductElement). Если позиция бухгалтерской проводки является результатом применения (обработки) фиксированной суммы затрат (FlatRate), то и здесь может происходить привязка. Позиции бухгалтерских проводок привязываются к отдельным объектам управления (Initiative), так что рассмотрение затрат возможно на уровне объекта управления. Часто для эффективной обработки позиций бухгалтерской проводки применяются так называемые профили бухгалтерских проводок (TransactionProfile), для которых также происходит привязка. Каждая позиция бухгалтерской проводки может быть также привязана к счету (Account) и ставке НДС (VATRate). Если позиция бухгалтерской проводки является результатом использования ресурсов, то это показывается с помощью связи с элементом InitiativeResourceAssignment (распределение ресурсов по объектам) или TimesheetEntry (позиция табеля учета времени). Для возможности расчета статей затрат можно выполнить соединение с элементом CostCenter (статья затрат).

Для организации системы отчетности в рамках проекта необходимо работать с агрегированной информацией о затратах. Такая агрегированная информация отображается с помощью элемента InitiativeCostData (данные о затратах объекта), который соотносится с элементом Initiative (объект управления).

В модель данных заложена так называемая система оценки, которая может представляться в качестве общей структуры данных, например для целей менеджмента качества и управления рисками, а также для установления приоритета проекта. Данная структура должна содержать информацию о критериях, которые могут использоваться для оценки и анализа элементов (преимущественно элементов Initiative).

При этом AssessmentFramework (структура оценки) состоит из набора критериев оценки (AssessmentCriteria), которые могут располагаться в виде иерархии. Кроме того, для каждого критерия оценки должны определяться соответствующие документы (Document). Структура оценки вместе с критериями оценки образует шаблон для оценки объекта управления (InitiativeAssessment). Оценка объекта состоит из элементов оценки объекта (InitiativeAssessmentItem), которые могут иметь прямое соответствие с критериями оценки. Элементы оценки объекта могут располагаться в виде иерархической структуры и содержать ссылки на документы. Оценка объектов выполняется сотрудниками (Staff), так что можно делать ссылки на любых сотрудников. То же самое касается и элементов оценки объекта. Для них могут быть определены соответствующие сотрудники.

Если из оценки объекта следует принятие необходимых мер (мероприятий), то они определяются с помощью элемента "Меры элемента оценки объекта" (InitiativeAssessmentItemMeasure) и могут ссылаться на объект управления, что позволяет осуществлять их детальное планирование и управление.

Модель данных предусматривает использование любых документов (Document). Документы могут относиться к элементам продукта (ProductElement), ресурсам (Resource), объектам управления (Initiative) и назначениям (Appointment). Документ может храниться в различных версиях документа (DocumentVersion) (предусматривается версионность). С каждой версией документа в зависимости от времени могут быть соотнесены соответствующие типы статуса документа (DocumentStatusType). Для каждого такого соотнесения может происходить отдельное одобрение [элемент DocumentStatusApproval (одобрение статуса документа)]. Данное одобрение является специализацией элемента GenericApproval (одобрение общее). Параллельно с этим документ может находиться в обработке сотрудником. Эта обработка отражается с помощью элемента DocumentVersionCheckedOut (версия документа в обработке). Для каждой версии документа есть один или несколько сотрудников (Staff), которые выступают в качестве автора или редактора.

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