Claims Intake Model Sprawl
An insurer's claims intake process is documented as a 14-step Visio flowchart last updated two years ago. Three regional teams handle intake differently: North adds two verification steps for high-value claims, South combines document collection and validation, and West outsources the police-report chase. Six exception types recur-missing police report, lapsed policy, duplicate claim, fraud flag, bodily injury, and third-party liability-but the current diagram shows only one generic error path. About 22% of claims are reworked, and average intake cycle time is 9 business days against a 5-day target. A newly hired analyst proposes replacing the Visio with one standardized BPMN to-be model covering every region and exception. The operations director likes the idea but worries about losing local flexibility and spending weeks on modeling. You are asked to recommend a modeling approach before any redocumentation begins.
1. Evaluate the analyst's proposal to build one standardized BPMN to-be model covering every region and exception. What scope, notation, and level of detail do you recommend before redocumentation begins?
Read the worked answer
Recommendation: do not start with one exhaustive to-be model. First build a compact as-is model per region at level 1–2 to expose real differences, then a standardized to-be core with explicit variation points. Use BPMN because it can show pools/lanes, events, gateways, and subprocesses; a Visio flowchart cannot reliably represent parallel work, timers, or exception triggers. Scope the core to the 14 steps minus region-specific add-ons, and put regional differences in a separate variation matrix or business-rule table rather than three full model copies. Level of detail: model only activities that change handoffs, decisions, or controls; do not model screen-by-screen tasks. Target roughly 8–12 core activities plus 3–4 subprocesses. Rationale: 22% rework and a 9-day cycle suggest the problem is exception handling and handoffs, not missing task documentation. A single exhaustive model would take weeks, be hard to validate, and still hide local practice. Set a modeling standard and a review gate before scaling.
2. How should the six exception types be represented so the model remains usable and does not explode into dozens of paths?
Read the worked answer
Use an exception-handling subprocess rather than drawing every combination on the main path. Start by ranking the six exceptions by frequency and risk using claims data; likely missing police report, duplicate claim, and lapsed policy are higher volume, while fraud and bodily injury carry higher controls. On the main BPMN model, attach boundary error events or an event subprocess to the relevant task, then route to a single resolve-exception subprocess with a decision table by exception type. Model the top two or three in detail; keep the rest as named exception categories with an owner and service-level target until data justify more detail. This preserves traceability without creating 6×14 paths. Add a business rule task or decision table for validation so rule changes do not require redrawing the model. Also record exception frequency and rework loops in model metadata so the 22% rework is visible, not hidden. Review with operations to confirm the categories match practice.
3. What governance should accompany the model repository so the three regional variants do not drift again?
Read the worked answer
Establish a single repository with a named process owner, version control, and a change-review cadence. Require every model change to state whether it is core, a regional extension, or a temporary workaround; regional extensions must be approved by the process owner and recorded in the variation matrix, not forked into a separate diagram. Link each model to the relevant SOP, system, control, and KPI so drift is detectable. Set a monthly data check: compare model-implied handoffs and exception rates with actual cycle time and rework. Use a lightweight architecture review for new steps; if a region wants two extra verification steps, it must show risk reduction or cost benefit. Publish only approved models and retire old Visio files. This prevents local reinvention while allowing justified variation.