Scaling a Working Automation Across Twelve Teams
A central automation team built a document-intake workflow for the Legal department: it watches a shared mailbox, extracts fields from PDFs, files them into the matter management system, and notifies the assigned paralegal. It took six weeks to build and has run reliably for Legal for five months. Leadership now wants it deployed to eleven more departments - HR, Finance, Procurement, and eight others - within a quarter. The Legal version has 14 hardcoded values: mailbox address, folder paths, field names, a department-specific approval chain, and three exception rules that encode Legal's practices. Each department has different field names on its forms, different approval chains, and a different risk appetite. Two departments have regulatory constraints Legal does not (HR handles personal data; Finance requires audit trails). The central team has four engineers.
1. Evaluate the 'deploy to eleven departments in a quarter' request. What should the central team build versus what should each department own, and what is a realistic sequencing?
Read the worked answer
The request as stated is not achievable and should be renegotiated, not heroically attempted. Four engineers, eleven departments, one quarter, with two regulated domains and per-department customization, is a recipe for eleven brittle copies.
What the central team should own (the platform):
- The intake engine: mailbox watching, PDF extraction, filing, notification - the parts that are genuinely the same everywhere.
- A configuration layer that externalizes the 14 hardcoded values: mailbox, paths, field mapping, approval chain, exception rules. Departments supply config; the engine stays one codebase.
- A shared audit/event log, since Finance needs audit trails and everyone benefits.
- A template and onboarding guide so a department can self-serve the common case.
What each department should own:
- Its field mappings and approval chain (configuration, not code).
- Its exception rules, reviewed with the central team for safety.
- A named business owner who signs off on behavior and handles escalations.
Sequencing:
- First, refactor Legal's version into the configurable engine (2-3 weeks). Do not build eleven copies.
- Onboard one low-risk, high-similarity department (e.g., Procurement) as the pilot for the config model. Fix what breaks.
- Then HR and Finance, because they need the audit trail and data-handling work - do this deliberately, with compliance review, not as a fast follower.
- Roll the remaining departments in waves of 2-3, each with a business owner and a two-week observation window.
Six to eight departments in the quarter is a realistic, defensible target. Promising eleven invites eleven silent failures.
2. For the HR and Finance deployments specifically, what additional controls are required, and how would you decide whether those departments are ready?
Read the worked answer
HR (personal data):
- Data minimization: extract only the fields the workflow actually needs; do not copy full documents into shared locations.
- Access control: the mailbox, folders, and matter system must enforce least privilege; the automation's service account gets only what it needs.
- Retention and deletion: define how long extracted data lives and automate deletion. Personal data in a status log is still personal data.
- Redaction or restricted handling for sensitive fields (ID numbers, health information) before anything is logged or notified.
- A documented lawful basis and a privacy review before go-live, not after.
Finance (audit trails):
- Immutable event log: every intake, extraction, filing, and notification recorded with timestamp, actor (service account), and outcome. Append-only.
- Traceability from source document to filed record - a reviewer must be able to reconstruct what happened to any document.
- Separation of duties: the person who configures exception rules should not be the only person who can approve them.
- Reconciliation: periodic checks that every received document is accounted for (filed, queued, or explicitly failed).
Readiness gate - apply to both, and do not waive it:
- A named business owner and a named technical contact.
- Configuration reviewed and signed off by the department.
- A dry run on real (or realistically anonymized) documents with a measured error rate and a human reviewing every output for the first two weeks.
- A documented failure path: who is notified, how fast, and what they do.
- Compliance/privacy sign-off for HR; audit-log verification for Finance.
If a department cannot meet the gate, it waits. The cost of a bad HR or Finance deployment is far higher than the cost of a delayed one.