Establishing a unified ITSM environment for an automobile-parts manufacturer

The Auto-Tech context

Auto-Tech is a Japan-based automobile-parts manufacturing company. It started out as a subsidiary of Toyota but is now a multinational enterprise serving multiple brands. Auto-Tech has three entities: North America, Europe, and Japan. In this e-book, we will be focusing on its North America entity.

Here’s the organizational structure of Auto-Tech:

The North America entity is split between three countries: Canada, the United States, and Mexico. Canada is the sales hub, Mexico is the manufacturing hub, and the US is the center of operations. These three countries together consist of 18 locations for Auto-Tech. These locations predominantly produce HVAC components for automobiles, and the locations are further organized based on customers.

For example, if Ford is a customer of Auto-Tech, then there are representatives in these locations that handle only Ford. There will be a sales representative in Canada focused on Ford alone, and there will be an operations manager who handles operations only related to Ford. Though representatives of different customers have to work together under the Auto- Tech umbrella, they exercise reasonable discretion too to respect their customers.

Auto-Tech has Japanese roots. The company’s Japanese values are reflected in its processes throughout all locations. One of those values is the importance placed on job titles. For example, one location would have a job title known as “General Manager.” In another location, the same role would be referred to as “Division Top.” Both these roles are identical in terms of responsibilities and privileges, but they bear different titles. And Auto- Tech reflects the importance of titles in its IT environment as well. Even though they are identical positions, the IT system has to refer to them with unique job titles. Auto- Tech would never compromise on this aspect. This factor played a crucial role in how we implemented a unified ITSM system for Auto-Tech.

The need for a unified system

Auto-Tech has been around for more than five decades, and this was the first time the company was looking for a unified ITSM system. After evaluating on-premises solutions, Auto-Tech decided a complete cloud solution would suit best to unify its processes.

Auto-Tech’s North America entity’s headquarters is in Southfield, Michigan. Over the years, Auto-Tech formed new locations across North America, and each location created its own IT team. These different IT teams had their own ways of managing their locations, occasionally with different processes, too. When Auto- Tech’s new CIO wanted to unify these locations, the company had its work cut out for it.

Though this system gave Auto-Tech the freedom to operate in a manner customized to each location, it also paved the way for inconsistencies and complications. To sort this out, Auto-Tech decided to implement a unified ITSM solution, with all operations under one umbrella. Locations could be different and may even expand in the future, but they must have one functional space.

If there was a policy in Southfield, it should be reflected in the company’s Mexico location. Auto-Tech wanted all inconsistencies to vanish, and to have an irrefutable cloud ITSM solution.

Auto-Tech’s IT environment

Before we implemented our solution, Auto- Tech had a localized IT environment— localized domains, Active Directory environments, and other setups. Amongst the 18 locations, they had 12 domains and 12 different help-desk-like systems. The IT teams in these 18 locations adopted a “shared service environment” using a tool known as Lotus Notes. A user from Location 1 could raise a request across the other 17 locations, and the approver could be a user in any of the locations.

With over 10,000 users across 18 locations, the shared service environment was held together by a heavily customized email client. Lotus Notes gave requesters just two forms to deal with: an incident form and a service request form. When a user wanted to log a service request, they selected the location (a.k.a. “company” in Auto-Tech’s terms), and the list of categories changed based on the location.

Also, when a user selected a category, the entire template changed accordingly. The resource options, the fields, and even the approval workflows were all based on the company and category chosen by the user. Auto-Tech has 18 companies and more than 50 unique categories. This amounts to a shared category count of more than 150.

Apart from these categories, Auto-Tech has four sets of categories, grouped according to its needs:

• Requesters’ categories, subcategories, and items
• Technicians’ categories, subcategories, and items
• Incident categories, sub-categories, and items
• Service request categories, subcategories, and items

Here’s what Auto-Tech’s environment looked like:

Auto-Tech’s shared service environment

Auto-Tech defines workflows for its processes based on the four sets of categories above and the chosen location. Let’s take a look at an example to understand what a basic approval workflow looks like.

User A at Location 1 raises a service request (a chosen set of category) for a service at Location 2. Here’s how the approval works:

Stage 1

Approval goes to the user’s reporting manager at Location 1.

Stage 2

Approval goes to the department head of that service at Location 1.

Stage 3

Approval goes to the divisional manager. This person may be located at any of the other 17 locations.

Stage 4

Approval goes to a system (service) owner. This person may again be located at any of the other 17 locations.

Stage 5

Goes to a help desk manager located at Location 2.

In some locations, instead of “Divisional Manager,” the role would be referred to as “General Manager,” “Director,” and the like. Auto-Tech’s IT team achieved this in Lotus Notes by simply placing a contact book for approvals. If a resource or service needs the approval of a department head, an address book icon would emerge to populate the entire user database as soon as the user selects the resource or service. Technically, users had the option of selecting their department heads, divisional managers, general managers, etc. themselves.

This is just one example based on one location belonging to one set of category. Auto-Tech followed this same process for all its ITSM requirements.

The result was scattered data in massive quantities across all locations.

It is understandable why Auto-Tech wanted to unify this system. As the company was on its way to implementing Azure and Office 365, its main requirement was to create a unified ITSM setup for all locations. But we faced some unique challenges with Auto-Tech’s environments beyond just the scattered data.

Unique challenges in Auto-Tech’s environment

Auto-Tech did not want to lose or modify its processes during the implementation. We faced multiple challenges, two of which were unique to Auto-Tech.

Itemized approvals

Let’s say a new user is brought on board at Location 1, and they’re a design engineer who needs access to various design tools. Each tool in Auto-Tech has different types of access. In a typical IT environment, there will usually be a form to list all types of access a user needs. The approver can easily go ahead with their job.

In Auto-Tech, however, this was not the case. Let’s say the user needs access to an application called Sigma. The user’s manager cannot directly give access to their recruit. There will be an owner or a manager for Sigma at that location. Only after that manager approves the request can the technicians provide access to Sigma. Likewise, the engineer might need a tool known as 400, which has another owner.

So, if a manager selects five applications for a user, the approval workflow will have to move through five different owners. This was a major challenge that we needed to tackle in our implementation.

Processes across locations

The second challenge had to do with sites. Let’s say Location 1 has a manager for Sigma, while Location 2 has a different manager for the tool. Some locations don’t have any owner for Sigma.

One application combined with one location leads to a unique workflow.

Variable titles, but repetitive roles

We already discussed how much importance Auto-Tech places on job titles. Let’s say in Location 1, the approver of Sigma might simply be called “Sigma Owner.” The same role in Location 2 may be called “Sigma Manager,” and in Location 3, it could be “Sigma Technician.” Since these titles are of much importance to Auto- Tech, the company’s ITSM environment needed to speak the same language with no compromise on the job titles.

So, in 18 locations, there could be 18 owners, with 18 job titles, for one application, and each will occupy a unique space and a process in the ITSM environment.

Each approval has to flow with a different value, catering to different locations, and also respect all the different job titles.

A modern system for a classic enterprise

Auto-Tech has been serving the automobile industry for five decades, and its processes play a major role in why it is the enterprise it is. When we got the chance to unify Auto- Tech’s processes and provide it with a single ITSM space, it gave us a new experience in implementation.

Across Auto-Tech’s 18 locations, it had 48 different processes. We agreed to demonstrate our unified ITSM solution by testing out six of the company’s toughest processes in terms of importance and complexity.

On top of those challenges, here was the scale of our implementation:

To achieve the level of versatility required for Auto-Tech’s environment, we added 700 different form rules to the templates. We also included 45 unique scripts to customize our solution for the company’s requirements.

This was also a learning curve for us in terms of the versatility and customization we could achieve for any enterprise across the world. In the previous chapter, we saw how ticket volume was a major challenge for Cemm-Tech. For Auto-Tech, varied processes across locations was the biggest challenge. Complexity in terms of engineering our solution to suit the company’s interactions was a challenge, too.

Beyond the engineering and technical challenges, the implementation phase perhaps had the biggest challenge. We had to gather all the data from Auto- Tech’s current Lotus Notes system and remodel the information in a way that would suit our solution. With multiple spreadsheets, forms, and even applications, we reorganized the data and fed it into our implemented solution. We configured all the different roles of various leaders and the users of other levels. We then created user roles in Auto-Tech’s new service management solution.

Auto-Tech gave us even more roles with the same privileges and responsibilities. These leaders have employees with more varied roles working under them. To factor in all those differences and blend them with different processes and service categories was challenging.

Let’s see how we did it:

• First, we configured the concerned department based on user, and then the department head.
• We then worked out approvals based on the roles of the department heads we created earlier.
• Each process had to be accounted for 18 times because of the different job titles.
• We then accounted for the 800 departments across these 18 locations. There are about 350 approvers. Each of them, again, with different job titles.
• There was then the case of multiple tiers of approvals.
• Let’s understand this with the example of VPN access. There are typically four tiers of approval for most requests. For cases like VPN access, there would be five tiers. In Location 1, the person to approve VPN access is called the “Division Top,” and in Location 2, they are called the “General Manager” or “Vice President.” So, same process, but when seen across 18 locations, it becomes different processes with different approvals. For every such process, we approached it from the user’s perspective. We created the users in Location 1, while we had the roles configured for that location and others in another database. Then, for a request like VPN access, we used the data from Lotus Notes to see how the approval takes place and mapped the tiers of approvals to these users.
• We repeated this for all 48 processes.

Fruits of the unified ITSM system

Once we compiled all its data, added customizations, and implemented a unified ITSM space, Auto-Tech started to have a lot more visibility. This aids in its decision-making and provides clarity about the company’s own processes. In fact, this unified space will help Auto-Tech evolve with new improvements in its processes. New projects, like adding new domains or configuring Office 365, happen with even more control and informed decisions.

Here’s how Auto-Tech’s environment improved overall: