Product lifecycle management: making the product definition something you can rely on

Release states are what separate this from a shared drive

A folder full of files can hold the same data, and many companies survive years that way. What it cannot do is distinguish a design somebody is still working on from one that purchasing may buy against, and it cannot prevent the second being quietly overwritten. Controlled states — in work, under review, released, superseded, obsolete — turn that distinction into something the system enforces rather than something a naming convention hints at. The value shows up on the day a buyer orders to a drawing that was never approved, or a supplier builds to a file a designer copied into a folder while still experimenting with it.

Somebody has to own the part number

Creation authority is the most contested decision in a rollout. Let anyone create a part and duplicates multiply, each with slightly different attributes, until purchasing is buying the same screw three ways and stock is spread across the copies. Restrict creation to one gatekeeper and engineers wait, then work around the delay. What works in practice is a defined request path with a short turnaround, a small group with authority to approve, and a rule that a part is not created without the attributes downstream functions require. Intelligent numbering schemes that encode meaning look attractive and tend to run out of structure exactly when the product range grows.

Where-used is the question that justifies the system

When a supplier discontinues a component, a material becomes restricted, or a defect is traced to a bracket, the immediate question is what else uses it. On a shared drive that means asking long-serving engineers and hoping. A properly maintained structure answers it in seconds and answers it completely, including the assemblies nobody remembered. This capability is worth more than the document storage that dominates most sales conversations, and it is the first thing to test in an evaluation: load a genuinely messy assembly and ask the system where a common part appears across the range.

Migrating decades of drawings is the cost nobody budgets

Existing data arrives as models in several formats and generations, scanned paper, files with no owner, and structures that live only in an old planning system. Deciding what to migrate is a business decision rather than a technical one: everything currently sold and supported, plus whatever is legally required to be retained, is a defensible line. Bulk-loading the rest unexamined imports the mess and makes searching worse. Reserve real effort for cleansing, expect the volume of unresolvable items to be larger than the estimate, and give someone authority to declare a drawing obsolete rather than migrating it out of caution.

If it slows engineers down they will route around it

Design work happens in bursts against deadlines, and any system that adds friction at exactly that moment will be bypassed. The classic pattern is a local working copy that never returns, and a released record that no longer matches what production received. Check-in and check-out have to be quick, search has to find things by the terms engineers actually use, and approval routes need to be short enough that a small change does not sit for a week waiting for a signature. Where regulation demands heavier control, say so explicitly and design around it, rather than applying the strictest workflow to every trivial revision.

Frequently asked questions

We are a small manufacturer with a shared drive. When does that stop working?

The usual triggers are the second site, the second designer working on the same assembly, and the first customer audit that asks to see revision history. Add to that any product carried in service for years, where somebody eventually needs to know exactly what was built. Before those points a disciplined folder structure with a naming rule can hold, provided one person genuinely enforces it. After them the cost of not knowing which revision is current starts appearing as scrapped parts and wrong purchases.

Does the design system belong to engineering or to IT?

Engineering owns the content, the numbering rules and the release policy, because those encode how the company defines its products. IT owns servers, backups, access control and upgrades. The arrangement that fails is one where IT sets configuration policy to reduce administration effort, producing rules engineers find obstructive, or where engineering runs the platform informally and nobody has tested a restore. Written ownership of each decision area, agreed before deployment, prevents most of the later friction.

Can the production system hold product data instead?

It can hold what production needs — the structure to be built, item attributes, procurement data — but it is a poor home for design iteration, revision history of models, and the review process before release. Manufacturers who try usually end up creating items early to get a number, then editing them as the design changes, which leaves purchasing exposed to unreleased designs. Keeping definition upstream and transferring on release preserves the boundary between what is proposed and what is approved.