ONE QUESTION, FIVE ANSWERS – With this month’s question we try to understand what lean idea or principle our interviewees would have liked to learn sooner or better in their journey. So, heads up… You might be in a similar situation.
“What lean idea or principle would you like to have learned sooner or better?”
MONICA ROSSI, Postdoctoral Associate on Lean Product Development, Politecnico di Milano – Italy
As an academic, I find myself working with so many different companies, people, situations, and ways of thinking. I wouldn’t say there is one idea that I wish I had learned sooner, but I do wish I had known how to best communicate lean from the outset. In the past, whenever I talked about set-based concurrent engineering, kaizen or, simply waste, I assumed that everyone would understand what I was saying. I failed to see that, while lean can be a common language, we don’t all learn to speak it at the same time.
I realized quite soon – it’s hard not to when you see puzzled and somehow hostile expressions in your audience – how important it is to move past “labels” and buzzwords and go straight to the core message behind lean ideas instead. That’s what we must communicate. And that’s what creates a common ground, allows us to connect with the people we teach (that’s my own version of listening to the customer), and eventually get to talk the same language they do. I have learned that once you start doing that, people are less defensive and open up to the idea of change. Our lean adventures can then begin, wherever they might take us – whether the astrophysics industry in Italy or a small enterprise in Myanmar!
STIJN SLOOTMANS, Project Manager UZALean, Antwerp University Hospital – Belgium
Our hospital, the Antwerp University Hospital (UZA), started its lean journey five years ago. To inform and involve front-line staff, we organized several training sessions. This was the occasion for the hospital management to communicate what we wanted to achieve with lean, as an organization. In the past five years, our lean coaches have supported front-line staff and department managers as they worked on improvement projects. However, it became evident that departments were not all going in the same direction – the link between improvements and the overall targets of the organization (included in our Strategy 2020 document) was not clear enough. At that time we became aware that strategy deployment is critical. In hindsight, we probably should have tried to master this earlier.
Our lean coaches and management team were inspired by the hoshin efforts carried out in other hospitals, and decided to implement strategy deployment at UZA. The method helped us to communicate and visualize our strategy and to focus it on our True North: Quality and Knowledge. The True North is now visualized on every department’s improvement board and each new project is clearly linked to both departmental and organizational goals.
SARAH WILLIAMS, Head of Student Services, Christleton High School – England
Believing that lean thinking could be applied to any realm of the public sector is a conundrum many of us play with in our minds: the concept of its application to education, certainly at the outset of our project at Christleton High School, felt nothing less than a mystery to me! My impression today couldn’t be more different!
What lean idea would I like to have learned sooner? Definitely the idea of defining value and understanding that value is only meaningful when it results is a service that meets a customer need. This idea was critical to our success in school (and indeed it is to anyone’s success). So, who are our customers in education? What are their needs? What does our service need to offer that will ensure those needs are met? This is truly fascinating… but often do we really ask ourselves these questions in the education sector?
PIERRE MASAI, CIO, Toyota Motor Europe – Belgium
Looking back at the foundations of TPS and at my own lean journey, what I would like to have learned and applied earlier is buried in the Jidoka pillar. While the lean literature talks about flow, there is relatively little on Jidoka, which is telling us to stop the flow in case of problems, think deeply and make sure those problems won’t reoccur.
The application to the assembly lines with Andon cords is well known, but the application to knowledge work is not as straightforward. Many problems are identified and visualized, but we fail to stop the work and concentrate on structural resolution. As a consequence, problems continue to occur and the flow does not improve. It is counter-intuitive to stop a complete line for a quality issue in a single place, but the resistance of knowledge workers and their management is even higher. Let’s apply this sooner with courage.
[To read a profile on Pierre, click here]
CATHERINE CHABIRON, lean coach and member of the Institut Lean France – France
I have worked on lean in IT for years, within the IT department of a major automotive equipment manufacturer. We started with projects, then moved to support operations and data centers – in each of these instances, we spent a lot of time at the gemba with our manufacturing and supply chain internal customers to develop competences on flow and data management in the ERP. Our focus was constantly on production and execution – where IT problems and poor data quality can create havoc – and it yielded good results in terms of stability and efficiency.
Over the past two years, however, I started to turn my focus on activities upstream: how do we design our products or our IT systems in the first place? Do we manage our product development like an endless suite of deliverables or do we really look at the product we are building? Do we include usage and competitive advantages in our design thinking? Do we discuss our designs with those who will be in charge of the assembly or of the after-market service? Wow! I feel like I should have thought of all this long ago. A Toyota manager in Australia once told me something that really struck me: “Where does the process touch the product?” Indeed, we fall in love with our product development process, we love work on production steps, but when do we really spent time looking at the product?