Comments 20
Эх, статья по сути похожа на призыв за-всё-хорошее-и-против-всего-плохого!
Например, на хабре была переводная статья про разработку космических ракет в США.
Полвека назад разработали, создали, запустили.
Наши дни: команда хочет повторить, документация вся есть. Пытаются сделать согласно документации - нереализуемо. Вот даже сделать не могут. Находят оригиналы (осталось штук 5 ракет в музеях и на складах), прикладывают одно к другому - не совпадает.
Реальные конструкции не совпадают с документацией.
Разные реальные конструкции не совпадают между собой.
...
В общем, чтиво интересное. Но если переводить на тему Вашей статьи, то выкристаллизовывается пара вариантов:
повторный запуск проекта/производства должен проводиться как новый проект, "с нуля". Это вывод американских ракетчиков;
повторные запуски проекта/производства должны производиться достаточно часто. Команда проекта при этом должна постепенно обновляться: между запусками немного инженеров уходит, немного приходит. Полной смены команды нет - и тогда есть шанс, что это будет работать. В качестве примера можно вспомнить программные продукты "на десятилетия" (например, Microsoft Windows 95/98/2000/NT/XP/Vista/7/10/11).
Вариант "а давайте всех разгоним, пройдёт время, и потом соберём новичков" (по-моему) работать не будет от слова совсем.
Похоже на то. Core команда, которая определяет правила. С управляемым процессом "выбытия" и "прибытия".
Хотя обеспечить такой процесс очень сложно... точнее даже очень долго.
Нужно строить команду несколько лет не позволив себе облажаться (обанкротиться, потерять лицо и тд).
Эх, статья по сути похожа на призыв за-всё-хорошее-и-против-всего-плохого!
С первого взгляда да, со второго - можно использовать как готовый шаблон обоснования сдвигов сроков, найма, привлечения аутсорса. Потому что такая "боль" есть везде в разных масштабах. Не факт что сработает на результат, но по крайней мере даст репутацию человека умеющего в бизнес-логику.
Чтоб осознать полноту документации в смысле статьи заказчику надо иметь у себя людей, способных эту документацию прочитать. Ну то есть зачем тогда подрядчик? :)
Подрядчик делает работу. Заказчик должен уметь её принять — это разные вещи. Если внутри нет людей, способных прочитать документацию и понять, что именно передано, заказчик не контролирует проект, а просто доверяет на слово. Если этого внутреннего контура нет, получается обратная история: заказчик платит не только за работу, но и незаметно покупает зависимость. Завтра захочет сменить подрядчика — а не сможет, потому что никто, кроме той команды, не понимает, как всё устроено.
(del)
Нехилая статья (забесплатно). Риспетч!
ЗЫ: как владелец процесса в данный момент устраняю зихера прошлых лет от прошлых владельцев процессов, работавших в парадигме "наотыбись -- итаксойдёт"))
При всем уважении к автору все что написано в статье это изобретение очередного велосипеда и попытка "натянуть сову на глобус" - использовать для решения проблем априори неэффективные решения без внятной теоретического обоснования.
Это ни в коей мере не критика лично автора, а критика ставшего повсеместным подхода современного российского промышленного менеджмента, заключающегося в упорном применении бессистемных, заплаточных решений в ручном авральном режиме при полном нежелании систематизировать работу, разбираться с причинами существующих проблем, изучать основы построения промышленных систем и организовывать их работу на рациональной научной основе.
Очень надеюсь, что мой комментарий, несмотря на его "колючесть" будет правильно воспринят и полезен автору и прочим коллегам, которые его прочитают.
Итак.
Во-первых - вместо того, чтобы плодить новые понятия типа "След решения" и
"Инженерная память", автору стоит изучить ГОСТ Р 21.101 и ГОСТ Р 2.503 (и/или иностранные аналоги) и стандарт PMBOK. В этих документах разработаны все необходимые понятия и все необходимые методические подходы для того, чтобы не путаться в понятиях, не путались окружающие, подчиненные, бизнес-партнеры и не происходило тех бед, о которых пишет автор.
Дополнительно западными инжиниринговыми компаниями давным-давно были разработаны процедуры TQ (technical question) и TD (technical deviation), которые детализируют и переводят в прикладную плоскость процессы управления изменениями, содержанием и стоимостью, а также используются в процессах закрытия проектов, описанные в стандарте PMBOK.
Эти процедуры, правда с подливкой из "россиянскоманегерского", значительно ухудшающей возможности данных практик используют в своих крупных проектах практически все российские гиганты - Газпром, СИБУР, ЕВРАЗ и т.д.
Автор пишет что "договоров и информационных требований недостаточно" а "формализация не закрывает весь риск", но забывает уточнить: "в россии"...
Автор "забывает" уточнить или не знает, что так происходит потому, что вместо того, чтобы использовать стандартизированные формы договоров (типо JTC или еще лучше - FIDIC), имеющие кроме понятной структуры и понятного разделения ответственности еще и кучу стандартных механизмов урегулирования, российские компании, при заключении договоров "в срок вчера" создают нестабильную солянку из российских и зарубежных договорных норм, а вместо детальных и стандартизованных ТЗ, основанных на стандартизированных требованиях также впопыхах пишется что-то похоже-дырявое из неопределенных фразы типо "технические решения должны быть современными и энергоэффективными".
Естественно такая "формализация" не решает проблем просто потому, что это в принципе не формализация, а ее видимость.
И это не случайность, а закономерный результат того, что менеджмент всеми силами избегает прозрачности
Именно по этому теряется история и инженерная память, договор, при реализации проекта превращается из удобного инструмента управления в рудиментарный ворох ненужной бумаги, по которому невозможно работать, а коммуникации превращаются в "базар по понятиям"... а в результате - гигантские финансовые потери.
Автор, очевидно, в угоду к-то пишет - "Цель владельца — не добиться полного отсутствия временных решений. На сложном проекте это нереалистично. Цель другая: не должно быть невидимых временных решений".
Но это старый и бородатый баян, родом из давным давно устаревших и вышедших из употребления подходов западного менеджмента, возродившийся, как феникс на благодатной "почве" российского менеджмента 90х-2000х.
Давным давно крупные европейские и японские инжиниринговые компании поняли, что когда дело касается серийного и сложного оборудования, а особенно крупнотоннажного промышленного производства, к которым относятся и реализация промышленных проектов финансовые результаты псевдогибкости ни в какое сравнение не идут с теми финансовыми потерями, которе несут временные, бессистемные, стохастические решения. Если посмотрите на работу иностранных инженеров на строительных площадках то увидите, что 90 и более процентов их работы это выполнение стандартизироаанных и унифицированных операций строго по регламентам и чек листам и никак иначе.
Именно такая стандартизация и унификация позволяет иностранному инжинирингу обеспечить очень глубокую автоматизацию процессов в проектах, при чем не только внутри одной компании, а между компаниями, интегрируя ПО взаимодействующих компаний между собой.
Именно так появился и развивается подход ERP 2 (на Хабре, кстати, есть хорошая статья про то, что такое ERP 2) и именно такой подход позволяет иностранцам получать огромную финансовую выгоду от реализации проектов в ЕРС формате.
Именно совокупность этих подходов обеспечивает зарубежному инжинирингу маржинальность, которая ни в какое сравнение не идёт с теми выгодами, которые дают все легальные и нелегальные способы извлечения прибыли на российских проектах.
Более 10и лет назад американский институт строительной отрасли отчитался о том, что ЕРС формат позволяет сократить себестоимость и сроки на 10-15%, сократить оборотные средства, число изменений, складские площади и численность руководителей
А вот в России результатом промышленного управления принципиально иной.
Ежегодные потери существующего промышленного управления - порядка 13 триллионов рублей, из которых 2.5 триллионов сумма, которую ежегодно недополучает государственный бюджет в виде налогов.
Дополнительно - медленный, но стабильный рост промышленной аварийности - за десять лет сумма ущерба - порядка 0.4 триллиона рублей, по данным МЧС, которые к слову очень "избирательно" подходят к оценке ущерба, дабы, вероятно "не нагнетать", в лучших государственных традициях (примерно такая сумма была выделена в 2022 на развитие науки).
А еще стабильное старение основных средств...
И как "вишенка на торте" - тот факт, что среднее удорожание проектов в РФ составляет более 50%, а 83.5% проектов подорожали более чем на 10%...
Из этого вывод: ИЗУЧАЙТЕ И ПРИМЕНЯЙТЕ СТАНДАРТЫ...
Как при построении бизнес-процессов, так и при их дальнейшей автоматизации при внутри- и межорганизационном взаимодействии.
И будет вам благо и прибыль будете получать на земле и будет она больше, чем у всех ваших конкурентов)))
Спасибо, что прочитали так внимательно. Колючесть — это нормально, предметный спор полезнее вежливых кивков.
Про стандарты спорить не буду, потому что не с чем: ГОСТы, ISO 19650 и 15926, TQ/TD — это то, чем мы работаем каждый день, никакого открытия тут нет. Статья про другой слой: не чем заменить стандарты, а куда девается понимание, почему сделано именно так, когда проект сдан, команда разошлась, а объект ещё живёт. Грубо говоря, ПДД у всех одни, а ездят все по-разному — и разбираться приходится именно с ездой.
Про масштаб потерь по отрасли во многом соглашусь, но это тема для отдельного большого текста, а не для ветки комментариев. Ещё раз спасибо за время.
Тогда все равно не понятно "зачем козе баян"...
Возьмем ГОСТ Р 21.101.
Если проектировщик вносит изменение он должен на чертеже или в тексте выделить изменение (как - детально описывается ГОСТом), измененному участку присвоить номер, отразить количество измененных участков на листе, изменить N ревизии и перевыпустить комплект, дозаполнив, для перевыпускаемого комплекта документов, Таблицу регистрации изменений (Приложение Н). Одновременно проектировщик указывает в штампе номер Разрешения на внесение изменений, подписывает измененный документ и согласовывает его с нач.профильного отдела (нач отдела подписывает этот документ).
При перевыпуске комплекта документов в новой ревизии ГИП одновременно с подписанием изменённый ревизии (это как минимум уже третья подпись при внесении изменений) должен подписать и присвоить номер оформленному и подписанному проектировщиком (начальником профильного отдела) документу который называется "Разрешение на внесение изменений" (Приложение Л), в котором для каждого измененного участка в каждом из комплектов указывается код причины изменения (усовершенствование, изменение стандартов, доп.требование, кстранение ошибки) и основания для изменения (письмо заказчика, приказ, раздел проекта или расчет и т.д.), указываются документы, которые довыпускаются и прочие сведения.
Одновременно в проекте должен вестись Журнал изменений.
Таблица регистрации изменений, Разрешение и Журнал изменений имеют перекресные ссылки друг на друга (т.е. по факту являются сложносоставной таблицей, разбитой для удобства на 3 документа), а офиц.переписка, на которую ссылается Разрешение должна архивироваться т.е. при оформлении Разрешения ставится ссылка на наиментюование, номер и дату письма/трансмиттала/протокола совещения, под которым письмо/трансмиттал/пртокол совещания (или серия писем/протоколов по теме), которыми закреплено то или иное техническое решение зарегистрированы в СЭД и размещены в архиве.
То как надо вести архивы писем и протоколов, чтобы ничего не теоюрялось и оьеспечивалась отслеживаемость прописано в ГОСТ по Архивному делу.
ИТОГО - я вообще не вижу проблем с поиском истории, если документы движутся по ГОСТ...
По номеру измененного участка "проваливаемся" в Разрешение и в Журнал, там написана причина. Если нужна более подробная история по номеру письма/трансмиттала/протокола указанному в Разрешении "проваливаемся" в эл.архив, в котором письма и протоколы также сгруппированы и читаем почему сделано так, а не иначе.
Все описанное элементарно реализуется с помощью интеграции PDM системы со своей СОД и электронным архивом с СЭД... как в документоуентричной философии, так и для датоцентричной философии.
Просто при построении IT инфраструктуры и при реализации проекта надо не умничать и не вести себя как хреновый хирург "это херня, херню не лечим", а выполняй ГОСТ, а в идеале строить их так, чтобы не выполнить ГОСТ было невозможно. Это IT тоже позволяет)))
...я имею ввиду функцию "заморозки" документа и/или можели до получения Задания и/или оформления необходимых документов по ГОСТ
Вот теперь мы добрались до сути расхождения, и это хорошо.
С регистрацией изменений по 21.101 никто не спорит — механизм рабочий, и там, где он честно ведётся, история выпущенной документации прослеживается. Но весь этот аппарат включается, когда изменение уже дошло до бумаги: поправили чертёж, переписали абзац в пояснительной записке, передвинули позицию на схеме — и всё это оформили. Статья же про то, что происходит раньше, до всякой регистрации: сегодня первоисточник — информационная модель, и чертёж, и схема, и записка выпускаются из неё как производные. И вопрос не в том, как зарегистрировать изменение листа, а в том, под чьим контролем сами данные модели — атрибуты, связи, версии — и откуда они вообще берутся. По сути, регистрация работает уже со следствием. Статья — про причину.
Так что ГОСТ мы с вами читаем одинаково, расходимся только в том, к какому слою его прикладывать. Спасибо за обстоятельный разбор
Суть и вся прелеть в том, что механизм описанный в ГОСТ может одинаково применяться и для бумаги, и для 2х мерных документов, и для 3х мерных.
До эры ПК для получение чертежа нужно было оформить Разрешение пойти в архив, взять чертеж, сделать светокопию, отдать чертеж в архив, на светокопию внести изменения, проставить в штампе на ней номер изменения, внести запись в Журнал изменений и в Перечень, подписать все у ГИПа выпустить документы и сдать новую рев. в архив.
Точно также только проще, если у вас развернуты СЭД, PDM система с СОД. ГИП выдает задание, на его основе предоставляется доступ для возможности создания новой ревизии файла на основании ранеевыпущенного, на основании Разрешения дается доступ для редактирования нового файла-копии. 2х мерный чертеж и все сопутствующие документы вообще могут формироваться автоматом на основании Задания ГИП. Как доп бонус - систему с бумагой можно "обойти", а вот IT систему можно сконфигурировать так, чтобы в принципе возможность потрерять историю стала возможной только в случае скоординированной мощной диверсии)))
Тут надо только хорошо понимать ограничения той или иной СЭД, СОД, применяемой PDM системы и ПО/группы ПО которое у вас применяется для трехмерного моделирования, детально прописать алгоритмы работы, обеспечить интеграцию этих систем между собой, корректно настроить права доступа и пользовательские роли, в соответствии с этими алгоритмами и работать.
Некоторые СОД, PDM системы и ПО для трехмерного моделирования (особенно если систему собирали без прицела на цельную архитектуру непонимая особенности организации ТДО в проекте) не вполне корректно друг с другом "дружат", быват возникают ограничения, которые впрямую не позволяет реализовать ГОСТовский механизм, но мы с IT специалистами всегда придумывали как обойти тот или иной недостаток.
По моему опыту реальные проблемы возникают только тогда, когда при совершаются очень критичные ошибк а архитектуре, которые в 99.9% случаев связаны с тем, что люди, которые их строят в принципе не учитывают необходимости выполнения требований ГОСТ и прочих НТД и в принципе не занимаются IT архитектурой и интеграций IT систем между собой.
Было бы интересно, конечно, на каком ПО вы свою IT систему собрали, что у вас не получилось реализовать ГОСТовский механизм, интересно было бы как и с помощь каких возможностей вы его реализовывали, какие фичи каких систем стали критичным ограничением и какие были предложения по обходу, но об этом в статье ничего нет)))
Всё, что вы описываете — задание ГИПа, разрешение, доступ к новой ревизии на основании ранее выпущенной — начинает работать после того, как документация выпущена и утверждена, а участок модели заблокирован. Этот порядок я не трогаю, он нужен. Но статья про другой отрезок — до первого утверждённого выпуска. Проектировщик ведёт модель в своём рабочем контуре — задания, статусы, проверки там есть, но для Разрешения в классическом смысле ещё нет выпущенной ревизии, к которой его можно привязать. А главные решения принимаются именно здесь: чем наполняются данные, как увязываются атрибуты и связи, почему модель дошла до выпуска именно такой. И оговорюсь про термины: речь у нас о промышленных капитальных объектах — заводах, установках. Грубо говоря, рабочий контур там — программы, в которых создаётся модель, плюс СОД, а выпуск и согласования — в документообороте. И какой инструмент ни возьми, версии отвечают на вопрос "что было", а не "почему так сделали".
Так что говорим мы про разные отрезки жизни проекта: вы — про то, что после утверждённого выпуска, я — про то, что до него. Оба отрезка нужно держать под контролем, просто инструменты у них разные.
Мы с вами говорим про одно и то же - про промышленный проект.
Вне зависимости от стадии проектирование строится однотипно. Единственное что меняется в случае внесения изменений после выпуска - доп.документы.
Вы пишете что основные решения и то, "чем наполняются данные, как увязываются атрибуты и связи" принимаются на стадии разработки.
И пишете, что у вас контур разработки и контур выпуска разорваны (разработка в спец ПО, а выпуск - в ДО).
Для абсолютного большинства РОССИЙСКИХ проектов это так. Вы правы. В России эти решения действительно принимаются стохастически в ручном режиме по ходу проекта так как взбредет в голову исполнителю, конкретному руководителю, ГИПу или проектной группе (причём я видел когда у разных групп разрабатывающих один раздел все было разным - тех решения и подход к данным).
Мой основной месидж и т.с. основная причина по которой я, как может показаться, "прикопался" - в том, что именно этот подход и является ненормальным.
Именно это является коренным отличием российских проектировщиков от иностранного ижиниринга. И именно это является основной причиной низкого качества российских проектов, ошибок, последующей неразберихи и в конечном счете причиной срыва сроков и потери денег.
Но в статье про это ничего нет.
Опять, же для истребления зла, о котором вы пишете и с которым в РФ все, как ежики жрущие кактус, живут из проекта в проект, давным-давно изобретены решения - стандартизация, унификация, типовые маршруты, шаблоны, стандартные политики доступа и
файлов и самое - главное интеграция ПО между собой. При таком подходе все процессы разработки от ТЗ до Базового проекта, от Базового проекта до рабочего и от Рабочего до asBuild, включая выпуск смет и договорная работа - интегрированы между собой.
А доступ, наполнение и форматы передачи данных (между отделами, подразделениями и компаниями), увязка атрибутов, стандартизированы и при разработке принимаются по строгим правилам (прекрасный пример этого то, как интегрированы данные в семействе AVEVA).
В этом случае, строго говоря, вообще нет значения разрарабатывается проект во внешнем или во внутреннем контуре, это может быть семейство интегрированного ПО разработанного 1 компанией (как AVEVA), а может быть и по-другому - интегрированное между собой ПО различных разработчиков.
Но опять же про этот, действительно интересный момент, ничего в статье нет и ничего нет про то как и с помощью каких инструментов этого можно добиться)
Смотрите, по сути проблемы мы уже не расходимся — вы её сейчас описали даже жёстче, чем я в статье. Вопрос остался один: с чего начинать. Вы говорите — со стандартизации, типовых маршрутов, интеграции ПО. Всё так, работает. И роли с ответственностью в зрелых методологиях тоже прописаны. Но живут эти роли, пока идёт проект. А статья про то, что дальше: у кого остаётся логика решений, когда работы закончены и люди разошлись.
И здесь расскажу случай из практики, без имён. Нас пригласили на поддержку проекта после того, как с него в один момент ушёл крупный зарубежный подрядчик — из тех самых, с эталонными процессами, работавший на стеке Hexagon. Нам передали всё: среду, модели, документацию, базы. Формально комплект полный. Но часть решений читалась только по результату: сделано так, а почему — из переданного не восстановить; например, какие-то атрибуты появлялись в спецификациях после постобработок, которые никто уже не мог объяснить. Пример тем и показателен: зрелые процессы и хороший стек сами по себе не гарантируют, что логика решений переживёт уход команды.
А то, чего вы не находите в статье — как стандартизировать процессы, как строить интеграцию, какими инструментами, — это методика внедрения. В статью про то, кто должен владеть инженерной памятью, она не помещается по жанру, потому её там и нет
Конечно, без автоматизаци этот ГОСТовский механизм кажется громоздким, сложным и не удобным, даже если чертить на ПК, а раз так, то это дополнительные затраты и штат... Проектировщику не выгодно. Проектному офису заказчика в моменте не выгодно. Понятно поэтому что российские манагеры этот механизм очень долго пытались обойти. В итоге обошли, сделав ГОСТ не обязательным и не включая в ТЗ обязательность его выполнения и в итоге, как вы правильно пишете, что подтверждают и комментаии - затраты незаметно из CAPEX перетекли в OPEX.
НО опять же, повторюсь, эта "громоздкость" ГОСТа только кажущаяся, т.к. современные инструменты позволяют значительно сократить количество ручных операций при выполнении этого механизма
это всё теория а на практике например, есть исходники прошивки устройства, разработанные 25 лет назад, только на ПО которое если и найти, то на современных компьютерах не работает, а там еще и библиотеки были, но перед компиляцией поменяли дэфайны.
в логике работы разобраться невозможно, слишком много костылей в коде.
В вашем примере, по сути, две разные беды, и обе по теме статьи.
Первая — подмена дефайн перед компиляцией и костыли без пояснений: почему сделали именно так, уже не видно. Это ровно про потерю логики решения.
Вторая — умершая среда: исходники есть, но собрать их уже не на чем. На первый взгляд это выглядит как возражение: какой смысл хранить файлы, если среда всё равно устареет? Но для меня это скорее аргумент в пользу инженерной памяти.
Файлы могут лежать на сервере десятилетиями сами по себе. Среда так не живёт: её нужно сопровождать, переносить на новые инструменты, фиксировать библиотеки, параметры сборки и критичные настройки. Судя по описанию, никто вовремя не пересадил код и окружение в живую среду — поэтому вместо сопровождения началась археология, которая иногда обходится дороже, чем разработка заново.
В статье я как раз об этом пишу: инженерная память — это не папка на сервере, а живой контур с владельцем, который ведёт и данные, и среду через смену инструментов и команд. Спасибо за пример — считайте, что дописали к статье ещё один кейс.
Согласен. Поэтому за границей вся сфера пром. строительства, разработки технологий, IT, технической и контрактной стандартизации это огромная индустрия, которая финансируется промышленными гигантами и "независимость" которой только кажущаяся.
А в России изолированные компании и IT подразделения пытаются решить эту задачу почти изолированно.
Попробуй разобраться...
Потеря инженерной памяти объекта