TECHNOLOGY TRENDS
Technology is a key enabler for most business process improvement projects. Major advances took place in the budgeting and reporting software space in the 1990s; now, in the twenty-first century, a number of new and promising technologies are available to further help automate and streamline analytics processes. The following sections describe some of the technology trends that will impact budgeting and reporting ac- tivities, as well as other activities in most businesses.
Prebuilt Business Intelligence Tools
Analytics tools, especially online analytical processing (OLAP) software, have been around for many years. However, in the late ’90s and in the early part of the new millennium, this technology saw a surge in popularity. Much of this increased inter- est was no doubt caused by the fact that a large number of companies were finishing up their implementations of a new enterprise resource planning (ERP) system and came to the realization that they could not get good visibility of all the valuable data they were now capturing in the new system. The virtual nonexistence of user-friendly, yet powerful report writers and analytical tools as an integral part of new ERP systems led financial managers and analysts right back to the analytical tool they had been using for years—Excel spreadsheets.
However, as they deal with larger volumes of data with more information at- tached to each transaction, spreadsheet users all over the world are discovering that spreadsheets were not built to analyze data from large ERP systems. This, coupled with new and improved business intelligence technologies, has led to a surge in in- terest in OLAP tools and powerful report writers.
Already, many very successful business intelligence (BI) software implementa- tions have opened up a whole new world of analysis capabilities for their users (see Exhibit 5.1). Unfortunately, many of these implementations have come at a high cost to the customer because of the challenges of properly integrating a third-party BI tool with an ERP system. Further, these challenges have led to less than optimal data availability and integrity in the BI tools, meaning that even though the result is many
times better than without the analytical platform, more is still needed to see full- blown use of both the data in the ERP system and the features available in the BI software.
The potential solution to these issues is now available from an increasing num- ber of ERP vendors, BI vendors, and system integrators. The solution can be labeled pre-built business intelligence, or PBI, (the term has already been used by a number of vendors and experts in the BI industry). What is PBI? In simple terms, it means that the integration of the ERP system (or any other valuable data sources for that mat- ter) and the business intelligence tool, and in many cases also the reports or views that users typically desire, have been prebuilt before the implementation (see Exhibit 5.2). In other words, much of the tedious and error-prone work of former BI imple- mentations has been eliminated. How is this possible? In many cases, the ERP ven- dors themselves have entered into an OEM agreement with a BI software vendor, and then sat down and linked the tool to the different ERP modules. And, because ERP vendors are already familiar with the typical reports and graphs customers want to use to analyze data, (for example, accounts receivable or sales order processing modules), they can also predefine a number of these and deliver them with the BI tool. In other words, the customer can get BI “out-of-the-box,” instead of BI four months and $100,000 in consulting charges later. Obviously, customizations and other work will be required to get a good PBI solution up and running, but the main EXHIBIT 5.1 Traditional Approach to BI for ERP
Time/Cost/Effort
Medium
Activities
Implementation Time Implementation Cost Maintenance Effort Report-writing Effort
Data Warehouse
OLAP Cubes Reports
Low High
advantage is that you will get it a lot sooner and for a lot smaller investment in con- sulting than for a nonintegrated BI solution.
Because of the apparent attractiveness of PBI solutions, ERP vendors, along with systems integrators and other technology companies, are rapidly developing standard integrations, scheduling devices, and predefined reports that make a BI tool into a PBI tool.
In summary, a large number of companies can now analyze their ERP data with powerful business intelligence software at a lower cost than ever before, and with better integrations to the data sources, thanks to the emergence of PBI solutions.
Open Databases
One of the most important technology trends affecting BPI is the movement of ven- dors toward commercial database platforms for their business applications. Because analytics software is only as good as the data available to it, it is of key importance that data can be accessed easily and directly via analytical tools, or transferred to a data warehouse.
Though there is no industry-standard definition of what an open database plat- formis, most technical people would agree that an open database is software that fa- cilitates structured data storage and that can be populated or read from by using one EXHIBIT 5.2 PBI Approach to BI for ERP Systems
Time/Cost/Effort
Medium
Activities
Implementation Time Implementation Cost Maintenance Effort Report-writing Effort
Data Warehouse
OLAP Cubes Reports
Predefined Reports
Predefined Integration
Low High
or more commonly known data extraction tools (you can read more about modern ETL tools later in this chapter).
For more than a decade, it has been (and still is) common to transfer data between databases, such as between a general ledger and a consolidation and reporting or a budgeting tool, by using a standard text file (often referred to as a flat file). As long as both the source and destination database can accept the text file format, it should be possible to transfer data. Most modern databases, such as Oracle, Microsoft SQL Server, Sybase, and DB2 (you can find a list of popular databases in Part Five), sup- port more sophisticated data transfer procedures than simply producing and loading text files.
Perhaps the most common underlying technology standard for data integration is Online Database Connectivity (ODBC). If a database supports this standard, it is relatively easy to make a direct connection between two systems (although usually it will still be necessary to do a data conversion before the data can be loaded into the source database). In addition, most modern databases that we consider “open”
and easy to read from, support Standard Query Language (SQL). Using SQL, a tech- nical consultant can write or customize an integration between two open databases and facilitate a direct and automated data transfer process.
Budgeting and reporting tools might depend on updates from the data source(s) as frequently as several times per day, and in the future, close to real-time access.
This means that it is critical that data transfer (and possible conversions) be fully automated and that they only trigger manual (human) intervention when there are exceptions or issues that cannot be handled by the business rules in the extraction, transformation, and loading program. This type of automation lacked integration ca- pabilities in the past, hence it was very labor-intensive to keep them up to date. Today, however, an increasing number of companies have replaced their old proprietary transaction systems with new ones that allow for automated integration with data warehouses and data marts, thereby opening up their data for easy and automated integration with analytics software.
Common Data Exchange Formats
The main obstacle to providing decision makers with a single report writer interface that has direct access to all the information that resides in their company’s financial databases is that different software vendors have never been good at extracting data and delivering it to each other’s databases. Historically, it has been the job of the company’s IT department to move data from one system to another. In its simplest sense, this job has consisted of creating an export file from the data source and im- porting it to the other system.
The most common file format that has been (and still is) used is the text file. In this context, a text file is a list transactions, wherein each transaction is a row, and each row consists of a number of information fields (such as account number, period, amount, cost center, currency code, etc.) separated by a common character such as a comma, space, or semicolon. In many cases, however, moving data from one data- base to another is not as simple as exporting and importing files. Often, systems have
conflicting codes; for example, the same account number can refer to two different revenue or expense categories in two systems. In particular, this is a common prob- lem in large companies with multiple subsidiaries that use systems from different ven- dors. In the case of conflicting code systems, a data conversion (sometimes referred to as data cleansingin data warehouse projects) is necessary to make it possible for two or more systems to exchange information. In a worst-case scenario, data has to be manually reentered from one system to another (see Exhibit 5.3).
In most companies, the IT department will write conversion programs to auto- mate the conversion of data files. In a better scenario, one of the two systems ex- changing data can convert the data file to the other system’s required format as the file is being exported or imported. Also, a number of third-party data conversion tools are available today that have predefined or user-defined links to popular systems and that can save a company’s IT department a lot of time and money (see the ETL product and vendor list in Appendix C).
ETL Tools
Increasingly, software vendors (in particular, budgeting software, financial report- ing software, OLAP software, and data warehouse vendors) recognize the need of organizations today to move large volumes of data smoothly and efficiently among databases; and in recent years, a number of powerful new tools have become avail- able. Many of these tools have been referred to as extraction, transformation, and
EXHIBIT 5.3 Evolution of Data Transfer Current
and Future Processes Current Process Histroical Process
Data Source Data Transfer process
Manual Rekeying of Data
Manual File Handling
Automatic File/Data Handling
Destination Database
Automatic Extraction File Export Reports
Automatic Loading Data
Transformation
File Import
loading tools (ETL). Setting up an effective data extraction, transformation, and load- ing process can take up to 70 to 75 percent of the time spent on a typical warehous- ing project.
ETL tools automate the sometimes extremely laborious (manual) job of moving data from one data source/data base (e.g., a transaction database like the general ledger) to another (e.g., a data warehouse or data mart). In general, an ETL tool does the following:
1. It reads data from an input source (relational table, flat file, etc.).
2. It passes the information through a business-rule-based process to modify, enhance, or eliminate different data elements.
3. It writes the output result out to another relational table (e.g., in a data ware- house), flat file, and so on.
A number of tools perform the ETL functions with greater or less functionality in a certain area, such as extraction, transformation, or loading; but true ETL tools are strong in all three areas.
A good example of an ETL tool is the Data Transformation Services (DTS) utility, which is included with the Microsoft SQL Server database management system (DBMS). The tool comes with a number of prebuilt links to make it faster and easier to connect to other popular databases such as Oracle, Sybase, UNIX-based databases, and Microsoft Access. This capability makes it faster and easier to set up integrations; it also allows for scheduling, so the ETL process can take place auto- matically at any given point in time and with a predefined frequency.
More recently, we have seen the emergence of common data exchange lan- guages, on which governments, information standards organizations, software companies, and different interest groups from all major industries are cooperating.
Probably one of the most significant of these data exchange languages is the eXtensi- ble Markup Language (XML) and eXtensive Business Reporting Language (XBRL), a subset of XML specifically developed to ease exchange of businessinformation among different applications. The formal definition of XBRL is: “A standards-based electronic language for business information, financial reporting, and analysis.”
Standards like XML and XBRL take data handling a major step forward from the HyperText Markup Language (HTML), the current Web standard also used for web-enabling formatted reports or other financial information. With the new XML standard, plus the related ones specifically developed for accounting and financial information, it will be possible search and extract for sample industry or competitor information from across the Web. Because a layer of business logic can be applied to a search, instead of returning information from allof your competitors, it can, for example, filter out only those that have a market capitalization higher than $500 mil- lion or total revenues higher than $200 million (see Exhibit 5.4).
XBRL standards (which describe the business language) have been, or are cur- rently being, developed for the following areas:
• Assurance schedules
• Authoritative literature
• Business reporting (balanced scorecard, benchmarking, etc.)
• Credit line reporting
• Economic indicators and demographics
• Financial statements
• General Ledger
• Journal entry reporting
• Mutual fund performance
• Performance-related Press Releases
• Risk reporting
• Regulatory filings
• Tax filings
The positive impact of XBRL on financial reporting can be very significant.
Imagine decision makers in a company being able to turn on their computers (or handheld devices) in the morning and see fresh information on their screens that has automatically been extracted (thanks to XBRL) from competitors’ or partners’ press releases and regulatory filings. And because XBRL contains specific information EXHIBIT 5.4 XBRL Simplifies Exchange of Data
General Ledger
Explanatory Text Third Party Information Best-of-Breed
Systems
Custom-Built System
CRM System
Tax Filing
U.S. GAAP Financial Statement in German U.S. GAAP Financial Statement on the Web
Bank Filing
Internal Reports and Data Files
Press Releases
Government
Vendors Employees’
Cell Phone/
PDA Investors and
Creditors
Competitors’/
Own BI System News Agencies
XBRL XBRL
Data Source Recipient
XBRL Document on the Web or Intranet
about the type of data being extracted, the BI software can take the data and put it into the right context. In other words, if a manager is looking at a key performance indicator report with actual-to-budget variances and actual-to-industry or -competitor variances, the industry and competitor information can be included automatically thanks to XBRL (see Exhibit 5.5).
Further, because of the specific information contained within an XBRL tag (part of the XBRL code that is linked to financial or text information), it is possible to au- tomatically locate and retrieve pieces of information within a report/document and pull it out to use it somewhere else, for example in a BI system (see Exhibit 5.6).
All major industries now have international organizations that develop XBRL tags specific to their industries’ financial and other information. These industry- specific tags are known as taxonomies.
Some key benefits of XBRL include:
• Enables faster access to external information.
• Makes it easier to create integrations to third-party systems and documents.
EXHIBIT 5.5 Sample KPI Report KPI—Key Performance Indicators Company: SPORTY Manufacturing June 2001
Actual Budget Variance Variance Industry Competitor
Jun-01 Jun-01 in $ in % Average XYZ
Net
Revenue $1,300 $1,100 $200 15% $922 $875
Average Revenue per
Employee $260 $220 $40 15% $85 $80
Gross
Margin $400 $350 $50 13% $280 $200
Average Gross Margin per
Product $25 $20 $5 20% $22 $15
Online Sales as a
% of Total
Sales $15 $20 ($5) –33% $5 $10
Cash Flow $35 $30 $5 14% $28 $15
Sales
Pipeline $3,000 $4,000 ($1,000) –33% na na
• Saves cost by reducing development time.
• Saves costs and potential errors by eliminating manual data entry.
In the coming years, as legacy applications are phased out and new software and integration standards are adopted, it will be easier to move data between a com- pany’s own systems or between the databases of different organizations. For business intelligence, this means that decision makers and analysts will have easier and faster access to frequently updated information, which ultimately should support quicker and better decision making.
Using Data Marts and Data Warehouses to Enhance Business Intelligences
Chief financial officers, controllers, analysts, and other high-end users of financial information in a company will agree that their ERP software was not built with easy budgeting and reporting in mind. More than a decade ago, it was common to have isolated financial modules for each accounting area, to use multiple report writers to get information out of the different modules, and, typically, to do budgeting in Excel.
Today, most companies have an ERP system in place that provides highly in- tegrated accounting databases. Report writers can access data from multiple modules and integrate it in information-rich reports. Many vendors now also have budgeting and reporting tools that can directly access several, or all, of their accounting modules (see Exhibit 5.7).
EXHIBIT 5.6 XBRL Example Financial Report Example Balance Sheet
Company XYZ
Period Ending Period Ending 12/31/2001 11/30/2001 Cash and Cash Equivalents $235,000 $238,000
Simplified XBRL Example
<group>
<group type=”currentAssets.cashandCashEquivalents”>
<item period=“2001-12-31”>$235,000 </item>
<item period=“2001-11-30”>$238,000 </item>
</group>
Conversion to XBRL
It is now increasingly popular to gather all the significant data from the ERP system and load it into a data warehouse or a data mart and then connect report writ- ers and analysis tools to these to create a more consistent and knowledge-oriented environment.
For many years now companies have been deploying data warehouses as a means to facilitate common data storage for better reporting and analysis. A data warehouse can be defined as a collection of data designed to support management decision mak- ing. In the past, a majority of these implementation projects have been known to be slow, complex, and often very expensive. Data warehousing activities have, therefore, for the most part, been found only in large companies with a particularly strong need for the technology and with enough resources to build and support it. Now, many recent trends and technology developments are making data warehousing a hot topic in a wider variety of companies. Some of these trends are:
• Business intelligence push. The popularity of BI tools (here referring to reporting and analysis software) are pushing data warehouse initiatives to provide a com- mon, easily accessible data source.
• Technological advances. Adoption of open database platforms and powerful integration tools makes it easier and less expensive to build and maintain data warehouses.
EXHIBIT 5.7 Evolution of Financial Systems 1. The Past — “Data”
Isolated Financial Systems
2. Today — “Information”
ERP-Focused Integrations
3. The Future — “Knowledge”
Data Warehouse-Focused Integrations
Data Data
Data Data
ERP
Input Information
Information Input
Data
Warehouse BI Tools
ERP Input/Output