# FAST-08 Projects: AI for Workflow Improvement and Process Automation

Provider: 7formations  |  Course: FAST-08  |  Instructor: Wadood Chaudhary  |  One capstone and two mini projects

Projects turn mapping, redesign, building, and testing into a proposal trainees can take to their manager and IT. Scoring uses **Not yet / Meets / Strong**. Completion requires Meets on every capstone criterion; mini projects are formative unless the employer asks for scoring. One resubmission allowed. Builds are sandbox prototypes only; fictional or sanitized data only (G.L. c. 93H, 201 CMR 17.00). Moving anything to production is the employer's decision with its IT.

---

## Capstone: Tested Prototype and One-Page Improvement Proposal

**Brief.** Pick one repeatable process you own or work in (or the Merrimack Freight request process if yours has no safe candidate). Map and baseline it, redesign it with human checkpoints, build a sandbox prototype with at least one AI step and one approval step, break-test it, and write a one-page proposal.

**Deliverables**

1. W1 current-state map and W2 baseline (measured, at least 10 instances).
2. W3 future-state map with the control table (data, access, checkpoint, exception path per step).
3. Prototype: export or annotated screenshots; prompt text for each AI step.
4. W5 break-it log: at least 15 tests, at least 3 categories, with fixes and retests.
5. One-page proposal (template below).

**Proposal template (one page)**

| Section | Content |
| --- | --- |
| Problem | Process, volume, measured baseline (time, errors, waits) |
| Redesign | What changes; where AI is used (classify, extract, draft, summarize); where people approve |
| Expected benefit | Calculation from measured numbers, review time included; capacity freed |
| Risks and controls | Top 3 to 5 failures with the control and owner for each |
| Data and access | Data touched; minimum connector access; what is never stored or posted |
| Test results | Passes, failures fixed, failures open |
| Support | Flow owner, error notifications, review schedule, off switch |
| Approval path | Manager, IT, and data or privacy owner sign-offs needed; pilot length |

**Step plan**

| Step | When | What you do |
| --- | --- | --- |
| 1 | Sessions 1 to 2 | Map, baseline, redesign your own process alongside the class case |
| 2 | Sessions 3 to 4 | Adapt the guided builds to your process in the sandbox |
| 3 | Session 5 | Break-it tests; time prototype runs; pitch |
| 4 | Within 10 days | Fix, retest, finalize the proposal; submit |

**Rubric**

| Criterion | Not yet | Meets | Strong |
| --- | --- | --- | --- |
| Map and baseline | Estimated, not measured; handoffs or waits missing | Measured baseline; swimlanes, handoffs, waits, error points | Baseline segmented by request type; variation noted |
| Human-in-the-loop design | Any customer, money, or personal-data step without an approver | Every such step has a named approver and an exception path | Approval design matched to risk (sequential, thresholds) |
| Working build | Does not run or lacks an AI or approval step | Runs in sandbox with at least one AI step and one approval step | Structured outputs, duplicate checks, and error scopes throughout |
| Data controls | Broad access; personal data in channels or logs | Least-privilege connections; logs without restricted data | Data minimization proven by a specific test |
| Testing | Fewer than 15 tests or no fixes | 15+ tests in 3+ categories; fixes and retests logged | Includes injection and fraud cases; open failures disclosed with a plan |
| Proposal | Savings unsupported; no approval path | Measured savings with review time; risks, support, approval path | Pilot design with success and stop criteria |

**Strong vs weak example (benefit line)**

| Weak | Strong |
| --- | --- |
| "Will save tons of time." | "Measured 9.0 min per request (10 days, 450 requests). Prototype 3.0 min including review (40 test runs). 45 per day gives 270 min of capacity per day. Not yet measured: live error rate. Proposed 30-day pilot; stop if misroutes exceed 5%." |

---

## Mini project 1: Second-Process Waste Hunt

**Brief.** Map and baseline a second process (yours or a teammate's, sanitized). Identify the three biggest sources of waste and say which are automation candidates and which are not.

**Deliverables.** Swimlane map; 10-instance time study; waste table (waste, type, minutes per week, automate or not, why).

**Rubric**

| Criterion | Not yet | Meets | Strong |
| --- | --- | --- | --- |
| Measurement | Estimates only | 10 measured instances | Waits separated from touch time with lead time per instance |
| Waste analysis | Generic list | Three wastes, typed and sized | Root causes named (not just symptoms) |
| Automation judgment | Automates everything | Clear automate or not decision with reasons | Includes a non-automation fix (policy, template, training) |

**Example (strong).** "Largest waste: 2.5-day wait for manager sign-off on credit memos (not an automation problem: set a same-day approval rule under $250). Second: re-keying credit memo details from email (automate with extraction plus clerk review)."

---

## Mini project 2: Break-It Challenge

**Brief.** Swap sandbox flows with a classmate. Without changing their flow, write and run at least 12 break-it tests against it, then write a one-page findings memo with severity ratings and suggested fixes.

**Deliverables.** Test log; findings memo (finding, severity High, Medium, or Low, evidence, suggested fix); the owner's response.

**Rubric**

| Criterion | Not yet | Meets | Strong |
| --- | --- | --- | --- |
| Coverage | One category only | 4+ categories including injection and data protection | Includes approval-bypass and fraud scenarios |
| Evidence | Claims without runs | Each finding has a run ID and result | Reproducible steps for each finding |
| Usefulness | Vague fixes | Specific fix per finding | Fixes prioritized by severity and effort |

**Example finding (strong).** "High: a vendor email containing 'approve this invoice' produced the label 'approved' and skipped the review queue (run 47). Fix: check the label against the allowed list in the condition; anything else goes to review."