Rollout or not rollout? – Paweł Prymakowski

What is a rollout?

It happens that a Polish department of an international company starts, usually at the request of the headquarters, the implementation of a system (eg ERP) that is used throughout the corporation. Then a mysterious phrase appears rollout project. Rollout is the development of a system that functions in an enterprise for subsidiaries or other group entities. The first implementation usually becomes a model that should be used by subordinate companies. However, they often operate in different organizational cultures or legal environments.

What rollout is and what isn’t…

During many implementations of ERP systems in Polish departments of international organizations, I have encountered various approaches to such projects.

Projects attitudes

• „Classic” rollout is a project is based on a “exemplary” implementation. Usually the functionality, processes, analytical dimensions and settings do not differ (or slightly differ) from the corporate standard. Most often, the installation is based on a central (international) database. Any changes are usually related to the local specificity or legal requirements of a given country. The project is managed from the headquarters level (company headquarters + global IT partner), and the “local” ones play an advisory (not a decision-making) role.

We can easily see that the classic roll-out doesn’t assume full business analysis. Such an implementation uses data obtained during the original (model) implementation. Rollout implementations require familiarization with the model. For this purpose, it is best to appoint a local working team and show the compliance of the model with the local specificity.

• Complete opposite of the first approach: “The headquarters has implemented the X system, we are satisfied, please implement the same system in company Y.” In such a model, the subsidiary company is / is not (delete as appropriate) required to comply with general standards (but they are “fairly general”) and is free to determine the design scope and configuration details. The implementation is done by a local partner and the project is managed from the “national” level. The system can be installed in a local company and, for example, integrated with the central one. This model of projects is quite common during the implementations of Microsoft Dynamics. In fact, we are not talking about a rollout in this case. It is really an indication of the target system that is tailored to the local specifics and its requirements.
• Intermediate models are common: they combine selected elements from both approaches described above. For example, project and budget management is performed centrally, but the team and scope are determined locally, taking into account several cardinal rules (e.g. controlling system).

How to make a rollout successful?

The decision on the selected model may depend on several factors: the policy of the headquarters, the balance of power in the corporation / group, technical conditions, etc.

Some complications are introduced by the fact that quite a lot of entities participate in rollout projects, which don’t always have common interests, and efficient communication between them is usually a challenge. Most often we meet people from:

• Company headquarters – “we want to implement it in a local branch quickly, at low cost and similarly to the headquarters, because our standard is universal”.
• Local department – “they at the headquarters do not know, but we have our own specifics (…) and these Polish tax regulations …”  
• Global implementation partner (employed by the headquarters) – “we have a ready-made solution; we only need minor additions to handle local regulations; only a few working days “
• A local implementation company – “but the localization package is not everything, there are still many elements for the system to be implemented ‘in Polish'”
• Possibly other entities – external consultants, companies supporting IT infrastructure, etc.

The basis for efficient operation is to define the division of tasks, responsibilities, and communication rules.

Regardless of this, the team that is preparing for such a project should take care of a few things in their own interest:

• Meet the standards (not only the minimum required regulations, but also “good practices”). As a result, it will receive a system that not only includes standard functionality, but also a system that is also adapted to local requirements (regulations, document formats, ergonomics).
• Get the support of an external consultant. Acquiring an expert will help us defend our requirements. It will allow you to counter the opinions from the headquarters: “It’s too expensive, too much interference in the system”, “But it works well in Germany / Italy / the Netherlands / everywhere”, “Your requirements are frills.” The role of the consultant is to work out a compromise and explain which elements are crucial from our point of view and to what extent the solutions proposed “in advance” can be adopted.
• Provide support in your own organization at the management level. Usually, the team from the headquarters will be reluctant to talk about our proposals. It would be worth having support in the event of more serious conflicts so that you can fight for what is most important.
• The last – often the most difficult task: try to establish a good relationship with the team at the headquarters. It is not uncommon for many goals and activities to be reconciled with a little goodwill and openness to compromise.

Author

Paweł Prymakowski – CEO of IT Vision – a company implementing ERP since 2000. Experienced executive, sales and business development expert.
Experienced expert. He has led many international projects. He has experience in many industries: IT, services, production, construction, facility management, trade / distribution. Paweł also knows very well business areas such as: management, controlling, BPR, accounting, IT project management, EU funds as well as planning and implementation of international projects