How a cement manufacturing enterprise overcame its ITSM setbacks

A look at Cemm-Tech’s business environment

Our first story involves Cemm-Tech, a multinational cement manufacturing giant.

Cemm-Tech has a strong global presence in almost 70 countries and employs close to 72,000 employees total. It operates with four business service centers across six continents. Cemm-Tech’s America Business Center alone has a tremendous spread across 12 countries. Each country supports six business process factories, and, in turn, each process factory has numerous processes.

A process factory is a collection of processes that involve all activities from procuring raw materials to delivering the final product (cement) to customers, and all the related sub-activities. Cemm-Tech has a regional support center (RSC) with close to 650 technicians supporting the company’s process factories. Cemm-Tech has a total of six process factories.

For example, Process Factory 1 handles the process of raising the orders placed by customers and processing them. Process Factory 2 is responsible for procurement of raw materials, supplying to the factory, and so on.

Here’s an overview of how Cemm-Tech operates:

In this e-book, we’ll be taking a close look at BSC 2: the company’s America Business Center. BSC 2 has a complex layer of requirements. Let’s understand Cemm-Tech’s process and requirements first before we see how the company ended up with a viable ITSM solution.

Understanding the company’s requirements

Cemm-Tech’s requirements are based on how its process factories function and interact with each other. The 650 technicians in its RSC handle the process factories across many levels, interacting with more than 30,000 users. Here’s how the interactions take place:

• All communication and queries from clients, vendors, and employees go to the RSC first. Each query is a ticket.
• When the query is beyond the scope of the support center, the ticket is passed on to the process factories.
• People outside the ITSM system (which comprises the support center and the process factories), like sales representatives and finance executives, might have to attend to the ticket, but the system must still take account of the ticket.
• Interactions take place through multiple channels:

Each interaction between a person and the system can be categorized into three levels:

Level 1:

Clients, vendors, and employees interact with the support center, and it creates a ticket.

Level 2:

The ticket moves beyond the support center and escalates to the process factories.

Level 3:

Supporting functions handle a small percentage of these tickets.

Cemm-Tech had a straightforward requirement for its ITSM solution:

A well-oiled ITSM machine that ensures every interaction is both simple and good enough to do the job.”

To produce that, we first needed to achieve the following requirements:

• An easy-to-use medium to facilitate the transactions between the RSC and all other parties involved
• A robust interface to manage ticket queues that allows technicians to prioritize tickets and minimize response and resolution times
• Escalations handled with accurate transfer of data:
  • Escalation from Level 1 to Level 2 or Level 3, i.e., from technicians to process factories and supporting functions
  • Escalation from Level 2 to Level 1 or Level 3, where process factories resolve tickets or pass them on to supporting functions
• A system for how process factories, which raise an order and follow up to complete it, interact with the system and between themselves
• A way for members that are not present inside the system (like support functions) to handle tickets
• A workflow for how tickets are escalated outside the system, and how their responses are updated back in the ticket
• Other generic ITSM features like SLAs, ticket categorization, and ticket assignment to groups

These requirements, though comprehensive, were only the surface-level requirements. Our real task was to understand the deeper challenges that existed. Understanding those challenges was a major step in establishing a full-fledged ITSM solution for Cemm-Tech.

Establishing a full-fledged ITSM solution

After multiple rounds of interactions with Cemm-Tech, we began to understand the company’s processes inside and out and the challenges in them. We had to tackle these challenges first before we could go on to implement regular ITSM functionalities. Once we did that, we went on to fix the company’s ITSM process at the root and established a complete ITSM setup to power Cemm-Tech’s business processes. Here’s a snapshot of the company’s ITSM transformation:

In the following sections, we have elaborated on the above snapshot to give you an idea of the entire process of transforming Cemm-Tech’s ITSM.

Setting the stage for the implementation

Before we executed the ITSM transformation, we fixed a few gaps and addressed some challenges to set the stage for implementation.

Speaking the industry language

You could refer to most of the employees of a software-based startup as “IT people” and still be right. The opposite is true for a manufacturing enterprise. Many of the employees at manufacturing companies are not comfortable using software and, at times, not even computers. For Cemm-Tech, its RSC is staffed by IT professionals while its process factories are not. But while handling escalations, the professionals from these process factories must also use the system.

Consider these departments:

Most of these departments are heavily dependent on a handful of IT personnel for tasks that involve computers. Even those in other departments that are used to software are strictly confined to SAP and other software that is specific to their industry. When these people need to handle escalations using an ITSM solution that doesn’t speak their language, it creates problems.

Typical ITSM language like the following doesn’t work here:

Imagine a Supply Chain person, whose work mostly involves interacting with the Shop Floor workers, looking at a screen filled with terms they don’t understand. That is where the challenge of speaking the industry language comes in.

Here’s what we did to tackle it:

Simplify or remove complex IT jargon from the solution. The more industry-friendly a solution is, the more efficiently employees can handle escalations and close tickets.

Removing IT jargon can increase productivity and make those outside the IT team more comfortable using the service desk. Our repeat interactions with the managers and Shop Floor technicians of Cemm-Tech helped us simplify the solution. We replaced the ITSM terms with industry-specific terms. And if a particular feature did not make sense, we removed it.

From a manufacturer’s perspective, you should seek those features that save you time and improve productivity. Any level of complexity is going to achieve the opposite. You want the terms on the screen to be ones that your employees can understand and relate to.

From our perspective, it was about replacing the term “assets” with “equipment,” “incidents” with “equipment issues,” and so on. We also had to remove some features that could confuse technicians.

For example, “project permissions” would probably never make sense for a Shop Floor manager to use on the employees working under them. The employees would rather use the manager’s profile to raise their equipment issues than create profiles for themselves, and then request that the manager give them permissions. Rather than increase complexity, it would make sense for us to remove this feature.

The challenge of speaking the industry language applies to those managers and engineers who are already working with SAP and other software, too. Here’s one such scenario that could happen with any manufacturing enterprise like Cemm-Tech.

A manager, who is a design engineer, hires a recruit to work under him. Cemm-Tech’s IT person is now approaching the manager to sort out the recruit’s IT requirements.

Scenarios like these can pop up when an ITSM solution does not speak the industry language.

This should be a primary area of focus for a manufacturer looking at an ITSM solution.

Improving ITSM functionalities

Beyond just speaking the industry language, mismatched functionalities can be a huge challenge for a manufacturing company.

Let’s look at a scenario to understand mismatched functionalities at the Supply Chain process factory for a manufacturing enterprise like Cemm-Tech.

Typically, a service desk maps all issues to “assets.” While this functionality makes sense for a software company, it causes headaches for a manufacturing company. This functionality should be customized to suit the manufacturing industry. Here’s what the functionality, which would create problems for a manufacturing enterprise like Cemm-Tech, looks like:

An IT company would want all its assets to be managed properly and linked to the correct third party so the ticket is appropriately communicated about and closed. A contract is only mapped to an asset, and the tickets are all connected to that asset.

However, this makes no sense at all for a manufacturer like Cemm-Tech. Its suppliers are in no way related to their “assets.” It would now be much simpler and more productive to simply map the contract directly to the ticket. And that ticket can then be mapped into related part numbers and order numbers, which would easily solve the problem.

An extension of the above scenario applies to related documents. As a manufacturer, you want to have documents that make sense to your department. In the same scenario, it is possible to upset the Supply Chain department even more by misguiding them or giving them functionalities for storing and maintaining asset warranty details, leases, etc. Here’s how it is:

If you are the Supply Chain department head, this functionality would be of no use to you. All these are asset-oriented contracts, and you would probably never use them. However, if there was a functionality to maintain tender information, that would be helpful. If you have a form where you can fill out tender information and map it to a ticket, that would be even better.

There are also cases where we needed to add some functionalities. Cemm-Tech’s engineering team has a change in design, and they want to create a ticket to handle it. They’d be sharing design files through this ticket. A good idea now would be to make the design file a protected one so that it is not accidentally changed or accessed by someone. Likewise, if a factory employee wants to raise an issue about the equipment, there must be a functionality to do so. The solution should fetch the equipment number easily and also list the possible issues to make it easy for the employee.

For an enterprise like Cemm-Tech, the process of understanding its industry-specific functionalities could take weeks or even months of effort. But that effort is precisely what helped us provide a solution that Cemm-Tech feels comfortable working with.

Creating a single ITSM space

Before implementing ManageEngine’s solutions, Cemm-Tech’s BSC 2 was using two different service desk tools:

• A tool for the RSC to handle Level 1 interactions
• Another tool for managing requests inside the process factories and supporting systems

The company used two different service desk applications for good reason: each satisfied a different set of users with different requirements. However, even though the decision was understandable, Cemm-Tech still did not have a unified ITSM space to streamline all of its processes.

Let’s now consider some numbers to put things in perspective:

The above are the results of analysis by our team when we gauged Cemm- Tech’s overall requirements. The volume of tickets per month itself is a significant number for an RSC with fewer than 700 representatives coordinating the entire process.

However, if you look closer, you can see the smaller picture—an RSC has to juggle two different tools to cater to more than 30,000 users across multiple interactions. On top of that, the requests are distributed across six process factories and 12 countries, with users who need the support of various languages. Here’s what this meant for Cemm-Tech:

• The executive in the RSC needed to recreate every ticket that was escalated, in a different tool. This means the actual number of tickets that the team was handling could have been higher than what’s in the table above.
• Both these tools were different in their functionalities, user interface, and other service management aspects. That was a challenge.
• A good amount of information might have been lost since it’s almost impossible to transfer data from one tool to another with 100% accuracy.

One of our main challenges was to streamline these different channels into a unified space. The RSC should be able handle tickets without much trouble. And from a manufacturer’s perspective, this challenge is a crucial one. No matter your varied requirements, a streamlined ITSM solution that caters to both support staff and the process factories, without placing an unreasonable load on either one, is crucial.

To implement a full-fledged ITSM solution like we did, understanding these challenges well was of utmost importance. And during every step of our implementation, we tackled these challenges.

Implementing a complete ITSM solution

Establishing a minimalist process

When we dug deeper to tackle the challenges we discussed earlier, we stumbled upon our biggest process-based challenge yet. Before we jump into it, here’s a quick reminder of how Cemm-Tech’s BSC 2 process works:

• All requests by customers, vendors, and employees move through the RSC, and a ticket is raised.
• When the RSC cannot handle the ticket themselves, they escalate it to process factories.
• Depending on the ticket, the process factories either handle it themselves or escalate it to other support functions.
• Once either the process factories or the support functions handle the ticket, the RSC closes it.

Now, here’s the key point to note in this process:

Requesters (customers, vendors, and employees) should not be able to contact the process factories or the support functions directly. All requests must pass through the RSC. Also, the requesters cannot know who handles their queries inside the process factories.

Here’s how Cemm-Tech handled this requirement:

The company duplicated every ticket that had to be escalated.

And since the technicians in the process factories shouldn’t have direct contact with the requesters, the RSC staff removed the requester’s name, created a duplicate ticket in their own names, copied all the data from the original ticket, and escalated this new ticket. Once the process factories handled the new ticket, they copied all the data back to the old ticket and closed it.

This method has more drawbacks than meets the eye:

Here’s how we dealt with it:

We applied our service management tool’s task management feature to eliminate all the extra non-value-adding processes.

Every time someone in the RSC needs to escalate a ticket, they simply create a task under the ticket and assign it to the process factory. They can either assign it to a team in the process factory or to an individual. If it is a team, the manager responsible will in turn assign it appropriately. In any case, the ticket is completely removed from the picture.

Here’s how this solution worked well for Cemm-Tech:

• Process factories have to deal with tasks alone. This means they save time and energy and do not need to interact with features that do not help them.
• It has solved Cemm-Tech’s objective of requesters and those attending to tickets not having direct communication with each other. As the RSC alone handles the tickets, this separation has become rather simple.
• The RSC now spends little time managing escalations. This has improved SLA adherence and, ultimately, technicians’ productivity.
• Unforeseen errors have been reduced drastically. Relationships with suppliers and customers have improved as the margin for error has reduced.

We introduced some automations to help Cemm-Tech further.

• Every time a task is closed, the data in the task is automatically copied to the original ticket. The reverse happens too: Every time a task is created, the data in the ticket is copied automatically to the task. This has reduced the time taken by the RSC, and ticket closure rates have also increased.
• If a process factory technician closes a task, the ticket is automatically closed.
• When a task or ticket is closed, an automatic email is sent to the requester. This again leads to more satisfied suppliers and customers.

To truly realize how much trouble our solution saved Cemm-Tech, we must look at this in terms of volume. For ease of understanding, we will be rounding off some numbers.

Original volume of tickets per month on average = 250,000

Total number of technicians in the RSC = 650

Total man-hours saved per month = 4,167 hours

Every single man-hour reflects as dollars saved for an enterprise like Cemm-Tech. Once this effect compounds over months and years, the company would be looking at an improved, scalable, and profitable ITSM process.

Enhancing service management at the root

Once we removed the problems like duplicity and established a minimalist process, it was time to do some enhancements at the root of the company’s service management: its ticket management.

A manufacturing enterprise’s priority is always its process factories and, in turn, its support centers. Cemm-Tech’s RSC should have the best ticket management system if it must serve the process factories well.

Here’s how we implemented an enhanced ticket management solution:

Going a step further

Every enterprise has its unique flavor that makes it successful. Implementing an ITSM solution for them is no different—they have their unique flavors in terms of what they want. After fixing Cemm- Tech’s process and enhancing it even more, we went one step further and catered to some of the business’s other requirements.

These requirements were mostly for features yet to be added to our general solution. However, for a manufacturing enterprise like Cemm-Tech, these new features gave the company’s processes a huge boost.