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:
Clients, vendors, and employees interact with the support center, and it creates a ticket.
The ticket moves beyond the support center and escalates to the process factories.
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:
Cemm-Tech's IT environment before
Cemm-Tech's new IT environment with ManageEngine
Speaking the industry terms
Te rms like “asset request” and “project permissions” did not make sense.
We replaced them with industry-friendly terms that make sense to all process factories.
The functionalities mirrored an IT company's and were not much help to Cemm-Tech.
We modified and implemented functionalities to suit Cemm-Tech’s process factories—especially mapping tickets to various aspects of the business.
A unified ITSM space
Having two different service desk solutions created room for error amongst IT teams.
We implemented a unified ITSM solution to streamline the company’s entire process under one umbrella.
Ticket management: Creation, escalation, and resolving tickets
Duplicated tickets led to inefficiency and wasted man-hours.
The company has an efficient process with no duplication, enhanced with automation, traceability, and visibility into tickets.
Volume of tickets
The IT team received a large volume of tickets due to gaps in processes.
Overall ticket volume was reduced by more than 25%, resulting in increased response time.
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:
Loss of efficiency
Obviously, there is no productive output from copying the same data twice. The technicians lost time, and it meant they couldn’t maintain SLAs and that ticket closure times increased.
Risk of losing effectiveness
Since technicians had to manually reproduce the data from duplicate tickets back to the original tickets, the chance of error increased. Errors in ticket handling could lead to requesters not having a good experience, or damaged relationships with vendors, either of which is critical for a company like Cemm-Tech.
If there is an escalation, the RSC must manage two tickets instead of one. And they should have a way to identify which ticket is which. Technicians may maintain their own table for tracking tickets. Or they may distinguish the duplicate ticket by adding information that points to the original ticket, but this information could readily get mixed up with other data in the ticket, like part numbers, order numbers, and contract numbers. In any case, this leads to complications. If Cemm-Tech wanted to expand and establish a new business center in a bigger region like South Asia, this complication would make it more challenging.
These drawbacks could almost convince a manufacturer that an ITSM solution is not worth it. This meant we had our work cut out for us when figuring out how to deal with this problem in a much smoother way.
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
Cemm-Tech's original status
Result after ManageEngine's solution
Original volume of tickets
Tickets added due to duplication (with 10% escalation)
Time taken to handle duplicate tickets at an assumed efficiency of 10 minutes per ticket
Extra time saved per technician
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:
Automatic ticket creation
Creating a ticket once communication is made, especially via email, is a standard process. But when we automated it, the RSC’s work became a lot easier. All RSC staff had to do was focus on how to either respond to tickets or escalate them.
Traceability of tickets
Once a ticket is opened, it might have to go through multiple process factories before it is closed. For example, Process Factory 1, which handles the entire process of raising the order, collecting the cash, and serving the order, might pass tickets on to many departments internally. The commercial team, the Procurement department, and the Accounts department might all be involved in processing one ticket.
Accurate and easy tracing of a ticket across departments and stages makes it a lot easier for the process factories to close tickets.
Retrieving acustomer’s history
This useful function gives the RSC better visibility into a customer’s mindset. For example, a particular vendor might have provided the wrong batch of raw materials the previous month, and Cemm-Tech’s Accounts department might have withheld payment temporarily. The same vendor could raise a ticket about the delayed payment later. If an executive from the RSC has access to the previous interactions, there will be no need to escalate this ticket.
With a customer’s, vendor’s, or employee’s history at hand, there are fewer escalations and the ticket closure rates increase.
Easy reassignment of tickets
This feature lets Cemm-Tech create business rules that automatically route tickets to the concerned departments. It also helps the company apply templates appropriately to categorize tickets. For example, a Shop Floor worker raises a ticket about an issue with a piece of equipment. This ticket would first go to Cemm-Tech’s in-house service engineers. If it is beyond their scope, it should then go to a vendor that consults about the issue and fixes the equipment. This process could repeatedly occur until the equipment is fixed satisfactorily.
Cemm-Tech can now use this feature and reassign the ticket using a few easy-to-write business rules. This saves the company lots of back-and-forth communication and valuable time.
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.
Custom notifications for external users
This is another feature specific to Level-3 users (the support functions like Sales, Finance, Quality, and Logistics). This is particularly useful since these users handle minimal escalations yet still some of the most important ones. This feature is critical for most manufacturing industries as it helps cut out unnecessary interactions with those outside the system.
Ticket closure via email responses
Given the size of the RSC and its need to cater to 30,000 users, this feature is a crucial one. It could save them hundreds of man-hours since many tickets are straightforward and can easily be closed with email responses.
SLA reminders for external users
External users handle some of the most crucial tickets and are already a busy batch. They contribute to Cemm-Tech’s productivity in many ways, but a ticket could always miss their attention. SLA reminders are a great way to help them handle these crucial tickets.