Integrating OpenBOM with Enterprise Resource Planning (ERP) Solutions Part 1 of a 3 Part Blog Series
/Why integrate OpenBOM and ERP? What would such an integration do? And how is it implemented? These questions will be the focus of a three (3) blog series.
So let’s kick it off with the first blog and a short (re)visit to the popular theme of the “digital thread.”
Simply put, the idea of the digital thread is to link data that is generated from across the product lifecycle of activities. There is a lot of buzz around this concept. Analysts, software vendors and industry thought leaders all purport its importance and value. Organizations may not use the same phrase, but they want and need improved efficiencies, the ability to streamline processes, automate menial and repetitive tasks, and ultimately improve their performance and competitiveness.
It’s no wonder, the product life cycle is a maze of inherently disconnected manual processes and applications independently producing a steady flow of product-related content. These applications can include product-data management (PDM), enterprise resource planning (ERP), manufacturing execution systems (MES) and a slew of others. OpenBOM has PDM functionality or can be integrated with PDM, but as the product life-cycle management (PLM) platform, it sits right in the middle of it all.
It might be argued that the “digital thread” is really code-word for “integrations.” The fact is that without connecting systems together … there is no digital thread. Instead companies have improvised with intervention-based activities disguised as “processes” seeking to overcome disconnectedness.
Automating the exchange of data between OpenBOM and ERP is a critical step towards building the digital thread. Think of OpenBOM as the process engine and ERP as the transaction counterpart. OpenBOM is the headwaters of product data. That’s where parts are defined, relationships and configurations are established, changes made, etc. ERP and other downstream applications act on this data.
The most common use case for an integration is the “part/bill of materials (BOM)” release process. Once the parts of a product configuration are ready to be purchased, outsourced and/or manufactured, they typically need to be transferred to an ERP system. This is where purchasing, inventory planning, production scheduling and work orders are initiated.
It is not unusual for BOM structures to be comprised of tens or even hundreds of parts. Historically, a list of parts to be released would be given to someone to manually enter into an ERP system. Consider all the steps involved … check to see if the part exists, if not, create the part and enter the numerous attributes associated with the part, then check relationships and update relationships, check to see if a preferred vendor/supplier exists, associate the part that vendor/supplier, plus potentially other administrative operations. It can easily take 15 to 30 minutes per part. As can be imagined, these steps are fraught with the potential for error such as typos, not finding what is needed due to inconsistent nomenclature, or simply overlooking details. And these errors filter to the downstream activities in the product lifecycle and are only further amplified.
The cost of these errors is real and manifest in the expense associated with redesigning parts that already exist, scrap and rework, overlooking make or buy opportunities, expedited shipping expenses, warranties, etc. From a business perspective, this is classified as the “Cost of Quality” (CoQ). COQ is ultimately a profit drain and is estimated to represent 3 to 10 percent of a company’s annual revenues.
By integrating OpenBOM with ERP, an organization is effectively taking steps to reduce their COQ. The digital thread or rather integrations are not just a nice efficiency tool, but a business imperative.
Part 2 of this series will continue the discussions with a look at the common use cases an integration would facilitate. Part 3 will “pull up the hood” and take a closer look at the “how” of integrations.