Setting up a structure for your architecture can be challenging when you want to include the demands of all stakeholders and cover all use cases. For some architectural views it is easy – applications typically come in “flat” and might just have one level below in your meta model (for components and other viewpoints), or risks and controls are typically already categorized before they are imported into an architecture tool.

Finding the right structure for your business processes can be tricky, though – various demands and opinions might come together that conflict each other. On the one hand, you have the business units who want to improve a process ‘soup to nuts’, while others have a specific focus on regulatory compliance, and others are even looking at processes from a functional perspective. Or, in some projects, all three aspects come to play, which obviously can lead to confusion or short-term decisions that will haunt you long after the project has ended.

This two-part article series will cover all three aspects and give you a recommendation how to handle this in your architecture and database structure.

Which views should I look at?

Let’s take a step back and have a look at where processes are in the architecture picture. Processes are part of the Business Architecture view in a larger enterprise and are connected to other views, such as applications, data, and technology (see for example TOGAF’s ADM that shows these views in an overview). Other parts of the Business Architecture are organization and risk & controls – typically represented by people that business folks in the lines of business work with.

Business processes are the most tangible of an architecture that a regular business person will encounter – in the end everyone in the organization performs steps that were (hopefully) designed to create an output that can be sold to a customer (a product or service). However, when it comes to describing processes there is not a consensus on how this should be done. Some people want to have a process breakdown, while others look at lower-level steps and how to improve them (typically these are the Six Sigma and Lean folks), while others look at a product-oriented sequence of steps, and the last group is interested in larger End-to-End processes and how they can be measured and improved.

This article will bring clarity into this dilemma and will help you setting up a structure in your architecture tool that allows you to support all of these use cases, while still providing a consistency that is needed to do a structured analysis or measure the performance of the processes in scope. At first, we will have a look at the functional process view in this article.

Functional business process view

The functional process view contains the logical decomposition of business processes. It is aimed to cover a single function of an enterprise, such as “Finance”. Typically you see these broken down in 4 or 5 levels (see for example APQC’s Process Classification Framework), and you can identify the main stakeholder or owner of this area – the CFO for the Finance area for example.

When you think about the functional view, think about a big map that shows all information, but allows you to drill in, so that you can see the details better:

Functional process decomposition
  • On the first level you see the country in its entirety (say, the US). It is one Value-Added Chain model that includes objects like “Finance”, “Marketing”, “Human Resources”, “Procurement”, “Logistics”, etc. (Enterprise Process Map).
  • When you drill down into one process, then you will see -as shown in the graphic above- that you are navigating in one “slice” of the pyramid. For the Finance process you would then see objects like “Accounts Payable”, “Accounts Receivable”, or “Asset Management”.
    In our example you would now see the map of one state that shows the major cities (Main Process).
  • On level three you will then see objects like “Create invoice” for the Accounts Receivable L2 process. Until now you typically see processes represented by value chain objects (chevrons) and these might or might not be connected to each other, depending on the data/meta model, and how your tool is configured.
    This level would now be a map of a county that shows the major streets in the county and cities in our analogy. This Business Process typically shows the value creation on a higher level, and includes the process interfaces to other main processes.
  • When it comes to the lowest level, typically the notation changes (to BPMN, EPC, or whatever other low-level notation your tool provides). This is the who-does-what-when-where level and it includes tasks like “submit invoice” which typically have relationships to apps, data, roles, etc.
    In our analogy this level would be the city street level map, where you can see the individual houses, intersections, etc. This model is the “Process“.
  • What I typically not recommend to model is the procedure level below level four (in our example) – the level where you show which fields to fill out in an screen and which buttons to press. That information changes relatively frequently with every update and if you want to provide this information to your model viewers, I recommend to take a screenshot with callouts and embed it as an attribute or link to a screen recording by using the “link” attribute of a task object.

When creating this hierarchy it is recommended that you restrain yourself to 4 or 5 levels. Any levels beyond that will just lead to an increase of the width of the pyramid, and therefore come with many, many more models to be managed.
What you also might see is resistance when agreeing on the number of levels because some org units might already have made up their mind and don’t want to adjust their structure. Avoid giving in to this notion, so that your abstraction levels are the same. What I have seen in the past was that these type of org units did not want to have the “fight” with their stakeholders and all these middle layers (one client org unit had 12 levels, while we agreed with others on a 4-tier hierarchy) contained only one or two process chevrons … this will severely impact your analysis, training, and reporting capability in the future.

How do I approach the creation of the functional process view?

Even though it would be beneficial to have a fully built out functional process view available from the start, I do not recommend to spend months or years to capture all processes. Most likely you will find a lot of things not being covered because people have left the organization, or existing material cannot be found anymore.
In addition to this, the time delay before you get to do something new is too long for the value that you get from that initial herculean effort.

My recommended approach to this is as follows:

  • Start with the definition of the first two levels (assuming is is a four level hierarchy for the purpose of this article), and bring the stakeholders and dedicated process owners together. The objective it to define the “buckets” of processes and who takes over responsibility for which area.
    While doing this establish the principle that “he who owns a process, must also cover other processes requirements”, which means for example that some lines of business are doing financial processes that are not done in the accounting department. If the accounting department is now tasked with building out the Finance main process, then it also has to model the financial processes that the line of business organization does – you should avoid to “outsource” this task to the line of business org unit (aka the other main process), because that won’t break the silos and you cannot ensure that whatever Finance activities they do will be consistent with the overall concept how Finance should be done in the enterprise.
    In addition to this, determining responsibilities and owners will also clarify who to involve when it comes to creating End-to-End (E2E) processes.
  • After you’ve agreed on the high-level structure (the “buckets”) determine the concepts and principles for your main process, and put these into writing. Also include your plan of going forward (which sub-area has priority for you?) and socialize this with the other main processes to get their buy-in, or trigger a change in your plans if they have requirements that justify a higher priority than your initial ideas.
  • Next have a look at two aspects: determine and collect which content for your area exists (and don’t forget to ask the other owners if they have something to share), so that you can import lower-level processes into your repository as an accelerator.
    If you are using an enterprise-wide system, check if it comes with reference processes. Even though you might have done customizations, you should capture those (with a big sticker “needs adaption” on the model). The reference processes can also help determining the shape of the content on the lowest value-chain level, in our case level 3.
    Investigate which projects are currently going on, and which ones are planned. Most likely these projects have already created future-state content as part of their solution design, and you should add this to your catalog of existing content at this time.
  • Use these projects to coordinate with them to ensure that they follow your concept, and once they have a final design -the “as-implemented” state, not what was signed off at the end of the solution design phase- grab this content and integrated it into your main process structure.
    Just keep in mind that the projects most likely created E2E processes and their share of your process might not be a complete process, so be prepared that you might have to add lower-level content to make a process “whole”. We will cover how to keep E2Es and functional processes in sync in the next part of this article series.
  • While you are doing these lower-level activities (on L4 in our example), adjust your level 3 models accordingly – the Business Process level. Depending on your conventions, which were defined in your technical governance phase of the tool implementation, you might show process interfaces to other main processes (recommended) and therefore you will have to have conversations with them to determine the shared events and which data will be handed over.
    You also will see that after a certain amount of content was created/imported on the lowest level, that you might have to rethink the structure on level 3 – you might have to split or combine processes, or maybe an exception process that one of the Subject Matter Experts has “sold” as its own process is in all reality just another loop in another process.

What are the benefits of a functional business process view?

The benefits of a functional decomposition are multiple:

  • Consistent leveling of processes, using a consistent meta model describing the abstraction level, and type of information that can be found in each level. Examples would be that you find applications on the lower-level processes (level 4 in the graphic above), while risks could be found on either level 3 or 4 … or both in some cases.
    This allows people in your organization to “speak the same language” when it comes to processes.
  • Having a functional process view also allows to ensure that the processes in one slice of the pyramid follow the same concepts and ideas. In the Finance area these might be that accounting only happens via cost centers and projects, but not via any other construct.
  • When modeling your own processes you will see the need to coordinate with other areas and determine what the process interface between two processes should look like: which end event in an upstream process triggers the downstream process, which data will be sent over, how applications support this, and so on.
    This exercise will also uncover the various scenarios that you might want to have a look at when it comes to the End-to-End view described in the next article.
  • Lastly, over time you will build up a network of processes that shows all activities of the enterprise in one view, and the responsibilities for each area (on every level) can be clearly defined. This network then can be used as the foundation for analysis of your Enterprise Baseline that you do when identifying improvement opportunities in the first phase of the process/solution lifecycle.
Functional business process view

In the next article of this series we will have a look at the End-to-End business process view, why you should create one, and also how you cover the demands of your risk folks when it comes to processes.