Digital business processes roll-out at multi-entity company

Introduction

The digital transformation is still accelerating and spreading across large enterprises looking for cost reduction and operational improvement.

We can observe on the market a rising number of digital transformation teams and departments, resulting in significant number of projects involving business and IT.

The methodology of delivering projects is evolving from traditional waterfall/fix to more agile, strongly aligning technology teams with business users. IT is also shifting from classical heavycoded on-prem application development, towards multi-services, cloud approach and low-code/nocode platforms which are more change-friendly and better for prototyping.

Nevertheless, the number of successful projects in larger organizations has not changed. The statistics are showing that only approx. 30% of companies are successful in digital transformation. And of course, there are many reasons for that, but the main is surely, organizational challenges. To describe them, we can point to few most important factors:

• Change resistance
• Involving many departments/ subsidiaries into projects
• Constructing the right project teams
• The proper strategy for rollouts in subsidiary companies
• Effective requirement discovery process
• Change Management process after initial implementation

In this article we want to focus on the strategy of rollout process in multi-entity companies capital groups and holdings, sharing some good practices and highlighting important topics. The article is based on GoNextStage (GNS) consultants experience gained in projects for Clients that have gone through complex projects involving international rollouts.

Standardization vs localization dilemma

When leading a project that requires a rollout on different entities inside a large enterprise there is always a dilemma between forcing one standard or implementing a dedicated process suitable for local business requirements. Of course, this depends on many elements, for instance:

• Structure of the group – shared services or decentralized business units
• Is this an international rollout covering law or tax requirements which may differ by country
• Strategy of how autonomous subsidiaries could be from the business perspective – how much do we want to align and streamline processes in a group
• Scope of the project and type of application to be implemented
• The budget of the rollout projects
• Differences in IT architecture and approach in group
• Differences in sales and customers services

During implementation of bpm processes, companies with multi-entity structure must clarify the strategy of standardization/localization
approach. This strategy should be supported by management and project owners.
Stronger standardization is better when organization:

• decides for standardization of processes to achieve coherent information flow and management inside group
• decides for standardization of customer services
• wants to implement corporate culture and structure

Stronger localization is better when organization:

• wants to keep a local process as they are with only some improvements
• is supporting autonomous business in area of customer service and back-office
• needs to keep dedicated data structure or IT system

The company strategy can be more extreme on each approach but also can try to balance the two approaches – this is what we are most experienced in at GNS. The balanced approach is using both sides of the “scales” trying to get most of it. Below we will describe shortly our balanced method, which we simply call balanced rollouts approach.

RAFAŁ POGONOWSKI
Project Manager / PMO Lead
Green Business Centre Sp. z o.o

DIGITIZATION OF BUSINESS processes is always an opportunity to organize and standardize processes. When preparing for the implementation, it is worth considering, at least initially, which organization requirements need to be implemented in the future (rollouts). The result of implementation in the first company in the Group should be a reference model. Depending on the type of company and the processes, the reference model should cover 60-80% of the requirements of the next business entities. A substantial element in the preparation for roll-out implementation is change management.

Balanced rollouts approach

The main challenge is always to manage the cost of the project. As budling standard and rolling it out without any customization is always cheaper than time-consuming customization for single company in a group. Another cost factor that will escalate in future, is the support services. Support teams will have to manage number of different processes rather than just one standard.

Our method is to balance costs between both approaches by using an innovation method of implementing one process for multi-entity, keeping customized business rules, integration, data scheme for each subsidiary.

Balanced rollouts approach needs to be based on proper BPM/low-code platform that allows to design processes around organization which have multiple business entities. For us the best choice is always Webcon BPS. This mature low-code platform gives several functionalities that help to manage process per entity e.g., permission management, business and forms rules, integration services, data views and many more. Webcon BPS is an efficient platform for enterprises usage in large scale with lots of application running.

GNS main stages of balanced rollouts

Now let’s dive into details on how we preform rollout project. The graph below shows the overview of the GNS method of implementing initial project and rollout project. Below the graph we have described the main stages.

Initial project

We start analysis mostly with presenting our prebuild applications, which we called GNS Proven Business Logic (PBL), templates which were worked out during significant number of projects with different Customers (we have described that subject in this article).

Thanks to using PBL, the analysis stage is more fit-gap type. It means that we can present our templates on demo as prototypes for future customization. After that, we have typical agile D&D (design&develop) stage when we work closely with Client teams, designing, developing, and testing final solution. After number of iterations, we finalize with UAT tests and go live, paying attention to the proper user adoption.

The outcome of initial project is a standard process. This product becomes an input for the rollout on subsidiary companies in a group. The standard will also be improved in the future by stabilization stage and support phase which both positively impacts the standard by company adoption, implemented change requests, etc.

Rollout project

In rollout project we start with analysis by fit&gap approach, using standard process as a template. This stage is very crucial when it comes to good communication between teams and business in relation to standardization/localization. In many companies this will vary depending on management and IT strategy balancing the two approaches described above in this article.

In general, the rollout project has the same stages as an initial project. Depending on the analysis result in D&D we can deploy new process or use a multi-entity process functionality on Webcon BPS platform. During D&D stage, apart from dedicated localization changes, we will very often design and develop new improvements, comparing to the standard process. Those improvements sometimes are just minor changes but can be also a bigger feature that needs to be upgraded to the standard. This is a phenomenon we call the balancing feedback loop between initial standard and localized process. It is simply a new improvement from rollout project that has been deployed to standard process so future rollouts can benefit from it.

Diagram presenting the balancing feedback loop:

So, from the one side the standard process is constantly being upgraded by improvements (CRs) from initial implementation and on the other side it is improved be new functionalities from project rollouts. This cycle we can call an Invert rollout which is an effect of balancing feedback loop.

RAFAŁ POGONOWSKI
Project Manager / PMO Lead
Green Business Centre Sp. z o.o

WHEN DECIDING to implement a new functionality, we always try to consider whether adding this change to the standard (reference model) and utilize it in processes in other companies. The invert roll-out approach applied by GoNextStage was a perfect-match for Green Holding Group.

Invert roll-out and change management

As we described above, during every stage of rollouts – analysis, D&D, UATs and support, there are many situations when new functions or even bigger architecture changes are transformed to a standard. We can point few reasons for that:

• localization requirements need to change the architecture of standard to be more configurable for next rollouts
• finding a new, better way to improve some process logic or user experience
• localization requirement turns out to be also proper to extend standard functionality to become more automated

When rollout project is already implemented in many companies in the group, the new functionalities from feedback loop needs to be rolled out back to every of those companies that already use the standard process. Here it is always a hustle, what to change and what not, considering localized requirements. It requires solid change management and communication inside the organization. Often, the complexity of invert rollout, having many companies onboarded to a system, discourages transformation leaders from even analyzing its potential benefits.

How to encourage to preform invert rollout and how to manage it in your project? Here are some good practices that can help you:

• ensure good communication between digital transformation teams responsible for rollouts and companies’ business inside a group. It is very useful to have a regular meeting discussing changes of architecture in standard process and deciding about new functionality from feedback loop. Those meetings should include both – digital transformation teams and business teams. More difficult decisions should by supported by management or c-level
• support communication between business owner of different companies inside the group. Sometimes this is unfortunately a huge problem and barrier as companies are not keen to communicate and share knowledge
• always be cautious with stronger localization during rollout, that leads to complete disconnection from a standard process and blocks the ability for getting new improvements work out by other subsidiaries
• constantly train and adopt users to new functionality in every company
• digital transformation team should be a unit independent from the whole multi-company group. The team should build good relations with business owners and help them to achieve their digital transformation goals
• take care of proper change management system supported by enterprise architect models, impact analysis and documentation

Summary

By this article we mostly want to encourage digital transformations teams to pay attention when designing new functionality during rollouts and analyze the impact on standard model/process. By following this path, every company in the group will benefit from evolution of the standard processes and can actively take part in improving those standards.

If you have any questions or concerns do not hesitate to contact us.