Benefits Agency: Process Maps or Value Stream Analysis
The State Benefits Agency processes 1.4 million unemployment claims a year through nine channels and 23 legacy systems. Average processing time is 21 days against a legislative target of 5 days; the error rate is 18%. The agency has funded a business architecture team for 12 months. Leadership has asked for detailed process maps of every step in every channel. The BA lead believes value stream analysis is the better starting point. Constraints include unionized staff, procurement rules that limit new tools, incomplete performance data, and a mandate to show results within two quarters. The agency also has a new director who wants to reduce call-center volume and improve claimant trust. The team has four architects and limited access to frontline staff. They must define scope, choose the right blueprint, and show how architecture will guide prioritization without boiling the ocean.
1. Should the team start with detailed process mapping or value stream analysis? Defend your choice.
Read the worked answer
Start with value stream analysis. Detailed process maps of every step in nine channels would consume the team before any cross-channel pattern emerged, and they would embed current organizational boundaries rather than reveal handoffs. A value stream map for unemployment claim intake through payment shows the end-to-end stages that matter to claimants: claim initiation, identity verification, eligibility determination, wage and separation verification, adjudication, payment, and appeals. At each stage the team can capture value items, elapsed time, error points, and channel variation. Process maps are still useful, but after the value stream identifies the stages with the greatest delay or error, and only for those stages. The trade-off is precision: value stream analysis is less granular, but it is the right level for a 12-month mandate and a director who needs prioritization. The team should validate stages with frontline staff and use existing data samples, not wait for perfect measurement.
2. How should the team scope the first 90 days to show results?
Read the worked answer
Scope the first 90 days to one value stream, one claimant segment, and three to five pain points. Choose the highest-volume segment, such as initial unemployment claims filed online, rather than all nine channels. Build the value stream map with stage owners and a small sample of claims; use call-center logs and error reasons to locate delay and rework. Map only the capabilities that enable the selected stages, then heat-map them for pain severity, volume affected, and ease of change. Select quick wins that do not require procurement, such as clarifying evidence requirements or reducing a redundant verification handoff. Publish a baseline and a target for one or two measures, for example elapsed days from claim initiation to first payment. The reasoning is that showing a credible result on a narrow slice builds permission for the broader architecture work; trying to map all channels in 90 days would produce a thin inventory and no operational change.
3. How should the team address the union and procurement constraints in the architecture approach?
Read the worked answer
Treat the union and procurement rules as design constraints, not as afterthoughts. Use a stakeholder map to identify union representatives, frontline supervisors, and procurement officers, and involve them when value stream stages imply changes to work allocation or job roles. Keep the architecture focused on capabilities and value stream outcomes rather than on redeploying staff; if a stage redesign affects bargaining-unit work, route it through the established labor-management process. For procurement, avoid an architecture that depends on a new platform in the first year. Favor capabilities that can be improved through existing systems, data cleanup, policy changes, and process ownership. If a tool is needed, define business architecture requirements that can enter the procurement process without prescribing a vendor. The reasoning is that an technically elegant target state that ignores these constraints will not be implementable; the architecture must be actionable within the agency's real governance.