Alignment of Corporate Business Processes

In large international corporations, there is a need to align business processes running within individual organizational units in a group. This allows the company to use consistent information necessary for proper enterprise management.

It should be noted that a full business process alignment is not possible at the corporate level because of the need to consider specific local requirements reported by individual entities. Local specificity may be related to legal requirements resulting from the national legislation, or to the differences in operational (production, service) activities of individual organizational units.

Therefore, business processes in an organization must be divided into the processes common for all organizational units and the local processes, characteristic of the selected companies or branches.

The division of business processes into the above two groups (common and local processes) is a conventional, corporation-specific division. The line of this division is largely dependent on the headquarters’ determination to develop and introduce a common solution, as well as on the clout and determination of individual branches to defend local solutions.

For example, a common process may assume cooperation with an external shipping company. In this case, the steps related to handling outbound deliveries by a third party, including a proper settlement of transport costs (settlement of transport service costs), are defined within the common processes. In turn, a local process may consist in handling outbound deliveries by using an internal transportation fleet. In this case, the changes in cost settlement rules arising from the necessity to include maintenance and operation costs borne by a local entity must be taken into account.

Another example of a common process may be a VAT registration based on the applicable European Union directives. In this case, a tax obligation is recorded when the accounting document is registered based on the document creation date. However, a local requirement may be to register tax based on a different date (a dedicated tax reporting date), arising from the legislation applicable in a specific country.

Separation and description of the common and local processes in a corporation is a difficult undertaking that requires collaboration between the headquarters and all group companies. This task may be easier if we use tools to support enterprise management. Standard processes contained in these tools may be a good starting point for describing target company processes. The integrated SAP ERP system may be a system to base the definition of the common and local processes on.

This article summarizes BCC’s (now All for One Poland) experience gained during the reference solution development projects for international corporations, including the solution implementation in particular organizational units. The character of such projects, their diversity and the main project risks, including examples of risk mitigation, are presented at a general level.

Description of Common Processes

To begin with, let’s think how to approach the separation and description of the common processes in a large, international or multi-branch organization. The key questions follow below. The answers should serve as a starting point prior to planning the activities related to the common process description.

Have the headquarters of the corporation gathered the knowledge on the scope and course of processes in individual branches? It is necessary to check the level of detail of this knowledge, and whether it covers all areas of activity and entities at a satisfactory level.

Is the corporation a homogenous organization, or are there clear divisions due to historical conditions (e.g. considerable autonomy of local companies as a remnant of earlier acquisitions)? What influence will individual entities have on the development of a common solution? What will be the scope of the common processes and the resulting scope of local solutions? What will be the scope of responsibility at the level of headquarters and individual entities? The answers to these questions greatly depend on the level of company centralization and possible differences in the operational activity profiles.

Is it possible to create a team that will be able to develop the common solutions for all entities?The team members should have very good, detailed knowledge of the processes in the organization, including all areas to be covered by the description.

Will the business process description be embedded in a particular IT tool, and to what extent is third-party support in the IT system implementation provided for? Are the individual branches using a specific IT tool, or are they planning to use such a tool in the future? While today it is difficult to imagine that this type of undertaking could be carried out without the use of an IT system, third-party support and an implementation scope are very important issues, in particular when planning the budget.

What is the schedule for the implementation of the common solutions at individual companies within the corporation? In large organizations, the order in which the entities are covered by the solutions, or the division into groups that will be covered by subsequent phases, may result from very different keys (e.g. first off, the companies with a wide range of activities and many processes or with a narrow activity profile, the strongest in the group, those with the best-structured processes, or those where the implementation need is the most urgent).

What financial means may be used to work out a common process description? To answer this question, one must bear in mind that the business blueprint for the common processes is a part of the whole project, and the budget for this phase should be determined proportionally to other phases.

To what extent should the deliverables of other projects carried out in the corporation be used? The main factors are the quality, scope and functionality of the solutions and the ability to enhance and integrate them with the new tools.

What will be the level of detail of the business process description? What documentation standards should be observed during the preparation of the common process description? At this point, it is worth balancing the need for detailed documentation against the amount of work needed to prepare it. Remember to include in the budget the time needed to prepare the documentation.

In effect, each such project will be conducted differently so that it includes the specifics of a given company. For example, the business blueprint for the common process description may be implemented as:

  • A project with a minor contribution of individual organizational units, assuming the use of the selected IT system (e.g. SAP ERP, SAP BI) and internal resources of the corporation; the deliverables of previous projects will be used during the project.
  • A project with a major contribution of key organizational units (for example representing typical areas of operational activity), assuming the use of a specific IT system, internal resources of the corporation and external resources (e.g. SAP consultants from implementation companies); the deliverables of previous projects will not be used during the project.

Local Processes

The description of the common processes is supplemented with the description of local processes. They extend and complement the description with other business processes that are specific to the selected branches so that the solution includes a complete set of processes in the organization covered by the project scope. The description of the local processes is performed after completing work on the description of the common processes.

In some cases, the process developed for the needs of a local company is so universal that the corporation may decide to accept it as a new common process. This mostly happens in situations where the existing common processes do not satisfy all business requirements. For example, when business requirements evolve due to a change in the market situation.

The description of local processes extends and complements the process documentation with other business processes that are characteristic of the selected branches.

Reference System for Common Processes

An approved description of the common processes prepared for a specific IT solution (e.g. an integrated SAP ERP) is a starting point for developing a reference system (template). Such a system is prepared to test the functioning of all the common processes before their first live use in the organization.

Since the description of the common processes can be developed at a quite general level, it is necessary to plan the business blueprint phase. Its goal is to map the business requirements presented in the description of the common processes to individual functionalities available in a specific IT system.

An approved description of the common processes prepared for a specific IT solution is a starting point for developing a reference system (template).

The business blueprint must be expanded to include a description of the configuration settings of a specific IT solution so as to allow later preparation of all processes in that system, without having to organize additional workshops to refine the requirements.

After the completion of the business blueprint phase, the realization phase should take place. During this phase, the IT system is configured and extensions to the standard functionality are developed according to business expectations. Then, sample data is uploaded into the system and tests of the common processes are performed. While preparing the sample data, remember that the data structure and diversity should reflect the target business data which will be uploaded into the productive system. This will allow you to thoroughly test the solution and check all required process execution variants.

Both implementation phases (business blueprint and realization) should end in a formal acceptance of their deliverables. In the case of the realization phase, a reference system is accepted. It then serves as a base for implementation projects that aim to get the common processes to the go-live stage in individual organizational units of the corporation.

Template vs. Local Processes

The common processes can be implemented in the corporation in different ways, with consideration of the number of organizational units in which the processes go live at the same time. Relatively simple reference solutions may be implemented in parallel in a greater number of companies. Large implementation projects (e.g. the implementation of an IT system covering all major areas of activity) are usually carried out in stages, for one organizational unit at a time.

During the local implementation, the functionality available in the reference system is analyzed in detail and all changes to processes are described.

As already mentioned, the local processes can be adapted as new common processes. In this case, it is necessary to make sure that the reference system settings are updated in parallel with the project works for a specific organizational unit.

The go-live of new common processes in other branches of the corporation is usually covered by separate projects that are carried out at a later time. Organizations need time to prepare to use the new functionality.

During the rollout project (i.e. the reference system implementation in a local company), the following major activities can be distinguished:

  • Analysis of the reference system scope
  • Description of local processes for new functionalities which are not available in the reference system
  • Description of the system settings for local processes/new functionalities
  • Description and configuration of organizational structures for a new organizational unit (based on reference system structures)
  • Activation of relevant reference processes (activation of common processes for a new entity)
  • Migration of test data for the common processes
  • Tests of the common processes
  • Configuration and preparation of the system extensions for local processes
  • Migration of the test data for the local processes
  • Tests of the local processes
  • Acceptance tests of the common and local processes
  • Training courses for key users and end users
  • Master data and transactional data migration within the go-live preparation
  • System go-live
  • Post go-live system support

Dealing with Risks

This section examines the most important risks associated with building a system template for a corporation and suggested risk mitigation factors.

Overly general description of the common processes and no definition of key terms used in the project documentation. Please note that during individual project phases, many people will use the description – often those who didn’t participate in the preparation of the process description. Lack of precision or a description that is too detailed may, in extreme cases, lead to misunderstanding of the process and preparation of an inappropriate configuration concept. To reduce this risk, precise information on the level of detail required for the documentation must be provided (templates and sample documents), and a kickoff meeting must be organized to discuss the deliverables of this phase and to present the work schedule. Additionally, people responsible for the preparation of the phase deliverables must be appointed.

Overly detailed description of the selected common processes and overly general description of other common processes. Examples of the mitigation factors for this risk include a providing a detailed work schedule, progress monitoring and reacting to possible delays, and appointing people responsible for the preparation of the phase deliverables.

Difficulties in mapping the requirements gathered in the common process description to IT system functionalities. This risk may occur in a situation where the process description is considered only as a business project, in isolation from the IT system. It can be mitigated if people who are familiar with the IT system that was selected for the reference system development engage in the preparation of the common process description. In addition to the common process description, it is worth adding the descriptions of the method used to implement the solution in a specific IT system and scheduling the time needed to discuss how the business requirements for particular processes should be implemented in the IT system.

A large number of open issues identified during the common process tests conducted in a reference system. Examples of mitigation factors for this risk include a detailed description of the method to be used to implement specific business requirements in the IT system during the business blueprint phase and performing partial tests in order to present the selected functionalities in an early project phase. It is important to remember to accept all major deliverables (common process description, detailed common process blueprint, unit/integration tests performed on the development system, tests performed on the quality system).

A large number of local processes identified during the rollout project. This risk can be reduced by involving all organizational units of the corporation in the development of the common process description and requiring them to formally accept of the description of those processes. The scope of the common processes should include all major areas of activity of the company, and it should be sufficient to effectively conduct business.

Knowledge and Experience

There are huge benefits to be gained from standardizing business processes at the corporate level and taking advantage of capabilities to gather and process the data in one consistent and efficient solution. However, it is a long road to achieve them. The development of reference solutions and their implementation in subsequent branches or companies of the corporation, in consideration of local processes, is a very challenging task. It is worth combining the knowledge of the way the company operates and of business conditions with the potential of the consulting company that knows the IT system in which the processes will be implemented and has experience in similar projects.