Mobile Business Intelligence Reporting

From a sociological perspective, users are becoming more comfortable with their phone’s ergonomics and multitude of features, and are using them as full-functioning mobile computers. Phones and laptops are becoming interchangeable. Initial evidence of this convergence is the large volume of e-mails sent from BlackBerrys and other mobileWindows-enabled smartphones, as well as the proliferation of CRM mobile applications. Also, phones have an advantage over laptops because they can be carried anywhere and used anytime – 24 hours a day, seven days a week. They don’t require mobile hot spots or other Internet connections and with Bluetooth they can be easily connected to printers and other peripherals making almost the entire office portable.






Mobile browsers now provide the same functionality of desktopWeb browsers so users get a consistent experience regardless of device. More people are searching theWeb, reading news, watching streamed TV, accessingWeb applications, and making transactions on their phone. this trend continues business is driven to evolve. Google, for example, recognized the increased use of mobile devices as a medium forWeb browsing and made its search tool and productivity applications (Google Apps) available on mobile phones, setting the benchmark for usability.

Smartphones are also forcing a shift in the paradigm of how information technology (IT) groups work. There are currently 1.5 billion phones in use around the world. By 2011 half of the world’s population will have mobile phones – 50 percent of which will be smartphones. This change clearly indicates that enterprises have to embrace smartphones as a primary form of communication. IT groups – for the first time in their history – have to adapt to consumer requirements instead of dictating their own agenda. If consumers can now access their Gmail on phones, why not access corporate apps too?


Improvements in Productivity

Economic gains from enabling mobile reporting are irrefutable. Currently one out of seven e-mail users is also a mobile e-mail user, having a BlackBerry or another smartphone. Early adopters,mainly executives, have seen measurable increases in productivity by being able to:

- Work during times otherwise wasted, such as while waiting at airports and before meetings
- Respond immediately to urgent messages
- Be avalable to and connected with other key decision-makers 24/7


Gains in productivity outweigh the expense of mobile devices and applications – an estimated fixed cost of $2,500 per mobile user. A low-cost mobile BI solution that does not require additional infrastructural investments such drives up the per-user return on investment (ROI). Furthermore, as mobile computing spreads through the ranks to all employees, the ROI increases exponentially.

According to Gartner analysts Steve Kleynhans, “Most IT organizations are ill prepared to deal with this new environment in which users drive technology.” IT groups are often (and in many cases justifiably) leery of new technologies. Knowing the difficulties inherent in implementing unproven solutions, many would prefer to wait for other companies to provide successful case studies with clear user benefits. Yet, waiting until this technology becomes mainstream means missing out on years of productivity gains.


Dashboards for Everyone



The sheer volume of information available, however, means users risk information overload. Dashboards have emerged as a concise way to visualize information. Instead of analyzing multiple reports and the relationships between them, a dashboard offers an analytical perspective. All relationships and associated measures are presented in a single, prepackaged view. The key obstacle to mass use of mobile dashboards is the small screen on the device as well as the requirement to be connected to the dashboard infrastructure. Two trends are changing this:

Better, larger screens with higher resolution are becoming popular, as on the iPhone, HP hybrid devices, and Nokia business phones. And, better browsers with advanced zoom functions, touch screen navigation, and interaction enhancers – such as zoom drop boxes for easier selection – display content in a useful way similar to dashboard displays.

Active Dashboards can be distributed to anyone – on any device – either via e-mail, via the My Mobile Favorites launch page or by posting them on theWeb, and users can interact with them online or offline.

Agile BI (Business Intelligence) Basics

What is Agile BI?

Cindi Howson: The Agile Manifesto was first published in 2001 by a group of software engineers (see agilemanifesto.org) trying to improve the software development process and customer satisfaction. There are 12 principles, but the six that most apply to BI are:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Simplicity -- the art of maximizing the amount of work not done -- is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.


Who is using agile development and how important is it?

I do get the sense that more innovative companies are using agile development, but I have also seen it in established manufacturing companies. It is less well suited to companies that have outsourced BI because it makes it harder to build things to a specification. Then again, I’m not a supporter of outsourcing for BI.

Agile BI emerged as a common theme among successful BI case studies when I began researching my book Successful Business Intelligence in 2007, so last year, we included this data point in the survey. Overall, agile development was identified as being not that important.



Agile sounds like the Wild West of BI with no requirements, no documentation.

If you are used to having everything highly documented with requirements precisely defined, then less formal requirements definition can seem like the Wild West. The difference is in the how and degrees. Requirements are still gathered, but perhaps through rapid prototyping, collaboratively, rather than the business writing out their specifications before they can look at any results.

Business Intelligence First Steps

Many small and mid-sized enterprises (SMEs) are looking for the best business intelligence (BI) solution to address their specific business problems. Whether these business pains are putting out regular fires, managing a sales force, increasing customer satisfaction, or gaining more visibility into the business and data, business intelligence is becoming the buzzword used to identify the solution used to address these problems.

Unfortunately, business intelligence on its own is not the answer to solving an organization’s business problems. The ability to effectively solve issues and develop a successful BI infrastructure depends upon the combination of the people involved and the business processes put in place. Although there are no surefire ways to ensure project success, there are things that SMEs can do and take into account when looking at starting their BI initiatives.

This article explores the first steps that SMEs should take in order to work toward BI success. The key factors that organizations must consider when looking to use BI to solve business problems and gain visibility into their business are:


1.Defining the right scope
2.Identifying, using, and managing the right data
3.Engaging the right people
4.Integrating proper project planning and management practices

Defining BI Project Success

As mentioned, the four areas listed above do not guarantee project success. However, careful consideration of these items gives companies a way to start any BI project on the right foot and put the processes in place that are required to grow and maintain a strong BI infrastructure and front-end analytics and reporting solution. Because there is so much to consider when looking at any hardware- and software-related project that deeply affects how people do business on a daily basis, taking a step back and identifying individual aspects helps simplify initiatives that require the collection of many complicated and diverse business and technical requirements.

1. Defining the Right Scope – Answering the Right Questions
The first step in any BI project is to identify the business problem. In some cases, organizations want business intelligence to solve all of their problems at once. Obviously, one of BI’s advantages is the ability to consolidate large amounts of disparate data to help companies gain a broader view of what is happening within the company. However, when looking at solving business issues and aligning strategic goals with business performance, doing it well outweighs doing it fast. Therefore, companies should identify their main business pain and start building their solution around that issue to identify general goals and metrics associated with performance management. By developing a targeted scope that addresses key business issues and starting small, organizations can work toward building a solution that meets the needs of many departments within the organization based on incremental success.

2. Identifying, Using and Managing the Right Data – Turning Data into Information
Once the scope is defined, businesses can look at what information is required. This means looking at where data resides, who accesses that data – both operationally or analytically, how often it is updated, how often it is required for reporting and analytics, the types of business rules that exist, what hardware and software it runs on, and what gaps currently exist in relation to analytics or general visibility. Although it is important to start small, organizations can identify all of the information required for the data warehouse because it is easier to identify all required data sources up front to lessen the time spent on integration activities over time.

The type of data and systems currently in use will affect the overall solution choice. Depending upon integration requirements, some solutions integrate specific types of data or information from source systems more easily, while others offer robust linking, matching and data profiling that can help with complicated data reconciliation efforts or merging various business practices into a single data warehouse. Although not always seen as important to business users, the ability to maintain data integrity on a continual basis will help ensure accurate data visibility and better decision making over time.

3. Engaging the Right People – Enter the Stakeholders
Without proper input from the people who own the data and interact with the data, there is the potential to miss key requirements when looking at developing a BI solution. Every person interacts with information differently depending upon his or her role within the company. Consequently, the requirements gathered can make the difference between project success and a solution that no one uses. To make sure that general buy-in occurs, it is important to include the relevant stakeholders in the process. Stakeholder involvement will be different in each company as many different business functions may interact with financial or sales data, or have input related to employee performance.

4. Integrating Proper Project Planning and Management Practices – Back to the Basics with Project Management
Even though not all companies use formal project management tools to manage software selection initiatives, managing projects requires some sort of formalized approach. Tracking stages and managing dependencies throughout the project life cycle helps identify whether everything is on track, how delays will affect future activities, and if the project will be completed within the proposed time frame and budget. The success of a project should not be measured by only identifying whether a project finishes on time and within budget, but implementing BI for the first time within defined parameters helps ensure support for future expansions. Within a BI environment, there are constant projects to enhance and expand solution use because of the benefits seen by companies as they begin to interact with their reporting and analytics environment.

Building BI Step by Step
These four aspects provide guidelines for organizations at the beginning of a BI project and can help lead to a greater chance of project success. Overall, organizations should realize that implementing BI requires business, technical, people, and process considerations and that any gap in one of those areas will create a hole in the overall project. Even if the first implementation breeds success, the continual use and expansion of business intelligence depends upon the cohesion of these four areas.

The ability to define and limit an initial project scope, include stakeholders within the requirements-gathering phase, and manage the project using a defined framework all fall into the areas of business, people, and processes. BI infrastructure and identifying data and how it will interrelate usually provide the bulk of what goes into preparing a BI initiative for the first time. And even though technology requirements are very important within any BI project (especially when looking at data warehousing for the first time), it is also essential not to overlook the business, people and process areas as they become a greater influence as business intelligence use starts to expand within the organization.

Open Source BI Solutions: a Low TCO Prospect

Business intelligence is a vital component for successful business management. It introduces capabilities for effective decision-making, resulting in higher income and increased growth for the organization. BI programs must keep strategic goals and organizational missions in mind, while reducing the cost and time of implementing solutions.

Open source BI may be evaluated against the parameters of total cost of ownership, performance, scalability and user requirements.

Why is Business Intelligence important to an Organization?

Organizations can make intelligent decisions when timely information is consistently made visible to decision-makers at all levels, as this endows them with the ability to monitor important drivers of organizational performance. A well-designed BI system collects the organization’s operational data from different sources, presenting it to decision makers and stakeholders simply and meaningfully through use of a user-friendly tool. A good BI solution helps organizations gain better insight into their businesses, improve decision-making and optimize enterprise performance.


An Open Source BI Overview

Open source BI has come a long way compared to other commercial BI products, and is becoming widely recognized as an important component for enterprise-level applications. Open source BI projects such as Pentaho and Jasper have evolved from community-driven tools to viable technology with professional support for enterprise-wide adoption and witness growing demand. Organizations can use open source BI software to replace custom-coded applications. The open source BI tools can also be considered for BI components that complement the existing proprietary solution to reduce license cost. Because organizations are not locked into proprietary vendor’s platforms, open source enlarges organizational flexibility.

TCO: Critical Factor in Implementing BI Solutions

While few will deny the importance of BI, the most important factor to be considered for BI is the total cost of owning the application. The TCO concept measures costs related to the acquisition of a BI solution, its deployment and ongoing use. Though TCO estimation methods vary for different BI implementations based on requirements and business needs, certain proportions may be assumed to calculate the TCO in most projects. For example, typically staffing costs account for 50 percent while the hardware costs account for 8 percent of the project value. Based on market trend reports published by leading industry analyst organizations, the cost breakdown in Figure 1 may be assumed as the TCO breakdown for most BI implementations.

Open source helps reduce TCO on all the parameters in Figure 1. Open source BI helps in reducing costs and risks for prospective BI users. Though this does not suggest that open source BI is the right choice for every organization in every BI deployment, it can be used as an alternative for reducing BI costs if it satisfies user requirements.





Major TCO Components

Hardware: This covers the cost incurred in procuring the hardware throughout the organization, including all client machines, servers, storage solutions and networking devices attached to servers. As most software licenses are based on the number of CPUs, it directly impacts the cost of hardware. Using a scale-out approach, low-cost servers can be used to deliver open source BI solutions.

Software: The cost related to the software is one of the significant factors in the overall TCO. Open source BI is available at a fraction of cost as compared to commercial products. Open source BI customers have the flexibility to choose the components and their support level according to the requirements of the end users.

Staffing: Staffing constitutes 40 percent to 50 percent of the BI application’s cost, including the cost of resources during the analysis, development and maintenance phases. The ability of the vendor to provide the documentation and technology of expert resources makes a big impact on the TCO. Open source is based on public standards and public domain technologies.


Selection Criteria for Open Source BI Solution
Though TCO is the commonly accepted financial measure for evaluating the BI solution, factors such as user requirements, complexity of development and scalability of the solution have to be analyzed to perform the TCO calculation. The five factors that affect a BI solution are:


•BI product selection and user requirements,
•Complexity of development,
•BI project timelines,
•Product support and third party support and
•Performance and scalability.

These points can be used to compare the open source BI solution with proprietary vendor’s solutions.

BI product selection and user requirements. The objective of collecting BI user requirements is to establish the outcome of the BI solution and other aspects of the projects relating to time, cost and resources. In the case of open source BI solutions, organizations can verify the requirements without contacting the product company, because organizations can initiate a proof of concept and refine the requirements without buying the BI tools.

Complexity of development. Developing a BI solution is not only dependent on the user requirements but also on the product features and technology. As compared to proprietary vendors, open source BI products are based on the technologies available in the public domain. The resources for developing and maintaining applications are easily available. Most open source BI solutions allow a design approach in which a prototype can be done rapidly with regular testing and feedback from the BI users.

BI project timelines. Any BI solution requires orchestrated efforts by the team to complete the solution on time. Selection of proprietary and open source technology affects the human cost. While considering the open source tool, organizations must consider developers and supporting people such as database administrators and testers to understand and learn the technology. Open source BI products have simplified the use of tools and added features that can reduce the development timelines.

Product support and third party support. All open source companies provide support for the products at very low subscription prices compared to proprietary vendors. A systems integration partner is usually brought in to support the solution.

Performance and Scalability

The performance of the BI solution is dependent on factors such as data source performance, server hardware, content complexity and user requests. Most open source BI solutions support scale-up and scale-out architectures and can scale linearly.

Integration with existing infrastructure. Open source BI solutions provide a comprehensive integration interface wherein customization can integrate with the existing infrastructure. Also, this solution can be embedded on compliant servers. Information like cubes and report can be integrated through XML, HTML or JSR-168 portlets. Open source solutions are compatible with multiple operating systems.

End users and supporting personnel training. End users are business people who understand business terms. Open source solutions have the capability to put up a semantic layer that hides the complexity of the data and allows end users to exploit information using business metadata. It removes the necessity for end users to learn the coding language or syntax related to products. System integrators or open source BI companies can provide training to the support team when the BI solution moves into production.

Do business organisations need single process management infrastructure?

Last week, a friend sought my advice on whether her company should implement single process management infrastructure to automate & manage their enterprise-wide process management needs. The insurance company she works for is evaluating BPM system / application to automate travel reimbursement process. While doing so, the company is also exploring the possibility to utilise the same process management infrastructure to automate processes such as New Business process, Policy servicing process, Claims Management process, New Product Development process, etc.

Now the processes described above are different in nature and have different traits. I remembered having read an interesting process classification theory put forward by two wise men (unfortunately I do not remember their names) many years ago. They classified organisational business processed based on Business Value (Revenue Increase, Cost Reduction, Productivity / Efficiency enhancement, etc) and their Repeatability, i.e. their ability to repeat itself for every instance of the process that occurs.





As is shown in the diagram above, organisational processes can be classified into four areas:

•Production processes - with high business value and high degree of repeatability;e.g. New Business process, policy servicing process, claims management process


•Collaborative processes - with high business value but low degree of repeatability, e.g. New Product Development, Contract Formulation


•Admin processes - with low business value but high degree of repeatability; e.g. Travel Reimbursement process, Leave approval process, Conference booking process


•Miscellaneous / Ad-hoc processes - with low business value and low degree of repeatability
In my opinion, the same process management infrastructure may not be utilised to manage all the types of processes described above. There are two issues:

1.Is the BPM system capable to manage both repeatable and non-repeatable processes


2.Is it financially feasible for the organisation to manage high value and low value processes using the same BPM system
Fortunately, BPM systems have evolved over a period in time, and some of the leading BPM systems now possess dynamic process management capbility, which allow business users to alter the flow of the process even at run time, i.e. as the business process gets executed. Such BPM systems would address issue #1.

However, these BPM systems tend to be expensive requiring high end IT infrastructure. In such cases, software, hardware and implementation services costs tend to be prohibitively high to justify the utlisation of the same process management infrastructure for low value admin processes along with high value add production and collaborative processes.

So, in my opinion, organisation may have to settle for more than one process management infrastructure to manage all the enterprisewide processes. What do you think?

From BPM to Management by process

In one of my first courses about Business Process Management, the chairman, an expert in Total Quality Management, was making a major difference between Process Management and Management by Process.

For me it was just a question words. Some years after, making a return on experience from my first BPM initiative, I really understood this difference when I discovered the remedy had been worst than the disease. Let me explain why.

After this course, we decided, the Quality Director and myself as Information System Director, to instruct the managers of our company about Business Process Management.

A map of the processes was defined, and the process owners trained (more or less one in each functional department). After a first set of process attributes was established (mission, inputs, outputs and key performance indicators), objectives were defined and tracked through dashboards.

It seemed everything was perfect in the best of the worlds:

- The Quality Director could offer periodically to the top Management, a measurement of the performance on the company, not only in terms of Finances, but also on Customer Satisfaction and Internal Processes Improvement

- The IS Manager had official spokesmen from each Department to address and implement improvement initiatives through technological solutions.

So why, some years after this initiative, had the organization become more divided, with more difficulties to deliver in time, quality and cost? Wasn’t Management of the Processes supposed to provide more effectiveness and efficiency to the business?
After analyzing the situation, it appeared that only one dimension of the problem had been addressed, the vertical one. The functional organization had been reinforced.

In fact nobody was addressing the horizontal axis, neither looking for integration and coherence of the whole system.
The Processes was managed, yes; but the company was not managed by Process.

• What is Process Management ?

– Focus is put on Effectiveness (Benefits optimization)
– Improvement initiatives are local or by job categories (vertical)
– Most of IS solutions are specific to perfectly match the functional needs
– Power is in the hand of the Process Owners, who define “best of breed” solutions
I name this way the vertical axis of the business processes improvement, as it use to match with the hierarchical organization


• What is Management by Process ?

– Focus is put on Efficiency (ROI driven)
– Priority is put on results at company level
– Ad-hoc organization with leadership at top level
– Improvement axis is more horizontal, i.e. Supply Chain
– Processes are integrated with strategy (Balanced Scorecard)
– Off-the-shelf solutions are chosen (for less Total Cost of Ownership)
– Enterprise-wide view is required to communicate (Enterprise architecture)
As the initiatives are considered from an integrated point of view, I call it the global or horizontal axis.

If you have to assume some BPM responsibility, be sure you are balancing the two axies.

Most of the business process initiatives start coming from a Department which wants to solve a concrete problem first. It is a good starting point.

However, as a coordinator of the whole improvement process, you are facing a major risk: to make your organization more vertical with barriers between the Departments, which make the horizontal operations more difficult.

To mitigate this risk, I see three major actions you should lead at company level, if not implemented yet:
- "Plant your Balanced Scorecard tree" to link Business Process improvement with Strategy
- Define the value chain your organization brings to its stakeholders (customers...)
- Be the Enterprise Architect (also called city planner) of your Business

Dashboard is to envelope, as scorecard is to letter

Dashboards and scorecards are the Holy Grail of business intelligence. With either interface, users can easily and quickly find, analyze, and explore the information they need to perform their jobs. To borrow a term from the telecommunications industry, dashboards and scorecards represent the last mile of wiring connecting users to the data warehousing and analytical infrastructure organizations have created during the past decade.

Industry perceptions

But which is right for you? Although many people use dashboard and scorecard synonymously, there is a subtle distinction between them. Dashboards monitor and measure processes. The common industry perception is that a dashboard is more real-time in nature, like an automobile dashboard that lets drivers check their current speed, fuel level, and engine temperature. So, a dashboard is linked to systems that capture events as they happen, and warns users through alerts or exception notifications when performance against established metrics deviates from the norm.

Scorecards chart progress toward objectives. The common perception of a scorecard is that it displays periodic snapshots of performance associated with an organization's strategic objectives and plans. It measures business activity at a summary level against predefined targets to see if performance is within acceptable ranges. It displays key performance indicators that help executives communicate strategies and help users focus on the highest-priority tasks needed to execute plans.

So, while a dashboard informs users what they are doing, a scorecard tells them how well they are doing. Or, put another way, a dashboard is a performance monitoring system; a scorecard is a performance management system.

Reality blurs the distinctions

In reality, however, these distinctions often fall apart when we examine how organizations use dashboards and scorecards. Most dashboards provide context to evaluate performance. Even indicators on an automobile dashboard provide more than just raw data. The labels on the gauges show when you're speeding, when you need more fuel or have an engine that's overheating. Newer cars even alert drivers with sounds or lighted icons when something needs immediate attention.

Meanwhile, many scorecards provide users with more than just monthly snapshots of summary performance data. Executives use them to empower users to work more productively. The best scorecards provide actionable information--the right data delivered to the right person at the right time. There's no use charting a department's progress if the data arrives too late or without sufficient detail for users to know how to fix a problem or capitalize on a fleeting opportunity.


Using cascading scorecards

Many people believe the term cascading scorecards refers to a series of hierarchical dashboards that align individuals and groups to an organization's overarching strategy. Integrating scorecards throughout the organizational hierarchy can effectively prod the organization to focus on the real drivers of corporate value and performance. Too often, executives create strategies and send them to managers and staff, who are too preoccupied with more immediate concerns, such as meeting budget goals, to concentrate more deeply on executing strategy. Deploying scorecards throughout the organization also shows employees how their actions affect the organization's direction and performance.

Dashboards and scorecards are not mutually exclusive. In fact, the best dashboards and scorecards merge each other's elements. If dashboards don't measure performance against key business objectives, why is the organization engaged in that business activity? If scorecards don't empower users with actionable information to change performance outcomes, what's the point of keeping score?

I like to view a dashboard as the container for performance information, and the scorecard as the content in that container. Or, a dashboard is like an envelope and the scorecard a letter inside it.