How much flexibility is too much?

Author – Tim Smith

“…it is very much up to the customers to innovate based on their unique environments”

This statement and many others like it are attractive to a wide range of manufacturers because everyone “thinks” their particular business is unique so therefore a really flexible system where a company can build exactly what they want, is appealing.

I have made a statement which, I am sure that some of the readers will take exception to. I said that you are not unique. Let us start by examining this statement.

By definition- noun, a person or company that makes goods for sale. Ok, we agree with that statement.

How then do we define manufacturing? Manufacturing is the processing of raw materials or parts into finished goods using tools, human labor, machinery, and chemical processing. Large-scale manufacturing allows for the mass production of goods using assembly line processes and advanced technologies as core assets. Are we in agreement so far?

Further to defining your manufacturing, there are three main types of manufacturing production: make-to-stock (MTS), make-to-order (MTO), and make-to-assemble (MTA)… and combinations of each. Let’s go a little further, most manufacturing environments fit into one of five general categories. Repetitive, Discrete, Job Shop, Process (batch), and Process (continuous). Most companies use more than one of these environments to get a single product out the door. What defines you to your customers? Product quality, price, availability, reliability and customer service.

Well then, how about manufacturing systems?

Continuous Manufacturing System.

Intermittent Manufacturing System.

Flexible Manufacturing System.

Custom Manufacturing System.

So, I think that every manufacturer can define themselves within the framework above. What about the tools that help drive the process? Various types of software are used by manufacturing industries, such as product development process (PDP) software, product data management (PDM) software, product life-cycle management (PLM) software, enterprise resource planning (ERP) software, computer-aided design (CAD) software, computer-aided manufacturing (CAM), and one or two other software types.

Since all the above frames your manufacturing definition, then you are not as unique as you think. I am not debating your corporate vision, mission statement, key personnel, team spirit, etc. I am leveling the playing field by which I can then begin to speak about how much flexibility is too much.

Let us talk a bit about software and flexibility. Everyone has a horror story about going through an ERP or MRP rollout. Since the enterprise software is so large and so flexible and has so many options, it cost much more money and time to implement than any estimate. In fact, the estimates were not even close. Now over time all these systems have refined their implementation to reflect more structured deployment. The ERP and MRP vendors have learned that most manufacturers do have very similar structures. However, there is a fundamental differentiator in a software’s adoption, either have a software which adapts to a company’s process or change the company’s processes.

Changing a company’s process is an uphill battle and is usually where software implementations stall or fail. Providing a software solution which adapts to a company’s process is where the challenge lies.

Many software vendors which have had their beginnings in SCADA, HMI implementations, etc. offered a hugely configurable system usually requiring development and code additions to make it work. When finished, the customer had a system which, by it’s very nature was fit to their business but difficult and costly to change. In fact, the structured deliverable impeded the ability of the human process to evolve because the system now dictated the process and not the other way around.

Let me illustrate this point. My apologies for the simplification, but I am sure that the reader can backfill to their own environment. QC has an established a process which was then captured and implemented into a manufacturing operations system. The system was, as described above, a custom-tailored system to mimic the process. When a downstream defect appeared, the process would halt respective production and sample check all the incoming parts for the operation. If the defect rate fell outside of being capable then a manual investigation of the defect source of all upstream operations would ensue, investigating either materials or processes. The QC manager has determined that a “Red Tag” process would help in reducing scrap and mitigate defective parts being overlooked. The new process would need an alert system which would alert key upstream processes to hold production and tag suspected lots. Unfortunately, to add the new process to the tailored operations system is complicated and costly. The flexibility of the original system has proven detrimental to the ability to adapt.

Let’s look at the initial implementation of a open ended super flexible system where “…it is very much up to the customers to innovate based on their unique environments” Most manufacturers can’t spare their key engineers, CI practitioners, IT and development staff, supervisors and production teams to create a steering committee to define what the new tools would look like. Remember that the consensus is that you are unique and that the processes you already have work. To customize a super flexible package from the ground up becomes a monumental hurdle. You cannot commit enough resources or time to define and implement the system yourself. So, you pay for a massive amount of services to accomplish the task. The issue is that there is a shortage of critical development talent to achieve your goals. I have talked to numerous manufacturers who have committed to an enterprise deployment as described above only to be two or three years into its implementation and not have a working system anywhere in the enterprise. On the other hand, there are several boilerplate solutions that will give you some results rapidly, some in a matter of weeks, that is something to work with. But they are rapid to deploy and thin on results. They can only do so much and are rigid in their implementation. The return on any investment is culled out quickly.

The challenge is to find a manufacturing operations management system which does not repeat the failures of its predecessors in an over complicated, super flexible implementation. A system with proven structure, because all manufacturing falls into certain categories and processes, and the adaptive flexibility to mimic your process without limiting the ability to further adapt. Yet it also must be designed to scale, adapt, and evolve, without a huge direct development penalty. No company wants to employ developers not dedicated to core capabilities such as automation and robotics, CAD, material conveyance, etc. You would never think of tackling an ERP development, why would you want to tackle an MRP or MOMs development? The products today have taken man years and possibly millions of dollars to develop. If you are assessing your next phase of Industry 4.0 and evaluating or just assessing feature and function, do not get infatuated with the ability to create the perfect mousetrap. It will rarely happen. Look for a system providing functional support for critical aspects of your manufacturing process, such as machine operational event capture and key process data (not all discrete machines support this aspect so don’t get hung up on it, that’s why IIoT exists. Ask the vendors). Does the system include human data capture? Does it support all aspects of your production scheduling? Work orders, OpSteps, Product standards, asset overrides, Part # or product profiles. Does it support labor ticket creation for direct labor, indirect labor, breaks, etc.? Does it support workflow, e-alerts, ticket escalation, operator HMI, mobile access, email, and text alerts, etc. If you select a platform which supports these functions, it’s far easier to build on them than having to start from scratch. If a vendor does not have the depth in their product to support all aspects of handling jobs, then do not ever expect it in the product. A good vendor has built into their platform the ability to adapt, adopt, scale, and evolve. Vendors should have a modular platform allowing for new functions, features, metrics and KPIs to be added to the platform rather than the software rewritten to accommodate it. You never want to have a snowflake system where it is different from everyone else using it and therefore needs costly ongoing development. Do not get hung up on machine connectivity either. Good vendors have productized the approach and can connect and configure machines with native software protocol in a couple of hours. They should be able to install and capture data from legacy machines in a few hours. The process should never take days or weeks to add machines. In my experience, I have seen a facility with up to 100 machines connected and reporting in a month. I have seen smaller implementations of 50 machines or less connected in one to two weeks. Usually delays on the shop floor are due to insufficient network drops, insufficient server resources, time to access machines requiring hardware not scheduled, lack of personnel to dedicate to the implementation, fractured communication between IT, OT, production and management. (That’s a different article).

Once the machines are connected then the flexibility of the system comes into play. No one should have to develop anything at this point for typical deployments. It should all be user configurable. That’s as much flexibility as needed. Most users want to follow a structured approach. Since the system is “New” you will rely on the initial structure to get you going. Then, as your teams leverage the system, they will either configure new views and reports or ask the champion to do it for them. Then in the event that something needs to be created that is totally unique to your organization (though I doubt it), which is rare, the system easily supports the addition of a new view, page, widget, (something shiny) quickly and affordably. Thereby giving you the best of both worlds, a cost-effective platform ready to go out-of-the-box and the ability to support any unique additions. I had a casting company who put the system in. out-of-the-box they were collecting data on all furnaces, and at each step of the casting process. They wanted a special HMI to reflect per cycle data. Rather than having to code whole new web pages for them, the addition of a couple of widgets enabled the standard operator interface to evolve into a casting HMI. Another company wanted a “special” inspection station HMI where an operator could quickly categorize a reject. It took fifteen minutes to configure the view. There was a request for a “special, absolutely unique view” to be created exactly from a custom HMI view from another facility in the organization. It took three days to create the unique view. If the system you are investigating treats every view as something to be developed, run for the hills. If the system you are investigating has canned views with simple “user configuration” for data, then it does not fit the definition of configurable. A user should be able to pick elements (widgets, templates, controls, etc.) and add them to a page view and configure them to present data. I don’t mean configuration where the user has to know how to connect to a database and create inner and outer joins to aggregate a data set. That is enough to send anyone over the edge. It should be as easy as pick a machine or group, pick a data type like event, metric or process, pick a time scale like shift, hour, job, etc. and then select the data item from the list, done. Then you can dress it up, change colors, fonts, sizing, position and save. Add a couple to a dozen widgets to a view and voila, a comprehensive dashboard.

Then, you should be able to publish the amazing new view to a library where anyone in your organization can get a copy.

The journey may be new to you. It’s not new for me. With a decade of shop floor experience and a few decades of software and IT experience and a decade of Manufacturing Operations Management, I may have a little insight. My mentor would say, “I may be wrong, but I think that you could look at it this way.” FLEXIBILITY is defined as “The ability of software to change easily in response to different user and system requirements.” That is the key. Giving you the alphabet and telling you to write whatever story you want is in line with many of these developmental toolkits. On the other hand, selecting a product because it’s easy to install and is uncomplicated with a handful of options means you will outlive its ability to provide a recurring rate of return. The Flexibility is in its ability to easily change. As you change, it changes. As you adapt it adapts. As you grow, it grows. Choose carefully and wisely.