Implementation
The implementation stage of any project is a true display of the defining moments that make a project a success or a failure. The implementation stage is defined as "the system or system modifications being installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements" (DOJ, 1). While all of the planning that takes place in preparation of the implementation phase is critical, I am of the opinion that the implementation itself is equally as important.
When working through the process of defining and selecting my organization's new enterprise business system, the implementation stage became the most anticipated and important part of the SDLC for the organization. A tremendous effort had been exuded in planning and preparation for the application development and deployment.
ERP- Vendor Evaluation Services, Gap analysis and ...
English: Business consultant
business_routesThe start of the implementation phase was an indication that progress was being made and the system was well underway.
For my organization, the implementation phase kicked-off with the coding of the application. Because we were using a retail system with a few customizations, the coding stage was not nearly as long as it might be with other business systems. With regard to coding, two things had to occur. The first was to customize some of the fields and interfaces in the retail system. The second was to develop the web-based front-end that would serve as the primary interface to our application. Both of these coding tasks were completed in a reasonable amount of time.
After the initial coding was complete, the customized application and web interface were presented to my organization for approval. For the most part, the presentation was successful. We had decided to modify a few of form fields and change the color scheme of the web interface. The consultant made the necessary code changes and presented the modified versions for our approval. The changes were precisely what we expected and we accepted the final versions. After receiving our approval, the consultants finalized the code and prepared to move into the testing phase.
In testing, the objective is "the bringing together of all the programs that a system comprises for testing purposes" (SDLC Glossary, 1). The testing phase for our application was broken into two halves. The first half was to test the entire application from a programming perspective to ensure as many bugs as possible were detected. This part of the testing process was completed by the consulting organization. Upon completion of their testing, a document was given to my organization that detailed all of the problems encountered and what actions would be taken to remedy the issues. After acknowledging the issues, the consultants took some additional time to fix the known problems and repeat their half of the testing phase. Again, we received a report detailing that no new issues were discovered and that all prior known bugs had been resolved. At this point, it was time to begin my organization's half of the testing phase.
We selected six of our power users to test the application in their daily work environments. In many instances, this phase of testing was similar to a parallel system deployment. The employees were asked to perform their job functions using both the old and the new systems. We understood that there may be loss or corruption of data in the new system, so it was necessary to have the users make use of the old system as well. We also realized that this testing approach was time consuming and would case a significant loss in productivity. As such, it was decided to limit our portion of the testing phase to ten business days. During those ten days, each of the users was asked to maintain a log of any problems, concerns, or issues they had encountered while using the new business system.
At the conclusion of the ten days, the entire group of test users and the consultants met to discuss the logs that had been maintained. As it turned out, the number of problems were minimal, but nonetheless, had to be addressed. Similar to the first part of the testing phase, the consultants were given some time to make the necessary programming modifications to compensate for the issues discovered by our employees. After a short period of time, the same group was convened to review the modifications and ensure that everyone's concerns had been addressed. After agreeing that all of the issues had been addressed, it was time for the official installation of the application.
In our particular case, the installation process was fairly simple. We decided to remove the test system completely from the server and install the final system from scratch. The consultant provided all of the final code and a fresh instance of the system was installed on our in-house server. Because we had designed the system to be entirely web based, the only client installation necessary was for system administrators. The administration client was deployed to each our system administrators within a matter of minutes. All other users would make use of the system through their web browsers.
At the end of the new installation, a small test phase was completed again. The purpose of this phase was only to ensure the new installation was functioning as expected. We simply tested all aspects of the application while checking for errors. Fortunately, we didn't discover any additional problems, so we were ready to begin using the new system.
We had decided to use our old and new business systems in parallel for the first month of operation. The reasons behind this choice were two-fold. First, even though it would be time consuming to enter duplicate data, we wanted to ensure that our business flow did not suffer should the new system fail or require extensive modification. We felt the productivity loss was well worth it in comparison to losing an entire month's worth of data. Secondly, we needed to train the end users in small fragments as to not disrupt the general flow of business. Because of this, it would take a while to make sure every employee received training. So, the employees would still be able to use the old business system while awaiting their training session on the new application.
"After installation and testing and total system validation, training and documentation (operations and maintenance) manuals are usually provided" (SDLC, 1). Over the course of the next few weeks, we held individual training sessions with each of the employees that would utilize the new business system. The application training was conducted by our power users instead of the consultant. We felt our users better understood the needs of their peers and it would make more sense for the training to come from within. So, the power users were trained by the consultants and the remainders of our employees were trained by the power users.
Select members of our IT department were trained by the consulting company. The training was centered around the maintenance and troubleshooting of the system and not necessarily around the programming and code. The training covered things like where the program files were stored, what data should be backed up, and how to perform basic troubleshooting in the event the application was not responding. Any support outside of these general parameters would be handled through our maintenance contract with the consulting company.
Once all of the training had been completed and the system had been operational for an entire month, we discontinued use of our old system and migrated historical data to the new application. At this point, we were totally dependent on the new business system and most every employee within the organization was somehow making use of the application.
The last steps of our implementation were documentation and ongoing support. End user documentation had been prepared and delivered during the individual training sessions. The documentation consisted of simplified how-to instructions that would assist the employees in completing their everyday tasks. The other major component in the documentation was the site manual that was prepared and delivered by the consulting company. The site manual contained all of the standard manuals from the retail software as well as some site specific manuals written by the consultants. They also included application specific data such as data flows, programming layouts, and web interface instructions. Essentially, the site manual contained most everything that would be needed to develop the application again, should that ever be necessary.
With regard to ongoing support, we entered into a maintenance agreement with the organization that developed the business system for us. Because we didn't have any in-house programming talent, we thought it to be a wise investment to pursue a maintenance agreement. To our benefit, the agreement also included a specified number of hours to make any desired modifications to the application. While these hours wouldn't be enough to develop new modules or redesign interfaces, they would be helpful should a field need to be moved or some other minor detail need to be changed.
The implementation of our business system was very organized and paced. There was never an urgency to quickly fix something or a rush to deploy the system. Instead, we approached the implementation phase from a logical and organized perspective to ensure nothing was overlooked. After all of the hard work and planning that went into preparing for implementation, it was rewarding to achieve the final result.
Works Cited:
DOJ System Development Life Cycle Guidance. Chapter 1.
SDLC Glossary: System Testing.
W&H Systems, Inc.. SDLC.
Business Class
English: An example implementation for split payme...
English: Typical business systems