Is software a part? Nope, it's a document!

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" or "references"). So, whichever approach you prefer, PDXpert software can handle it just fine. However, let us explain how 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 critical piece of software code that makes everything work.

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 (the payload) are best treated as a part or a document.

Typically, a final shippable software assembly consists of

1. unprogrammed medium, such as blank CD-R, empty flash memory, unformatted hard disk, or pre-masked ROM; and

2. software binary image: on its own medium (often referred to as "golden master") or as an electronic file managed within a PLM software file library; and

3. a documented procedure for transferring the binary image onto the unprogrammed medium.

Our question becomes: Does the binary image [2] (or its human-readable source) have a part number, like the unprogrammed medium [1], or a document number, like the transfer procedure [3]?

Isn't 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 is being built, and certainly before it leaves the factory.

Let's first consider the arguments in favor of classifying software as a physical part.

Is software 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 aspect of the final product and therefore must be considered a component of, say, a flash memory assembly or a functioning ROM-based microcontroller.

While this is quite true, it only tells us that the software must exist in some form before we can ship the product. It really doesn't help us to decide the issue of whether the binary object (or its source code) is either a part or a document.

Is software tooling or a fixture?

Since a single software object can be used across multiple units of production, there's no per-item demand. 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 (albeit without ever wearing out). 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."

However, this seems like an awkward construct because, unlike tooling and fixtures, the software is specified to fulfill product requirements, not support a production environment.

The software image as a design 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.

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

Computer software is the definition of how to convert blank media into something else. It's really not much different than production instructions for where to drill holes (although the "holes" are quite small).

In our example software assembly above, the software binary image [2] is a document.

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 delivered 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 design, but may only purchase the physical product, so too should your production & support systems manage 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. 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. Product documentation is, in fact, a shippable item: each has a part (as contrasted with document) number assigned, and each must be forecast, obtained and shipped to fulfill the requirements of your final product.

2. Again, we must treat a "golden master" source, whatever it is (PLM file attachment, 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 a contract deliverable.

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

Contact us if you'd like to discuss how the general concepts in this note may be applied to your situation. We'd be happy to address other PLM software good practices — ask us!