Software implementation
Software introduction (also software rollout ) is the project-like process of establishing software in larger organizations (e.g. companies or public administration ). This includes the steps of software distribution , installation , configuration , recording of data, setting up the IT operating organization ( operating ), training of employees, as well as the conversion of internal company processes. If the software is to replace an old system , data migration and a shutdown of the old system can also be added. In the case of standard software , the customizing can be embedded in the entire software implementation project; in the case of individual software, the software implementation is the step after the software development .
There are basically two strategies for introducing software: the big bang and the iterative introduction .
Big bang
The new software is fully implemented and put into operation at a single, clearly defined point in time (usually at times when the unavailability of a system is largely uncritical, for example on a weekend or at the turn of the year) so that it is then fully available. To minimize risk, this type of software implementation requires extensive planning and preparation in advance (extensive software test , training of administrators , operations and end users ). In the event that unforeseen or unrecoverable error situations occur at short notice, a rollback should be planned.
A risk of this strategy is that the software is never fully implemented or used with a long delay (for example, because the requirements for the software change frequently and at short notice, so that improvements must be made continuously). In addition, technical difficulties (load situations, performance) can often only be assessed poorly in advance, which often only shows after commissioning whether the solution is actually suitable for productive operation.
Iterative introduction
Opposite the Big Bang is an iterative introduction of a new system, i.e. the introduction in several, smaller steps. Smaller components and the dependencies between them must be identified and analyzed in advance. Both must be taken into account during the iterative introduction (for example, a web application cannot be installed before the web or application server required for it is installed).
The iterative approach is intended to reduce risks from a possible failure of the entire system. Furthermore, it gives the software users the opportunity to gain experience with parts of the system at an early stage, which in turn can be taken into account when developing and introducing the next parts. Often, however, you will have to live with incomplete interim solutions over a longer period of time. If there is a legacy system in which data is entered, iterative introduction is difficult. During the transition period, employees may be forced to work with two systems.
A risk that should not be underestimated in the iterative introduction of a new system is corporate policy changes during development: projects are stopped / scaled down for cost reasons, company restructuring requires new planning, the company management sets new priorities. This can lead to the fact that the entire system is never fully implemented in its original planning and can therefore only be used as a whole to a very limited extent or, in the worst case, unusable.