The learner can distinguish an as-is (current state) model from a to-be (future state) model and explain why both are modeled.
As-is vs to-be process models
As-is vs to-be process models
Before designing an improved process, a business analyst always models the process as it works today. This is called the as-is model (sometimes 'current state'). Documenting the as-is creates a shared, agreed understanding of reality among all stakeholders — business owners, developers, and operations staff. Without this shared baseline, different people will describe the same process differently, and the team will solve the wrong problem.
Once the as-is is agreed upon, the analyst identifies the pain points: bottlenecks, manual steps that cause errors, unnecessary approvals, or delays. The team then designs the to-be model (sometimes 'future state') — the process as it should work after improvements are implemented. The to-be model directly shapes the requirements for whatever system or change is being built.
The gap between as-is and to-be is where requirements come from. For example, if the as-is shows that an invoice approval takes three days because a manager must sign a paper form, the to-be might replace that step with an automated digital approval. The gap — 'paper form vs digital approval' — becomes a functional requirement.
A key insight: you cannot safely design the to-be without first understanding the as-is, because you risk automating a broken process or missing a step that only exists in someone's head. Modeling both states prevents costly surprises late in delivery.
Lesson notes
As-is vs to-be process models
Before designing an improved process, a business analyst always models the process as it works today. This is called the as-is model (sometimes 'current state'). Documenting the as-is creates a shared, agreed understanding of reality among all stakeholders — business owners, developers, and operations staff. Without this shared baseline, different people will describe the same process differently, and the team will solve the wrong problem.
Once the as-is is agreed upon, the analyst identifies the pain points: bottlenecks, manual steps that cause errors, unnecessary approvals, or delays. The team then designs the to-be model (sometimes 'future state') — the process as it should work after improvements are implemented. The to-be model directly shapes the requirements for whatever system or change is being built.
The gap between as-is and to-be is where requirements come from. For example, if the as-is shows that an invoice approval takes three days because a manager must sign a paper form, the to-be might replace that step with an automated digital approval. The gap — 'paper form vs digital approval' — becomes a functional requirement.
A key insight: you cannot safely design the to-be without first understanding the as-is, because you risk automating a broken process or missing a step that only exists in someone's head. Modeling both states prevents costly surprises late in delivery.