It turns out executives are hugely optimistic about how digital will change their business. Forty-six percent of executives surveyed believe that in less than five years digital will have an impact on more than half their sales. This suggests not only huge awareness of the potential for digital to change today's business but also an expectation that their company will be successful in making the transformation needed to bring this expectation to fruition. And it's in the biggest companies, where change is hardest, that executives expect the greatest change.
In B2B industries like consumer packaged goods (CPG), wholesale sales, and professional services, the shift is expected to be dramatic — Forrester estimates that the US B2B eCommerce market will be $1.13 trillion by 2020.
CPG execs expect digital to have an impact on almost half their sales. Even though the percentage predicted by 2020 is still less than 50%, if CPG companies were to generate anything close to 45% of their sales through digitally enhanced products and services or through online sales by 2020, it signals a dramatic shift in the CPG landscape. The ripple effects of the digitization of more and more CPG will be felt through wholesale and retail channels.
“Figuring out how to think about the problem.” That’s what Albert Einstein said when asked what single event was most helpful in developing the Theory of Relativity. Application integration is a problem. A big problem. Not to mention data, B2B, and other domains of integration. As an industry analyst and solution architect, what I’m most interested in first is how to think about the problem.
Pop Quiz: The Goal of Integration
Which of the following statements best articulates the goal of integration strategy?
The goal of integration is to keep data in sync across two or more siloed applications.
The goal of integration is to improve business outcomes by achieving consistent, coherent, effective business operations.
The correct answer is B. Was that too easy? Apparently not, because most of the integration strategies I see are framed as if the answer were A. Most, but not all — and it’s the ones framed around B that I’m most interested in. Here’s the difference:
A-style integration centers on technology. It begins with data and business logic fractured across application silos, and then asks, “How can integration technologies make it easier to live with this siloed mess?”
B-style integration centers on business design. It begins with a businessperson’s view of well-oiled business operations: streamlined processes, consistent transactions, unified tools for each user role, purpose-built views of data, and the like. It designs these first — that is, it centers on business design — and then asks, “How can integration technologies give us coherent business operations despite our application silos?”
As some of you know, I’m a bit of a political junkie. I believe I picked up the political bug from years of riding shotgun with my dad as he listened to Rush Limbaugh blaring on the car radio. As a kid, I loved listening to Rush and trying to understand where he was coming from, trying to understand his perspective, trying to understand his ideology. The term “culture wars” in U.S. politics is used to define a clash between two different political ideologies – conservatism and liberalism.
Over the past few years, I’ve also started using the term “culture wars” to describe the clash and fragmentation we’ve seen in the BPM market. In the BPM space, the clash has primarily been around dynamic case management (DCM), human-centric workflow, and straight-through processing ideologies.
I’m the first to admit that fragmentation and categorization is not always a bad thing, since it can help software buyers and decision-makers better understand which solutions best match their business requirements and desired business outcomes. However, the fragmentation in BPM sometimes overlooks the primary purpose and value proposition of BPM – to help support creating a sustainable business change program.
Outside of BPM, one of my other passions is mentoring college students through the process of launching new startups. I enjoy helping students tighten up their business ideas and seeing them build business plans that can attract the funding they need to stand up and implement their ventures.
Recently, after reviewing and providing feedback on a student’s business plan, the student responded, “I can launch my business without a business plan; all this planning seems like a waste of time.” At first, I thought he was joking. However, I could read by the look on his face that he was serious. I am sure you can imagine the conversation that followed.
The next day when I reflected on the conversation, I had a moment of satori. I could see that startups share the same risk/reward profile as business process management initiatives. Just like startups, BPM initiatives promise huge returns to investors and stakeholders. Additionally, just like startups, BPM initiatives are fraught with risks such as inadequate funding, low adoption, and difficulty attracting skilled resources.
My conversation with the student about the importance of business planning seemed to parallel conversations I often have with enterprise architects and business architects launching or retooling their BPM initiatives. Most tend to overestimate the BPM’s potential rewards and downplay — or do not fully understand — the risks involved with launching a BPM initiative. However, for the most successful BPM initiatives, I have found that their leaders tend to have a “lean startup” mentality.
What does it mean to have a “lean startup” mentality?
I recently finished reading Moneyball, the Michael Lewis bestseller and slightly above-average Hollywood movie. It struck me how great baseball minds could be so off in their focus on the right metrics to win baseball games. And by now you know the story — paying too much for high batting averages with insufficient focus where it counts —metrics that correlate with scoring runs, like on-base percentage. Not nearly as dramatic — but business is having its own “Moneyball” experience with way too much focus on traditional metrics like productivity and quality and not enough on customer experience and, most importantly, agility.
Agility is the ability to execute change without sacrificing customer experience, quality, and productivity and is “the” struggle for mature enterprises and what makes them most vulnerable to digital disruption. Enterprises routinely cite the incredible length of time to get almost any change made. I’ve worked at large companies and it’s just assumed that things move slowly, bureaucratically, and inefficiently. But why do so many just accept this? For one thing, poor agility undermines the value of other collected BPM metrics. Strong customer experience metrics are useless if you can’t respond to them in a timely manner, and so is enhanced productivity if it only results in producing out-of-date products or services faster.
Over the past three months, I've been heads down working on our upcoming "Forrester Wave™ For Human-Centric BPM Suites, Q3 2010" report. I've also been on the road over the past five weeks attending and presenting at different BPM vendor conferences - gotta love Vegas! I must admit I have barely had time to keep tabs on my different BPM tribes - blog sites, Twitter conversations, and LinkedIn discussions. I've been checking in here and there around different camp fires and adding a little spark occasionally when something interesting caught my eye.
But today, I ran across a simmering debate around social BPM on different blog sites, here and here. Seems like this is fast becoming the hottest topic in BPM. Guess I shouldn't be surprised since I helped drive the conversation around social BPM over the last year. It's very good to see the conversation evolve and also good to see different perspectives on how social can help improve all aspects of BPM initiatives.
Earlier this month I delivered a presentation on social BPM at IBM's Impact 2010 event. This presentation provided the most up to date perspective on how we see customers using and applying social techniques and methodologies to BPM initiatives. During the session, we framed social BPM in the following way:
My colleague, Holger Kisker, just posted a very insightful blog on the convergence of BI and BPM technologies. Yes, Holger, BPM vendors definitely have some BI capabilities. And so do some search vendors like Attivio, Endeca and Microsoft FAST Search. And so do some middleware vendors like TIBCO, Vitria and Software AG. And so do rules vendors like FairIsaac, PegaSystems. Should I go on? I have a list of hundreds of vendors that "say" they are a BI vendor.
But it’s not that simple. First of all, let’s define BI. In the last BI Wave we defined BI as “a set of methodologies, processes, architectures, and technologies that transform raw data into meaningful and useful information used to enable more effective strategic, tactical, and operational insights and decision-making”. To provide all these capabilities a vendor should have most of the necessary components such as data integration, data quality, master data management, metadata management, data warehousing, OLAP, reporting, querying, dashboarding, portal, and many, many others. In this broader sense only full BI stack vendors such as IBM, Oracle, SAP, Microsoft, SAS, TIBCO and Information Builders qualify.
Even if we define BI more narrowly as the reporting and analytics layer of the broader BI stack, we still want to include capabilities such as 11 ones we use to rate BI vendors in the BI Waves:
91% of executives say customer experiences are critical or very important to their businesses, nearly 5,000 consumers prefer better customers experiences over lower prices and better customer experiences drive higher revenue and profits,—according to Forrester Research .
Forrester analysts will host a “Tweet Jam” on February 10, 2010, from 1:00 – 3:00 PM ET to answer questions from Business Process professionals and App Dev professionals about top challenges facing their process improvement initiatives. During this interactive Jam session, Forrester analysts will share the results of our groundbreaking “Business Process Professional Role Deep Dive” research that uncovered major trends and critical challenges facing aspiring process improvement programs.
Key questions we will tackle during this Tweet Jam include:
1. Which role(s) should lead your business process initiative?
2. What are the best practices for establishing your BPM COE?
3. Do yourtraditional business analysts have what it takes to drive BPM initiatives?
4. How heavily should you rely on your software vendor for project implementation?
5. How should you connect your EA and BPM initiatives?
6. Which process improvement methodology (Six Sigma, Lean, TQM) is best for your initiative?
7. How should you incorporate BPMN modeling into your process initiative?
8. How should you measure the progress or success of your process initiative?
9 What’s the typical sizeand composition of process improvement teams?
10. How should process improvement connect to master data management?
11. How do you think Social BPM will impact your organization?
The session will be hosted by Clay Richardson, Connie Moore, CraigLe Clair, Alex Peters, John Rymer, and Ken Vollmer. To join this interactive conversation, simply tune in to the #bpmjam hash tag on Twitter or follow the analysts that will host and moderate the session.
Business Process professionals are scratching their heads at today's announcement by Progress Software to acquire Savvion. Process professionals are asking what exactly does this deal mean - for Progress and Savvion's combined customer portfolios and for the broader BPM market.
Connie Moore and I sat down earlier today to record a video blog post on what this deal means for Business Process professionals and to the broader BPM market.
In our video blog post (also posted on Forrester's YouTube Channel), we outlined three key themes driving the Progress/Savvion deal and how Process pros should view and respond to the latest round of acquisitions in the BPM space: Process pros should: