CASE STUDY – This Shared Service Center in Poland has leveraged lean, technology, and automation to completely transform itself and provide an ever-better customer experience.

Words: Krzysztof Drozd, Senior Project Manager, Service Management, Clariant Services Poland

Piotr works for a global corporation that has centralized almost all production-related processes in one global services center, including ordering materials for production and delivery. He is responsible for production supply in his plant, and he is worried about an urgent order for prefabricated components – critical for manufacturing – that he has placed two weeks ago. Not only has the order not been delivered yet, but Piotr is also unsure whether it has been shipped at all and whether it will be fulfilled by the supplier.

So, he decides to send a message to the Shared Services Center using the ServiceNow system. Unfortunately, the interaction with the agent is less than ideal and leaves Piotr frustrated and with no new information about the status of this important order.

Virtually every organization has posters, banners, brochures, presentations, and training on how to take care of a customer, how to understand their expectations, and how to fulfil their needs. Yet, many a time the actual customer experience is abysmal. Such inconclusive interactions lead customers like Piotr to feel like their voice is neither heard not understood and that their case isn’t handled in a professional manner.

The root causes of this all-too-familiar type of interaction, in which the customer doesn’t feel heard, understood, and taken care of are to be found in the different interpretation of the voice of the customer by different functions within a company and in the fact that the touchpoint with the customer is more often than not designed from a silo perspective.

So, to get their request fulfilled on time and handled properly, the customer is often forced to fight a battle with the organization’s multi-headed dragon. Indeed, despite considerable efforts to develop a culture of process management over decades, the dominant model in organizations is still one based on functions, specialization, and silos. You can see it anywhere you turn. When a customer calls a “call center”, they will get rerouted from one specialist to another. At project meetings, the so-called relay ownership is manifested (“I did my part of the project. Ask them.”).

On mission statements and on their websites, organizations maintain that the customer is at the core of everything they do, but in everyday practice, what the customer means to them is the number of transactions, requests, and complaints. The current business trends that determine the customer’s interaction with an organization, such as digital transformation, growing process automation, or replacing human interaction with chatbots, often leave the customer vulnerable, disappointed, and frustrated. There might be no running away from these trends, but that doesn’t mean that the silo mentality should continue to inform the way organizations conduct business.

At Clariant, a Swiss multinational chemical company, we have run several experiments in the domain of Service Management. Our approach brings together Customer-Interaction-Platform, Lean Thinking, and Robotics & Automation to create a synchronized operational model. These are our “Three Musketeers”, joining forces with the motto “All for one, and one for all”. Over time, Clariant has developed several virtuous practices – from the “3D Camera” to SIC, from CTQ decoding to Harmonization Lean Event and Deviation Management Baseball Game. Their outcome? Unique and consistent customer experience. In this article, I will tell you about some of our experiments.

HOW TO LISTEN TO THE CUSTOMER?

Service Management at Clariant developed two practices that ensure complete and comprehensive listening of the voice of the customer – the 3-Dimensional Camera and 3-Tape Recording.

The 3-D Camera model consists of three steps in a predetermined sequence. First, we explore data in the systems, trying to identify patterns and regularities in the resources. Data exploration should be concluded with a script of questions to people from the first line of customer support. As a second step, we ask people these questions (see examples of questions in the image below). Finally, supported by the knowledge resulting from the data and from the answers to the questions, we take a look at the overall process.

This model is essentially a description of the work done by a professional detective on the crime scene (in lean, we call it gemba). The detective analyses the coroner’s report, as well as the results of all chemical and biological evidence examination. This is the data exploration stage (the first camera). After that, the professional detective compares evidence with witness testimony (the second camera). Frequently, a visit to the crime scene completes the picture (the third camera).

Four years ago, the Opex/Lean team (part of Service Management at GBS Clariant) implemented the 3-D Camera approach for problem solving at every level, consistently asking ourselves these three questions: what does the data say? What do the people say? What does the process say?

Moving away from a silo mentality, we have become much better at understanding expectations, needs, problems, and risks. The knowledge provided by the three cameras allows us to approach the customer with a well-prepared and well-thought-out script consisting of all the right questions (which we created borrowing Design Thinking and UX techniques).

The other practice – 3-layer recording – focuses on the art of listening and records the customer’s voice on three levels: what does the customer say? What does the customer say between the lines? What does the customer not say (but we expected to hear)?

In practice, we use a template where we note down key answers. Afterwards, we verify whether there is coherence between what the customer says directly, what they say between the lines, and what they choose to omit. If we identify any inconsistencies, we know we need to repeat the examination, for example by conducting the interview again.

Below you can see an example of the 3-Layer Recording related to the design of a new Customer Portal. It is plain to see that there are inconsistencies between the records.  

HOW TO FULLY UNDERSTAND THE CUSTOMER?

Collecting customer needs and expectations is one thing but translating them into the language of the project and the process is a whole other story. In many organizations, product, service, or process design is often informed by a method that could be called “fortune-telling”: the design team investigates the customer’s requirements and takes a guess as to what to offer this customer.

To decode the customer’s voice and create a sensible process that responds to real customer needs, the Clariant SM team decided to use a well-known Six Sigma technique: Critical to Quality (CTQ). Below you can see an example of developing success factors critical for meeting the customer’s expectations:

“I want a qualified professional on the other side of the Ticketing Tool system [a customer communication platform linked to the SAP system], not a Call Center agent”.

We started by defining what the customer perceives as professional and competent. In other words, we went from general to detailed. Interviews and workshops with customers resulted in the following definition: a qualified professional can listen to you till the very end, without any unnecessary interruptions (I was clearly heard); they know the right questions to ask after they have listened to you (I was fully understood); and they know how to solve your problem without any avoidable delays, and without the necessity to consult others right from the start.

We used the Critical to Quality Tree to dig into the customer’s expectation and understand its specifics and to translate these into key drivers of the process. As a last step, we created measurements for these drivers.

At a later stage, with the TT system receiving input in the form of measurements, the TT Dashboard, a popular visualization system with daily updates, was created. We have systems and measurements that have standardized our interactions with the customer.

The next step was building a problem-solving system for customer’s pain points. Previously, problems reported by the customer were solved on an ad-hoc basis: the customer would report a problem or submit a request, our TT system would log the request, an agent would create a ticket and categorize it, and then wreck their brains to figure out how to respond to it. Sometimes the solution was simple, the request typical, and the reply easy to formulate. Other times, however, the request was complex and uncommon. On those occasions, each agent tried to find a solution, each in their own way. Sometimes they found it. Sometimes they did not. And it didn’t always work. So, the results on TT Dashboard were green or yellow/red depending entirely on the circumstances.

In response to this challenge, in 2019, GBS Clairant launched a global problem-solving program based on lean principles. We named it Structured Problem Solving (SPS), with the aim of addressing root causes, and began using A3s (only we called them SPS OnePagers). Through observations at three centers in Poland, India, and China, we described the current situation.

We then designed different training, practices, and simulation models. At first, we added a coaching module (the SPS Coaching Academy) to the training segment. At a later stage, we developed the SPS Mentoring Program. All problem-solving initiatives, the so-called SPS cases, are logged in the central database, which every employee has access to.

To ensure adherence to the new problem-solving approach, we introduced two measurements – the In Full measurement and the On Time measurement. The SPS program has operated for four years, with the ultimate goal of turning everyone at GBS Clariant into a problem-solver.

HOW TO COMBINE PROBLEM-SOLVING COMPETENCIES WITH CUSTOMER’S PAIN POINTS? THE ALLIANCE BETWEEN LEAN AND TECHNOLOGY (TT)

So far, the operational model of the SPS program focused on formulating a concept, developing a skill, promoting the problem-solving culture, and creating the SPS Framework. This goal was achieved at the end of 2021. This year, we set another goal: to use the TT technology to design a model in which:

- problems will be systematically identified;

- problems will be separated from incidents;

- identified problems will be defined within the three attributes: scale, trend, pattern;

- baseline measurements will be calculated properly and systemically;

- ownership will be assigned for the resolution of each problem;

- there will be assigned coaching and mentoring support from Service Management;

- there will be systemic logging in the CPTT database;

- the starting and finishing moment of the DMAIC cycle will be activated automatically.

Under the new system, a Cluster Manager receives a condensed piece of information in the form of a one-pager including a graph with explanations, measurements, and actions to perform. The information is automatically assigned to Huddle Meetings, during which the team and the director of the domain analyze progress, provide support and record that a problem has been solved.

The Service Management team updates their database of incidents and problems, with two objectives:

1. Recurring incidents become a problem. This is when Service Management creates an SPS case, often linked to the IT area responsible for the functioning of the TT platform and solves a problem of recurring incidents at the source. In the long run, the goal is for most incident types to stop occurring at all. A problem that is solved at the source does not come back like a boomerang.
2. Identified problems often have recurring patterns. Having a proper reservoir of identified problems and the right business analysis tools, Service Management will recognize such problem patterns. If we know the pattern, we can also identify typical causes, and use our experience when it comes to what measures can work. This way Service Management can build the coaching and mentoring catalog for subsequent problematic cases of a well-known pattern.

Below you can see the example of July report for an Accounts Payables team.

The new operational model for the SPS program is expected to take the problem-solving culture at GBS Clariant to the next level by combining lean competences with technology. The new model has been developed as part of a project entirely based on the Agile methodology and SCRUM framework.

After four years of developing competences and structures in building problem-solving culture, we decided to implement a new model. We wanted to move away from the “hero approach”, in favor of more systemic solutions. The change minimizes procrastination (the system does not allow for the postponement of the DMAIC cycle), moves away from solving easy problems (customer problems come before internal ones), and assigns clear responsibilities (the lead of the team in which the problem occurred is the owner of the problem).

HOW TO COMBINE LEAN COMPETENCIES WITH ROBOTICS & AUTOMATION? THE ALLIANCE BETWEEN LEAN AND RPA

Since the GBS organization was created at Clariant, as Service Management department, we have created a domain responsible for the development of a continuous improvement culture and one responsible for Robotics & Automation (RPA). From the very beginning, we emphasized the need for synergy between the two domains. In practice, this came down to Lean/RPA joint calls, mutual training on key methods and tools, as well as joint projects. However, the alliance between Lean and RPA was more incidental than systematic.

In 2022, much like for Lean and Technology, we decided to build a proper model for cooperation between the domains. We launched two pilot projects run with both Lean and RPA. First we deployed TWI (we call it the Four-Dimensional Method, reffering to the four steps in the TWI JM method).

The moment the 4-D method results in process optimization, we assess whether the process, in full or in part, meets the other four criteria necessary for feasible and profitable automation:

• Process Input that is digitalized or possible to digitalize. The future robot needs to understand the input (these days, with Machine Learning or Artificial Intelligence, this input does not need to be perfectly digitalized).
• Actions and steps in the process must be standardized and repetitive. We will not be able to automate a process or a part of it, when they are executed differently each time.
• All elements with branches in the process, such as “if OK - then” or “if NOK - then”, must be based on logical rules. They cannot rely on discretion.
• Creating and maintaining a robot needs to give positive Return On Investment (ROI).

This model of cooperation between Lean and RPA, tested in the pilot projects, follows this sequence: first, the Lean Stream (4 steps of the 4-D method); secondly, RPA Stream (4 automation criteria).

MOVING TOWARDS FULLY FLEXIBLE TEAMS

The demand for customer centricity encouraged Service Management to initiate a change in team configuration and “modus operandi”. This involved full merger of the Technology (CIP), Opex/Lean and RPA teams. Currently, none of the teams is executing their domain projects anymore. We moved away from the Subject Matter Expertise (SME) model in favor of complete replaceability and competency. Indeed, 2022 is the last year in which we execute projects following traditional project management, for example in accordance with PMBOK or PRINCE2. Our CIP (Technology) and Opex/Lean teams are already executing a project that is entirely based on the Agile methodology and SCRUM framework.

MEASURING CUSTOMER CENTRICITY

Without success measurement, there is no success. We can be getting better and more efficient in our projects, change our organization’s structures and methods, and build competencies, but how do we know that the customer is really the center of our business system?

Measuring Customer Centricity provides us with a snapshot of the Customer Experience. And these criteria are not that hard to create. They are the same I mentioned at the beginning of this article: is the customer heard? Is the customer understood? Is their case handled professionally?

These criteria were adopted by our Service Management teams in one of the projects executed fully based on the SCRUM framework, and they turned out to be very successful.

Ultimately, if customers confirm that these three criteria are met, we do not need to ask whether customers are truly at the center of everything we do as an organization. It is blatantly obvious that they are.

_{THE AUTHOR}