Business owned Applications are a reality- Formalize it

A real-life medium to large size organization will have hundreds (if not thousands) of small to medium sized ‘applications’ which are owned by business and are not on IT radar. The key reason is that IT is not able to (rightly so) meet all the business demands within the time and money constraints it has. Therefore, working units in the business create their own applications, which may range from excel based to a full-fledged IT platforms. Many a times, these business units have their own ‘captive’ IT units.

Many of these systems, over time grow, spread and become an important link within the business processes. While being critical, they don’t have the level of robustness and reliability, which is inherent with IT-owned systems. This generates a financial, operational and compliance risk. 

These applications also become an important part of your data quality and BI agenda. This is because they carry important and business critical information. In my experience, a fair proportion of effort on any enterprise level Data quality or BI initiative goes into mapping, extracting and transforming the data from these sets of apps.

The response of an organization may range from ‘fight’ to ‘flight’. My recommendation is to accept the reality, formalize it and mange it. The informal business applications are here to stay and you cannot take away the reasons, which lead to their existence. Here are the steps one can follow:

• • Step 1- First of all, one needs to have a sponsorship from the owning business functions to open-up their world and let the teams working on Data Mapping or data quality program.
• • Step II- One can create a quick inventory list of all informal applications, and do a first level prioritization.
• • Step III- More detailed analysis of the inventory list by using a standard set of questionnaires. Some of the questions in that questionnaire would be:
  • - Will the key business processes come to stand-still if the application does not work for one day, one week, and one month?
  • - Does this application stores or processes the financial data?
  • - Does this application stores or processes the data related to the privacy laws, like credit card numbers, personal contact details?
  • - Does this application have a disaster recovery in place?
• • Step IV- Short-list the applications, where you to have the first go. Make a road-map to bring the critical applications into IT fold.
• • STEP V- Issue guidelines on the management of information applications. As part of these guidelines, you can include:
  • - What can be part of the informal applications and what can’t be.
  • - Procedure of periodic check on the inventory
  • - Procedure for aligning with IT principles and architecture for a given class of applications
  • - Sign-off from IT on controls and quality related areas etc…

There are multiple benefits of this approach:

• • Business and IT can work collaboratively.
• • Awareness of risk is half the battle won. Once you know the soft spots, you can work on them.
• • Your Data Quality, Data Integration and BI initiatives will be smoother and efficient.

In other words, formalize this reality and you will be able to manage the risk much better. For more details on this subject, you may refer Business Applications are a reality- Manage it in my portal Business Intelligence and Performance Management Institute .

Evaluating BI Service Provider

Dear Readers! I have many links to my portal here, as I am struggling to cover a big subject in a single post.

As BI has picked-up pace, many IT service providers who have grown big through OLTP/transaction system based businesses, have started their ‘BI practice’. In spite of their best intentions, the ‘OLTP’ and ‘ERP’ DNA becomes a significant barrier in building a true-blue BI capability. Therefore, ‘Big’ may not be ‘Best’ here.

I have mentioned at some places in my portal www.bipminstitute.com , BI and Data Warehouse (as a key part of BI) require a different  mind-set and capability-set to manage. Some of the reasons are as follows:

• • Business requirements are fluid and constantly changing.
• • Business Requirements are difficult to articulate and capture.
• • Dimensional Model is pretty different from OLTP data modeling 
• • Needs in-depth domain expertise to model and design.
• • Load Management is unpredictable.
• • Testing is vastly different 
• • The DW modeling has to be extensible and flexible , even if business does not ask for it.
• • Short attention span from stakeholders, as life can go on without BI (unlike an ERP).
• • Storage space and infrastructure needs are less predictable.
• • BI is 80% business and 20% IT (disclaimer- I am not short-changing IT, but emphasizing upon the criticality of business stake-holding)
• Etc… Etc..

An OLTP-based  Vendor has to understand these unique aspects, and bring that fundamental shift (as an economist will say ‘macro-economic restructuring’) in the skills and mind-sets.  As you select a BI service provider, one can ask many questions from the potential service provider, on the above subject areas.

I have struggled for many years to find a service provider which can provide a heady mix of business, IT, Process and Modeling skills under one roof. I have been able to find only a few but they were too exhorbitant to afford. Finally I had to resort to a combination of 2 to 3 service providers to complete the skill-basket, while keeping the BI initiatives financially viable.

You can refer  Data Warehouse has unique challenges and Business Intelligence Vendor Evaluation to complete the picture.

Simple but highly effective- Periodic Reports Rationalization

There are more simple steps an organization can take to manage its information than complex technology driven ones (though both are necessary). These simple steps can be done by any organization without massive IT investments. They not only boost effectiveness, but also create a strong foundation for your IT-based BI platforms. Here is one of them:

On periodic or monthly basis, rationalize your reports and views (if you have a reports and ad-hoc query viewer) in terms of -

• • Reports not getting used
• • Duplicate or nearly duplicate reports
• • Report having mis-matching formulae.

You can address the above by de-activating the un-used reports, creating super-set reports, fixing formulae etc…

Key points to mention here are:

• • It does not take much time. I have seen people rationalizing 200+ reports in a single day, after few months.
• • You do not have to be perfect. 70-75% achievement is good
• • This is one such operational step, which does not require funding, high-level sponsorship or a go-ahead etc. It can be driven by the CIO along with the assigned IT and business analyst.

The critical success factor is the discipline of regularity. If you do it well, when you go for your BI investments, you will have much smarter (and leaner) business requirements in place. Do try it once and share your feedback.

More details on this subject are in Periodic Rationalization & Prioritization of Information has multiple benefits in my portal Business Intelligence and Performance Management Institute .

Design & Model DataWarehouse for broader applications

It is a myth that Data Warehouse main purpose is for data analytics. When you are creating the business case for your Data Warehouse, you can include the following benefits, with only some of them belonging to the traditional analytics:

1. Enterprise Reporting
2. Offline Operational Data Store (refer ODS types ask a question)
3. Data Analytics
4. Data Mining
5. Business Modeling
6. Operational BI

As you design and scope your Data Warehouse, you should account for potential uses, which go beyond data analytics. This is how your Data Warehouse design will be influenced, if you are going for more broad-based applications:

1. More granular data
2. More Descriptive Attributes
3. More Robust and scalable platforms
4. Load and Job schedule Management
5. Your Dimensional Model
6. Your OLAP strategy

This topic is dealt in more detail in Data Warehouse is not for analytics. Design it for broader applications, in my portal Business Intelligence and Performance Management Institute .

Additivity of Measures as you design your Business Intelligence platform

Most of the analysis through the Business Intelligence environment is on summary or aggregated data. You create aggregations at various points in a BI environment:

1. Aggregations in dimensional models
2. Aggregations in your multi-dimensional OLAP
3. Aggregations in the design of your views and reports in the end-user tools (like enterprise reporting, data mining tools etc..)

These aggregations involve aggregating the measures (or ‘facts’ in dimensional modeling lingo). A key pitfall to avoid is to check if the measures are possible to aggregate various aggregation operations like sum and average. This capability for a measure to be aggregated is called the additivity of a measure. Measures can belong to following categories:

1. Fully additive (can be aggregated across all dimensions)
2. Semi-additive (can be aggregated across some dimensions)
3. Non-additive (cannot be aggregated)

For details on the additivity of measures and examples, please refer Additivity and Aggregation of Measures-Facts in OLAP Analysis in my portal Business Intelligence and Performance Management Institute.

Integrating your stand-alone BI environments- Gradual Approach

By the time organizations come out with the idea of an enterprise Business Intelligence Program, there are many stand-alone BI environments which have mushroomed by that time. Business and IT stakeholders are wary to rock the boat on stabilized and business critical data-marts. Business leaders are short of stamina to focus on enterprise BI program, as it is more convenient to grow the functional level existing data-marts.

The question is on how to then proceed for integrating these environments. This is with the assumption that you don’t want to reinvent the wheel and want to leverage on what is already done.

Instead of a big-bang, one can go for a gradual approach whereby a decent proportion of the plumbing work can be done in the back-ground before you start engaging broad-set of stakeholders.

The steps that I will recommend is:

1. Integrate the ETL
2. Integrate the front-end tools
3. Integrate the Data Marts

Please refer to the gradual BI integration approach, the steps and cautions in Integrating your stand-alone BI environments- Gradual Approach in my portal www.bipminstitute.com .

Maximizing the Effectivenss of Data Steward for Data Quality and BI

This tip can form the foundation of your BI and Data Management effort.

A Data Steward is responsible for the health of the data within an organization. This role has a great potential and delivery capability, if an organization can adopt the following approach:

1. Make Data Steward accountable for defining the data quality goals
2. Make Data Steward accountable for the Data Quality KPIs
3. Make Data Steward accountable for delivering on the Data Quality Goals
4. Empower and rightly position the Data Steward
5. Data Steward should be part of Business
6. Data Steward should be a subject matter expert on the businesses, processes and IT interface.
7. Assign functional level Data Stewards
8. Assign distinct data stewards for distinct data group
9. Avoid process-based data steward

To understand the details behind each of the above factors, please refer How to Maximize the effectiveness of Data Stewardship in my portal www.bipminstitute.com .

Building Business Intelligence Business-Case

Business Intelligence business case can be a simple subject, when a business function is looking for creating a data-mart. In this case the demand comes from business and business has worked out their mathematics to justify the needs. The main issue comes when you are building a business-case for foundation investments for an end-to-end platform.

The example of foundation investments include meta-data repository, enterprise data warehouse platform, enterprise reporting tool etc.. These investments can be of significant order. The responsibility of preparation of business-case comes upon a hurridly appointed “BI champion’, who could be CIO, CFO or a major business-head.

Some hard-hitting justifications include regulatory and compliance adherence, customer satisfaction, customer cross-sell and up-sell and avoiding financial write-offs.

Quantifying and ‘justifying’ the business benefits is also a challenge, and one can apply tricks like involving an external vendors and asking specific questions from business owners.

I have placed a page on some of the hard-hitting justifications on the BI, and also some tricks on how one can enhance the benefit quantification impact. Please refer Building Business Intelligence Business case in my portal www.bipminstitute.com.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!