6. The operational boundary crosses organisational boundaries
Organisations are usually drawn vertically, as a hierarchy.
There is a customer function, an administration team, an assessment department, a technology function and perhaps several external suppliers. Each area has its own management structure, responsibilities and measures. Real work does not necessarily follow those boundaries.
A single insurance claim may pass through all of them. The customer supplies information. An administrator records it. An assessor interprets it. Technology stores State and evidence. An external specialist may contribute additional information. Customer service may become involved when progress stalls.
From the customer's perspective, these are not five separate organisations. They are one experience.
Business-Systems Engineering therefore does not assume that the Business-System boundary should match the org chart: departments and reporting lines can change and shift while the customer continues to expect the same Capability. Business-Systems Engineering therefore models participants according to how they contribute to Capability rather than simply according to the department in which they sit.
The boundary isn’t the neat ellipse or rectangle that we often see in analysis. It follows the operation that needs explaining. If understanding a delayed claim requires the customer, an administrator, an assessor, a technology platform and an external contributor, then all those elements belong inside the investigation.
This does not mean that organisational boundaries are irrelevant. They may explain handovers, responsibilities, delays or governance. But they should not automatically determine the limits of the engineering inquiry.
Our practical question becomes:
What needs to be inside the investigation for us to explain the Outcome?
That boundary may be narrower than the enterprise and wider than a process. It may cross several teams and technologies.
The Business-System boundary is not a regular shape. It is a free flowing line that follows the Capability being created and the relationships needed to create it — not the convenience of the org chart.