Blog · Essay · redesigning a workflow

Redesigning a Workflow Is More Than Automating a Task – What Went Wrong and How to Fix It

When the Singapore Sets Out AI Governance Priorities for Financial Sector headline hit the wires on September 11, 2026, I was in a client meeting discussing a pilot that had just stalled. The article (https://news.google.com/rss/articles/CBMikwFBVV95cUxPQkNnM2tFUnhldkF2dG15QlZkM2tFdk9ZeUp3NDBOQ0YyZHBwTS1aRGduQjVHcEJLeVJCMDlkaXIzLUl6ZUoyUTFGczRIUWJjSl93bVd1RmFkUWNMZWdUS3Y4M0NsTXdFTzJEaWF2dTk1ZkJrNWFBaTNtY0JGTFNqQVdEbVd5LUpsVXo5dlRKWkxRWUE?oc=5) framed the conversation around governance, but the real pain point was operational: the client had automated a single data‑entry step and expected the whole underwriting process to become AI‑driven overnight. It didn’t. The pilot crashed, the team grew skeptical, and the budget was suddenly under scrutiny.

In this essay I walk through exactly what broke, the diagnostic lenses I apply on a Monday, and the concrete steps that turn a broken automation into a genuine workflow redesign where AI can run end‑to‑end.


1. Automation vs. Redesign – The conceptual gap

Most CEOs hear the word *automation* and picture a robot button that speeds up a repetitive task. That is only the first rung on the ladder. A true workflow redesign asks three deeper questions:

  1. Where does the decision point reside? If a human still makes the final call, the AI is merely a speed‑up, not a transformation.
  2. What data does the AI need to make that decision? Often the required data lives in silos, in legacy systems, or in unstructured formats that were never meant for machine consumption.
  3. How does the output flow back into the broader process? A model that spits out a risk score is useless if downstream systems cannot ingest it without manual re‑entry.

When we skip these questions and just slap a model on a single step, we create a *pipeline fracture*: the model works in isolation but the surrounding process collapses.


2. What actually broke – A client case study

The client: a mid‑market insurer in Southeast Asia, 1,200 employees, legacy policy‑admin system built on a mainframe.

The goal: reduce the time to issue a new policy from 5 days to under 24 hours using a generative AI model to extract risk factors from PDF applications.

The implementation:

  • Scan PDFs → OCR → extract fields → feed into a pre‑trained risk‑assessment model → output a score.
  • The score was displayed to underwriters, who still performed a manual review and entered the decision back into the mainframe.

What failed:

  1. Data latency – OCR took an average of 3 minutes per page, but the mainframe batch window only opened every 6 hours. The model’s output sat idle, breaking the promised 24‑hour turnaround.
  2. Human‑in‑the‑loop friction – Underwriters were not trained on interpreting AI scores. They treated the score as a *suggestion* and still performed the full manual review, adding an extra 2 hours per case.
  3. Integration gaps – The risk score was stored in a separate NoSQL store. The policy‑admin system had no API to pull that field, so staff manually copied the number from a dashboard.
  4. Governance blind spot – The AI model was trained on historical data that contained a bias against certain zip‑codes. The compliance team flagged the model during the first audit, halting the rollout.

The result? The pilot delivered a 30 % speed‑up on the *extraction* step but the overall end‑to‑end time stayed at 5 days. The CFO froze further AI spend.


3. The Monday‑morning diagnostic checklist

When a CEO asks me, *“What should I look at first?”* I hand them a three‑column checklist that can be run in a single morning meeting. The columns are Process, Data, Governance.

ProcessDataGovernance
1️⃣ Identify every hand‑off. Map who does what, when, and which system they use.1️⃣ Catalog the source of every field the AI model consumes. Note format, latency, and freshness.1️⃣ Verify model training data against your risk‑policy matrix. Flag protected‑class attributes.
2️⃣ Ask: *If the AI step disappears, does the process still work?* If yes, you are only automating.2️⃣ Run a data‑quality audit: missing values, duplicate records, OCR error rates.2️⃣ Confirm that the model’s output is logged, versioned, and can be rolled back.
3️⃣ Define the *desired* end‑state: a single, continuous flow where the AI output is the *only* input to the next system.3️⃣ Test data pipelines end‑to‑end with a synthetic batch to measure latency.3️⃣ Align the model’s explainability requirements with your regulator’s expectations.
4️⃣ Build a *fallback* manual path that can be triggered automatically if the AI fails.4️⃣ Establish a data‑governance owner for each source system.4️⃣ Draft an incident‑response playbook for model drift or bias alerts.

Running this checklist on Monday forces you to surface the exact points where the pilot will break once you try to scale.


4. Turning a broken pilot into an end‑to‑end redesign

4.1 Re‑architect the hand‑offs

Instead of treating the AI model as an *add‑on*, embed it as the decision engine. In the insurer example, the revised flow became:

  1. Ingestion – PDFs are uploaded to a cloud bucket that triggers an event‑driven OCR service (sub‑second latency).
  2. Feature store – Extracted fields are written to a centralized feature store that the risk model reads in real time.
  3. Decision – The model returns a *policy‑approval* flag, not just a score. If the flag is *auto‑approve*, the policy is created automatically; otherwise it routes to an underwriter with a *risk‑explanation* overlay.
  4. Commit – The policy‑admin system consumes the approval flag via a REST API, eliminating manual entry.

4.2 Data pipeline hygiene

  • Standardize formats: Convert all incoming PDFs to a uniform image size before OCR. Use a single OCR engine across the organization to keep error rates predictable.
  • Latency budgeting: Allocate a maximum of 30 seconds for OCR + feature extraction. Anything longer triggers the fallback path.
  • Versioned feature sets: Store each version of the feature schema alongside the model version to guarantee reproducibility.

4.3 Governance baked into the flow

  • Bias guardrails: Deploy a lightweight fairness monitor that flags any policy‑approval decision that correlates with protected attributes beyond a pre‑defined threshold.
  • Audit trail: Every model inference writes a log entry with input snapshot, model version, and output. This satisfies ISO 27001 audit requirements (see my earlier post on AI security and compliance).
  • Human‑in‑the‑loop policy: Underwriters receive a *confidence score* and a *counter‑factual* explanation. If confidence is below 70 %, the case is automatically routed for full review.

4.4 Change‑management sprint

  • Pilot a single line‑of‑business for 30 days, not the entire portfolio.
  • Train the end‑users on interpreting AI explanations. Use short, hands‑on workshops rather than long webinars.
  • Measure the *end‑to‑end* metric: time from application receipt to policy issuance. Do not get distracted by sub‑step speed‑ups.

5. The CEO’s Monday action plan

  1. Map the current workflow on a whiteboard. Highlight every system, human hand‑off, and data store.
  2. Pinpoint the single step you are tempted to automate and ask the three deeper questions above.
  3. Run the checklist with your CTO, CISO, and the business owner of the process.
  4. Define a success metric that reflects the whole journey (e.g., “policy issuance under 24 hours”).
  5. Schedule a 2‑hour sprint with a cross‑functional team to prototype the end‑to‑end flow, not just the isolated model.

If you follow these steps, the next AI experiment will be a *transformation* rather than a *speed‑up*.


FAQ

What is the difference between automating a task and redesigning a workflow?

Automation replaces a manual step with a tool but leaves the surrounding process unchanged. Redesigning a workflow re‑thinks the entire sequence so that AI becomes the *decision engine* and the surrounding steps are re‑aligned to consume its output directly.

How do I know if my data is ready for an end‑to‑end AI flow?

Run a data‑quality audit that measures completeness, latency, and format consistency for every field the model will use. If any source fails the latency budget or has more than 5 % missing values, address those gaps before scaling.

My organization is heavily regulated. Will redesigning a workflow increase compliance risk?

On the contrary, a well‑designed end‑to‑end flow makes compliance easier because you can embed audit logs, version control, and bias monitors at the point of decision. This aligns with ISO 27001 and other frameworks.

How much budget should I allocate for a workflow redesign versus a simple automation?

Start with a modest pilot budget (5‑10 % of the total AI spend) that covers data pipeline work, model integration, and user training. The bulk of the investment should go to the *process engineering* effort, not just the model license.

When should I involve the CISO in an AI project?

From day 1. Security and governance are not after‑thoughts; they are part of the data pipeline and model‑serving architecture. Early involvement prevents costly re‑work later.


If you’re ready to take the next step and run a focused, CEO‑level diagnostic on a high‑impact process, let’s talk. I’m happy to walk through the checklist in a short discovery call: https://calendly.com/rohan-girdhani/discovery-call.


*Further reading:* my previous posts on CEO‑level AI accountability, AI budget and data foundation, and AI‑ready data for mid‑market CEOs provide deeper context on the surrounding themes.

In the market

Headlines this post is responding to — not invented stats.