Руководство по разработке CONOPS

Когда вы входите в проект, который находится в стадии разработки или производства, то вам придется изучить несколько документов общим объемом не менее 30-50 страниц, чтобы понять:
- обоснование разработки системы и рассмотренные альтернативы;
- общую организацию и взаимодействие в проекте;
- описание операционного и организационного контекста системы.
Эти данные вам нужны для понимания основных заложенных в проект предположений и общего замысла, они задают основу для принципов принятия решений и координации на проекте.
К сожалению, обычно такие данные раскиданы по обильной проектной и технической документации. Стандартные методики управления проектом подразумевают два документа, которые описывают проект в целом - это устав проекта и техническое задание.
Проблема в том, что устав не описывает технические выборы и обоснования, а техническое задание не описывает рассмотренные альтернативы. И часто эти два документа не содержат анализа операционного и организационного контекста. При такой организации документов вам надо читать и держать в голове техническое задание, устав и аналитическую записку, чтобы понять, как будет использоваться система, что она изменит в текущей деятельности и как в целом организован проект по ее созданию.
Это настолько распространенная проблема, что для нее есть несколько решений. Наиболее проверенным решением, на мой взгляд, является разработка документа “Концепция эксплуатации”, иногда ее называют “Концепция использования”.
Google на поисковой запрос “concept of operations” выдает 639,000,000 результатов, а сама практика в ходу с 1998 года, когда был введен соответствующий стандарт 1362-1998 - IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps). Концепция эксплуатации помогает получить комплексное понимание обстановки, функции системы в ходе ее эксплуатации и задает критерии успешности системы.

Это руководство состоит из:

Обоснований для разработки КонЭксп

Описания формата и стандарта документа

Примера КонЭксп с разбором методики его разработки

КонЭксп помогает:

Согласовать взгляды стейкхолдеров на функционирование системы, зоны ответственности и методы коммуникации;

Определить высокоуровневую концепцию системы и обосновать ее превосходство над другими альтернативами;

Определить среду функционирования системы;

Определить высокоуровневые требования;

Обеспечить критерии приемки для воплощенной системы.

Что должен содержать КонЭксп?

КонЭксп - это текстовое и графическое описание предположений и замысла руководства в отношение какой-то деятельности. Оно отвечает на следующие вопросы:

Как? Какие ресурсы нам нужны чтобы спроектировать и построить систему?

Кто? Кто является стейкхолдерами системы?

Почему? Чего такого не хватает вашей организации, что дает эта система?

Что? Насчет каких элементов есть определенность и что она точно должна уметь делать?

Когда? Какая должна быть последовательность действий по воплощению системы?

Где? Какое географическое и физическое размещение системы?

Минимально КонЭксп состоит из следующих разделов:

1. Решаемая проблема

2. Миссия и обоснование

3. Замысел руководства

4. Ограничения по финансированию

5. Обзор планируемых к использованию технологий

6. Обзор операционной и рыночной обстановки

7. Решаемые задачи

8. Роли и обязанности задействованных организаций

Когда вы пишите текстовые документы, помните, что согласно принципам пирамиды делового письма Барбары Минто  ни в коем случае нельзя оставлять ничего не значащие заголовки разделов “Решаемые задачи” или “Замысел руководства”, потому что эти общие слова никак не передают содержание соответствующих разделов. Другими словами, рекомендуемая структура КонЭксп является метамоделью документа. Поэтому структура примера выглядит так:

1. Проблема

2. Система управления жизненным циклом (PLM-система) на базе продуктов Autodesk и ELMA ECM+ ускоряет запуск и реализацию проектов разработки и строительства заводских комплексов без увеличения штата

3. Контроль инженерной документации и управление процессами бэк-офиса запускается в 1 квартале, сквозное проектирование и полная интеграция данных жизненного цикла во 2 квартале

4. Бюджет проекта 4,7 млн.р. с 30% авансом с полной стоимостью владения на 5 лет 6,1 млн.р.

5. Продукты Autodesk и ELMA ECM+ поддерживают сквозной процесс разработки с интеграцией данных через обменный файл формата COBie

6. PLM система обеспечит сквозной процесс разработки и контроль строительства

7. Система будет моделировать состав, конфигурацию и работы по созданию и поставке заводских комплексов

8. Потребуется пересмотреть контракт с заказчиком и создать службу справочных данных

Такая структура позволяет быстро понять содержание документа и начать обдумывать свои действия.

Чек-лист КонЭксп:

Четко ли указана причина разработки системы?

Все ли стейкхолдеры определены и все ли предполагаемые роли описаны?

Рассмотрены ли альтернативные концепции решения проблемы и обоснован ли выбор решения?

При выборе оптимального решения учтены ли необходимые интерфейсы к существующим системам?

Описана ли необходимая поддержка и обеспечение?

Включено ли в эту поддержку техническое обслуживание?

Описана ли операционная обстановка и среда функционирования?

Я пользуюсь следующей методикой разработки КонЭксп:

Шаг 1. Создать модель жизненного цикла

Шаг 2. Создать варианты концепций автоматизации, выбрать подходящий

Шаг 3. Проанализировать операционный и бизнес-контекст завода

Шаг 4. Составить полную модель жизненного цикла завода с учетом результатов анализа контекстов

Шаг 5. Составить операционную архитектуру и структуру программы проектов

Шаг 6. Проанализировать стейкхолдеров программы и сформировать оргструктуру программы.

Пример КонЭксп “Система управления жизненным циклом завода по производству композитов”
[Blogger сжимает большие картинки, поэтому вот ссылка на модель ArchiMate для тех, кто хочет разобраться в методике. Файл по ссылке вначале надо сохранить, открывать только локально. Свободный редактор Archi можно скачать здесь. Русификация от Александра Лучкова лежит здесь.]

Вводная на ситуацию

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

- Поскольку таких проектов будет все больше, директор считает, что на его примере  надо создать и обкатать новый процесс;

- Бумажный документооборот, электронная почта и работа с проектной документацией явно недостаточны, т.к. поиск нужной информации занимает иногда час или больше, а проектные архивы пришлось перенести на склад;

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

Поэтому он предлагает вам автоматизировать процесс проектирования и строительства заводских комплексов и создать типовой проект, и ждет от вас предложений по подходу. 

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

Чтобы не придумывать велосипед, вы провели небольшое исследование и обнаружили, что наиболее проработанной сейчас является концепция полностью обслуживаемых объектов капстроя от концерна FIATECH, которую вы перевели и оформили в виде диаграммы ArchiMate:

В ходе этого же исследования вы нашли подходящую модель жизненного цикла:

http://15926.org/topics/plant-lifecycle-model/index.htm

http://15926.org/topics/management-summary/index.htm

Ее вы тоже оформили как диаграмму ArchiMate:

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

Модель жизненного цикла осталась неизменной, она всех устроила.

Настал момент встречи с поставщиками ИТ-решений. На этой встрече будет ваше руководство, ожидаемый результат этой встречи в том, что поставщики докажут вам реализуемость вашей желаемой схемы автоматизации. Вы решаете разделить обсуждение на 3 части. Для каждой стадии проекта по разработке и строительству заводского комплекса вы будете отдельно обсуждать комплекс автоматизации проектирования, отдельно комплекс автоматизации управления проектом и документооборотом, а потом обсуждать интеграцию, передачу и хранение данных, включая управление мастер-копиями. Для того, чтобы организовать такое обсуждение, вы готовите диаграммы обеспечения жизненного цикла технологиями проектирования и управления документооборотом.

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

С помощью этой диаграммы вы обсуждаете автоматизацию разработки на стадии разработки эскизного и технического проекта.

Эти обсуждения строятся так, чтобы ответить на интересы стейкхолдеров, проектных ролей: маркетолога, представителя заказчика, инженера-проектировщика и инженера-технолога, инженера справочных данных, закупщика и поставщика. Как организовывать совещания с учетом интересов стейкхолдеров см. пост http://sdu2020.blogspot.com/2016/12/oarrs.html 

Про основы инженерии справочных данных можно почитать здесь http://bit.ly/2TumsoP

Суть таких совещаний в том, что поставщик ИТ-решения должен объяснить и показать как конкретно решение обеспечивает и поддерживает деятельность, которая описана моделью жизненного цикла. Особое внимание надо обращать на доступность нужных данных у стейкхолдеров и на интерфейсах как пользовательских, так и программных. Элементы, описывающие программные функции, желтые блоки, нужны, если будет нужно подробнее обсудить те или иные возможности программного обеспечения.

Диаграмма, по которой обсуждается интеграция ИТ-систем и обмен данными, их доступность на интерфейсах.

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

Проблема выявилась с обновлением спецификации материалов, bill of materials (BOM). Формат BOM, на котором вы остановились, такой http://bit.ly/2ENAZUx В нем есть разделы, которые ведут инженеры, производственники и закупщики. Процесс выпуска у вас выглядит следующим образом:

Если говорить проще, то вначале в BOM у вас обновляется инженерная информация, и какое-то время инженерная, производственная и закупочная части BOM будут рассогласованы. Компания сознательно пошла на такой шаг, чтобы получить высокую скорость внесения инженерных изменений, она критична для бизнеса. Закупщики видят изменения, анализируют измененные и новые спецификации, 3Д модели и чертежи, обсуждают их с поставщиками, обновляют сроки, цены и условия поставки, и вносят информацию в закупочную систему, т.к. именно там у них происходит документооборот. И PDM должна забрать эти данные, чтобы обновить BOM. Получается, что выпуск данных в BOM, который находится в хранилище PDM, происходит из двух систем - из САПР стандартными механизмами интеграции и из ELMA ECM+. Вопрос, который волнует специалистов по интеграции - как забирать данные из закупочной системы? Самый простой вариант был бы выкладывать из ELMA ECM+ в конце дня таблицу с закупочной информацией, где ключом служит номер артикула (part number) единицы учета, PDM бы считывала этот файл во время ночной синхронизации, и объединяла с инженерной информацией по ключу номера артикула. Вы какое-то время обсуждаете, устраивает вас такой механизм синхронизации и приходите к мнению, что с вашим объемом данных и скоростью процессов эта схема даст удовлетворительный результат. Вы заносите результат договоренностей в модель ArchiMate:

И подытоживаете все в диаграмме интеграции:

Эти диаграммы и пояснения к ним описывают вашу концепцию автоматизации жизненного цикла. Теперь вы можете переходить к анализу контекстов и планированию структуры программы.

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

По этой диаграмме обсуждается функция актива “Заводской комплекс” в системе активов заказчика EPCM контракта. Вы назначаете встречу с представителями заказчика и выясняете в чем же, по их мнению, функция завода, какова стратегия компании заказчика для приобретения заводского комплекса. В ходе этого разговора вы выясняете, что функция заводского комплекса - это поставлять композитные волокна для армирования строительных плит и свай на стройкомбинаты заказчика. За счет таких армированных железобетонных изделий заказчик планирует значительно продлить срок службы своих объектов капстроя и уменьшить долгосрочные затраты на управление активами. Кроме того вы обсуждаете вопросы информационной обеспечения безопасности актива после передачи заводского комплекса заказчику и вопросы финучета и контроллинга. На вопросы про конкурентов заказчик вам ничего не смог ответить, и вы запланировали провести свое исследование на эту тему. По вопросам работы с госорганами заказчик предоставил вам их корпоративного юриста и сказал, что можете уточнять все у него. В конце вы обсудили как лучше организовать инженерное обследование места строительства, порядок подключения к инженерным сетям и инфраструктуре, примерный бюджет такого обследования и даты проведения этого обследования.

Следующим пунктом вы рассматриваете контекст разработки и производства, в этом контексте находятся обеспечивающие системы и технологии разработки и производства. Обеспечивающие системы, фактически, “протаскивают” заводской комплекс по жизненному циклу - от проектирования до снабжения работающего завода сырьем и организации маркетинга и сбыта готовой продукции. Часть этих обеспечивающих систем уже существует, а часть надо будет создать, об этом пойдет речь дальше, при планировании структуры программы. Проект автоматизации, о котором мы говорили с генеральным директором и который обсуждали с поставщиками ИТ-решений, является частью обеспечивающих систем: 

EnSys1. Система проектирования заводского комплекса [обеспечивающая система],

EnSys2. Генподрядчик строительства и его субподрядчики [обеспечивающая система],

EnSys4. Система обслуживания, ремонта и модернизации завода [обеспечивающая система].

Когда мы говорим про системы проектирования и строительства, нам надо понимать структуру и состав целевой системы заводского комплекса. Они описываются диаграммой системного контекста.

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

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

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

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

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

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

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

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

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

Вначале перенесем данные со стрелочек в отдельные информационные объекты. Этот процесс называется реификацией.

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

Модель жизненного цикла использующей системы обычно оформляется как предпроектная стадия:

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

EnSys1. Система проектирования заводского комплекса [описание системы], 

EnSys2. Генподрядчик строительства и его субподрядчики [описание системы], 

EnSys3. Система подготовки кадров для заводского комплекса [описание системы], 

EnSys4. Система обслуживания, ремонта и модернизации завода [описание системы], 

EnSys5. Система материального обеспечения хозяйственной деятельности заводского комплекса [описание системы], 

EnSys6. Логистическая цепочка снабжения сырьем BRM [описание системы], 

я с помощью информационных объектов моделирую начальное, текущее состояние, и целевое состояние. Например, для EnSys1. Система проектирования заводского комплекса [описание системы] начальное состояние будет Design and construction automation concept [information object], а целевое Enterprise IT architecture increment [information object]. В результате я получаю модель жизненного цикла обеспечивающих систем:

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

Вход. Design and construction automation concept [information object]

Практика. EnSys1. Define IT contractors and develop implementation plans [practice]

Выход. IT-systems implementation collaboration agreements [information object]

моделирует работу стейкхолдера “Руководитель проекта”, который входит в оргзвено “Технический заказчик (EPCM группа)” с технологиями выбора поставщиков, например, тендерными таблицами, и планирования проектов по поставке ИТ-систем, например, методикой управления ИТ-проектами и процессом управления конфигурацией и изменениями в ИТ-системах.

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

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

Финальный шаг разработки модели КонЭксп - это анализ стейкхолдеров и формирование оргструктуры программы. На практики жизненного цикла назначаются стейкхолдеры:

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

- это не даст вам никакого полезного упрощения, фактически, стейкхолдер будет равен практике, а модель стейкхолдеров будет дублировать модель практик;

- модели, в которых больше 30 стейкхолдеров/проектных ролей, невозможно поддерживать, они бесполезны.

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

Когда у меня есть список стейкхолдеров, я могу распределить их роли между имеющейся оргструктурой программы, назначить оргзвенья на стейкхолдерские роли:

И прописать оргинтерфейсы, соглашения по взаимодействию, которые действуют для этой оргструктуры:

Теперь, когда у вас есть модель, которая описывает концепцию эксплуатации, я напишу на ее основе короткий обзорный документ, структуру которого я привел в начале руководства.

КонЭксп “Система управления жизненным циклом завода по производству композитов”

Проблема

Небольшая инженерно-производственная компания занимается проектированием и управлением стройкой заводских комплексов по производству композитных материалов. Текущий процесс управления проектами и разработкой построен на ручном управлении, а поток заказов растет. Увеличение штата скорее всего проблему не решит, т.к. текущая организация и так работает на пределе, при увеличении числа работников менеджмент не будет справляться с руководством. Поможет ли автоматизация процессов разработки и управления проектами увеличить количество выполняемой работы? Предварительный анализ проблемы показал, что поможет. Но выбор программного обеспечения для организации инженерной разработки и промышленного строительства очень широкий, что выбрать, чтобы не ошибиться? Другими словами, какой класс программного  обеспечения выбрать для автоматизации разработки и управления проектами и в какой последовательности внедрять программные модули, чтобы получить наилучший эффект?

Система управления жизненным циклом (PLM-система) на базе продуктов Autodesk и ELMA ECM+ ускоряет запуск и реализацию проектов разработки и строительства заводских комплексов без увеличения штата

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

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

Разработка конструкции заводского комплекса поддержана системой электронного документооборота ELMA ECM+ с функциями: моделирования, исполнения, контроля и мониторинга бизнес-процессов, включая их оптимизацию; управлению задачами и проектами, тендерами и типовыми закупками; управления документооборотом, администрированием офиса, согласованием служебных записок и заявок, управление закупками и бюджетом. Все это включает в себя и организацию взаимодействия и поддержание справочных данных поставщиков и других контрагентов, включая практику закупок и управления договорами подряда. ELMA ECM+ управляется с консоли администратора и интегрируется с решениями 1С, которые компания уже использует. Запуск ELMA ECM+ рекомендуется осуществить в первую очередь, т.к. в своей коробочной конфигурации она за несколько дней после установки позволит организовать процессы бэк-офиса, которые сейчас отнимают у руководства до 20 часов в неделю.

Непосредственно сам процесс разработки конструкции заводского комплекса  предлагается вести в программном комплексе Autodesk Product Design and Manufacturing Collection, который включает в себя AutoCAD, Inventor Professional, Inventor HSM, Fusion 360, Autodesk Nastran In-CAD и Factory design utilities. Этот комплекс инженерных программ из коробки интегрирован с программой хранения и управления инженерной и проектной документацией Autodesk Vault. Проектирование зданий происходит в строительном САПР Revit, коллективная работа проектировщиков промышленного здания организована через Revit Server. 

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

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

Совместная работа и ведение архива обеспечено Autodesk Vault, который позволяет: хранить документы, индексировать и искать нужные документы, администрировать инженерные данные, автоматизировать процессы разработки, управлять проектной документацией и отслеживать ревизии документов, управлять жизненным циклом продукции и ВОМ, а также сопровождать инженерные изменения.

Использование этих комплексов по экспертным оценкам уменьшает трудозатраты инженеров на 400-600 часов в месяц со второго месяца использования, что равносильно найму 3-4 дополнительных человек. После переноса всей проектной документации в инженерные комплексы скорость подготовки коммерческо-технических предложений ускорится с 56 рабочих часов до 12 за счет автоматической обработки данных, настроенных форм и автоматического перерасчета параметрических моделей. Это позволит участвовать в большем количестве тендеров без увеличения загрузки инженерного штата.

Контроль инженерной документации и управление процессами бэк-офиса запускается в 1 квартале, сквозное проектирование и полная интеграция данных жизненного цикла во 2 квартале

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

Список этих практик - обеспечивающие процессы бэк-офиса (кадровые, командировки, некоммерческие закупки, ИТ и т.д.), контрактация и коммерческие закупки, включая тендерные закупки, внутрикомандное общение, в т.ч. документооборот между функциями, юридически значимый документооборот с контрагентами, управление спецификацией материалов (BOM management), управление выпуском конструкторской документации (release management).

В проект по автоматизации должны быть вовлечены начальник инженерной дирекции, начальник коммерческой дирекции, руководитель технического заказчика. Проектирование идет в Autodesk Fusion 360 в “облаке”. Выпущенные чертежи и КД по эскизному проекту хранятся в хранилище ELMA ECM+ либо в базовой конфигурации Autodesk Vault. Процесс управления выпуском КД, изменениями КД и управления спецификациями на завод (bill of materials) автоматизировано рабочими процессами ELMA ECM+. В случае, если временным хранилищем документов выбирается ELMA ECM+, спецификации на завод хранятся в Excel по согласованной форме основного списка сборки (master parts list). 

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

Затем, в течение следующей рабочей недели, группы работают по тем версиям КД, которые были одобрены на этом комитете.

Отвечают за исполнение процесса начальники подразделений, проверяет исполнение проектный офис.

Управление проектом по утвержденным формам документов, отчетность и обновления проектного архива еженедельная. Планирование контрольных точек проекта и стадии эскизного и технического проектирования на старте проекта в первые дни. Постановка задач в ELMA ECM+, 4 потока задач - общий по проекту на базе плана по контрольным точкам (1), задачи технического заказчика (2), задачи инженерной дирекции (3), задачи коммерческой дирекции (4). Еженедельная сводка по статусу задач идет руководителю проектного офиса.

Какие ждут проблемы на Этапе 1? Руководителя службы справочных данных нет, интеграции систем нет, все сверки и выгрузки производятся вручную. Нужно проводить еженедельную проверку и чистку справочников ELMA ECM+, чтобы удалять дубликаты, иначе потом будут большие проблемы при переносе данных. КД только в солидах, нет связки с конфигурацией и BOM. Потом надо будет все переносить в PDM. Сквозная модель стройки и производственной линии появится только в конце технического проектирования, до этого все коллизии и ошибки проектирования надо будет ловить вручную. Переход на сквозное автоматизированное проектирование будет происходить параллельно с активной разработкой технического проекта. При этом скорость разработки упадет в 3-5 раз на срок 2-7 недель. Придется переносить текущий BOM, КД и привязывать проект к типовым библиотекам Autodesk Inventor.

Цель Этапа 2: запустить комплекс инженерных программ, хранилище проектной документации Vault, запустить интегрированный процесс контроля инженерной документации и управления изменениями.

Нанимается руководитель службы справочных данных, строится модель данных для интеграции баз данных и проектирования интерфейсов между базами данных. Заключается договор на поставку лицензий Autodesk Collection, Revit и Autodesk Vault  на внедрение процессов сквозного проектирования. Производится внедрение машиностроительного и строительного САПР, осуществляется перевод инженерной документации в PDM, запуск интегрированных процессов управления конфигурацией. После перехода данные переносятся из ELMA в PDM Vault, данные в ELMA и рабочие процессы управления инженерными выпусками и изменениями закрываются, сотрудников и подрядчиков переучивают пользоваться Vault вместо ELMA. КД импортируется из Autodesk Fusion 360 в Autodesk Collection.

Процессы работы с внешними подрядчиками переделываются и переводятся на PDM.

Процесс перехода на PDM должен завершиться до начала контрактации строительства завода. Строительство завода ведется уже в PDM и САПР с ежедневной сверкой КД и факта, управление проектом строительства в PDM.

Какие проблемы ждут на Этапе 2? Перенос данных в Vault, создание справочников и отладка всех процессов одновременно приведут к высокой загрузке инженерного и технического персонала, т.к. придется одновременно вести техническое проектирование и осваивать новые программные продукты. Отставание от графика, которое возникнет на этом этапе, будет наверстано в течение следующих 3-5 месяцев работы на проекте.

Бюджет проекта 4,7 млн.р. с 30% авансом с полной стоимостью владения на 5 лет 6,1 млн.р.

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

Продукты Autodesk и ELMA ECM+ поддерживают сквозной процесс разработки с интеграцией данных через обменный файл формата COBie

В ходе анализа вариантов автоматизации команда проекта рассмотрела 3 варианта автоматизации - с СЭД “Директум”, Компас 3Д и Лоцман PLM и Autodesk с освоением полного комплекса инженерных программ на первом же этапе. ELMA ECM+ оказалась оптимальной средой для организации документооборота из-за набора коробочного функционала, удобства пользовательского интерфейса и возможности настройки рабочих процессов с помощью редактора BPMN. При выборе Autodesk команда руководствовалась необходимостью дальнейшего перехода на BIM и объединения машиностроительного и строительного проектов. Затруднение было с определением порядка освоения программ инженерного комплекса. В результате архитектурное проектирование было решено делать как обычно в AutoCAD с дальнейшим переносом проекта в Revit и BIM360. Машиностроительное проектирование будет перенесено в Autodesk Inventor.

Синхронизация инженерных и закупочных данных во время процессов выпуска КД и внесения инженерных изменений осуществляется через обменный файл формата COBie ночью, ELMA ECM+ формирует отчет по произошедшим изменениям инженерных данных, а Autodesk Vault формирует отчет по произошедшим изменениям закупочных данных, пришедшим из ELMA ECM+.

Остальные интеграции между инженерными программами, хранилищем и СЭД стандартные.

PLM система обеспечит сквозной процесс разработки и контроль строительства

Комплекс из системного моделлера Archi, продуктов Autodesk Product Design and Manufacturing Collection совместно с Autodesk Revit и Autodesk BIM360, используется для организации разработки, проектирования и управления строительством заводских комплексов. Процессы бэк-офиса инженерно-производственной компании организуются с помощью решений на базе системы электронного документооборота ELMA ECM+. 

В контур автоматизации войдут практики:

Определение начальных требований;

Разработка технологии и архитектурное проектирование заводского комплекса;

Рабочее проектирование заводского комплекса;

Управление справочными данными;

Закупка материалов и оборудования;

Контроль исполнения заказов на изготовление и поставку материалов и оборудования;

Контроль за деятельностью подрядчиков;

Изготовление элементов заводского комплекса;

Логистика;

Строительство и монтаж, внутренняя приемка;

Валидация производственного процесса;

Управление активами;

Данные из PLM-системы используются для отчетности руководству исполнителя, заказчику и после завершения проекта переносятся с системы управления активом заводского комплекса и ТОиР с помощью полностью заполненного обменного файла COBie.

Для полноценного использования PLM потребуется закупка 2 лицензий Autodesk Vault и 12 лицензий BIM360 для подключения заказчика и подрядчиков к необходимым источникам данных. PLM меняет практику приемки работ строительного подрядчика, т.к. план приемки и необходимая документация теперь будет доступна из системы публикации Autodesk BIM360 Docs в том числе на мобильных устройствах.

Система будет моделировать состав, конфигурацию и работы по созданию и поставке заводских комплексов

Ключевым элементом PLM является сконфигурированное под структуру типового заводского комплекса хранилище Vault с настроенной моделью свойств единиц учета (configuration items). Структура типового заводского комплекса включает в себя:

SysoI 1. Комплекс заводских зданий и сооружений

SysoI 1.1. Завод 

SysoI 1.2. Ограниченная территория заводского комплекса

SysoI 1.3. Периметр безопасности заводского комплекса

SysoI 1.4. Склад и лаборатория

SysoI 1.5. Система внутренней логистики заводского комплекса

SysoI 1.6. Газовая подстанция

SysoI 1.7. Точки подключения к инженерным сетям место строительства

SysoI 1.8. Система управления активами, ТОиР и обеспечения непрерывности деятельности

Единица учета SysoI 1.1. Завод разбивается дальше:

SysoI 1.1.1. Здание завода

SysoI 1.1.1.1. Фундамент здания завода

SysoI 1.1.1.2. Коробка завода

SysoI 1.1.1.3. Инженерные сети и системы здания

SysoI 1.1.2. Производственные линии завода

SysoI 1.1.2.1. Производственная линия ЗБЗ

SysoI 1.1.2.2. Производственная линия продукции

SysoI 1.1.2.3. Вспомогательное технологическое оборудование

SysoI 1.1.2.4. АСУ ТП

SysoI 1.1.2.5. Инженерные сети производственного цеха

SysoI 1.1.3. Производственная система завода

SysoI 1.1.4. Система менеджмента качества завода

SysoI 1.1.5. Система менеджмента рисков и безопасности окружающей среды завода

SysoI 1.1.6. Периметр завода

SysoI 1.1.7. Административные и хозяйственные помещения завода

SysoI 1.1.8. Интерьер и рабочие места на заводе

Модель свойств единиц учета берется из спецификации стандарта обмена данными по объектам капстроя COBie, а стандарты заполнения PLM и качества данных определяются 

The Ohio State University BIM Project Delivery Standards Check и Western Michigan University Revit Model Checks. 

Конфигурация обеспечивающих систем хранится в ELMA ECM+ и описывает состав и характеристики:

EnSys1. Система проектирования заводского комплекса

EnSys2. Генподрядчик строительства и его субподрядчики

EnSys3. Система подготовки кадров для заводского комплекса

EnSys4. Система обслуживания, ремонта и модернизации завода

EnSys5. Система материального обеспечения хозяйственной деятельности заводского комплекса

EnSys6. Логистическая цепочка снабжения сырьем ЗБЗ

EnSys7. Система выставок, маркетинговых мероприятий и сбыта продукции

Модель свойств элементов для ELMA ECM+ стандартная с необходимыми доработками, заложенными моделью жизненного цикла v.1.4 от 25.12.18.

Потребуется пересмотреть контракт с заказчиком и создать службу справочных данных

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

Процесс интегрированных изменений и контроля инженерной документации будет управляться рабочей группой, которая состоит из руководителя службы справочных данных, главного проектировщика и руководителя технического заказчика (руководителя проекта EPCM). У руководителя службы справочных данных должны быть полномочия по управлению всем процессом интегрированных изменений, включая выдачу распоряжений проектировщикам по устранению замечаний к КД и проектной документации, которая стоит под контролем конфигурации. Руководитель службы справочных данных должен будет разработать следующие стандарты:

Сокращения и определения

Кодирование артикулов, номеров деталей и единиц учета

Взаимозаменяемость

Версии продукта и номеров деталей

Контроль версий

Стандарт спецификации материалов

Стандарт спецификации заводского комплекса

Управление инженерными изменениями

Запрос на изменения

Руководство по эксплуатации

Передача документов заказчику

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

Что дальше?

1. На основе КонЭкс, структуры изделия (PBS) и модели жизненного цикла вы легко разработаете WBS:

и сможете спланировать проект по стандартной методике:

Работы по планированию проекта

Разработка и согласование обоснования и фин.модели проекта и устава проекта
Разработка модели жизненного цикла проекта и завода
Запуск процессов технической координации
Разработка и согласование плана управления проектом
Разработка планов проекта
Определение продуктов проекта
Определение пакетов работ
Определение ключевых навыков, которые необходимы для реализации стадий 2-4
Организация полномочий и ответственности в проекте
Разработка планов фаз и планов по контрольным точкам
Определение предметов поставки проекта и разработка спецификаций на предметы поставки
Разработка и согласование плана приемки предметов поставки 
Выявление рисков и планирование реагирования на них
Утверждение базового плана проекта, проектных фаз и плана по контрольным точкам. Постановка планов под контроль конфигурации.

Работы по исполнению проекта, мониторингу и контролю

Подготовка и распространение отчетов о ходе работ
Контроль исполнения всех задач проекта, вошедших в базовый план
Контроль производства предметов поставки, их приемка и проверка документации на предметы поставки
Выявление отклонений и управление изменениями проекта
Постоянное улучшение процессов
Контроль процессов и обеспечение качества процессов
Проведение проверок качества предметов поставки и продуктов проекта 
Регистрация результатов проверок в журнале предметов поставки и приемки по качеству
Измерение хода работ в сравнении с плановыми показателями и контроль за исполнением работ
Организация и проведение тендеров и заключение договоров с поставщиками
Проведение индивидуальной и групповой оценки 
Перераспределение ресурсов проекта
Подготовка информации, ее распространение и управление информацией, отправляемой третьим сторонам
Сбор и обработка обратной связи по работам проекта, предметам поставки и продуктам проекта
Измерение показателей проекта и сравнение их с отчетами о ходе проекта
Анализ и оценка данных по исполнению и принятие решений по корректировке хода проекта либо планов проекта
Выявление факторов, которые являются причинами отклонений и устранение таких факторов
Построение прогнозов и запрос изменений в случае необходимости, реализация интегрированного контроля изменений
Одобрение либо отклонение запрошенных изменений, корректировка проектной документации в случае одобренных изменений и информирование заинтересованных сторон о происходящих изменениях
Управление конфигурацией завода и подтверждение качества составных частей завода совместно с представителями заказчика
Отслеживание заявок на закупку и поставок
Подготовка и рассылка отчета об окончании проектной фазы.

Работы по закрытию проекта

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

Сбор накопленного опыта, обучение людей на основании полученного опыта, корректировка практик реализации и выполнения проектов.

Заключение

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