4 Ways to Distribute Your Error Reports

Following up on my last post about Error Report Contents I’d like to identify 4 ways an error report can be distributed.

Error reports can be distributed in the following manner;

Mainframe or application logs: Such reports can be deleted when the time limit has been reached. This will take space and has limited search capabilities.

Email alerts: Great for filing up your inbox. If you’re ambitious enough you can sort, organize, follow-up or delete them.

Webpages: Having them on web pages provides that modern look and feel and provides access to anyone you wish. You can then drill down to gather further details on the error, job, and even further details. Can be a bit cumbersome to manage.

Database tables: In this form you can query the results, and maintain a history in an easy to read format, provided you have the right skills.

Recommendation: Regardless of how you look at it. In a support role, you need to action incidents quickly. To do that use email alerts, once completed you can delete them and keep your inbox clean. Furthermore, you want to report on them, so only delete them if you have a record of them elsewhere. The best bet is to have your errors written to a database table where you can create some KPI’s on files or even source systems (another tidbit to keep in mind for error reports). SQL will allow you to create some good KPI's and identify key trouble areas. With those indicators you will be able to take corrective actions on systems and files that just don't measure up to any service level agreements you may have in place.

5 Simple Tidbits to Include in Your Data Error Report

ETL code and processes are key in the operations of updating and maintaining a data warehouse. A good operational set-up will have data error reports available for the data quality analyst to verify and action.

Traditionally an error report will tell you the data is wrong, provide an error code which relates to a very lame description of the error. In many cases it was written by a business analyst who has worked a long-time on the project and just wants to wrap up the work and move on to the next project. Therefore, in those cases the support analyst or data analyst will be left holding the bag, or scratching their head when they do get a data error. Don’t let it get to that, push back and ask for more.

These are a few items to include in the error reports to make life easier for the support team, other than an error code.

Include:

1. Job number/name: this is an easy find to report on, this is the job that was handling the data when the error occurred.

2. Impacted Table: not everyone will know what job impacts what table, so include it, this will provide immediate recognition of the type of data your dealing with.

3. Primary Index: having the primary index will allow you to search for the record that is at fault either in the temporary table, or in a temporary holding file.

4. A brief meaningful description of the error, a two-word error message just does not cut it in many situations.

5. The most important piece of information to include in an error report would be to identify the action required to fix it. This is often excluded by many business analysts as they gather requirements. Data quality is often omitted from requirements and the business does not know the data the way they should (but are getting better), and have no idea how to correct it. It is a significant piece of information that will save significant amounts of time on the part of your support team. In the event you are not able to put the action required in an error report (due to possible text length or most often funding), reference the error back to the appropriate document that contains the actions required.

Just remember no one likes to get an error report, alert or notification identifying what has broken next. So make it easier for all those support analysts out there, give them what they need.