As this article is Systems Analysis for business IT instead of looking at a car we look at a business and instead of studying gear boxes and engines we study staff and IT.
In this article we will try to give an introduction to some of the concepts of systems analysis that you may encounter in a small business, more specifically we will be looking at how IT is used within a small business. In total we are going to touch on analysis of a current system, the design of a new system, the move to the new system and the shutting down of the old system.
System analysis
The first stage is to study the business as it currently exists, the key concept is to understand how the business works as it is no good designing a system if it doesn't meet the needs of the end user. The are numerous methods of getting this information and the starting point will probably be a meeting with whoever manages the business. When you meet with a client it is probable that they will have some ideas about what they want the new system to be capable of, however it is not a good idea to design a system based solely on this as it probably won't take into account the needs of the people who will actually be using the system and may be focused on new features at the expense of older features that are in fact business critical (which means the business will struggle to function).
This "requirements analysis" takes place before any designs are made, so that all the functions of a business are identified. This is probably best achieved in a small business by shadowing members of staff for a few days or weeks and identifying all the tasks each member of staff has to do and the way in which they carry them out. This process can be very time consuming, however, time spent studying how a business works can save endless problems caused by a system that does not carry out tasks that staff regularly do and can allow the design of a new system to take into account end user behaviour.
To give an example, if you have been asked to create a database, you should get a copy of all the records the business currently keeps and then make notes on what information members of staff require on a day to day basis. Using these two bits of information can help you design a system that contains all the information the business needs and also give priority to day to day tasks over other tasks which happen infrequently.
So why is this all so important? Well the truth is, it is very difficult to find out what a business needs and you may well find yourself very frustrated:
- People don't fully understand what they want and/or need.
- People don't understand that what they want isn't always what they need.
- People find it difficult to commit to a system design.
- People will probably ask for things to be added after a cost and deadline have been set.
- People won't understand what you are trying to do.
- People don't understand IT and really don't understand new IT.
Therefore it is up to the system analyst to understand what a business needs.
System Design
Once all the system's requirements are understood the next stage is the design of the new system.
The first part of the design stage is to work out solutions for the problems put forth in the systems analysis; it is no good picking a software language if you don't know what you have to write. It is in this stage you really see the importance of good systems analysis, the designer should have a series of user needs that they can use to mould their system.
For example, your design specification may ask for an on-line diary but it is only through proper systems analysis that you can determine how the users will actually use the diary. You might normally write a diary so that only the person who enters a date in the diary can edit it. However, if from the system analysis you find out that the diary is mainly used not by the person who enters the date but by their secretary, you will need to plan the design accordingly.
This may seem like common sense but because the people who develop the software are not in direct contact with the end users, they are reliant on a good systems analysis since the programmer's assumption may not meet practical day to day needs.
It is also important to note that you may not actually be designing the software youself, indeed your job as an analyst may be to pick "off the shelf" software packages that best suit your system requirements and budget. This can often be problematic as many software packages don't work together as smoothly as you would like. You also may wish for the new system to work with computers and software a business already owns. This can also be problematic as both the computers and existing software may be out of date and difficult or even impossible to upgrade.
Rather than buying an existing software package you may be using your systems analysis findings to write a specification that you will then submit to an external developer. This will have the benefit of being a tailor made IT solution but will probably be more expensive.
If you are designing the system “in house”, the seperation between systems analysis and system design becomes blurred, with the intergration of both processes. On a smaller scale, the combined analyst and developer may well be thinking ahead to the design during the analysis stage.
Many methods exist that aim to aid systems analysis and design, most of them are too complex to go into here, so we will just mention a few concepts that you may wish to study if this is an area that interests you. One concept you may find of use is prototyping. Prototyping is where you mock up a model of the final system to see how the end users respond. Prototyping can be considered to be rather like interactive storyboards, not an actual working system but a model that allows the end user and client to provide feedback. You may also wish to investigate the use of UML "use case" diagrams. These can be very useful as they can help organise systems analysis, something that is particularly important if you need to transfer information between people, either in a meeting with a client or between developers and analysts.
Development and Implementation
From the design a system is developed, this will be tested by the developers as they build it (alpha testing) but an important part of testing is getting the end users to try out the software (beta testing). Beta testing holds a twofold importance, not only does it test that the developed software is (mostly) bug free, it also gives you the chance to slowly introduce the new system to the end users.
The move to a new system is an important step, you can't simply get the new system running overnight and expect people to come in the next morning and start working on it. People dislike change, most users of a system will have only learnt enough of the system to carry out what they need to do and will hate having to use a new system. It is a very important task to sell the new system to the end users. Part of this selling of the new system will take place as training, training the end user allows you to point out all the flaws of the old system, give them the skill they need to use the new system and prepare them for the switch over.
Rather than just setting a switch-over date and changing systems then, it is probably best to run both systems for a short period, this will allow for a smother transfer and allow for a fast change back in case the unthinkable happens and the new system is incapable of doing the job it was designed to do. This running of two systems will increase the workload with many people having to do extra work. Many people will also be tempted to continue using the old system when they should be using the new system, so it is probably best if this period is kept to a minimum, however the old system should ideally remain in place for a longer period in case of unforeseen problems. If at all possible the new system should be able to interact with the old system at some level, allowing for the transfer of data between systems in case a problem occurs.