ROI Case File No.443 'The Unmanned Window at 3 A.M.'
The Unmanned Window at 3 A.M.
Chapter 1: The Phone That Rings Through the Night
"At three in the morning, calls come in to staff members' personal smartphones. Two or three times a week."
Koichi Watanabe, IT Operations Director at TechGlobal, said this while lightly touching the dark circles under his eyes. The company operates fourteen locations across eastern Japan, including three factories that run twenty-four hours a day, three hundred sixty-five days a year.
"When the production line stops and it seems like an IT issue, people on the floor need to contact someone. There's no official channel, so they call the personal number of whoever helped them last time. This has been going on for three years."
"Does each location have an IT person?" I asked.
"In name, yes. But they're all wearing multiple hats. Most of them are primarily accountants or administrators who are considered the 'IT person' because they know computers. They don't have the skills or authority to handle calls in the middle of the night."
"Where does knowledge accumulate?" Gemini asked.
Watanabe gave a rueful smile. "Inside people's heads. 'Restarting this server at this location does this,' 'that printer needs the power cycled before you reinstall the driver' — this kind of information is scattered across fourteen locations, recorded nowhere."
"Why outsourcing?" Claude confirmed.
"Two reasons. One: staff are burning out. Two people resigned last year due to the overnight calls. Two: a new factory opens in six months. The current structure can't absorb it."
The full shape of the case came into focus. The problem was not "which vendor to outsource to" — the very design of what to outsource and what to keep in-house had never been established.
Chapter 2: Two Diamonds
"This case calls for the Double Diamond."
Gemini drew two diamonds side by side on the whiteboard — the left labeled "Discover and Define the Problem," the right labeled "Develop and Deliver the Solution."
"The Double Diamond model," I began, "is a framework that translates design thinking into practice. Its defining feature is a phase dedicated to correctly defining the problem before solution development begins. In this case, where outsourcing has been pre-selected as the solution, we first need to revisit the actual problem in the left diamond."
[Discover: Broaden what we know about the situation]
"The first phase of the left diamond is Discover," Claude continued. "We gather facts broadly. Let's check Open Casefiles for patterns from similar cases."
The screen showed data from past IT helpdesk outsourcing engagements. The most common factor in failed cases: "incidents were not classified before outsourcing."
"Watanabe-san, could you walk us through the IT issues you can recall from the past six months, grouped by type?" I prompted.
Watanabe began taking notes. Network outages, device problems, software license expirations, printer failures, server maintenance — within ten minutes, eighteen categories had emerged.
"Of those, which ones tend to occur at night?" Gemini asked.
"Network failures and server-related issues. The factory's production systems depend on the network."
[Define: Narrow down to the real problem]
"Next, the Define phase," I continued. "We classify the eighteen incident types along two axes. The first: frequency. The second: required expertise — can anyone handle it, or does it need a specialist?"
Gemini drew the matrix. The upper right — "high frequency, low expertise" — was populated by printer failures and password resets. The upper left — "low frequency, high expertise" — held serious network failures and server outages.
"What should be outsourced is this upper-right quadrant," Claude pointed. "High-frequency, standardizable incidents can be converted into manuals and transferred to an outsourcing partner. The upper-left, high-expertise incidents require a fundamentally different selection criteria for the vendor."
"The 3 a.m. phone calls," I summarized, "are the small number of incidents in that upper left. Two or three times a week sounds frequent, but in absolute terms it's likely fewer than ten incidents per month. Conflating the severity of a problem with its frequency leads to poor outsourcing design."
[Develop and Deliver: Give the solution a form]
"We move to the right diamond," Gemini continued. "In the Develop phase, we define outsourcing requirements in three tiers."
"Tier one: a 24/365 first-response desk," Claude explained. "Receives high-frequency, low-expertise incidents and resolves them using manuals. This can be handled by a relatively affordable outsourcing partner."
"Tier two," Gemini continued, "is an escalation structure for high-expertise incidents at night. If first-level response can't resolve the issue, the contract must require escalation to a specialist engineer within thirty minutes. Whether this structure exists is the crux of vendor selection."
"Tier three," I added, "is a mechanism for knowledge accumulation and transfer. Build a contract clause requiring that every incident resolution by the outsourcing engineer is documented and returned to the company's internal knowledge base. If knowledge accumulates only at the vendor's end, you create vendor lock-in."
"For the Deliver phase," Gemini concluded, "run a pilot at five locations for three months and measure incident classification accuracy and escalation response time. A reverse-engineered schedule is needed to complete the full rollout two months before the new factory opens."
Chapter 3: What Comes After a Well-Defined Problem
Watanabe studied the matrix on the whiteboard.
"When we talk about outsourcing, management always asks 'how much will costs go down?' But I now see there are things that need to be resolved before we can answer that."
"The essence of the Double Diamond," I replied, "is the paradox that the faster you rush to a solution, the weaker your problem definition becomes. In this case, outsourcing was decided from the start. But moving forward without defining what to outsource produces a structure that costs a lot and doesn't work."
"The 3 a.m. phone calls," Claude added, "are solved not by outsourcing but by classifying incidents and standardizing first-level response. Outsourcing is simply the means of execution. Swap that order, and the quality of your brief to the vendor changes from the ground up."
Watanabe nodded deeply. "Next week, I'll share this matrix with all the IT staff and start from a survey of actual incident data."
Chapter 4: The Window at Dawn
After he left, Claude murmured: "The 3 a.m. calls weren't a technology problem. They were a design problem."
"That's right," I replied. "Knowledge sitting in individual heads, no central desk, no one accountable overnight — that's not negligence. It's structural failure. The Double Diamond is also a tool for questioning that structure."
Outside, the city moved quietly through the night.
Five months later, a report arrived from Watanabe.
The incident classification survey found that seventy-three percent of all incidents fell into "high-frequency, low-expertise" — flagged as transferable to outsourcing. Two months after the pilot began, overnight calls to staff members dropped to zero.
The full rollout was completed three weeks before the new factory opened. Outsourcing costs came in eighteen percent below initial projections. Clearly defining the problem had sharpened the requirements brief, giving Globex the upper hand in competitive bidding.
Watanabe's report read: "The Double Diamond's lesson — don't choose a solution before defining the problem — held up in vendor negotiations too. Because we were clear about what we were delegating and what we were keeping, we didn't hand everything over to the vendor."
The 3 a.m. phone isn't ringing tonight.
"Outsourcing is a solution, not a problem. Yet most companies start looking for a vendor before defining what to outsource. The Double Diamond provides a two-stage thinking process: broaden, then narrow, before reaching for solutions. When you correctly define the problem in the left diamond, the solution in the right diamond becomes surprisingly clear. The time invested in problem definition always returns as avoided rework in the execution phase."
Related Files
Tools Used
- Open Casefiles — References failure patterns and success factors from similar cases
