Armin Sestic - Fotolia
Enterprise systems like ERP collect and manage data. Accessing and exploiting that data -- although arguably a primary function of ERP -- has always been a weak point. Early manufacturing resource planning (MRP II) systems (predecessors of ERP) came bundled with preformatted reports and displays. Difficult manual programming was required to change the standard reports or generate new ones.
The second generation of ERP was built on a relational database management system. Although standard reports were still provided in the basic package, the database system allowed the use of general-purpose query tools like structured query language (SQL) to build custom reports and screens without programming. In what could be considered a parallel development, most enterprise systems adopted a Windows-like user interface with an ability to easily extract data into Microsoft Excel and Access. Users are familiar with these tools and feel comfortable manipulating data in those environments. All of these tools came into use in response to the desire to make better use of the masses of data trapped inside enterprise systems.
In the 1990s, data warehousing entered the picture as a way to get more value from ERP data. Detailed data from ERP, CRM and other systems is consolidated into a separate data warehouse and analytical tools are used to "slice and dice" the data in a process called data mining. The data is replicated in a separate warehouse for two reasons: the tools tie up a lot of system resources so they are less intrusive on their own server, and the separate repository enables the combining of multiple data sources (separate databases) without concerns about interfacing the systems or possible interference between them. On the negative side, warehouse data is not real time – it's only as recent as the last download.
Around the turn of the century, ERP suppliers began offering business intelligence (BI) modules as enhancements to their product suites. Also called executive information systems (EIS), executive dashboards and other similar terms, these modules were an adaptation of data mining and reporting tools with prebuilt data visualization (dashboard "indicator" dials, graphs, red/yellow/green traffic lights, charts) for high-level summaries and that drill-down to the underlying data. Note that this is most often "live" data in the active ERP tables. Companies could tailor the indicators and build new ones with provided tools.
BI tools put more and better information into the hands of users, and extend the active system user base upward through the organization to the executive suite. Without BI dashboards, few executives log into an ERP system. If they need information, they'll ask a subordinate to pull it out of the system for them.
But BI tools tend to be technical, so few executives or departmental users will attempt to create new views or analyses. From that perspective, BI dashboards are like the old predefined reports in ERP. If a user wants another view, he has to ask IT to build it.
Today's analytics tools are BI tools made usable for non-programmers. At least that's the direction analytics vendors are moving in. Democratized (or perhaps consumerized) BI tools within ERP application suites promise to optimize the exploitation of the vast accumulation of data in ERP systems.
Data warehousing and data mining within those warehouses is still a valid and useful pursuit that will not be supplanted by ERP analytics unless ERP is the only system-of-record in the enterprise. The warehouse still offers the advantage of combining data from multiple systems and has more powerful analytical tools than are found in ERP analytics modules.
Planning for BI integration
Manufacturing BI tools gain importance
Overcoming cultural barriers to BI
Discover the difference between MRP Live, MRP on SAP HANA and MRP Classic