Skip to Content
Personal Insights
Author's profile photo Rainer Bruns

Business Integration in implementation projects

 

Introduction

Implementation projects – especially large implementation projects – are organized in different functional project teams. These teams tend to work on the team-internal tasks and expected results, but in order to set-up systems completely, the integration between these teams needs to be enabled, both business level and on technical level. The early orchestration of mandatory integration tasks avoids increasing effort and cost through mismatched designs and non-compatible end-to-end solutions, often revealed in a later project stage.

In order to foster thinking across teams rather than thinking in silos, business integration management is needed.

 

Business Integration in an Implementation Project

Implementation Projects are organized in different functional teams that are working in their specific functional area. These teams are focusing first on their specific functional area, but in order to implement complex IT systems as SAP S/4HANA successfully, the different functional areas need to be interconnected. This requires thinking rather in business processes than in functional silos.

If the different project teams don’t consider dependencies to other project teams, these topics might not be seen to be relevant for alignment with other teams, so that in worst case multiple teams are working independent on each other on the same topic with different results. This would lead to disconnected processes.

The later these disconnects are identified, the higher the effort is to correct the solution with impact on time, effort and quality of the solution.

Business Integration Management is an approach to foster the necessary process-oriented thinking and to manage on disconnected topics as soon as possible.

 

Business Integration Management concept

Business integration needs to be managed; it does not “happen” automatically. This requires dedicated project members managing the business integration. The highest efficiency is achieved if an experienced consultant and customer’s representative are cooperating to manage this area. They have different roles and experiences to bring in:

Business Integration Manager (consultant):

  • Good knowledge of the overall solution that is implemented
  • Experiences in earlier implementation project

Business Integration Manager (customer’s side):

  • Good overview about the customer’s entire business
  • Good network into the customer’s organization

In order to manage the business integration, three “components” need to be set-up:

  • Integration Matrix
  • Integration Single Point of Contact (SPOC)
  • Weekly integration alignment meetings

The components are summarized as “Business Integration Management Framework”, see Figure 1.

Figure 1: Components of the “Business Integration Management Framework”

  • Integration Matrix
    The Integration Matrix is an overview about all identified integration topics. Integration topics might be easy topics like “account determination in procurement”, or they might be very complex topics like “how to sell articles in a store although no article master exists for it?”.
    (It is important to be aware the the complexity of an integration topic does not necessary result from technical complexity but from business complexity.)
  • Integration Single Point of Contact (SPOC)
    As there will be multiple topics that need to be addressed and worked on, each functional team needs to nominate an integration SPOC. This person needs to have an overview about the different integration topics the respective team is owning or needs to be engaged with.
  • Weekly integration alignment meetings
    In this weekly meeting, new identified integration topics are explained, road blockers are named and brought to everybody’s attention, or other issues that have been identified, are shared with the other participants. This meeting also is used to exchange experiences and to ask for support, if not yet addressed in another way.

 

End-2-End scenario walkthrough

Another method to foster End-2-End thinking is to perform End-2-End scenario walkthroughs.

The End-2-End scenarios are created based on realistic scenarios from the customer. Ideally, they touch as many processes as possible, in order to raise awareness of all project members that the different processes are interlinked. Each team needs to explain the key topics of its processes that are affecting other processes, or to raise topics that are affecting the own processes.

The End-2-End scenarios are created by connecting the processes of the different functional teams. These scenarios could be created within Solution Manager. During an early stage of a project this could be best practice processes combined with already identified but not yet designed processes as shown in Figure 2. Walkthroughs, that are performed at a later point in time, can be performed based on already designed customer specific processes.

 

Figure 2: Example of an End-2-End scenario, based on best practice processes.

 

Further on, concepts of general importance could be explained to a wider group during a walkthrough session, e.g. article master concept or business partner concept.

 

Summary

Business Integration is an approach to raise awareness of thinking in cross team processes and not only in team specific topics. In addition, it offers a framework to manage topics that have to be designed or “negotiated” between multiple teams so that at the end the project is delivering a system with smooth and robust processes.

 

Assigned tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Werner Wagner
      Werner Wagner

      Hi Rainer,

      you are highlighting an important and recurring issue in our project work. Keeping a sharp eye on the "compatibility" of the solutions found in each contributing team is key for success. I'd like to add the thought, that under integration aspects, our cloud solutions basically contribute to an easier-to- accomplish integration on the business side, by design. At the same time, additional technical integration needs might occur, moving integration requirements into a different dimension. In the end one does not escape this challenge, it exists in many shapes and forms.

      Thanks for your thought-provoking article.

      Werner