От объекта к системе

Глава 6. Изменение — это процесс

6.1. Изменение не происходит само

В предыдущих главах мы установили важное различие. Revision изменяет описание объекта. Она не изменяет сам объект.

Но тогда возникает следующий вопрос. Если изменение описания не является просто созданием новой Revision, что представляет собой само изменение?

На практике инженер говорит: «Нужно изменить конструкцию».

Но за этой короткой фразой скрывается целый процесс.

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

Изменение — это не момент появления новой Revision.

Изменение — это управляемый процесс, результатом которого становится новое состояние управляемой информации.

6.2. Как выглядит изменение без процесса

Представим простой сценарий. Конструктор открыл чертёж насоса Н1. Нашёл отверстие, которое нужно увеличить с 10 до 12 мм. Изменил значение. Сохранил файл. Файл теперь содержит новое значение.

Но произошло ли управляемое изменение?

Мы не знаем. Неизвестно:

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

Технически данные изменились. Инженерно управление изменением ещё не произошло.

Именно поэтому зрелая инженерная практика отделяет изменение данных от управления изменением.

6.3. Что говорит промышленная практика

Эта идея не является особенностью конкретной PLM-системы. Она формализована в стандартах управления конфигурацией.

MIL-HDBK-61A определяет управление конфигурацией как процесс поддержания соответствия характеристик изделия требованиям, конструкции и эксплуатационной информации на протяжении жизненного цикла.

Ключевое здесь — соответствие.

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

MIL-HDBK-61A также вводит понятие Engineering Change Proposal — предложения об инженерном изменении:

An ECP is a formal request to change the configuration of a CI. It shall include a description of the proposed change, the reason for the change, and an assessment of the impact on affected CIs.

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

6.4. ISO 10007: изменение как отдельный процесс

ISO 10007:2017 Quality management — Guidelines for configuration management определяет пять процессов управления конфигурацией:

Configuration management comprises:

• configuration management planning;
• configuration identification;
• configuration change management;
• configuration status accounting;
• and configuration audit.

Среди них отдельно выделено configuration change management — управление изменениями конфигурации.

Это принципиально.

Изменение не является побочным эффектом управления версиями. Оно является самостоятельным процессом управления конфигурацией.

ГОСТ Р ИСО 10007-2019 сохраняет ту же структуру.

Revision появляется внутри этого процесса как результат изменения описания.

6.5. ЕСКД: отечественная формализация изменения

Отечественная инженерная практика формализует управление изменениями через систему стандартов ЕСКД и ЕСТД.

Центральным документом является ГОСТ Р 2.503-2023 «Единая система конструкторской документации. Правила внесения изменений». Стандарт устанавливает, что изменение в конструкторскую документацию вносится на основании извещения об изменении. ГОСТ Р 2.504-2021 дополняет его в части внесения изменений в электронную конструкторскую документацию.

Извещение содержит сведения, необходимые для внесения изменения, включая:

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

Изменение не сводится к записи:

Revision A → Revision B

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

6.6. Что общего между стандартами

Если сопоставить CMII, EIA-649, NASA Systems Engineering Handbook, MIL-HDBK-61, ISO 10007 и ЕСКД, терминология различается, но структура процесса оказывается очень похожей.

Предложение об изменении
        ↓
Оценка влияния
        ↓
Утверждение / отклонение
        ↓
Реализация
        ↓
Верификация
        ↓
Учёт и отчётность

Названия различаются. Процесс один.

6.7. Почему недостаточно Revision

Теперь становится понятно, почему нельзя сделать Revision центром всей модели изменения.

Revision отвечает на вопрос: какое состояние описания зафиксировано?

Но Revision не отвечает сама по себе на вопросы: Почему возникла необходимость изменения? Кто предложил изменение? Какие последствия были оценены? Кто разрешил изменение? Когда оно вступило в действие? Какие изделия оно затрагивает? Как проверено его выполнение?

Если все эти сведения хранить внутри Revision, Revision превращается в контейнер для совершенно разных понятий.

Она начинает одновременно означать:

• состояние описания;
• предложение изменения;
• основание;
• решение;
• разрешение;
• результат реализации;
• историю процесса.

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

6.8. Baseline: относительно чего происходит изменение

Есть ещё один важный элемент процесса — baseline.

Невозможно управлять изменением, если неизвестно, относительно какого состояния оно выполняется.

ISO 10007 указывает:

Configuration baselines shall be established at appropriate points in the life cycle to provide a basis for change management.

Базовая конфигурация создаёт контролируемую точку отсчёта для последующих изменений.

NASA Systems Engineering Handbook формулирует ту же идею:

Baselines are established at key points in the life cycle to provide a controlled reference for subsequent changes.

В ЕСКД аналогичную роль выполняет утверждённый комплект документации, относительно которого оформляется последующее изменение.

Таким образом:

Baseline B1
     │
     ├── Change 1
     │
     ▼
Baseline B2
     │
     ├── Change 2
     │
     ▼
Baseline B3

Baseline отвечает на простой вопрос: относительно чего мы определяем изменение?

Без этой точки отсчёта невозможно однозначно определить, что именно изменилось.

6.9. Кто принимает решение

Изменение редко затрагивает только одну инженерную область.

Изменение диаметра отверстия может затронуть:

• конструкцию;
• технологию;
• производство;
• закупки;
• испытания;
• эксплуатацию;
• качество;
• уже изготовленные изделия.

Поэтому в практике управления конфигурацией решение об изменении принимается не просто автором изменения.

В CMII и EIA-649 используется Configuration Control Board — CCB.

В NASA также используется CCB, причём состав участников определяется характером изменения.

В MIL-HDBK-61 используется механизм Engineering Change Review Board.

ISO 10007 говорит о назначенном органе или лице, ответственном за управление изменениями.

В ЕСКД решение оформляется в установленном организацией порядке.

Название органа может различаться. Принцип один:

изменение должно быть оценено с учётом всех затронутых областей.

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

Поэтому изменение является междисциплинарным процессом.

6.10. Что должна хранить информационная система

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

Минимально необходимо иметь возможность восстановить:

• кто предложил изменение;
• когда оно было предложено;
• на каком основании;
• какие объекты затронуты;
• какие документы затронуты;
• кто проводил оценку;
• каковы результаты оценки;
• кто принял решение;
• когда решение принято;
• когда изменение введено;
• кто выполнил реализацию;
• кто подтвердил результат.

Это уже не одна Revision. Это цепочка связанных сущностей.

Объект
     │
     └── Описание
            │
            ├── Revision A
            │
            └── Revision B
                   ↑
                   │
                Change
                   │
                   ├── Proposal
                   ├── Impact Assessment
                   ├── Decision
                   ├── Implementation
                   └── Verification

Revision фиксирует состояние. Change связывает состояния и хранит историю решения, которое привело от одного состояния к другому.

6.11. Изменение может не привести к новой Revision

Это ещё одно важное следствие.

Не каждое действие, связанное с изменением, обязательно приводит к новой Revision.

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

Поэтому нельзя строить процесс вокруг предположения:

Change = новая Revision

Правильнее:

Change
   │
   ├── rejected
   ├── cancelled
   ├── deferred
   └── implemented
            │
            └── новая Revision

Revision является возможным результатом процесса изменения, но не самим процессом.

6.12. Изменение объекта и изменение его описания

Теперь можно связать эту главу с выводом Главы 4.

Изменение начинается одинаково:

Предложение изменения
        ↓
Оценка
        ↓
Что именно изменилось?

И здесь появляется принципиальный вопрос: изменилось описание существующего объекта или изменился сам объект?

Если объект остаётся тем же, изменение приводит к новой Revision его описания. Если изменение нарушает критерий, по которому объект считается тем же объектом, возникает новый объект.

Таким образом, процесс изменения не отменяет различия между объектом и описанием. Наоборот, он делает это различие практически необходимым.

                 Change
                   │
            ┌──────┴──────┐
            │             │
     тот же объект    новый объект
            │             │
      новая Revision   новый объект

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

6.13. Практический пример

Вернёмся к насосу Н1.

В Revision A отверстие имеет диаметр 10 мм. Инженер предлагает изменить его на 12 мм. Возникает Change C-1024.

Change C-1024
  Причина:
      изменение требований к креплению
  Затронуты:
      конструкторское описание
      технологический процесс
      спецификация
  Оценка:
      производство — допустимо
      технология — требуется изменение операции
      испытания — повторные испытания не требуются
  Решение:
      утверждено
  Реализация:
      Revision B
  Введение:
      с серийного изделия №250

В результате система хранит не просто:

Revision A → Revision B

Она хранит историю:

Почему появилась Revision B? → Change C-1024

Почему возник Change C-1024? → изменение требований

Кто оценивал? → конструктор + технолог

Что изменилось? → отверстие 10 → 12 мм

С какого изделия применяется? → №250

Именно это делает изменение управляемым.

[Иллюстрация 7: Временная ось. На ней отмечены точки Baseline (B1, B2, B3). Между ними — изменения (Change 1, Change 2, Change 3). Каждое изменение ссылается на предыдущий Baseline.]

6.14. Граница применимости стандартов

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

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

Они не предписывают конкретную модель данных Constructum. Они не говорят, что Change, Revision, Proposal или Impact Assessment должны быть отдельными таблицами или объектами.

Это уже архитектурное решение.

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

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

6.15. Связь с предыдущими главами

Глава 4 установила: граница между «тем же объектом» и «новым объектом» определяется взаимозаменяемостью.

Глава 5 установила: Revision фиксирует изменение описания, а не изменение объекта.

Глава 6 добавляет: изменение является управляемым процессом.

Если объект остаётся тем же, изменение реализуется как новая Revision его описания.

Если изменился сам объект, результатом становится новый объект.

В обоих случаях решение должно быть прослеживаемым.

Модель данных должна поддерживать оба пути и не смешивать процесс изменения с результатом изменения.

6.16. Главный вывод

Промышленность формализовала управление изменениями более полувека назад. CMII, EIA-649, NASA Systems Engineering Handbook, MIL-HDBK-61, ISO 10007 и ЕСКД описывают изменение как управляемый процесс.

Изменение начинается не с новой Revision. Оно начинается с предложения, проходит через оценку, решение, реализацию и верификацию, а затем приводит к новому состоянию управляемой информации.

Поэтому информационная система должна хранить не только:

Revision A → Revision B

но и ответ на вопросы:

• Почему?

• Кто?

• На каком основании?

• Что затронуто?

• Кто оценил?

• Кто утвердил?

• Когда вступило в силу?

• Как проверено?

Это не дополнительная история вокруг Revision. Это и есть управление изменением.

Revision фиксирует состояние.

Change фиксирует управляемый переход между состояниями.

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

Часть I завершена. Мы установили, что изменение описания и изменение объекта — разные события, что Revision принадлежит описанию, и что изменение является управляемым процессом. В Части II мы перейдём к вопросу существования: что значит, что изделие изготовлено, и как система различает возможное и реальное.

Примечания к главе 6

Источники:

• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §1.1, §2.1–2.4.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.3, §4.2.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §5.1, §5.3.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §2.1, §4.1.
• ISO 10007:2017, Quality management — Guidelines for configuration management. §3.1–3.5.
• ГОСТ Р ИСО 10007-2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ 3.1128-88. Единая система технологической документации. Общие правила выполнения изменений технологической документации.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.114-2016. Единая система конструкторской документации. Технические условия.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ 15.002-2018. Система разработки и постановки продукции на производство. Продукция производственно-технического назначения.

Типы доказательств: