The Best of Best Practices for a Thriving Center of Excellence

One of the more daunting barriers to the establishment of a viable Center of Excellence in most firms is the persistent view that SAP is an IT subject and thus IT holds decision-making powers that it should never be given. Over the years I’ve observed dozens of clients send out SAP management to create a business-centric organization that few business people agree to join. Unsurprisingly, one of the most frequent questions I get is “how do you get business people to participate in a center of excellence?” The short answer:  have business people build and lead the center of excellence.

Even when business people are involved in a Center of Excellence, a further barrier is thrown up if there is a lack of authority vested in the business process owners.

Consider, for example, how the owner of the Orders-to-Cash business process needs process authority across a number of vertical departments:

 

 

 

When authority over individual applications is given to vertical department heads, we find that conflicting “improvements” tend to occur. One common example is when the head of sales decides to promote sales by changing the sales order process to allow for massive discounting and accelerated sales closings while at the very same time the head of the warehouse changes his applications to squeeze out inventory.

 

Ideally, department heads will not have the authority to change applications. Ideally, all changes to applications should be approved by the relevant business process owners. In this light, business process owners should be inclined to accept requests that are justifiable and do not negatively impact key performance.

 

Here again is a template organizational chart:

 

Note that the arrows from process owners to the applications are unidirectional. That is because in a functioning Center of Excellence there is no longer a “negotiating” culture and process owners clearly direct the applications maintenance agenda.  If the process owners do not have the requisite authority, the Center of Excellence becomes a Center of Mediocrity.

 

So here is an extremely excellent practice that I learned from a client who purchased a large quantity of both of my books and therefore merited a freebie consulting session. In the course of our discussion I learned that not only was his company forming a Center of Excellence (pre-implementation, no less!) but that they had also adopted a policy:

Any individual destined for senior management had to spend at least two years in the enterprise and enablement domains.

 

“It is obvious to us,” the client confided, “that the work experience of mastering business process and the inherent business measurements as well as the cause and effect of business process improvement is the best possible preparation for a senior position.”

 

Further, exposure to the enablement domain helps assure that these future senior execs will gain insight into the end user (we prefer to call them process drivers) experience and thus understand, in depth, how business processes are fulfilled.

 

I cannot think of any policy that could do more to fully authorize (as well as energize) business process ownership in the context of a business-centric Center of Excellence.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Life's Too Short: What to do about that "Cut Your Costs" Directive

In my books, in this blog, and in my day-to-day client connections, I lay a lot of pressure on IT to become more business-centric. When things go wrong in an enterprise applications environment, however, the very worst culprits are usually higher-ups on the business end who are utterly clueless and who far too often chop their own firms off at the ankles.

 

What if you were a CIO and received this message from your CEO or CFO?

 
"We insist that by the end of the calendar year you cut by no less than 10% your department’s ability to help the company improve its business process performance and, by consequence, save money, increase client satisfaction, and evolve. Please refer any questions to our internal audit group which has been assigned to assure that you comply with this request."
 

Twenty-eight years ago I was a CIO. OK, full disclosure.  I was a Directeur Informatique in Paris. While the majority of the other directors were a joy to work with, our CEO was neither bright nor diplomatic and proved it one day by circulating a memorandum -remember those? This particular specimen was typed on an IBM Selectric III, Xeroxed, and delivered in a wrinkled brown company mail envelope- to all directors stating that each of us should cut our costs by 10%.

Had he written that the enterprise as a whole needed to cut costs by 10% we would probably have found that the request was reasonable. But each of us?  Zut alors! That included three factories, the sales force, purchasing, accounting, marketing, and transport.

In an attempt to make sense of this and perhaps make some limonades out this citron, I worked with all the other directors to find ways in which IT could assist them in reducing costs. The product of this was a plan for a number of straight-forward  IT projects that would result in a company-wide reduction of recurring costs to the tune of 13%. This net amount included raising the IT budget by 17% over a two-year period after which IT costs would be reduced, post projects, to 105% of current.

The numbers in question:

• Current annual costs = $222M
• Projected annual costs after project completion =  $193M
• Projected savings:  $29M (13% saved)

This proposal was met with a reminder that I had been asked to cut IT costs by 10%. That I was instead proposing to raise IT costs by 17% was evidence that I was mentally challenged. (This was France, folks. The man needed some strong paper for “le dossier Doane” that he was obviously building.)

I saved him time and simply left and have never returned to the client side. And in the twenty-eight years that I have been in services, I have come across countless companies where “powers on high” issue decrees to IT departments to cut costs by a “fill in this awful blank” percentage.

 

During this same time-frame, I find that the majority of business leaders have only a slight handle on business measures, goals, or any particular understanding of actual cause & effect with which they justify demands upon IT.

 

In the course of the many SAP Executive Seminars that I have led over the years, I find that a disappointingly low percentage of C-levels can articulate why they are moving their firms from legacy to SAP. I tend to hear literature, as in "we want to streamline our operations" or "we need to upgrade our infrastructure to support our evolution" or "we need to be leaner and more efficient". There are hundreds of such quotes from corporate "Hallmark Cards" that provide nothing whatsoever in regard to inspiration or, more importantly, guidance for the project to follow.

 

What needs to happen is for business leaders to become more numerate when it comes to directing IT efforts. That will be the subject of an upcoming post, tentatively entitled: 

 

Read This or Get Fired:  The (Long Overdue) Rise of Numeracy in the World of SAP

 

If you are an IT executive and receive a message like that posted at the top of this blog, I really have no advice for you other than to take to the road like I did. It's always a matter of Yes or No or Life's Too Short.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The Borderless Enterprise: Beyond “Hyphenates” to Business Process Xperts

The former SAP BPX Wiki has, thankfully, been shut down. Contributions to that space tended to be fixated on business process modeling software and a grab bag of other technical arcana that failed to directly address the melding of business process skills and more technical SAP skills.

In the interest of resuscitating the principle (and three-letter acronym) in a more rounded and useful fashion, Jon Reed and I (with some useful input from Jim Link) have continued to explore why and how practitioners coming from two directions, business and IT, should blur (if not eliminate) the skills gaps that characterize this longstanding nightmare of a business/IT dynamic.

 

This cycle of presentation-clarification-review-development-revision-review-production results in a huge loss of time and an equally huge level of professional frustration on both sides.

Most firms have business analysts or equivalent and these people are the ones who find themselves working between business stakeholders or process owners and SAP applications people and in these interactions there is a form of translation that occurs in which business concepts are applied or to configuration and/or ABAP.

 

The Italians have a phrase “traduttore, traditore,” which means “to translate is to betray” and this is what too often happens between business analysts and SAP configurators. Much of this “betrayal” can be overcome with an expansion of both role descriptions.

 

The following is excerpted from The SAP Green Book, A Business Guide for Effectively Managing the SAP Life Cycle, available through SAP Press. http://www.sap-press.com/

 

Beyond “Hyphenates”: Business Process Experts

 

When learning the SAP alphabet, clients quickly become familiar with the shorthand for the various modules: FI, CO, SD, MM, PP, et al. From the 1992 announcement of R/3 to the present, these same two-letter acronyms have been used as shorthand definitions for project and support staff assigned to the applications. With time, consultants and in-house staff turned into hyphenates as FI (Financials) specialists also knew CO (Controlling) to become FI-CO; in similar fashion, many SD (Sales & Distribution) also became familiar with MM (Materials Management) to become SD-MM.

 

While such wingspan has for years been commendable, we are now in a mature phase with SAP such that “hyphenate staff” is sooo yester-millennium.

 

Jon Reed has been advising SAP/ERP consultants since 1994 (www.jonerp.com) and is a certified SAP mentor for BPX (business process expertise). He finds that the traditional “module consultant” is more and more required to move past modules and expand into full-blown process consulting.

 

“In the past, it was sufficient for a consultant to be a hyphenate: FI-CO, SD-MM, MM-PP,” he relates. “Consultants, both internal and external, are increasingly required to stretch their knowledge not only in terms of a horizontal business process but also in regard to related business measurements at the KPI level.”

 

We agree that traditional ‘hyphenates’ still have value, especially if they can combine SAP technical skills with strong consulting bones and the requisite business knowledge. We also agree that an individual with a mastery of the Orders-to-Cash business process, combined with experience in configuring the majority of the modules that support that process, is worth gold.

 

Jon adds, “Speaking of Business Process Experts (or BPXers as they are often referred to in an SAP context), it's important to understand that "BPX" is not just a vision of where the SAP functional skill set is headed. It's a recognition that IT and business are becoming increasingly intertwined, and the best SAP professionals - the ones your company wants to keep on the softball team - are those chameleons who can walk across the aisle with comfort and talk business or "tech speak" as needed.”

 

BPXers fall into the crucial realm of business process owners and applications configuration, where business results are directly driven. The old business-asks-IT dynamic is obsolete. 

 

As Jon Reed concludes, “The SAP skills world of the future is a techno-functional convergence, where suits are sometimes geeks and geeks sometimes wear the suits.”

If you already have a configuration team of SD-MM-PP, you have the raw material for an orders-to-cash BPX team. MM with a dose of FI can cover procure-to-pay. To get there, you have a horizontal challenge and a vertical challenge:

 

 

Horizontal: Stretch the SAP skills through training and exposure to the SAP Community Network (et al)

 

Vertical: Deepen the business skills through increased contact with business process owners/analysts and super users.

 

As you mature your SAP, the accent should increasingly be on the business end. In shorthand terms, your applications staff should become a mirror image of your business process ownership except that it will possess the requisite SAP skills and still have a foot in traditional IT.

 

Evolving from a “hyphenate” environment to a BPX environment cannot happen overnight or without resistance from application specialists who are content to master a narrow environment. This evolution will occur with greater efficiency if your firm has at least a functional version of a Center of Excellence that is business-centric. As you continue to erode the wall between business and IT (that dotted line in the preceding chart), your applications consulting staff will quite naturally move more confidently through the business aspects, supported by both the business process owners and the super users.

 

Jon Reed provides the following summary of BPX skills:

 

"Soft skills":  Soft skills is really a cliché; it takes real work to get at the specifics of why soft skills matter. I think of soft skills as the ability to mix as effectively in the plant break room as the corporate boardroom. We don't all need to be able to get in front of the dreaded "white board," but we do need to be able to get across the business case for what we are currently doing. Another misconception about "soft skills" is that you are stuck with whatever skills you have in that area. That's not the case. There are many ways to improve soft skills, whether it's PowerPoint training, Toastmasters, or even a formal MBA program. It all depends on the specific skills that need to be improved.

 

Industry know-how: Increasingly, SAP professionals are expected to bring "industry best practice" knowledge to the table, and this will certainly apply to the BPX skill set of the future. Even technical SAP professionals can add value to their skills by understanding the specifics of their industry, such as knowing the keys to successful development on retail projects. Knowledge of SAP's own Industry Solution functionality can play a role here as well.

 

Knowledge of the end-to-end business processes that relate to your SAP skills focus: While it remains important to have a focused SAP skill set, there is no question that the "big picture" knowledge needed around that skill set continues to grow. Traditionally, many SAP professionals functioned in "silos" such as HR or Financials. Increasingly, SAP customers are approaching ERP in terms of end-to-end business processes such as order-to-cash, procure-to-pay, and the like. Enterprise trends such as information lifecycle management and product lifecycle management also indicate that we need to understand how our skills focus fits into a bigger picture. 

 

Ability to work as the "liaison" or "missing link" with functional and/or technical teams from the opposite side of the aisle:  It's no accident that the phrase "become a marriage counselor between Business and IT," first used on the SAP Community Network by Denis Browne, is often brought up in the context of BPX skills and presentations. The first chapter of this book “SAP Marital Counseling” echoes this sentiment.

 

Beyond the skills listed here by Jon, your newly-minted BPXers should also be moving down the path of Business Process Modeling (BPM). In past years, clients have extensively used simple tools such as Visio rather than extremely sophisticated tools such as the ARIS toolset.  It is understandable that clients would use Visio during an implementation project as the learning curve for ARIS is quite steep. I would venture to say that over the long haul after go-live, a client should be prepared to step up to something more sophisticated than Visio. Having said that, the important step is to get the BPXers and the Business Process Owners into the same room. After such a momentous accomplishment, I’d be happy if they deployed Etch-a-Sketch as the business process modeler.

…

Moving your applications staff into BPX mode will do wonders in the never-ending quest for business and IT alignment by providing faster results when improving business processes and by bringing SAP that much closer to the business heartbeat.

 

(In an upcoming posting, I will present the Maturity Models that we have developed, tracing how to move from a Super User to a BPXer or a simple configurator to a BPXer.)

Continuous Business "Whatever We're Doing" Improvement

Over the past month I have spent time with more than a dozen SAP clients and prospects on the subjects of center of excellence, KPI measurement, continuous business process improvement, and SAP super user networks. In the course of one to three hour meetings, I do my best to isolate client challenges that may inhibit any chance of their moving past the second level in the CGI enterprise maturity model.

If an organization can only complete implementation and then stabilize, we say they are "doing a great job of standing still".  Such organizations lack the sufficient business and IT dynamic that can inspire them to move forward into a center of excellence environment. Instead, they tend to take a path toward entropy and, through time, the SAP applications are treated just like any other utility.

When I challenge companies that are in this state to wake up to the need for evolution, I often am answered with solid arguments as to why they cannot:  lack of budget, lack of senior management support, an unsophisticated corporate environement and the like.

Just as often I hear things that I would never have expected. "That's all too hard, Michael." "We don't care about measurement, we care about results." (Really, a man who would never be my client once said this.) "Our business people are too royally inclined to join us IT peons to make it work."

A few years ago, while researching super user networks, I was asked:  "My management doesn't want to call them 'super' or 'power' anything. They think such terms over-glorify them."

My obvious response was that his firm had far deeper problems than the lack of a super user network.

This past week, however, I have come across the all-time lamest, most breathtaking, so-unbelievable-it-should-be-chiseled-into-stone comment ever (though it comes to me indirectly). While working with two charming people on a plan to improve business process performance, one of them cautioned me about their CEO. "He doesn't want to hear the word 'process', ever."

I haven't met the CEO and may well not be doing so in the future. This might be a good thing as I would be heartily tempted to quote W. Edwards Deming:  "If you can't describe what you are doing as a process, you don't know what you're doing." This is clearly not something a CEO is anxious to hear.

Having said that, I find that even those organizations that dare speak the word "process" are nevertheless struggling mightily to a) establish and authorize horizontal and transversal business process ownership and b) determine the KPI hierarchy to be monitored in order to continuously improve those processes. Without both a and b, a client organization may see improvement but is, relatively speaking, making guesses as to what or how it should improve, in what order, to what end and, as such, largely wasting vast investments into high-performing SAP applications software.

Having ridden Deming's broad shoulders with one brilliant line, I will conclude with yet another:

"It is not necessary to change. Survival is not mandatory."

IT, Your Fifteen Years Are Up (Take Two)

Cutting the IT Bottom out of SAP’s Peach Basket

This article was originally posted in April of 2011. Given my observation of a rising threat of shadow IT in the SAP installed base, I am reposting in hopes that readers will avoid that trend.

"Technology is a word that describes something that doesn't work yet."
— Douglas Adams

Fifteen years ago, I believed that the SAP market would be a brave new world in which IT actually served business and where technology would be seen as an enabler rather than an end state unto itself. SAP promised to free us of undue operating system concerns through its powerful middleware and since the applications were configurable, I was looking forward to a dramatic reduction in the sway of programmers, data base managers, and anything having to do with operating systems. I was confident that newly-minted business process owners would become the centers of information power at client sites and that information technology, while hardly being banished to “the boiler room” would all the same be placed into a proper business support context.

Ah, well.

Having been recognized as both a consultant and an industry analyst through these SAP years, I have often been asked why SAP projects tend to go so badly. Another question posed to me on a regular basis is: why are so few firms getting full benefit from their SAP investments?

There is a single answer to both questions: because clients, consultants, and SAP itself erroneously believe that SAP is an IT subject. By consequence, most activities relative to implementation and subsequent deployment are incorrectly focused.

The fact is: SAP is no more about IT than books are about ink and paper. The client story is supposed to be the subject and how that story can be better written.

All the same, through my first fifteen years working in the world of SAP, I continue to observe:

a) Clients give their IT departments unwarranted leverage when selecting applications software for acquisition

b) After acquisition of SAP, clients usually turn over implementation leadership duties to their IT staff

c) SAP continues to brand itself as a technology firm rather than a business solutions firm

d) Both client IT and SAP are tenacious in maintaining a “software-centric” culture and agenda that is matched by business slouching its way forward with the oldest fig leaf in the enterprise: “without this information, we can’t do our jobs”.

When firms implement SAP, their business people are given a grand vision of how much more streamlined their processes will be, how much better their reporting, and how the in the future the firm will embrace change rather than suffer from it. But after go-live, IT is still in charge and the tendency is to focus upon cost containment, risk avoidance, consolidations. This is not always due to IT management’s desires for such focus; often it is simply the result of corporate dictates.

SAP itself, utterly branded as a technology firm, does far too little to address this misfire. As such, after years of leading its clientele down an acquisition path, it has fallen behind that same clientele when it comes to business-centric software deployment and positioning. The supplier’s current preoccupations are HANA (an in-memory computing offering), mobile applications, Business ByDesign (applications for small businesses), and the ever-present NetWeaver. Business is not amused.

This is not to say that these subjects are unimportant but quite clearly they do not strike at the heart of business people’s over-riding concerns.

The following are examples of what I’ve heard from clients over just the past three years (not verbatim, but highly accurate):

“We over-customized our applications and ever since we went live, it’s all we can do to keep up with maintenance. For a while, we had a steering group charged with business process improvement but we never had the time or money to address their issues, so they disbanded.”

“Our IT management only knows how to buy and install new software. We never focus on how to make it work better or how we can get value from it. Our motto is “the more software we have the better we are.”

“We build a center of excellence that worked fairly well for about six months. Then we hit 2009 and there were a lot of layoffs. The center of excellence just melted away since so many of its members were gone and not replaced.”

“No one on the business end will join our center of excellence. They just don’t believe us anymore.”

Even leading light firms can see that light flicker. Some months ago, while speaking about centers of excellence to a group of clients in Atlanta, I cited a local client that has been a core model for the past ten years. During the break after my talk, I discovered that one of the audience members worked for that client. He approached me, introduced himself, and said: “I’ve been there the whole time. We used to be really good like you described. We’re just not that good any more.”

When I asked what happened, he replied, “Budget cuts. We went from business process improvements right back to basic maintenance.”
…

Dr. James Naismith is credited with the invention of the sport of basketball in 1891. His initial “baskets” were peach baskets nailed ten feet high in a gymnasium. The sport was initially codified into 13 rules as published by the good doctor. Unfortunately he missed one very crucial step in the development of the sport.

From http://blog.mitchellandness.com/?tag=/peach+basket

The peach baskets were closed at the bottom, which resulted in someone having to climb up on a ladder to get the ball after a basket was made. A little while after, the peach baskets were replaced with a metal rim and hanging net. Again, the net was closed at the bottom. It wasn't until 1906 when people began to open the bottom of the net to let the ball fall through.

The game was invented for college students and between 1891 and 1906 we can presume it was played by thousands and thousands of them. All the same, fifteen years passed before it finally occurred to someone to cut out the bottom of the peach basket.

Obviously, that change in “basketball process” has radically benefitted both players and fans over the past 105 years.
…

Year after year I come across clients with a serious lack of agreement regarding their SAP maturity. IT people give me the thumbs up and business people just shake their heads.

I believe that if everything was left up to technologists nothing would operate but everything would work.

Today, the phrase “business and IT alignment” makes me cringe as ‘alignment’ is both a cipher for “can’t we all just get along” and a false grail. The only alignment needed is a repositioning: IT at the service of business, period.

On the bright side, over the past year I have observed a distinct movement in this direction. I know a consultant who was hired by business stakeholders at a major client and told to provide business intelligence in the form of dashboards. He was also told not to communicate with the firm’s IT or SAP support staff or with the Deloitte consultants who were onsite. “They’ll only get in our way.”

I have also come across a high number of clients who, attempting to build a center of excellence, have kicked out initial suppliers because their approach was too IT-centric.

In a wonderful article by Jim Shepherd of Gartner, The "Digital Natives" Are Restless: The Impending Revolt Against the IT Nanny State, he writes:

“Gartner has seen a steady increase in the percentage of IT spending that’s directly funded by user departments, rather than the corporate IT budget….I'm regularly hearing middle managers and even senior executives complaining bitterly about IT departments that are so focused on the global rollout of some monolithic solution that they have no time for new and innovative technologies that could have an immediate impact on the business. They're fed up with IT's refusal to acknowledge the technical sophistication of today's average user, most of whom have spent their lives surrounded by complex hardware and software. They regularly purchase, deploy and manage a wide variety of computing and communications technology in their personal lives, but at work, they have to call a "professional" if they want to change their screen saver.”

This all suggests that a dramatic change in process is overdue for clients with SAP. IT predominance is the bottom of the peach basket. Time to cut it out and get business fully into play.

The best way to do so is to establish and sustain a business-led Center of Excellence that features continuous business process improvement. The chart below is a shorthand version.

Regular readers of this blog and or my books are aware that I have written quite a bit on this subject since 2001. For more on this subject, you can visit my website at http://www.michaeldoane.com/. Further, I will be keynoting with Brian Dahill at the ASUG/SAPPHIRE Preconference on May 15th: Creating a Business-Run Customer Center of Expertise (COE) with SAP, 8:00 a.m. – 5:00 p.m. I had the honor of participating in this event last year and found it to be exceptional. I recommend it to anyone currently engaged in building or improving a business-centric center of excellence.

Helping clients to move into a business realm of SAP is going to take a greater effort on the part of the entire eco-system, including ASUG, SAP services, consulting partners, and industry analysts. This does not have to occur at the cost of continued applications excellence but we do need to stop tinkering with the SAP applications engine at the cost of filling business needs.

It must not go unsaid that such a shift means that business must become more involved and more accountable. In a proper center of excellence, the key position is that of business process owner, with the accent on ownership. Without this, your center of excellence will simply be yet another center of mediocrity.

There are a host of best practices in this regard, most of them fully explored in The SAP Green Book, Thrive After Go-Live. However, I learned one of the very best practices from a client since the second printing of that book. Not only did the client describe to me his fully business-centric center of excellence, he added that working in the center of excellence for two to three years was deemed a required stepping-stone for anyone destined for senior leadership. “Center of excellence experience is viewed as being at the heart of all we do and are.”

Swish.

IT, they're just not that into you: Is Shadow IT on Your Horizon?

In the SAP World, Shadow IT is on the Rise

I have a resourceful neighbor who went nearly a year without a job. His specialty is HR and he read my two books on SAP as a way of enhancing his marketability. Some months ago, he called to tell me he was doing some SAP consulting at a major West Coast utility. "It's wild," he said. "A number of us have been hired by the business side to build dashboards. We were told not to talk to the SAP support people and especially not to the other consultants who are onsite."

My neighbor and his colleagues had a ten-month run at this client. His read is that the business people who hired them did so because of ten years of disenchantment with ealing with an isolated, hard-of-hearing SAP support staff. My neighbor added  "[SAP] isn't what they reach for when they need a solution."

Even more recently, I spoke with a prospect where SAP was also installed about ten years ago. He said that most of the SAP support staff is very worried that they are now viewed as obsolete as business is increasingly tempted to go in an entirely new direction. Buzzy language was used, including "cloud", "SaaS", and something about immediacy. Needless to say, I also learned that business people and SAP/IT people lacked "alignment".

Since 2008, as the economic downturn has persisted, corporate belt-tightening has obviously extended to IT. For all firms, long-sought "business and IT alignment" has frayed as IT departments are ever more deaf to business calls for better services and better response.

While I have seen no primary research on this and hesitate to pronounce a trend on the strength of anecdotal evidence, I have been reading more and more articles from reliable analysts on this subject. To be clear, here is the Wikipedia definition of Shadow IT:

"Shadow IT is a term often used to describe IT systems and IT solutions built and used inside organizations without organizational approval.

Shadow IT is considered by many an important source for innovation and such systems may turn out to be prototypes for future approved IT solutions. On the other side, shadow IT solutions are often not in line with the organization's requirements for control, documentation, security, reliability, etc.

While the beneficiaries of shadow IT gain immediate satisfaction, their data silos tend to increase, thus inhibiting or negating integration with mainline IT."

The causes of shadow IT are fairly obvious on the surface:  users/stakeholders are not getting what they want or need from internal IT so they look elsewhere.  Here are a few of the most common scenarios:

1. Your big fat ERP-CRM-HRM-SRM platform that you installed between 1997 and 2005 has been maintained but has not evolved. Your IT leadership was content to implement, stabilize, and merely maintain. Thus, you are all doing a fine job standing still. Business is not amused.
2. Your IT leadership is very well plugged in to your business leadership but shortsighted corporate leaders view IT as just another utility like heating/AC, plumbing, or the telephone network. Repeated corporate mandates to IT to cut spending result in IT leadership telling business "Sorry, we no longer have the funds to complete your desired request." Business is not amused.
3. A business opportunity exists that requires IT capability that the in-house group cannot provide in time. Business stakeholders find an outside capability that will satisfy their need. While that need is temporary, business tends to cling to its new tool rather than return to the in-house flow. Business is amused and IT does not know why.
4. Your enterprise lacks discipline from top to bottom. Creative chaos is the mantra. Business buys whatever technology it wants and who cares about integration. Everyone is amused.

 The root cause of most shadow IT is a faulty business/IT dynamic characterized by excessive IT-centricity relative to the SAP plant. The expression of this IT-centricity is an exaggerated focus on the enterprise applications leading to neglect of all other business aspects.

For a number of years, I have helped clients administer a collective self-assessment of their SAP/Enterprise Maturity in which we test maturity levels for state of the applications, state of the end users, the business/IT dynamic, and the ability to measure business results. We find that in nearly every case, the only one of these areas in which the client has reached maturity is the state of the applications. End users are seriously neglected, the business/IT dynamic is shaky, and clients are seriously challenged when it comes to business measurement.

On a scale of 1 to 10 in these assessments, 7+ reflects maturity, 6 to 7 reflects near maturity, and <6 reflects a shortfall.  Here is how, on average, the clients have rated themselves.

State of the Applications = 7.3
Business/IT Dynamic = 5.8
State of the End Users = 5.5
Value Measurement = 5.3

Note that these are collective self-assessments and input is anonymous; these two elements drive a high level of credibility. Further, input is derived from twenty-five to forty client respondents with a general balance between business stakeholders and SAP/IT support and leadership. Unsurprisingly, responses from business stakeholders are more pessimistic than those from SAP/IT support and leadership.

Are You Becoming Obsolete? (A Quick Inventory)

To find out if your IT organization risks becoming obsolete in the eyes of your business staff, answer each of the following questions using this scale:  4 for "of course", 3 for "yes", 1 for "no" and 0 for "I don't know what that means".

In your organization:

Do you disagree that 'on-time and on-budget" are the most important success criteria for projects?
Do your efforts focus on measurable benefits as much as on your IT costs to gain those benefits?
Do you track key performance indicators (KPIs) for business performance as well for IT?
Do you provide active support (such as a super user network) for your end users?
Does your organization recognize and fully support business process owners?

Add up your score. If it is less than 10, you risk becoming obsolete and if you do not change your ways, those shadows will only lengthen.

Reducing Shadow IT to a Naturally Desirable Level

It isn't necessary to totally stamp out shadow IT. Indeed, as mentioned in the Wikipedia definition "shadow IT is considered by many an important source for innovation and such systems may turn out to be prototypes for future approved IT solutions."

I have nothing against a level of creative chaos provided that whatever IT assets are acquired are inevitably manageable. Nor do I believe that every application in an organization needs to be under an SAP rooftop. Shadow IT is most damaging to an enterprise when it frays the continuity and effectiveness of business process fulfillment or when faulty data is used as the basis for decision-guiding business intelligence.

The simplest way to avoid undue shadow IT is to establish a center of excellence by which empowered business process owners will continually improve business processes with the guidance of key performance indicators and will not have to negotiate with the SAP applications support staff.

If the SAP applications teams is fully focused on business process fulfillment and improvements, business will happily participate and will therefore be far less inclined to go into "the shadows".

...

For more on this subject, read IT, Your Fifteen Years are Up:  Cutting the IT Bottom out of SAP's Peach Basket here or download a printable version at

http://www.michaeldoane.com/Research___White_Papers.html

The Words are Out: SAP Press in Blue and Green

I published The SAP Blue Book, A Concise Business Guide to the World of SAP in June of 1998. The book serves as a demystifier for "anyone who has a stake in SAP". Over fourteen years and seven printings, it was self-published, available only through a direct order or via Amazon.

In 2009, I added The SAP Green Book, A Business Guide for Effectively Managing the SAP Life-Cycle. Both books address client concerns and have proven to be "for the whole team" as, through May of 2012, the average order quantity for The SAP Blue Book was 8.1 and for The SAP Green Book 5.3

In late 2011, I signed a contract with SAP Press to include the books in their catalog. Thus far, the association has been pleasurable in the extreme. Jon Kent and Kristine Erickson of WIS have been totally supportive in terms of promoting the book while Florian Zimniak and Emily Nicholls of Galileo Press provided excellent editing for both books, especially The SAP Green Book. It was especially gratifying to see the books prominently included in the SAP Press Bookstore this year at SAPPHIRE. Further, while The SAP Blue Book has only recently been released, The SAP Green Book, which was released in mid April, has been in the SAP Press Top Ten for over a month.

http://www.sap-press.com/products/The-SAP-Blue-Book-%E2%80%94-A-Concise-Business-Guide-to-the-World-of-SAP.html

I have recently been asked what I might write next and I have no answer to that question. But I will say that while we in the SAP eco-system have hundreds of books and white papers for practitioners, we are in great need of more books targeted to the clientele (my books are ready by SAP practitioners but also business stakeholders, business analysts, BI engineers, super users, training staff, and applications support people). I have therefore been encouraging a number of my contacts, many of whom are excellent writers, to join in.

http://www.sap-press.com/products/The-SAP-Green-Book-%E2%80%94-A-Business-Guide-for-Effectively-Managing-the-SAP-Lifecycle.html
Beyond this, I would like to compile a list of books that may not have specific SAP subject matter but which can inform the clientele about key issues. To start that list:

Management of the Absurd by Richard Farson. This should be read by business process owners, business process analysts, and anyone involved in organizational change management as the author writes elegantly and memorably about the challenges of building an organization that lasts.

CRM at the Speed of Light by Paul Greenberg. Even if CRM is not your subject, the business and IT lessons included in this book are worth gold. In addition, Paul (yes, I know him) is an engaging and often humorous writer, something rare in the techie world.

I look forward to hearing from all of you, especially about books that are highly readable, hopefully humorous, certainly memorable and with actionable advice.

My thanks in advance.