Oh, you’ll want a custom report

In 1789, Benjamin Franklin wrote, “In this world nothing can be said to be certain, except death and taxes.” I think he got it mostly right. He should have said: “In this world nothing can be said to be certain, except death, taxes, and the need for custom reports from your ERP system.” In Ben’s defense, computers and ERP systems weren’t invented yet, so he did the best he could...

I’ve been around ERP systems for over 30 years, and 20 of those years have involved ERP implementations. I’ve used reports generated from our ERP system when I was a supervisor, operations manager, and plant manager. I’ve requested custom reports – more than once. I’ve seen good and not-so-good implementations. I consider myself to be an expert (I’ll let you decide for yourself).

I lay out my qualifications so you’ll know that my opinion about custom ERP reports is based on what I have learned over the last 30+ years. Hear me out for a few more minutes before you dive into the SyteLine (now rebranded as (CloudSuite Industrial) SQL tables.

Let me start by saying I’m a fan of custom reports derived from the SyteLine SQL tables. The right report can save an untold number of hours over years of searching for specific data. It can inform the users and promote better business decisions. No matter how many hundreds of reports are in SyteLine, every company will have legitimate needs for custom reports derived from the SQL tables. This doesn’t mean every request for a custom report is valid, or the best use of your resources. Allow me to provide some guidelines for when to dive into the SyteLine SQL tables and when not to. Let’s start at the beginning: The day SyteLine was installed.

New implementation guideline

In most cases, when a new ERP system is installed, it’s destined to replace multiple non-integrated systems. If you want to reap the benefits of the new, fully integrated ERP system, the processes, procedures, and reports based on your old tools should be replaced, too. This will create new reporting requirements and leads to my first guideline: Don’t create a custom report early in an implementation to replace an existing report. Don’t even think about reports until processes and procedures are defined. I know some may say they can’t live without their special report, and they are correct. But that’s based on the current systems. All of that is about to change.

Related: Infor Syteline Review

Existing system guideline

What if SyteLine was installed and implemented years ago? If that is the case, ask yourself this question before requesting a custom report: Does the report reflect data derived from strong processes and procedures, or is it being requested because they don’t exist? I know that’s a bit generic, so let me give you an example. I have been to many companies who own MRP, but don’t use it because they don’t know how it works. They still need to perform a basic business function – buy raw materials. This leads to some questions:

• What do we have?
• What do we need?
• When do we need it?

Using SyteLine’s planning tools answers all these questions and more. Since MRP isn’t being used, an inefficient procedure is developed. Then a custom report request is submitted to make the job easier. All the data, after all, is in the SyteLine SQL tables. You just need to get to it!

Let’s freeze right there and look at the situation. A company has already bought functionality that will provide their material requirements, within their integrated ERP system. Now they want to invest time and energy developing a custom report that provides the same data (if the report is accurate) they could get if they were trained on what they already own. Not a good, long-term, sustainable decision. My second guideline is this: If the custom report is a crutch instead of a tool, investing time and money into it is the wrong strategy.

No shortcuts

It is tempting to think of your SQL database as the source of all knowledge. It can be, but only if the data is clean. Guideline three: The best way to ensure accurate data is by needing and using it every day. This acts as a natural “filter” to keep the data clean. Achieving this requires an understanding of your ERP system, along with solid processes and procedures.

If you’d like to have a chat about SyteLine SQL tables or anything else (it’s free – really), click on the link below.