Giving Business Intelligence the Business, Part 5

 

It’s the process … again.

This article concludes a series we’ve run on this blog during the past several weeks about Business Intelligence. During that time, topics have been explored that will be built out in a whitepaper I am writing on behalf of Quest with several of its key service and solution providers. The focus has been, and will continue to be, on the Business use of BI technologies rather than upon those technologies themselves.

I was discussing all this yesterday with Bill McGinnis at RapidDecision (http://www.rapiddecision.net/) one of the contributing vendors to that whitepaper series. Bill, by the way, is a familiar face at Quest events and will be at COLLABORATE 10 (About COLLABORATE). We were discussing Business User Adoption, a segment of that whitepaper, in two ways: that (a) business decisions are typically made within the context of a finite, definable process, and that (b) for information (i.e. Business Intelligence) to be effectively used (i.e. Business User Adoption) it needs to be available in the way in which decisions are made within those processes. The result is that BI tools need to be designed, developed, deployed and supported within the context of a decision process. Much too often (most of the time?) information such as Reports, Analytics and Dashboards are used to validate a decision being made rather than to reach the decision in the first place.

What Bill and I realized was that, just as any organization has a finite set of Transaction Processes that ERP systems automate and integrate, it correspondingly has a finite set of key Management Processes that require information from BI systems. By first identifying those Management Processes and the way in which information is used during those processes, BI can become truly relevant.

As an example, consider the Management Process of Sales and Operations Planning (S&OP), which supports the Transaction Process of Plan to Produce. S&OP is the process that any organization uses to balance demand (Sales) with supply (Operations). Yes, every organization has this process (small ‘p’) by nature, although many don’t define it or design it as a Process (large ‘P’). If done well, this process results in an optimal plan. If not done well, it results in a negotiated – or even worse – averaged plan. The key determinant may very well be the way in which information is used. All too often, each constituency enters such a dialogue armed with its own reports or dashboards rather than there being a consolidated set, commonly referred to as a ‘Single Version of the Truth.’

Two needs emerge: (a) BI products need to be tailored to specific Management Processes and (b) prior to BI development or deployment an organization’s BI team needs to engage its functional counterparts around the way in which such processes operate and the way in which supporting decisions are made. This is analogous to the process mapping portion of any ERP deployment.

Of course, this requires two things: (a) that an organization is prepared to define a Management Process in the first place and (b) that a strong I.T./Business Alignment exists within the organization. Both of these items are very hard to accomplish, but it may very well be that improving Business User Adoption may depend upon it. We may be kidding ourselves by continually deploying these systems without them.

The next blog series will take on this issue of Business/I.T. Alignment but will be delayed for a couple of weeks. My wife and I are beginning our move south, and I’ll be preoccupied for a while. The packers arrive in one hour.  

Regards,
Rick

Giving Business Intelligence the Business, Part 4

 

Interlude

“It was not a failure to collect intelligence, it was a failure to integrate and understand the intelligence that we already had”.
— President Barack Obama, January 5, 2010

This is a piece that I have been wanting to write for two weeks, but have been cautious of the direction it would take — until I read a column this morning by Doyle McManus, a columnist for the Los Angeles Times (doyle.mcmanus@latimes). That column focused on the subject of information sharing and the Information Sharing Environment (referenced below). The more I consider all of this, the more comfortable I become of the direction I will take.

Following the failed effort of the Christmas Day Lap Bomber, much has been discussed and debated of the causes and steps that need to be taken. But that’s not the point of this column; it’s the point stressed by President Obama. And as for the aforementioned column by Mr. McManus (and there has been much less publicity of this), it reported on the four year existence of the Information Sharing Environment (ISE), a governmental organization whose goal is to promote “our ability to gather, analyze, and share information and intelligence regarding those who want to attack us … by leveraging existing capabilities and aligning policies, standards and systems to ensure those responsible for combating terrorism have access to timely and accurate information.”

Rodin's Thinker in LEGO® - Copyright © A. Lipson 2001

And yet we still experienced a “systemic breakdown” as egregious as this one. Just yet another example of governmental incompetence, right? 

But wait a minute. Is this truly unique to government? If we think about our own organization, whether it be a business, a non-profit group, a university or, yes, a governmental entity, we can probably recall a recent incident of “systemic failure” of business intelligence. Where a faulty decision, or a lack of one altogether, was the direct result of the correct information not being available when and to whom necessary. Or, if you will, when the single version of the truth was not recognized. (By the way, that term, single version of the truth, is now represented by an acronym: SVOT.)

In thinking about all of this I was reminded of some research that was conducted in 2002 by the Council of Logistics Management (now the Council of Supply Chain Management) on the ‘Shadow Organization in Logistics’ (Shadow Organization). The subject of the research was an organizational dynamic in which the formal business structure is often in conflict with informal power of its culture.

Perhaps intuitive, I agree, but …

Imagine the impact such things have on the effectiveness of BI technologies. And on our natural reaction in the face of such things to add yet more technology with predictable results. In a rather perverse way, the more technology we introduce into such an environment, the more ineffective the outcome becomes. Or the more pixilated our thinking becomes …

Perhaps our responsibility as I.T. professionals is to begin focusing equal energy around the effective use of BI capabilities compared to the energy spent creating and deploying them. Perhaps our responsibility as User Group members is to begin to request such content and dialogue from peers and vendors.

To this end, next week’s blog will end the six-week look at Business Intelligence with a discussion of ways to improve BI’s effectiveness by an improved alignment of BI processes and technology.

Regards,
Rick

Giving Business Intelligence the Business, Part 3

 

End-to-End BI Process Architecture 

Building upon the theme of my last post, Business User Adoption (meaning, the degree to which BI systems are actually being used in the course of real work), business understanding and acceptance of BI would be greatly enhanced if it could be displayed within a Business Process context, rather than a Technical one.

In other words, by defining technology in the language of the business. Not a very novel concept, but one that we have to keep learning. It’s in keeping with the belief that Technology within itself does not deliver Business Value; such value can only be delivered through the way in which Technology is used.

As proposed at the end of my last post, BI can be viewed as an end-to-end business process, starting with the collection of data and ending with the action taken in the use of that data. And herein lies the fundamental difference in this approach when compared to the technical way in which BI is viewed today. In a Technical context, BI ends with the delivery of the information via reports, analytics, alerts, etc. In a Business Process context, BI ends with the action taken (i.e., the business result). While I can find no references to this concept with respect to BI, there has been much written about I.T. being viewed as an end-to-end business process from a transaction systems standpoint. The best I’ve seen was provided three years ago by the preeminent BPM resource, the BPM Institute (What is End to End Anyway?).

A proposed end-to-end BI process is displayed below. Note that it is a linear flow, not a circular one. Linear flows represent both a beginning and an end to a process. This is the language of business. Circular flows are intellectual depictions of interaction and their use in depicting business processes should be stopped. But I digress…

 

Walk into any business manager’s office and explain BI using this process flow, and he/she will get it immediately. Once at the same level of understanding, walls will come down and true collaboration will begin. The business manager will understand what BI is about, and perhaps most importantly, the I.T. professional will send the message that Business Value is the real goal of I.T.

Regards,
Rick

Giving Business Intelligence the Business, Part 2

User Adoption Rates

So let’s deal with the elephant in the room: the continuing low rate of Business User BI Adoption, which is the key BI metric that reflects the degree to which BI systems are actually being used in the course of real work (my definition). Google ‘Business User BI Adoption Rates’ and you will be overwhelmed with choices. Lottsa stuff has been written for years about this, and the list of opportunities for improvement has been pretty consistent:

• Executive buy-in (the cure for all ills), Business/IT Alignment, User Training
• Data Management (availability, quality, governance), New Tools and Technologies, Integration
• Ease of Access, Timeliness
• Etc.

All of the above are, of course, very important, and one should not imply otherwise. A comprehensive piece on this was written not too long ago by tdwi (Increasing BI Adoption). And yet Adoption Rates have remained flat. Is the advice wrong or are we simply unable to act upon it? What are we missing?

Because it’s not an IT problem and cannot be fixed if we approach it that way.

Think otherwise? Consider a typical, architectural view of Business Intelligence systems:

 

Source: Successful Business Intelligence: Secrets to Making BI a Killer App
Cindi Howson (McGraw-Hill; 2007)

But how would a Business User view the same set of capabilities? How many of us have tried to describe BI to our functional counterparts in this way – and then encountered glazed-over looks? They don’t really care, and they detach at that moment. BI becomes an IT project instead of a Business project. Is it any wonder adoption is weak?

Viewing BI from a business perspective yields an entirely different result. It, by nature, would result in an end-to-end process view. Technology (the beginning of such a process) would be defined by the use of the information delivered (the end of such a process). Business users would be much more engaged. From a business perspective, I’d propose an entirely different way of viewing BI Architecture:    

 

In this way, the Business Process would drive the requirements and the dialogue with business users. Yes, that moves us out of our comfort zone (technology and applications), but it is the secret to dealing with the User Adoption problem.

Regards,
Rick

Giving Business Intelligence the Business, Part 1

A Slightly Contrarian View of BI’s Progress

Business Intelligence is one of Quest’s major themes for the late part of 2009, and it has already received sufficient attention to extend the focus into early 2010. Activities thus far have included a workshop held at Circuit (a regional conference held in Washington, D.C.) and the first round of the online ‘BI Shootout,’ focusing on partner solutions, conducted earlier this month. And there are more activities under discussion – including a white paper based on Quest’s findings. BI is a hot topic right now, and for good reason.

But wait a minute. Hasn’t it been a hot topic for quite some time? Poke around this question a bit and something appears to be a little off. Things just don’t add up.

2009 marked the fourth consecutive year in which ‘Business Intelligence’ was the top investment priority in Gartner’s annual survey of 1,500 CIOs worldwide (Gartner EXP Worldwide Survey). And yet, as Accenture recently observed from recent research, 40 percent of major corporate decisions are still based upon gut feel. Furthermore, a recent study by IBM revealed that two thirds of managers still “… rely upon error prone manual processes when it comes to dealing with data.” And research from Gartner has found that most companies still fail to link BI to the ‘last mile’ of business decision making, which results in BI investment going to waste. What’s going on?

One cannot question the degree of innovation under way within the software industry, advancing BI capabilities beyond the rudimentary Data Warehouses that began the explosion in BI capabilities fifteen years ago. It’s been truly remarkable. And yet Business User Adoption Rates, a key BI metric, have been flat – or even declining. For all of our success in advancing and delivering BI capabilities, the impact on business decision making continues to disappoint.

So what’s going on here? Are we underachieving as an industry, or does the bar simply keep rising? And thinking further, how do we measure the progress in the first place? While considering this, I remembered reviewing material earlier this year from tdwi, a research and education organization focused on the technology side of BI (tdwi). There was an article reporting on a recent survey involving business user adoption of BI. The statistics provided in the report are eye-openers.

While we always need to be careful of literal interpretation of statistics (think Disraeli … Mark Twain quotations – Statistics), the topic of user adoption comes up a lot and deserves further attention. More later.

Regards,

Rick

Where are the Architects? Part III

This will be the last in a series devoted to Enterprise Architecture. And thankfully. While it is a critically important topic, it is also one of the most over-reported – and yet consistently confusing. As a result, while EA is a core capability for large enterprises, it is virtually absent for most of medium and small size. And very little is written about what can be done to move EA beyond an intellectual exercise for such enterprises. We get it, we know we need it, but don’t know where to start. That’s the focus of this final segment.

But first I’d like to travel sideways a bit. Who hasn’t seen the recent spate of Infor’s ‘Down With Big ERP’ ads (Down With Big ERP) in publications such as Business Week and the Wall Street Journal? While admiring their chutzpah ( … with 80,000 customers and over $2B in revenue on the way to $3B, Infor doesn’t sound very small itself …), one also has to also admire their progress in rescuing 2^nd tier platforms such as SSA, MAPICS, BAAN and Epiphany (and 33+ others) from obsolescence and using world-class middleware between them into a pretty impressive open ERP Platform. But one must embrace the fact that at its core is Enterprise Architecture. The further one moves from black box, single instance ERP, the more one needs architects.

So that brings us back to the question of what should be done. As Oracle, with its extended suite of products, both On Premise and In the Cloud, continues the rollout of its own open ERP Platform, we’ll need to create enterprise architects as we created business analysts during the early days of ERP. And we need to develop standards for dialogue among ourselves and with Oracle, starting with a common definition and purpose around which to build measures and value. We could not have succeeded with 1^st generation ERP without Business Analysts, and we will not succeed with the 2^nd generation (Fusion) without Enterprise Architects.

The forum for those Business Analysts was Oracle’s User Group network, and it can be for Enterprise Architects as well. An Enterprise Architecture Special Interest Group (SIG) would be a wonderful first step. I’ve participated in User Group start-ups myself in previous lives and can attest to the fact that it is a rewarding experience, both personally and professionally. Quest is, of course, ready to facilitate this, and Oracle has enterprise architecture teams that are more than ready to assist in new ways of promoting the proliferation of this critical skill. What you can do now is let Quest know you’re interested. With such timing, we can certainly get some traction in time for COLLABORATE 10 in April.

And for those on the more technical side of enterprise architecture, I recommend joining the Oracle Enterprise Architect Forum (Oracle Mix: Oracle Enterprise Architect), a very active social network of technical architects designing and using Oracle products. You’ll need Oracle sign on privileges, of course.

So that wraps up the Enterprise Architecture series. The next series will be ‘Putting the Business in Business Intelligence’, a timely one, given that BI is a major theme for Quest in the fourth quarter of 2009 and beyond.

Regards,

Rick

Where are the Architects? Part II

I was due this week to discuss the challenges and opportunities that Enterprise Architecture places on User Groups, but a book arrived that I started reading … Sorry, Jim Prevo: I really wanted to follow up on your recent comment in to my earlier post, but I have realized that I should first explore the nature of Enterprise Architects further.  

The book is Wrench in the System: What’s Sabotaging Your Business Software and How You Can Release the Power to Innovate by Harold Hambrose, which was the central theme in his recent interview with CIO Magazine (Full Interview). I was referred to that interview in a recent discussion by a colleague, and while I disagree with a number of Mr. Hambrose’s conclusions concerning on-premise ERP, his perceptions are certainly eye-opening. After more than 20 years of experience with such systems, one cannot argue that we are still underutilizing many of their inherent capabilities. But that’s a discussion for another day.

My reason for reflecting on that interview is that it is very relevant to the discussion of Enterprise Architecture. Mr. Hambrose compares Business Analysts to a role he describes as ‘Designers’, which lines up very nicely with the context in which the blog arc refers to ‘Enterprise Architects’. I strongly recommend those reading this to also read the full interview linked above, if not the book itself.

The biggest challenge for Enterprise Architects, and for all of us in promoting and nurturing the role, is, as the last exchange in the interview concludes, “making the computers do precisely the right thing for you (sic) business…”.  

That rather simple (perhaps too simple) statement defines Enterprise Architecture better than anything I’ve read. EA’s purpose is to model business systems around the business, its organization, structures, processes and stakeholder value. But it is so much more than the Framework nature around which it is currently defined (EA Architecture Framework). Enterprise Architects (or, if you will, ‘Designers’) require a different approach to meet the fundamental business need just described.  While conceptually sound, Enterprise Architecture has struggled to gain broad acceptance for two reasons:

• It is not scalable, and is resource and tool intensive.
• Its top-down, Framework-driven structure requires extensive up-front leadership buy-in.

For most organizations, especially those of small/medium size, Enterprise Architecture frameworks are simply too big, too rigid and not actionable. They exist, but don’t yield business value. 

A different approach is needed – one that is scalable and that can evolve over time, as opposed to being mandated at an executive level. One that approaches ERP from an even balance of business and technology perspectives. And, most importantly, a process that is ‘iterative’ rather than one-way and top-down. In this way, Enterprise Architects can begin to earn the business ‘presence and trust’ that Business Analysts developed over time. The point, perhaps: Should we begin treating Enterprise Architecture as a Business Engagement ‘Process’ rather than a ‘Technology’ Framework?

Finally, this is the last new blog post this week. I’ll be at the Circuit conference in Washington, D.C. hosting a workshop entitled ‘Putting the Business in Business Intelligence’. Seems like a continual theme developing… 

Regards,
Rick

Where are the Architects?

Last week’s post looked at 2^nd generation ERP Platforms such as Fusion from the perspective of the customer by exploring our own ‘state of readiness’ for the changes coming our way. It posed three questions: 1) Do we have the wisdom to make the right (architectural) decisions, 2) Where are the Architects? and 3) Can I.T. organizations evolve at the same pace as the technology industry? Really, it’s the second question that may be the most problematic.

It seems like Enterprise Architecture is all over the place lately. It is the topic du jour in ERP circles, and yet it has been a relatively obscure I.T. methodology since its inception as the Zachman Framework in 1987. And now, after bouts of obscurity for the past 20 years, it is a hot topic of conversation, a growing presence in large I.T. organizations and potentially a high visibility career track in itself.

But why now? Perhaps the answer lies in the very nature of the emerging 2^nd generation ERP Platform. But first, let’s explore some history from ERP’s 1^st generation.

In the early days of ERP, the common theme was ‘change the process, not the software.’ Hard to believe, I know, but we all had a certain degree of technical arrogance at the time. There was a period of time where vanilla software took precedence over process differentiation. ERP Platforms at the time were very rigid and thus required adherence to packaged code and workflows, i.e.: ‘vanilla’ at all cost. But business models are not rigid. For businesses to thrive, they need to 1) differentiate themselves from their competition and 2) and adapt to changing market conditions. So there was a fundamental disconnect: Rigid systems technology platforms being hardwired into flexible business models. Each necessary and yet contradictory. Conflict was inevitable.

This I.T.-Business conflict damaged many programs and led to many failed projects. But a solution evolved over time with the emergence of Business Analysts. While virtually ignored by leadership, these individuals evolved from  ‘Power Users’ during implementation projects to an ongoing role focused on ‘determining the optimal point between the business need for process uniqueness and technology’s need for commonality’. Internally, Business Analysts sit at the convergence of I.T. and Business Functions, and they play an increasingly strategic role in organizations. Externally, Business Analysts now play a key role in with technology vendors in determining the ‘Fit and Functionality’ of software. If only we had anticipated this role and nurtured it from the beginning…  

Fast forward to the 2^nd generation ERP, whose very nature is defined by agility, not rigidity. Its open, service-based architectures will permit an increasing degree of flexibility in the way such platforms are deployed, maintained and upgraded. ‘Fit’ is now being defined by the degree to which the Platform matches an organization’s business model, and ‘Functionality’ is delivered by an interoperable set of applications and services, some on the ground and some in the cloud (…I know, but I had to mention cloud computing somewhere…). This technology holds great promise, but a new skill set will be required to bring it to reality.

Two imperatives emerge from this discussion:

• Business Analysts are to First Generation ERP what Enterprise Architects will be to ERP’s 2^nd Generation. The role needs to be clearly defined.
• The Fit/Gap process step so ingrained in ERP projects must be expanded or replaced with an Enterprise Architecture process step. Packaged Software architecture did not require this. Platform Architecture most certainly does.

Next Week: The challenges and opportunities that Enterprise Architecture places on User Groups.

Regards,
Rick

Are we ready?

This represents my first entry in this blog, and it comes with some hesitation. Quest’s goal with this endeavor is to create an idea exchange throughout its membership, opening up multiple channels of dialogue and learning. That requires subject matter that is practical, thought provoking and oriented toward results. As I’ve researched for this blog, I have reviewed many others to look for what works and what doesn’t. One thing I have found consistently: the vast majority of blogs have zero comments. Thus, my hesitation. With blogs, silence can be deafening … Topics need to be carefully selected as not to waste a reader’s time.

So why not start with a popular topic, but from an entirely different angle: Are we ready for Fusion?

Much has been discussed about emerging 2nd generation ERP systems such as Fusion. Rather than the ‘Package’ approach of 1st generation ERP, this emerging 2nd generation takes a ‘Platform’ approach, with an interconnected set of disparate applications and services. It can also include SaaS components (….or whatever form cloud computing will take…). The advantages of agility, flexibility and process-centric development that this architecture enables are compelling. We will finally have the ability to architect ERP around our various business models as opposed to the reverse, which was the outcome of 1st generation ERP (remember ‘Change the Process, not the Software’). Early adopters of ERP had to choose between the value of standardization and the need for process uniqueness. Perhaps we can now have both? And with Applications Unlimited, it appears that we can evolve towards Fusion at our own pace instead of on a forced march.

With Fusion, Oracle appears to be taking an industry leadership role. OpenWorld’s message was that of a management team tightly wound around a clearly articulated vision and a roll-out approach focused upon Day One Quality and Optimal Performance. While some participants (and… many blogs…) noted the lack of excitement around the ‘soft launch’ of Fusion and the conservative roll-out plans, a more in-depth consideration is one of careful planning and realistic expectations. The story is finally making sense and is exciting. Fusion appears to be finally ready for us.

But are we ready for Fusion? Consider:

• We now have choices rather than ultimatums. Two examples come to mind: (1) Implement all or nothing or (2) Upgrade or lose support. And there will be many others.  Do we have the wisdom to make those choices? What techniques will be necessary?
• Enterprise Architecture is a core component of the 2nd generation ERP. And not just the technology architects from the Distributed Computing days. These new EAs will design process flows across applications, platforms and even organizations. Packaged integration and workflows will be replaced by a model-based frameworks and templates. Where are the Architects?
• Business Process Management is a big component of 2nd generation ERP. Rather than enforce business processes embedded within hard-coded workflows, the new ERP will provide (require!) organizations to design their own business processes in close collaboration with their functional counterparts. This will create a huge challenge for I.T. organizations still striving for ‘Business/I.T. Alignment’. I.T. organizations must evolve; can they?

I have been told that the maximum length required to read a blog entry should be the time it takes to drink a cup of coffee. I think I’m there. But this is only a beginning. I’ll be exploring this topic in much more detail over the next few weeks but would first like to pause, take a breadth and ask for opinions.

What do you think?

– Rick Beers

So what exactly is “making I.T. real”?

What do we mean when we talk about “making I.T. real”?  If you’re a follower, what can you learn from the topics we’re going to be talking about?

making I.T. real is a practical, reusable how-to guide addressing the effective alignment of information technology with the structures, processes and objectives of the enterprise. 

making I.T. real promotes the view that information technology is now so ingrained in everything we do that it can no longer be considered solely an I.T. organization’s responsibility. Information technology is a mission critical, shared asset governed by I.T., yet owned by the enterprise.

making I.T. real is a developing set of methodologies intended to create a mutual understanding of business requirements and information technology’s capabilities.

1. An updated approach to Enterprise Architecture.
2. An iterative Business Engagement process.
3. The business impact of Business Intelligence systems.

Effective use of these methodologies, and others that follow in time, can transform Information Technology into a value-driven and respected business asset.