 |
|
|
|
|
|
|
|
 |
| |
|
|
|
90-Day Action Plan
Enterprise Architecture (EA) programmes help create and enforce company technology standards that
guide the selection of hardware and software throughout the organisation.
Organisations who already have an EA framework in place will need to validate the Business Intelligence
Domain against the other components of the EA.
First month: Articulate mission
A. State the mission of the BI domain (why it exists and what it seeks to achieve).
This will bring clarity as to why the domain will provide value to the organisation.
—Note that this BI space is traditionally part of an overall data or data warehousing
domain area in most Enterprise Technical Architectures (ETAs).
B. Ascertain the participants in the BI domain.
—This domain must include IT managers with experience setting corporate-wide standards,
guided and facilitated by members of the EA team familiar with domain development work.
—Members should also be drawn from pre-existing BI groups and data warehouse projects.
In addition, representatives from key end-user departments should also be included, as
business expertise is critically important.
Second month: Define domain
A. Definition of the BI domain.
—This should cover the BI domain architecture as well as related domain architectures,
for example, sub-domains such as data management, data warehouse, data mart.
In addition, the following sub-domains would apply to this domain:-
analytic dashboards, enterprise reporting and structured information delivery,
ad-hoc query and analysis suites, and OLAP servers.
—Organisations should standardise on products from these sub-domains.
B. Define the BI standards within the BI domain.
Third month: Enforce compliance
A. Enforce compliance with BI standards in terms of investment decision making on
BI tools through EA governance and IT Portfolio Management processes.
Now more than ever, businesses realise that timely business intelligence in today’s fast-moving environment is a key factor for long-term success.
For most organisations, Business Intelligence (BI) tools represent a major investment that significantly enhances their business decision-making processes.
Being clear as to what tools to use for which purposes minimises redundancy and conflicts of business analytics.
During 2003, many progressive enterprises pursued BI standards—such as enterprise reporting, ad-hoc query and analysis, online analytical processing, and analytical dashboard— to increase consistency, promote reuse, and reduce costs.
However, these initiatives have been mainly haphazard, leading to non-standardised platforms. Delivery through portals also remains some distance away for most organisations.
But by 2005, we expect organisations to incorporate BI platforms into comprehensive information delivery infrastructures —which are still lacking in most organisations now.
Steering in the right direction
Analytic dashboards have become more high profile in recent times. This is because although BI vendors can supply the required technology, most organisations lack a clear understanding of how analytic dashboards will alter the way business performance is measured.
There have been a few dashboard success stories, but most enterprises have struggled to achieve a big payback.
To succeed, analytic dashboards should be deployed within a portal framework as part of an overall information delivery strategy.
The key to BI success will still lie within the organisation having an overall information delivery strategy, as opposed to disparate piecemeal efforts addressing different aspects of the information delivery chain.
Measuring for success
Although the motivation to manage the enterprise with Key Performance Indicators (KPIs) must come from executive leadership, the KPIs themselves need to be defined from the bottom up.
Instead of creating a massive project to define KPIs throughout each business unit, enterprises should embed the KPI creation process within the portal framework deployment.
Take for example a hospital that wants to integrate BI into their systems. One KPI might revolve around profitability.
By gauging its success from the profitability of each patient per visit, a hospital may take actions that subsequently result in cases of staff trying to get patients to stay for longer periods and using hard-selling methods to get them to spend more per visit.
With BI tools, the hospital may discover that it may be getting higher profitability per patient.
However, what may not be immediately apparent is why revenues of the hospital continue to shrink and patients seem to get increasingly annoyed.
In that case, one solution could be setting a KPI which is aligned with Balanced Scorecard metrics.
In most cases, end-user communities will not even distinguish between structured and unstructured content—they just outline the information they want.
Within the requirements analysis phase, the BI and portal teams can work to turn information requirements into KPI formulas.
Doing these tasks in parallel creates significant leverage to reduce costs and ensures that the work actually gets done.
Have a clear vision
Although we believe this bottom-up process for community-driven KPIs is crucial, it is also critical simultaneously to have top-down leadership that expresses a clear vision to ensure the success of an analytic dashboard strategy.
Without the clear vision and executive commitment to a performance metric-driven strategy, analytic dashboard technology will be limited to modest deployment throughout the enterprise.
The reasoning is simple: If you don’t know what to measure in order to drive business success, why bother to measure?
Worse still, measuring the wrong things will likely motivate the wrong behavior, leading to potentially undesirable results.
Take the simple example of measuring the productivity of Customer Service Representatives (CSRs) in Call Centres.
If the KPI adopted is the number of inbound calls each CSR takes, CSRs may not be focused on customer interaction. Instead, the CSRs’ motivation to generate more calls may result in unacceptable service, which could result in customers calling back for additional service requests or complaints.
In that case, measuring that KPI may show that the call rates for CSRs have gone up, but it will not explain why customer attrition is on the rise at the same time.
Thus, BI is only as useful as how its users apply it.
Real-time BI constraints
As a result of the bottom-up KPI creation process, IT organisations should adopt dashboard tools that provide distributed security structures, which will in turn enable distributed KPI monitoring and creation.
This activity goes beyond personalising dashboards by picking from a predefined list of existing KPIs.
However, empowering business users to create their own KPIs will be limited for organisations accessing real-time information from operational data systems.
In these cases, custom development will be required to access the native data source, extract the information, and transform the data according to a KPI formula.
Because we recommend using enterprise information integration techniques for low-volume queries, IT organisations are required to carry out significant testing and IT control to prevent overtaxing operational systems.
Although leveraging analytic dashboards within a portal framework deployment is a more efficient approach in terms of resource usage, not every organisation is ready to deploy a comprehensive portal framework yet.
Alternatively, the dashboard need not be rendered to a browser interface; it could simply be built into any application interface, for example, Microsoft Excel.
In such cases, analytic dashboards will be even more dependent on executive leadership to embrace a strategy of managing by KPIs.
The significant systems integration costs to deploy an analytic dashboard must be justified on their own merits.
However, there is no need to deploy analytic dashboards enterprise-wide simultaneously. Systems integration costs can be managed by incrementally deploying dashboards by business units.
In some cases, the KPIs could be built without a data warehouse since data can be pulled from operational data stores.
Data warehouse preferred
However, pulling information from a data warehouse is an enormous benefit to populate a dashboard, since data transformation can be done in batch mode before distributing it to different dashboards that have similar KPIs.
Thus, data transformations can be performed once for several usages.
Today, most organisations recognise the value and need for BI within their organisations.
They know the strengths to capitalise on and weaknesses to mitigate and BI can only help to make them more adaptive.
And being responsive to change will make the difference between the good companies and the great, lasting ones.
Barry Williams
Founder and Principal Consultant
Database Answers
|
|
|
 |
|
|
