This is the third in a series of three blog posts about the best practices in business intelligence and what questions CEOS should ask before investing in BI.
This is the third in a series of three blog posts about the best practices in business intelligence and what questions CEOS should ask before investing in business intelligence. To read the second post, click here:
Question 5) Will we need to consider formalized data architecture?
In all likelihood, yes. Organizations generally evolve their information platform based on apparent business need (BI maturity). Consider drivers which evolve organizations from a direct-to-source only strategy:
- Impact on transactional business system may be too great;
- Information requirements are too great for as-is retrieval;
- Query complexity or data volume too great for adequate response times;
- Data Summarization routinely needed first;
- Data in separate business systems cannot be joined;
- Data residing in multiple systems is inconsistent;
- Data requires extensive manipulation before it can be used as information.
When comparing application databases to information databases, both have completely different design philosophies. Application databases have a data in philosophy – lots of small read, write, and delete operations. Application databases are considered very volatile due to the operational nature of each business process on a daily basis. Information databases have a data out design philosophy optimized for reads, large and complex queries and overall the subject-oriented nature of each reporting and analytics request.
The image below shows the correlation between analytical requirements and the need to represent data within an optimized data architecture (data warehouse).
Analytical Sophistication Drives DW Requirements
Much of existing application reporting available within any ERP / CRM / SCM business system address operational reporting requirements quite nicely. Many modern day scenarios force the complexity of preparing data for analytics.
Question 6) How do I mitigate unplanned technical feasibility challenges?
Most organizations truly don’t understand the challenges that lie ahead when preparing data for the data architecture. Why would they? Only apparent need manifested from a BI reporting and analytics requirement bring to light a slew of potential issues. The question is, can this be mitigated as early as the planning phases of a budget procurement process? Fortunately, the answer is yes.
Technical feasibility in the BI sense is an assessment of challenges when preparing data for planned and unplanned business requirements. With respect to Business Intelligence, defining and prioritizing a list of high impact BI project candidates is not good enough. Project candidacy also needs to account for technical feasibility.
Consider the following list of scenarios:
- As a global company, we need to consolidate data from 6 different billing systems. Each billing system has its own unique business rules, database type, history, location, language support, currency, etc;
- After lots of consensus building, we understand some of the Customer Master categories we could use to analyze customer data, however not all business systems support these categories. Most of the category values are not standardized;
- Some of the legacy billing systems will require new software to get data out, or require additional development by the local administration team to just provide us with source data;
- Some locations already have their own data warehouses;
- Required data were largely not enforced, so many of the values are missing;
- Most local sites have Excel-based reporting and analytics which takes days to prepare after the period close. The entire process needs to be repeated every month with many contributors;
From a technical feasibility perspective, any challenges must be known and factored into prioritizing project candidates and planning. In order to understand such challenges, a small task team led by a BI Analyst or BI Solutions Architect would perform a technical feasibility assessment based on gathered BI requirements. Technical feasibility needs to be rated and factored into any budget and project candidacy prioritization process.
Fortunately, the Technical Feasibility Assessment is treated more like a BI Audit. The assessment process itself is an iterative process (repeated for each project candidate) and should be completed in a number of days. The goal is not to find every single nuance you may encounter in a project, rather to quickly understand apparent challenges and patterns in the data you are about to acquire and consolidate.
To learn more about TriCore’s BI Services, click here.
To read Part 4 of the series Click Part 4