Six tools and no shared service data at Meridian Logistics
Meridian Logistics operates 42 distribution centres across six countries. Its IT service chain involves seven providers and six service management tools: ServiceNow for the internal service desk, Jira Service Management for two application providers, BMC Remedy for the hosting provider, two home-grown ticketing systems, and an MSP portal. There is no shared configuration management database. The internal team estimates 12,000 configuration items are recorded, with roughly 30% duplication, and no agreed service mapping. When an incident crosses providers, tickets are re-keyed manually; average handoff takes 15 minutes and a major incident averages three handoffs. During the last major incident, it took four hours to assemble the correct technical bridge because no one could confirm which provider owned the affected database. Two providers refuse to expose raw ticket data, citing contract confidentiality. The new CIO wants a 'single pane of glass' within 12 months but has a limited budget and no authority to terminate contracts early.
1. Recommend a tooling integration pattern for Meridian. Compare a single platform, a federated model and an integration layer, and justify your choice against the constraints.
Read the worked answer
A single-platform replacement is the cleanest target but fails the constraints: seven providers, six tools, limited budget, no early termination and 12 months. It would become a procurement and migration programme, not a service integration programme.
A purely federated model, where each provider keeps its tool and the customer has a portal, is cheap but reproduces the current problem: no shared incident identity, no reliable ownership and manual reconciliation.
The best fit is an integration layer with a single front door. The customer retains ServiceNow as the service desk and service integration platform; providers keep their tools but must expose and consume a defined API or exchange format. A shared incident ID, priority, service and assignment data are synchronized. The CMDB is federated by CI class, with an authoritative source per class and a reconciliation service. A single major incident bridge and dashboard sit above the tools.
This pattern respects contracts, avoids rip-and-replace and delivers the CIO's 'single pane' as a service view rather than a single product. The trade-off is integration engineering and data governance, which must be funded explicitly.
2. Define the minimum shared data model and the ownership rules needed for cross-provider incidents and configuration items. Explain why each element is necessary.
Read the worked answer
For incidents, the minimum shared data set should include: a global incident ID; the affected business service; severity and priority using one matrix; the current owning provider and assignment group; the incident status and last update time; the SLA/OLA clock; and the major incident parent-child link. These elements are necessary because without them Meridian cannot tell whether two tickets describe the same event, who must act next, or whether a handoff is late.
For configuration items, the minimum set should include: CI ID; CI class; name; location; owning provider; supporting service; upward and downward relationships; operational status; and last verified date. Ownership must be by CI class and by service, not by tool. For example, the hosting provider may be authoritative for database instances, the network provider for circuits, and Meridian for service mapping. Each class has one authoritative source and a defined reconciliation frequency.
The key rule is authoritative source, not master tool. Providers can keep their own records, but where a conflict exists the class owner's record prevails. This must be written into the data-sharing schedule, including the two providers that currently refuse raw data. They can expose the required fields via API rather than raw extracts, which addresses confidentiality while enabling integration.
3. Sequence the first six months of work and identify two quick wins and two risks.
Read the worked answer
Months 1-2: agree the minimum data model, the shared priority matrix and the authoritative-source rules with all seven providers. Start with the top 10 business services, not all 12,000 CIs. Months 3-4: implement a shared incident ID and automated exchange between ServiceNow and the two highest-volume provider tools; stand up a single major incident bridge with a named SIAM controller. Months 5-6: pilot federated CMDB reconciliation on 500 CIs supporting two distribution-centre services; publish a service dashboard showing handoff time and ownership.
Quick win one: a single major incident bridge and shared bridge number. This directly addresses the four-hour assembly failure and builds credibility. Quick win two: a common priority matrix for the top services, which reduces disputes at handoffs without waiting for tool integration.
Risk one: data quality collapses because the 30% duplication is replicated into the integration layer. Mitigation: reconcile a bounded pilot before scaling, and assign class owners. Risk two: provider resistance hardens around confidentiality. Mitigation: offer API-level field exchange, not raw data, and make the data schedule a contract change rather than an informal request. A third risk is that the CIO treats the dashboard as the outcome; the governance process must use it to make decisions.