Thursday, September 23, 2010

Good, Bad, Dirty, Ugly SAP Implementation


 

Many SAP Implementation were stated as "successfully" implemented, indeed these are 'Unsuccessful' because of these six factors which were listed. The following paragraphs elaborate on the six factor groups which could be useful to those implanting or just implemented.


 

Factor 1: Worked with SAP functionality/maintained scope

A crucial part of working with the SAP functionality is the ability to streamline operations. When implementing a system, many organizations fail to specify their organizational objectives. Job skills are raised by the requirements of the new, post-implementation company. Idiosyncratic ways of doing business, which were manageable, although most likely inefficient, under the "old system", are no longer tolerated. Companies that do not understand these issues early on will face serious problems. Successful companies have recognized the importance of "cleaning up" their operations, which will allow them to implement "vanilla" SAP – with minimal customization.

Even though the so-called "vanilla" approach is adopted by two-thirds of implementing companies, some customization will always be required in order to meet individual needs . The key, it appears, is to know just how much to customize. For example - Colgate-Palmolive, a $9 billion consumer products manufacturer, implemented SAP in 41 countries in 1998. Installing an integrated computer system at this level of magnitude would be a daunting project for anyone. A direct quote from Ed Toben, CIO of Colgate-Palmolive, puts the plan into clear terms: "This is complicated stuff, you have to do anything you can to simplify it" (Stedman, 1999). The ability to implement SAP with minimal customization requires assistance from several other factors, primarily streamlining operations and re-engineering the business – both of which will help the organization to run in a more straightforward manner. Thorough planning is also a close partner, as it is threaded through the plans from scope to budgets. Scope is the initial "blueprint" of an implementation plan. Within this original plan, budgetary and resource needs are established. During the course of the project, it can be easy, often transparently so, to become so involved in details that additional responsibilities or requirements are added or affected. Suddenly, but often too late, the realization comes that the project is a victim of "scope creep". The ability to maintain scope is closely related to planning, and it is possible to achieve for companies both large and small. Colgate-Palmolive Company also listed scope maintenance as a factor to their success.

Factor  

% Contributed for Success  

% Contributed for Unsuccessful l/ Failure

Worked with SAP functionality/maintained scope

High ( 55% ) 

Low  

Project team/management support/consultants

High ( 49% ) 

Medium 33%

Internal readiness/training 

Medium (41%) 

High 53% 

Deal with organizational diversity 

Low 31%

High 40%

Planning/development/budgeting 

Low 20%

45% ( High )

Adequate testing 

Low 10%

33% ( Medium )


 


 

Maintaining scope is just as important for small companies as it is for large organizations. The approach for "rolling out" their implementation is another very important consideration under the SAP functionality/scope umbrella. Much has been said about "big bang" approaches and gradual rollout of modules within a company. There is no evidence that any one way is better than another as a whole; however, one approach will be better for companies on an individual basis. There have been many widely publicized "big bang" successes, and many failures. The same is true for gradual (phased) rollouts, although these generally are not headline-grabbers. I know , Chevron, a $43 billion oil giant, attributes a phased rollout to their success. They successfully implemented SAP and replaced over 250 legacy systems on a global basis using the phased approach. By implementing gradually, they were able to catch any "bugs" before moving forward, thereby avoiding any catastrophic, system-wide problems. Amoco, Merisel and Owens Corning are examples of other companies who chose to take a gradual rollout approach, and who consider the decision a contributor to their success. Home Depot has successfully implemented several modules around the world, and utilized the phased rollout approach. The phased rollouts take longer to complete, and are more expensive due to the additional time commitment; however, the approach does offer a reduced business risk . Only one of the companies analyzed cited SAP core functionality as a problem. Sobey's, an $89 million Canadian grocery chain, did not feel SAP could handle its requirements, and prematurely abandoned the implementation process. For the most part, companies, even the ones who experienced miserable, expensive failure, agree that SAP will perform as advertised.


 

Factor 2: project team/management support/consultants

The successful project team is cross-functional, consisting of the most knowledgeable

people in the organization. The team, at all times, must be dedicated solely to the project, and have no other responsibilities within the company. Lockheed Martin, a leading aeronautical group, stated one of its keys to success was "assembling a team capable of making and executing" the changes required .


 

A successful implementation is only achievable when high-level executives have a strong commitment to the project . The attitude of senior managers will affect not only the flow of funds and information to the project, but also the subordinates view the project, its future impact upon the company as a whole, and its impact upon the employees as valued and capable individuals. Fujitsu Microelectronics, an international manufacturer of semiconductors, successfully completed its ERP implementation within ten months. They attribute success in part to top management support. During the entire project, company management provided substantial incentives to team members, and ensured that internal communication channels were open at all times. GTE completed 11-month integration not only on time and within budget, but also without the aid of an outside consulting firm. Again, top management was a primary factor cited for their success. Senior management at Farmland Industries showed its support of the process by providing bonuses to employees and consultants. The project members were charged with ensuring that not only technical goals were met, but also that the "people" element and business changes were taken care of at the same time . Farm Land had the foresight to understand that an ERP system was not only a significant technical change, but also a massive cultural change. As stated earlier, and reinforced with these examples, the ERP software can be designed to work perfectly well, but lacking top management support, the project is destined to fail. Senior management has the authority and responsibility to support the project internally through incentives and bonuses, and externally through maintaining open and effective communication channels and a reassuring, positive attitude. By constantly exposing the positive benefits and results of such an endeavor throughout the implementation process, success is much more likely to occur.


 

Factor 3: internal readiness/training


 

The "people element" and training aspect of an ERP implementation have historically received the least amount of attention. The paradox of this is that when this factor is ignored or downplayed, primarily because it does not have the largest quantifiable benefit, expenses are greatly increased in the long run. By treating resource training with little regard and financial support, it is not hard to realize the reality of delay, confusion and financial ruin that may result. Some companies insist on assigning a fixed cost or percentage to the training effort, regardless of need or variable conditions.

This mistake has certainly been the root cause of many failed implementation attempts. Fortunately, it has also been a source for others to learn from such experiences and avoid repeating the mistake.


 

The people element must be handled on two levels. At one level, employees must be trained on the new system in order to use it to continue day-to-day operations. The second level is educational exposure. Managers must know and understand the implications of the system, and must come to a consensus about the changes that will take place. If they agree that change is necessary and possible, they can be charged with disseminating this information to their subordinates. If managers are not in agreement or collaboration, then there will be no "enthusiasm", or buy-in, and there

may even be active resistance (Davenport, 2000). The reinforcement of a "team environment" is critical to the overall success of an ERP implementation. Members of the project team should be encouraged to support each other and work toward common goals. This also leads to a "cross-pollination" effect, resulting in a more collaborative and self-sufficient mix of talent and responsibilities.


 

Not unexpectedly, the most common failure factor reported was that of "readiness

for change".


 

Implementing an ERP system completely changes the culture within an organization, and many companies have found themselves hard pressed to accomplish this successfully. Unisource, a $7 billion corporation, scuttled its implementation plans due to "internal problems". The company was unable to deal with the levels of cultural change that would have to take place in order to be successful under an ERP system.


 

Many companies have been guilty of making simplistic assumptions of how an implementation will affect the culture within their organization. Culture changes do not occur magically, and must be handled with the utmost care and precision . These changes directly relate to the human cost element, or human psyche. If people are not ready or willing to change, change simply will not occur. All managers must be charged with the responsibility of controlling worker anxiety and resistance to the ERP system .

Factor 4: deal with organizational diversity


 

Organizations have many cultures. Individual branches of the same organization have their own ways of doing things, and each function/department operates with different procedures and business requirements. Not unexpectedly, the larger, more global companies cite their diversity as an obstacle to success. Individual units and groups are often companies of their own right, and do not wish to be assimilated into one corporate culture. "Re-engineering" of the business is required here, both on the "people" level, and on the operational level. This organizational diversity differs from factor #1 (worked with SAP functionality/maintained scope) in that the company changes its culture, not just its processes.


 

Farmland Industries, a $10.7 billion farmer-owned cooperative wanted to ensure that their endeavor would be successful. Before launching their implementation, they interviewed over thirty other SAP users, in an attempt to "learn from the mistakes of others". The knowledge gained allowed them to re-engineer their business before beginning the process, and resulted in a successful implementation. It appears to be more critical for large, diverse organizations to re-engineer their processes and remove idiosyncrasies – both cultural and procedural – before taking on a project.

Amoco ($33 billion, oil/petroleum) and Chevron ($43 billion, oil/petroleum) painstakingly

Re-engineered their companies. The concept of re-engineering the business is not simply to

fit the software. Before any company can be linked effectively to world-class supply

chains, their internal processes must be world-class . Chemical giant E I DuPont, scuttled its SAP implementation after determining that its organizational units were too diverse, feeling that it would be too difficult for them to attempt to re-engineer their processes (Koch, 1996). On the other hand, it is possible to overcome this problem. Many large companies, Amoco and Chevron, for example, successfully re-engineered their business and overcame the problem of organizational diversity.


 

Factor 5: planning/development/budgeting


 

Planning a sophisticated ERP project should not be taken lightly or with little forethought. As mentioned before, there are enormous potential costs associated with such an undertaking. In addition to the high costs paid out before the go-live date, there can and have been major expenses incurred by companies that were unable to fully develop a comprehensive plan. Planning should be closely identified with maintaining scope during an implementation. Cost overruns and developmental delays are costly, sometimes fatal results of ineffective planning. Home Depot, Lockheed Martin, and Mead Corporation are some examples of companies that attributed their success to planning. Lockheed planned a well-equipped team to do the implementation, allowing

them to make a solid plan for achieving their stated goals. Mead Corporation, a large pulp and paper manufacturer researched the notorious Hershey Foods implementation in an effort to learn what they would need to do differently in order to succeed, or more specifically, to avoid failing. Consequently, Mead successfully implemented nine separate modules simultaneously within their operations.


 

Developmental delays with ERP implementations were more of an issue during the Y2K readiness period, and some companies in the midst of an implementation were forced to scuttle the operations and make quick fixes to their legacy systems. For example, this was a primary issue with Nash Finch, a national food wholesaler. Delays, however, can cause any operation to be scratched if the senior managers feel they should no longer, financially or otherwise, support a project that may never get off the ground within a reasonable period of time. Developmental delays can also lead to resource attrition, which in turns affects the learning curve and completes the vicious cycle by creating additional obstacles to obtaining cut-over.


 

Knowing this, Fujitsu Microelectronics successfully completed their well-planned implementation in ten months. Projects are demanding, not only on the company, but also on the employees on the team.


 

Implementations can become very costly, despite all efforts at developing a solid plan. Unisource and Snap-On-Tools attribute this to part of their failure. Waste Management, Inc. found the unexpected costs too much to handle, and subsequently retired their ERP implementation project. Many projects, especially failed ones, find themselves over budget, some by as much as 189 percent. Only one-sixth of projects are completed on time and within budget.

Factor 6: adequate testing


 

System testing has proven to be the key element of success for some companies, and a

Direct cause of failure for others. The Gillette Company endured five months of rigorous testing procedures before their successful go-live date. Eastman Kodak completed what at the time was the largest implementation on record, attributed testing as a primary factor for their success. After

Months or years of development, it may be feasible to assume that both team members as well as executive management are tired of dealing with the project and just want it to be completed. The result of this myopic thinking, however, is that testing is reduced or ignored, and "red flags" are disregarded. Whirlpool Corporation, for example, attributes inadequate testing as its single reason for an unsuccessful- and costly-implementation. In an attempt to meet their deadlines, red flags were ignored.


 

Whirlpool gambled on its testing program by reducing the amount of time needed in an effort to avoid the "wrath" of senior executives. Furthermore, Whirlpool executives admitted that to complete adequate testing and fix any problems would have delayed go-live by only one week. Consequently, these "red flags" reappeared at go-live creating inventory and delivery problems, and costing the company more financially in the long run . This also proves the importance of another success factor – top management support. Unrealistic fears of delaying the "go-live" dead line indicated that senior executives were not completely "in tune" to the importance of completely testing the implementation; even that resulted in a slight delay. Hershey Foods stated that their rush to complete the implementation in order to be "ready" for their busiest time of year, in addition to other issues that essentially doomed the project early on, caused their massive, highly publicized Failure .


 

Conclusions


 

Six factors were identified for success and failure of SAP implementations in this . It has been noted that the primary factors (working with SAP functionality and maintained scope, and project T eam/management support/consultants) for successful implementation of SAP are different from the primary factors (inadequate internal readiness and training, and inappropriate planning and budgeting) that contribute to failure of SAP implementation. Hence, it can be noted that the factors that contribute to the success of SAP implementation are not necessarily the same as the factors that contribute to failure. This points out that management should be focusing on one set of factors of avoid failure and another set of factors to ensure success. The main regret in ERP implementations seems to be that there was not enough time and attention devoted to the internal readiness factor and their changes during the implementation process. This is true for all companies that have had implemented an ERP system, whether it is SAP or any other vendor.

Friday, January 22, 2010

What is AIDA ?

I have no idea, when I heard first time about AIDA in year 2005. I understand that it is more used in Ad world.

A.I.D.A Means Attention, Interest, Desire, Action

Attention: Capture your stakeholder / team / business attention right away, with a riveting photo and headline. Exceptional dash boards/ reports showcase headlines and images that work together.

Interest: If you handle your team properly, their inputs (generated out of interest ) isn't nice ? May be wrote a good headline in your email , likely they'll be intrigued and continue reading. Your email where you can isolate a fear, problem, concern or need of theirs.

Desire. Make them want what you have. Pose your solution to the aforementioned problem. Build your case.


 

Action. Finally, tell your audience what to do. After all they action ( Do it ) now !!


 

Monday, December 21, 2009

Avatar (Movie ) and SAP Project Management

When I first saw movie Avatar on first day of release in Harrow – Vue theatre, I have not had any idea of writing this blog article. My impression was fantastic visual effects and story like a pakka (aka perfect) Hollywood story climax as we expected. Thereafter, my curiosity made me too goggled on Avatar Movie Making. Interestingly I found few similarities which I would like to share with you.

Any sap project need a detailed preparation likewise avatar team done. In 1994, director James Cameron wrote a 114-page scriptment for Avatar. John Cameron said his inspiration was "every single science fiction book I read as a kid", and that he was particularly striving to update the style of Edgar Rice Burroughs' John Carter series. The success of a sap project is based on passion. In creative industry passion leads to success some times. My observation is like avatar direct every project manager needs personnel style and passion.

In August 1996, Cameron announced that after completing Titanic, he would film Avatar, which would make use of "synthetic", or computer-generated, actors. The project would cost $100 million and involve at least six actors in leading roles "who appear to be real but do not exist in the physical world". In June 2005, Cameron was announced to be working on a project tentatively titled "Project 880", concurrently with another project, Battle Angel. By December, Cameron said that he planned to film Battle Angel first for a summer 2007 release, and to film Project 880 for a 2009 release. In February 2006, Cameron said he had switched goals for the two film projects – Project 880 was now scheduled for 2007 and Battle Angel for 2009. He indicated that the release of Project 880 would possibly be delayed until 2008.Later that February, Cameron revealed that Project 880 was "a retooled version of Avatar", a film that he had tried to make years earlier, citing the technological advances in the creation of the computer-generated characters Gollum, King Kong and Davy Jones. Cameron had chosen Avatar over Battle Angel after completing a five-day camera test in the previous year. In December 2006, Cameron described Avatar as "a futuristic tale set on a planet 200 years hence [...] an old-fashioned jungle adventure with an environmental conscience [that] aspires to a mythic level of storytelling". Instead of classical or standard project approach sap project managers should approach with Innovation plus creativity means stakeholder confidence.


 

Cameron's early scriptment for Avatar had circulated on the Internet for years. When the project was re-announced, copies were subsequently removed from websites. From January to April 2006, Cameron worked on the script. As on to today many programme manager or directors or CIO are still in old fashioned thinking assuming that project manager is typical manager to look after people budget facilities report to stake holder etc. Like Cameron worked on the script, how many sap project manager really has capability or ability to look in to technical details or even willing to know about it.

Working with Dr. Paul Frommer, linguist and Director of the Center for Management Communication at USC, he developed a Na'vi language and culture, the indigenous race on Pandora. The language has a vocabulary of about 1000 words, with some 30 having been invented by Cameron. The tongue's phonemes include ejective consonants (such as the "kx" in "skxawng") that are found in the Amharic language of Ethiopia, and the initial "ng" that Cameron may have taken from New Zealand Māori. Just for few minutes of the movie creative industry works hard to mark their stamp. In a sap project, what we used to couple and decouple business process with sap configuration. End result likewise instead of few minutes' tapes (reels) ready to use bespoke solution. If someone in a movie industry consulting various people for making few minutes movie , our everlasting so called best of breed solution do not need consulting ?

Movie Making is an art, SAP project management is not?


 


 

Thursday, September 24, 2009

Avoid BW Project Management Mistakes

video

SAP BI Dcoumentation Links

I suggest a goodlink for new SAP BI or semi professional to go through click here . - Kumar Vuppala

Dash Boards ( Simulation ) files

video

SAP BI and the Conservation of Complexity

You may remember a rather obscure law of science from your high school days in physics called the Conservation of Energy:

The total amount of energy in a closed system remains constant. In other words, energy can be converted from one form to another, but it cannot be created or destroyed.

I don't claim to understand this principle fully, but essentially it's saying there is a finite amount of energy in any given system and that amount cannot be changed. All you can do is change the way it's packaged. I guess it's a little like the mess in my boys room. It never really goes away ~ it only changes form now and then.

I would like to offer a corollary to the Conservation of Energy that I call the Conservation of Complexity, which states:

The total amount of complexity in an information system remains constant. In other words, complexity can be transferred from one party to another, but it cannot be created or destroyed.

This principle states that in any given information system there is a finite amount of complexity that cannot be removed. All you can do is determine who deals with the complexity. With any given business intelligence system the options have traditionally been the BI software/system vendor, IT back end resources, IT front end resources, and the end user.

Going back to ancient history (10 ~ 20 years ago), the following graphic shows how the typical transactional system might have distributed complexity:

Mainframe Vendor: 20%
IT back end: 20%
IT front end: 50%
End user: 10%

What this is essentially saying is in this type of system the bulk of the complexity falls on the IT front end resources, or the report writer/developer. In most situations the IT back end resources are only responsible for providing simple database views or perhaps some stored procedures to simplify data retrieval, but in almost all cases it falls upon the report developer(s) to deal with most of the complexity in the system. The primary problem with this arrangement was the bottleneck created by the IT front end 's it simply wasn't feasible to keep enough resources on hand to keep up with demand.

I experienced this arrangement first hand when working at my first real job after college in the mid to late 80's. I worked at the Data Processing Center at the college I had attended and part of my job was to produce IBM VM/SP (mainframe) reports for college staff. I can assure you that there was a LOT more demand for information than I could possibly keep up with. And while the end user was certainly shielded from much of the complexity of the system, they certainly experienced more than their share of frustration waiting for their ration of data from the mainframe gods (this of course leads us to yet another corollary principle, the Conservation of Frustration, which we'll save for a future discussion).

Once SQL-based relational systems came of age one of the first attempts to resolve this issue was to provide the end-user with their own query and/or report writing tools with the hopes that they would become more self-sufficient (adhoc queries). The distribution in this type of system looks something like:

RDMS Vendor: 25%
IT back end: 25%
IT front end: 0%
End user: 50%

Essentially this arrangement eliminated the bottleneck created by the IT front end resource. It also shifted some of the complexity to the back end resources (primarily due to the need for additional and more complex views and reporting structures). The reason why this was a colossal failure for the vast majority of end users is easy to understand (at least now): the typical end user proved incapable of dealing with such a high level of complexity. It quickly became obvious that shifting the bulk of the complexity onto the end user was not the path to take.

Once again, I experienced this misguided effort first hand. I worked with more than one client in the mid to late 90's who had attempted to put reporting/query tools in the hands of their end users and almost died trying. I remember one particular client, a large hospital in Denver, CO, that had purchased over 400 copies of Crystal Reports and installed them on users PCs in the hopes they would somehow manage to find their way to their data. Wishful thinking. Fortunately for them we were able to later work a trade for a true enterprise reporting system. But back then a lot of end users simply put their "off the shelf" software back on the shelf.

About this same time the data warehouse was born. The idea behind the data warehouse was to provide a back end data structure that essentially would absorb much of the complexity associated with traditional SQL transaction systems. The distribution then became something like this:

Warehouse Vendor: 30%
IT back end: 30%
IT front end: 15%
End user: 25%

In this scenario, the warehouse vendor takes on some additional complexity by providing out of the box data structures and tools for gathering, cleansing, and organizing the data. In most cases it still requires IT front end resources to create queries (in the case of SAP BW) and other custom interfaces to allow users to access data stored in the data warehouse.

You may notice the end user is shown dealing with more complexity than the IT front end resource. On the surface this contradicts one of the stated benefits of a data warehouse that the end user can easily access the data in the warehouse via a simple GUI interface. In other words, the user can be self-servicing. The reason for this is we are making the assumption that many end users are not only interested in accessing the data but also in presenting the data.

Using the standard BEx interface it is fairly simple for an end user to access SAP BW data. All the use needs to do is open the query, respond to the necessary prompts, and then run the query. The data is then retrieved into the Excel spreadsheet. If this were the end of the story there would be very little complexity for the end user to deal with.

However, in many cases the end user does not simply want to leave the data in the spreadsheet "as is". The most common need is to produce printed output. Because the BEx interface is basically a dump of data into a spreadsheet, it requires a considerable amount of work to format the output to make it "fit for print". Something as simple as page headers and footers are quite difficult to accomplish. Pagination and labeling are also a challenge. Therefore, when the user requires formatted output of SAP BW data, the level of complexity that the user must deal with is often quite high.

In the typical rollout of SAP BW the initial end user community is quite small and unusually advanced in both their data access requirements as well as capabilities. These are the "power users". While the standard BEx interface may prove quite useful for these more self-sufficient users, it is almost a certainty that as the reports are rolled out to a wider base of users that many users will find BEx to be insufficient in meeting their needs. For these users the distribution of complexity needs to be more like the following:

Warehouse Vendor: 30%
IT back end: 30%
"Information Broker": 30%
End user: 10%

This shift in complexity is primarily the result of moving the responsibility for the finished (or formatted) output from the end user back to IT front end resources, or as it says above, the "Information Broker". I use this term deliberately to get away from the mindset that it is up to official IT front end resources to help users produce finished output.

I have worked on a lot of BI projects throughout the years and one thing that is always puzzled me a bit is how little companies invest into front end resources in IT. In almost every case, even with the largest companies, you can count the front end resources on one hand or finger. Even then they are almost never dedicated to assisting the end user in accessing and formatting data. On the contrary, they typically have other responsibilities that dominate their time and attention. The end users get the leftovers. And they get a lot of complexity dumped in their laps.

I will save this idea of an Information Broker for a later installment. This is partly because I have got to have some time to think it through a bit. For now my point is simply this: if your business users are looking to IT front end resources to take on some of the complexity they are dealing with, they are likely going to be waiting a long time. There has to be another way.

At first glance this can appear to be a step back to the days of transactional reporting where the bulk of the complexity fell upon the IT front end resource, and in some ways this is true. I have been reading a lot lately about the need for real ROI with the tremendous investments companies have been making in their information infrastructure, in particular with data warehouses like SAP BW. In order to insure maximum ROI it is imperative that companies find creative ways to reduce the amount of complexity presented to the broader end user base. I am convinced that a little extra investment in the right resources can, in this case, reap tremendous bottom-line benefits.

Information Brokers: The Missing Link?

In a previous installment, SAP BI and the Conservation of Complexity, I introduced the concept of an information broker. In that installment I make the point that a major reason why so many companies fail to realize the full potential of the information housed in their various application systems is because end users are unable to effectively deal with the high level of complexity presented to them. Even in a warehouse environment such as SAP BW where data has been cleansed, sanitized, de-normalized, and supposedly made fit for human consumption, it can be a daunting task for the rank-and-file user base to access mission critical information.

If we can accept the premise that users are being forced to deal with too much complexity when accessing corporate information, then what can and should be done to rectify the situation?

One obvious place to look for improvement would be in the technology being used - the 'front-end' tools. There has been no lack of effort over the past few years by all the big BI vendors to provide the holy grail of front-end tools - a tool that can be effectively used by the un-initiated end user. Some recent examples fall under the heading of natural language query tools, such as Intelligent Question from Business Objects. The promise of these tools is to provide a way for the ordinary business user to ask a question and actually receive an answer (What were my five top selling products in the southern region last quarter?).

The purpose of this installment is not to argue the merits of these tools and debate their relative effectiveness in providing real answers to business user's questions. I have not personally had the opportunity to use one of these tools at a customer site and therefore cannot provide any real-world observations. And while I certainly agree that it is important for all BI tools to become more 'natural' and simple to use, there's more to solving this puzzle than simply putting the right tools in the right hands. As with many business problems, it can be more of an organizational/people issue than a technological issue.

As I've worked with companies through years, I've noticed that certain people tend to function as 'information magnets' in any organization. They are usually fairly easy to spot: all you've got to do is follow the tracks worn in the carpet leading to their cube. One thing they have in common is everyone else around them looks to them for answers to their questions. These are the keepers of the infamous 'spreadmarts' and, quite frankly, we should all be thankful for them because without them commerce as we know it would grind to an immediate and grinding halt.

While I would agree that these spreadmarts are not the most ideal method of disseminating information, we should all recognize that they have served a very important function that, for whatever reason or reasons, was not (and is not) being performed elsewhere: they have functioned as information clearinghouses where raw data is brought in and usable information is produced and delivered to decision makers. If we think of this in terms of a transaction of goods or services, then we could say that the keepers of these spreadmarts operate as a sort of 'information broker', connecting the right piece of information with the right person in order to produce the best possible business outcome.

Although this method of collecting and disseminating information has proved somewhat effective and useful, it is not without significant issues. Perhaps the foremost is lack of control over corporate data. Because this process involves downloading data from corporate data stores into either Excel or Access the data can therefore be easily manipulated - a feature for some but a cause for concern for anyone responsible for corporate governance. There is also the issue of distribution of the information. These local spreadmarts and Access databases do not offer the secure distribution and auditing capabilities of a true enterprise reporting system.

The idea I would like to propose is for IT to deliberately identify, engage, and empower these individuals and help make them part of an enterprise reporting solution. In most of the reporting projects I've been a part of there is, at best, a sort of 'us vs. them' mentality among IT staff. Instead of being viewed as potential allies these 'keepers of the spreadmarts' are often seen as part of the problem and are often ignored or otherwise shoved to the side while the 'real' enterprise BI solution is being implemented. However, by leaving these individuals out of the loop and not giving them a central role in the design and implementation of the enterprise BI system the entire project can be jeopardized. They are the ones whole truly understand the business need and where to find the answers to questions in the data.

How would this work itself out practically as part of an enterprise reporting project?

* Early on in the process there needs to be a deliberate effort to identify these individuals in an organization. The scope of the search would depend on the scope of the reporting system deployment. This could be accomplished using a simple survey of end users: Who do you go to in your department to get answers to your business questions?

* Once these individuals have been identified, include them in the early stages of design. They can offer invaluable assistance in identifying deficiencies in the data and common analysis 'themes' requested by end users.

* By providing these individuals with early ownership of the new solution they will feel less threatened and therefore more likely to adopt and promote it rather than resist.

* It is important that these individuals be officially recognized as the critical link between IT and the user base at large. I would even recommend going as far as giving them an official internal title, such as 'HR Information Broker'.

* Lastly, these individuals need to be empowered with the training and guidance they need to fully understand and adopt an enterprise BI system. They need to be shown how they personally will benefit from moving to an enterprise system and how they can better serve their end users (through developing end user reports, creating meta-layer views, creating business logic/formulas, etc.).

One common flaw I've notice in many IT departments is a lack of real understanding of the business need and how information is really used in an organization.

This is understandable as IT does not work as part of the business, but rather in support of the business. By identifying existing 'information brokers' and bring them into the fold early on in the project, IT can help insure that the new BI system will be designed correctly and fully adopted by the end user community.

And you may also find the missing link between your data and your users.