Although both research and experience have shown that ERP cannot be thought of as “just another IT project,” the SDLC can be used as a basic approach for such a project. ERP Solutions uses a five-step approach to implement an ERP system for its clients. The five steps have different names, but the tasks are fundamentally the same. Here’s their process:
Designing and implementing any type of information system is a daunting task. Such projects are complex, often spanning many months with budgets in the five-to-six figure range or more. The Centers for Medicare and Medicaid Services, a part of the federal Department of Health and Human Services, prepared an excellent document with a brief overview of several systems development methodologies (2010).
The items in their list include:
- Prototyping. An approach for working with the systems development life cycle (discussed below) in which system users review small prototypes of system elements. Systems developers receive feedback on the prototypes, which they use to improve it as the system moves toward final implementation.
- Incremental. The system is broken into pieces during the development process; the systems development life cycle is applied to each piece, eventually resulting in a complete systems design. The pieces may be functionally based (e.g., accounts payable, accounts receivable), technology based (e.g., spreadsheet elements, relational database elements) or conceived in some other way.
- Spiral. Like the preceding items in the list, the spiral approach deconstructs the system. Each element of the system goes through a spiral of four activities: determine objectives, alternatives and constraints; evaluate alternatives, including risk identification and resolution; develop and verify deliverables; plan the next iteration.
- Rapid Application Development (RAD). As the name implies, RAD focuses on delivering a high-quality system in a relatively short time at low cost. It therefore relies heavily on IT system development tools, such as graphical user interfaces and computer aided software engineering. This approach usually involves some elements of prototyping as well.
Arguably, the oldest and most recognized approach for systems development is the systems development life cycle (SDLC), sometimes referred to as the “waterfall” approach. Depending on the source you consult, the SDLC comprises anywhere from five to ten steps. The basic tasks are the same, but different authors aggregate / disaggregate some of the steps.
O’Brien and Marakas (2011) describe the SDLC in five phases, each yielding a specific deliverable:
- Systems investigation (yielding a feasibility study)
- Systems analysis (yielding functional requirements)
- Systems design (yielding system specifications)
- Systems implementation (yielding an operational system)
- Systems maintenance (yielding an improved system)
Although the SDLC is presented in a very linear fashion, and ideally operates the same way, very few systems development projects are able to go through the steps linearly. In the next section of this article, we’ll look in more detail at the steps in the SDLC.
The first phase of the SDLC, investigation, is about recognizing an unmet need and developing a very preliminary idea for how to meet the need. The proposed project will usually need an organizational “champion,” who is responsible for doing some background research and proposing the idea through whatever mechanism the organization has in place. After the initial idea is proposed, a team conducts a feasibility study. Feasibility studies commonly look at three broad sets of issues: market, organizational / technical, and financial. The feasibility study should be conducted as objectively as possible. I recall one organization I worked with that hired a consultant to do a feasibility study for a service his company provided; not surprisingly, the results showed that the project was entirely feasible—provided his firm was hired to do it!
If the project is feasible, it can proceed to the second step of the SDLC: systems analysis. While the investigation phase sets some high-level goals for the system, the systems analysis phase makes those goals more detailed. The design team should do a complete requirements analysis, collecting data from a broad cross-section of people expected to interact with the completed system. Data for the requirements analysis should be gathered in multiple ways whenever possible: surveys, observation, one-on-one interviews, focus groups and the like.
With the functional requirements in hand, the team embarks on the third step: systems design. During this phase, actual development work begins. The team may prepare various conceptual views of the system via flowcharts, data flow diagrams, entity-relationship models or other documentation techniques. In this phase, the system is “fleshed out” in even greater detail: screen layouts, business rules, database schemas, software tools, forms and other documents. The designed components should be validated with users / prospective users of the system to ensure that they conform to the requirements developed during systems analysis.
After everything has been designed, implementation can begin. Actual software selections are made; computer code is written. The databases are constructed. Implementation can follow one of several approaches. In a direct cutover implementation, the old system is taken down and the new system put up in its entirety, usually over a weekend or some other period of light activity in the organization. The organization may conduct a parallel implementation, in which the old and new systems are run side-by-side for a time; parallel implementation allows an organization to “work out the kinks” in a new system, while still allowing employees to fall back on the old system if the need arises. Phased or modular implementation rolls out the new system in pieces. For example, when the California State University implemented its Common Management System (CMS) using PeopleSoft, half the campuses pilot tested the system for a year before it was implemented throughout the state. Training and documentation are also important parts of the implementation process. An organization can develop the most effective, efficient system in the world, but it could be rendered useless if no-one understands how to operate it.
In today’s rapidly changing business environment, an organization’s information systems cannot stand still. Or, as Will Rogers once put it: “You may be on the right track. But you will get run over if you just sit there.” The last step in the SDLC is maintenance. Maintenance allows the organization to fine tune and revise the system over time, ensuring that it remains relevant and responsive to user needs. Sadly, the maintenance phase is often seriously neglected as part of the SDLC, leaving the organization dissatisfied in the long run.
How would the SDLC be applied to an actual case? For the 2nd edition of my accounting information systems textbook (see the references), I worked with a group of students from my university’s computer information systems program to design an online test-generation site (www.hurtaistext.com). Let’s look at how the SDLC phases manifested in that project.
- Investigation. The project began at the beginning of the term when students formed their own teams. They each listened to a series of presentations from potential clients about the various projects available. The teams evaluated the preliminary project requirements as described in the presentations against their own skills and interests; each project team was then matched with a client for the duration of the term. Because more projects were available than teams, some projects proceeded no further than this phase.
- Analysis. The team and I had several conversations about the requirements for the software I wanted them to design. For example, it had to be easy to learn and easy to use. It had to have a graphical user interface. It needed sufficient security provisions to guard against unauthorized access. It had to be able to accommodate various question types, and to allow users to combine various question types into a single exam. It also had to be capable of producing two versions of each exam: one with the answers and one without the answers.
- Design. During the design phase, the team started constructing the software. We used GoDaddy.com to establish a domain name for the site; the students used Word files to input the questions into the database they had constructed. True to the iterative nature of the SDLC, we often had to return to analysis tasks as questions arose during the design process.
- Implementation. It took the student team about eight weeks to design the system before it was ready to be implemented. The web site “went live” and users learned about the system through the publisher. Users began signing up for the web site; I gave them access after verifying their identities. As of this writing, the site has over 40 users.
- Maintenance. Ideally, the systems development team would also be in charge of maintaining the system. In this case, however, maintenance falls to me due to the transitory nature of the team. Maintenance tasks include processing new registrations, updating the questions and figures in the bank and responding to user queries about how to use the system.
I hope that short description helps you see how the SDLC is actually used to design and implement an information system. Now, let’s look at how the SDLC is related to ERP systems.
Although both research and experience have shown that ERP cannot be thought of as “just another IT project,” the SDLC can be used as a basic approach for such a project.
ERP Solutions uses a five-step approach to implement an ERP system for its clients. The five steps have different names, but the tasks are fundamentally the same. Here’s their process:
- Education. Many executives think they want / need an ERP system, but have little knowledge about the issues and process involved. The education phase, then, parallels “investigation” in the SDLC. It can also phase into “analysis” if the education process leads to the development of preliminary systems requirements.
- Software selection. Very few organizations design an ERP system “from scratch.” Good products are available and can be adapted to virtually any organizational context. Based on the size and nature of the organization, the ERP project budget, the willingness and capabilities of the organization’s employees, software selection focuses on the analysis and design phases of the SDLC.
- Network / virtualization. ERP systems have specific requirements when it comes to hardware, networks and other technical issues. This phase continues design activities, focusing on hardware and networking requirements.
- Implementation. The project proceeds next to implementation. In a perfect world, implementations are accomplished with no glitches—sadly, the complexities and idiosyncrasies of real organizations usually mean that issues will need to be resolved once the system is implemented.
- Assessment / review. The ERP Solutions web site describes this phase as follows: “Harness the power of analytics to help you survive and thrive in these challenging times. ERP Solutions helps you optimize your information system so that you and your company can rely on a more predictive information strategy that enables intelligent decision making. Our methods and capabilities help you develop predictive metrics and optimization business process through your new or existing system to create new solutions for your specific challenges. Discover what predictive insights you have and turn them into operational reality and narrow the gap between strategy, execution and return on investment.” The tasks accomplished in this phase closely parallel the SDLC’s “maintenance” step.
I hope you’ve enjoyed this series of articles and that they have given you some useful advice for your organization. Please contact me if you’d like to discuss any of the topics in greater depth.
- Centers for Medicare and Medicaid Services. Selecting a Development Approach. Retrieved 10 December 2010 from https://www.cms.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdf.
- Hurt, R. L. Accounting Information Systems: Basic Concepts and Current Issues (2nd edition). McGraw-Hill / Irwin, 2010. www.mhhe.com/hurt2e.
- O’Brien, J. and G. Marakas. Management Information Systems (10th edition). McGraw-Hill / Irwin, 2011.