Development leaders! Project leaders and business analysts! Application and solution architects! Want to move forward on your business technology (BT) journey and be viewed by your business stakeholders as a valuable team member? Take a tip from last week's Forums held in Boston. Embrace Business Process Management (BPM) And Customer Experience. Don't ignore them, embrace them. Why? They're essential to helping you achieve your business outcomes.
I know, I know. You read the above and now think "Gee Kyle, what's next? Going to enlighten me on some new BPM or customer experience management technology that's going to transform my very existence, my company's future?"
Nope. Let me explain....
Last week we hosted more than 250 of your application development and delivery and business process peers in Boston and focused on how to succeed in the new world of customer engagement. The most impactful discussions I heard were the side conversations we held with attendees, sometimes occurring over dinner and cocktails. We didn't discuss technology. We discussed the skills your peers were developing in two fundamental areas:
BPM - no, not the technology but the Lean and Six Sigma based methods, techniques, and tools organizations use to focus on business processes and not functions; to strive for continuous improvement; and to focus on customer value.
Customer experience - defined more eloquently by my peer Harley Manning, but I'll summarize as the methods, techniques, and tools used to understand how customers perceive their interactions with your company.
And I must say I am particularly keen to get into the thick of it this year. We’ve got some really interesting ones coming up; in relatively quick order, I have three different IQPC events (reflecting our growing partnership with IQPC):
Business Process Excellence in Financial Services Exchange in London on September 19 and 20. Here I will be delivering an opening keynote and chairing a panel between BPM heavyweights IBM (Phil Gilbert), EMC (Chris Preston), and Pega (Russell Keziere). That should be really interesting — we’ll have the heads of all things process-related from most of the big banks in Europe in the room. Looking through the delegate list, I can’t wait to meet them all — so much to learn from their experience and insights. Of course, I’ve got my own views, but nothing like testing them with those on the coal face of change.
Then in October I am chairing, keynoting, and running an active research session at the BPM Leaders Meeting in Amsterdam (October 20-21). Again, a really interesting lineup of speakers — a truly pan-European bunch, where we will focus on four major themes over the two days, culminating in a workshop format at the end where all the themed sessions/discussions feed into our active research session. My objective is to create a series of documents/blog posts/discussions that derive from the insights we’ll collectively build at the event.
I've always heard great buzz about Austin's South By Southwest Conference (often simply referred to as SXSW). The conference brings together indie film, music, and tech to discuss and collaborate on building the future. The tech side of the conference — SXSW Interactive — is often where up-and-coming tech ventures break major news. In short, SXSW Interactive often serves as a petri dish for testing out new ideas and innovations.
Last week I attended SXSW to zoom in on emerging trends in social and consumer tech that would likely spill over into the business process — and social BPM — world over the next several years. Of the 15-20 keynotes and sessions I attended, three or four really resonated with the overall direction we see for social BPM and social business:
For most of the past year or so, I have been working on a set of research docs in parallel to my inquiry and consulting work at Forrester. And the results are finally becoming available on the Forrester RoleView platform. With seven docs out in the past few weeks, this set should provide a comprehensive guide to Forrester clients setting up and running BPM programs.
In the early part of next quarter, I am entering a research phase on a topic I have alluded to many times: techniques for Process Architecture.
One of the key problems that BPM initiatives suffer from is that, even with all the attention, we end up with processes that still have significant issues — they are too inflexible and difficult to change. They become just another version of concrete poured in and around how people work — focusing on control rather than enabling and empowering.
A phrase that I picked up (from a business architect) put it fairly succinctly:
“People tend to work hard to improve what they have, rather than what they need.”
This was then further reinforced by a process architect in government sector on an email:
“The wall I keep hitting is how to think about breaking processes into bite-size chunks that can be automated.”
The problem is that we don’t have good techniques to design (derive) the right operational process architecture from the desired business vision (business capability). Of course, there is an assumption here that there is an effective business vision, but that’s a subject for another line of research.
I am talking about the operational chunks — the pieces of the jigsaw puzzle required to deliver a given outcome. Not how the puzzle pieces are modeled (BPMN, EPC, IDEF, or any other modeling technique), but how to chop up the scope of a business capability to end up with the right operational parts.
As some of you know, I am hopelessly addicted to golf. I can already hear you asking, “What does golf have to do with marathons, and what do marathons have to do with business processes?” Well, I’m glad you asked. Before becoming a golf addict, I was a runner – running 5Ks, 10Ks, and half marathons. My goal was to work my way up to a marathon. This is still my goal, but I learned a while ago that you can’t be a serious golfer and also be a serious runner – they both compete for long stretches of time on Saturday mornings (although I did have someone recommend that I combine the two into "marathon golf").
When I was a runner, I quickly learned that how you run a 5K or 10K is different from how you run a half-marathon. It seems obvious now, but when I trained for my first half marathon I didn’t realize how critical it was to hydrate all the way through and to also change your breathing technique. Ultimately, I found a training program that helped me get ready for my first race, and I ended up crossing the finish line in pretty good time and without killing myself.
We are sometimes so focused on details that we forget to think clearly. Nothing new there; it’s still a story about trees and forest. A few years ago, this was clearly the case when I met with one of the first vendors of run book automation. My first thought was that it was very similar to workload automation, but I let myself be convinced that it was so different that it was obviously another product family. Taking a step back last year, I started thinking that in fact these two forms of automation complemented each other. In “Market Overview: Workload Automation, Q3 2009,” I wrote that “executing complex asynchronous applications requires server capacity. The availability of virtualization and server provisioning, one of the key features of today’s IT process [run book] automation, can join forces with workload automation to deliver a seamless execution of tasks, without taxing IT administrators with complex modifications of pre-established plans.”In June of this year, UC4 announced a new feature of its workload automation solution, by which virtual machines or extension to virtual machines can be provisioned automatically when the scheduler detects a performance issue (see my June 30 blog post “Just-In-Time Capacity”). This was a first sign of convergence. But there is more.
Automation is about processes. As soon as we can describe a process using a workflow diagram and a description of the operation to be performed by each step of the diagram, we can implement the software to automate it (as we do in any application or other forms of software development). Automation is but a variation of software that uses pre-developed operations adapted to specific process implementations.
Returning home after IBM’s Impact user conference (Impact 2010). I’ve been to a lot of BPM conferences in my time, but never one this big. 6,000 miles (to Las Vegas) there and 6,000 miles home again to see 6,000 people going through a few of days of indoctrination and engage in a few meetings with important execs. From the point of view of a busy analyst, one has to wonder whether it was all worth it. But putting aside the sore back/neck and the lack of sleep, I think that, on reflection, it was worth the trip. I am sure other pundits will have already posted their own interpretations of the conference, so this is just one report to add to your perspective of Impact 2010.
6,000 people all gathered to hear the carefully scripted message. Well that is what it seemed like; a scripted story that was supposed to sound spontaneous. Even the Q&A was scripted on the teleprompter, which, quite apart from the wooden presentation style of one or two of the speakers, sort of took away from the central message.
There was a pretty important message there. A message that was being communicated to the faithful. And whether you like it or not, IBM has a lot, and I mean a lot, of faithful followers. I didn’t do a scientific assessment of the number of IBM badges versus non IBM badges, but even if half of the attendees were internal, there were plenty of customers there too. And those internal folks were also being recruited as emissaries and evangelists for the new mantra.
It was quite a challenge to nail down all the detailed points ... and of course, the publishing process took a little getting used to. To be honest, I had most of it finalized over a month ago.
The next doc is just about to go into the editing queue - that will focus on the rationale behind the Pega acquisition of Chordiant, highlighting a major shift we see in the way that Enterprise Apps are developed.
Inside the BPA Group at Forrester, we conducted a little experiment. I suggested that we should collaborate on a piece about the Pega acquisition of Chordiant. What followed was a large number of email exchanges. I drew the short straw in bringing all these thoughts together into a coherent whole. I prepared a document for Forrester clients to explore the acquisition in detail (probably getting through the editing process next week some time), and this blog post is culled from that document. So while the blog post bears my name, it reflects the collective opinions of Connie Moore, Bill Band, Natalie Petouhoff, John Rymer, Clay Richardson, Craig Le Claire and James Kobielus. Of course, I have put my own interpretation on it too.
Pega definitely wants to be in the customer experience/customer service business, and they want to get there by having a very strong BPM offering. It is not that they are moving away from BPM in favor of Customer Experience – they’re just strengthening their hand in CRM (or CPM as they would call it), more forcefully making the connection. We already knew this, but the Chordiant deal just reinforced that point (see related research doc from Bill Band in 2005 !!). This is not a new direction or change in direction for Pega, it is a strong move that takes them faster in the direction they were already going.
From a product point of view, Pega are adding/strengthening their hand – Choridant’s marketing automation and predictive analytics seem to be of greatest interest. Of course, Pega also values the engineering talent that Chordiant has, and will redirect those people over time to work on integrating these capabilities into the BPM offering. They were also interested in the vertical industry and functional expertise that Chordiant had to offer.