Business Analysis Notes

Techniques BABOK Guide v3, 10.32

Organizational Modelling

5 min read · Updated

In short An organizational model is a picture of how a company or unit is structured: who belongs to it, which roles exist, who reports to whom, and how it works with other units and outside parties. You use it to find stakeholders and decision makers, and to design the roles and reporting lines a change will need.

Based on: IIBA, BABOK® Guide v3, technique 10.32 “Organizational Modelling”; Watermark Learning, BABOK v3 Study Tables, section 10.32; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 8.

On this page

What it is#

Organizational modelling describes the structure of an enterprise or one of its units: its boundaries (who is a member), the relationships between people inside it, their functional roles, and how the unit interacts with other units and external stakeholders. The BABOK Guide uses it to define roles, responsibilities, and reporting lines, and to align those structures with the organization’s goals.

The guide’s elements, explained in plain terms:

  • Types of organizational model. A functionally oriented organization groups people by shared skills or expertise, such as sales, finance, or engineering. A market-oriented organization groups them around customer groups, regions, or products. A matrix organization combines the two, so people report both to a functional manager and to a product, project, or market manager.
  • Roles — the positions or roles within the unit.
  • Interfaces — the unit’s working connections with other units and outside parties.
  • Organizational charts — the diagram itself: boxes for units, roles, or people, with lines for reporting relationships.
  • Influencers — people whose real influence differs from what their position on the chart suggests.

The study tables note a practical strength: an org chart is the most common model in most organizations, so nearly everyone can read it, and it gives you a ready starting list of stakeholders.

When to use it#

The Watermark study tables link the technique to these BABOK tasks: 3.2 Plan Stakeholder Engagement and 3.3 Plan Business Analysis Governance; 6.1 to 6.4, to describe roles, responsibilities, and reporting structures in the current state, the future state, and the change strategy; 7.1 Specify and Model Requirements and 7.4 Define Requirements Architecture; 8.4 Assess Enterprise Limitations and 8.5 Recommend Actions to Increase Solution Value.

In practice, reach for it:

  • at the start of an initiative, to find stakeholders and who makes decisions;
  • when a change creates, removes, or reshapes roles;
  • when designing approval chains or access rights;
  • when the structure itself may be limiting the value of a solution.

When to use something else. An org chart shows formal structure, not how work flows. The BCS book points out that the functional view of an organization is static and inward-looking and hides informal relationships; a process view shows how work actually crosses department boundaries to serve the customer. Pair the org model with Process Modelling. For detailed system access rights, use a Roles and Permissions Matrix.

How to do it#

  1. Set scope and purpose. The whole enterprise, a division, or one team? Current state, future state, or both?
  2. Collect what exists. Org charts, HR lists, job descriptions. Check the date on each; charts age quickly.
  3. Identify the organizational type: functional, market-oriented, matrix, or a hybrid. This explains where decisions are made and where handoffs will hurt.
  4. Draw units, roles, and reporting lines. Prefer roles over personal names, especially in future-state models. Note headcount per role if it helps.
  5. Add interfaces. Show the other units and outside parties the unit works with: suppliers, contractors, regulators.
  6. Find the influencers. Ask “who do people go to for advice?” and “whose agreement really matters?”. Mark informal influence separately from formal reporting. This view can be sensitive, so agree on who sees it.
  7. Validate the model with a manager inside the unit.
  8. For the future state, show new or changed roles and reporting lines, and describe who moves into which role and when. This feeds organizational change planning.

Example#

The Workshop is a fictional chain of 12 bike-repair workshops. Its current structure is market-oriented by location: each workshop is a small unit with its own manager.

  • Role in the company
  • Outside party
  • Informal influencer
Figure 1. Current state. Each of the twelve workshops orders parts on its own; the senior mechanic’s influence is informal and not on the formal chart. Notation: organization chart; solid lines = reporting or contract, dotted lines = interfaces and informal influence
View as text
Current state
Owner
├── Outside development team (contract)
└── Workshop manager  ×12
    ├── Front-desk staff
    └── Mechanics
Interfaces: each workshop manager orders parts from the supplier separately.
Influencer: a senior mechanic at the oldest workshop; other mechanics call
him for advice, and he informally sets how repairs are recorded.

The model makes two things visible. First, there are twelve separate ordering relationships with the same parts supplier, which helps explain inconsistent stock. Second, the senior mechanic is not on the chart as a decision maker, yet the new status-update feature will succeed only if mechanics accept it. The analyst invites him to the requirements workshops.

The future-state model adds one role:

  • Role in the company
  • New role
  • Outside party
Figure 2. Future state. A new parts coordinator orders from the supplier; workshop managers request parts through the system. Notation: organization chart; solid lines = reporting or contract, dotted lines = interfaces
View as text
Future state
Owner
├── Outside development team (contract)
├── Parts coordinator (new) ── interface: parts supplier
└── Workshop manager  ×12
    ├── Front-desk staff
    └── Mechanics
Workshop managers request parts through the system; the coordinator orders.

The change shifts a responsibility away from workshop managers, so they become stakeholders in the change, not just users of the new system.

Common mistakes#

  • Copying an outdated chart → confirm it with HR or managers and date it.
  • Names instead of roles → model roles; people change jobs.
  • Assuming the chart shows how work happens → add a process view.
  • Ignoring informal influencers → ask about them and mark them separately.
  • Sharing sensitive views widely → influence maps and reorganization plans need an agreed audience.
  • Missing external interfaces → show suppliers, contractors, and regulators.
  • Future state with no transition → describe who changes role, when, and with what support.

Template#

Template
**Unit / scope:** <...>      **State:** current / future      **Date:** <...>
**Organizational type:** functional / market-oriented / matrix / hybrid

| Role | Reports to | Headcount | Key responsibilities | Interfaces (units, external parties) | Notes |
|------|------------|-----------|----------------------|--------------------------------------|-------|
|      |            |           |                      |                                      |       |

**Influencers (restricted view):**
| Person or role | Source of influence | Relevance to the change |
|----------------|---------------------|-------------------------|

Checklist#

  • Scope, state (current or future), and date stated
  • Organizational type identified
  • Roles, reporting lines, and headcount shown
  • Interfaces with other units and outside parties shown
  • Influencers identified and handled with discretion
  • Model validated by someone inside the unit
  • Future-state changes linked to a transition plan

Sources and further reading#

  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.32 “Organizational Modelling”.
  • Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide). Section 10.32.
  • D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Ch. 8 (functional versus process view of the organization).