What’s Going On In German Companies | Bodo Wiegand | Wiegand’s Watch

Bodo WiegandBodo Wiegand heads Germany’s Lean Management Institute. In his latest newsletter, on Wiegand’s Watch, he explains his concerns about the future competitiveness of German companies. Here is my full translation of his article, followed by my comments:

Bodo Wiegand: “A huge potential is not realized and simply left fallow – can we really afford that?

I think we cannot afford it.

In China and India, more engineers are trained each year than we have in Germany in total, and then we fail to exploit the huge potential of the engineers we have. Why? Because we do not want to give up our fiefdoms, our functional thinking and our single-minded concern for our turf.

Continue reading

Digital Transformation vs. Lean Transformation | Bob Emiliani

“Corporate investment is increasingly shifting from machinery and employees to robots and software. Why? Because CEOs think digital transformation will be a source of competitive advantage. And it is a transformation that they think they can execute more rapidly compared to Lean transformation. CEOs also think that automation and artificial intelligence will take on greater roles, while the work of employees will take on less significance over time. They think technology is becoming more valuable than employees.”

Sourced through Bob Emiliani’s blog

Michel Baudin‘s comments: “Digital transformation” is a quaint way of describing the growing pervasiveness of software in business, with its infrastructure of computers, computer-controlled devices, and networks. Digital is normally opposed to analog, as in music CDs versus vinyl LPs. The early work on industrial automation was based on analog mechanical, fluidic, or electronic control systems, and its “digital transformation” happened decades ago with the advent of numerically controlled (CNC) machine tools and programmable logic controllers (PLCs). This is not what Bob is talking about, but I am not sure what he is talking about.

Continue reading

Manufacturing’s Digital Revolution | Travis Hessman | Industry Week

GE's Jamie Miller

GE’s Jamie Miller

“The once distant and isolated worlds of OT and IT – of physical production and the software that drives it – has been on a steady, inevitable collision course for over a decade.  Today, with the help of sensors, powerful analytics, and the Internet of Things, those two sides of the manufacturing world are finally ready to merge. The result will be nothing short of a full-scale manufacturing revolution.”


Sourced through Industry Week

Michel Baudin‘s comments:

“OT,” as an acronym, is new to me. In this context, it stands for Operational Technology, and it differs from IT in that, instead of putting out words and pictures on screens for humans to read, it issues instructions to physical devices, like automatic machines, robots, or Automatic Guided Vehicles (AGVs). “OT” in this sense is so recent that,  google doesn’t know it, and spells it out as Occupational Therapy.

In her keynote presentation at the IndustryWeek Manufacturing & Technology Conference and Expo in Rosemont, IL, on May 4, GE’s Jamie Miller asserted that the OT/IT merger and the data-rich world of the Industrial Internet were the key drivers of changes in manufacturing for the next few years. But the obstacles to this merger, or even convergence, have been non-technical for decades. While the Industrial Internet of Things (IIoT) may be a real breakthrough, its absence was not the reason OT and IT have remained apart.

Continue reading

The Internet of Things in Toyota Operations | Laura Putre | Industry Week

toyota-logo“… Trever White, divisional information officer, noted that his team is regularly on the plant floor, building good relationships so team members can articulate what their challenges are. One challenge they recently identified was the need to build a containment system to more quickly identify and contain a quality issue when it emerges…”

Sourced through Scoop.it

Michel Baudin‘s comments:

As described in this article, advanced IT for Manufacturing, at Toyota, starts from the needs of the shop floor and works its way up. First, you build systems that take root because they help in daily operations, Then you extract and summarized data from these systems for the benefit of managers and engineers.

ERP, on the other hand, starts from the needs of management and works its way down, and I think it is the key reason why ERP success stories are so hard to find.

Manufacturing Data Cleaning: Thankless But Necessary

Whether you manage operations with paper and pencil as in 1920 or use the state of the art in information technology (IT), you need clean data. If you don’t have it, you will suffer all sorts of dysfunctions. You will order materials you already have or don’t need, and be surprised by shortages. You will make delivery promises you can’t keep, and ship wrong or defective products. And you will have no idea what works and what doesn’t in your plant.

I have never seen a factory with perfect data, and perhaps none exists. Dirty data is the norm, not the exception, and the reason most factories are able to ship anything at all is that their people find ways to work around the defects in their data, from using expediters to find parts that aren’t where the system thought they were, to engineers who work directly with production to make sure a technical change is implemented. Mei-chen Lo, of Kainan University in Taiwan, proposed a useful classification of the issues with data quality. What I would like to propose here is pointers on addressing them.

Continue reading

Is Choosing a Consultant Truly The Second Step in ERP Implementation?

According to the previously cited guide from ERP Focus, choosing an implementation consultant is the second step of ERP implementation, right after selecting a vendor. In the consulting business, being a certification as an implementer from a leading ERP vendor is known as a license to print money. Even vendors of ERP products acknowledge that their customers spend more to implement the software than to buy it, and that much of this cost goes into consulting fees. The following are a few thoughts about the process of ERP implementation and the roles played by consultants, contractors, and the in-house IT team. Continue reading

“I’ve had results with Lean but Corporate pushes ERP. Any advice?” | LEI | Michael Ballé

Question:  “I’m the head of a business unit and have had visible results with lean. Yet, my corporate colleagues refuse to acknowledge this and want to force their ERP and purchasing practices on my division. This is very frustrating – any advice?”

Answer: “I certainly understand (and share) your frustration and, unfortunately, I don’t really have useful advice[…] No easy answers”

Sourced through Scoop.it from: www.lean.org

Michel Baudin‘s comments:

Ballé then follows up the non-advice with a 1,079-word essay where, among other developments, he equates the use of ERP with colonialism, leading to the conclusion that there are no easy answers.

Let us assume that the question is from a real manager in a real situation, in a position to make choices with real consequences for his or her career as well as for the company. It deserves an answer.

Continue reading

Toyota’s IT Vision at Industry Week’s Best Plants Conference | Chain of Thought

See on Scoop.itlean manufacturing

“‘…Toyota Motor’s group leaders were complaining about the systems IT was delivering. They wouldn’t let them focus on being out on the production line. So IT’s focus became providing tools to allow group leaders to be more efficient…”

Michel Baudin‘s insight:

The article’s author is challenged about getting to the point but, when he eventually does, it is worth reading. What I found most original is IT focusing on the needs of group leaders, Toyota’s name for first-line managers, who oversee four to six teams of four to six operatiors each. It is a constituency is definitely underserved by IT in most manufacturing organizations and whose potential is underestimated.

Most companies expect little from first-line managers beyond expediting parts, tracking time and attendance, and disciplining workers to make their numbers. In fact, being both part of management and in direct contact with production operators on the shop floor puts them in a unique position as agents of change.

This is why TPS puts them in charge of smaller groups, with the expectation that they will spend time leading improvement projects and supporting the professional growth of their teams. Most IT groups pay more attention to the executive suite than to the shop floor, where, in particular, you are not just interacting with people through screens but also with machines through their controllers. This requires a different set of IT skills, and the article says that Toyota partnered with Rockwell Automation for this purpose.

See on mhlnews.com

ERP and Lean

The discussion Pat Moody started in the Blue Heron Journal is in the form of advice to a production planner in a heavy equipment plant who has been put in charge of implementing a new ERP system to replace a collection of legacy systems. The call for help is signed “Hopeful in the Midwest.”

What would we say if, instead, this person had been tasked with throwing out all the machine tools of multiple vintages that make up the plant’s machine shop and replace them with one single, integrated Flexible Manufacturing System (FMS)?

My recommendation to this person would be to find another job. Unless the company has gone through preparation steps that Hopeful does not mention, the ERP project is likewise headed for disaster and Hopeful should run from it.

ERP boosters take it for granted that one single integrated system to handle all information processing for a plant is an improvement over having multiple systems. From a marketing standpoint, it is a powerful message, well received by decision makers, as evidenced by the size of the ERP industry.

Yet most plants do have multiple systems, and it is worth asking why. It is not just because organizational silos are uncoordinated. It is also because the best systems for each function are made by specialized suppliers. The best systems for production planning and scheduling, supply chain management, maintenance, quality, human resources, etc. are developed by organizations led by experts in each of these domains.

ERP systems are built by companies that grew based on expertise in one of these domains and then expanded to the others, in which they had no expertise. One major ERP supplier got its start in multi-currency accounting; another by dominating the market for Database Management Systems; yet another by focusing on HR management. Unsurprisingly, the software they provided in all other areas has frustrated practitioners by its mediocrity.

Perhaps, the reason you hardly ever meet any manufacturer who is happy with an ERP implementation is that the idea of an all-in-one integrated system is not that great to begin with.

What is the alternative?

First, management should respect the need for departments to have the systems that support them best, requiring only that they should be able to share information with other departments.

For example, Marketing, Engineering, and Accounting should not be mandated to use modules from a single all-in-one system, but they should be required to use the same product IDs and product families, for management to be able to view sales, production, and financial results accordingly.

To make this possible, the company needs a consistent information model of its activities, including the objects that need to be represented, the states these objects can be in, the information they need to exchange, and a structure for all the retained information.

The development of such a model is beyond the capabilities of a production planner, and often beyond the capability of anyone in the IT department of a manufacturing company. It requires high-level know-how in systems analysis and database design, and should be done by a consultant who is independent of any ERP supplier, in cooperation with the operating department and the IT group.

The first phase should focus on improving the performance of the legacy systems in targeted areas, and introducing middleware to facilitate the integration of data from multiple legacy systems. This involves work in Master Data Management for specs and nomenclature, Data Warehousing for history, and real-time databases for status.

The replacement of legacy systems should be considered based on the lessons learned through improvement, in particular with a realistic, internally developed view of costs and benefits. As in the case with new production equipment, the introduction of new IT systems may best be coordinated with the development of new production lines or plants.

Using project charters: not as easy as it seems

In a comment on a previous post, the Virginia MEP’s Bill Donohue  listed several tools that he feels are particularly useful, among which were Project Charters, and I would like to share my experience with them. The concept is self-explanatory, and you can see a variety of examples by just googling “project charter.” It is simply a form intended to provide a one-page summary of a project.

I have been involved with two multi-year projects with clients who wanted to use this tool, and it seemed such a simple, common-sense approach that I embraced it with gusto. To my great surprise, the project teams didn’t. It just required them to fill in such data as the name of the project, the list of team members and roles, short descriptions of current, ideal and future states, the main implementation milestones, and estimates of what good it would do.  It would be a great summary on an A3 sheet of paper, and a perfect tool to communicate with peers and management, while keeping the team focused on the goals.

But it didn’t turn out that way. Working with teams to generate charters took much longer than anticipated. These documents were perceived as a hurdle to clear before implementation could start. Once generated, they were never referenced in the inner workings of the team but only trotted out for management meetings. They were generated on Excel worksheets based on templates supplied by management and primarily used in PowerPoint slides, in which the font was too small to read on screen. Since most teams did not have access to a large format printer, whenever they were printed, it was on A4/letter-size paper rather than A3.

I wondered why the teams were not embracing this tool. They had a feed-the-bears attitude to it. Managers were the bears that periodically had to be fed, and the charters were offerings to keep them at bay. I thought the charter should instead be a project management tool used primarily used by the team itself, and only secondarily for management communications.

I had previously used a more informal approach, where we would write a one-page memo explaining in plain text the who-what-where-when-why-how of the project. With the signature of the manager in charge of the target area, this memo would then be posted on the shop floor for every affected person to know what was going on and the extent to which their cooperation was needed. It was generally well accepted by project teams as “Communications 101.” One reason management wanted formal charters was standardization. They wanted all projects in the program to have descriptions in a common format to make them easier to review.

Lean implementation was starting in these companies, with management keen to engage employees at all levels and tap into their creativity, but filling out a form is not an activity that we usually associate with creativity. Possibly, management’s demand for charters was sending a mixed message: be creative but follow these standards. It was saying “think out of the box but stay within this box!”

Perhaps the form itself was a problem. In both cases, it had been designed by a committee of managers who were as new to Lean as the rest of the organization, and I thought the following features were mistakes:

  1. There were too many different roles identified for team members. The relevant distinction in practice is between core members, who are committed to the project, and the others, who are only involved. In a line redesign project, for example, the production supervisor in charge and the manufacturing engineer are both core members, but the plant safety expert who needs to approve the design is only involved. In the form, members could be assigned one of four different roles. Some were accountable for the outcome, others executed the project, others yet were consulted on it, and finally, there were those who were just kept informed. It sounded great, but, in fact, created unnecessary complexity and wasted time in discussions of which category each member should be in.
  2. The form confused PDCA with a project plan. The main phases of any project were identified as Plan, Do, Check and Adjust. It really didn’t fit any non-trivial project, which you would break down into smaller tasks each defined by deliverables. PDCA is a discipline you would apply to each of the tasks, as well as to the project as a whole, but Plan, Do, Check, or Adjust would not appear as bars in a Gantt chart or entries in an action item list.  In a setup time reduction project, for example, one task is to shoot a video of the current method, but you cannot fit it under Plan, Do, Check, or Adjust.
  3. The form had boxes for information that the teams could not possess until the project was completed. If you are a carpenter building your 50th staircase, you should be able to summarize current and future states, how long you will need, what good it will do, etc. But if you are a team undertaking setup time reduction on a machine for the first time, you are entering what is for you uncharted territory. Upfront, you don’t even know the details of the existing state, let alone the future. At this point, all your setup time reduction team knows is that its goal is to achieve changeovers under 10 minutes on a specific machine in daily practice. When JFK said “this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth,” this one sentence was enough of a charter to focus the work of tens of thousands of people for the following eight years. There would have been no way, at that point, for fill out an A3 form with more details, because they were unknown.
  4. Project teams are also ill equipped to estimate the economic benefits of their project, and wary of writing down amounts they may be held accountable for. In fact, the first few projects that mark the beginning of Lean implementation are never grassroots initiatives. They are selected by management, for their combination of economic value and skill development potential. The setup time reduction team in our example does not need to estimate the benefits of quick setups; they just need to achieve them, promptly and within budget.
  5. The committee that designed the charter form had also come up with a “smart” naming scheme for projects.  It had codes for site, department, project category, and start date. It was a conditioned reflex for people who had grown up with such naming systems, but it served no useful purpose while adding complexity.

After a long struggle, the teams managed to produce at least partial charters. The managers  were not happy, but they had to make do and let the projects proceed. As they did, however, the charters rapidly became obsolete. The teams did not pay much attention, but the charters had to be updated for management presentations, which revealed another problem: there had been no plan for revision management on the charters. The charters had been generated as worksheets in Excel books, that had been emailed around, copied on memory sticks, and printed. There are technical solutions to manage documents so that revisions are made by authorized editors, reviewed properly, and stored in such a way that you can trace back the history of revisions, but this was not one of them.

What lessons have I learned from this experience? Not wanting to throw out the baby with the bath water, I still think of project charters as a useful tool, but it has to be introduced in phases, initially giving project teams the freedom to experiment with both content and format to come up with documents that are useful to them. The handful of pilot projects at the start of Lean implementation requires management attention, but not much administrative paperwork. Never mind standardization at this stage. Soon afterwards, you have tens of projects running in parallel, orchestrated by a steering committee, and, at that point, project charter A3s can be helpful.

Rather than being defined upfront by a committee of managers, charter formats should be allowed to emerge from the organization’s project experience, with current and past project leaders in charge. There may also be different templates by category of project, considering that different contents may be appropriate for setup time reduction, assembly cells, machining cells, milk runs, supermarkets, kanban, etc. The need for revision control on these documents should also be considered when selecting tools to generate them, which requires more IT expertise than either the project leaders, the managers, and even most Lean consultants have. Their first choice is almost always Excel, and it does not meet the needs. Alternatives to be considered include, for example, Infopath for form generation and Sharepoint for storage, retrieval and revision control on charters.