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

Глава 17. Что происходит, когда модель не соответствует практике?

17.1. Система, которую никто не использует

Представим предприятие. Три года назад внедрена PLM-система. Бюджет освоен. Серверы работают. Лицензии куплены. Обучение проведено. Формально проект завершён успешно.

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

PLM-система существует. Но не используется. Или используется формально: для хранения финальных версий документов, которые уже согласованы другими средствами.

Глава 15 показала: правильная модель ограничивает невозможные состояния. Глава 17 задаёт обратный вопрос: что происходит, когда модель не соответствует реальной инженерной практике?

Что произошло?

Технологии не подвели. Сервисы работают. Интерфейс функционирует. Проблема находится глубже.

Модель данных не соответствует тому, как инженеры мыслят и работают.

И пользователи сделали единственное, что могли: обошли систему.

17.2. Почему пользователи обходят систему

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

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

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

Первый: приспособиться.

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

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

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

Второй: обходить.

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

Конструктор хранит актуальную таблицу изменений в Excel. Технолог ведёт рабочую версию маршрута в своей базе. Производство использует локальный учёт. А в PLM данные попадают только после того, как работа уже выполнена.

Третий: сопротивляться.

Требовать доработок. Создавать новые поля. Добавлять специальные статусы. Писать исключения. Участвовать в бесконечных совещаниях о том, как заставить систему поддерживать ещё один частный случай.

В результате модель постепенно усложняется. Но её исходная проблема остаётся.

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

Изделие нужно разработать. Документацию нужно выпустить. Производство нужно запустить. Экземпляр нужно учесть. Если система мешает выполнить работу, пользователь найдёт другой способ.

17.3. Как возникает обход

Рассмотрим простой пример.

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

• само изделие;
• его конструктивное описание;
• изменения этого описания;
• изготовленные экземпляры;
• документы, которыми оформлено описание;
• применённую к конкретному экземпляру ревизию.

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

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

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

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

Каждое такое решение сначала кажется небольшим техническим компромиссом. Но компромиссы накапливаются.

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

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

17.4. Модель становится частью проблемы

На этом этапе возникает опасная иллюзия.

Предприятие видит, что пользователи обходят систему, и делает вывод: система недостаточно функциональна. Покупается новый модуль. Добавляются новые поля. Появляются дополнительные workflow. Расширяется API. Меняется интерфейс. Иногда меняется вся технологическая платформа.

Но если исходная модель осталась прежней, проблема остаётся.

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

17.5. Неправильная последовательность

Предприятие решает построить новую PLM-платформу.

Архитектор выбирает технологии. Команда начинает разработку. Через полгода сервисы работают. API опубликованы. Интерфейс функционирует.

Через год пользователи начинают обходить систему. Через два года предприятие решает «переписать систему». Выбирает новые технологии. Через три года новая система работает.

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

Технологии изменились. Модель — нет. И проблема не решена.

17.6. Правильная последовательность

Правильная последовательность начинается с другого вопроса.

Не: «Какую систему мы будем строить?»

И даже не: «Какие функции должна иметь система?»

Сначала необходимо определить: «Что существует в инженерном мире и что система должна уметь представить?»

Архитектор определяет модель данных. Какие объекты существуют? Как они связаны? Какие изменения относятся к объекту, а какие — к его описанию? Что является самостоятельным объектом? Что является документом? Что является экземпляром? Какие правила должны быть невозможны для нарушения?

Затем команда проверяет модель на реальных сценариях. Конструктор создаёт изделие. Изменяет его описание. Выпускает новую Revision.

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

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

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

Через пять лет предприятие решает обновить технологии. Меняет базу данных. Меняет язык программирования. Меняет протокол.

Модель остаётся. Данные сохраняют смысл.

Переход проходит без изменения самих инженерных понятий.

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

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

Система не позволяет создать Revision для объекта. Это неудобно. Но это правильно. Revision принадлежит описанию.

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

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

Если ограничение отражает реальность, оно является правильным. Пользователь может быть недоволен. Но ограничение защищает от ошибки.

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

Поэтому задача хорошей модели не в том, чтобы разрешать пользователю всё. Её задача — разрешать то, что соответствует реальному миру, и запрещать то, чего в этом мире быть не должно.

17.8. Что происходит, когда модель правильная

Если модель содержит необходимые понятия, пользователям не приходится создавать собственные замены.

Конструктор работает с изделием и его конструктивным описанием. Технолог управляет технологическим описанием. Производство ведёт учёт изготовленных экземпляров.

Документы оформляют и фиксируют соответствующую информацию, но не подменяют собой изделие.

Изменения проходят как изменения соответствующих описаний и управляются установленным процессом.

Каждый работает в своей области. Система помогает. Не мешает.

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

Хорошая информационная система не заставляет человека подстраивать реальность под структуру базы данных. Она позволяет выразить реальность в данных.

17.9. Почему обучение не решает проблему

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

Проводят дополнительные курсы. Пишут инструкции. Назначают ответственных. Устанавливают контроль заполнения. Вводят KPI по использованию системы.

Но обучение может объяснить человеку, как пользоваться системой. Оно не может сделать неправильную модель правильной.

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

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

Если для выполнения обычной работы необходимо обходить ограничения системы, обход становится частью процесса.

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

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

Глава 13 установила: модель данных определяет архитектуру системы.

Глава 15 установила: модель может предотвращать онтологические ошибки.

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

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

Вместе эти главы формируют последовательную картину.

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

Затем определить, какие изменения относятся к описанию, какие — к самому объекту, а какие создают новый объект.

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

И только после этого оценивать, насколько хорошо система поддерживает работу людей.

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

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

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

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

Конструктор видит изделие. Система видит запись. Инженер видит изменение конструкции. Система видит изменение нескольких полей.

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

И тогда пользователь начинает строить вокруг системы собственную модель реальности. Система формально продолжает работать. Но постепенно она перестаёт быть источником истины.

Поэтому главный критерий хорошей модели данных — не количество поддерживаемых функций и не сложность архитектуры.

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

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

Если модель не соответствует практике, система сама становится препятствием.

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

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

Источники:

• 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.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.114-2016. Единая система конструкторской документации. Технические условия.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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