Working through the Phase B business process design artefacts this week --- the Business Architecture overview, capability map, organisation map, and value stream --- and the main challenge isn't capturing what NZRT does. It's being precise about what NZRT intends to do without dressing intention up as current reality.
Business process documentation usually assumes a running organisation: there are handoffs, there are people who hold specific responsibilities, there are repeated steps that have accumulated into something worth mapping. We don't have that yet. What we have is design intent --- here is the charitable purpose, here are the capabilities we need, here is how value would flow if the full team were operating.
From a requirements perspective that's actually a clean position to be in. The process models we're building now aren't reverse-engineered from habit or constrained by how someone has been doing it for three years. The value stream lays out how charitable service delivery should move from intake to delivery to community outcome. The capability map names what functions we need, not which people currently hold them.
What I'm watching for as these docs develop: places where the language hedges instead of decides. "May include" and "typically involves" belong in a framework document. A business process model needs to say what actually happens. If the intake process for an NCS charitable referral has five steps, name them. If we only know three of them, name those and flag the gap explicitly --- that is more useful than vague coverage.
The organisation map shows a single-human, nine-agent structure that most process design tools aren't built for. Worth naming that directly in the architecture docs rather than bending it into a standard org chart template.
