Big bang adoption or direct changeover is when a new system is adopted instantly, with no transition period between the old and new systems.
When a new system needs to be implemented in an organization, there are three different ways to adopt this new system: the big bang adoption, phased adoption and parallel adoption. In case of parallel adoption the old and the new system are running parallel, so all the users can get used to the new system, and meanwhile do their work using the old system. Phased adoption means that the adoption will happen in several phases, so after each phase the system is a little nearer to be fully adopted. With the big bang adoption, the switch between using the old system and using the new system happens at one single date, the so-called instant changeover of the system. Everybody starts to use the new system at the same date and the old system will not be used anymore from that moment on.
The advantage of a big bang adoption is that the new system does not need to be compatible or connected with any old systems it is replacing. This significantly simplifies the design of the new system, especially in an organization that is running on multiple incompatible systems. However, the big bang adoption type is riskier than other adoption types because there are fewer learning opportunities incorporated in the approach, so more preparation is needed to get to the big bang. This preparation will be described below, illustrated by the process-data model of the big bang adoption.
Implementation
Once the management has decided to use the big bang method, and supports the changes which are needed for this, the real changing process can start. This process comprises several steps: converting the system, releasing parts of the system and training the future users.
The activities in the process are explained in the table below, to state them clearly. The concepts that are used to execute the activities are in capitals.
Convert the system
At first, a plan for the whole adoption process is needed. The plan allows future users to know what will happen and when they should expect certain changes, which avoids unnecessary uncertainties and therefore creates a better working atmosphere. The plan also makes clear when the real adoption takes place and gives the future users the opportunity to get ready for this change. The model below shows that the activities (in the grey box) lead to outcomes (in the boxes next to the grey box) to be able to have a partial outcome: the converted system
When the plan is made and everyone knows what is expected from them, the technical changeover can start. First the old data needs to be converted into a form which is able to work with the data in the new system (Koop, Rooimans and de Theye, 2003). Then this data needs to be loaded into the new system, which results in the so-called loaded data. This loaded data needs to be tested to check the efficiency of the data and to test the level of understanding of the future users. Off-line trials need to be executed to check whether the system and the users can work together. Not only do the efficiency and the understanding need to be tested, but the validity needs to be tested to make the level of data validation clear. If the data is not valid, the management need to determine the changes again and the organisation will have to prepare a different way of executing the Big bang adoption.
Release parts of the system
If all the data is valid, separate parts of the system can be released. The database which is converted from the old database needs to be released, so the new data is accessible. Next, the produced application needs to be released, so the new application can also be used. The infrastructure of the whole new system also needs to be released, so that it is clear what the system will look like and how everything is connected (Koop, Rooimans and de Theye, 2003). In this phase only separate parts are released, which don't form the new system yet, but only parts of it. All of this happens off-line: only the system developers see this, while the users are still working on the old system. The model above shows what activities need to be executed (in the grey box) by the system controller, to get the outcomes that lead to the released parts. If the release of the parts failed, the management need to determine new changes again (See Adoption; Prepare an organization for adoption).