Maureen Clarry stresses the need for change skills in business intelligence on BeyeNetwork

12 May 2009

The article

beyenetwork2

Maureen Clarry begins her latest BeyeNETWORK article, Leading Change in Business Intelligence, by stating:

If there was a standard list of core competencies for leaders of business intelligence (BI) initiatives, the ability to manage complex change should be near the top of the list.

I strongly concur with Maureen’s observation and indeed the confluence of BI and change management is a major theme of this blog; as well as the title of one of my articles on the subject. Maureen clearly makes the case that “business intelligence is central to supporting [...] organizational changes” and then spends some time on Prosci’s ADKAR model for leading change; bringing this deftly back into the BI sphere. Her closing thoughts are that such a framework can help a lot in driving the success of a BI project.
 
 
My reflections

I find it immensely encouraging that an increasing number of BI professionals and consultants are acknowledging the major role that change plays in our industry and in the success of our projects. In fact it is hard to find some one who has run a truly successful BI project without paying a lot of attention to how better information will drive different behaviour – if it fails to do this, then “why bother?” as Maureen succinctly puts it.

Without describing it as anything so grand as a framework, I have put together a trilogy of articles on the subject of driving cultural transformation via BI. These are as follows:

• Marketing Change
• Education and cultural transformation
• Sustaining Cultural Change

However the good news about many BI professionals and consultants embracing change management as a necessary discipline does not seem to have filtered through to all quarters of the IT world. Many people in senior roles still seem to see BI as just another technology area. This observation is born out of the multitude of BI management roles that request an intimate knowledge of specific technology stacks. These tend to make only a passing reference to experience of the industry in question and only very infrequently mention the change management aspects of BI at all.

Of course there are counterexamples, but the main exceptions to this trend seem to be where BI is part of a more business focused area, maybe Strategic Change, or the Change Management Office. Here it would be surprising if change management skills were not stressed. When BI is part of IT it seems that the list of requirements tends to be very technology focussed.

In an earlier article, BI implementations are like icebergs I argued that, in BI projects, the technology – at least in the shape of front-end slice-and-dice tools – is not nearly as important as understanding the key business questions that need to be answered and the data available to answer them with. In “All that glisters is not gold” – some thoughts on dashboards, I made similar points about this aspect of BI technology.

I am not alone in holding these opinions, many of the BI consultants and experienced BI managers that I speak to feel the same way. Given this, why is there the disconnect that I refer to above? It is a reasonable assumption that when a company is looking to set up a new BI department within IT, it is the CIO who sets the tone. Does this lead us inescapably to the the conclusion that many CIOs just don’t get BI?

I hope that this is not the case, but I see increasing evidence that there may be a problem. I suppose the sliver lining to this cloud is that, while such attitudes exist, they will lead to opportunities for more enlightened outfits, such as the one fronted by Maureen Clarry. However it would be even better to see the ideas that Maureen espouses moving into the mainstream thinking of corporate IT.
 

 
Maureen Clarry is the Founder and President/CEO of CONNECT: The Knowledge Network, a consulting firm that specializes in helping IT people and organizations to achieve their strategic potential in business. CONNECT was recognized as the 2000 South Metro Denver Small Business of the Year and has been listed in the Top 25 Women-Owned Businesses and the Top 150 Privately Owned Businesses in Colorado. Maureen also participates on the Data Warehousing Advisory Board for The Daniels College of Business at the University of Denver and was recognized by the Denver Business Journal as one of Denver’s Top Women Business Leaders in 2004. She has been on the faculty of The Data Warehousing Institute since 1997, has spoken at numerous other seminars, and has published several articles and white papers. Maureen regularly consults and teaches on organizational and leadership issues related to information technology, business intelligence and business.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | Stumble

 

3 Comments | business, business intelligence, change management, cultural transformation, education, it business alignment, management, management information, technology | Tagged: , , , , , , , , , , | Permalink
Posted by Peter Thomas

Mountain Biking and Systems Integration

12 May 2009

Introduction

Mountain Biking

This is another in my occasional series in which I draw conclusions about business, technology and change from my experiences in various of the sports that I enjoy. The first article in this series was Perseverance, which compared the degree of effort required to succeed in rock climbing with that necessary in change management. Here I am going to focus on another of my pastimes, mountain biking.
 
 
Some background on Mountain Biking

Mountain biking (invariably abbreviated to MTBing, with the bikes themselves called MTBs) is something that I have got into more recently than rock climbing, but I suppose there are some parallels between the two. My path into rock climbing started with loving walking in the outdoors, which became hill-walking, which became scrambling (hill-walking where you have to use your hands to get through steeper sections), which eventually became rock climbing. Starting at the same place, MTBing is another logical progression from general and hill-walking. While rock climbing was about increasing the angle at which I moved (to vertical and then over-hanging), MTBing was about increasing my speed.

Another thing that rock climbing and MTBing have in common is their adherents’ obsession with equipment. With rock climbing this ranges from the shoes you use, to bouldering mats, to ropes, to the various pieces of equipment that you use to protect yourself. With MTBing, the focus is mostly on the bike itself.

There are two main types of mountain bikes: hard tails and full suspension bikes. Hard tails have a shock absorber at the front, but the rear is essentially the same as in a road bike. An example of two hard tails appears below – these are actually my bike and my partner’s, both rather muddy from a day out.

Two hard tail mountain bikes

Two hard tail mountain bikes

Full suspension bikes (as the name suggests) have suspension at both front and rear. The fact that you also need to drive the suspended rear wheel with the pedals makes these types of bikes much more complicated from an engineering perspective (and inevitably more expensive). While some zealots aver that all you ever really need is a hard tail, regardless of the conditions, the majority accept that a full suspension MTB will allow you to take on more challenging terrain with greater comfort and security. It is full suspension bikes that I will devote the rest of this article to.
 
 
The anatomy of a full suspension mountain bike

The following is a diagram showing the general anatomy of a full suspension bike; the UK version of a Specialized Stumpjumper FSR Elite (the US one currently being black). The image is copyright Specialized, one of the most well-know bike manufacturers, but the annotations are mine.

Full suspension mountain bike. Image © Specialized Bicycle Components

Full suspension mountain bike. Photo © Specialized Bicycle Components

As you might expect, one of the major factors influencing the performance of a MTB is the frame – this is the main structure of the bike, generally made from steel or alloy tubing, or sometimes carbon fibre in more expensive models. Helpfully in the diagram, the frame is essentially all the white bits. As we are talking about a full suspension bike, the back of the frame needs to flex in order to allow the rear wheel to move up and down.

The above design is for a cross country bike. This is the least aggressive type of MTBing and consequently places least stress on the frame. In this bike, the seat and chain stays (the triangular white bits at the back extending back to meet at the axle of the rear wheel) are both pivoted and their movement is damped by the rear shock absorber. In more full-on types of mountain biking (all mountain, free ride and down hill) the bikes can begin to resemble tanks – think of a 4×4 (SUV) compared to a regular car. Designs with a single, beefy swing arm at the rear are more common in these types of bikes.

However it is not the frame that I really want to focus on here, but the other components that go to make up the bike. Most of these are labelled in the diagram. Sometimes a bike comes complete with all of these and ready to ride. Other times you buy the frame only (or maybe the frame and shocks) and then add the other components that you would like to have. In this second approach the idea is to tailor the components to the type of riding that you want to do and of course to your wallet.

Often, even with a ready-to-ride bike, the owner might decide to upgrade some components, for example by purchasing a better front fork. Some of the manufacturers will sell you a ready to ride bike that has essentially all of their own components, but even then it is highly likely that the equipment for pedalling, changing gears and braking will be made by another organisation. On the bike in the diagram above, a lot of the components are from manufacturers other than Specialized. The range of other companies involved in the above bike includes:

  • Fox – the front and rear shock absorbers
  • SRAM – the chain
  • Shimano – the crank arm, chain rings, pedals, front and rear derailleurs, gear shifters and rear sprocket
  • Avid – the brake assemblies and levers (Avid are now part of SRAM)
  • DT Swiss – the rear hub (the front one being by Specialized)

It is also worth noting that Specialized, more than most other frame manufacturers, are known for producing their own components – they even make the shock absorbers for many of their models. On a bike from another company, the seat post, saddle, head stem, handle bars and tyres would all also be from another organisation; often different ones to those listed above.
 
 
The connection with Systems Integration

While, as mentioned above, the frame plays a very important role in determining how well a bike performs (and it is generally the most expensive part of the bike), what really leads to a great bike is how all of the different components are blended together. While Component A may be great on Frame X, working with Component B, it will be a much less good choice for Frame Y, working with Component C. The other factor that comes into this is of course cost and this makes a balance even harder to find.

It is in the above area that I see some similarities with systems integration. Here too the aim is to make products from different organisations work in harmony in order to deliver the greatest level of effectiveness at the lowest cost. Here too trade-offs will be necessary to meet the often incompatible goals of performance/functionality and cost. In systems integration, as in MTBing above, Product A may work well with Product B in Industry X, but be a bad option to run with Product C in Industry Y.
 
 
The most expensive is not necessarily the best

An interesting observation in MTBing is that simply picking the most expensive component in each category will not necessarily lead to the best performing bike. Some components suit the geometry of some bikes and work well in conjunction with other components regardless of cost. Here is just one example from a review of a bike in a magazine I subscribe to, Mountain Bike Rider (or MBR). The bike in question is a Giant Trance X5 and it just came first in MBR’s review of full suspension bikes under £1,000 ($1,500 – though it is probably cheaper than that in the US). This bike received a rating of 9/10 from MBR. Here is a picture of it:

Giant X5 full suspension mountain bike. Image © Giant U.K. Ltd

Giant X5 full suspension mountain bike. © Giant U.K. Ltd

This bike features an OEM rear shock as below (image copyright MBR):

Giant rear shock. © MBR magazine

Giant rear shock. © MBR magazine

Here is what MBR had to say about it (note that Fox – whose shocks were featured on the Specialized Stumpjumper above – produce both the most respected and most expensive shocks in the industry):

We found this presumably cheap own-brand unit to be the best we’ve ridden on a Maestro linkage [the type of rear pivot arrangement featured on the bike], whether by chance or design. It felt like it had less compression damping and married with the linkage better than any Fox unit we’ve tried. It was a lot more active, allowing the Maestro design to track the terrain better on this bike than on any other Giant Trance we’ve ridden previously.

It is worth noting that MBR terminology can be just as confusing as IT jargon until you get used to it. The above quote is actually relatively light on terminology.
 
 
Closing thoughts

While it is dangerous to extend some analogies too far, I think that there is something to be learnt here about how to run systems integration projects. It is the systems that work best with the other parts of the design that should be selected, not those that have the best features when considered in isolation, or those that come from the most prestigious companies.

It used to be said that buying the products of some IT vendors was a sure way to avoid getting fired (the vendors mentioned have varied over time). The above insight from the world of mountain biking suggests that looking beyond the obvious (and often more expensive) products may sometimes yield significant benefits.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | Stumble

 

5 Comments | business, systems integration, technology | Tagged: , , , , , , , , , , , , , | Permalink
Posted by Peter Thomas

Business Intelligence Competency Centres

11 May 2009

Introduction

The subject of this article ought to be reasonably evident from its title. However there is perhaps some room for misinterpretation around even this. Despite the recent furore about definitions, most reasonable people should be comfortable with a definition of business intelligence. My take on this is that BI is simply using information to drive better business decisions. In this definition, the active verb “drive” and the subject “business decisions” are the key elements; something that is often forgotten in a rush for technological fripperies.
 
 
The central issue

Having hopefully addressed of the “BI” piece of the BICC acronym, let’s focus on the “CC” part. I’ll do this in reverse order, first of all considering what is meant by “centre”. As ever I will first refer to my trusted Oxford English Dictionary for help. In a discipline, such as IT, which is often accused of mangling language and even occasionally using it to obscure more than to clarify, a back-to-basics approach to words can sometimes yield unexpected insights.

  centre / séntər / n. & v. (US center) 3 a a place or group of buildings forming a central point in a district, city, etc., or a main area for an activity (shopping centre, town centre).
(O.E.D.)		  

Ignoring the rather inexcusable use of the derived adjective “central” in the definition of the noun “centre”, then it is probably the “main area for an activity” sense that is meant to be conveyed in the final “C” of BICC. However, there is also perhaps some illumination to be had in considering another meaning of the word:

Centre of a Sphere

  n. 1 a the middle point, esp. of a line, circle or sphere, equidistant from the ends, or from any point on the circumference or surface.
(O.E.D.)		  

As well as appealing to the mathematician in me, this meaning gives the sense that a BICC is physically central geographically, or metaphorically central with respect to business units. Of course this doesn’t meant than a BICC needs to be at the precise centre of gravity of an organisation, with each branch contributing a “weight” calculated by its number of staff, or revenue; but it does suggest that the competency centre is located at a specific point, not dispersed through the organisation.

Of course, not all organisations have multiple locations. The simplest may not have multiple business units either. However, there is a sense by which “centre” means that a BICC should straddle whatever diversity there is an organisation. If it is in multiple countries, then the BICC will be located in one of these, but serve the needs of the others. If a company has several different divisions, or business units, or product streams; then again the BICC should be a discrete area that supports all of them. Often what will make most sense is for the BICC to be located within an organisation’s Head Office function. There are a number of reasons for this:

  1. Head Office similarly straddles geographies and business units and so is presumably located in a place that makes sense to do this from (maybe in an organisation’s major market, certainly close to a transport hub if the organisation is multinational, and so on).
  2. If a BICC is to properly fulfil the first two letters of its abbreviation, then it will help if it is collocated with business decision-makers. Head Office is one place than many of these are found, including generally the CEO, the CFO, the Head of Marketing and Business Unit Managers. Of course key decision makers will also be spread throughout the organisation (think of Regional and Country Managers), but it is not possible to physically collocate with all of these.
  3. Another key manager who is hopefully located in Head Office is the CIO (though this is dispiritingly not always the case, with some CIOs confined to IT ghettos, far from the rest of the executive team and with a corresponding level of influence). Whilst business issues are pre-eminent in BI, of course there is a major technological dimension and a need to collaborate closely with those charged with running the organisation’s IT infrastructure and those responsible for care and feeding of source data systems.
  4. If a BI system is to truly achieve its potential, then it must become all pervasive; including a wide range of information from profitability, to sales, to human resources statistics, to expense numbers. This means that it needs to sit at the centre of a web of different systems: ERP, CRM, line of business systems, HR systems etc. Often the most convenient place to do this from will be Head Office.

Thusfar, I haven’t commented on the business benefits of a BICC. Instead I have confined myself to explaining what people mean by the second “C” in the name and why this might be convenient. Rather than making this an even longer piece, I am going to cover both the benefits and disadvantages of a BICC in a follow-on article. Instead let’s now move on to considering the first “C”: Competency.
 
 
Compos centris

Returning to our initial theme of generating insights via an examination of the meaning of words in a non-IT context, let’s start with another dictionary definition:

Motar board

  competence /kómpit’nss/ n. (also competency /kómpitənsi/) 1 (often foll. by for, or to + infin.) ability; the state of being competent.

and given the recursive reliance of the above on the definition of competent…
  competent /kómpit’nt/ adj. 1 a (usu. foll. by to + infin.) properly qualified or skilled (not competent to drive); adequately capable, satisfactory. b effective (a competent bastman*).
(O.E.D.)		  

* People who are not fully conversant with the mysteries of cricket may substitute “batter” here.

To me the important thing to highlight here is that, while it is to be hoped that a BICC will continue to become more competent once it is up and running, in order to successfully establish such a centre, a high degree of existing competence is a prerequisite. It is not enough to simply designate some floor space and allocate a number of people to your BICC, what you need is at least a core of seasoned professionals who have experience of delivering transformational information and know how to set about doing it.

There are many skills that will be necessary in such a group. These match the four main pillars of a BI implementation (I cover these in more depth in several places on the blog, including BI implementations are like icebergs and the middle section of Is outsourcing business intelligence a good idea?):

  1. Understand the important business decisions and what figures are necessary to support these.
  2. Understand the data available in the organisation, how it relates to other data and to business decisions.
  3. Transform the data to provide information answering business questions.
  4. Focus on embedding the use of information in the corporate DNA.

So a successful BICC must include: people with strong analytical skills and an understanding of general business practices; high-calibre designers; reliable and conscientious ETL and general programmers; experts in the care, feeding and design of databases; excellent quality assurance professionals; resource conversant with both whatever front-end tools you are using to deliver information and general web programming; staff with skills in technical project management; people who can both design and deliver training programmes; help desk personnel; and last, but by no means least, change managers.

Of course if your BI project is big enough, then you may be able to afford to have people dedicated to each of these roles. If resources are tighter (and where is this not the case nowadays?) then it is better to have people who can wear more than one hat: business analysts who can also design; BI programmers who will also take support calls; project managers who will also run training classes; and so on. This approach saves money and also helps to deal with the inevitable peaks and troughs of resource requirements at different stages in a project. I would recommend setting things up this way (or looking to stretch your people’s abilities into new areas) even if you have the luxury of a budget that would allow a more discrete approach. The challenge of course is going to be finding and retaining such multi-faceted staff.

Also, it hopefully goes without saying that BI is a very business-focussed area and some BICCs will explicitly include business people in them. Even if you do not go this far, then the BICC will have to form a strong partnership with key business stakeholders, often spread across multiple territories. The skill to manage this effectively is in itself a major requirement of the leading personnel of the centre.

Given all of the above, the best way to staff a BICC is with members of a team who have already been successful with a BI project within your organisation; maybe one that was confined to a given geographic region or business unit. If you have no such team, then starting with a BICC is probably a bridge too far. Instead my recommendation would be to build up some competency via a smaller BI project. Alternatively, if you have more than one successful BI team (and, despite the manifold difficulties in getting BI right, such things are not entirely unheard of) then maybe blending these together makes sense. This is unless there is some overriding reason not to (e.g. vastly different team cultures or methodologies. In this case, picking a “winner” may be a better course of action.

Such a team will already have the skills outlined above in abundance (else they could never have been successful). It is also likely that whatever information was needed in their region or business unit will be at least part of what is needed at the broader level of a BICC. Given that there are many examples of BI projects not delivering or consuming vastly more resource than anticipated, then leveraging those exceptional people who have managed to swim against this tide is eminently sensible. Such battle-hardened professionals will know what pitfalls to avoid, which areas are most important to concentrate on and can use their existing products to advertise the benefits of a wider system. If you have such people at the core of your BICC, then it will be easier to integrate new joiners and quickly shepherd them up the learning curve (something that can be particularly long in BI due to the many different aspects of the work).

Of course having been successful in one business unit or region is not enough to guarantee success on a larger scale. I spoke about some of the challenges of doing this in an earlier article, Developing an international BI strategy. Another issue that is likely to raise its head is the political dimension, in particular where different business units or regions already have a management information strategy at some stage of development. This is another area that I will also cover in more detail in a forthcoming piece.
 
 
Conclusions

It seems that simply musing on the normal meanings of the words “competency” and “centre” has led us into some useful discussions. As mentioned above, at least two other blog postings will expand upon areas that have been highlighted in this piece. For now what I believe we have learned so far is:

  • BICCs should (by definition) straddle multiple geographies and/or business units.
  • There are sound reasons for collocating the BICC with Head Office.
  • There is need for a wide range of skills in your BICC, both business-focussed and technical.
  • At least the core of your BICC should be made up of competent (and experienced) BI professionals .

More thoughts on the benefits and disadvantages of business intelligence competency centres and also the politcs that they have to negotiate will appear on this blog in future weeks.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 

12 Comments | business, business intelligence, business intelligence competency centres, change management, cultural transformation, international projects, management, management information, project management, technology | Tagged: , , , , , | Permalink
Posted by Peter Thomas

More problems for Googlemail

8 May 2009

Googlemail failure (note the 'Beta' in small type by the logo)

Back on February 24th 2009, there was a major outage of Google‘s on-line mail service, googlemail, or gmail as it was originally called. I posted an article covering this back then.

Today Googlemail had another outage – it is still down as I type. Indeed the Twitterverse is rapidly filling up with tweets mentioning #googlemail and #fail.

While a very wide range of people use Google’s mail service and this hiatus may be no more than an inconvenience for many (and an excuse to tweet for others – not that many people need one of these nowadays), it is more serious for people who rely on Googlemail professionally. At one end of the spectrum are those organisations who have outsourced their corporate mail to Google. That is where mail to and from john.smith@bigcompany.com is actually supported on Google’s infrastructure. But it is also bad news for the many independent consultants who rely on Googlemail for communication, be that with a googlemail.com extension, or (in the same way as with large companies) using ace.consultant@mycompany.com.

In many ways communication failures may be more serious for this second group. Customers of large organisations will probably come back again, but consulting opportunities may be missed and deadlines lapse for the want of e-mail availability.

Before I spread too much doom and gloom, I should offer the perspective that I have never come across an e-mail system (corporate or otherwise) that didn’t crash sometimes, the beast just doesn’t exist. However, Google are a victim of their own stability. Because Googlemail is reliable 99.9% of the time (I have no idea about the real value, but would assume it is in the high 99s), we come to expect it to be there, even though it is essentially free (OK subsidised by in-line advertising if you will).

The very fact that the service is very reliable makes it even more annoying when it fails. No one grumbles much when twitter.com doesn’t work, because it is always failing. Perhaps Google’s strategy should be to have more frequent problems with Googlemail, so that users expectations are set at a more realistic level.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 

2 Comments | business, google, technology | Tagged: , , | Permalink
Posted by Peter Thomas

The importance of feasibility studies in business intelligence

6 May 2009

Introduction

Feasibility Study

In a previous article, A more appropriate metaphor for business intelligence projects, I explained one complication of business intelligence projects. This is that the frequently applied IT metaphor of building is not very applicable to BI. Instead I suggested that BI projects had more in common with archaeological digs. I’m not going to revisit the reasons for the suitability of looking at BI this way here, take a look at the earlier piece if you need convincing, instead I’ll focus on what this means for project estimation.

When you are building up, estimation is easier because each new tier is dependent mostly on completion of the one below, something that the construction team has control over (note: for the sake of simplicity I’m going to ignore the general need to dig foundations for buildings). In this scenario, the initial design will take into account of facts such as the first tier needing to support all of the rest of the floors and that central shafts will be needed to provide access and deliver essential services such as water, electricity and of course network cables. A reductionist approach can be taken, with work broken into discrete tasks, each of which can be estimated with a certain degree of accuracy. The sum of each of these, plus some contingency, hopefully gives you a good feel for the overall project. It is however perhaps salutary to note that even when building up (both in construction and in IT) estimation can still sometimes go spectacularly awry.

When you are digging down, your speed is dependent on what you find. Your progress is dictated by things that are essentially hidden before work starts. If your path ahead (or downwards) is obscured until your have cleared enough earth to uncover the next layer, then each section may hold unexpected surprises and lead to unanticipated delays. While it may be possible to say things like, “well we need to dig down 20m and each metre should take us 10 days”, any given metre might actually take 20 days, or more. There are two issues here; first it is difficult to reduce the overall work into tasks, second it is harder to estimate each task accurately. The further below ground a phase of the dig is, the harder it will be to predict what will happen before ground is broken. Even with exploratory digs, or the use of scanning equipment, this can be very difficult to assess in advance. However it is to the concept of exploratory digs that this article is devoted.
 
 
Why a feasibility study is invaluable

At any point in the economic cycle, even more so in today’s circumstances, it is not ideal to tell your executive team that you have no idea how long a project will take, nor how much it might cost. Even with the most attractive of benefits to be potentially seized (and it is my firm belief that BI projects have a greater payback than many other types of IT projects), unless there is some overriding reason that work must commence, then your project is unlikely to gain a lot of support if it is thus characterised. So how to square the circle of providing estimates for BI projects that are accurate enough to present to project sponsors and will not subsequently leave you embarrassed by massive overruns?

It is in addressing this issue that BI feasibility studies have their greatest value. These can be thought of as analogous to the exploratory digs referred to above. Of course there are some questions to be answered here. By definition, a feasibility study cannot cover all of the ground that the real project needs to cover, choices will need to be made. For example, if there are likely to be 10 different data sources for your eventual warehouse, then should you pick one and look at it in some depth, or should you fleetingly examine all 10 areas? Extending our archaeological metaphor, should your exploratory dig be shallow and wide, or a deep and narrow borehole?
 
 
A centre-centric approach

In answering this question, it is probably worth considering the fact that not all data sources are alike. There is probably a hierarchy to them, both in terms of importance and in terms of architecture. No two organisations will be the same, but the following diagram may capture some of what I mean here:

Two ways of looking at a systems' hierarchy

Two ways of looking at a systems' hierarchy

The figure shows a couple of ways of looking at your data sources / systems. The one of the left is rather ERP-centric, the one on the right gives greater prominence to front-end systems supporting different lines of business, but wrapped by a common CRM system. There are many different diagrams that could be drawn in many different ways of course. My reason for using concentric circles is to stress that there is often a sense in which information flows from the outside systems (ones primarily focussed on customer interactions and capturing business transactions) to internal systems (focussed on either external or internal reporting, monitoring the effectiveness of processes, or delivering controls).

There may be several layers through which information percolates to the centre; indeed the bands of systems and databases might be as numerous as rings in an onion. The point is that there generally is such a logical centre. Data is often lost on its journey to this centre by either aggregation, or by elements simply not being transferred (e.g. the name of a salesperson is not often recorded on revenue entries in a General Ledger). Nevertheless the innermost segment of the onion is often the most complex, with sometimes arcane rules governing how data is consolidated and transformed on its way to its final destination.

The centre in both of the above diagrams is financial and this is not atypical if what we are considering is an all-pervasive BI system aimed at measuring most, if not all, elements of an organisation’s activity (the most valuable type of BI system in my opinion). Even if your BI project is not all-pervasive (or at least the first phase is more specific), then the argument that there is a centre will probably still hold, however the centre may not be financial in this case.

My suggestion is that this central source of data (of course there may be more than one) is what should be the greatest focus of your feasibility study. There are several reasons for this, some technical, some project marketing-related:

  1. As mentioned above, the centre is often the toughest nut to crack. If you can gain at least some appreciation of how it works and how it may be related to other, more peripheral systems, then this is a big advance for the project. Many of the archaeological uncertainties referred to above will be located in the central data store. Other data sources are likely to be simpler and thus you can be more confident about approaching these and estimating the work required.
  2. A partial understanding of the centre is often going to be totally insufficient. This is because your central analyses will often have to reconcile precisely to other reports, such as those generated by your ERP system. As managers are often measured by these financial scorecards, if you BI system does not give the same total, it will have no credibility and will not be used by these people.
  3. Because of its very nature, an understanding of the centre will require at least passing acquaintance with the other systems that feed data to it. While you will not want to spend as much time on analysing these other systems during the feasibility study, working out some elements of how they interact will be helpful for the main project.
  4. One output from your feasibility study should be a prototype. While this will not be very close to the finished article and may contain data that is both unreconciled and partial (e.g. for just one country or line of business), it should give project sponsors some idea of what they can expect from the eventual system. If this prototype deals with data from the centre then it is likely to be of pertinence to a wide range of managers.
  5. Strongly related to the last point, and in particular if the centre consists of financial data, then providing tools to analyse this is likely to be something that you will want to do early on in the main project. This is both because this is likely to offer a lot of business value and because, if done well, this will be a great advert for the rest of your project. If this is a key project deliverable, then learning as much as possible about the centre during the feasibility study is very important.
  6. Finally what you are looking to build with your BI system is an information architecture. If you are doing this, then it makes sense to start in the middle and work your way outwards. This will offer a framework off of which other elements of your BI system can be hung. The danger with starting on the outside and working inwards is that you can end up with the situation illustrated below.

A possible result of building from the outside in to the center

A possible result of building from the outside in to the centre


 
Recommendations

So my recommendation is that your feasibility study is mostly a narrow, deep dig, focussed on the central data source. If time allows it would be beneficial to supplement this with a more cursory examination of some of the data sources that feed the centre, particularly as this may be necessary to better understand the centre and because it will help you to get a better idea about your overall information architecture. You do not need to figure out every single thing about the central data source, but whatever you can find out will improve the accuracy of your estimate and save you time later. If you include other data sources in a deep / wide hybrid, then these can initially be studied in much less detail as they are often simpler and the assumption is that they will support later deliveries.

The idea of a prototype was mentioned above. This is something that is very important to produce in a feasibility study. Even if we take to one side the undeniable PR value of a prototype, producing one will allow you to go through the entire build process. Even if you do this with hand-crafted transformation of data (rather than ETL) and only a simplistic and incomplete approach to the measures and dimensions you support, you will at least have gone through each of the technical stages required in the eventual live system. This will help to shake out any issues, highlight areas that will require further attention and assist in sizing databases. A prototype can also be used to begin to investigate system and network performance, things that will influence your system topology and thereby project costs. A better appreciation of all of these areas will help you greatly when it comes to making good estimates.

Having understood quite a lot about your most complex data source and a little about other ones and produced a prototype both as a sales tool and to get experience of the whole build process, you should have all the main ingredients for making a credible presentation to your project sponsors. In this it is very important to stress the uncertainties inherent in BI and manage expectations around these. However you should also be very confident in stating that you have done all that can be done to mitigate the impact of these. This approach, of course supported by a compelling business case, will position you very well to pitch your overall BI project.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 

3 Comments | bi and the economic crisis, business, business intelligence, data warehousing, management information, project management, technology | Tagged: , , , , , | Permalink
Posted by Peter Thomas

Bank Holiday weekend, followed by a busy week

5 May 2009

Monday 4th May was a public holiday in the UK and I seem to have been up-to-my-eyes so far this week. After a quiet week blogging last week, normal service should be resumed in the new few days.

Peter
 

Leave a Comment » | site update | Permalink
Posted by Peter Thomas

Next Entries »
Follow

Get every new post delivered to your Inbox.

Join 3,026 other followers