Specifying, choosing and implementing computer systems
The Procedures Manual is at the core of the ideas outlined in this book. I believe it helped the team I worked in implement Oracle Financials General Ledger with very few problems. The Procedures Manual details all of the tasks required to produce the desired output. With most systems implementations it is written just before (or after) the system is implemented with the reasoning that you can’t write a detailed procedures manual until you have established the detailed procedures!
However, I worked on the principle that you have bought the system and therefore there is no point in spending time analysing it and trying to fit it into your existing systems. You start with the system you have purchased and build out from that. This is done by linking the input screens to the tasks you have identified, changing these as necessary. The procedures manual is then written around each task. By writing the procedures manual as part of the design process forces out the issues early in the implementation. As you may know, when it comes to systems implementation, ‘The devil is in the detail’.
The manual is split into discrete sections, one for each task. Each section has pages detailing the work required to: input data; process data around input screens; or produce output. Sections involving complex operations may have an introduction with a flow chart. Each section is cross referenced to others, for example when a process (such as receiving invoices) feeds into another (input of those invoices). Users only need access to parts of the manual which affect their responsibilities.
There is a problem: people don’t read manuals. The solutions:
o Make it worthwhile the users to use it. So use it in systems design, user acceptance testing, training before ‘go live’, and training for new staff when the system is in operation (induction training).
o Only provide parts of the manual relevant to the user’s job. (This is the reason for splitting the manual into tasks).
o Divide the manual in such a way as to make it easily accessible.
o Ensure the users using the manual approve their parts, as part of user acceptance testing.
This manual is distinct from any manual (or help screens) produced by the vendor which relates to how the software is used.
As each section of the manual is completed, it is discussed in a meeting with those users directly affected in order to ensure it is complete, accurate and understandable.
The manual needs to be written by someone very familiar with the software and users’ requirements.
Where the system is being developed ‘in house’, the manual could be written alongside (or even before) programming commenced. It would then form the basis for database structure and program design.
The manual starts with a summary of activities and tasks which are referenced to the detailed sections
Sections of the manual which relate to input screens only used during initial set-
It forces consideration of most (if not all) of the detail early in the implementation. So, hopefully, no late surprises requiring last minute changes.
It should not be necessary to document existing systems in detail.
It gives the users an early opportunity to check that their requirements are being fulfilled.
Processes can’t be forgotten (for example, who’s going to provide foreign currency rates?).
The relevant sections of the manual can be used as a basis for user acceptance testing, which not only tests whether the system works as expected but that the manual is correct.
In training, the relevant sections of the manual can be given to the user with examples of the documentation used for input (invoices, overtime worked, stock dispatched). This makes the user familiar with the manual, is efficient (no separate training manual) and checks the correctness of the manual.
It provides an opportunity to address the ‘Problems, issues and requirements’ noted in the database.
The procedures manual is available on the ‘go live’ date.
There will be many input screens, some being used only during implementation. So it is useful to group them:
Setup screens: Only used to set up the system. They can define the structure of the database and are therefore unlikely to be used after setup. Only a few senior users need access. Examples include: account code structure.
Infrequent standing data changes. Rarely used and possibly having major significance. Only a few senior users need access. Examples include: the accounting calendar; tax rates; new currencies, new stock locations, new departments. (‘Standing data’ is used to allocate transaction data (by customer, for example) or for calculations (foreign exchange rates)).
Regular standing data changes. Updated, usually monthly. Access will vary with responsibilities. Examples include: currency rates.
Frequent standing data changes. Occur often and when required. Access will vary with responsibilities. Examples include: new customers; new suppliers (vendors): new stock items.
Transaction data. Usually daily input and high volume. May also come from electronic transfers. Examples include: orders; invoices; stock movement; cash received; time worked.
Output. Reports, usually on screen but can be printed, which are pre-
While grouping the input screens in this way is not essential, it does assist understanding the system and aids linking the screens with the task(s)
The tasks (SS 2-
Each task has a section in the manual.
Each task is linked to the job(s) responsible for completing it.
Tasks are not split between jobs. This is to ensure that when a user is given the section(s) of the manual relevant to their job, no other user is responsible for carrying out any part of the task. Thus one user can focus on the whole task. Note that one task can be carried out by several users. For example a shop sale can be carried out by any of the shop staff, but the task only needs one of the shop staff to complete it.
Tasks involving several screens will have an introduction.
Each input screen has a page(s) in the section of the manual.
The document should anticipate the risks arising from incomplete or inaccurate data and cover suitable management, for example edit checks.
Every field in every input screen therefore has instructions concerning the source of the data to be input.
Example documents are provided in the manual (Section C).
The setting up of this document as soon as the system is purchased forces out issues early on in the implementation. For example:
Who will input into each screen?
If a screen has only one user, what happens if they are unavailable?
Where does the data come from which is required to complete this field?
What happens if the standing data necessary in a drop down list is not present?
Which VAT option do I choose?
Where input is manual (that is input into a screen from a document or bar-
Sorting the mail.
Banking of cash and cheques (checks).
Receiving of goods by the store.
Processing customer returns.
The basis of this methodology is that these procedures are driven by the input (or output) screens not by ‘what we do at the moment’. This should ensure maximum efficiency and eliminate the need to document the existing systems in detail. (It might be beneficial to document existing systems at a high level prior to purchase/design to ensure all users and output is identified).
As with input, each process should be documented by individual task such that it covers one job holder’s responsibilities (although there may be more than one person doing that job, for example check-
As part of documenting the procedures you will need to consider the risks which threaten the objectives of each procedure and the ways of managing them. For example the risk that you take payment from a fraudulent credit card threatens your objective of maintaining profits. You might manage this by checking the address the goods are sent to agrees to the address of the card holder.
While some output (especially electronic output) will be generated automatically from batch programs, most output will be produced from screens, either as a result of queries or from standard reports chosen from a menu.
The documentation has a form similar to that used for input.
Where reports are required on a regular basis (daily, weekly, monthly), a check-