The Optimal Library Framework

If you are a manager, librarian, or someone in the design ranks who has volunteered to tackle your group's library issues, you are probably overwhelmed. There is much to understand. Obviously, there is an investment in time, money, and in most cases, both.

Let's cut to the conclusion and provide the optimal answer.

            Integrate your component library into your company's purchasing database.

Now that you are done laughing, we will introduce an alternative solution later in this commentary; however, you must grasp why we have made such a bold recommendation, even if you do not have the power to implement it.

Going back to the library philosophies on the prior page, one particular philosophy is essential to this discussion:

The optimal method of library management is to have a single database that serves both the engineering (aka the designers) and the business (aka the purchasers, accountants) groups. A library database separate from the purchasing system will always have an inherent information lag, which causes most of the problems. (We understand that this is not a simple thing to remedy; thus, the need for a separate library truly becomes a necessary evil.)

In our analysis and experience regarding company libraries, the same theme reoccurs. When two separate databases do not talk with each other, there is a communication and process breakdown.

Communication Breakdown

As mentioned in the philosophies, the moment there are two databases, there is an inherent lag of information between the databases. This time lag can be more than six months. That becomes problematic because information such as obsolesce or company-approved/reviewed component statuses do not readily find their way back into the designer's library database (if at all). This is critical information that allows a designer to make good component choices.

Conversely, the purchasing database generally has no opportunity to review the project's components until a Bill Of Materials (BOM) is generated. This is very risky if the BOM isn't generated until the project's end, which is NOT uncommon. The delay in creating a BOM happens for two reasons:

• If there is no library, the BOM has to be created by hand. This tedious process is generally held off until after the documentation has been sent to fabrication, under the false impression that the project is winding down. The pressure is no longer on the backs of the designers.
  

• The designers are being pushed by management for visible results in schematics and the PCB layout. Unless there is a procedure or understanding that the BOM must be submitted to purchasing after the schematic review, this is often forgotten due to the immediate design issues at hand.
  

Unfortunately, there is a high probability that the purchasing group will find at least one part obsolete or that the lead time will not meet the project's deadline. As a result, there is a scramble to fix the design, estimated to be over $28,000 a spin (according to Lifecycle Insights September 2018), if one includes the labor to find a new component, make a new library component, correct the schematic and PCB, verify the component with the purchasing department, and generate new assembly and fabrication documentation.

Therefore, by entering components into the company database upon need, that component can be evaluated immediately. Furthermore, if a component exists in the database/library, the designer, in cooperation with the purchasing department, can check for obsolescence, prices, environmental and trade statuses, and lead times. This allows changes to be made in the schematics and PCBs before a capital investment is made to manufacture components.

Process Breakdown

Process breakdown happens due to the lack of automation between steps. When two databases are not communicating, there is a need to bridge process gaps with manual labor and secondary tools. As a matter of fact, MS Excel is probably one of the most highly used "bridging tools" used by designers. The odd part about it is that most designers don't even realize that they are doing this. The moment Excel is used to convert file formats or shuffle data into a format for acceptance by another tool becomes a bridge to cover a process gap.

If the process requires manual intervention like e-mails to bring something to someone's attention, there will be issues... Take the following example. Suppose that three people are involved in the verification process of library components. The library that all three are supporting is simple. The library does not have any automation or capabilities beyond storing components.

Let's assume that a designer sends an e-mail to all three librarians that a component is ready for evaluation and placement in the library. Or let's assume that the designer requests a component because the librarians care for the rest. Now the three librarians must coordinate with each other to know who will work on it. Furthermore, they will have to report that back to the designer to let them know that it was assigned. This will result in several e-mails. This may not sound too difficult, but imagine ten designers doing the same thing! In short, this requires a system that provides status to the individuals involved.

Let's take another example. As simple as it may sound to create a unique part number for a component, there will be issues with allocating company parts numbers when there are two databases. One may not like company part numbers; however, these are necessary because, in any database, there is a requirement for a column of information that is unique. One should NEVER use the manufacturing part number as the unique number because there may be two companies out there with the same part number. This will lead to the ugly decision of either changing one of the numbers, which will no longer make the manufacturing part number correct, or one will be forced to create a company part number column.

As an exercise, go to digikey.com and type '500' into the Part Number / Keyword field on the main page. This will result in a match for a battery holder and a type of 3M tape. You may not purchase tape for your design, but the company purchasing database is not limited to electronic component purchasing.

The purchasing database almost always allocates the company part numbers. Usually, the design group has to ask for a block of numbers. The issue deals with the management of the allocation of numbers. Unless someone has done a job of owning this allocation, this is usually relegated to a spreadsheet. Sure enough, everyone has at it, and it turns into hash. Missing information is the most common issue.

Unfortunately, the longer that number is not remedied, the more difficult it will become to correct it, especially if it gets into the purchasing database system.

Therefore, if someone is looking for points of failure in their library flow, most fail points are due to the lack of automation in specific steps. Unfortunately, most of these fail points cannot be adequately addressed outside of a single database unless there is a bridge (like Excel) or a custom script to handle these things.

Next Best Thing