Turning Ambiguity Into Execution

There is a common misconception about the role of a Business Systems Analyst.

The BSA receives requirements, writes Jira tickets, documents a few process flows, hands everything to developers, supports UAT, and moves on to the next project.

That may describe the mechanics of the job. True.

However, it does not describe the real job of a senior BSA.

At the senior level, the work starts much earlier.

It starts when a business stakeholder says:

“Salesforce isn’t working.”

Or:

“We need to fix CPQ.”

Or:

“Sales doesn’t trust the data.”

Or my personal favorite:

“Can we just automate this?”

Those aren’t requirements.

They’re signals.

The real job of a Senior Business Systems Analyst is to take those signals — the complaints, competing priorities, disconnected workflows, technical constraints, spreadsheet workarounds, executive objectives, and sometimes contradictory stakeholder opinions — and turn them into something the organization can actually execute.

Ambiguity → structure → decisions → requirements → systems → adoption → business outcomes.

That is the work.

And after more than a decade working across Salesforce, revenue technology, GTM systems, CPQ, business process transformation, and enterprise environments, I’ve learned that this translation layer is often where projects are won or lost.

The BSA Sits Between Three Different Worlds

Enterprise systems work typically involves three groups that think very differently.

Business leaders think in outcomes.

They want faster growth, better forecasting, improved sales productivity, cleaner data, lower operational friction, stronger governance, or higher adoption.

Business users think in workflows.

They think:

• Why do I have to enter this twice?
• Why was my quote rejected?
• Why can’t I find this customer?
• Why does this opportunity have the wrong territory?
• Why am I using Salesforce, Slack, email, and a spreadsheet to complete one process?

Technical teams think in systems.

Objects. Fields. APIs. integrations. validation rules. flows. permissions. data models. Apex. middleware. environments. deployment dependencies.

A strong Senior BSA has to move comfortably between all three.

If an executive says:

“We need better pipeline visibility.”

the BSA can’t simply create a Jira story called:

Improve Pipeline Visibility.

The real questions begin there.

What does visibility mean?

Is the problem incomplete opportunity data?

Poor stage definitions?

Weak pipeline governance?

Incorrect territory assignment?

Duplicate records?

Inconsistent forecasting behavior?

Missing activity capture?

Bad integrations?

A reporting problem?

Or does leadership simply not trust the process generating the data?

Those are very different problems requiring very different solutions.

This is why requirements gathering is not transcription.

It is investigation.

Start With the Process, Not Salesforce

One of the most important lessons I’ve learned working with Salesforce and GTM systems is that not every business problem is a Salesforce problem.

And not every Salesforce problem requires more Salesforce configuration.

Sometimes the best solution is:

• a process change,
• clearer ownership,
• better governance,
• a redesigned approval matrix,
• improved enablement,
• a data cleanup,
• an integration change,
• or eliminating a step entirely.

Before opening Setup, I want to understand how the business actually operates.

That often means building a current-state process map. Consider questions such as:

What happens first?

Who owns the step?

What information is required?

Where is the information stored?

What system becomes the system of record?

Where does the handoff occur?

What happens when the happy path fails?

Where are people leaving the system and moving into spreadsheets, Slack, email, or manual workarounds?

A process map can expose problems that are almost invisible in a requirements document.

Consider a quote-to-cash workflow involving:

Salesforce → CPQ → approval workflows → DocuSign → ERP → billing

On paper, that may look like one business process.

Operationally, it could contain dozens of handoffs, decision points, exception paths, integrations, permissions, and dependencies.

The most dangerous parts are often between the boxes.

That’s where senior BSA thinking becomes valuable.

From Process Maps to Executable Requirements

Once the problem is understood, the next challenge is turning business intent into something a technical team can actually build.

That means moving from:

“We need a better approval process.”

to something much more precise.

Which transactions require approval?

At what threshold?

Based on what combination of discount, product, geography, contract term, customer segment, or deal type?

Who approves first?

Can approvals occur in parallel?

What happens if the approver is unavailable?

What information must the approver see?

Can the requestor modify the transaction while approval is pending?

What happens after rejection?

What happens after resubmission?

What happens to downstream systems?

Now we can start talking about:

• business requirements,
• functional requirements,
• user stories,
• acceptance criteria,
• process diagrams,
• decision tables,
• data mappings,
• integration requirements,
• role hierarchies,
• permission sets,
• exception handling,
• and non-functional considerations.

And yes, eventually that becomes Jira.

But Jira should be the output of good thinking — not the substitute for it.

A Jira ticket with perfect formatting can still represent a terrible requirement.

A Good User Story Is More Than “As a User…”

Agile teams sometimes become overly focused on story syntax.

As a sales representative, I want X so that I can Y.

Fine.

But the value is not in correctly filling in the template.

The value is in eliminating ambiguity before development begins.

A strong story should help answer questions like:

Trigger: What causes the process to begin?

User: Who is performing the action?

Inputs: What data must already exist?

Business rules: What logic determines the outcome?

System behavior: What exactly should Salesforce or another platform do?

Exceptions: What happens when the standard path doesn’t apply?

Integrations: What downstream or upstream systems are affected?

Permissions: Who can view, edit, submit, approve, or override?

Acceptance criteria: How will we prove that the requirement has been satisfied?

That’s the difference between writing tickets and engineering clarity.

The Senior BSA Has to Challenge Requirements

This is one of the biggest transitions between junior and senior systems work.

A senior analyst cannot simply say yes. Typically, an analyst is negotiating for a no or an alternative.

Stakeholders frequently request solutions based on the symptoms they can see.

Someone says:

“We need another field.”

Maybe.

But why?

What decision will that field support?

Who owns the data?

Where does the value come from?

Is the information already available elsewhere?

Does it need to be reportable?

Should it be calculated?

Will another integration consume it?

What happens when no one maintains it six months from now?

Every new field, automation, approval rule, integration, custom object, and exception creates additional system entropy.

Salesforce environments rarely become overly complex because one person made one terrible decision.

They become complex because hundreds of individually reasonable decisions accumulate without enough architectural discipline.

Senior BSA thinking means being willing to ask:

Do we actually need this?

Sometimes the most valuable recommendation I can make is not what to build.

It’s what not to build.

Think End-to-End, Not Ticket-to-Ticket

This becomes especially important in GTM systems.

A seemingly small Salesforce change can affect an entire revenue process.

Imagine changing how a product is represented during quoting.

That could affect:

Salesforce product data → CPQ configuration → pricing rules → discount approvals → quote templates → DocuSign → order creation → Oracle or another ERP → billing → reporting → renewals.

The Jira story may belong to one sprint.

The business process doesn’t.

This is why strong BSAs think horizontally across the architecture.

When working around Salesforce CPQ and quote-to-cash processes, for example, I am constantly thinking about dependencies:

What happens upstream?

What happens downstream?

What happens when the transaction is amended?

What happens during renewal?

What happens when a rep creates something incorrectly?

What happens when an integration fails?

The happy path is usually easy.

Enterprise systems get interesting when reality shows up.

UAT Is Not a Ceremony

User Acceptance Testing is another area where senior BSA thinking matters.

UAT should not be:

“Here is the feature. Please click around and tell us whether it works.”

A good UAT strategy begins much earlier.

The analyst should understand the business scenarios well enough to identify:

• critical workflows,
• high-risk transactions,
• edge cases,
• negative scenarios,
• integration dependencies,
• permission differences,
• data variations,
• approval paths,
• regional considerations,
• and downstream consequences.

If we’re testing CPQ, I don’t only care whether someone can generate a quote.

I care what happens with:

• different products,
• pricing structures,
• discount thresholds,
• multi-year deals,
• amendments,
• renewals,
• approvals,
• currencies,
• territories,
• user profiles,
• customer types,
• and integration handoffs.

And when something fails, the job isn’t simply to write:

UAT FAILED

in Jira.

Why did it fail?

Bad requirement?

Configuration defect?

Incorrect test data?

Integration issue?

Missing permission?

Unexpected business rule?

Training problem?

That diagnostic thinking is enormously valuable because it keeps organizations from fixing the wrong problem.

Technical Fluency Matters — Even When You’re Not the Developer

I don’t believe a BSA needs to pretend to be an engineer.

But working effectively in enterprise systems requires technical fluency.

When you’re working with Salesforce, CPQ, Oracle, DocuSign, Gainsight, Clari, LeanData, Marketo, APIs, middleware, or other pieces of the modern revenue stack, technical architecture affects business behavior.

A strong BSA should be comfortable discussing concepts such as:

• Salesforce objects and relationships
• data models
• SOQL
• declarative automation
• Flow
• validation rules
• permission sets
• role hierarchy and sharing
• APIs
• integration mappings
• upstream/downstream dependencies
• master data
• system-of-record decisions
• sandbox environments
• deployment sequencing
• regression testing
• release management
• technical debt

You don’t have to write every line of code.

You do need to understand the implications of what is being built.

That technical fluency also improves communication with architects, developers, admins, QA engineers, product managers, RevOps teams, and implementation partners.

You become the connective tissue between the people asking why and the people determining how.

Documentation Is Part of the Architecture

Documentation sometimes gets treated as administrative work.

I see it differently.

Good documentation is an operational control.

Process maps, requirements, decision logs, configuration notes, data dictionaries, UAT scenarios, training materials, and knowledge articles create organizational memory.

Without that memory, companies repeatedly rediscover why decisions were made.

I’ve built documentation ranging from detailed business requirements and UAT artifacts to practical enablement materials such as a “7 Steps to Getting Started with Clari” guide.

Those artifacts serve different audiences, but they solve the same fundamental problem:

How do we make complexity understandable enough that people can act on it?

A brilliant system that nobody understands eventually becomes a bad system.

Adoption Is Part of the Solution

I have also learned that a technically correct implementation can still be an operational failure.

You can deliver:

• elegant Salesforce architecture,
• sophisticated automation,
• perfect process diagrams,
• clean Jira stories,
• passed test scripts,
• and a successful production deployment…

…and still fail.

If the business doesn’t understand the process, doesn’t trust the system, or quietly returns to spreadsheets three weeks later, the transformation never happened.

That is why I increasingly view change management and adoption as systems problems, not post-launch communications exercises.

A successful implementation asks:

Do users understand why the process changed?

Does the system make the desired behavior easier?

Are responsibilities clear?

Do managers reinforce the new process?

Are KPIs available to measure adoption?

Can the organization identify where users are bypassing the workflow?

What happens after go-live?

Because enterprise transformation doesn’t end with Version 1.

There will be V2.

There will be V3.

There will be lessons from production.

There will be edge cases no workshop uncovered.

There will be business conditions that change six months later.

The system has to evolve without becoming unmanageable.

AI Makes This Role More Important, Not Less

Another factor is that AI is accelerating another major shift in business systems.

Salesforce Agentforce and similar AI platforms are creating new possibilities around sales productivity, service, automation, decision support, and customer interaction.

I’ve had exposure to that evolution through enterprise Salesforce work, including supporting Agentforce-related deployment activity in Japan.

But AI doesn’t eliminate the need for strong business analysis.

It magnifies it.

If anything, AI forces organizations to become even clearer about:

• process design,
• data quality,
• permissions,
• governance,
• decision boundaries,
• exception handling,
• human oversight,
• and intended business outcomes.

An AI agent operating on a poorly designed process doesn’t magically create a good process.

It can simply execute the bad process faster.

Before asking:

“Where can we use AI?”

I believe organizations should ask:

“What decision or workflow are we trying to improve?”

That is fundamentally a business systems question.

The Deliverable Isn’t the Requirement. It’s the Outcome.

Over the course of my career, I’ve worked across high-growth technology companies and large enterprise environments, including Johnson & Johnson / Shockwave Medical, Palo Alto Networks, WhiteHat Security, and Mojo Networks.

The technologies have changed.

The business problems have changed.

The titles have changed.

But the core challenge has remained remarkably consistent.

There is usually a gap between what the organization wants and what the organization knows how to execute.

That gap is where a Senior Business Systems Analyst creates value.

You investigate the problem.

You map the process.

You challenge assumptions.

You identify dependencies.

You bring the right stakeholders together.

You translate objectives into requirements.

You work with architects, developers, admins, QA, product teams, RevOps, Sales, Finance, and Operations.

You structure Jira epics and stories.

You define acceptance criteria.

You help drive UAT.

You investigate defects.

You support adoption.

You document what matters.

And throughout all of it, you keep asking the question that matters most:

What business outcome are we actually trying to create?

Because the real deliverable isn’t a Jira ticket.

It isn’t a BRD.

It isn’t a Salesforce Flow.

It isn’t a process map.

It isn’t even a successful deployment.

The real deliverable is a business process that works better after you leave than it did before you arrived.

That, to me, is the real job of a Senior Business Systems Analyst.

Strategic BSA Thinking

The strongest Senior Business Systems Analysts don’t simply sit between business and technology.

They create alignment between them.

They understand enough about the business to challenge the solution.

They understand enough about technology to challenge the requirement.

They understand enough about people to know that neither matters unless the organization can actually execute the change.

That’s where the role becomes strategic.

And that’s where business systems work stops being about maintaining platforms and starts becoming part of how a company operates, scales, and grows.