Defense & Aerospace Sustainment

Establishes and maintains the configuration baseline for serialised platforms in IFS Cloud Fleet and Asset Management, where serial parts configure template structures and those template structures are the basis for the serial structures used to plan, schedule and control a fleet. The link to IFS/PDM Configuration is activated by enabling after-delivery serial tracking on an engineering part, and serial part data carries the vehicle-part flag, life limit, operational parameters and maintenance group. Product model and manufacturer data must be established before serial structures are created, because product model drives the functional breakdown used when faults are reported.

IFS Cloud has a real and well-documented Part Ownership model - Company Owned, Consignment, Supplier Loaned, Supplier Owned, Customer Owned, Company Rental Asset and Supplier Rented - with an owner on the stock record, zero inventory valuation and exclusion from planning for customer-owned stock, controlled transfer-of-ownership paths, and persistent ownership that survives out of inventory for serial-tracked parts and tracked components. Modelling the government customer as the owner of Customer Owned stock is therefore a legitimate way to segregate and track government property. IFS does not, however, implement Government Property accountability as a regulated concept: there is no GFE/GFP property record, no property administrator approval workflow, no loss/damage/destruction report object, and no interface to any government property registry - all of which remain external or manual.

IFS Cloud provides real serialised identity: part serial tracking with a part serial catalog, serial history recording the objects, purchase orders and inventory locations a serial has passed through, and Serial Objects in equipment administration carrying type designation, technical data, warranties, structure position and maintenance history. That is a sound basis for item-level traceability of a serialised deliverable. IFS does not implement unique item identification as a regulatory scheme: no UII construct, enterprise identifier or issuing agency code field was found, no MIL-STD-130 data-matrix content generation, and no interface to any government item registry, so mark content generation and registry submission are a labelling/integration bolt-on and an external filing process.

Executes depot and workshop maintenance through the IFS Cloud Work Order and Work Task objects, where the work order carries the scope and the work task is the schedulable unit holding resource demands, material reservations, work task steps and work assignments. Labour is captured against the work task while it is in Work Started, with time, causes and work-done description recorded at Work Done status, after which no further transactions are permitted. Status progression through Released, Work Started, Work Done, Reported and Finished gives the auditable execution trail a depot needs.

Captures failures and faults found during operation or maintenance of a vehicle or serial using the IFS Cloud fault reporting flow, where a fault registered with the Pending Fault action creates a pending maintenance event and a fault registered as Already Repaired creates a serial fault history record. Faults are classified against a product model function breakdown with a fault code valid for that breakdown, and permitted faults can be deferred using fault deferral rules. In the EAM flow the equivalent entry point is a work order created at Fault Report status, which is then prepared and executed as corrective work.

Defines and maintains the interval-based maintenance programs that drive planned maintenance for serialised platforms in IFS Cloud, where a maintenance program is assigned per part number with maintenance groups reflecting different operational conditions, and a maintenance plan holds maintenance codes with intervals against operational parameters and calendar time. Due calculation works through the serial maintenance plan using the value since overhaul of the operational parameter, and creates a pending maintenance event when the calculated due date falls inside the days forewarning. For plant and equipment the equivalent construct is the PM action, a revision-controlled template that generates work orders by Calendar, Event, Condition or Manual methods.

Covers the arrival of a platform or major end item at a depot and its establishment as a maintainable, serialized record in IFS Cloud. The incoming asset is created or updated as a serial structure in Fleet and Asset Management - either manually, by copying an active template structure, or via the Import Asset CSV load documented for asset induction in repair and overhaul processes - and the induction work order or maintenance order that will carry the visit is raised against it. Ownership, workshop, location and maintenance group are captured on the serial so that customer-owned and government-furnished platforms are segregated from company-owned stock from the first transaction.

Executes the strip and inspect phase of a depot visit through the IFS Cloud Complex Assembly MRO shop order chain. Disassembly shop orders take their material from the work order for the overhaul object or a previous disassembly order and output the components to be disassembled plus the remainder of the overhauled part; disposition shop orders then authorise inspection and disposition of those unknown or uninspected items. Because the real configuration is unknown before teardown, both order types are created against position parts and only resolve to identified real parts as the inspector works the disposition lines.

Defines what work a depot visit will actually contain and controls the additional work discovered after the visit starts. In IFS Cloud the planned scope is assembled by prioritising pending maintenance events against a maintenance opportunity window, and the resulting work scope drives the interim MRO order structure; disposition shop orders are generated either through the initial work scope or through revaluation of that work scope after inspection of disassembled components. On the component repair side, service types both define a work scope and act as the price label for the work performed, with the part service contract as the primary source of price.

Manages the serial-tracked spares that rotate between supplier, stock, the customer, the platform and the repair shop. IFS Cloud provides a native Rotable Part Pool feature that lets segments of inventory be defined as rotables and grouped into company-owned, customer-owned or fixed asset rotable pools, with strict availability control rules that make pooled serials non-plannable, non-reservable and non-transferable until they are manually removed from the pool. For defense sustainment this is the mechanism that keeps government-furnished and customer-owned rotables financially and physically ring-fenced from company stock.

Executes the actual repair of removed components and maintains unbroken serial history through it. In IFS Cloud a repair shop order is an electronic document that authorises the repair or modification of a part; it is created with the Repair shop order type, allocated the part to be repaired, and generated either at the time of dispositioning component serials or at the time an assembled item is received. Serial identity is preserved through the Part Serial Catalog and Fleet and Asset Management history records, including the rename mechanism used when a modification changes the part number of a serial.

Rebuilds the overhaul object and proves it fit to return to service. Assembly shop orders draw material from inventory, disposition orders or repair orders and their expected output is the overhauled object or reassembled component; like the other MRO order types they are created initially for position parts and are assigned real parts once those parts are identified. The as-built serial structure must then reconcile to the template: a serial is only Operational when its configuration conforms to or exceeds the minimum configuration of the template structure, and it cannot be put into operation while Non Operational.

Manages the definition, assignment, execution and compliance recording of modifications - the IFS Cloud construct used to carry what defense operators call technical directives, TCTOs, service bulletins and retrofit campaigns. A modification is defined, then a modification program assigns part numbers and revisions and sets whether it executes at next visit in any workshop, at next interval maintenance, or at a calculated time from operational parameters or a calendar interval. Serial assignment is by revision for all serials or by serial range, and where a modification changes part identity the serial is renamed automatically when the terminating action is performed.

Certifies that a maintained, repaired or overhauled item is serviceable and releases it back to the operator using the IFS Cloud part certificate flow, where approval organisations, authorities, form types and authorised approvers are configured as basic data and only approvals in Approved status are valid for generation. Certificates are generated from maintenance orders, work orders and complex assembly work orders in Work Done, Reported or Finished status, and from CAMRO and CRO shop orders, via the Print Release to Service assistant. Before the form is produced the system validates that all work on the order is completed or cancelled and that there are no overdue maintenance events for the serials in the serial structure, then sets the operational condition of the serial structure to Operational.

Assembles a forward and current view of fleet condition from standard IFS Cloud objects: pending and overdue maintenance events from due calculation, open deferred faults, and Maintenance Planning Board scheduling statuses that show whether required work will complete inside the available window. Where IFS/Operational Plan is used, object accessibility derived from operational plans and operational modes separates time the platform is committed to operations from time it is available for maintenance. Readiness constructs such as mission capable rate are not IFS Cloud features - they are derived measures built on top of these objects and must be defined during design.

IFS Cloud Master Scheduling turns contract delivery quantities into forecasts on MS Level 1 parts and generates supply proposals that respect lot sizing, safety stock and safety lead time, with actual demand consuming the forecast. Demand and Planning Time Fences determine when proposals become fixed and when shop order or purchase requisitions may be created, and MS proposals explode through the manufacturing structure to feed MRP for subassemblies and purchased components. Where a contract must be planned in isolation, project master scheduling runs in the same pages separated by a project planned netting group value rather than an asterisk.

IFS Cloud represents a build-to-print article as an inventory part revision carrying a Manufacturing-type product structure header plus a matching routing alternate, both of which must be promoted from Tentative through Plannable to Buildable before Planning and Manufacturing can consume them. Routing operations are defined per work center with machine setup and run factors, and structure components can be tied to an operation number so material is issued at the correct step. Build-to-print itself is a contracting model rather than an IFS feature: the customer print is carried as Document Management revisions connected to the part revision, and the Site/Manufacturing Structure/Routing Update setting is what actually freezes the definition.

First article inspection in IFS Cloud is realised with a Quality Management control plan connected to the shop order, which defines what to inspect for which part and which shop order operation, and with analyses created and confirmed against that first production run. Variable, attribute and categorical data points are recorded per serial number where Serial Registration is enabled, and Print Data Sheet and Print Analysis Results produce the objective inspection record. IFS Cloud does not ship AS9102 forms or AS9102 compliance content in the documentation reviewed here, so the customer-facing FAI report package is a document management and reporting exercise built on top of the analysis results.

Lot and batch genealogy in IFS Cloud rests on parts flagged lot/batch tracked, with the parent lot able to inherit its number from a component designated Lot/Batch Origin in the product or recipe structure and its expiration date from one or more Expiration Date Origin components. Where component-to-parent genealogy is required, Multi-Level Tracking causes a shop order tracked structure to record which component lots were consumed into which parent lot, and that structure must be complete before the parent is received. Lot/batch numbers are carried on issue, scrap and receipt transactions, including through the Shop Floor Connector APIs, so the as-built lot record is a by-product of normal execution.

Shop order operations in IFS Cloud are reported through the Shop Floor Workbench, moving from Released through Setup Started, In Process and Partially Reported to Closed while capturing completed, scrapped, bypass and deviation quantities. For parts with Multi-Level Tracking enabled, a shop order tracked structure binds component serial and lot/batch numbers to each parent serial, and that structure must be validated as complete before the parent can be received. Barcode and machine data collection is not a separate IFS module: it is delivered through the Shop Floor Connector projection APIs for starting and stopping operations, reporting quantity and scrap, issuing components and receiving the order.

IFS Document Management holds each deliverable as a document title with one or more revisions moving through Preliminary, Approval In Progress, Approved, Released and Obsolete, where an approval routing of named electronic signatories must complete before release. Deliverable sets are assembled as document structures and document packages, the latter reporting weighted average progress against milestones and connectable to a project activity. Technical data package and contract data requirements list are contract constructs rather than IFS objects: they are realised with document classes, approval routings, packages, and the Document Distribution Assistant whose distribution history is the delivery 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.

In IFS Cloud the engineering BOM lives on the engineering part revision, which is the parent of the Consists Of and Where Used structure as well as the document survey, approval routing, development journal and change request. A revision is created with Create New Revision, optionally copying the previous revision structure and document survey, then approved before use, while the manufacturing product structure remains a separate, site-specific object. A configuration baseline is not an IFS object: it is expressed as a set of approved engineering part revisions plus the released document revisions connected to them.

IFS Cloud Document Management provides a genuine and well-documented access model - View/Edit/Admin levels per document revision, access templates per document class, person and person-group access with person access taking priority (and therefore usable as an explicit deny), Restricted Access to hide a document from anyone without at least view access, and object-controlled access inherited from Projects, Work Orders, Quotations, Invoices, HR and CRM objects. That model can be configured to support ITAR/EAR technical-data controls, but IFS supplies no export-control logic inside Document Management: there is no citizenship or nationality attribute, no deemed-export test, no automatic distribution-statement or classification marking, and no watermarking or digital-rights enforcement on files once downloaded. IFS separately sells IFS Unified Support for ITAR, which is a support and hosting service with US-person staffing on Azure Government, not a product feature.

Within IFS Cloud the defensible scope of this process is narrow and application-level: permission sets as the unit of authority, document access control over sensitive artefacts, Application Configuration Packages under Configuration Lifecycle Management as the controlled route for moving configuration into production, and Information Sources for evidence extraction. IFS also sells IFS Unified Support for ITAR, a support and hosting service providing operational and physical isolation, US-person support staff and Azure Government hosting - a contractual service, not a product certification. IFS Cloud is not a governance-risk-compliance tool: there is no system security plan, control catalogue, assessment, plan-of-action or incident-reporting object in the product, and no IFS capability claims compliance with any cybersecurity regulation on the customer's behalf.

IFS Cloud ships a genuine Export Control capability: export control codes and classification schemes held per part and per order country, approved codes on Supplier for Purchase Part, and Export License records carrying effective dates, coverage and restrictions on site, consignee, supplier, forwarder, customer, end user, end usage and nationality, which the purchase, customer and shop order flows test through Find and Connect Export License. What IFS does NOT do is determine the classification: ITAR USML categories and EAR ECCNs are regulatory constructs that IFS neither ships nor interprets, so the control code values are customer-maintained master data. Licence applications, TAA/MLA agreements and any government filing happen entirely outside IFS.

Contract data deliverables can be run in IFS Cloud using standard building blocks: Document Management document classes and revisions with approval routing, access control and document distribution for the deliverable artefacts; Project and Project Activity for the schedule the deliverable is due against; and Information Sources with Business Reporter for producing the reported content. What IFS does not provide is the contractual construct: there is no contract data requirements list, data item description, deliverable-due-date-driven obligation object, or acceptance/rejection cycle in the product, and no interface to any government invoicing or receipt-and-acceptance portal. Those are modelled as project activities and document classes by convention, or held in an external contract management system.

IFS Cloud controls who may be bought from through approved suppliers lists, which define the purchase authorization process for parts in a purchase group on a particular site. When a supplier holds approved status on the list and the Approved Until date has not passed, purchases of parts in that purchase group do not require authorization according to the defined authorization template; once the date passes the supplier is treated as unapproved and purchases require authorization again. Ongoing qualification is supported by the Supplier Performance Evaluation and Rating process with evaluation setup, supplier evaluation templates, KPI groups and KPIs; certification-body accreditation content (for example AS9100 or Nadcap scope) is not documented IFS functionality in the sources reviewed here.

IFS Cloud supplier agreements come in two forms: a purchase agreement that sits in the background and supplies the price for all applicable purchase order lines, and a blanket purchase order that is a long-term authorised commitment released with supplier agreement releases. Agreements carry owning site and valid sites, validity periods with maximum amounts and an Exceed With Warning / Exceed Without Warning / Do Not Exceed control, plus part, part assortment and supplier assortment pricing with step pricing and detailed price elements. Contract flowdown of prime-contract clauses (for example DFARS clauses, quality notes and specification revisions) is not a documented IFS Cloud feature in the sources reviewed here and is normally carried as agreement and purchase order text plus attached documents.

IFS Cloud has genuinely useful primitives here: Purchase Part quality requirements - Quality System Level with ranking, Qualified Manufacturer Required and Qualified Supplier Required - are evaluated against the supplier when a purchase requisition, purchase order or change order is released, and an unqualified supplier forces manual authorisation; Part Manufacturer records the manufacturer separately from the supplier; and serial and lot tracking with persistent ownership gives item-level provenance through receipt, build and repair. IFS does not implement counterfeit-avoidance as a regulated programme: there is no authorised-distributor register, no test-report or authentication-result object, no interface to any industry counterfeit alert exchange, and no suspect-part quarantine and reporting workflow beyond generic non-conformance handling.

IFS Cloud Human Capital Management holds competencies and certificates against the employee with validity periods, structured by Competencies Structure and Certificate Structure, and those qualifications can be made a requirement of work through Additional Qualifications on person resource demand lines so that resource search and allocation respects them. That machinery genuinely supports competency-gated work assignment. It does not support personnel security: no security clearance level, clearance investigation, citizenship or dual-nationality data object was found anywhere in IFS Cloud, so clearance and citizenship status must either be modelled as a locally defined competency or certificate with all the weaknesses that implies, or held in a separate personnel security system, and the legal record of clearance remains outside IFS in every case.

In IFS Cloud a detected nonconformance is raised as a Material Review Board (MRB) case against an inventory part in stock, a purchase order receipt or a shop order, using a non conformance code defined as basic data. Creating the case puts the parts into a Planned MRB in an isolating availability control so they cannot be used, and for purchase receipts it blocks further receipt into stock, scrapping, returning and cancellation of connected receipts until the case is dispositioned. Disposition outcomes (use-as-is, rework, return to supplier, scrap) are recorded in IFS, while the formal corrective and preventive action loop itself has no documented dedicated CAPA object in the IFS Cloud documentation reviewed here.

IFS Cloud calculates earned value (Budgeted Cost of Work Performed) from three parameters: the Earned Value Method on the project (Planned or Baseline), the Planned Cost Driver on the activity (Connected Objects, Activity Resources, Estimated Cost or Exclude Activity Resources), and the Progress Method on the activity (Duration, Template Progress, Manual, Consumption Based, Tasks or Connected Objects). Top-down methods assign activity progress down to each cost element line, while bottom-up methods roll cost-element earned value up into activity, sub project and project weighted average development. Analysis indicators including ACWP, BCWP, BCWS, CV, SV, CPI, SPI, VAC, IEAC and IETC are available through project performance analysis; formal EVMS compliance certification is a programme matter rather than an IFS feature.

IFS Cloud handles periodic payment against work completed through Application for Payment, where a valuation is made against the contract items up to a cutoff date using Progress (percentage complete), Quantity Complete, Cost Value, Cost Plus (actual cost factored by a mark-up) or Sales Value. The application moves through Planned, Approved, Submitted, Certified, Partially or Fully Paid and Canceled, is cumulative across applications, creates financial postings on submission and again on certification, and is retained in a Sales Contract Ledger tracking payment requests, amounts paid and amounts withheld. Statuses also feed the IFS Cash Flow Analysis with a reliability-graded cash flow status, while transaction-based billing runs through project invoicing.

Controlled stores in IFS Cloud rest on part-level tracking settings: serial tracking is configured as a combination of At Receipt and Issue, In Inventory and After Delivery, with full serial tracking making serial entry mandatory at receipt and keeping a serial on the part throughout its life cycle in the part serial catalog. Availability control codes isolate or freeze stock, MRB cases lock nonconforming material, and periodic verification is done with count reports that can be limited to cycle-counted parts, freeze stock while counting, and be split per warehouse. Shelf life and expiry handling is closely tied to lot/batch and serial identity, but the IFS lot/batch tracking reference page could not be retrieved during this research.

Plans spares provisioning for defense platforms with IFS Cloud Inventory Planning and Replenishment (IPR). Inventory parts are planned by reorder point (Planning Method B) and classified from issue transaction history by ABC value, movement frequency and lifecycle stage using the Perform ABC, Frequency and Lifecycle Classification assistant. Planning policies are inherited down the hierarchy Company, Site, ABC-Frequency-Lifecycle, Asset Class, Commodity Group and Supplier, setting service rate, demand model, safety stock model, lot size model and order point model. Slow-moving spares, typical of defense fleets, use the Poisson-based Slow Movers and Croston order point models, which target a service rate without an explicit safety stock. IPR then calculates lot size, safety stock, order point and next order date, and replenishment signals become purchase requisitions or orders through order proposals. Repair-driven (rotable) supply is not covered by IPR and must be planned separately.