Do You Need PLM, ERP, or Something Else? The Power of Understanding Your Problem

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” This saying is often attributed to Albert Einstein, highlighting the significance of thoroughly understanding a problem before attempting to solve it. However, it’s worth noting that, while this sentiment aligns with Einstein’s approach to problem-solving, there’s no concrete evidence or source confirming he expressed this exact phrase. Nonetheless, its core message remains impactful: a deep comprehension of a problem often paves the way for more effective and efficient solutions.

Over the past few years, I’ve spoken with thousands of engineers and companies that have reached out to OpenBOM, seeking solutions as part of their problem-solving process and solutions for engineering, manufacturing processes, and product lifecycle management. I’ve spoken with users who have left us hundreds of reviews on G2. We’ve seen companies come with problems in mechanical engineering, enterprise resource planning, electrical engineering, and other engineering disciplines. Sometimes they focused on core business processes and sometimes were looking for specific problem-solving techniques and engineering tasks. They were looking for product lifecycle management, ERP software, accounting software, and supply chain management and all of them were about to solve problems of business processes. However, their problem-solving process was different and not always focused on “PLM”. Some of them focused on mass production and others on custom development and engineering to order processes.

While each company used different problem-solving skills, their approaches have led me to reflect on how these organizations address their problems. One might assume that all manufacturing companies have a uniform thought process, but the reality is strikingly diverse. Modern manufacturing companies are using a variety of diverse disciplines to develop products – mechanical engineering, computer science, and computer engineering are combined with electrical engineering and problem-solving techniques. Often, the initial description I hear from an engineer or a company about their issues contrasts significantly with how they articulate it after further reflection.

Pattern Matching vs. Problem-Solving?

It’s crucial to fully grasp the problem before seeking its solution. I believe that readers of our blog would benefit from understanding the various perspectives on engineering, manufacturing, data management, collaboration, product lifecycle, bill of materials, purchasing, supply chain, and all associated disciplines.

I’ve identified three fundamental approaches companies use to address their problems:

1. Jump to a known “noun”. Map the issue to one of the existing product “nouns” or categories (often represented by three-letter acronyms) like CAD, PDM, PLM, ERP, QMS, etc.
2. Opt for implement a familiar “pattern”. This usually entails an attempt to automate a current manual process using software tailored to a specific task. Examples include exporting to Excel, transferring data from Program A to Program B, or organizing “files” or “documents” in a designated location. Check my article – The secret why engineers are using Excels instead of PLM was finally revealed.
3. Seek ways to support a specific process, such as New Product Development, Costing, Supply Chain, Procurement, etc. This involves recognizing a problem (or multiple problems) and then discerning which “solution” can rectify it.

While solutions can be found using any of the above approaches, I’ve observed that companies opting for the third method tend to have a more pronounced advantage. This is especially evident when compared to businesses merely looking to purchase a software “box of features” or those attempting to digitize an already chaotic mess of paper or electronic documents.

The Emphasis on Data and Process

Looking back over the past 20 years, there’s a marked trend towards positioning “data” at the core of business operations. This distinction sets modern digital companies apart from traditional businesses. Observe how businesses in various sectors, such as transportation, social networks, real estate, and many more, first define their data and then establish business processes dependent on this data.

Conversely, many manufacturing companies originating from the pre-digital era treat data as secondary. For them, data is merely an “outcome” of the process; for instance, CAD files emerge from the design process, while the purchasing BOM results from the procurement department’s endeavors. The primary challenge these companies face is their inability to structure processes and businesses around data.

As we transition deeper into the digital age, I believe companies should prioritize data. They should delineate how they function and how their products (or services) can be digitally represented. Once achieved, their approach towards finding solutions will undergo a transformation. Rather than merely considering how “to integrate PDM, PLM, and QMS with Document Workflow”, businesses will be outlining all data elements that describe their product, pondering process flow, and establishing KPIs to evaluate process efficiency.

OpenBOM: Pioneering the New Product Development Paradigm

At OpenBOM, we champion the idea that companies can progressively structure their processes around data using phased agile development. Typically, your journey with OpenBOM commences with the definition of data objects such as Items, Catalogs, BOMs, Vendors, etc. Once this foundational data is defined, the next step involves capturing and creating additional data. After successfully establishing how to store this data, companies must then address the organization of processes.

OpenBOM assists your team in streamlining new product development processes. It does so by consolidating multiple tasks and facilitating data sharing among users, enabling them to actively engage with and act upon this data. Here are some standard activities that our OpenBOM users deem crucial:

1. Defining the product structure, inclusive of individual items.
2. Organizing item catalogs.
3. Managing files or sourcing links from cloud data repositories.
4. Capturing the product structure, along with associated files.
5. Undertaking analyses, such as cost evaluations.
6. Identifying vendors, and formulating production plans and purchase orders (POs).

It is very important for companies to implement their PLM playbook. By creating a playbook, companies can move from lookin for a “noun” and “selecting checkboxes in PLM feature list” to analysis and understanding of problems they want to solve. At OpenBOM training library, we developed an onboarding training, that helps companies to discover what problems they need to solve and how to approach them in an agile way.

In Conclusion

Understanding data and processes is paramount. Trying to “guess” the appropriate three-letter acronym to align with your needs is a risky approach, especially in the 2020s. Digital transformation zeroes in on defining data, organizing information streams, and determining how a company can make decisions based on this digitally-defined data.

REGISTER FOR FREE to see how OpenBOM can assist you.

Best, Oleg