Information systems technology is vital a successful business enterprise in today’s world. Timely and complete information is required to make good business decisions and to implement profitable business and marketing strategies. This requires the system that gathers the information to be as sophisticated and through as possible. Defining that system in terms of its requirements (what the system must do) and specifications (how the system will meet its requirements) are the first, and probably most important, steps in building a quality system. (Stotz, 2007)
The first step in decided which information system to use is ironically enough, gathering information on the information you will need and the ways the information must be manipulated. The analyst must become an expert in the business area the system will support. (Satzinger, Jackson, & Burd, 2004) A human resources director will need the basic information of each employee, such as the employee’s position, salary, and W-4 information. In addition, a human resources file should contain a copy of the employee’s resume and any training the employee has received from the company. The file should also contain any recommendations, commendations, awards, complaints, and reprimands the employee has received. Additional information that would be useful is any special needs the employee has, such as ADA accommodations and work restrictions, and any other useful information, such as additional languages the employee may speak. And of course, payroll information should be part of the HR file. If a company has multiple locations (as Riordan Manufacturing does), it is important to note which location and department an employee is located and who their direct supervisor is. In the case of companies like Riordan Manufacturing, which spans multiple countries, it is vital to note how this affects payroll and job descriptions.
The easiest way to gather this information is simply to ask the employee and confirm the information with the employee’s supervisor(s). All information gathered must be easily updatable by the employee, the employee’s supervisors, and the HR officers. The employee should also be able to add some notes to their file, such as a desire to be considered for certain types of training. For the employee’s benefit, a copy of the employee’s job description, job specifications. “Job analysis is the foundation for forecasting the need for human resources as well as for plans for such activities as training, transfer, or promotion.” (Casico, 2002, p161) The HR coordinator should help determine what sort of trending must be done to determine what hiring, training, and promoting needs the company is going to have.
Once the necessary information is gathered, it then becomes pertinent to determine how the information should be recorded and stored. There are many options for how the HR database should function, such as how the fields affect each other and what priority is given to the fields. Care must also be taken to ensure that certain fields cannot be accessed and/or altered by unauthorized individuals. Security is vital in a human resources system.
The information may have to interact with other systems. As an example, in some retail businesses, receiving a customer compliment provides the employee with a small monetary bonus, thus the HR file should be tied to the payroll system. If the retail system also operates on a commission basis, it may be necessary to tie the HR system into the transaction system. However, in many cases, the ties may only be a certain field in the database.
Creating an interactive database can be a daunting task. Care must be taken to ensure no data is lost in either the HR database or the database interacted with by the HR database. A search engine should be built into the database to ensure information can be found quickly. In addition, a method must exist to quickly and efficiently create reports with all the information needed for specific tasks. A plan must also be crafted and implemented for backing up the HR database and securing the backup copies.
The first step after creating the database is creating an interface with which to enter data into the database. The interface must provide for all the necessary information to be entered, either manually or by scanning documents. This could also be the longest portion of the process, as the necessary information could be scattered in various locations or require interviews of multiple individuals. This is also the most resource heavy portion of the project, and it is vital to ensure that adequate personnel and resources are available for the project to succeed. (Perkins, 2007).
Once the information is entered, it remains only to craft the proper reporting tools and ensure the security and updatability of the interface. If you have properly analyzed the company’s needs and ensured the system meets the company’s requirements, all that remains is to train people on how to use the system, fix the bugs, correct employee errors, repair damaged files, keep the system backed up, and plug the server back in as needed.
Upon competition of the analysis phase, the design process can begin. The first step is to specify in detail how the various parts of the system will communicate with each other throughout the organization. The level of automation must also be considered, and how each activity is actually carried out by the end-users and the computer. The different levels of access must be planned, such as top level, HR level, payroll level, supervisor level, and employee level, and it must be specified how each level of user interacts with the system. A plan must cover how the system will work with other systems both inside and outside of the organization. It must also be determined how and where the system will store all of the information required by the organization. (Shelly, Cashman, & Rosenblatt, 2004)
A few needs are immediately obvious when it comes to deciding what sort of database to utilize. The database must reside on a central server in order that it can be accessed by all of the company’s locations. However, a field must be present so that a company can also access only the sales through it’s particular locale. The database should also be designed so that new fields are easily added so that changes can be made incrementally, rather than having a change to the management structure of the company require a complete rework of the HR system. (Changing the Paradigm of Software Engineering, 2006)
When designing a new bit of software, it is vital to ensure those involved know the schedule for completion and are provided with dates and what is required of them by those dates. (Chen, 2006). The information required to be input into the database must be ready when the database is completed and awaiting input.
It is important to make a model that will specify how the system activities will actually function. In the case of the HR program, when a new applicant is reviewed, the HR coordinator inputs the applicant’s information into the computer, along with proposed starting date, pay, and position. Once the position is input, the HR coordinator should be able to print off a job specification for the applicant based on that job title, and be able to make a note in the system that the applicant has reviewed the specification and is agreeable to all the job entails. At this point, the applicant’s data should be accessible by the individual in charge of hiring, and it should be possible to print off reports of all the applicants in order that they can be compared and reviewed. The report should include all necessary information to determine if the applicant meets all the requirements of the position. Reports should be customizable by those with higher level access and they should be able to save customized reports to prevent it from becoming necessary to add in additional functions at a later date.
It is important to keep a list of applicants available, as a company never knows when a position could open up that an applicant would fit in perfectly. It is also useful for future trending to note what qualifications a typical applicant possesses when for future hiring standards.
Once an applicant becomes an employee, others will need to access areas of the employee’s information. The HR coordinator will need to keep track of training completed and proposed and benefits the employee is eligible for. The supervisor will need to enter in possible firing criteria such as habitual tardiness, failures to complete job specifications, and co-worker issues that may arise. The employee will also need access to update information such as address, telephone number, and perhaps apply for job-openings in-house.
The information should be processed and possibly filtered in certain cases. As an example, if a supervisor enters a negative about the employee, the HR coordinator or someone with top level access should be able to review the negative and possibly remove it if they deem it unworthy. Each level of access should have the ability to overwrite the access of the level under it, but the reverse should not hold true. The only exception should be the employee’s ability to update contact information. If the company has multiple locations, it should have two top levels, one for the store, and one for the entire company. More top levels may be required if the organization is also divided into regions and/or districts.
The interface for each level can be very basic. A simple form containing dialog boxes is sufficient for the purpose of the HR program, though care should be taken to ensure the interface is legible and can be navigated easily. For navigational ease, the interface should be point-and-click rather than require dialog boxes be tabbed through or selected via a numerical system.
For security purposes, the HR database should be accessible only from the job site at all levels except top. Database controls should be placed to protect data from unauthorized access and to record all attempts at access and changed made. The system should also be automatically backed up to a secure location. The lower levels of access should be prohibited from accessing information in locations other than their own, should the company have multiple offices.
Once the blueprints for the system are complete, it is time to actually develop the software and begin the coding phase. Program development (including unit testing) typically accounts for at least one-third of all development labor. Program development also accounts for between one-third and one-half of the project development schedule. The magnitude of resources and time consumed during program development clearly warrants careful planning and management attention. (Shelly, Cashman, & Rosenblatt, 2004)
There are a variety of ways to order the implementation of the project, including ‘input, process, output’, ‘top-down’, and ‘bottom-up’. Most projects adapt the order to their needs or use a combination of approaches depending on their needs and any constraints they may be under.
Input, Process, Output development order, or IPO, is based on how the data flows through the system. External input processes, such as a data entry interface, are developed first. The part of the program that processes the input is developed second, and then the part of the program that produces the output is developed last. It is important to have a very clear system flowchart so that various modules can be classified as ‘input’, ‘process’, or ‘output’ and be developed accordingly. It is important to properly analyze dependency within the system. The major advantage of IPO is it simplifies the testing phase. The early developed input modules can be used to enter the test data, reducing the need for special purpose testing programs. And since user interfaces are more likely to require change during development, creating them in the beginning allows for early testing and evaluation. The disadvantage of IPO is the late implementation of the output processes means a greater likelihood of errors in the output devices, such a simple formatting problems in printed reports. (Shelly, Cashman, & Rosenblatt, 2004)
Top-down development begins with the module at the top of the structure chart. Bottom-up development begins with the set of modules at the lowest level of the structure chart. (Shelly, Cashman, & Rosenblatt, 2004) Both have their roots in the more traditional design and programming structure. Again, the key issue is to properly analyze dependency within the system and thus a very clear system flowchart is needed. The primary advantage of top-down development is that from the beginning, there is always a working version of the program. The disadvantage is that it doesn’t use resources very efficiently at the start. Bottom-up is the opposite, using resources efficiently but lacking an integrated, working system until the final phases.
Which sort of development team is utilized depends upon how the company is structured. A cooperating peer team has members if approximately equal skills and experience whose areas of specialization overlap. A chief developer team is a team with a single leader in charge of making all important decisions. A collaborative specialist team has members with a wide variation in skills and experience with minimal overlap. Keep in mind the basic rules behind the formation of teams, such as ensuring the team is neither to large nor to small and that the team is properly matched to the task. The teams should have technical reviews and insure they meet quality assurance guidelines in development.
Construction and testing are interdependent, and it is best to have a formal plan created before beginning these phases. Testing components individually is called unit testing. Testing components in groups is called integration testing. Testing entire systems is called system testing. A test case is a formal description of a starting state, one or more events to which the software must respond, and the expected response or ending state. Test data is a set of starting states and events used to test a module, group of modules, or entire system. (Shelly, Cashman, & Rosenblatt, 2004) All instructions in each and every module must be executed at least once, which can be a very tedious and time-consuming process. Keep in mind that every system will have errors, it is simply impossible to write a complex bit of programming without a logical error.
Once a program is developed and tested and a working version prepared, it is time to begin the installation phase. In a direct installation, the new system is installed and configured quickly into becoming completely operational, and then any overlapping old systems are terminated. They run concurrently for a very short time. The primary advantage of direct installation is it is simple and fast. Since there is no parallel operation, there are fewer logistical issues and resources. However, direct installation has it’s risks, without parallel operation, there is no backup should the new system fail.
In a parallel installation, the systems are run concurrently. These does utilize more resources, but has the advantage of giving additional time for testing while having the old system serve as a backup system. This mitigates any negative consequences should the new system fail. While a parallel installation may cause a substantial increase in the operating cost, it could potentially save the company any losses that could result from down time.
In a phased installation, the system is brought to operational in a series of steps. It can be combined with direct or parallel installation. While it is a more complicated process, it does substantially reduce risk in large, complex systems that have relatively independent subsystems.
It is important to have adequate personnel during installation, as the installation process is very demanding and recourse heavy.
During all of the above steps, documentation should have been being prepared. The documentation should provide information to the users on how to utilize and maintain the system. Documentation should include both a manual and any necessary comments within the code itself. System documentation contains descriptions of the systems functions, architecture, and construction details. Comments within the code itself are an example of system documentation. User documentation is the manual for how to interact with and maintain the system. System documentation must be actively managed to remain effective. It must be stored in an accessible location and form, retrieved when necessary for maintenance changes, and updated once changes have been implemented. (Shelly, Cashman, & Rosenblatt, 2004)
Without documentation, it can be nearly impossible to manage the training and support phases. Should the system documents be inadequately maintained, the value of the entire system could be compromised. What good is a system if no one knows how to use or repair it? Good documentation can reduce training needs and support requests. However, training and support are always needed, as users are a part of the system as well. Leaving users to master the program on their own increases error rates and causes the system to operate far below peak efficiency. Training allows users to be productive from the first moment the system is operational. Both end users and system operators must be properly trained to achieve the system’s purpose and to keep the system properly maintained.
Keep in mind the importance of structure when designing a program. A good systems analysis allows for a productive design phase, which allows a new system to be implemented and brought to it’s full potential quickly and efficiently. Ensuring a proper plan from the beginning eliminates wasted recourses and can prevent costly errors.
Casico, Wayne F. (2002). Managing Human Resources (6h ed.). , : The McGraw Hill Companies.
Changing the Paradigm of Software Engineering. (2006, August). Communications of the ACM, Retrieved July 18, 2008, from Academic Search Complete database.
Chen, A. (2006, February 27). RFPs: Quality Counts. eWeek, 23(9), 75-79. Retrieved July 18, 2008, from Academic Search Complete database.
Perkins, B. (2007, March 12). 12 things you know about projects but choose to ignore. Computerworld, 41(11), 34.
Riordan Manufacturing. (2006). Riordan Manufacturing Home. Retrieved July 12, 2008, from https://ecampus.phoenix.edu/secure/aapd/CIST/VOP/Business/Riordan/RioMfgHome002.htm
Satzinger, John W., Jackson, Robert B., & Burd, Stephen D. (2004). Systems Analysis and Design in a Changing World (3th ed.). Boston: Thomson Course Technology.
Shelly, Gary B., Cashman, Thomas J., & Rosenblatt, Harry J. (2004). Systems Analysis and Design in a Changing World (5th ed.). Boston: Thomson Course Technology.
Stotz, R. W. (2007, November). System definition: Defining the intended use for a system. Journal of Validation Technology, 14(1), 54.
© 2010, Within this mind. All rights reserved.