Full speed ahead into the future or stuck on the siding?

Starting a project to migrate the old and stable SolMan 7.1 to the new version 7.2 presents hurdles in companies.

It is difficult to argue why a large budget should be used to replace a stable system for which there is still little to no field experience.

Not for all companies are the improvements in 7.2 reason enough to implement an update in this dimension. An important argument for Life Science to implement SolMan 7.2 is the need to comply with regulatory requirements.

If errors occur during operation of version 7.1 after the end of maintenance, interfaces or add-ons are no longer maintained or connected systems are no longer supported, GxP-compliant operation is no longer ensured.

The conversion of the connected systems to S/4 Hana that has begun can also be used as a further argument. SAP does not guarantee smooth operation between SolMan 7.1 and the systems running on S/4 Hana.

Greenfield or brownfield?

Once the first hurdle has been cleared, the question of a strategy arises. Two options are available for this. The first alternative (so-called greenfield) is based on a newly set up system on which all processes, tables and master data are reloaded.

The legacy system must be shut down and archived as scheduled. The second alternative (called brownfield) also involves setting up the system again. However, the focus here is on continuing the system history and not splitting it between two systems (new and old).

The initial migration represents a high effort here. Both alternatives have their advantages and disadvantages. The greenfield variant offers the attraction of setting up a new, unencumbered system, which leads to lower maintenance costs. However, the legacy system must continue to be operated to ensure access to the history.

The brownfield alternative bypasses the initial effort of sorting out data before migration, but still maps the entire history after conversion to 7.2.

After project governance has been agreed, interfaces raise questions. In SolMan 7.2, SAP provides its own BPML editor, which raises the question of how long the interface to third-party tools will be maintained.

The new test suite also raises the question of whether and how long the interface to other test programs will remain usable. The interface to HP QC is no longer included in the standard and must be purchased separately.

The critical Life Science requirement to be able to provide legally binding signatures is also a problem in 7.2. This add-on functionality provided by SAP for 7.1 will no longer exist in 7.2.

This means that the requirements for a signature process that complies with regulatory requirements are no longer met. Individual solutions must be found here to close the GxP gaps - ideally with an experienced partner.

A special issue is also raised by the structure of 7.2 on agile project methods. Reconciling agile project methods and systematic GxP-compliant documentation is a difficult undertaking, for which empirical values from past inspections are also lacking. New approaches must be developed here or functionalities must be dispensed with in order to be able to pass an inspection.

In summary, the introduction of SolMan 7.2 presents those responsible with a major challenge.

Whether companies will take the gamble of running SAP systems (on Hana) with SolMan 7.1 out of maintenance, or whether they will accept the challenge of the update: It remains exciting. However, they will have to make a decision sooner or later.