Customised reporting

Most larger organisations have some need for customised reporting on training.

You can:

• Buy in a proprietary brand tool and adapt it (if the software allows it)
• Contract a specialist company to create a database interface that gives you the reports you want
• Contract someone like ourselves to create that database and interface from scratch

Plan, plan, plan

Reports are limited by the information that is captured within the database. If planning is not thorough prior to building the database you may get into a situation where you find vital pieces of the full picture have not been captured.

Alterations to the database tables and the code that writes to the database, can throw up huge errors if they are done after the database system has gone live. So plan, plan and plan again until you are sure you have captured everything you need.

Then you can decide whether you have to check data before it is saved (so as to ensure the information that is stored complies with your reporting needs and will not throw up errors). A good database designer understands the importance of this 'data integrity', along with a range of other issues and will ask a lot of questions prior to starting any work.

Talk, talk, talk

Beware the database designer who says: 'Yes, yes, I understand,' and then you do not see her or him for weeks. You need to be involved in the process to make sure the designer really does understand what you want. You may not need some of the refinements the designer builds in so you would be paying for redundant functions.

Database designers think differently from you and me. When we say: 'All I want is a simple ….' the designer is going into hyperventilation. It is an accepted fact that what appears simple to the end-user is often a complicated coding problem for the designer, and vice versa.

To avoid any misunderstandings:

• Discuss your ideas and have the designer describe to you in simple language what he/she will do to make it happen
• Repeat what they have told you in your own words and write it down
• Draw diagrams and links so that you all come to the same understanding about the expectations of users, administration staff and the database designer
• Paint scenarios like: 'So I am the training administrator and I want to find out .... How would I do that?'
• Email what you believe has been agreed on to the designer and ask them to immediately confirm that your understanding is correct
• Don't make assumptions - ask every inane question that comes to mind

As they say: The only dumb question is the one you don't ask.

Click here to find out how a troubleshooting database helped one client.

Edutech KM Ltd

PO Box 25-241, Victoria Street, Christchurch;
phone: 64-3-337-0234
fax: 64-3-337-0235
info@edutechkm.com
Copyright to Edutech KM Ltd 2008 Privacy Statement