Business Analyst
"Business analyst" is one title covering two genuinely different jobs, which is why the salary ranges and job descriptions you find never agree. This page separates them, gives an honest read on pay and AI exposure, and shows where the role leads.
Typical Pay (US)*
$90kmedian** AI-estimated from general U.S. labor-market patterns — not measured data from the U.S. Bureau of Labor Statistics or any official source. Real pay varies widely by location, employer, experience, and timing.
Outlook
Growth is modest — Mochivia's dataset estimates about 3.6% annually for the nearest occupation — and the artifact-production half of the job is squarely in the automation path. Drafting user stories from a transcript, converting notes into a process diagram, writing a first-pass requirements document, and building a standard variance report are all things a model now does in seconds and reasonably well. What resists automation is what O*NET itself points at: judgment and client-facing work. Getting three departments to agree on one definition, noticing the requirement nobody stated because everyone assumed it, and carrying political weight in a prioritization argument are not documentation tasks. The analysts who stay valuable move toward owning outcomes, which is why this role is a strong stepping stone into product or program management rather than a place to sit for fifteen years.
What does a Business Analyst do?
Before anything else: business analyst names two different jobs, and figuring out which one a posting means is the single most useful thing you can do. The first is the IT or systems business analyst. This person sits between a business team and a software team, works out what the business actually needs, and writes it down precisely enough to build — user stories with acceptance criteria, process diagrams in BPMN, data-flow mappings, and the specification for how an order should move through four systems that were never designed to talk to each other. They run requirements workshops, arbitrate between people who want incompatible things, and do user acceptance testing when the build lands. Tools are Jira, Confluence, Visio or Lucidchart, and increasingly SQL.
The second is the finance or operations business analyst. This person owns reporting and analysis for a business function — building the monthly operating review in Excel, maintaining a forecast model, investigating why a distribution center's cost per unit rose, sizing the savings from a process change. Tools are Excel first, then Power BI or Tableau, then an ERP system like SAP or NetSuite. The word "analyst" is doing very different work in the two jobs: one analyzes processes and requirements, the other analyzes numbers.
Both differ from the data cluster in a way worth being precise about. A data analyst answers questions from data in a warehouse using SQL. An analytics engineer builds the modeled tables that analyst queries. A data engineer builds the pipelines that land the data. A business analyst mostly works on process, requirements, and decisions — the data stack is something they consume occasionally, not something they own. When a company says "business systems analyst," they usually mean the first job with more technical depth.
O*NET 28.3 splits this across two occupations rather than one: 13-1111 Management Analysts, which lists "Business Analyst" as an alias and carries an estimated median near $99,000 with about 3.6% estimated annual growth, and 15-1211 Computer Systems Analysts, median near $103,000, which lists "Business Systems Analyst" as an alias. The federal assessment of the first is that judgment and client-facing work limit automation despite the analytic core — a fair description of where the durable value sits. The role suits people who are good with ambiguity and better with people than most technical staff, and it is one of the most reliable first rungs into product management, program management, or data work. It does not suit people who want to build things themselves; you will specify far more than you construct.
A day in the life
- Run a 90-minute requirements workshop with operations and finance, and leave with a process map neither side had seen written down
- Turn that map into eight user stories with acceptance criteria in Jira, then defend the edge cases in backlog refinement
- Discover mid-sprint that two stakeholders defined "cancelled order" differently and get a written decision from whoever owns it
- Rebuild a monthly operating report in Excel because a source system changed its export column order again
- Write the current-state versus future-state comparison for a system migration, including the manual steps that quietly disappear
- Run user acceptance testing on a release, log four defects, and negotiate which are launch blockers
- Draft a one-page business case with cost, benefit, and assumptions for a process change that saves 20 hours a month
How to become a Business Analyst
- 1
Decide which business analyst job you want
~2 weeksThe IT and systems path leads toward product and technical program management; the finance and operations path leads toward FP&A and strategy. The skills only partly overlap, so choose before you invest.
- 2
Learn requirements and process modeling
~2 monthsUser stories with acceptance criteria, BPMN process diagrams, current-state versus future-state analysis, and elicitation techniques. The BABOK guide is the standard reference for the vocabulary employers use.
- 3
Get seriously good at Excel, then add SQL
~3 monthsPivot tables, lookups, and model structure carry the finance path entirely. SQL has become close to mandatory on the systems path because waiting on an analyst for every question makes you slow.
- 4
Learn the delivery tooling and one BI tool
~1 monthJira and Confluence for how work actually moves, plus Power BI or Tableau for reporting. These appear in nearly every posting and are quick to become credible in.
- 5
Enter sideways from a domain seat
~6 monthsOperations, customer support, finance, or implementation roles convert into business analysis extremely reliably, because domain knowledge is the part employers cannot train quickly. No degree is a hard gate.
- 6
Add a certification only if your market rewards it
~4 monthsCBAP or PMI-PBA genuinely help in consulting, government, healthcare, and large enterprises where credentials gate interviews. At technology companies they carry almost no weight — skip them there.
Skills that matter
Learn the actual skills
Tell Mochivia your goal and it builds your personal curriculum — 15 minutes a day.
Build My Path