Digital transformation is about more than just shiny new software—it’s about a fundamental shift in how we work. At my former organization, the “secret sauce” of our transformation wasn’t just the tech; it was our digital operating model.

By moving into persistent, cross-functional teams, we unlocked a game-changing opportunity: the birth of our formal business analysis community of practice (CoP).

During my time there, our team grew significantly following a major merger. On the surface, things were moving. But underneath, we were a collection of silos. Everyone was using the tools and practices “the way they always had.”

I’ll be honest: I had been staying out of the weeds and making assumptions about how the work was getting done. But when we finally stood up our CoP—meeting every four weeks for 90 minutes of “no-regrets” learning—the reality came into focus.

The discovery: We were systems analysts in disguise

We started with a deep-dive current state analysis. We split into teams, interviewed stakeholders, and reported back. The results were eye-opening.

We discovered that while we had the title of “business analyst,” we were actually operating as systems analysts. We were experts at implementing software and documenting technical gaps, but we had drifted away from the actual business of analysis.

The real turning point happened when we started “The BABOK Sprint.” We broke down the business analysis Body of Knowledge chapter by chapter, with small groups presenting their findings every four weeks.

The big realization? Business analysis is a discipline that reaches well beyond technical delivery.

Our team had come to see business analysis mainly through the lens of technology delivery. We had narrowed the role to:

  • Being the bridge between business and technology.
  • Writing functional requirements for developers.
  • Testing software and producing documentation.

When I looked at our “business requirements documents,” I realized not one was a true business document. They were all functional and system-based.

The pattern was clear: Someone else in the company would do the analysis in their head, decide we needed a “thing” (a tool, a report, a new feature), and hand it to the BA.

The BA took the order and made it happen. They were delivering solutions, but they weren’t necessarily solving problems.

Join the journey

When business requirements focus too early on how a system handles a process, we risk carrying today’s limitations into tomorrow’s solutions. That can slow our ability to automate effectively and introduce useful AI.

Start by understanding the work itself: What outcome is needed? What are the essential steps and decisions? Which policies, business rules, and controls must be respected? Where is human judgment required? Separating those needs from the way an existing system operates creates room to simplify the process and consider different ways to deliver it.

System requirements still matter, but they should follow a clear understanding of the business need. That gives us a stronger foundation for deciding where technology can help—and where it cannot.

Through this series, I’ll explore how business analysis helps organizations move beyond documenting what exists to shaping what could work better.