Управление изменением изделия

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

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

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

• Шаг 1, "Определение проблемы" - проблема представляет собой сообщение о проблеме или предлагаемое усовершенствование конструкции изделия и, как правило, фиксируется в отчете о проблемах. Проблема до перемещения на следующий шаг анализируется, обсуждается и проверяется. Не обязательно используются отчеты о проблемах; проблемы могут также документироваться в запросах на изменение и извещениях об изменениях.

• Шаг 2, "Запрос изменения" - в запросе на изменение указывается одна или более проверенных проблем. С запросов на изменение, содержащих все соответствующие данные и соответствующий анализ, включая техническое обоснование и бизнес-обоснование выполнения изменения, начинается процесс управления изменениями.

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

• Шаг 3, "Планирование изменения" - если изменение принято к реализации, необходимо запланировать работы по документированию и применению изменения. На основании извещения об изменении создается план реализации. Этот план включает отдельные задания, связанные с данными об изделии, которые будут изменены. Предлагается график, и составляются рекомендации по решению относительно существующих запасов изделий. После согласования плана рабочий процесс включает реализацию.

• Шаг 4, "Реализация изменения" - задания на изменение распределяются среди пользователей, отвечающих за обновление документации к изделию и регистрацию новых конфигураций изделия. Новые конфигурации изделия выпускаются в производство, когда начинается физическая реализация.

• Шаг 5, "Физическая реализация" - изменения выпускаются в производство, и новые и измененные детали проверяются на соответствие конструкторским требованиям. Управление расхождениями со спецификациями изделий выполняется с применением процесса отклонения/несоответствия.

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

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

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

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