In computing, adoption means the transfer (conversion) between the old system and the target system within an organization (or more broadly, by anyone).
If the company is working with an old software system, it may want to use a new, more efficient system, have more work capacity, etc. So a new system needs to be adopted, after which it can be used by the user.
There are several adoption strategies that can be used to implement systems within an organization. The main strategies are the adoption of the big bang, parallel adoption and gradual adoption. "Big bang" is a metaphor for cosmological theory of the same name, where the beginning of the cosmos occurs at one time. This is also the case with the big bang adoption approach, where a new system should be adopted wholesale on a single date. In the case of parallel adoption, old and new systems run in parallel at first, so that all users can get used to the new system, but can still do their work using the old system if they want or need to do so. Gradual appointment means that adoption takes place in several phases, so that after each phase the system is slightly closer to fully adopted by the organization.
Video Adoption (software implementation)
Choosing adoption strategy
An adoption strategy must be chosen before adoption begins, and is selected based on the objectives to be achieved and on the type of system to be implemented. Three types of adoption, Big Bang, parallel adoption and gradual adoption, ranging from instant switch to strategies where users are increasingly starting to use the new system over a certain period of time (which can be several weeks, months or even years).
The actual selection is done by prioritizing the goals to be achieved and then matching the strategy against it (Eason, 1988). Eason defines the following goals:
- Possible "critical mass" requirements to make the system work.
If a large critical mass, or perhaps, is required for the system to work effectively (eg due to network effects), a big bang strategy might be the answer. (Rogers, 1995)
- Need for risk control, if there is a risk.
Minimizing risks for ongoing organizational operations can be very important. Introduction in parallel and gradually can help control this risk, depending on the situation.
- The need for facilitation of change.
The organization must be ready for a change. Socio-technical preparations such as training sessions and ready-made scenarios must be clear.
- Speed ​​of change
If the new system is designed to handle new requirements, such as business process reengineering, the speed at which an organization changes to a new process or tries to meet other new requirements.
- Local design needs
The system may need to be tailored to the needs of the user. In this case, the chosen strategy should provide an opportunity to do so.
Tabel Eason Matrix
The choice of an actual adoption strategy depends on more factors than this goal, but they create a window to select one of its kind. The other criteria are called variables (Gallivan, 1996). Gallivan suggests that the appropriate type of adoption depends on:
The innovative nature of the individuals
Attributes of people who adopt innovation/system
Type of innovation
Is this process or product innovation?
Attributes of the innovation itself
Preparedness, communication, and sharing
Complexity of implementation.
How complex is its application or how far?
These variables have a higher level than the Eason criteria and should be handled as such. Based on table 1 and on the high-level variables mentioned by Gallivan, one can make the right strategy choices to choose from.
Maps Adoption (software implementation)
Prepare organization for adoption
Figure 1: Organizational preparation process
To prepare the organization for the implementation of the new system, changes that will occur need to be determined. This is necessary to have a plan or overview of the transition, and can be done by making requirements for the system. After management determines the requirements in the specified change report, they must approve it in order to continue the change process. If there is no agreement, management needs to discuss the terms again and again until they agree. If an agreement is reached and the contract agreement is signed, the organization can take further steps. So now the test phase can be prepared, where the validity of the data to be used will be checked and where trials will be held (Eason, 1988).
In parallel, it is strongly recommended that a comprehensive user adoption plan be prepared to work in conjunction with affected businesses and users. This plan should take into account all pre-and post-system launch communications; user & amp; documentation; internal marketing efforts that will be undertaken to encourage adoption such as brand systems or stolen goods; as well as troubleshooting help during launch (eg extended help hour and/or hotline, and key contact identification for each affected business area).
See also
- Implement SAP
References
- Eason, K. (1988) Information technology and organizational change, New York: Taylor and Francis
- Gallivan, M.J., (1996) Strategy for implementing new software processes: Contingency framework evaluation, SIGCPR/SIGMIS '96, Denver Colorado
- Rogers, E.M. (1995), Diffusion innovation, New York: Free Press
- Dodson, J. (2011), 4 Stop to Explore the Restrict of Dangerous Enterprise Software, Washington
.
Source of the article : Wikipedia
0 Comments