Bringing TOM and TAM together – a must!

Introduction

An important deliverable in the early stages of the IT-enabled business transformation project is not just the definition of the Target Operating Model (hereafter: TOM), it also concerns the Target Application model (hereafter: TAM). This has become even more important with the introduction of SaaS ERP solutions as the rich set of standard functionalities these solutions offer, they have become more and more in the driver seat when realizing such a transformation project. However, experience has shown that organizations are struggling with understanding the content of both the TOM and the TAM and when which element needs to be covered during the project. In order to gain a good understanding, it is important to take one step back and learn from experiences in the past.

Recent KPMG study showed that organizations are still facing challenges when making ERP programs successful. This results in programs which are often delivered behind schedule, lacking sufficient focus on the change management component and, most importantly, not delivering the expected results. This is of course very unfortunate, however, as ERP will stay (either “best of breed” or “best of suite”), organizations need to learn from this and understand the benefits of these programs.

Table 1. Key outcomes failed ERP projects (source: KPMG survey 2018). [Click on the image for a larger image]

With the introduction of SaaS ERP solutions, a new set of game rules was introduced for the implementation of ERP solution. Where in the past, ERP solutions were more or less following the requested business rules (often resulting in significant number of customizations), SaaS ERP solutions have become more prominent, meaning that the standard functionality as offered within these solutions will determine the new way of working to a great extent. Although this may sound scary, the SaaS ERP solutions have definitely grown in maturity; we are of the opinion that organizations should be able to better comply with these solutions (and become less dependent on customizations).

Target Operating Model (TOM) explained in more detail

When implementing ERP solutions, organizations build up their TOM and TAM. This seems obvious when running a new ERP project, however, to make sure that all aspects are being covered, it is important to understand the exact components and the relationship between the TOM and the TAM. Let’s first take a closer look at the TOM and see what Wikipedia say about this model:

Definition TOM:

“Target operating model is a description of the desired state of the operating model of an organization. When working on the operating model, it is normal to define the “as is” model and the “to be” model. The target operating model is the “to be” model. It is possible to produce a target operating model for a business or a function within a business or a government department or a charity.”

In short, the TOM will form the foundation based on which further detailed designs can be elaborated for processes, workflow, organizational structure, roles & responsibilities including the supporting control and governance layer. In Figure 1 the model has been reflected, which KPMG uses as reference for explaining this concept.

Figure 1. Target Operating Model (source: KPMG). [Click on the image for a larger image]

During the implementation of (SaaS) ERP solutions, the TOM is also a useful umbrella for designing and implementing. However, experience has shown that some layers require more attention than others. Therefore, we have further finetuned this to make sure that these layers get the attention they need (see Figure 2).

Figure 2. Layers Target Operating Model (source: KPMG’s Powered Enterprise). [Click on the image for a larger image]

It is important to mention that not all content of each of these layers needs to be developed at the start of the project but will grow during the various stages of the project. When looking at the project stages of IT-enabled business transformation in which SaaS ERP is a critical component, we also recommend applying a different approach. During “old fashioned” ERP projects, an important project phase was the design phase (in most cases designed according the raised business requirements). Within SaaS ERP projects this phase should be replaced by what we call a Validation phase; the underlying assumption for this is that organizations will validate their requirements against the available (standard) functionalities of the ERP solution and in case of deviations will modify components within their TOM to adapt to the ERP solution. This is an important mind-shift and although SaaS ERP has been around for some time, we still see organizations struggling with this.

Example: When starting such a project, there is definitely a need to develop a high level “To Be” process diagram allowing the major stakeholders to gain a good understanding of the direction of the organization. However, in most cases it is not possible to define a process model to the lowest level (read: work instruction for the end users). Our recommendation is that such process diagrams are developed up to level 3 (see Figure 3). When the actual system implementation has started, this level can be worked out up to level 4 and 5. Our experience is that the leading SAAP ERP providers (like SAP, Microsoft and Oracle) already provide a wide range of work instructions embedded in their solutions.

Figure 3. Process levels TOM (source: KPMG). [Click on the image for a larger image]

By having a technology dimension in the TOM, a first link to the TAM has already been established. When linking this back to SaaS ERP projects, this needs to be further intensified. As mentioned earlier in this article, the reason is the guiding principle that organizations are willing to comply to a large extent to the standard functionalities. SaaS ERP solutions that are providing this are opening the door for IT-enabled business transformation. Where in the past more a top-down approach was applied (first defining the TOM and secondly the TAM), SaaS ERP solutions require a more balanced approach where the definition of both models goes hand in hand. This is also reflected in Figure 4, where experience has shown that to support a good design of both the TOM and TAM, it is recommendable to also bring in good practice from outside.

Figure 4. Bringing TOM and TAM together (source: KPMG). [Click on the image for a larger image]

Target Application Model explained in more detail

As already stated in the previous paragraph, the TOM already contains a technology layer. In our view, however, this requires more detailing to make sure all aspects from a technology point of view are covered. Figure 5 shows a model we use as reference to make sure that all IT-related aspects will get the attention they need. The core of the TAM is the application, integration and database/infrastructure layer. Important note: in case an organization decides for a SaaS ERP solution, this last layer, of course, becomes less relevant as this is “outsourced” to the SaaS ERP provider. Nevertheless it is recommended to pay attention to this layer during the project, to make sure the organization has a good view of the impact on the transition to the SaaS delivery model.

In addition, we also recommend discussing the IT service delivery organization, the related people component and the IT governance component. The reason for making this explicit, is that experience has shown that organizations often tend to focus on the business component of the service delivery and to a lesser extent the IT component. For example, when implementing SaaS ERP, the organization will need to comply in much stricter way to the product release sequence of the application provider. This is an important change in comparison with the maintenance of on-premise applications, where organizations are much more independent when implementing new releases or upgrades (often resulting in later or delayed installation of these new releases). The consequence of this stricter release management process is that an organization needs to make sure that its test management delivery process is capable of handling this higher release frequency.

Figure 5. Layers Target Application Model (source: KPMG’s Powered Enterprise). [Click on the image for a larger image]

Like the deliverables of the TOM, the deliverables of the TAM will also evolve during the project. Where at the start of a project, explicit attention needs to be paid to more strategic elements, the TAM will be detailed and finetuned during the remainder of the project. Figure 6 lists various deliverables of the TAM that need to be developed during the course of the ERP program.

Figure 6. Examples of TAM deliverables (source: KPMG Powered Enterprise). [Click on the image for a larger image]

The importance of guiding principles

Although the objective of this article is not to explain all elements of the TOM and the TAM in detail, we would like to highlight one important element and that is the concept of “guiding principles”. Guiding principles are statements that describe within which framework/boundaries, the new design of the TOM and TAM should adhere to. They serve as benchmarks against which “to-be” design options can be assessed. There are a number of inputs that inform guiding principles and may include strategy, project goals and critical success factors as well as known constraints. We strongly recommend that at the start of the project (during the Vision phase) explicit attention is paid to these guiding principles for all layers of the TOM and the TAM. To make sure that the guiding principles are accepted and governed, it is important that also all key stakeholders are included in this discussion (in Table 2 and Table 3 some examples of guiding principles for both the TOM and the TAM are listed).

Table 2. Example guiding principles TOM (source: KPMG). [Click on the image for a larger image]

Table 3. Example guiding principles TAM (source: KPMG). [Click on the image for a larger image]

Concluding remarks

In summary, the TOM is a blueprint of an organization’s view on how the organization should operate in order to realize their future strategic goals, the role of the human capital in support these processes, the way it is governed and the position of supporting technology. This supporting technology needs to further be detailed within the TAM. Considering the fact that a guiding principle within SaaS ERP project is the reliance on standard functionality as much as possible, our experience is that the definition of TOM and TAM needs to go hand in hand. The advantage of defining a TOM and a TAM, is that organizations will not only obtain a thorough understanding of their future organization from a business perspective but can also take into account the advantages the supporting technology landscape can bring. In case organizations are not able or willing to pay the right attention to these models, an imbalance will arise; they will not be able to generate the benefits that a true IT-enabled business transformation might bring.

Although not explicitly stated within the TOM and TAM, a critical success factor within IT-enabled business transformation is change management. In comparison with the “old school” ERP projects, change management has become even more important when implementing SaaS ERP implementations. The reason for this is again the underlying assumption that organizations are willing to comply to a large extend to the standard functionalities offered by these solutions. In case this will result in a deviation from the As-Is situation, the change needs to be realized in the organization and not in the application. In order to make sure that this change will be accepted, effective change management is key. This is also the reason why we strongly recommend making change management an integral part of your implementation approach.