Paging Dr. Lean

Monday, April 8, 2013

Paging Dr. Lean is brought to you by Patricia E. Moody, The Mill Girl at Blue Heron Journal. Submit your Paging Dr. Lean questions to tricia@patriciaemoody.com.

In the Paging Dr. Lean series, Patricia E. Moody asks lean experts to answer your lean questions. This forum allows industry leaders to speak to the lean issues or questions you come across each day.

Dear Dr. Lean:
I hope you can help me. I work in production planning in an assembly plant — we make heavy equipment for construction. We do lean on the floor and we have good purchasing, but the ERP is making me crazy. We are going to a new package that's cloud-based, which is great, with some good analytics. But we've got these other systems chugging along — engineering updates, forecasting and demand history, scrap analysis and quality monitoring by product line. Some of the old system information is critical for our everyday work and some of it we only review quarterly.

It looks like I will be heading up the production planning new system implementation team and I need some help on developing a project plan. Is it possible to run two systems at once, or should we go live immediately on the new one? How do we move critical data elements — bills of material (BOMs) and routings, costs, etc. — over to the new system, or should we get a temp to do it for us? I've heard about sunsetting but I have no idea where to begin.

Thanks Dr. Lean,
Hopeful in the Midwest


Dear Hopeful:
Welcome to the real world of manufacturing systems! Your situation is typical, and it warrants some strict adherence to change management processes to maximize benefits and lower the risks (gaps, expectations, job roles, communication, training and funding). I'm assuming that ERP justification, business analysis and value-stream mapping are complete, and that you're tasked with a project manager role for a module implementation. It will be good to review the ERP original proposal documents so that you can be consistent. If you are in the ERP evaluation stage, the questions and the process are very different — the reason for the change, proposed process, gap analysis, future network architecture, future customer demand patterns, integration strategy, etc. Be happy that you are in the beginning stages of implementation, and with some discipline, you'll be a shining star.

While lean is heavily enforced and concentrated in the manufacturing area, it has not caught the same steam in IT. Based on your situation, it looks as though there will be operational work-arounds to adhere to ERP, as the decision might have been technology-driven versus business-driven. You've got to go through detailed needs analysis mapping to figure out what information is used where, and how it is input, interpreted, used and passed on. For each data element you're planning to collect or use on the floor, conduct process mapping using any tool. For example, when staging a material for production, you access inventory records, confirm staging, move and verify that the material is QA certified, verify that the material is not damaged, and input and verify the quantity. This way, you can avoid redundancy, inaccurate data sets, reduced productivity and the mushroom effect. If no action is taken to address this challenge, you'll have information silos. (Lean Management Principles for IT by Gerhard Plenert is a good read.)

Additionally, the complexity index (degree of difficulty, personal competency and the number of systems required to collect a data-object versus what incremental value it is generating to a customer) and opportunity costs have to be identified so you can start sunsetting the old high-maintenance legacysystems to reap the ERP benefits, withmore features, analytics, etc. That may require enhancements or add-on packages based on your gap analysis. The aim is to leverage a single database and share the information corporate-wide for consistency. Naturally, you've got to run the old and new systems in a test environment with maximum volume, using lots of realistic and complex test cases, prior to sunsetting to make sure the new system covers all needs and is ready to go. Typically, running the dual process can range from one to four months, depending upon the complexity.

Good luck with the transition, as change is always fun, if it is beneficial and approached positively!

Yours truly,
Murali Ram
Partner at Rivulet Solutions

Murali Ram is a senior supply chain management leader with global expertise in designing and developing complex and innovative customer solutions. He enjoys strategic and tactical end-to-end supply chain consulting due to breadth of knowledge base. Well-versed in supply chain planning and execution IT tool kits to revamp and enhance solution offerings, based on business analysis.


Dear Hopeful:
You should make your decisions on one of the most fundamental principles of lean — that is the concept of focusing on value-added processes. If it doesn't add value in the eyes of the customer, it is waste. So, most of everything you speak of is pure waste. Now, with that said, waste is a necessary part of every production system. Your key is to make sure the waste processes are minimized, and don't get in the way of the value-added processes.

Now, let's assume heavy equipment is typically a low-volume, long takt-time environment, moving at a predictable pace that changes slowly. In that case, just do an ABC classification of your procurement needs and focus on the high-dollar impact items. You can directly display your inventory to your suppliers for the A items, and let them replenish based on consumption and inventory levels. Put your C items on an automatic replenishment systems. For your A and C items, send your suppliers whatever information your system regurgitates, and caution them to pay more attention to what you consume than what the system tells them about the demand forecast. After all, when have you ever seen a forecasting system that's accurate? What's left are your B items, so put your energy into those.

When migrating to a new system, remember that any system will take twice as long, cost twice as much and hurt twice as much as the IT leaders say it will. Make sure the IT leaders have a rock-solid process of migrating all of the critical data before you allow the new system to launch. Your first instinct will be to wait until you think it's really ready before pulling the trigger. But guess what, it will never be really ready. Make sure the fundamentals are sound, such as BOMs and routings, lead times, process times, etc., and then go ahead and pull the trigger. Launch your new system, but let the old one run in the background as a backup check.

Cary Weisenberger

Cary Weisenberger has 27 years of manufacturing, quality and supply-chain experience in aerospace, automotive, pharmaceutical and electronics implementing quality, operations and supply-chain transformations using lean manufacturing and six sigma concepts. He is a mechanical engineer, lean expert and certified six-sigma black belt.


Dear Hopeful:
Migrating from one ERP system to another is rarely smooth and trouble-free. However, following the recommendations I have outlined should be helpful.

Many ERP system vendors provide data conversion assistance. The ease and cost of data conversion is pretty much dependent on what system you have versus the new ERP system. If your new ERP system vendor provides data conversion assistance, carefully assess what it can offer. It may be well worth it. Remember to thoroughly test and retest all systems, including data conversion programs, before going live with your new system.

I am not sure of the size of your plant, however, "heavy equipment for construction" sounds like fairly complex machinery, possibly with a lot of features and options. Typically, that would mean your data volumes are high enough where manual handling of the data conversion (i.e. "get a temp to do it for us?") would be difficult. A manual conversion effort would be time intensive, and, in my experience, very prone to introducing more errors into your files than currently exist. Compounding the manual conversion problem is that data is constantly changing, which means maintaining two systems will be required and the probability for errors increases as the conversion cycle time lengthens.

When converting from an old system to a new system, it is a good time to correct data file errors. If you have maintained your data at a high quality level, that is a real good thing. But if your data is suspect or incomplete, there is no payoff from converting bad data. Usually, it just postpones correcting the data problem, but worse, decision-making support will not improve.

Do not try to run two systems at once. Three good reasons not to do it are: 1. You will have to maintain both systems. 2. The system outputs will often not be comparable and will lead to confusion. 3. There is no value to having two systems.

Going live with a new system is the critical juncture. Addressing data accuracy and the data conversion methodology is only part of the work required. I recommend you set up your plant in mini-test form (conference room pilot) on the new system and test, test and test all of the likely scenarios users will encounter. Users will learn a lot from doing extensive scenario testing. When you think you have all the glitches identified and many of them fixed, it is time to train, train and train some more. Having your system users well-prepared is essential.

In any case, be sure to have your trainers deployed and ready to help users at new system start. There is usually some confusion and probably a few "gotchas" when a new system goes live.

Lastly, and very importantly, is process. Based on some of the words you used in your "help request" concerning lean and ERP, I am wondering if process conflicts are in your future. For example, will MRP plans conflict with a pull system on the assembly floor? Worse, if you are doing well with flow in assembly, traditional scheduling logic that uses backward scheduling with fixed lead times, constant queues and infinite capacity will not support a lean flow process. In fact, it is illogical logic.

If your new system will not support your old systems that you can't survive without, then those separate systems should be "attached" to the new system. Automated data conversion (recommended) and interfacing any old systems will require IT support.

Remember, data preparation, pilot testing, training and data conversion will take most, if not all, of the pain away.

All the Best,
Mike Donovan

R. Michael Donovan has been a consultant to manufacturers worldwide for 35 years. In addition, he spent three years as vice president of operations for a six-plant large machinery manufacturer. Mike has extensive experience in operational excellence including ERP, lean, six sigma and supply chain management. Currently, he spends most of his time with strategic planning, strategy execution and the development of intentional cultures.


Dear Hopeful:
Regarding your first question, it is possible to run two systems simultaneously. However, most organizations have major cut-over problems when they try to do so. First, it requires twice the effort, resources and overhead to run two systems. Second, there are people who are afraid of change and will cling to the old system as long as they can. Third, when you are running both old and new systems and something isn't working on the new system, people under pressure to "get ('er) done" will gravitate back to the old system. All of these cause severe disruptions and inefficiencies in implementing the new system. Adapt the goal of one system, period. My suggestion is to create a detailed and well-structured implementation plan because it will create a shared understanding by the team regarding the critical tasks, milestones, risks and metrics. Make sure that you share this plan with executives and the organization so you have continuity of purpose. Then I would follow the plan, complete all of the preparatory work and education well, and then go live with one new system as a goal. There is a lot more to your new assignment than installing the software; it's a great time to clean up data and reengineer business processes to ensure more value-adding transactional processes and a much better operating environment.

Regarding your second question, I always develop teams of users to load and move over critical data elements. It takes more time, but it is being done by people who understand the nature and importance of this data. User-based teams also have more skills in terms of improving data integrity during this process. Temps take the work load off users, but most do not understand the functions of BOMs, routings, product masters, etc., so they do not realize the severity of keying errors and other data-integrity problems that are discovered during this process.

Regarding your third question, I understand sunsetting to be a practical, gradual cut-over to the new system. The world is not perfect; there will be unknowns and unanticipated implementation issues — and force-fitting a 100 percent cut-over on day X may create lots of problems. Your new cloud-based package will not be a "plug-and-go" architecture because there are so many people, process and data dependencies. Think Pareto and take care of the larger implementation issues. It may make sense to parallel a few activities temporarily until the time is right to go 100 percent. Don't go for an all or nothing implementation. Recognize that although your goal is 100 percent to go live on the new system, be real and don't be disappointed if your cut-over is 80 percent for a while. But put all of your efforts into implementing the new system successfully. The goal should always be one system, as fast as possible.

In summary, the key to your success is executive commitment to a one-system goal, and a well-thought-out implementation plan right up front — with very detailed tasks, responsibilities, timetables, deliverables and performance criteria. This should become a living plan that guides the implementation team(s) through the transition smoothly and successfully. It's a plan — be prepared to change the plan and the plan to change.

Terence T. Burton

Terence T. Burton is president and CEO of The Center for Excellence in Operations, Inc. (CEO), a management consulting firm with headquarters in Bedford, NH, and offices in Munich, Germany. Terry has nearly four decades of diversified experience in executive leadership, operations, supply chain management, quality, engineering and product development, software development, distribution and logistics, maintenance and repair, customer service, finance, sales and marketing, and recently healthcare and not-for profits. Since founding CEO in 1991, Terry has become an internationally recognized expert on strategic business improvement as a thought leader, turnaround executive, and "hands-on" practitioner, with a solid reputation for delivering results. He has worked on thousands of major improvement initiatives with over 300 clients in the Americas and Europe ranging from large multinational Fortune 500 corporations to small and mid-sized companies. His latest book, Out of the Present Crisis: Rediscovering Improvement in the New Economy was released June 2012.