Four Providers, One Warehouse Scanner Problem
A global manufacturer outsources infrastructure to four providers: network, data center, SAP hosting, and service desk. A recurring problem causes warehouse scanners to lose connection for 2–5 minutes several times a day. Each provider shows healthy metrics within its own boundary. The network provider says latency is normal. The SAP hosting provider says its application response is normal. The service desk resets scanners and closes incidents. The data center provider says no power events. The manufacturer's own IoT team manages the scanner firmware. There is no end-to-end problem record. The contract has no cross-provider problem process. Monthly service reviews are separate. Warehouse operations estimate 1,200 lost picking minutes per week and are considering a manual paper fallback.
1. What organizational structure and contractual changes are needed to manage this problem end to end?
Read the worked answer
Move to a federated model with an end-to-end problem owner at the manufacturer, supported by a cross-provider problem process. Contract changes: each provider must participate in joint problem records, share relevant data within agreed security rules, attend cross-provider reviews, and accept joint actions. Replace or supplement separate SLAs with end-to-end measures such as scanner connection availability and picking minutes lost. Create a single escalation and governance forum with authority to assign cross-provider actions. The manufacturer's problem manager should own the method and record; the service integration lead or a named end-to-end owner should be accountable for resolution. Without these changes, each provider can remain 'green' while the warehouse stays broken.
2. Who should chair the cross-provider investigation, and what authority do they need?
Read the worked answer
The manufacturer's problem manager should chair, or a service integration lead with a mandate from the manufacturer. The chair needs authority to convene all four providers plus the IoT team, set deadlines, demand data, and escalate non-participation to contract governance. They do not need to be the deepest technical expert; they need decision rights and sponsorship. Each provider should name a technical lead who can commit actions, not just attend. The chair should publish the problem statement, scope, timeline, and decision log. If a provider disputes the scope, the chair escalates rather than negotiating indefinitely. This is the minimum authority needed to turn four boundary-local views into one end-to-end investigation.
3. Design the first 10 working days of the investigation.
Read the worked answer
Days 1–2: agree the problem statement and collect synchronized logs from scanners, network, SAP, data center, and service desk. Days 3–4: build a single timeline of disconnects and compare against provider events. Day 5: agree hypotheses, such as roaming behavior, access-point handover, authentication timeout, or network path changes. Days 6–8: run controlled tests with each provider observing its own domain; capture packet traces where permitted. Day 9: review evidence and eliminate hypotheses. Day 10: agree interim workaround for warehouse operations and permanent actions with owners and dates. Communicate daily to operations. Do not wait for perfect data; start with the timeline. The first 10 days should produce a verified or narrowed cause, not a blame report.