Open a Shared Services Case With a Service Map

When a leader says shared services is not working, the phrase covers many problems. A requester might wait too long. A local team might send information twice. An approval might pass between groups with no visible owner. A central team might receive incomplete requests and seek basic details. A business development director should narrow a complaint before describing a major change.

Ask the leader to choose a request with a clear beginning and known outcome. Ask who made the request, what they needed, where they submitted the request, and when they received an answer. Trace every handoff. The route might include intake, local approval, central review, supplier contact, exception review, and final completion. A service map turns a complaint into visible work. The map also shows which parts of a story rest on memory and which parts need records.

A simple map has three columns: request, decision, and completion. Under request, capture user submission and source. Under decision, record every approval or choice required before work moves forward. Under completion, show final action and how a requester learned about completion. Add the name of the person or team responsible at each point. Avoid drawing a perfect future process during a first meeting. An early map should show present practice, including unclear steps and workarounds.

In a fictional meeting, chief administrative officer Priya says, “Every region complains about our purchasing help desk. We need a new operating model.” Director Carlos asks, “Will you follow one request from a regional buyer through completion? I want to see where a requester waits, where an approval changes hands, and what the service team sees.” Priya describes a safety equipment request. A buyer enters a request on 5/3. Procurement receives the request on 5/4. Procurement returns the request on 5/7 because a local code is missing. The buyer adds the code on 5/9. Approval arrives on 5/12, and the request closes on 5/15.

Carlos asks who knew the local code was required. Priya says regional buyers learn the code through local practice, although the intake form does not request a field. He asks whether procurement saw the missing code before review began. Priya says no. The case now has a specific question: does the intake route gather information procurement needs for a safety equipment request? The case does not prove a need for a new operating model. A service map helps Priya see a difference between an intake gap and a structure question.

Find out who experiences a failure and who controls process. The requester feels a delay, although another team might own intake design. A finance group might own an approval rule. A procurement service owner might manage queue work. Regional leadership might control local preparation. Naming roles matters because a diagnostic meeting without relevant owners often becomes a complaint session. Ask the sponsor which people know work from direct experience and which people hold authority to change a step under discussion.

Request a small sample of recent cases rather than a vast history. Five requests from one service area often reveal more than a vague collection of complaints. Choose cases from a defined period and capture the same facts for every case: request date, requester group, request type, information supplied, handoff dates, return reason, completion date, and known exception. The sample does not serve as a statistical claim. The sample helps a group compare paths and identify questions worth deeper examination.

In a fictional working session, Carlos brings five purchasing requests from April. Two standard office supply requests close within four days. Two safety equipment requests return because local codes are absent. A fifth request involves a supplier exception and requires finance review. Carlos places every request on a shared map. Priya notices every safety equipment request follows a similar return route. Procurement manager Lian says the intake form has no code field. Regional manager Omar says buyers receive a local checklist, although new staff often do not know where the checklist lives.

Carlos does not leap to a solution. He asks practical questions. Who owns an intake field? Who updates a local checklist? Which request types need a code? How will requesters know when a field applies? Does a standard request need a path used for a supplier exception? The questions separate an intake issue from an approval issue. They also show which decisions belong with process owners after a mapping session.

Service measures support a map, although measures do not explain every cause. Ask what the organization records today. A queue might show request volume, elapsed time, return count, and completion date. Ask whether elapsed time includes periods where a requester needs to respond. Ask whether all regions use one request category. Ask whether urgent cases enter a separate path. A number with a clear definition helps participants see patterns. A number without context sends discussion toward a false claim.

Ask about a sponsor’s decision date. A leader who needs to improve an intake form before a July rollout has a narrower need than a leader reviewing service ownership during annual planning. Diagnostic scope should fit a decision. For the fictional purchasing case, Priya needs a proposal before a June 20 operations meeting. Carlos proposes a ninety minute mapping session during the first week of June, followed by a short review with the intake owner and regional training lead. The group prepares changes for discussion at the June 20 meeting. No promise exists about which change leaders will choose.

An early objection often sounds like a demand for system or structure change. A sponsor might say, “Our tool needs replacement.” Ask which part of a service route the tool prevents. Does the tool hide queue status? Does a form omit an important field? Do people keep work outside a system? If the sponsor cannot connect a claim to a request path, keep exploring. A tool discussion might belong later, after the group understands a process problem. The same discipline applies to calls for more staff or a centralized team.

Do not overlook exceptions. A routine request and an unusual request might need different routes. When a group maps only a difficult case, people might redesign an entire service around an exception. Ask how often an exception appears and what makes a case different. In the fictional sample, supplier exceptions need finance review because a separate choice is involved. Safety equipment requests need a local code before procurement work starts. Those are distinct conditions. The service map should preserve a difference.

For fictional practice, create a request map for office access badges. Use a request submitted on August 4, manager approval on August 5, return on August 7 because a location code is absent, and final completion on August 11. Name a requester, local manager, service agent, and owner of the intake form. Write one question for each person about a handled step. Schedule a fictional mapping session for August 18. In the invitation, ask every participant for one badge request from August and the field list used at intake. On August 16, have the fictional intake owner mark missing fields on a copy of the form for review.