Update Safety Means Investment Security
| Translated by Julian Hammer
Release Change at Signal Iduna Accelerated Thanks to New Update Procedure
Update projects can present a significant cost factor for companies. This can be elucidated by some figures from independent authorities. World-wide, a total of about 458 billion US dollars were spent on enterprise software in 2019. Which means that since 2009, expenses have doubled (Source: Statista). Since unfortunately still about a third of all projects fail — or even half of them if one takes into account the success of projects with respect to adherence to date and budget — great financial risks are taken here (Source: PMI).
Investment protection therefore has paramount priority for companies when it comes to the implementation of software. Standard software often has to be customized via adjustments or extensions in order for it to comply with individual customer processes, other companies even opt for individual software solutions. Both software types, however, entail the risk of causing high expenses: in individual software solutions, the risks lie within software development; in standard software, the risks lie within the update process if the implementation of customer-specific adjustments in the new version cannot be performed without any major manual effort.
It is therefore all the more important that a software company make an effort to offer new procedures to its customers which provide a means to carry out updates based on automatic processes and which thus reduce costs even in updates of systems which entail major individual adjustments.
Update with numerous individual adjustments
Since 2011, the Signal Iduna group uses PLANTA project in the area of company organization to control the entire project portfolio with about 250 project managers, 4.000 users, and 300 projects. In the course of their years of software employment, Signal Iduna has moved away from the original standard software by implementing numerous individual adjustments. The customizing options provided by the PLANTA software were used to obtain a software with all benefits of standardized project management features on one hand, and to retain a certain flexibility which allows this software to be adjusted to company specific processes on the other hand.
Especially for customers like Signal Iduna, PLANTA has made an effort and has developed a new update procedure to protect customers with highly customized systems from experiencing major effort and costs in updates. Signal Iduna was the first PLANTA customer to use the new procedure and could therefore accelerated its release change substantially.
Rolf Jungnischke, technical product manager for PLANTA project in Signal Iduna’s business output and project portfolio management, considers the new procedure in this particularly complex change from DB release 9 to release 14 to be particularly positive: „In summary I can say that the new procedure is extremely helpful and that it has strongly accelerated the release change.“
Internal provisions at Signal Iduna scheduled an implementation of 3 months for the update of the employed PLANTA project management system. The challenge was that the go-live date was a fixed date and that the required conversion work had to be carried out in parallel with daily operations. Another factor which rendered the situation more complicated was the fact that the SIGNAL IDUNA group employed a strongly customized system and that the look and feel would change after an update. The changed look and feel gave rise to the project team’s aspiration to have a standardized design for all views: the user should not notice any difference between “old” and “new” or between “standard” and “own development”.
Opportunity to generate more fidelity to the standard
Another goal of Signal Iduna was to apply new functions from the standard in the release change or to forgo individual customizing — where possible — and thus to get closer to the standard again.
First the actual release change was carried out in several steps:
- Installation of an original PLANTA system in order to compare the new PLANTA standard version to the own individualized system
- Analysis via new update procedure: The analysis indicates the differences (“conflicts”) between standard and individual customizing, which are due to the fact that the standard has also changed since the time at which the individual adjustments were made by the customer. All deviations — even minor changes — are indicated in order to allow the user to decide for himself/herself whether they are real conflicts or not. In most cases, individual customizing can be retained.
- Editing and solution of the indicated conflicts
A large part of the conflicts indicated by the analysis could be identified as not serious and could be corrected by simply applying the required solution.
According to Mr. Jungnischke, this solution calls for a user who knows the system well and who is able to make sense of the conflict descriptions. However, initiated from the context menu with the respective system knowledge the analysis proves to be quite helpful and speeds up the release change.
If the customer carries out further updates, the decisions of the previous update are retained and are considered automatically. For the releases to come, PLANTA plans to implement further automation of this update procedure.
Subsequently, the reorganization of the individual system for more closeness to the standard was pending
- Adjustment of the individual customizings (views, data sources, Python scripts, DB adjustments) to the new release
In the course of this, numerous individual forms and reports were adjusted to the new look and feel, and Python calls / dashboards were adjusted as well. - Test
The test showed that here and there it is not reasonable to apply the standard and that some rework is required. - Go live
The project team at Signal Iduna was composed of three internal employees (one employee in full time and two with daily business running in parallel); on the part of PLANTA, one developer was available to assist where required. The project also proves to be quite successful with respect to its temporal progression. After preparatory work, like installation and GAP analysis, was completed, the team still had 2.5 months of time available and could eventually go into production four days before the date fixed for completion of the change. Currently, some minor rework is carried out and the end users are very happy with the new look and feel.
Conclusion on the new update procedure
Rolf Jungnischke (Signal Iduna) draws a positive conclusion from the new update procedure:
- The new update procedure immediately shows the differences (“conflicts”) between standard and individual customizing.
- The user should have Python skills and a profound system knowledge in order to be able to make sense of the conflicts and to be able to opt for the most adequate solution.
- In some cases, additional information could be helpful. As mentioned above, PLANTA is working on a further automation of this update procedure.
- In strongly customized systems, it is not always reasonable to apply a standard suggestion. This will become apparent in the test phase at the latest. However, errors could already be avoided upfront. Signal Iduna’s approach was to get closer to the standard again, which turned out well in certain cases. In some cases, however, Signal Iduna opted for a “hybrid solution” (e.g. standard Python and individual views). The new update procedure has rendered such a solution more practical.
