Introduction

Hello! I am TKG from the Corporate IT Group at KINTO Technologies (KTC).

As a corporate engineer, I usually manage the Service Desk and Onboarding Operations.

The other day, I presented the "Study Session in the Format of Case Presentations + Roundtable Discussions, Specialized in the Corporate IT Domain" at the event **“KINTO Technologies MeetUp! 4 case studies for information systems shared by information systems” **"

This time, I would like to introduce the content of the case study presentation from that study session, along with some additional information!

First, the presentation materials:

The presentation materials are stored on Speaker Deck.

The story of how the help desks of KINTO and KINTO Technologies have collaborated (and are continuing to collaborate) - Speaker Deck

Choosing the theme

Currently, I hold positions in both KTC and KINTO, and I am in charge of the help desk area in both companies.

When I was thinking about what to present, I realized that there aren’t many case studies on how close companies collaborate with each other. So, I chose this as my theme.

To be honest, I had some doubts about whether it was worth presenting since it wasn’t something particularly "flashy”.

However, I motivated myself by thinking that these not particularly glamorous topics are exactly the ones that should be shared, and I went ahead to prepare the content.

About KINTO and KTC

As this story is about the collaboration between KINTO and KTC, I thought it was important to first explain the relationship between the two.

I have always found it to be quite unclear, both before and after I joined, so I would like to explain their relationship from my point of view.

They are sibling companies rather than subsidiaries, and there's a common misconception that KTC only develops for KINTO. In reality, we also develop for our parent company, Toyota Financial Services (TFS), and create apps for end users, such as my route and Prism Japan.

The IT environments of the two companies are quite different.

You can see in the simplified chaos map above that KINTO appears to be fully cloud-based, but its core systems operate on-premises within the internal network.

On the other hand, KTC does not have an internal network at all. Each office operates independently. Our Muromachi Office has bases on the 7th and 16th floors, but each operates independently.

The only on-premises equipment consists of the network devices and multifunction devices at each location.

This is the structure of the IT departments of both companies.

While KINTO is divided into two sections, Service Desk (Help Desk) and Infrastructure Management (IT Support), KTC is divided into five.

What I will be discussing today is the Service Desk at KINTO that I am in charge of, what it would be the "Tech Service" at KTC.

Both departments handle help desk operations.

The roles of the various organizations within KTC are extensive enough to require multiple articles, so I will omit them here.

This concludes the explanation of the relationship between KINTO and KTC.

Episode 1. The story of implementing Jira Service Management (JSM) as the Inquiry Desk for both companies

At KTC, we were using Jira Software (Jira) to handle inquiries.

Initially, it worked well, but as the number of employees increased, issues started to arise with the existing Jira setup.

The problem was that the tickets were only written in free text, which created a burden for both the submitters and the help desk. Additionally, there were instances where the help desk couldn’t check the status or handle sensitive content (since the inquiry desk’s Jira was accessible to all employees).

We decided to implement a dedicated ITSM (IT Service Management) tool to allow our staff to focus on their engineering tasks (their primary responsibilities) without customizing Jira to potentially resolved these issues.

Although we wanted to compare various tools, we had limited time. Given that Atlassian products were already used within the company, we chose Jira Service Management (JSM) for its compatibility.

An additional advantage was that 10 licenses were available for free for one year, making it easy to test and evaluate the tool.

Initially, the plan was to implement JSM only at KTC, but as we continued collaborating between KINTO and KTC, we became aware of the issues at KINTO as well, so we decided to cooperate together.

The implementation started with KINTO.

We first established implementation and operational experience at KINTO, following the concept of "Winning Quickly", and then leveraged that experience to roll it out at KTC.

There were no major concerns during the implementation at KINTO, but several concerns arose when it came to implementing at KTC.

Some of the specific concerns that emerged at that time were as follows:

Q1. Won’t it require more effort if we cannot refer to other requests when issuing accounts, changing permissions, etc.?

A. With JSM, it is possible to create optimized forms for each type of service request, eliminating the need to refer to other requests

Q2. (Since everyone can make requests) Will service requests occur without the manager’s approval?

A. While such requests may occur, the help desk will coordinated with the manager as needed

Additionally, I recently had the opportunity to gather feedback from managers of various departments regarding the implementation of JSM. They said that the concerns they had previously did not turn out to be negative, and it has become much easier to track their requests. They evaluated it as a significant improvement compared to the previous system.

Initially, our focus was on implementation. That was the situation.

We have been continuously optimizing the inquiry forms, removing “unnecessary fields that turned out to be redundant after use”, and creating batch request forms to streamline processes.

One of our top priorities has been the "expansion of the knowledge base". However, through our analysis of inquiries, we found that the proportion of service requests was higher than incident-related inquiries, which particularly require a knowledge base.

This likely stems from the fact that KTC is a group of technical professionals with high IT literacy.

Therefore, the focus has shifted more towards service requests, which cannot be resolved by the users themselves (i.e., only administrators can handle), rather than incident-related issues that users can resolve on their own.

Currently, we are focusing on reducing the number of service requests and improving the speed of processing them.

Episode 2. The story about how KINTO used KTC’s expertise to reduce costs and improve the PC replacement process (and continuing to do so)

At KTC, we generally outsource the kitting process.

However, since there are instances where onboarding happens suddenly, we have been working on automating the kitting process using MDM (mobile device management).

At peak times, more than 20 people join in a month!

For more details on this efficiency improvement, please refer to the presentation material below (in Japanese):

The benefits of automating Windows Kitting - Speaker Deck

On the other hand, at KINTO, we had vendors perform initial kitting from image deployment, and then installed individual applications.

Although we had already been using Intune for settings, there was no specific trigger to push for further efficiency.

At that time, we embarked on a large-scale PC replacement project at KINTO, which gave us the opportunity to collaborate more closely with KTC to streamline the process.

By collaborating between KINTO and KTC and reviewing past documents, we were able to eliminate parts that previously required manual work and replace manual settings with Intune.

As a result, we no longer needed to request vendors for image creation, achieving greater efficiency.

While we have made progress in streamlining processes, we believe there is still room for improvement.

Due to the different environments compared to KTC, reaching a "zero-touch" setup seems quite distant, but we would like to improve it little by little and move towards "little-touch" setup.

In conclusion: Never forget to appreciate our predecessors

Both KINTO and KTC have only been around for a few years since their founding, and they had to quickly establish the environments.

There is no doubt that the people at that time made the best choices during the chaos of starting up, and they laid the foundations step by step.

Within the changing environment, the case we discussed is an example of how we were able to successfully improve things when given the right opportunity.

KINTO and KTC still have many areas that are not fully optimized, and there is a lot of room for improvement in both companies.

If you are someone who is eager to take on this challenge, please join us! Together, let’s enhance the IT environments of KINTO and KTC, creating a space where staff can perform at their best without spending time on tasks other than engineering!