Engineering Change Management

Capture, evaluate and route proposed engineering changes as Change Requests (CRs) in IFS Cloud PDM/Configuration. A CR gathers information to analyze the consequences of a change (error corrections, improvements) and, once approved, authorizes creation of a Change Order. CR statuses move Preliminary to Active to Processed (or Cancelled).

Authorize and execute approved engineering changes through Change Orders (COs) in IFS Cloud PDM. A CO is issued from one or more approved Change Requests, carries an action list of tasks assigned to individuals, and drives the creation of new engineering part revisions. When the CO is approved, all connected CRs are set to Processed.

Create a new engineering part revision to carry a change, since a released revision can no longer be modified. The Create New Revision command lets you copy structure and document survey from a prior revision, connect the revision to a Change Order, and prepare it for approval and release. An Engineering Change Note documents what changed.

Release an approved engineering part revision to production and roll the change into structures by replacing the old part/revision. Release is irreversible and enforces prerequisites (active structure, approved characteristics/manufacturer, completed approval routing, approved documents). The Replace Part/Revision assistant propagates the new revision into the structures where the old one is used.

Closes the loop from field failure back into engineering and out again as a corrective action in the field. Failure reports from work orders, warranty claims and returns are analysed to root cause in a FRACAS discipline, safety and regulatory reportability is assessed, and where required a corrective action plan is agreed with the regulator. IFS Cloud service campaigns then drive execution against the affected installed base population, with completion tracking, progress reporting and verification that the corrective action actually prevented recurrence.

Controls every planned intervention on data centre critical infrastructure through a change record and an approved MOP in IFS Cloud. Changes are classified as standard, normal or emergency so routine work is not over-governed, the MOP is held as a revision-controlled Document with scripted and back-out steps, and redundancy risk is assessed before the change authority authorises release. Only an approved MOP revision releases the executable Work Order, and closeout updates the as-built record.

Change in IFS Cloud is executed as a new engineering part revision, optionally connected to a change order at creation, copying the prior revision structure and document survey, and closed out with an Engineering Change Note and document distribution. Impact is assessed through Where Used on the affected revision, and where the change is form, fit and function identical the Replace Part/Revision assistant swaps it into selected parents and writes a note into each parent journal. Production effectivity is then carried by the structure and routing revision, which can be driven either by date or by serial range according to the site structure and routing effectivity setting.

Controls the release and field deployment of medical device software and firmware updates, including cybersecurity patches, across an installed base tracked in IFS Cloud. Each approved update becomes a planned campaign that generates Work Orders per affected Serial Object, records the pre and post update version, and captures verification evidence. Regression to the prior version is retained as an explicit rollback path.

Turns accumulated IFS Cloud service data - work order failure codes, fault reports, complaint cases and returned-part findings - into a statistically defensible trend signal that either triggers a CAPA or produces a documented reason not to. IFS Cloud is the data source and the place corrective actions are implemented; the CAPA record itself is a quality-system artefact with no standard IFS Cloud object. Effectiveness is verified against the same trend metric that raised the signal.

Plans a field safety corrective action from the moment a safety signal is confirmed to the point an approved FSCA plan and field safety notice are released for execution. In IFS Cloud the process is anchored on the installed base: the affected population is reconstructed from the Part Serial Catalog, lot/batch records and Serial Object registry, and the consignee list is derived from Customer Order and part serial history. The regulatory artefacts themselves (FSCA plan, health hazard evaluation, field safety notice) have no standard IFS Cloud object and are normally held as Documents or in the eQMS.

Executes an approved recall or field campaign across the affected installed base and proves it worked. In IFS Cloud each affected Serial Object gets a Work Order and dispatched Work Tasks with the corrective kit reserved from inventory, while consignee notification, response and effectiveness-check outcomes are tracked to the level set in the recall strategy. Effectiveness-check records and recall status reports have no standard IFS Cloud object and are held as Documents or in the eQMS against the campaign.

Controls changes to process chemicals, technology, equipment, procedures and facilities affecting a covered process, as required by OSHA PSM 29 CFR 1910.119(l), with replacements in kind excluded. Each change is screened, assessed for technical basis and safety and health impact, authorised, implemented and closed out only after process safety information, operating procedures and training have been updated and a pre-startup safety review is complete. IFS Cloud has no standard MOC record object, so the change itself is normally held in a dedicated MOC system while the physical work runs as IFS Cloud Work Orders and the updated documents are controlled in Document Management.

Controls modifications to treatment chemicals, technology, equipment and operating procedures so that no change reaches start-up without technical review, authorisation, updated documentation and trained staff. OSHA process safety management requires written procedures to manage such changes other than replacements in kind, and requires affected operating, maintenance and contract employees to be informed and trained before start-up. In IFS Cloud the MOC is raised as a Case, implemented through a Work Order, and evidenced by updated controlled Documents and Functional Object master data.