For those of you who might have missed last week’s Tech Forum, we started off with the first piece in a mini-series which attempts to compare hype with reality—highlighting the wide gap between what the technology promises and what is achieved in reality.

The purpose of this series is not to criticise everyone and everything around. Rather, the objective is to highlight ways and means to prevent mishaps and to ensure that the promise is actually converted into reality. Last week, as an example, we discussed the hype and reality of Business Intelligence (BI) initiatives. The last article highlighted many shortfalls, lacunae and real life issues that can hamper or interfere with BI initiatives. In this article, the remedies and preventive measures are discussed for all the issues listed in the previous article.

Due to space constraints, I cannot reproduce each issue listed earlier verbatim. I have however provided a short title corresponding to the points raised last week, so you can easily compare them if you need to. Alternatively, check the EC website—Tech Forum is archived online at www.expresscomputeronline.com/ techforum.shtml.

Managing reality

• Lack of user awareness
  The real value of BI initiatives lies in more effective interpretation and understanding of existing information. Therefore, each user role has to be analysed to explore and enlist possibilities of enhancing information assimilation, analysis and decision making. This may mean making the process of using information simpler, more presentable, more usable, more concise and more indicative, rather than just a mere listing of transactions. Once this potential is understood, end users will be more than willing to adapt themselves to the BI initiative.
• Poor database design
  Poor design is typically a result of ad-hoc application development. The data design of business critical systems that have been running for a long time cannot be changed and normalised overnight. Instead, it is simpler to accept the inefficiencies in the data design and move further. The correct way of approaching this problem is to look at any BI initiative as an opportunity for unifying and rationalising database architecture across the enterprise. Generally BI touches multiple applications within an enterprise. Therefore, you should think of all possible ways of generating a data repository which is logical, streamlined, normalised (and denormalised if required), well documented and integrated across heterogeneous applications. This may require specific tasks like scheduled batch processing to decode, simplification of data structures, creation of interim tables, creation of views that cut across applications, evolution of a separate reporting server with optimised data structures and so on. Believe me, this effort is not just useful in BI. It is also very important from the point of EAI and evolution of common business logic components for enterprise reuse.
• Underutilisation of existing reports
  This is a common problem. Usage of reports is inversely proportional to their number! More reports need not mean more information and better decision making. To solve this problem and to ensure that traditional reporting becomes more effective, it is important to analyse what is the exact information needed by users and in what form. Duplicating earlier reports blindly will not lead to better utilisation of information because, in effect, no additional functionality has been created. You need to unearth what exactly it is that users require, to work better and more effectively.
• Excessive features lead to user inundation—not empowerment
  Users are empowered when their effectiveness increases. Excessive features confuse the users. Therefore, it is important to restrict features that are given to end-users. Restricting features may sound like promoting underutilisation of available features. But here the phrase ‘restricting features’ means filtering only those which are useful to the users. Otherwise, you are putting the complete onus of trying out each available feature and then finding out which one is useful onto the end user. Nobody has the time or desire to do this.
• Statutory reporting as a habit
  Utility of existing reports needs to be cross-checked, starting with top management. Most formats were made in the early days of IT when it was assumed that information would be available only periodically, application data would be in islands, processing would take weeks and so on. Now all these presumptions have changed. But the reports remain the same. A rethink of statutory reporting always leads to more effective usage of information.
• Slow reports with large amount of data
  If reports are difficult and time consuming to generate, end-users are bound to utilise them less often, even if the information contained within them is very useful. To handle this problem, you have many choices.

  a. Check if you could reduce the content within these reports so that the speed is better. This is often possible.

  b. Check if you could have a snapshot of data copied periodically on a separate reporting server. Optimise this server for reads rather than writes (unlike OLTP database). Create a departmental or application specific cube to minimise the complexity of runtime joins and SQL processing.

• Slow response to report enhancement requests by IT/vendor
  Why is this response slow? Because changing of reports is a developer task. You need to change queries, stored procedures, batch processes, UI (if the info required is not being captured in the first place), report writer layout and so on. This is definitely a time consuming process. Moreover, from a developer perspective, the project is over when the reports mentioned in the initial specifications are delivered and accepted by users. Requests for report enhancement are looked upon as hindrance rather than as an opportunity to enhance information usage. There again is the problem of a cold war that often exists between IT and end-user departments. Whatever may be the reason, the solution is simple. The IT Team / vendor needs to change their mindset and understand that reporting enhancement requests is a positive sign. That indicates that the users are finding the data more and more useful. If these requests are pursued correctly, this will lead to faster maturation and better utilisation of the application data. Understand that even in-house applications have versions. The second version is based upon the wish list emanating from usage of the first version. Therefore, you need to ensure that there are processes, resources and budgets available to cater to this ongoing process of user request fulfilment.
• Geographically scattered information
  Everyone talks about a unified database. But if points of data capture are geographically distributed, you are only left with one choice—periodic upload of information. This periodicity is typically 2-4 weeks. Making it daily seems to be an inundating task, at least on the face of it. This could be due to bad application design, low bandwidth, inability to flag records to enable incremental upload, poor control over remote sites, and so on. However, with today’s technology, it is very much possible to ensure timely, accurate and daily upload of information from remote sites regardless of the infrastructure and the remote site application environment. I will present you with a live case study illustrating this, in a future column.
• Proactive rather than reactive utility of information
  If data is not available at a frequency that makes effective decision-making possible, user level interest goes down. Making data available well in advance (if not in near-real-time) induces or compels decision-makers to take action. Even if they were not used to it earlier, the very presence of glaring facts in front of them makes them sit up and take notice. In this situation, if they don’t take action, they would be answerable.
• Manual/semi-automated heterogeneous data processing
  This is a common scenario in most organisations. Very often there are specific personnel whose job is to manage the data upload, cleansing, plumbing, decoding, merging, splitting, and so on. Finally they produce some kind of reports which are statutory. Many IT departments are not fully aware of the fact that all these activities can be almost fully automated. There are many ETL tools available now. If you already have at least one copy of SQL Server, you already have one of the most feature-rich ETL tools called Data Transformation Service with you. DTS works with data stored in any RDBMS and format. You need not have your applications on SQL Server at all. Moreover, if you already have your own batch process code, script, etc, it can be easily plugged into DTS. Explore this possibility and try to free human resources that are doing this monotonous and non-challenging activity of data transformation.
• BI Initiatives do not progress beyond a department
  Completion of the BI initiative does not stop at deploying the tool, mapping data structures, duplicating existing reports and providing 10 more toolbars for drilldown and graphs! It finally is dependent upon how much more refined, faster and effective the end-user work has become as a result. If it has had no impact, or worse, has made users confused and inundated, no initiative (leave alone BI) will progress any further. Users will learn any amount of complexity and sophistication provided it
  makes them more effective in their own business role. For example, Business Objects (a very comprehensive BI tool) has taken extra efforts to ensure the User Interface is exactly like Excel. This simplifies usage and increases user acceptance.
• Vendor / IT dependence
  BI tools provide a method of creating a middle tier for reporting purposes. I have worked extensively on Business Objects in this area. The repository maps databases, cubes, ASCII data sources, table structures, joins, views and all such complexity into English (or business) language objects. These objects can be understood easily by users. Once base reporting is over, users need to be trained in using the repository itself to generate their own reports and to enhance existing reports. This will lead to independence from the vendor and the IT department. Moreover, it provides a much more flexible environment for users in a language they understand (business language). Thus acceptance is higher, IT involvement is minimal and information utilisation is most effective.

BI in reality
Here is an example of what I would consider real Business Intelligence. Consider a statutory report of salesperson-wise sales in a quarter. This is a very common report in any organisation. Now, what do you do with it? You compare sales with targets, sales with competitor sales and so on and so forth. What actions are you expected to take based upon this information? One or more of the following:

• Assess the deficiency in sales target coverage and take appropriate action.
• Assess the effectiveness of the sales staff and incentivise them.
• Compare the sale with expected trend and analyse variations, if any.
• Compare the sale with market information to understand the correlation.
• Lastly, as an underlying thought in all organisational activities, increase profit by reducing the cost of selling.

Now let us consider the last point. To understand the cost of selling, you will need to refer to another report, which gives salesperson-wise expenses for the quarter. These are all types of sales expenses including customer entertainment, discounts, special schemes, freebies, events, etc.

Now what is the next obvious thing a sales head would want to do? He would want to correlate the amount of sale with the cost of sale for each salesperson. Invariably there would be all possible combinations. The person who obtained higher revenues need not have spent a high amount. Similarly a person who has incurred considerable sales expenses may not have got in more business. And then there could be persons who have spent in proportion to sales.

Thus you may have to decide a benchmark which is the allowable expense percentage based upon the sales figure. You would also want to know both the extremes. You want a report where at least the following two lists are available:

1. List of sales persons who have spent above the expenditure norm and yet have not accrued good sales figures.
2. List of sales persons who have achieved high sales while keeping the sales expenses well below the defined norm.

What do you do with this information? Again it is obvious—category 2 needs to be rewarded and category 1 needs to be grilled.

Now, why am I giving such a long story? Because a decision-maker has to go through such a long process to arrive at these two simple lists which are action items for him! He has to go to multiple places to generate interim reports, calculate average sales expense and decide allowable expense norm, recast all reports according to the expense limit percentage, go to the top and bottom of sales as well as expenses list and correlate the figures, and then finally arrive at good and bad performers.

So where is the business intelligence? Here is a practical definition in the context of this example. If you can give a simple report that contains the two final lists directly in a single step to the decision-maker, you have achieved Business Intelligence.

Please note that till this stage there is no need for any drilldown or graphs. It is a simple, common business analysis need converted and made easily available using technology (the names of technologies do not matter to end-users. The impact of technology matters).

Now if you have achieved this type of BI, the same user will tell you a hundred more such scenarios upfront. At that time, if you have a flexible BI tool at hand and you have already created an enterprise level repository based upon all your heterogeneous data sources, all that you need to do to implement BI for him is to train him on the toolbars and options of the BI tool. The only difference is, now the user will be more than willing and excited to learn it and use it effectively because he really feels empowered!

Conclusion
Hype and reality are really far apart in today’s world of IT. However, one technology that can not only bridge the gap but also assure you of guaranteed success has always been there with us. It is called CS. No, it is not another piece of jargon. It is simply Common Sense!

Did you find this useful?
Do give me your feedback about the utility of the “Hype v/s Reality” series. If your feedback indicates that this type of critical yet constructive content helps you in managing IT better, I will pursue this series further.

Feedback
Your feedback, suggestions, requests for covering specific topics or issues are welcome. Please send feedback to techforum@mediline.co.in

About the Author Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in