It’s been a fun few weeks. I’m not sure if it had anything to do with Halloween, but in the last 10 days I’ve fixed more business intelligence “systems” problems than in the last six months. But in almost every case, it wasn’t a systems problem at all. It was a people problem.

Blaming the system is easy but usually not correct. If you have problems with your technology, you probably have issues in your process, training and communication. When (and only when) you have these other pieces in place (and working well) should you look to your system as the source of your problems.

A few examples of “system” problems we’ve worked on over the last two weeks:

1. Interface doesn’t process three out of several hundred files sent.

Looks like a system problem, right? Not quite. A little investigation showed the interface was programmed to look for the field “carrier.” In the three unprocessed files, the field wasn’t called “carrier” but “vendor.”

This isn’t a system problem. It’s a lack of documentation problem (which is the bane of our existence). It’s crazy how many ISVs can’t provide documentation for their own systems.
Looking at the file we received, it wasn’t corrupt. It was just different. We had to figure out HOW it was different before we could fix it. And we needed the vendor to tell us what to do.

2. General Ledger doesn’t agree with billing system.

For years, this organization blamed its disparate systems for its problems. When a new auditor was hired, he wouldn’t accept “it’s the system” as an explanation. With a bit of digging, the organization discovered that they posted many adjustments directly to the General Ledger, without first hitting the billing system. Other revenue came in via wire transfer and had nothing to do with the system. This wasn’t a system problem. This was a lack-of-proper-procedure problem.

3. Order transfer to Invoicing fails.

At this organization, once an order is filled, the user pushes a button to turn the order into an invoice. On this day, it failed with a very strange error message.

We eventually figured out that a developer has created a trigger on the database—which is a bad idea with almost any kind of packaged software. But beyond being the wrong thing to do, it also wasn’t moving from development to production correctly. A bad strategy executed poorly. Not a winning combination.

Again, this isn’t a system problem. It’s a training and process problem. The developer needs better training, and the company needs better processes to move things from development to testing and from testing to production.

4. Interface program overrides accounts to a default string of all 999999s.

Finally! A system problem! And a truly weird one. At this client, accounting information was sporadically overridden to all 99999s during an interface process. We couldn’t reproduce the problem when we retested the same file. This DOES appear to be a system problem because the program produces different results with the same information. Everything else (training, processes, communication, etc.) looks solid. Now, we need to clean up the test system to reproduce the results and figure out exactly what’s happening.

We’re in the business of fixing system issues. And they do exist: -interfaces are missing, tools don’t scale, numbers don’t match, etc. But most of the time, the problem isn’t the system—it’s everything around it.

How about you? In your company, is it the technology or the training, processes and/or communication, which cause the most headaches?

 

Get tips and insights delivered to your inbox

Start a conversation with us

Call: 917-848-7284
Email: inquiries@redthree.com

Request a Consult