Very, very few business units operate in complete isolation within a company. (If they do, I suspect they are close to being closed down or sold.) Thus, to truly develop an impact assessment of what will happen when a given business unit (BU) halts operations, it is really important to understand the web of dependencies within which the business unit operates.
The way I explain this concept is to talk about a flow of data or products. In essence, there are those “upstream” and “downstream” of the BU. Those “upstream” are those providing the BU with needed input (data or product) and are the BU’s suppliers who the BU will yell at if the input stops arriving. Those “downstream” are those consuming the output of the BU and are stakeholders who will be yelling at the BU if it fails to deliver that output.
Using a payroll department as a simple example: one of the suppliers will be those providing the number of hours worked by employees and one of the stakeholders would be the employees. Without the hours worked the payroll department cannot calculate the appropriate pay for the employees. If the employees are not paid, you can be very sure it won’t take long before they will be yelling at the payroll department about it. This is turn, is likely to add motivation (if nothing else) to the payroll department’s yelling at those failing to provide the critical numbers.
During your BIA process you will have determined the BU’s stakeholders and suppliers. These “other entities” can be inside the company (e.g., the payroll area of the finance department) or they can be external (e.g., the company that hosts your corporate web site). Taken together, this is a very wide range of options and so I prefer to use the term “entity” when talking about the business units. Further, these entities can vary in size from a team within another operational area to an entire independent company to your entire client base. They can also vary in importance from “nice-to-have” to “must-keep-happy-at-all-costs”.
The basic aims of your data collection are to:
1. identify the entities,
2. determine whether they are stakeholders or suppliers,
3. determine their importance,
4. determine how quickly the “flow” needs to resume,
5. and, of course, what it is that is needed or supplied.
Reporting this information for a single BU can be a challenge. Reporting it for multiple BUs (e.g., a division) or for the entire company is even more of a challenge. An approach I’ve found to be useful is to map the information out with nodes representing the various entities and connecting lines depicting the relationships.
Depending on what you wish to emphasise, you can then play with various options such as using different colours for nodes to represent internal/external entities, line thickness to represent the criticality of the relationship. Deciding how to do this is something of an art and you may find it necessary to use different options for different audiences. Some people may prefer to see criticality, others want to see resumption windows, etc.
Example of an entity relationship map
In the attached stakeholder graphic (which uses dummy data), I’ve used colour to indicate the type of entity, filled circles to indicate entities and yellow-filled boxes to indicate departments. As you can see, this map shows us that “DivA_Dept1” (upper left corner) has identified a feedback loop and provides output to only the “Clients” and “CCA” stakeholders. On the other hand, “DivB_Dept8” (bottom middle) has a great many stakeholders.
There are, of course, many alternative options. Let your inner information artist free!