Shared Services Isn't a Structure Problem — It's a Data Problem
When universities consolidate business operations into shared services, the real test isn't the org chart — it's whether the underlying systems can actually support the new model.
As Marquette Today reports, the university has moved to a shared services model for its business operations. The announcement will read, to many administrators, as an organizational story — departments consolidated, roles redefined, reporting lines redrawn. That framing isn't wrong, but it is incomplete.
Shared services restructuring in higher education tends to get planned as a people-and-process exercise. The Gantt charts fill up with change management milestones, communication rollouts, and training schedules. What gets underestimated, consistently, is the degree to which the old operating model was encoded in the systems themselves.
The Hidden Technical Debt of Decentralization
When business functions live inside individual colleges or units, those units often develop their own workarounds — shadow spreadsheets, local database instances, one-off integrations between the SIS and a department-level finance tool. These aren't failures of discipline. They're rational responses to systems that weren't built to serve a distributed model cleanly.
The problem surfaces when you try to centralize. Suddenly, the shared services team inherits not just the work, but the entire ecosystem of local adaptations that made the work possible. A procurement process that ran fine inside the College of Engineering may depend on a custom approval routing that no one documented, pulling from a data field that the central ERP doesn't populate the same way.
This is where shared services transitions quietly stall. The org chart says consolidation is complete. The actual workflows say otherwise. Staff in the new center spend months reverse-engineering what the old units knew instinctively. Throughput drops. Leadership wonders why efficiency gains aren't materializing.
What Sustainable Consolidation Actually Requires
The institutions that navigate this well treat the systems audit as foundational work, not a downstream IT task. Before the new service center goes live, someone has to map where data originates, how it moves, and which local customizations are load-bearing versus legacy clutter. That's less glamorous than the reorganization announcement, but it determines whether the model holds.
It also requires honest assessment of what the central platforms can actually do at scale. A student information system configured for departmental autonomy doesn't automatically perform well when volume and standardization demands shift. Neither does a CRM that was implemented unit by unit, with inconsistent field definitions and parallel workflows.
Institutions that treat shared services as an opportunity to rationalize their underlying architecture — not just their org charts — tend to come out ahead. Those that graft the new model onto unreformed systems tend to find themselves revisiting the whole exercise in three to five years.
For institutions currently in this transition, or planning one, the capabilities we bring to integration and operational design reflect exactly this kind of systems-first thinking. The structural question and the technical question aren't separable.
If Marquette's implementation reflects careful pre-work on the data and systems side, it stands a real chance of delivering what shared services models promise. That work rarely makes the announcement. It tends to show up — or not — in the results.