Why Business Analysts Should Explain an Automation Script Aloud

STRONG EXPLANATION — FIRST 90 SECONDS:

Reviewer: "Walk me through this automation
script."

Business Analyst: "Sure. Let me start with
what it's for before how it works.

The business rule: invoices over $10,000
must match a PO within 2%. If they don't,
finance needs to review before payment.

So the script reads the invoice CSV, validates
the header, matches each line to a PO in the
staging table, and calculates the variance.
If variance > 2%, it writes the row to a
review queue and alerts the finance channel.
If variance <= 2%, it writes to the ERP.

The failure modes: if the ERP is down, it
writes to a fallback file and alerts ops —
it doesn't retry blindly. If the CSV header
is wrong, it stops and alerts rather than
processing bad data.

The trade-off: I chose a hard stop on bad
headers because processing them silently
once cost us a 3-day reconciliation. The
cost is that a header typo blocks the run,
so I added an alert with the exact column
mismatch.

Let me show you the validation and the
alert."

What the reviewer thinks in 90 seconds:
- "They started with the business rule." ✅
- "They explained the data flow in plain
  words." ✅
- "They named the failure modes." ✅
- "They named a trade-off and the cost of
  the alternative." ✅
- "They know this script." ✅

Signal: strong. The rest of the explanation
confirms it.

WEAK EXPLANATION — FIRST 90 SECONDS:

Reviewer: "Walk me through this automation
script."

Business Analyst: "OK, so there's a for loop
here that goes through the rows, and then
an if statement that checks the variance,
and then it writes to the database. There's
also a try-catch block. I used pandas to
read the CSV and then there's a function
for the PO matching."

What the reviewer thinks in 90 seconds:
- "They're describing syntax, not the
  business rule." ❌
- "No data flow — where does the CSV come
  from, where does it go?" ❌
- "No failure modes." ❌
- "No trade-off." ❌
- "I'll ask a follow-up and see if it's
  memorization or understanding." ⚠️

What happens next:
- The reviewer asks "What happens if the
  ERP is down?"
- The BA says "I think there's a try-catch."
- The reviewer asks "What does the catch
  block do — log, retry, or fallback?"
- The BA pauses.

Signal: weak. The rest of the explanation
is an uphill climb.

Why it failed:
❌ Syntax before business rule
❌ No data flow
❌ No failure modes
❌ No trade-off
❌ The first 90 seconds signaled "I ran it,"
  not "I own it"

FAILURE MODE ANSWER — WHAT DECIDES:

Reviewer: "What happens if the ERP write
fails halfway through the batch?"

WHAT THE BA SAYS:
"It rolls back the batch and alerts ops. Let
me walk through why.

The write is wrapped in a transaction per
batch of 500 rows. If any row fails — a
constraint violation, a connection drop —
the whole batch rolls back, so staging never
has a partial record. The row that caused the
failure is logged with the error and the PO
it was matched against.

The trade-off: batch-level rollback means
one bad row blocks 499 good rows. I chose
that over row-level commits because row-level
would leave staging in a half-written state
that finance can't reconcile.

The alternative would be to write the bad row
to a quarantine table and continue. I didn't
do that because it adds a second write path
and more code to test. For this volume —
about 2,000 rows a night — a blocked batch
is a 10-minute fix, not a disaster.

So: rollback per batch, alert with the
offending row, and a runbook for ops."

What the reviewer thinks:
- "They named the transaction boundary." ✅
- "They named the failure and the alert." ✅
- "They named the trade-off: batch vs.
  row-level." ✅
- "They named the alternative and why they
  rejected it." ✅
- "They thought about ops, not just code." ✅

Signal: confirmed trust.

Why it decides:
✅ Transaction boundary is explicit
✅ Failure is logged with context
✅ Trade-off is named
✅ Alternative is named and rejected
✅ Ops runbook exists

TRACEABILITY ANSWER — WHAT DECIDES:

Reviewer: "How does finance know what the
script rejected?"

WHAT THE BA SAYS:
"Every rejected row goes to a review queue
table with four columns: the row data, the
reason, the PO it failed against, and a
timestamp. Finance opens a filtered view,
fixes the row, and re-runs only that row.

The reason codes are the key part. There are
five: HEADER_MISMATCH, PO_NOT_FOUND,
VARIANCE_EXCEEDED, DUPLICATE_INVOICE, and
ERP_TIMEOUT. Each maps to a different action
— PO_NOT_FOUND means finance calls procurement,
VARIANCE_EXCEEDED means they review the
contract, ERP_TIMEOUT means they just retry.

The trade-off: the review queue is a second
system to maintain. I chose it over email
alerts because email gets lost and finance
can't track it. The cost is one more table
and a view, but it saves the "did anyone
see the alert?" conversation.

I also added a daily summary: how many
rejected, by reason. That's how we caught
the duplicate-invoice spike last quarter."

What the reviewer thinks:
- "They named the queue and the columns." ✅
- "Reason codes map to actions." ✅
- "The trade-off is named: queue vs. email." ✅
- "They added a summary that caught a real
  issue." ✅
- "This is BA-owned automation." ✅

Signal: confirmed trust.

Why it decides:
✅ Traceability artifact is named
✅ Reason codes are actionable
✅ Trade-off: queue vs. email
✅ Daily summary with a real outcome

WALKTHROUGH — STRONG VS. WEAK SIGNAL:

Scenario: "Explain this invoice-matching
script to a non-technical finance lead."

WEAK SIGNAL:
"So the script opens the CSV, loops through
the rows, does a left join with the PO table,
checks if the variance is more than 2%, and
if it is, writes to a review table, otherwise
it writes to the ERP. There's a try-catch
around the ERP call."

What the reviewer thinks:
- "That's a code translation, not an
  explanation."
- "The finance lead doesn't know what a
  left join is."
- "They didn't explain what finance should
  expect."
- Signal: weak.

STRONG SIGNAL:
"Think of this script as a pre-check before
payment. For every invoice line, it asks:
'Do we have a PO for this? Is the amount
within 2% of the PO?'

If yes, it passes the line to the ERP for
payment. If no, it puts the line in a review
queue with the reason — and finance gets a
daily list of exactly what needs attention.

The 2% is the same tolerance in the finance
policy, so nothing changes for you — you just
see fewer manual checks. The one new thing:
if the file itself is malformed, the script
stops and tells you which column is wrong
instead of half-processing it.

The trade-off: if the ERP is down, the run is
delayed rather than partially written. You'll
get an alert in the finance-ops channel."

What the reviewer thinks:
- "They translated the logic into finance
  language." ✅
- "They tied it to the existing policy." ✅
- "They named what changes for finance." ✅
- "They named the failure behavior." ✅
- "They named the trade-off." ✅
- Signal: confirmed trust.

Why it decides:
✅ Business language, not code language
✅ Tied to the existing policy
✅ Named what changes for the audience
✅ Failure behavior is explicit
✅ Trade-off is explicit

TAKE-HOME REVIEW — STRONG VS. WEAK SIGNAL:

Scenario: "Review this take-home. The BA
automated a weekly sales report."

WEAK TAKE-HOME:
- One 300-line script, no functions
- No input validation
- No error handling
- Hard-coded file paths
- No README

What the reviewer thinks:
- "It runs, but it's a one-off."
- "No validation, no error handling, no
  explanation."
- "I can't tell if they can hand this to
  someone else."
- Signal: no-hire for mid/senior.

STRONG TAKE-HOME:
- Three functions: load, validate, write
- Validation: checks the header, row count,
  and null rate; stops with a named error
- Error handling: if the write fails, it
  logs the row and continues, then reports
  the failure count
- Config: file paths and thresholds in a
  config file
- README: setup, the business rule, the
  failure behavior, and a trade-off —
  "I chose to continue on row-level write
  failures instead of rolling back the batch,
  because a partial report is better than no
  report for a weekly cadence. The cost is
  that finance must check the failure count."
- A 5-line "explain it to a stakeholder"
  section written in plain English

What the reviewer thinks:
- "Functions are separated by concern." ✅
- "Validation is explicit and fails loudly." ✅
- "Error handling is thoughtful." ✅
- "Config is externalized." ✅
- "The README explains decisions and
  trade-offs." ✅
- "There's a stakeholder explanation." ✅
- Signal: strong hire.

Why it decides:
✅ Functions, not one blob
✅ Validation with a named error
✅ Error handling with a report
✅ Config externalized
✅ README with trade-offs
✅ Stakeholder explanation included

Automation Script Explanation Checklist:

FIRST 90 SECONDS:
☐ Start with the business rule, not the
  syntax
☐ Explain the data flow in plain words:
  where it comes from, where it goes
☐ Name a failure mode early
☐ Name the business impact of the failure
☐ Avoid jargon unless the audience knows it

WHAT DECIDES:
☐ Name the input validation: header,
  row count, null rate, tolerance
☐ Say what happens on bad input: stop,
  quarantine, or continue
☐ Name the failure mode: ERP down, write
  failure, timeout
☐ Name the rollback behavior: batch,
  row-level, or fallback file
☐ Name the traceability: review queue,
  reason codes, daily summary

WHAT CONFIRMS:
☐ Explain the trade-off in the design:
  batch vs. row-level, queue vs. email
☐ Explain what changes for the stakeholder:
  fewer checks, new alerts, new queue
☐ Explain the alternative you rejected and
  why
☐ Can re-explain in 30 seconds to a
  non-technical audience
☐ Can answer "what happens if…" without
  opening the code

RED FLAGS:
❌ Starts with "there's a for loop"
❌ No data flow
❌ No failure modes
❌ No trade-offs
❌ "I think there's a try-catch"
❌ Can't explain what the stakeholder sees
❌ Can't re-explain in plain English

Why this works:
- The first 90 seconds set the signal
- The rest of the explanation confirms or
  overturns it
- Business framing, failure modes, and
  trade-offs are the three things that
  can't be faked

30-DAY PRACTICE PLAN (FOR BAS):

Week 1 — Business framing drills
☐ Pick 5 scripts you've written or run
☐ For each, write the business rule in
  one sentence, no jargon
☐ Record yourself explaining it in
  90 seconds
☐ Cut every sentence that starts with
  "the code does…"

Week 2 — Failure modes
☐ For each script, list 3 failure modes
☐ For each, write what happens: stop,
  rollback, quarantine, or alert
☐ Write the trade-off for each decision
☐ Re-record the explanation with the
  failure modes included

Week 3 — Stakeholder translation
☐ Explain one script to a non-technical
  colleague
☐ Ask them what they think changed for
  them
☐ Fix the parts they didn't understand
☐ Add a "what changes for you" section to
  your README

Week 4 — Mock walkthroughs
☐ Run 2 mock walkthroughs with a peer
☐ Ask them to score the first 90 seconds
☐ Re-run with a stronger business-rule
  opening
☐ Compare the two recordings

Signs it's working:
✅ You start with the business rule without
  thinking
✅ You name failure modes and rollback
  behavior
✅ You explain what changes for the
  stakeholder
✅ You name a trade-off in the design
✅ You can re-explain in 30 seconds to
  anyone
✅ The reviewer asks "what else?" instead
  of "I don't follow"