Свяжите запросы, затронутые ревизии, проверки и внедрение. Сразу видно, что готово к изменению и что еще требуется до перехода производства.
Войдите, чтобы изучить пример в Jodoo. На экранах показаны вымышленные производственные записи.
Система управления инженерными изменениями связывает предлагаемое изменение изделия или процесса с проверками, работами по внедрению и записью о выпуске. Для производственной команды главный практический вопрос — понимают ли закупки, инженерная служба и производство, что меняется, что еще заблокировано и какую ревизию использовать.
Производитель хочет квалифицировать альтернативного поставщика кронштейна. Инженерной службе нужно оценить предлагаемую ревизию кронштейна, закупкам — решить судьбу 40 имеющихся кронштейнов, а производству — определить, что делать с 12 уже запущенными единицами. Также нужно изменить инструкцию по сборке.
Один зеленый статус согласования не отвечает на все эти вопросы. Предложение, объем по объектам, функциональные решения и работы по внедрению должны оставаться связанными, не теряя своего отдельного смысла.
Пример Jodoo показывает различия на рабочих записях: смена поставщика еще оценивается; другое изменение чертежа разрешено, но заблокировано проверкой; изменение инструкции прошло проверенный выпуск.
| Решение | Что проверяет команда | Что это разрешает |
|---|---|---|
| Принять запрос | Текущий объект и ревизия, проблема, предлагаемое изменение и подтверждающие материалы. | Подготовить приказ на изменение. Переход производства еще не разрешен. |
| Разрешить приказ | Затронутые объекты, оценки последствий, обращение с запасами и WIP, а также объем внедрения. | Начать утвержденные работы по внедрению. Текущие ревизии пока не меняются. |
| Проверить внедрение | Завершенное действие, подтверждающие материалы и все оставшиеся критичные для выпуска работы. | Исключить это действие из числа открытых критичных работ. |
| Подтвердить выпуск | Затронутый объект, выполненные обязательные условия и фактическая граница действия. | Обновить именно этот управляемый объект и сохранить историю ревизий от исходной до выпущенной. |
Проверяющие получают назначенные задачи и могут вернуть работу на исправление. Инициатор подает предложение, а назначенный проверяющий принимает решение. До использования приложения для реальных изменений настройте ответственность и правила доступа своей команды.
Сравнивайте исходную и предлагаемую ревизии для каждого объекта отдельно. Кронштейн и инструкция по его сборке могут входить в один приказ, не получая общего номера ревизии и не теряя собственной истории выпусков.
Просматривайте критичные действия, ответственных, сроки и результаты проверки. Разрешенное изменение чертежа по-прежнему отображается с незавершенной работой, если проверку первого изделия выполнить не удалось.
Вместе просматривайте готовящиеся приказы, нерешенные оценки последствий и выпущенные объекты. Открывайте связанные записи, чтобы найти решение или подтверждение, стоящее за показателем.
При замене поставщика нужны сведения о предлагаемом поставщике и подтверждение квалификации. При изменении производственного процесса — затронутая операция. Уполномоченный администратор может настраивать эти условные поля, не превращая каждый запрос в длинную универсальную анкету.
Технические подтверждения должны быть конкретными: примечание к чертежу, результат проверки или управляемую инструкцию можно связать с требующим их изменением, а не прикреплять к посторонней задаче.
Добавьте проверяющую функцию, нужную для категории, измените получателя задачи или создайте представление просроченных работ по внедрению на заводе. Формы, связанные записи, задачи проверки и панели Jodoo можно настроить под процедуру команды.
Изменение процесса все равно нужно испытать. Проверьте существующие записи, возвращенные задачи, расчеты и правила доступа, прежде чем применять новые настройки к реальной работе.
Запросы и проверки разбросаны по файлам и сообщениям; команде нужен четкий объем по каждому объекту и контроль внедрения; бизнес-администраторы должны адаптировать процесс при изменении изделий, поставщиков или ответственности.
Пример дает практическую отправную точку: семь связанных форм и встроенные этапы проверки. Начните с одного управляемого изменения и настройте фактическую ответственность команды.
Ключевыми требованиями являются собственные связи CAD, разметка изменений BOM, конфигурации изделий или корпоративный контроль данных об изделиях. Это приложение не служит хранилищем CAD, механизмом атомарного выпуска нескольких объектов или валидированным решением для подписей в регулируемой среде.
Сравните системы координации и специализированные решения для инженерных изменений до выбора системы, которая будет отвечать за ревизии.
Зафиксируйте причину изменения до принятия обязательств по внедрению.
Спланируйте затронутые ревизии, имеющиеся запасы и переход производства.
Согласуйте ответственность и решения о выпуске по всему процессу.
Перед применением выпуска пример проверяет, что объект активен, а его текущая ревизия по-прежнему совпадает с исходной ревизией изменения. При несовпадении выпуск не изменит объект. Инженерной службе необходимо заново оценить затронутый объем; эта проверка не заменяет параллельное управление конфигурациями BOM или CAD.
Да. Создайте отдельную запись затронутого объекта для каждого элемента. В ней сохраняются исходная и предлагаемая ревизии, решение о дальнейшем использовании и история выпусков. В примере изменение поставщика затрагивает кронштейн и инструкцию по его сборке, но у них не появляется одно общее поле ревизии.
Используйте приложение для нужной команде координации, но заранее определите, какая система хранит утвержденные данные об изделиях и запасах. Пример не синхронизируется с PLM и не проводит операции в ERP. До признания любой системы основной для интеграции нужны однозначные идентификаторы, правила доступа, обработка ошибок и сверка.
Уполномоченный бизнес-администратор может менять в Jodoo варианты выбора, условные поля, назначения проверок и рабочие представления. Например, для смены поставщика можно запрашивать подтверждение квалификации, а для изменения производственного процесса — затронутую операцию. Перед использованием в реальных изменениях проверьте новые правила и права доступа.
Нет. Встроенные задачи проверки и зафиксированные решения не означают, что система электронных подписей валидирована. Отдельно оцените нормативные обязанности, порядок валидации и необходимые средства контроля. Пример предназначен для демонстрации координации инженерных изменений.
Откройте представление готовности, изучите ожидающую решения оценку закупок, а затем сравните ее с разрешенным, но заблокированным изменением чертежа. Эти различия помогут определить, что должна видеть ваша команда.
