When a $2B privately held business in the Pet Health space began implementing Oracle, the portion of the project related to employee data integration appeared to be a technology initiative.

Employee data would flow from six different HR systems into Oracle, organizational hierarchies would be established, and the business would move forward on a modern enterprise platform.

Hearing about it, I thought, “this makes sense in theory, but it seems like a stretch.” I asked to review the plan. Like a lot of enterprise implementation plans these days, the plan made sense.

Until I took a detailed look at what had been developed to date.

I had already spent several years working on other transformation initiatives and had developed an appreciation for how much complexity rapid growth had introduced into the organization. The turning point came after the lead systems architect left the project. During a walkthrough with the technical team and a large consulting firm, they demonstrated the proposed HR-to-Oracle integration.

The architecture was thoughtful.

It simply assumed an enterprise that didn't exist.

The design depended on a single employee reporting hierarchy flowing into Oracle from the HR systems. It was a logical assumption, but as I continued working with HR, Finance, and Operations, it became increasingly clear that, in practice, the organization wasn't truly operating from a single hierarchy.

Some employees legitimately reported one way for HR purposes and another for financial accountability. Other operational relationships existed across systems that no individual HR application could represent. Oracle itself had been designed to accept hierarchy information only from those source systems, leaving no practical way to manage legitimate enterprise exceptions once production began.

The technology wasn't exposing bad data. It was exposing a business that was more interconnected than the systems had been designed to understand.

As discussions continued, one question surfaced repeatedly. "When will HR finish cleaning up the hierarchy?" Although it sounded like the right question, it turns out that it was not.

Even with perfectly maintained HR data, the underlying business requirement would still remain unmet. The organization had established a policy before fully understanding how the business actually functioned. From that point forward, every discussion focused on making reality conform to the design instead of asking whether the design reflected reality.

The problem wasn't data quality.

It was enterprise stewardship.

No single team owned the relationships between HR, Finance, Oracle, ServiceNow, and the operational realities of forty thousand employees. Every system accurately represented its own domain. No one owned the seams between them.

Once I understood that, I stopped thinking about the integration itself.

The integration wasn't the project. The missing governance was, and Go-live confirmed it.

Within hours, hierarchy requests began arriving.

Then dozens more.

By the end of the first day, well over one hundred requests had accumulated.

Each request required a very specific import format that hadn't yet been provided. At the same time, the implementation team was consumed by more urgent production issues—system access, stabilization, and the countless demands that accompany every major ERP deployment.

Exactly the situation I had worried about had arrived.

Not because anyone had done poor work.

Because the enterprise problem had never actually been solved.

Within days, I received the file specifications and the approval to move the solution into Quickbase. The objective wasn't to build another application. It was to establish an operational process for a responsibility that had never really belonged to anyone.

Rather than trying to create another source of truth, I designed a governed place where multiple authoritative systems could be reconciled responsibly before changes moved back into the enterprise.

Within the project, we eventually began referring to it as a destination of truth. Why? Because while it did not replace HR or Oracle as the data source, it did become the place where the enterprise could responsibly resolve the seams between them.

The application quietly proved its value.

One solved request became ten.

Ten became hundreds.

Hundreds became thousands.

Several months later, the organization built an automated pathway into ServiceNow so requests could flow directly into its operational processes. What had been conceived as a temporary solution was gradually becoming part of how the enterprise operated.

A few weeks ago, I opened the dashboard.

Upwards of thirty thousand hierarchy requests had passed through the application since its inception.

It had been built two years earlier as a temporary solution.

It is still there today.

Applications don't usually survive that long by accident. They survive because the enterprise still needs the process they enable.

Looking back, I think about the weekly program status meetings. While most work-streams gradually turned green, the hierarchy work never quite did. At the time, I assumed that was an earnest reflection of the state of the project. Later I realized it reflected something much more important. One leader was willing to report risk as it actually existed instead of how everyone hoped it existed.

I've found that meaningful transformation almost always begins there.