Are Your Data Structures Robust and Flexible?

As a solution consultant and sales engineer within the enterprise software space, I am constantly asked by clients one key question:

  • Can I create [XYZ] report?

This is such a rational, legitimate question! After all, what’s the point of an enterprise software platform that collects and aggregates data if you can’t generate the reports you need?

Hopefully the answer to this question is “Yes.” Well developed, well thought out systems can facilitate the aggregation, roll ups, and slices and dices of data in multiple ways with ease. Want to compare how department A is performing against department B? How about instead of comparing department A, we compare Program 1 to Program 2? What about rolling up transactional data in more than one vertical across the company?

The possibilities really are endless in the way clients want to report on their data. And they have every right to! However it can put some enterprise software systems in a bind if their data structures aren’t carefully designed.

This is a result of using excel spreadsheets before the implementation of a enterprise system, where data structures aren’t enforced. Referencing cells in formulas is quite a manual process, however it provides users with a lot of flexibility to facilitate aggregations and calculations. However this can get pretty complicated for many enterprise systems to replicate. It becomes almost impossible for a system with poor data structures.

Here are some questions to ask when investigating data structures of enterprise software systems: 

Are reports configurable or do they require custom development?

As discussed in my previous post, you want a tool that is configurable, not customizable. This will save buckets of money on development costs and allow non-technical users to operate and administer your system. If reports aren’t configurable and require custom development, reporting will be a nightmare.

Does the vendor have a reporting team? 

There will always be some reporting requirements that stretch any system. However if the vendor has an entire reporting team dedicated to running SQL scripts to pull client reports, that may be an indication that reporting may not be as simple and straight forward as previously thought.

Does the system have multiple types of database objects? Can they be related?

Well designed enterprise software systems have multiple database objects at varying levels of detail. These systems will also allow users to associate multiple object types together. Sometimes reports will require associating object A with object C, while others will require associations of object B with object C. If an enterprise software has only a couple of data objects that don’t talk to each other, creating reports could be impossible with a custom SQL script.

Can transactional data be tagged with multiple categories?

Tagging transactional data with multiple categories allows users to tell the system where they want the data to go. If an enterprise software system does not allow you to tag data with more than one transaction, roll ups across departments, programs, regions, and more will be extremely difficult.

Written by dwinbourn