Is software a document or a part?

PDXpert PLM software manages both part and document records, and offers the flexibility of using either record class on an assembly's structure ("bill of materials"). So, whichever approach you prefer, PDXpert software can handle it just fine. However, let us try to convince you that treating software as a document, rather than a part, more accurately reflects its usage in product design, manufacturing and support.

Why does it matter how software is classified? For the same reason that other items get classified: to create specific business rules that are applied to all members of the class. Identification numbers, revision rules, release and change workflows, authorized users, and other item attributes are defined by (1) whether the item is a part or document and (2) by the specific type of part or document.

What does it mean to have "product software"?

Software is a strange thing. You can't touch it, yet it is an essential ingredient in your product. It gets shipped out with every unit, but even if you lay out all the components on the part list, you won't see the essential software code.

For this discussion, software — those bits and bytes that the engineer symbolically crafts during product design — is distinct from its production medium, the physical item that contains those bits and bytes for use by the computer. There's no question that the medium used in the product must be treated as a part. The real debate is whether the bits and bytes themselves are a part or a document.

Typically, a final shippable software assembly consists of at least

1. un-programmed medium, such as blank CD-R, empty flash memory, unformatted hard disk, or pre-masked ROM
2. software binary image (on its own medium), often referred to as "golden master"
3. instructions for transferring the binary image onto the blank medium

Does the binary image (or its human-readable source) have a part number, like the blank medium, or a document number, like the transfer instructions?

Is the software image a physical part?

If the product has to ship with software, then that software must be planned and available as the product's being built, and certainly before it leaves the factory. From this perspective, software could very easily be assigned to the part class.

Software as a component

As a general rule, physical items are assembled into a product (for example, a machine screw) or otherwise consumed during production (e.g., masking tape in a paint booth). Some people argue that software is an essential part of the final product and therefore must be considered a component of, say, a flash memory assembly or a functioning ROM-based microcontroller.

Software as tooling or fixture

Since more than one finished good can use the identical software code, there's not a per-item requirement. Instead, a single software object can be used across multiple units of production. Moreover, the substantial development cost for software is similar to tooling, in that it can be separately identified and its cost allocated over a product's life cycle. In discussing items on the engineering bill of materials, one product data management consultant contrasts a complex product's parts list with its "related tooling, fixtures, gauges, templates, test equipment and software."

Is the software image a design or production document?

Documents convey essential instructions for the fabrication, assembly, inspection and test of a product. A document doesn't ship with a product¹ nor is there a limit on how often a single document may be used during the course of production.

Just like every other design and production document, software is not (on a per-unit basis) planned, purchased, fabricated, received, routed or consumed; nor will it be inventoried in the stockroom². The current iteration is infinitely available, may be updated without affecting the stockroom³, and can be used during service and repair without requiring refurbishment or disposal of the previous code.

Its cost may be capitalized and amortized, but this accounting treatment is no different than for any other design artifact that documents the product.

Benefits of treating software as a document

Naturally, the data you create and manage within a product lifecycle management system is especially useful to downstream computer systems like ERP, SCM and CRM. All of these systems work with physical objects that can be acquired from vendors, inventoried and then supplied to customers.

In treating software as a document, you create an extremely simple way of ensuring that your computer code is conveyed in an appropriate and approved physical form (such as compact disk or flash memory). Just as your customers may not have access to your product's electrical schematics or circuit assembly drawings, but may only purchase the physical product, so too should your systems supply only a software assembly (blank medium, binary code and unique part number) and not the software itself.

The PDXpert PLM data export mechanism can enforce a crisp definition of what these downstream systems will import by providing only part data and filtering the document data. The result is that ERP systems will only forecast the blank medium and the "burned" assembly, and service and support systems will only attempt to ship physical assemblies, not raw code, to end users.

Best practice suggests that each production release of the software document is assigned a new document identifier, rather than a revision of the preceding production software release. This practice will always force a discussion of whether the software change affects the parent medium-plus-code assembly as an interchangeable change, requiring only a bump in the assembly revision, or represents a significant functional change that requires a new assembly part number.

Notes:

1. In this instance, we must distinguish design and manufacturing documents from product documentation, such as user guides, installation and maintenance instructions, service manuals, etc. All of the product documentation are, in fact, parts: each has a part (as contrasted with document) number assigned, and each must be treated as any other parts for purposes of production planning.

2. Again, we must treat a "golden master" medium, whatever it is (CD, DVD, ROM, floppy, flash), as distinct from the production assembly of medium-plus-code that is included in each production unit. In traditional government configuration management, the golden master is called the Computer Software Configuration Item (CSCI) and is part of the contract deliverables.

3. Although, like any other documentation change, a revision could affect the product assemblies that rely upon it.

071117.0942