среда, 27 марта 2019 г.

Путь бизнес-архитектора

На инженерах лежит ответственность больше, чем на людях других профессий, потому что результаты их работы доступны для всеобщего обозрения. Его действия, шаг за шагом, воплощены материально. Он не может похоронить свои ошибки, как врач. Он не может заговорить их убедительной аргументацией как юрист. Он не может, подобно архитекторам, скрыть их за деревьями и плющом. Он не может как политик, обвинить в своих ошибках оппонентов и надеяться, что люди забудут про них. Инженер попросту не может отрицать, что это сделал именно он. Если его творение не работает, он проклят.
~ Герберт Гувер, инженер Кыштымского медеплавильного завода, филантроп, спасший сотни тысяч русских во время голода 1921, предприниматель и 31 президент США

Мы прошли длинный путь к пониманию того, что такое практика бизнес-архитектуры. Тема вышла из моды, в ней остались в основном профессионалы, которые хорошо понимают в чем суть работы бизнес-архитекторов.



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

Вот краткая программа того, как стать бизнес-архитектором:
1. Изучи и начни практиковать онтологику
2. Изучи и начни практиковать системное мышление
3. Пойми и начни видеть, что предприятие как система систем состоит из модулей-оргзвеньев, которые работают в направлении одной цели и выполняют функцию в цепочке производственной кооперации, т.е., деятельность предприятия - это всего лишь одна функция в жизненном цикле какой-то целевой системы, которая создается системой систем производственной кооперации, также известной как "цепочка создания ценности/value chain"
4. Пойми и начни видеть, что эта функция предприятия разбивает его на несколько частей, которые называются оргспособностями/capabilities, и предприятия участвует в нескольких цепочках создания ценности/производственных кооперациях. Вопрос распределения ресурсов между оргспособностями и есть вопрос стратегии.
Здесь бизнес-архитектор начинает видеть предприятие как черный ящик.
5. Пойми и начни видеть людей как стейкхолдеров, носителей дисциплины практик, научи их нацеливать на целевую систему оргспособности в каждой ситуации и удерживать фокус внимания на объектах их практики с учетом надежности человека.
6. Пойми, что люди как оргмодули являются частями организации и у них есть обязательства, которые они дают от имени своего оргзвена другому оргзвену и конфигурация этих обязательств и контрактов и есть архитектура предприятия, см. Martine and Jarillo 1989 и Dietz.
7. Пойми, что мышление и принятие решений всегда является распределенным байесовским выводом, где доверие - это количественный учет веса свидетельства стейкхолдера на итоговое решение, величина, на которое он сдвигает вывод, а уважение - это принятие результатов вывода дисциплинарных мыслительных моделей. И для принятия решений всегда надо поддерживать ситуационную осведомленность команд в каждом из трех контекстов оргспособности - организационном, операционном и системном.

=========================================================================
The great liability of the engineer compared to men of other professions is that his works are out in the open where all can see them. His acts, step by step, are in hard substance. He cannot bury his mistakes in the grave like the doctors. He cannot argue them into thin air or blame the judge like the lawyers. He cannot, like the architects, cover his failures with trees and vines. He cannot, like the politicians, screen his shortcomings by blaming his opponents and hope the people will forget. The engineer simply cannot deny he did it. If his works do not work, he is damned.

~ HERBERT HOOVER

We've come a long way to understand what business architecture practice is. It's no fad nor fashion nowdays, it's professional occupation with no hype aroma around it.




We understand for what it comes to raise such professionals, but educational curriculum is dozens pages long. How do you compare options? And if it is secondary education you're looking at then what are gaps you need to fill in your skillset to become one state-of-the-art business architect?

Here is what you do:
1. Learn and start developing ontologies using pragmatical approach and Bayesian thinking process. You need to capture both formal logical thinking and intuition to come up with ideas about enterprises.
2. Learn systems thinking as systems engineering schools understand that term. You will got nowhere if you cannot very fast apply RFLP (requirements-functional-logical-physical) concepts to set up taskforce.
3. Ground RFLP model to enterprise domain and start seeing that enterprise as a system of systems consisting of orgunits as physical modules, that are aligned to the single goal and such collection performs a function in value chain so that enterprise business is just one function in this value chain of some system-of-interest that is created by this value chain. Enterprise has few such functions and is usually part of few value chains.
4. Comprehend the idea and start see it real life that such function is breaking enterprise down into distinguished parts, which are called capabilities, and this is capability that is participating in value chain, not the enterprise as a whole. The question how you distribute resources over capabilities is central to enterprise strategy.
This is business architect looking at enterprise as a black box.
5. Start seeing people as stakeholders who hold practices' discipline, way of thinking properly in practice domain and learn to aim them on capability they are part of as this is their system-of-interest they should cooperate upon. You should learn how to keep stakeholders' attention on life cycle practices business objects and hold in mind human factor at the same time.
6. You should learn to see that people are also part of orgunit modules and they have commitments on orgunit business interfaces. Configuration of such commitments and contracts on business interfaces is enterprise architecture, see Martine and Jarillo 1989 and Dietz.
7. Finally, learn that thinking and decision making is always distributed Bayesian reasoning, where trust is quantitative account in stakeholder's final decision, value she moves her Bayesian inference. And respect is account for stakeholder's thinking model and result of inference. This will allow you and your team always maintain  situational awareness in each of the three context - business, operational and system.

пятница, 22 марта 2019 г.

Системно и по понятиям. На Twitch.

Вторник и четверг, в 13:00 будет выходить передача "Системно и по понятиям". Это первая передача в серии "Обедай и учись на бизнес-симуляциях".

Структура программы:
1. Понятие. Термины, значения, объекты, смысл и практики. Этимология. Концептуальная карта понятия.
2. Применение понятия в игре Production Line. Привязка понятия к жизни, где и как его увидеть.
3. В каких моделях и контекстах используется и польза применения.
4. Какие решения принимаются по модели с использованием этого понятия?
5. На какие интересы каких стейкхолдеров отвечают эти модели?
6. Практика, дисциплина, источники знаний, инструменты практики.
7. Ошибки и путаница.

Канал на Twitch
https://www.twitch.tv/turkhale

суббота, 16 марта 2019 г.

Wargame intro


Лида сидела в офисе одна и пила утренний кофе. В голове вперемежку крутились мысли о том, что покупать Насте на день рождения, приглашать в детский сад аниматоров или фокусников, переходить ли на полную ставку, потому что деньги бы ей не помешали. Все прервал сигнал сообщения, Лида потянулась за телефоном, там висело уведомление корпоративного приложения. Она хотела было уже смахнуть его как очередной спам от HR, но в уголке была фотка финансового директора. Для квартальной отчетности было рановато, и она с интересом открыла сообщение, там была одна строчка: "Ваш код оплаты 33067, действителен до 17 марта. Остаток по счету 1,298,915". Она с непониманием смотрела на сообщение и тут увидела всплывающее окно чата, это был Карл. "Зайди ко мне прямо сейчас," - писал он. Лида оглядела себя в темном экране ноутбука как в зеркале, чуть поправила челку, и пошла к боссу. Карл подвинул ей листок плотной бумаги с размашистой подписью вице-президента по продуктовой разработке. Сверху на бумажке было написано: "Устав проекта МНФ-16/19АВТ". Лида быстро пробежала глазами по тексту и остановилась на строчке с руководителем проекта.
- Я? - удивилась она. - Да я ни разу проектом не управляла, я же системный инженер.
- Я в курсе. Но Рейнолдс сказал, что если ты достаточно умна, чтобы подготовить предпроект, значит, у тебя хватит ума, чтобы его выполнить. Вдобавок, ему понравилось, что ты про себя ему сказала, что ты умеешь доводить дела до конца. Get things done, он сказал, что программе этого сейчас не хватает.
- Ну ладно, но мне нужен перевод на полную ставку тогда, 12-часовой недели не хватит, чтобы успеть сделать все по этому проекту. И перевод мне нужен с момента начала проекта, то есть с понедельника.
- Заполняй заявку, присылай мне на согласование. Тебя больше ничего не смущает?
- Сумма. Маловато что-то.
- Ага. Рейнолдс урезал тебе фонд оплаты труда вдвое.
- Эй, а как же проект сделать?
- Иди в логово, у интернов ставка по низшему грейду. Как говорится, назвалась груздем, полезай в кузов. Доводи это все до конца.
- Есть у меня подозрение, что ставка у них по низшему грейду не просто так, есть какие-то объективные причины. Ну да ладно, справлюсь. Какие у меня лимиты на самостоятельные траты?
- До 75,000 тратишь как хочешь, отчитываться надо только финконтролю. До 150,000 согласуешь со мной. Заработанным распоряжаешься в пределах лимитов, возврат инвестиций прописан в уставе.
Лида пошла к себе на место и стала думать. Продукт она знала хорошо, значит, на системном инженере можно сэкономить. Нужен технолог по сборке, и тут интерном не отделаешься. А вот остальных надо будет найти в логове. Она открыла календарь и стала расчищать расписание. Когда офис заполнился людьми, шумом и дежурными шутками, она вспомнила про кофе. Он был уже холодный, отсрочить неизбежный визит к интернам не получалось. Лида взяла свои заметки к встрече и пошла к лифту.
На двери логова висела нарисованная на миллиметровке рожа Шрека с указанием конструкторских размеров. Лида увидела на скетче пару ошибок с размерами и допусками, хмыкнула и уверенно вошла в комнату. Стоявший там гвалт моментально стих, парни и девушки оторвались от телефонов и планшетов, взглянули на нее и вернулись к своим делам. Из угла сильно дул кондиционер, у Лида появилось ощущение, что она пришла в ситуационный центр ЦОДа. "Кто нарисовал Шрека?" - сказала она громко. Все опять оглянулись на нее, но больше никак не отреагировали. Лида подошла к самому крупному, обошла его вокруг и стала за его спиной. Он пару секунд терпел, но не выдержал и повернулся к ней. Лида довольно улыбнулась про себя, опыт корпоративных разборок у нее был немалый и как ставить людей на место она знала. Парень только что сделал шаг навстречу послушанию, сам того не понимая. Новичок еще, вырастет и эти трюки на него действовать не будут. "И? - спросила она его с небольшим нажимом. - Говорить сегодня будем или ты по программе обмена из Пакистана приехал и так быстро не говоришь?" Лида играла рискованно, если бы HR узнали, ей пришлось бы проходить курс толерантности или чего-то еще, но она чувствовала аудиторию и считала, что вряд ли эти бунтари ее сдадут. "Августа это", - буркнул он и ткнул локтем в сторону эстонки в светлом свитере с зеленым бейджем на широкой ленте. "Так, народ! - крикнула по весь голос Лида, да так, что все примолкли. - Августа не знает GD&T, на Шреке 3 ошибки с допусками и размерами. Ей надо помочь. А мне на проект нужны инженеры, которые умеют либо работать без ошибок, либо выдерживать мою критику. Есть тут такие?" Ага, парочка даже убрала телефоны в карман штанов, значит, раппорт установлен. Можно начать разговор. "Меня зовут Лида, я системный инженер 5 грейда и руководитель проекта по строительству небольшого автосборочного производства из машинокомплектов в программе Global Micron. В производственном плане есть 30 недель на то, чтобы выпустить 3,000 автомобилей, 250 из них в дорогой комплектации, 750 в средней комплектации с поставкой на местный рынок. Я плачу вашу ставку плюс 20%, премия по результатам проекта. За каждую неделю в проекте вы получите 25 баллов к своей корпоративной карме, +750 за весь проект". Она специально ничего не стала говорить про расположение, чтобы проверить, заинтересовался кто-нибудь или нет. "Где завод находится?" "Не завод, это будет одна производственная линия для выпуска ограниченной серии под локальный спрос. Технопарк G15". "Далеко". "Что значит далеко? 50 км за городом, 10 минут пешком от станции С-бана или 30 минут на машине". "Компенсация бензина будет?" "Это значит, вы согласны? Тогда присылайте резюме сюда, - и Лида выложила три свои визитки на стол. - Заявления принимаю до вторника". И вышла в почти полной тишине, только пара людей перешептывались в углу. Теперь ей предстоял нелегкий разговор с главным технологом, и она решила, что надо успокоиться, давить на опытного менеджера так же, как на интернов, у нее вряд ли бы получилось. В кафе она подсела к Глебу, он был опытный проектный менеджер, недавно его назначили заместителем небольшой программы Шарп. Через 4 года, если он не налажает, он сможет возглавить программу. В любом случае дружеский совет ей бы не помешал.
Из-за столика она вставала уже больше уверенной в своих силах, ничего вроде бы сложного в управлении этим проектом не намечалось. Тем сильнее по ней ударил отказ Клауса: "Я тебе еще раз говорю — вот моя роспись ресурсов. Могу выделить производственного технолога через два месяца и то, если подашь заявку прямо сейчас с повышенным коэффициентом". Она ушла на свое место как по подушкам. Но делать нечего, придется разбираться самой, спрашивать совета на форумах, нанимать консультантов. Она поморщилась, потому что корпоративные политики делали все эти вещи очень трудозатратными. В этих мыслях и заботах она просидела до обеда,, пока ее станция не не заблокировалась. Всплыла предупреждающая надпись: "Ваши рабочие часы окончены, вы должны покинуть территорию в течение 20 минут", Лида собрала сумку, и поехала домой.

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


Контрольные вопросы:
Как бы вы провели бизнес-анализ ситуации?
В чем проблема и какой у нее контекст?
Какая система является целевой для Лиды?
Нарисуйте модель жизненного цикла целевой системы и укажите место возникновения проблемы.
Какие элементы системы канбан есть на этом заводе?

Проблема запуска проектов.
Постановка проблемы
Системная инженерия
Чем занимаются системные инженеры
Управление программами
Модель жизненного цикла

воскресенье, 10 марта 2019 г.

Архитектура предприятия в тумане войны

Война — область недостоверного: три четверти того, на чём строится действие на войне, лежит в тумане неизвестности, и следовательно, чтобы вскрыть истину, требуется прежде всего тонкий, гибкий, проницательный ум… Недостоверность известий и постоянное вмешательство случайности приводят к тому, что воюющий в действительности сталкивается с совершенно иным положением вещей, чем ожидал; это не может не отражаться на его плане или по крайней мере на тех представлениях об обстановке, которые легли в основу этого плана. Если влияние новых данных настолько сильно, что решительно отменяет все принятые предположения, то на место последних должны выступить другие, но для этого обычно не хватает данных, так как в потоке деятельности события обгоняют решение и не дают времени не только зрело обдумать новое положение, но даже хорошенько оглядеться. Впрочем, гораздо чаще исправление наших представлений об обстановке и ознакомление с встретившейся случайностью оказываются недостаточными, чтобы вовсе опрокинуть наши намерения, но могут все же их поколебать. Знакомство с обстановкой растёт, но наша неуверенность не уменьшается, а напротив — увеличивается. Причина этого заключается в том, что необходимые сведения получаются не сразу, а постепенно. Наши решения непрерывно подвергаются натиску новых данных, и наш дух всё время должен оставаться во всеоружии.
Клаузевиц К. Глава 3 // «О войне». — М.: Госвоениздат, 1934.
https://ru.wikipedia.org/wiki/Туман_войны


Текущий технологический и ИТ-ландшафт предприятий стал результатом ряда обоснованных в каждый конкретный момент решений. Но ваша текущая ситуация с данными, процессами обмена и обработки, их связями с ежедневной реальностью бизнеса и идущих проектов не ясна никому. Время от времени приходят консультанты и рисуют:
- прекрасные иерархичные карты бизнес процессов,
- модели архитектуры предприятия, информационной архитектуры или схемы озер данных и отчетности с красивым будущим,
- диаграммы сетей искусственного интеллекта, который найдет порядок и подскажет как заработать денег там, где теряются даже ветераны с 20-летним опытом.
Да, кликбейты работают даже на топ-менеджеров и собственников, всем хочется простоты и стройной понятной картины мира. В реальности ландшафт бизнеса покрыт туманом войны, а ИТ-ландшафт лишь моделирует то, что происходит в реальности. Поэтому ИТ-ландшафт - это туман войны бизнеса, который перерисован программистами со слов бизнес-аналитиков. И красивые архитектуры предприятия по TOGAF, которые объясняют как у вас будет работать предприятие и как будут автоматизированы процессы после цифровой трансформации попросту нереалистичны и вот почему. Схемы и диаграммы вообще подразумевают логику. Компьютер в логике намного сильнее, чем человек, например, он выигрывает в шахматы, го, покер и вообще почти везде, где есть правила и считаются последствия. Но как он выигрывает? Даже самый мощный компьютер не высчитывает конечную ситуацию, с которой он завершит победную партию. Он просто каждый ход улучшает текущую ситуацию. То есть даже компьютер с его безграничными по сравнению с человеком возможностями по логике не может применить TOGAF даже в идеальном мире с известными правилами, открытой доской, в которую играют два игрока. В реальном бизнесе доска закрыта, игроков сотни, все ходят одновременно, правила гораздо сложнее, фигур и возможностей для хода намного больше. Шансов на то, чтобы просчитать ситуацию TO BE и составить выполнимый план трансформации нет никаких.
Но военные успешно решают подобные проблемы. Вопрос как они это делают и можно ли перенять их методы для ведения бизнеса? Gerben Wierda в своей книге Chess and the Art of Enterprise Architecture описал свой опыт применения практики моделирования архитектуры предприятия, а кейс цифровой трансформации Intel показал, что этот опыт можно перенести в другую компанию и применить его там.

Как надо адаптировать практику архитектуры предприятия для работы в условиях тумана войны?
1. Не планировать дальше, чем на 3 шага вперед,
2. Показывать на одной карте стратегический, тактический и оперативный уровень одновременно,
3. Иметь на карте как можно более точную обстановку.

Краткосрочное планирование при долгосрочном замысле
Реалистичные планы всегда рассчитаны на короткий срок, но как тогда  достичь долгосрочной согласованности, ведь без объединяющих принципов и указаний все разбредутся в разные стороны?
Долгосрочная согласованность достигается за счет того, что планы опираются на неизменные элементы ИТ-ландшафта и боевой приказ. Дело в том, что некоторые ИТ-системы после того, как их ввели в эксплуатацию, служат по 15 лет. Стратегия компании меняется каждые 1,5-2 года, поэтому хранилище данных переживает много стратегических циклов, оно задает вам надежную основу для планирования. Это означает, что вам надо иметь точные описания таких почти неизменных частей вашего ИТ-ландшафта. 
С принципом боевого приказа все немного сложнее. Люди, не знакомые с концепцией маневренной войны, часто думают, что боевой приказ указывает подразделению что делать, когда это делать, какими силами решать задачу, и каким замыслом операции надо руководствоваться. Это кажется довольно логичным, но боевые приказы работают ровно наоборот. Боевой приказ определяет намерение командования, замысел операции. Он не сильно ограничивает способ исполнения замысла. Замысел всегда больше, чем результат конкретной битвы. Приказ сообщает почему операция производится, но не как или что надо сделать. Морпехи считают, что без боевого приказа указания неполны, т.к. вы не можете понять, зачем их отдают. Когда намерение ясно, вы можете выбрать средства и способы исполнения задачи. Намерение командования устойчиво и не подвержено постоянным изменениям, в отличие от текущих планов.
Так и миссия проекта должна четко указывать почему выполняется проект, описывает его общее конечное состояние, но не диктует, как и что надо в нем сделать.
Подробно этот принцип описан в D8: Принцип боевого приказа: укажите конечное состояние, его назначение и минимально возможные ограничения. 

Военные принимают решения коллективным обсуждением за одной картой
Что больше всего меня удивляло в принятии бизнес-решений, так это то, что каждый руководитель смотрит в свои отчеты и принимает решения по ним. Директора по логистике не интересует ситуация в коммерческой дирекции, а продуктовиков не волнует отчетность Helpdesk. Военные понимают, что логистика, снабжение, операции и разведка должны действовать совместно, иначе успеха им не видать. И на этой карте надо понимать общий меняющийся контекст, текущее расположение, направления движения и динамику элементов, и их взаимодействие. Такое понимание называется ситуационной осведомленностью https://en.wikipedia.org/wiki/Situation_awareness
Модель архитектуры предприятия должна связывать модели деятельности, организации, технологий,  инструментов и проектов перехода в единую связную карту. Эта карта должна храниться в общем хранилище,  быть доступной для каждого и по ней должны приниматься решения, которые будут учитывать текущую реальность и координировать планы различных игроков.

Чтобы эта карта была полезной, она должна быть актуальной, устаревшие данные никому не нужны
Как военные обеспечивают актуальность своих карт? Очень просто - разведданные поступают от всех и наносятся на карту штабом. Также и модель архитектуры предприятия должна создаваться всеми, а отдел архитекторов только обеспечивает ее целостность, непротиворечивость, обучает людей пользоваться моделью и постоянно улучшает процессы ее ведения.
Нотация модели архитектуры предприятия не сложнее нотаций военных карт, ей может научиться каждый. В серии дальнейших постов "Кригшпиль" я на примере симуляции запуска автомобильного производства буду показывать, как картировать реальность и использовать получившиеся карты для принятия решений. 
Архитектура предприятия, ориентированная на принятие решений, должна заменить классические тяжеловесные и далекие от реальности подходы.

среда, 6 марта 2019 г.

Руководство по разработке 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:
В ходе этого же исследования вы нашли подходящую модель жизненного цикла:
Ее вы тоже оформили как диаграмму 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 контракте
Проверка полноты поставки продукта проекта с учетом всех произведенных и корректно одобренных изменений
Проверка того, что предметы поставки произведены в соответствии с согласованными спецификациями и корректно переданы заказчику
Прогнозирование экономических выгод реализации проекта и организация проверки корректности прогнозов по мере появления свидетельств и доказательств
Корректное закрытие всех проектных фаз, освобождение ресурсов, организация оценки людей и команд

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