Since software developers and database administrators are responsible for creating and maintaining databases, most organizations rely on them to also provide business reports to the user community. This happens because they are the only ones with SQL knowledge as well as the only ones that have access to the raw data directly. While giving the people with the keys to the locks the responsibility of fetching the information might make sense initially, it can quickly become an organization’s Achilles heel. Here are some reasons why.
1. They Do Not Teach Reporting in Computer Science Curricula
In fact, most universities spend very little time covering the topic of databases. Many address the subject on a very theoretical level in terms of how you would create a database engine from scratch. Today, relational databases are amazingly effective at storing enormous amounts of data. There is rarely a reason to consider any other storage approach. Unfortunately, only a very rudimentary explanation is given. Since databases often outlive applications (ie, you’ll throw away the app every 5-10 years, but the database must live on), professions working with production databases do not have the luxury of starting from scratch or re-factoring the data structure. And while the topic of production relational databases is only briefly covered, reporting fundamentals are almost completely absent from most computer science curricula.
2. They Do Not Teach Reporting in Certification Courses
Many software professionals refine their understanding of platforms and tools through certification courses. Microsoft offers some excellent courses and certifications. While these certifications will certainly improve someone’s understanding of the capabilities of the platform and how to accomplish specific areas, they do not cover reporting. Some courses may cover how to use developer tools to connect to a database and extract information, little is offered in terms of what makes a good report.
3. Books on Databases and Reporting Tools Do Not Cover What Makes a Good Report
There are many great books on how to generate reports and access data, but unfortunately they make the assumption that you already know what you want to create. This works fine in cases where the details of the report are well understood, but that is rarely the case in today’s rapidly changing business environment.
4. Developers Have Little Context for Actually Understanding Business Data
After going to a good university, getting certified and reading some books, a developer will have a solid grasp of how to use the tools to access or summarize whatever information is asked for. Unfortunately, he or she will still have little understanding what the results mean or why the information is valuable. This is often intentional as developers have access to very sensitive information and an understanding of what it means could be very dangerous in the hands of a competitor.
A relatively common scenario is a common back and forth where the business person instantly wants a different report the second he looks at it because what was provided was not what was expected or the results provided some insight and a new report is now required to investigate further. The information might as well be random data or hieroglyphics. A true business analyst would often be able to anticipate such requests or find patterns in the data. Unfortunately, the majority of developers and database administrators are technical experts with little understanding of business operations.
5. Developers Cannot Anticipate the Reporting Requirements of the Distant (or Immediate) Future
While a good developer will generally develop flexible software that serves today’s needs as well as tomorrow’s, the nature of reports is radically different from the nature of software.
Software does need to be upgraded, but a good design will serve its core purpose for many years with only minor changes. Reports have a much shorter shelf life and it is nearly impossible to predict. A sales meeting or business decision will require a report that needs to be generated immediately. Since developers and IT staff have myriad other responsibilities, they are not sitting idle waiting for reporting requests. Delivery often takes weeks or months and the first report often creates the need for others.
Imagine if it took weeks to request a quote on a stock and having to anticipate what stocks you might want to research next month. That is the state of affairs in most organizations when it comes to internal reporting. By the time the technical team can respond, the moment has passed because they can’t predict the future either.
The Solution – Self-Service Reporting
Fortunately, business people today have a very firm grasp of what reports are needed and how to best utilize them. The only thing they lack is access. Since new reports are usually variations of existing reports, they do not need to master all the complex technical skills required to maintain and administer databases. They just need simple online tools to add simple customizations to a base set of foundational reports.
While the BI industry has proposed ad hoc reporting for many years, self-service is not about creating reports from scratch. Rather than presenting users with a blank canvas, the ideal solution is to unlock the reports in a way that many simple changes can be made quickly and without formal training. Just as setting up a corporate blog may involve IT, but adding and modifying content can be done by anyone, self-service reporting offers an option that works for the entire organization and that’s what we do at Izenda.
