When you start to peel the covers back, an organization is only as good as its data. Without high-quality data and business intelligence (BI) architecture, companies risk embarrassment, lost sales and even legal issues. This is evidenced by the speed with which companies have integrated ERP and other data systems over the years.
Although these ERP integrations have helped companies streamline and automate their operations, the systems suffer from two key weaknesses: First, by their very nature, many systems that automate company operations are transactional. Although transactional databases hold historical records, the databases are optimized for operations -- adding, changing and removing data -- rather than for fast reporting. The structure of transactional databases makes historical and trend BI reports difficult to develop and slow to execute. Second, extending the native capabilities of ERP integration can be very difficult. It often means working with the ERP vendor on an ad hoc contract or jumping through various hoops. While monolithic ERP integrations represent stability, they also represent a lack of flexibility in many cases.
Particularly due to feature gaps in existing ERPs, many organizations are turning to third-party -- often cloud-based -- vendors to solve specific issues or meet a specific business need that can't be solved in the ERP integration. Further, in order to address ongoing historical reporting and BI architecture issues, organizations are deploying massive data warehouses intended to bring order to chaos and provide new information on which to make management decisions.
Avoid big chaos during critical stages
- At the time of service acquisition. Avoid big chaos by making sure that there is a clear and followed process for acquiring new data services. Don't let rogue acquisitions negatively affect your data.
- During implementation and integration. When one-off systems are implemented, it can be tempting to take the easy route and not worry about a minor date element.
- While determining reporting elements. When data elements from the new system are chosen, they need to be somehow linked to existing data to provide context. Failure to do so can lead to insular decision making. -- S.L.
While these goals are well and good, the implementation of the BI architecture solutions needs to be undertaken in a careful and considered manner. Even in the smallest of organizations, there’s a burgeoning use of BI architecture. With big data comes an opportunity for the CIO to act as a data steward and use the new data in meaningful ways. However, no good can come from a system that's been implemented haphazardly or without an eye toward consistency and inclusion in an overall data lifecycle plan. Without careful planning from a data steward, big data becomes big chaos.
How do you become a data steward for your company? How do you protect yourself against big chaos and provide the best possible opportunity for success in your data efforts?
- Implement a strict data governance processes. Data needs to change from time to time. For example, you might need to modify lookup codes as you undertake a new sales campaign. Before you embark on such changes, vet them through a representative committee so that any potential second-order consequences can be discussed and mitigated. This becomes more and more important as new systems are added.
As data changes hands during its life, the governance process will also determine who can do what with the data. For example, just because data originates in sales doesn't mean that sales should be able to do anything they want without consulting with others. For example, the data steward should understand what sales does with data and why and have some input to ensure that there is operational success throughout the company.
- Create a data lifecycle document. All data has some kind of cycle or funnel. For example, during a data element's lifetime at a college, it visits admissions, the registrar and business office and eventually ends up in the development office. In admissions, the data is "born" -- or, to look at it another way, admissions is the sales database. Once the sale is made and the student enrolls, the registrar owns that data for grades and courses while the business office owns the financial information. After the student graduates, the fundraising and alumni relations office holds primary responsibility for that data element.
Your data steward and governance structure should determine each and every time primary responsibility for data changes hands. It should also be well-documented so there is no ambiguity, outlining which systems are authoritative for a particular data element. This becomes even more important as additional systems are brought in-house: The risk of data overlap is too great and companies risk data duplication, which results in multiple versions of the truth. By identifying up front authoritative data elements, companies are better prepared to track the right metrics.
Big data or big chaos? Big data leads to better decisions, while big chaos leads to turmoil. Fortunately, there are ample ways for you to keep your data house in order. My biggest advice is to go into your data projects with a clear head and a solid plan of action and become a data steward to ensure that quality decisions are based on good, solid data.
Scott Lowe is the founder and managing consultant of the 1610 Group. A former CIO, he's a frequent contributor to TechTarget, TechRepublic and other IT publications. Write to him at [email protected] or [email protected], or follow him on Twitter @OtherScottLowe.