Why bother with the Internet of Things (IoT)?

Great question! Maybe to understand your product, make a deeper connection with customers, create a new business model, increase revenue or even build a new revenue stream. Perhaps you’d like to find out what your products are doing after you sell them and figure out which features to include or remove from your next iteration. There are piles of ideas and ways to make the IoT work for you. In short, however, it depends on your initiatives — and the IoT could be just the thing you need to move your initiatives from “How are we gonna do that?” to “This is gonna be awesome!”

When considering your corporate initiatives and the IoT, I’d encourage you to integrate them rather than looking at them as separate things. At EAC, our Connect Services (the way we help customers achieve their IoT objectives) starts with strategy. You’ve got to make a connection between the motivation to have smart and connected products and your initiatives. In other words, your approach to the IoT could be the central catalyst of your initiatives. Otherwise, it’s just a fun and techy science project without clear direction.

Let’s say you’re a forward thinking company and you call yourself innovative while having a goal of improving dealer service capabilities and increasing end-customer engagement. Perhaps you could build a whole new business unit that collects data from your product in the field and distributes use and service information back to your dealers as they provide service. It could increase revenue (data/subscription sales to dealers), increase your ‘innovative edge’ as perceived by your end customers (through apps and product information) and feeds feature and performance data back into your design cycle. You could aggregate the data from your products in the field to your ERP and MRP systems and have truly integrated (connected) PLM into your business. Just for the sake of argument, this could include role-specific mobile device apps for dealers, DIY repair, data junkies and regional usage maps. We could even weave this into production and procurement roles and have data actually ‘flowing’ in several directions. Who knows where it could lead.

Ok, now back to avoiding the ‘science project.’ The key is to have a strategy — figure out why you want to be part of the IoT and then go do it. Our goal at EAC is to help companies transform the way they design, manufacture, connect to and service their products. As a part of that, we’d like to help you build your strategy, devise ‘connected things,’ and implement a facilitating platform easing the access, sharing and use of the information. This 3-legged stool is what we place our IoT strategy on — next time I’ll talk more about the ‘things’ or the ‘platform.’ For now, how can we help you build your IoT strategy? Let us know…

I find that people tend to blur the lines between ERP, MRP, and PLM. The purpose of this blog is to summarize the high-level intent of most ERP, MRP and PLM systems.

ERP — Enterprise Resource Planning:
One of the biggest driving factors for the need for an enterprise-class ERP system revolves around finance/accounting. Anything that is related to income or expenses must be tracked in extreme detail. To properly manage finances, many other aspects of the business need to be tracked and controlled in a transactional manner. Everything from human resources, sales, returns, shipping, inventory, and so on. To ensure all information remains accurate very strict rules and processes are set up. There are a vast amount of ways ERP systems can help a company manage their business. Many companies find benefit and are almost required to have some sort of ERP system. These systems help them manage their business in today’s market full of government regulations and reporting requirements.

MRP — Material or Manufacturing Resource Planning
Both of these have a very high level of detail around material tracking. Material Planning tends to focus more on the cost of material and its location at any point in time. This can include everything from shipping, lead times, actual cost, to material movement throughout the manufacturing process and the cost associated with it. Manufacturing Planning also has a detailed tracking of material. However, these systems tend to focus more on the manufacturing process. One specific thing they tend to track is work cell details. Some examples of this tracking are the material going into and out of a work cell, the resources required for the work cell to operate, tooling required at each work cell, and in some case detailed work instructions for each process required at the work cell, and much more.  These systems still have a very tight process that must be followed for control of the manufacturing or assembly process. Variations to the process are not typically permitted unless it is a defined; pre-approved process variation.

PLM — Product Lifecycle Management:
Good examples of these systems tend to have a completely different mindset from ERP or MRP systems. PLM is all about the management of the process behind the product, from conception to sunset, as well as the history and collaboration that goes along with it. The focus tends to be on a more dynamic and flexible way to allow people to focus on the development of a product, not on transactional functions related to it. Most PLM systems also typically have a PDM (product documents management) system inside of them. PDM is used to control the history of the intellectual documentation needed to design and manufacture a product. Everything from CAD (computer aided drafting) files to general production specification documents. PDM ensures this data stays as accurate as possible through versioning and access control based on the state of the object in the overall design process. Better PLM systems also have Program, Project and Change Management processes built in. PLM then combines all this functionality into an overall product lifecycle management process.

Many larger ERP systems offer modules to do MRP, PLM and even PDM. In many cases, these add-ons just do not have the detailed functionality needed or the flexibility required to accomplish what the customer is looking for. For instance, I personally have participated in the development of an MRP system. While the ERP system we used had a type of MRP module, it did not track the details or allow the flexibility we needed at the work cell level to control our assembly process.

I have seen many examples of larger companies also using a major ERP system to do PLM. These same companies then find out these systems are just too limited in both functionality and flexibility to allow engineers to develop and design new products freely. Another area ERP tends to fall short of the companies expectation is with PDM. Often the problem is with the lack of integrated control of the CAD files. Due to this limitation, it makes the interaction between engineers and the ERP system tedious and time-consuming.

I personally feel these ERP systems tend to fall short in these areas is due to their focus on transactional functions and very tight controls. Based on their origins around finance, this type of control is completely and understandably needed. Because of this, there is little to no development around the flexibility needed for free-flowing processes often required in the product development environment.

Some best examples of a complete implementation of ERP, MRP and PLM I have seen are companies that have utilized the best of each system based on their business needs. They then utilized integration methods so appropriate data is shared between all systems. Some of the most painful examples I have seen are companies trying to change and force their internal business processes into the envelope provided by an OOTB ERP system. Or worst yet, paid a very large amount of money to recreate the wheel and customize their top level ERP system to do what they need.

In the end, all of these systems have a place in today’s business. They each have strong points and weaknesses. Just be cautious of any company that claims they can do it all. Remember the quote; “Jack of all trades, master of none.” Why not get a team of “masters” and have them work together.

I’d like to start off by clarifying the difference between eBoM vs eBoM. Most companies developing products have both an eBoM and mBoM.

• Engineering Bill of Materials (eBoM) — as designed
• Manufacturing Bill of Materials (mBoM) — as shipped

You may not agree, many don’t see it this clearly. The industry does, and therefore, some software tools have more ability than you may know. But, I guarantee, if you overlay these two elements onto what you are doing for Bill of Materials (BoMs), whether in Engineering, or in Manufacturing, or in Production, you’ll see the clarity of these two simple elements rise to the surface.

Definition of eBoM and mBoM:

eBoMs are created in engineering, are typically driven from the CAD tool, and are usually centric to the final assemblies list of parts or components that make up the as designed or eBoM.

mBoMs will contain, or be ‘driven’ by the eBoM. MBoMs make up the ‘end item’, or product as shipped. Of course, the eBoM, or ‘parts list’…the eBoM requires additional things like shipping containers, crates, peanuts, or packing foam, plastic bags for accessories, power cords, or items necessary to complete the product that is not defined on the eBoM.

Manual processes for eBoMs & mBoMs

In the drawing board days, we often communicated this detail as a table on the final assembly drawing. Sometimes as many sheets attached or referred to on the final assembly drawing. Hopefully, you’ve evolved beyond that! If not, that’s okay, there is hope. Unfortunately, many still use this legacy approach and are still creating (painfully) this table on their CAD assembly drawings. Others may be manually forming them in spreadsheet software.

The next step, and pain point, you must re-enter or get the data into your ERP/MRP tool. Either manually, or via an importation, it is error-prone. What if changes occur? But, that never happens, right?? Ha.

How much time does your organization spend on these tasks? How about errors because of changes? Do you have the role of Configuration Manager defined?

The task of creating the mBoM from the eBoM usually has many manual and painful disjointed steps. Often involving exporting out of one tool, into another, but only if you are evolved enough — as I stated earlier, many are not this evolved, but have the vision to do so…maybe you’ve already made a connection from your data management tool to your ERP/MRP system?

PLM Systems like PTC Windchill help you manage your BoMs

EAC can help you form this vision, and guide you to a better way of understanding this topic in the context of your organization. We strongly believe there is a better way to develop products – and managing eBoMs and mBoMs is just one part of doing it better.

PTC Windchill can drive the eBoM into the mBoM or vice versa. It has the out of the box ability to be the tool for the Configuration Manager roles in your organization. Options and variants are another use case you’ll see in a future blog topic.

Organizations have found ways to leverage PLM systems that transform their product development process and defeat pain points like the disjointed processes that come with manual creation of the mBoM from the eBoM.

Take a look at the Aberdeen PLM Research revealing that organizations with connected PLM see a 22% increase in engineering productivity and 21% improvement.

If you’re looking for a PLM solution such as PTC Windchill, our Product Development System Services (PDSS) team can help implement the software within your organization.

Download our free eBook on Designing an Effective Change Control Process to help understand the digital transformation movement better.