The Optimal Library Framework

Pipe Dreams vs. Reality

If you are a manager, librarian, or a designer who has volunteered to fix your group's library issues, you likely feel overwhelmed. Between the investment in time and capital, there is a steep mountain to climb. One of the first decisions to make is what system will store and manage the library.

The optimal solution is to integrate your component library directly into your company's purchasing database.

Now that you're done laughing, let's explore this option since it is vital to understand why we make such a bold recommendation. Even if you lack the authority to implement it, you'll know what to expect when you resort to an alternative solution.

The Philosophy of Unified Data

The most effective method of library management is a single database that serves both Engineering (the designers) and Business (purchasing and accounting). When these databases are separate, an inherent information lag exists. While we recognize that unifying these systems is a massive undertaking - making separate libraries a "necessary evil" - the problems caused by this disconnect are consistent and costly.

1. Communication Breakdown

The moment two databases exist, a lag of information begins. This delay can exceed six months, meaning critical data - such as obsolescence or company-approved status - rarely finds its way back to the designer's library. Without this feedback loop, designers unknowingly make poor component choices.

Conversely, the purchasing department rarely sees a project's components until the Bill of Materials (BOM) is generated. If the BOM isn't produced until the end of the design cycle - a common occurrence - the risks are high. This delay usually stems from two factors:

Manual Editing: Without a centralized library, the BOM must be manually written. This tedious task is often delayed until after fabrication documentation is sent, under the false impression that the project is "winding down."

Schedule Pressure: Management prioritizes visible results like schematics and PCB layouts as proof of meeting the schedule. Without a strict procedure to submit the BOM immediately after the schematic review, it is often forgotten in the rush to hit design milestones.

There is a high probability that purchasing will discover an obsolete part or a lead time that misses the deadline. Fixing this late-stage error - finding a new part, updating the library, correcting the schematic and PCB, and regenerating documentation - costs an estimated $28,000 per spin (Source: Lifecycle Insights, 2018). With the current inflation, that figure will be higher.

2. Process Breakdown

Process breakdown occurs when a lack of automation forces teams to bridge gaps with manual editing. For most designers, Microsoft Excel is the primary "bridging tool." Most don't realize that the moment you use Excel to convert file formats or shuffle data for another tool, you are manually covering a process gap.

The Email Trap

If your process requires manual intervention, like emails, it will eventually fail. Imagine a team of three librarians managing a simple, non-automated library:

A designer emails all three to request a new component.

The librarians must coordinate who takes the task.

They must then email the designer to confirm assignment.

This creates a flurry of emails for a single part. Scale that to ten designers making multiple requests, and the system collapses. Without an automated status tracker, visibility vanishes.

The Part Number Paradox

Even a task as simple as creating a unique part number becomes a minefield with two databases. Typically, the purchasing database allocates company part numbers. If the design group manages their own allocation via a shared spreadsheet, it almost inevitably turns into a "hash" of missing info and duplicates. The longer these errors persist, the harder they are to fix once they finally hit the purchasing system.

The Verdict

Most points of failure in a library workflow are caused by a lack of automation between disparate systems. Unless you move toward a single database, these failures can only be patched with "bridges" like Excel or custom scripts. To build a truly scalable system, you must bridge the gap between the person drawing the schematic and the person cutting the check.

It should be noted that companies like Altium recognize this deficiency. They have created products that can interface between A365/Enterprise to well-known Product Lifecycle Management systems (PLMs). In the past, this effort was a significant undertaking, as it required heavy and expensive coding by individuals who understood library concepts and the structures of each system.