Timely reporting is critical if your company is to make quick, informed decisions. For example, your operations head may require a report listing all the production delays that occurred in the last week, or someone in finance may immediately want to know your firm’s receivables situation. If so, it’s time to build a database to hold the data required to build these reports.

I’ve always said that about 40 to 50 per cent of any database implementation project is analysis — the time spent up front figuring out exactly where the all important data will come from to feed the database.

This includes understanding company procedures and processes or, more specifically, finding out from employees exactly who does what, how it’s done and at what stage it occurs during the process. While it’s not the most difficult technical aspect of the project, this preparation is critical if you want to get the design right.

SMBs usually want a database system to do one of two things: connect their accounting system to a production system, or connect accounting to a customer relationship management (CRM) or contact management system. Then they want the systems to talk to and understand each other.

Broken telephone

But there’s a common disconnect between management and the people in the trenches when it comes to procedural events. It’s amazing how often a database plan is shown to a guy in shipping and he says, “That’s not how it works.” Then the president says, “What the hell are you talking about?” And the guy says something like: “Ever since Bob left, we do it this way.”

This disconnect between what management thinks is going on and what actually is going on seriously impedes a company’s ability to understand its data flow, and it’s why the “designed-byexecutive” database project — one that receives insufficient input from important stakeholders — never works. The more you involve everybody in the analysis where the rubber meets the road, the more effective your system will be.

To build a useful database, you must decide who it is designed to help. Often the member of senior management who makes the preliminary call to an expert to design it (or the one who kicks off the project internally) is either the chief financial officer or chief information officer, or equivalent. The final design will commonly have this person’s fingerprints all over it. So if the CFO calls the shots, a real bean-counting type of database system emerges. Likewise, if the technology expert is leading, the database will satisfy his or her requirements first. Either scenario may in fact be what’s best for the company, but be certain it is, and guard against building a database for the wrong reasons.

Map it out

To solicit preliminary input, get all parties in a room with flip charts, a blackboard or whiteboard (or several of them), and establish workflow paths. My favourite way of doing this involves asking “what-if” questions: “Okay, what happens currently in this department if the phone rings and somebody makes a request?”

Once flowcharts are established, code can be written and the process of building the database can begin.

In some cases, a company has a database that’s not working well anymore, but rather than trash it, they want to fix it. This might be an option. These days, getting differentiated systems from vendors such as Oracle, IBM and Microsoft to talk to each other has become much easier than before. But often the most efficient way to get to your ultimate goal of timely reporting is to build from scratch.

A common mistake companies make is to start with an unwieldy list of wishes and desires for the many reports and output they want to see. Actually, database design processes are most manageably done in small bites. Being patient and moving slowly usually results in the best system in the end.

Also, it’s important to decide early on what’s essential and what’s affordable so you can stay focused on a reachable goal. Understand that if you have some pieces of Access, DB2 and Oracle databases and you’re just putting them together, or even if you are buying a new system that requires very little customization, the process is never fast, easy or cheap.

The most crucial thing to remember is that the many challenging hours of testing, troubleshooting and debugging you must go through before the job is done are not a waste of time. They are part of the design process. Nobody knows what problems or issues are going to crop up during this stage, but it’s only when you try to do something and it doesn’t work that you can truly fix it.

Greg Michetti is the founder and president of Michetti Information Solutions Inc., and vice-chairman of the Computer Network Advisory Board at the Northern Alberta Institute of Technology.