As stated above,accounting information systems are composed of six main components: - People: users who operate on the systems
- Procedures and instructions: processes involved in collecting, managing and storing the data
- Data: data that is related to the organization and its business processes
- Software: application that processes the data
- Information technology infrastructure: the actual physical devices and systems that allows the AIS to operate and perform its functions
- Internal controls and security measures: what is implemented to safeguard the data
When an AIS is initially implemented or converted from an existing system, organizations sometimes make the mistake of not considering each of these six components and treating them equally in the implementation process. This results in a system being "built 3 times" rather than once because the initial system is not designed to meet the needs of the organization, the organization then tries to get the system to work, and ultimately, the organization begins again, following the appropriate process.
Following a proven process that works, as follows, results in optimal deployment time, the least amount of frustration, and overall success. Most organizations, even larger ones, hire outside consultants, either from the software publisher or consultants who understand the organization and who work to help the organization select and implement the ideal configuration, taking all components into consideration. Certified Public Accountants (CPAs) with careers dedicated to information systems work with small and large companies to implement accounting information systems that follow a proven process. Many of these CPAs also hold a certificate that is awarded by the American Institute of CPAs--the Certified Information Technology Professional (CITP). CITPs often serve as co-project managers with an organization's project manager representing the information technology department. In smaller organizations, a co-project manager may be an outsourced information technology specialist who manages the implementation of the information technology infrastructure. The steps necessary to implement a successful accounting information system are as follows:
Detailed Requirements Analysis where all individuals involved in the system are interviewed. The current system is thoroughly understood, including problems, and complete documentation of the current system—transactions, reports, and questions that need to be answered are gathered. What the users need that is not in the current system is outlined and documented. Users include everyone, from top management to data entry. The requirements analysis not only provides the developer with the specific needs, it also helps users accept the change. Users who have the opportunity to ask questions and provide input are much more confident and receptive of the change, than those who sit back and don't express their concerns.
Systems Design (synthesis)—The analysis is thoroughly reviewed and a new system is created. The system that surrounds the system is often the most important. What data needs to go into the system and how is this going to be handled? What information needs to come out of the system, and how is it going to be formatted? If we know what needs to come out, we know what we need to put into the system, and the program we select will need to appropriately handle the process. The system is built with control files, sample master records, and the ability to perform processes on a test basis. The system is designed to include appropriate internal controls and to provide management with the information needed to make decisions. It is a goal of an accounting information system to provide information that is relevant, meaningful, reliable, useful, and current. To achieve this, the system is designed so that transactions are entered as the occur (either manually or electronically) and information is immediately available on-line for management to use.
Once the system is designed, an RFP is created detailing the requirements and fundamental design. Vendors are asked to respond to the proposal and to provide demonstrations of the product and to specifically respond to the needs of the organization. Ideally, the vendor will input control files, sample master records, and be able to show how various transactions are processed that result in the information that management needs to make decisions. An RFP for the information technology infrastructure follows the selection of the software product because the software product generally has specific requirements for infrastructure. Sometimes, the software and the infrastructure is selected from the same vendor. If not, the organization must ensure that both vendors will work together without "pointing fingers" when there is an issue with either the software or the infrastructure.
Documentation—As the system is being designed, it is documented. The documentation includes vendor documentation of the system and, more importantly, the procedures, or detailed instructions that help users handle each process specific to the organization. Most documentation and procedures are on-line and it is helpful if organizations can add to the help instructions provided by the software vendor. Documentation and procedures tend to be an afterthought, but is the insurance policy and the tool that is used during testing and training—prior to launch. The documentation is tested during the training so that when the system is launched, there is no question that it works and that the users are confident with the change.
Testing—Prior to launch, all processes are tested from input through output, using the documentation as a tool to ensure that all processes are thoroughly documented and that users can easily follow the procedures so that you know it works and that the procedures will be followed consistently by all users. The reports are reviewed and verified, so that there’s not a garbage in-garbage out. This is all done in a test system not yet fully populated with live data. Unfortunately, most organizations launch systems prior to thorough testing, adding to the end-user frustration when processes don't work. The documentation and procedures may be modified during this process. All identified transactions must be tested during this step in the process. All reports and on-line information must be verified and traced through the "audit trail" so that management is ensured that transactions will be handled consistently and that the information can be relied upon to make decisions.
Training—Prior to launch, all users need to be trained, with procedures. This means, a trainer using the procedures to show each end user how to handle a procedures. The procedures often need to be updated during training as users describe their unique circumstances and the "design" is modified with this additional information. The end user then performs the procedure with the trainer and the documentation. The end user then performs the procedure with the documentation alone. The end-user is then on his or her own with the support, either in person or by phone, of the trainer or other support person. This is prior to data conversion.
Data Conversion—Tools are developed to convert the data from the current system (which was documented in the requirements analysis) to the new system. The data is mapped from one system to the other and data files are created that will work with the tools that are developed. The conversion is thoroughly tested and verified prior to final conversion. Of course, there’s a backup so that it can be restarted, if necessary.
Launch—The system is implemented only AFTER all of the above is completed. The entire organization is aware of the launch date. Ideally, the current system is retained and oftentimes run in "parallel" until the new system is in full operation and deemed to be working properly. With the current "mass-market" software used by thousands of companies and fundamentally proven to work, the "parallel" run that is mandatory with software tailor-made to a company is generally not done. This is only true, however, when the above process is followed and the system is thoroughly documented and tested and users are trained PRIOR to launch.
Support—The end-users and managers have ongoing support available at all times. System upgrades follow a similar process and all users are thoroughly appraised of changes, upgraded in an efficient manner, and trained.
Many organizations chose to limit the amount of time and money spent on the analysis, design, documentation, and training, and move right into software selection and implementation. It is a proven fact that if a detailed requirements analysis is performed with adequate time being spent on the analysis, that the implementation and ongoing support will be minimal. Organizations who skip the steps necessary to ensure the system meets the needs of the organization are often left with frustrated end users, costly support, and information that is not current or correct. Worse yet, these organizations build the system 3 times instead of once.
