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…

For over 20 years I worked in the manufacturing industry as a designer, CAD or IT manager. One issue I have seen and experienced many times is the difficulty of getting upper management to understand the need and benefit of getting the latest CAD, PLM systems, or any other IT systems. In each role there was always the need for new software to keep my teams and systems as productive as possible. In this blog I will, at a very high-level, outline how I was able to get upper management to buy in on projects I felt were needed.

Very early in my career I was a CAD administrator. At the time we needed new CAD software. I was able to talk to upper management very often. I would try to explain and tell them the need. I would verbally walk through the benefits and even give them demos of the software. But… they would not want to pull the trigger on buying the latest software. I could theorize with them until I was blue in the face. It just didn’t matter.

Then, a mentor of mine recommended I put everything to numbers, such as creating a ROI and roadmap of what was required to implement the new software. So, I did. First, I did time studies against what we were doing today. I did this by getting input from various different users. This was basically recording how long it took them to do the most common tasks. I would always take multiple samples and then take the average. Then, using a trial install of the new version of software I was able to get comparisons for each use case tested against current software. I put the time savings to cost savings based on hourly rate averages. I also related it to increased engineering department output capabilities. For instance, our department could produce four projects a year. With the time improvements we can now produce five.

The next time I spoke with my manager, I simply put a one page short summary of total potential time and cost savings in front of him. Which in this case, immediately got his attention. He of course wanted to know how I came up with those numbers. I had to be ready to back my numbers up. I did this by giving him a more detailed page and walked him through my findings at a high-level. I also had a page outlining the general implementation roadmap with a timeline summary. Only three total pages, not a short novel. He could no longer just dismiss or put off the need. I received approval to proceed with my plan in less than a month after presenting my numbers to my manager. In this case my manager was one of the company owners, but having hard numbers and a tentative plan got the ball rolling.

One thing to note from the above example, by doing what I outlined above, it elevated my standing at my company. They were impressed at my willingness to push for, justify, and plan for something I believed in. Not just asking them to take on the burden of something I felt was a good idea.

This scenario was repeated throughout my career. I could bring in vendors to demo their product, put quote after quote in front of management. Meeting after meeting with vendors and upper management, I could not get management to agree until I took the time to document the true benefits in time and money (roadmap and ROI).

If you have product or process improvements you feel will benefit your company, you need to show your management that you truly believe in it. You need to do the needed research and documentation to show the benefit and how you recommend proceeding. You cannot just go and tell management there are problems. You must present a solution for the problem you are identifying. If you do this extra work, it will not only help get your request approved, but will also help how you are viewed by your management.

Look, I know what I am outlining is no small task. It can be time consuming, very time consuming in some cases. That’s why many times this never gets done and needed improvement projects never happen. There is just not enough time for internal staff to do the needed research, and get their day-to-day tasks done as well. That is why you need to partner with a company dedicated to help with product development improvements at your company, such as EAC. We don’t want to just sell you software, we want to help you and your company improve the way you design, manufacture, connect to, and service your products. We do this with our proven people, products and processes. If you and your company improve and succeed, we improve and succeed. We will do as much of the work as we can to help you get the needed numbers and roadmaps put together. There is always going to be some time needed from internal people. However, we try to keep this as minimal as possible.

In summary, if you can see areas where your processes or systems could be improved you need to put it to numbers. You need an ROI and a roadmap to take to upper management. It may seem frustrating at times, but you need to understand where management is coming from. They also have people they answer to. They can’t go to a board, or an owner, or their manager with just a demo and a quote. Not only is that not the information they are concerned with, but you typically don’t get that type of time with them. They need quick and real information to justify the need. You must be willing and ready to get this for them. Just remember, EAC is here to help you do this. Please reach out to us.

Want to learn more?

We perform Product Development System Assessments (PDSA) for our customers. I’m frequently surprised by how many product development organizations still use email as their primary medium for the communication of information. Attached to these emails are test reports, marketing information, requirements, etc. Documentation that is critical to the performance of their product development!

I recently read a British study stating 38% of a knowledge worker’s time is spent looking for information. I can’t really believe that. We’ve run into organizations where it is that high, but not as a standard or average. But event if you discount that and cut it in half, that is about 20% of the time that knowledge workers spend just hunting for information. And this time spent hunting, this loss of efficiency, is invisible because it just gets buried with everything else inside the charges to project time within specific projects.

The other issue we have with email is that it’s open loop. It has no feedback. If the timing of the sending of some information is wrong, then the recipient will have to search through their inbox for the information after the fact and often times will ask for it to be resent rather than hunt for it. Also, you have various revisions distributed across the organization sitting on various hard drives – some of them current and some of them out of date.

When Bowen & Spears, famous researchers, talked about the need for a direct link between internal suppliers and internal customers, I think they talked about that connection as more personal, more collaborative, and closed loop. For your information flow, if you’re still using an open loop system, find a collaborative tool — PLM for instance. Help your researchers and knowledge workers take the pain out of their information flow.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive.

Follow Bill at http://www.twitter.com/systhinking

Recently I had an epiphany. It wasn’t the kind of epiphany that changes a life forever and drives someone to become a monk in the Himalayas, but it was an epiphany nonetheless. It had to do with collaboration, data management, reporting, and the way many of our customers inevitably deal with their customers.

For the sake of this blog I’m going to oversimplify the “discrete manufacturing” industry into two categories: Original Equipment Manufacturers (OEM) and OEM suppliers. Many of our customers supply larger companies. This puts our customers in a unique situation in which they operate their businesses within other people’s timetables. They operate their internal projects within larger projects managed by the end customer. This is where things can get tricky, but I digress…

I was grabbing lunch with a couple friends, colleagues, and long-time engineering veterans when the conversation veered into oncoming traffic. A simple question, “Does anyone have any meetings they need to get back for?” opened up a new line of dialogue. One of the engineers referenced a late afternoon meeting and started talking about the time they waste on redundant meetings with their internal teams and the end customer. Throughout any given week they have status meetings, update meetings, and check-ins on the updates and statuses. Everyone is always trying to stay on top of expectations and progress and it seems like it’s, well, getting in the way of progress!

The other engineer sympathetically chimed in because they both felt the same pain and frustration with the overhead of trying to GSD (Get $#!+ Done!). Throughout the conversation, phrases like “they didn’t hire me to attend meetings” and “I wonder if anyone is adding up how much these meetings cost?” were thrown around. I couldn’t help but think there had to be a better way…in fact, I knew there was a better way. You can dive in and learn more about Knowledge Worker Management and Time Boxing here, but for now I’m going to focus on the tools that can help GSD.

Nowadays the acronyms PDM and PLM have become common terms in the engineering and manufacturing world – Product Data Management and Product Lifecycle Management. These tools can relieve some of the frustration. If a company uses a tool like PTC Windchill to collaborate with customers and internal teams, they can set milestones, see real-time reporting based on work states, and manage changes easily and within clearly defined workflows. They can help provide answers to questions without needing to interrupt the engineering staff.

If you give us a call and a few minutes we can help you understand the return on investment in a legitimate PDM/PLM tool (something other than file folders and shared drives). We can help you figure out how much time and money PTC Windchill can save you – hard numbers that help the bean counters sleep at night. But, it is important to remember there are tangible benefits to improving your collaborative space that go beyond cycle times and promotion requests. Investing in a PDM or PLM tool can free up time for engineers to get back to engineering. An engineer’s lunchtime conversation should focus on the amazing innovations they’re working on. It shouldn’t focus on frustrating meeting-itis. Engineers aren’t cheap. Let’s get them back to work and out of redundant meetings. I think tools like PTC Windchill can help do exactly that.

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.