Capabilities

Six areas of business, systems, and data analysis

OptiTech provides business, systems, and data analysis consulting for federal, state, and municipal programs and the contractors that deliver them. Each area lists the methods, tools, deliverables, and how we use AI.

Not a typical business analyst

  • A typical analyst documents what the program asks for. We also look at how the program works today: its systems, its tools, and how code moves from development to production. Then we find where the time goes.
  • Many programs already pay for tools they don't fully use. That can mean Jira automation, Power BI, Confluence templates, or AI features already in their Microsoft licenses.
  • We put those tools, and approved AI tools, to work on the analysis itself. The aim is clearer requirements, checked data, and a ready backlog sooner, with less manual effort.
How we work with AI

AI does the slow parts. A person does the judgment.

AI tools have changed how analysis gets done. We use them for the slow parts: reading long documents, drafting first versions, finding gaps and edge cases, and checking consistency across a large backlog.

Tools we work with

  • Hosted assistants: ChatGPT (OpenAI), Claude (Anthropic), Gemini (Google)
  • Copilot: Microsoft 365 Copilot in Word, Excel, Teams, and Outlook, and GitHub Copilot
  • Local models: open-weight models that run on one machine, used only where the program allows it

Each use below names the kind of tool that fits. On a federal program, the tool actually used is whichever one the program has approved.

Rules we follow on every program

  1. Approved tools only. We use the AI tools your program has approved, such as agency-provided tools, and nothing else.
  2. No sensitive data in public tools. No CUI, PII, source-selection, or procurement-sensitive information goes into a public AI tool. Sensitive material stays on the systems the program authorizes. If the program has no approved AI tool for it, we don't use AI on it.
  3. A person reviews every output. AI drafts. The analyst checks and edits, and signs off on what the team receives. AI never makes decisions.
  4. We keep a record. We log what AI helped produce, and label it when the program asks.

We follow each program's AI policy and federal guidance.

Download: How we use AI on federal programs (PDF)

Product names are trademarks of their owners and are used only to identify the tools we use. They don't imply any partnership with or endorsement by their makers.

01

Business analysis

The agency's need turned into requirements your developers can build from and your testers can check.

In practice (prior work, as an employee): In-house and local LLMs used to draft documentation, requirements, user stories, and test scenarios, with a person reviewing and finishing each one.

Methods, tools, AI uses, and deliverables

Frameworks and methods

  • BABOK knowledge areas as the working checklist
  • Stakeholder interviews and structured discovery
  • Current and future-state analysis
  • Gap analysis
  • UML use-case diagrams
  • INVEST user stories
  • Given/When/Then acceptance criteria
  • AI acceptance criteria
  • MoSCoW prioritization
  • Requirements traceability matrix

Tools

Jira, Confluence, Visio, Excel. AI assistants: ChatGPT, Claude, Gemini, Copilot.

AI in this work

  • Workshop transcripts become draft requirements, a decision log, and open questions (Copilot in Teams or Word, or another tool the program has approved for sensitive content). We check that every requirement traces to something a stakeholder said.
  • Business rules become draft Given/When/Then acceptance criteria and edge cases (a hosted assistant or Copilot). The product owner accepts them.
  • Policy text is compared with the current workflow to list gaps (Copilot, or a local model where the program allows it). Each gap cites the clause, and the analyst confirms it with the subject-matter expert.

Acceptance criteria for AI features

An AI feature can give a different answer each time, so "returns the right answer" isn't testable. It needs criteria for where answers come from and what happens when the AI isn't sure.

A typical criterion: The system gives the user the right policy answer.

Written for an AI feature:

  • Uses approved sources only.
  • Names the source for each answer.
  • Makes no policy determination the source doesn't support.
  • Meets the evaluation threshold the program agreed to.
  • Logs every interaction, as the program's records rules require.
  • Routes any answer below the confidence threshold to a person.

Deliverables

  • Discovery notes and problem statement
  • Current/future-state maps
  • Business rules catalog
  • User stories with acceptance criteria
  • AI acceptance criteria
  • Traceability matrix
  • Open-questions log
02

Systems analysis

A clear picture of how the systems, interfaces, and data flows behave today, and what has to change, written for the engineers who build it.

In practice (prior work, as an employee): GitHub Copilot used to query code repositories for answers about functional steps and to work through issues; browser developer tools with AI assistance used to investigate identified bugs, find likely causes, and give the engineering team recommendations so fixes could be applied faster. Engineers made the changes.

We work with engineers as the analyst. We don't write production code.

Methods, tools, AI uses, and deliverables

Frameworks and methods

  • UML activity and sequence diagrams
  • Data flow diagrams
  • Interface and API requirements
  • Data mapping
  • Dependency analysis
  • Legacy behavior documentation
  • Federal SDLC documentation practices

Tools

Jira, Confluence, Visio. GitHub, for reading API specifications and repository documentation. Salesforce, AWS-hosted environments, Splunk, and New Relic, for observing system behavior. AI assistants.

AI in this work

  • Legacy code, stored procedures, or configuration are read, read-only, to draft a plain-language "what the system does today" (GitHub Copilot chat, or a local model where the program allows it for restricted code). An engineer confirms the behavior.
  • API specifications become draft interface requirements, field-level data mapping, and error cases (a hosted assistant or GitHub Copilot). The mapping is validated against real payloads in a test environment.
  • Architecture documents and tickets become a draft dependency map (Copilot) for the tech lead to review.
  • Bug investigation: browser developer tools and an AI assistant used to investigate an identified bug, find the likely cause, and give engineers a recommendation. Engineers decide on and make the change.

Deliverables

  • Interface and API requirements
  • Sequence and data flow diagrams
  • Data mapping sheets
  • Dependency map
  • As-is system behavior document
03

Data analysis

Confirmation that a system produces what everyone assumes it produces, and reports leadership can trust.

In practice (prior work, as an employee): On a city business tax system, SQL queries against non-production environments produced metrics and reports that helped streamline collection procedures.

Methods, tools, AI uses, and deliverables

Frameworks and methods

  • Data validation and data quality checks
  • Source-to-target reconciliation
  • Migration validation
  • Entity-relationship diagrams (ERDs)
  • KPI definition
  • Root cause analysis on data defects

Tools

SQL, SSMS, Azure Data Studio, Excel, Power BI, Tableau. AI assistants, including local models where the program allows them.

AI in this work

  • Draft SQL validation queries for a migration (row counts, nulls, duplicates, referential checks) from the schema only, with no data (GitHub Copilot or a hosted assistant). The analyst reads and runs every query and interprets the results.
  • Draft the data dictionary and KPI definitions from table schemas and report specs (Copilot). The data owner signs them off.
  • Summarize data-quality findings for the program (Copilot in Excel or Word). Every number traces to a query result.

Deliverables

  • Validation and reconciliation results with an exceptions log
  • Data quality findings
  • KPI definitions
  • Dashboard and reporting requirements
04

Financial and revenue systems

Analysis for systems that collect, pay, or account for public money, from someone who has worked in treasury, tax, and revenue operations.

We don't give tax, accounting, or audit opinions.

Methods, tools, AI uses, and deliverables

Frameworks and methods

  • BPMN maps of payment, collection, and revenue flows
  • Reconciliation reviews
  • Business rules for tax and fee logic
  • Gap analysis against a new platform
  • Controls documentation
  • UAT scenarios from real transaction patterns

Tools

SQL, SSMS, Excel, Power BI, Tableau, Visio. AI assistants.

AI in this work

  • Group reconciliation exceptions by likely cause, using a program-approved tool only. The analyst verifies each group against the ledger. AI never clears an exception.
  • Turn fee, penalty, or allocation rules into test scenarios with expected values (a hosted assistant with the rules only, or Copilot). The expected values are calculated independently in Excel.
  • Draft payment and revenue workflow narratives from procedures and process maps (Copilot), for review by a finance expert.

Deliverables

  • Payment and revenue workflow maps
  • Reconciliation review
  • Business rules table
  • Financial system requirements
  • Reporting requirements
  • Gap analysis
05

Agile delivery

A backlog that's ready before the sprint starts, and dependencies someone is tracking.

Scrum and SAFe delivery experience.

Methods, tools, AI uses, and deliverables

Frameworks and methods

  • Scrum
  • SAFe
  • Kanban
  • PI planning
  • Definition of Ready and Definition of Done
  • Backlog refinement
  • Dependency and risk tracking
  • Release planning

Tools

Jira, Confluence. AI assistants, including Copilot inside Microsoft tools where licensed.

AI in this work

  • Flag likely duplicates, stories that fail INVEST, and missing acceptance criteria before refinement (Copilot, or Jira's built-in AI if the program has it on). The product owner decides.
  • Draft sprint review notes, release notes, and PI-planning risk and dependency lists from Jira and meeting notes (Copilot). The team reviews them before they're shared.
  • Summarize retrospective themes from anonymous input (Copilot) for the team to confirm.

Deliverables

  • Refined, ready backlog
  • DoR/DoD checklists
  • Dependency and risk log
  • PI planning inputs
  • Release notes
06

Tool and systems evaluation

A review of the tools, systems, and delivery procedures you already have, including development, deployment, and release. It ends with a list of changes expected to save time or cost, ranked by effort.

In practice (prior work, as an employee): In-house and local LLMs used to draft documentation, streamline procedures and processes, and support incident command, with a person reviewing every draft.

We evaluate and document. Configuration, pipeline engineering, and security engineering stay with your engineers.

Methods, tools, AI uses, and deliverables

Frameworks and methods

  • SIPOC
  • Lean value-stream mapping
  • Current/future-state maps (BPMN)
  • RACI for handoffs and approvals
  • 5 Whys and fishbone
  • Gap analysis

Tools

Jira, Confluence, Visio, Excel. GitHub, Jenkins, and Harness, reviewed for pipeline inventories and release steps. Splunk and New Relic, reviewed for monitoring and alert requirements. AI assistants.

AI in this work

  • Read the program's CI/CD pipeline configurations (for example Jenkins, Harness, or GitHub Actions, whichever it uses) to draft a pipeline inventory and migration stories (GitHub Copilot chat). A DevSecOps engineer confirms, and engineers make the changes.
  • Draft or update release procedures, runbooks, and environment-promotion steps from tickets and chat history (Copilot), for the release manager to approve.
  • Score an inventory of manual steps for what existing tools could take over (a hosted assistant or Copilot, using the method below). The program decides.

Deliverables

  • Tool and license inventory
  • AI Opportunity Ledger
  • Delivery and release process map
  • Findings, with changes ranked by effort and payoff
  • Updated procedure and checklist drafts
  • AI use plan within program rules

Scope, from the analyst's side

  • How work moves from request to production: intake, backlog, development handoffs, testing, environment promotion, release approval.
  • Written procedures and release policies compared with what teams actually do.
  • What the program licenses and how much of it is used, including AI features already paid for.
  • Where approved AI tools could take over drafting, summarizing, or checking work.

How the evaluation runs

  1. Inventory

    the systems, tools, and licenses you already have.

  2. Find the manual steps

    re-keying, copy-paste, manual reconciliations, status chasing, repeated documents.

  3. Score them

    by frequency, time, cost of an error, and stability. First ask whether the step should just be deleted.

  4. Match to what the program already licenses or has approved

    for example its built-in Jira automation, Power Automate, Power BI refresh, Copilot features, or existing pipeline stages. We don't recommend buying new tools by default.

  5. Pilot one

    the top item, with a named owner and a human review point.

  6. Measure

    hours saved, cycle time, and rework, against a baseline taken first.

How each step gets classified

For every manual step we find, we recommend the simplest treatment that works. The program decides.

Delete the step first. If it doesn't need to exist, nothing else matters.

Eliminate
The step doesn't need to happen. Remove it.
Human
A person does it. Decisions with real impact on people always stay here.
Rule
A fixed check the system applies the same way every time, like a required field or a date range.
Automation
The system moves or copies data between steps or systems, with no judgment involved.
Analytics
A report or dashboard answers the question, so nobody has to look it up by hand.
AI Assist
AI drafts, summarizes, or searches. A person reviews the result before it's used.
AI Agent
AI carries out a bounded, multi-step task and makes no decisions. A person approves before anything is submitted, sent, or changed. If a step is classified this way, the program's own approved tools and engineers build and run it. We write the requirements and controls.
Example: how some common steps are classified
StepTreatment
Validate required fields on a formRule
Copy the same record into a second systemAutomation
Draft routine correspondenceAI Assist, reviewed by a person before it goes out
Approve or deny a requestHuman, with AI support for research only, in an approved tool

The AI Opportunity Ledger

The ledger is one working spreadsheet that lists every step worth changing, how it should be treated, and where it stands. It lives on the program's own systems and gives the program a ranked list it owns and can keep updating after we leave. Items are ranked by multiplying their scores, so one weak factor pulls an item down.

  • Process
  • Business pain
  • Technology treatment
  • Data readiness
  • Risk
  • Effort
  • Expected value
  • Status

We find the manual work and specify the fix. Your engineers build it.

Interested in our services, or in partnering?

Send a short note about your program and what needs analysis. We'll set up a short call.