Fourteen Systems of Record at One Resort
A 620-room resort runs IT with nine staff; the CISO position has been vacant for seven months. Over 18 months, marketing bought a customer data platform, F&B bought a scheduling app, the spa bought a booking tool, and housekeeping adopted a consumer messaging tool for room-status updates. Guest data now sits in 14 systems, and a consultant's draft report says the group cannot state where a guest profile is mastered. The spa director insists her system is 'hers' and refuses to migrate. The GM wants one version of the truth and a decision on whether to centralise all technology decisions in IT. The CFO is alarmed by PCI scope creep and an unbudgeted 22% rise in SaaS spend.
1. Propose a governance model. Explain why a simple IT-centralisation mandate would fail here.
Read the worked answer
Why centralisation alone fails. Every one of these purchases was made because central IT was slow or silent. A flat mandate does not remove that pressure; it drives purchases to expense cards and free tiers, where they are invisible and outside security review. It also puts IT in the position of owning business outcomes it cannot influence, and it converts a data problem into a political one.
Model: decision rights by domain, not by department.
- Enterprise-decided (CIO + CFO): identity and guest profile master, network, integration standards, security review, contract signature, and any system holding payment or guest PII.
- Shared (business owns requirements and adoption; IT owns interface and security): PMS-adjacent tools such as spa booking and F&B scheduling.
- Local (department decides, IT informed): tools with no guest data and no integration.
Mechanisms that make it real. A review threshold - anything above $25k annual or touching guest/payment data goes to a monthly architecture forum with a 10-day service-level commitment, so IT cannot be slow and then complain. A named data steward per domain. A standing rule that no guest PII leaves the enterprise profile master without an approved interface, which the spa cannot override because it is a data rule, not a turf rule.
Sequencing. Publish the model, then use the spend crisis as the first test case rather than starting with the spa confrontation.
2. How would you triage the 14 systems and the spa dispute in the first 90 days, given you cannot replace everything?
Read the worked answer
Amnesty first. Run a two-week inventory with no blame and no immediate cancellation, or the remaining shadow systems simply stay hidden.
Then classify each system into four buckets:
- System of record (guest profile, reservations, folio, payment) - must be enterprise-owned and interfaced. The CDP is a candidate here; it is also the likely reason profiles are fragmented.
- Point solutions feeding a record - keep, but require an interface and a named internal owner. Spa booking and F&B scheduling probably land here.
- Duplicates - consolidate. Expect two or three of the 14 to overlap on scheduling or messaging.
- Orphans nobody claims - cancel at renewal. The audit already implies nine.
The spa dispute. Reframe from ownership of the system to ownership of the data. Treatment history feeds marketing segmentation and guest recognition, so it belongs in the enterprise profile; the therapist scheduling screens do not. Offer the spa director continued control of the workflow and configuration plus a seat at the data council, in exchange for a read interface into the profile master. If she still refuses, escalate on a documented risk basis - PCI scope and the group's inability to honour a guest data-deletion request - not on authority.
Deliverables by day 90: inventory, target map of records, cancellations booked, and one interface live as proof the model works.