process – Page 93

Gartner Day 2: Savvion customer presentation

Arun Mathews of Motorola, a Savvion customer, presented on the experiences of implementing BPM at Motorola. He started out with a list of reasons why they started with BPM, ranging from Six Sigma projects driving the need for new policies and procedures, through metrics and measurement needs. They started by mapping the as-is business processes, analyzing the processes, designing the to-be processes, and implementing in Savvion: pretty standard stuff.

Then, they start on process monitoring and continuous process improvement; as a big Six Sigma shop, continuous improvement and innovation are part of their corporate culture and their a process-oriented company, which gives them a huge advantage over many other large companies. They also have a focussed methodology for doing all of this, which appears to be a key differentiator for them over other organizations implementing (or attempting to implement) BPM.

They have a number of successful BPM projects that they’ve implemented, including core supply chain processes. Although he couldn’t share many of the numbers with us, since it’s proprietary information, he did discuss the metrics that they used as direct input into process improvement, such as timeliness and reworks, both of which impact customer satisfaction.

What did they learn from all this? First of all, this is a major paradigm shift that needs some amount of change management at all levels, but the business loves it once they start to see the benefits. Training in BPM methodology is key to this acceptance. Incorporate BPM into a long-term architecture plan, but start small on implementation projects with high ROI and/or high visibility.

Motorola has obviously made a big commitment to BPM, and are reaping the benefits of it: they’ve redefined their process automation and management to use a collaborative methodology with the business taking on much more ownership, which in turn reduces project timelines and costs. Motorola IT is recognized as an industry leader, and in 2005, their CIO recognized BPM as one of the top reasons for their innovation. The bottom line, however, is that it’s not enough to just buy a BPMS and start implementing: you have to have a process view on things.

Gartner Day 2: Appian customer panel

Next up was the Appian customer panel, hosted by Michael Beckley, co-founder and VP of Product Strategy at Appian, who I had met last night at the Appian booth.

Beckley started out with a few remarks about Appian, but the main part of the panel was hearing from their customers: Tom Bolger and Todd McGinnis of West Monroe Partners, Bruce Grenfell of Concur Technologies, Terry Jost of Talisen, and Dennis Nickel of Telus (who I met at breakfast this morning).

West Monroe is automating loan origination processes for their customers
Telus is adding Appian to their IT outsourcing business process not for the purpose of automation, but to make sure that the hand-offs between people are done in a standard fashion so that details are not lost.
Concur Technologies delivers travel and expense management services via SaaS to their customers, and manages business processes such as approvals involved in those services.
Talisen is adding BPM to procurement processes for their customers.

Interestingly, only one of the five is actually an end-customer; the others are technology companies who are implementing BPM for their customers in some way.

They really just got rolling when the first 30-minute session was up; like the ones I complained about yesterday, they structured an hour-long session spanning the two 30-minute session timeslots. With no logical breakpoint, I stepped out in the middle of the panel in order to catch the presentation by Savvion’s customer, Motorola.

Gartner Day 2: Bruce Williams

The second keynote speaker of the day is Bruce Williams of Savvi International, author of Six Sigma for Dummies (and the accompanying workbook) and Lean for Dummies, speaking on What BPM Means to Business Innovation. Funny, at last year’s Gartner BPM summit, everything was about Six Sigma; this year, this is the first time that I’ve heard it mentioned.

He points out one view of BPM, that it’s just a faster, better treadmill, but we’re still doing the same old things. BPM is more than that: not just operational efficiencies and defect reductions, but measurements and activity monitoring, process controls, and integration between systems and services. Furthermore, he goes on to say that the biggest value from BPM is in business innovation, not process improvement: the introduction of something new and useful and the process by which it is brought to life.

But why is innovation important? Why not just milk the cash cows? The answer is pretty obvious, although ignored by many traditional organizations: the lifecycle of every product or service eventually comes to an end, often because someone else introduces a disruptive product or service to the marketplace that obsolesces the old way of doing things. As James Morse of the Harvard Business Review said many years ago (a quote that I have referred to many times), “the only sustainable competitive advantage comes from out-innovating your competition.” Ultimately, innovation trumps optimization.

Williams continues on with a lot of stuff about why the innovation cycle looks like it does, but there’s really nothing new here: this is just the classic stuff for why products or services pass their peak: fatigue, customer demands, market redirections, competitive pressures, technological changes, globalization effects, organizational changes, demographic shifts, regulatory constraints, economic effects, supply drifts and many other factors. He does point out, however, that most US firms have no program in place for fostering innovation, and don’t even have a clear idea of how to become more innovative. Tom Davenport did a study last year that showed that companies are focussing primarily on product innovation, and mostly ignoring things like business model innovation, or even business process innovation; Williams added some things that didn’t even make the list, like innovation in accounting practices or risk management.

He went through some of the different dimensions of innovation — reactive versus proactive; incremental/sustaining versus radical/disruptive; formal versus informal — and looked at how these dimensions mapped onto some specific cases. When he referred to Americans as the kings of innovation, however, it made me doubt his world view overall and left me with a bit of a bad taste: it came across as ethnocentric flag-waving that has no place at a business conference. I recognize that Americans lead innovation in a number of areas, but there are many other countries in the world that are leaders in their own areas of innovation. He’s also under the deluded notion that everyone wants what Americans have, driving SUVs full of consumer goods back to their monster homes in the suburbs, and laughingly pointed out a survey that he had done that concluded that if everyone in the world lived like he did, we’d need over 7 planets worth of resources to accommodate them. Yikes.

At the end of it all, although he had a pithy quote about how BPM is the grand unification theory for business (which is apparently trademarked?!), Williams had very little to say about BPM, but a lot to say about innovation: one of the prime motivators for why you might be considering BPM.

Gartner Day 2: Daryl Plummer

The second day started with a keynote by Daryl Plummer, BPM/SOA Elixir (unfortunately, I missed the breakfast session with Michele Cantara about the BPMS market, but I ended up in a fascinating discussion about requirements collaboration using wikis with Jason Klemow, and the concept of subscribing to processes with specific attributes in a BPM with Dennis Nickel of Telus).

Plummer obviously likes to play with the new technology, which I suppose is a prerequisite for his job: he talks about TiVo and Second Life as things that are fast becoming essential parts of culture, although it’s clear that few people in the audience (except maybe me) embrace both the concept of downloading and consuming what I want when I want it, and the importance of online social networks.

He starts with some basic definitions of “service”, especially the relationship between processes and services, to drive home the idea that SOA impact people too, not just systems. He also made an excellent distinction between a model-driven (process-centric) view and a typical programmer view of things: a model-driven view describes what a person does (the business process); a programmer view describes what the system does (the code that attempts to implement that process). After having a discussion earlier about defining processes based on the data values that flow through those processes, when I couldn’t quite elucidate why that wasn’t ultimately the right way to do things, this strikes me as an important distinction.

He summarized the results of Gartner’s 2006 CIO survey (“CIOs are programmers that are passin’ for normal folk”), where the top business trend is improving business processes: there’s a lot of pressure all around to automate processes and improve them along the way, and this is going to happen only with both SOA and BPM. Plummer takes the enterprise architecture view of this, which I really appreciate — business context and functions driving from the top of the architectural view, and services as a way to fulfill the needs of the business. Processes need services to be implemented quickly and effectively, and services aren’t of use unless they are consumed by processes. SOA allows us to build an infrastructure of shared services for ready consumption by processes.

One of the key reasons for SOA and shared services is that legacy apps are still hanging around, in spite of all our efforts to get rid of them. Adding a service layer over the legacy apps allows us to create higher-level services and processes that consume these services without having to know how — or even what platform — to access the data directly on its original platform.

SOA, as Plummer reinforces, is an architectural style: not web services (although web services can be used to implement SOA), not a particular product, but encapsulated functionality accessed through a standardized interface that allows for loose coupling of services and applications. He goes through a checklist of how to know SOA when you see it, although some of the items on his list (such as a centrally managed runtime middleware network) are not, strictly speaking, an essential part of SOA.

He continues on with a discussion of event-driven processes (he refers to them as event-driven services in counterpoint to BPM-driven services, which is not necessarily a separation that I agree with). Services, properly implemented, can be combined into event-driven processes rather than structured, pre-defined processes, in order to be able to respond to events that happen in an unexpected order or manner. I did, however, like his view of the “new” application container: UI and navigation via a portal, security and management as part of the network, and logic and data accessed via services from wherever they might exist. Explicit orchestration ties all this together, which provides agility in the process model.

He points out that an SOA is never finished: in fact, it’s designed to never be finished. He uses the analogy of the Sagrada Familia in Barcelona, a cathedral that’s been under construction for more than 100 years now, and continues to change as it is built. He covers off some things about development techniques to be used when developing services within an SOA infrastructure, and highlights the business service repository as a centrepiece for BPM’s use of SOA.

His final recommendation is that the critical path to competitive business advantage goes through SOA and BPM: you need to use SOA as the underlying mechanism, BPM as the methodology for tying things together in order to get the business process improvement that’s required to differentiate your organization in the marketplace.

Pegasystems Lunch

This is out of chronological order, but I didn’t have my laptop at lunch so had to reconstruct this from memory and a few scratched notes.

I squeezed my way into the Pegasystems lunch, which was completely full, in order to hear Alan Trefler speak. He was very engaging, with lots of amusing graphics, but one phrase at the end of his talk really grabbed me: “you have to get away from the poisonous import/export environment so that BPM doesn’t become the next CASE”.

What he meant by this is that by modelling in one tool, then exporting it to an execution environment where there is imperfect round-tripping, there’s a danger of having the processes caught in the execution environment where you’ll be stuck maintaining it in a more code-like environment: presumably, the execution environment has imperfect modelling, or you wouldn’t be using another modelling tool in the first place. This makes the modelling tool useless except for the initial design process, and therefore hinders the future agility of the process. He makes the analogy to CASE (think back to the 80’s and 90’s), where nice-looking tools generated code could then be “tweaked”, but you then ended up doing any further code maintenance in the code environment rather than the CASE environment because there wasn’t proper round-tripping between the environments.

This is part of the problem that I have with external modelling tools: unless you can round-trip seamlessly, you don’t have process agility.

Food for thought.

Gartner Day 1: Jim Sinur

Jim Sinur took the stage for Are Rules Inside-Out in BPM?, where he claimed that he’d push the envelope in how we thought about rules. He started with how rules are a start, but agility requires a full business rule management strategy so that you can manage the rules that you’ve externalized, especially if you have multiple business rule engines. Now to be fair, many organizations haven’t even externalized their rules yet from their enterprise applications and business processes, but if they ever do, they’d better be ready to manage them or they’ll have a big mess of rules to deal with.

Today’s business rules landscape is pretty confusing, covering everything from neural nets and expert systems to business rule engines and business rule management systems. If these business rules are too rigid (unchangeable), it impacts the agility of the business processes and the entire organization; if IT has to spend a huge amount of time and money to change rules, then you can be sure that it’s not going to happen very often. However, IT is often unwilling to put control of the business rules into the hands of the business; there needs to be a way to have proper governance over changing of rules, but not so much control that it’s impossible to keep up with shifting business requirements. In many cases, the business has no idea how difficult it is to change any given rule, and some standardization of this — via rule externalization and management — would also improve service levels between business and IT.

The key is to understand where rules affect processes, and see where the ability to change rules for in-flight processes can greatly improve agility. Sinur went through the business benefits of rules, and some of the risks of fixed rules: primarily, business rule management is an enabler for governance. He also walked through different models for adopting rules: the safe and steady control model (slightly smarter process), the cautiously dynamic model (process with above average intelligence), and the aggressively predictive model (Mensa process). Obviously, the model has to suit the organization’s risk tolerance as well as the underlying process, since these range from just automating some well-understood decisions to suggesting and implementing new rules based on behaviour within the process.

He has some great recommendations for getting your rules under control, including such thoughts as 15% of the rules are the ones that the business really needs to change to remain agile, so pick the right ones to externalize, and understand both the business benefits and risks associated with changing that rule.

Watch for Gartner’s definition of what should be in a BRMS later in 2007, since this is becoming somewhat of a commodity.

Gartner Day 1: Lombardi customer session

Metastorm and Lombardi both did something that I really dislike: instead of running two 30-minute sessions after lunch, as the schedule would indicate, they ran a 1-hour session that spanned the two 30-minute spots. Since I had planned to see one session of each, I ended up feeling a bit unfulfilled by both.

Anyway, I attended the second half of the Lombardi session, Process-Driven: We’ve Only Just Begun, and heard Tim Barnes of Devon Canada (an oil & gas company) speak about how they were trying to improve communication between data, applications, processes, people and companies. For them, this is all about integration, and in fact started with an EAI team. They’ve brought in Lombardi TeamWorks, but are still figuring out how to tie that back to their ESB and their previous integration efforts. They’ve defined their best practices, but are still at the point of developing shared services.

They’ve done three smallish BPM projects so far, and he spoke about the HR onboarding process that they automated, with some degree of difficulty. One of the big problems was that the people on the project knew how to implement applications, but didn’t really get process, which required a complete team refresh — Janelle Hill spoke about exactly this issue this morning of having people on the team who are process-savvy.

Their next steps are to develop their BPM architecture and develop a formal life cycle around BPM initiatives, as well as enhance their existing BPM centre of excellence.

He was followed by Steve Schade of the Church of Jesus Christ of Latter-Day Saints (a.k.a. Mormons) discussing how they’ve applied BPM technology to their extensive geneaology project. They have a ton of family history records on microfiche, but if they were to image all of it (as they have done with some of it), there would be 19 PB (that’s 19,000 TB) of data, so they’re looking for alternatives in the process of putting this data online and searchable on their FamilySearch.org website. They had been doing some ad hoc scanning and indexing of records, but needed a scalable process where they could pinpoint inefficiences and get some control and visibility over the process.

In their first BPM implementation, they took a process that formerly took weeks to execute, and reduced the time to hours, while moving control of the project setup from IT to the business area. Through an obviously good selection of an initial project, plus good training and rollout plans, they had a big success on their hands. On their second project, they took on something that’s more complex, and which Schade thought might be a bit more than they could handle, but they’re still working away at it. They used Lombardi’s professional services and outside consultants on the first project to get them moving, and consider this essential to their success. They also see having business operations invovled in process modelling as key.

Gartner Day 1: Metastorm customer session

After lunch, we had two short vendor sessions: in some cases, the vendor themselves presented; in others, the vendor’s customer presented. For the first session, I went to see Metastorm’s customer Great Clips talk about The Power of SOA & BPM for Human and System-Based Process Optimization. Jim Waldo and Kathy Wetzel of Great Clips talked about how they analyzed their processes, particularly the process of opening a new (franchised) salon. Their process is very human-intensive, and there were a lot of gaps in the old process.

By applying BPM tools and techniques, they were able to eliminate 20% of the work steps and simplify another 70% of the steps, automate at least 8 handoffs and eliminate status checks. In total, they were able to shave 2 weeks of lag time out of the 16-week salon opening process, which has allowed them to grow the business without increasing the headcount — for five years now. There’s greater visibility into the processes, which provides for better management.

They phased in BPM over 3 years, and have seen an unexpected agility in introducing changes to processes, and find that they spend a lot less time worrying about the paperwork and the processes, and more time concentrating on the things that matter, like increasing their business and promoting their brand.

Gartner Day 1: Janelle Hill

More tough decisions on which session to attend, but I’m here in Janelle Hill’s BPM: A Change From Business As Usual.

Hill talks about four sea changes that are currently impacting organizations:

Globalization requires agility
Information transparency accelerates product and service commoditization, which requires innovation if you’re going to survive
Rising importance of the consumer, since we all as consumers have more and more choice on where we give our business
Information overload, mostly due to a flood of information being available over the internet but out of any appropriate context

So what’s really new in BPM, both as a management discipline and a technology? First of all, process orientation isn’t a replacement for everything that’s currently in place, like BPR was touted to be, but complements a functional orientation. Second, we’re moving beyond just process improvement to process visibility in order to become more effective. Third, we need to bring back some of those transformational ideas that we flung out when abandoning radical BPR (although not the techniques), and look beyond just incremental improvement to an iterative implementation of transformative change. Lastly, you have to have process agility, because the market is changing and you need to respond to it.

What else is changing is the way that we create these applications: we’ve moved from building it all ourselves to customizing packaged applications, and are starting to move to composing applications using agile methods rather than coding. And although BPM suites aren’t exactly new news, they are starting to be used more widely in order to more readily model, automate and monitor processes.

Hill discusses why explicit processes are the new imperative — processes that are visible to all stakeholders, and are independent of their implementation — in order to drive visibility, agility, synchronization of design and execution and all those other good things that we need from processes these days. BPMS’, by allowing the process model to directly drive the execution, help to drive the implementation of explicit processes. Evaluating BPM suites is done quite differently from evaluating other software products: there’s a blurring of the design and runtime, meaning that a range of composition skills from non-technical business to deeply technical must be supported. Also, external web services and other components are used extensively, so there needs to be different sorts of tools available for more than just orchestration of these components. Since many BPMS are shipped with templates and prebuilt components, there’s also a matter of selecting a suite that has templates that cater to your industry, or making a conscious decision that these templates are not relevant to you since you’re going to build your own processes from scratch anyway. She showed a great chart that mapped 11 business process characteristics (with examples) to architectural implications for BPMS selection, and discussed 7 different process use cases.

She then discussed some details of the roles involved in BPM projects, and the skills required; the business-IT-shared responsibilities is identical to what Gartner’s been saying for a year now, and hopefully we’ll soon start to see some of those short-term shared responsibilities start to shift either to business or IT. The process architect and process analyst are roles that are pretty much new territory, and existing architects and analysts needs to gain some skills before they take this on. I had a call from one of my customer the other day, a large financial services organization, that plans to just have a business analyst with no process experience take on what is essentially a process analyst role; I don’t predict a lot of success in this scenario, and I don’t expect that Hill would either.

Expect a new BPMS magic quadrant from Gartner in September, with some minor shifting of the existing players. Since last time around, Fuego has been acquired by BEA and FileNet has been acquired IBM, and some of the other major and minor vendors may start to make an appearance in the quadrant.

So far, I’ve been successful at blogging the sessions live. I’m off to lunch now and to have some meetings at the vendor booths, so I’m sure to fall behind with some of my notes from this point on.

Gartner Day 1: Benoit Lheureux

I decided on Benoit Lheureux’ session on BPM’s role in multi-enterprise commerce, although we’re had some technical difficulties and started late. This is much more about B2B and middleware than BPM, so it should be interesting to hear the perspective from the B2B viewpoint. If this turns out to be a dog, I’ll be out of here for Process Modelling for Profit, but the slides look interesting and I’m very interested in inter-organization collaboration and process choreography. He just used the word “mashup”, so I think that I’m staying, although the slightly smarmy “my friends” method of address did put me off a bit.

By now, the Gartner presentation framework is clear: each has exactly 20 slides; each has a Key Issues (agenda) slide with exactly 3 points (although Lheureux cheated by inserting a few extra slides that weren’t in the downloaded version of the presentation). People with 120-slide presentations, take note of how the professionals do it.

Lheureux describes his research as looking at multi-enterprise integration, or how to bind your business processes with the business processes of your trading partners. He opens with the question of how tightly you should be binding your applications and business processes with those of your business partners.

He makes the bold statement “EDI software is dead”, having been replaced by B2B gateway software that is more process-aware, and sees B2B projects as proliferating — doubling in the next five years — since there is a widespread recognition that organizations realize that their business processes are not just internal any more, and B2B needs to be a strategy rather than a discrete project. It used to be that you had your applications running internally, with some degree (if you’re lucky) of internal visibility, but no external integration or visibility: you’d need some sort of manual process for providing both integration and visibility to external business partners. Now, however, you can’t be competitive working that way any more. Furthermore, some of the functions done within organizations are being outsourced, further driving B2B requirements.

Gartner predicts that by 2011, 25% of new business software will be delivered as SaaS. Not 25% of what you’re running in total, but 25% of the new stuff; still, that’s huge. And I drink that particular Kool-Aid: I believe that this shift is happening now, and will continue to grow. SaaS is one form of B2B, in that you’re integrating in some way with the SaaS provider, but this also provides the potential to integrate with other trading partners via the SaaS platform itself. In addition to the SaaS model of multi-enterprise integration, there’s also the more traditional EDI-style e-commerce, plus integration via portals or mashups.

Lheureux discusses three approaches for implementing these B2B projects: run your own B2B gateway, outsource the B2B infrastructure (previously “EDI VAN”), or outsource the entire B2B project (previously “managed EDI”). He then dug into the issues of the choreography and monitoring of multi-enterprise BPM.

Gartner also predicts that by 2011, at least 40% of all new multi-enterprise integration projects will use BPMS. I can agree with this one too; besides, I figure if it doesn’t look like it’s going to come true, Gartner will just change the definition of BPM again. 🙂

He then discussed the four multi-enterprise BPM styles:

Blind document/transaction exchange, e.g., exchange purchase orders, to lower transaction cost, latency and errors by increasing automation. No shared process visibility or execution, and the process is difficult to change.
Intelligent document/transaction exchange, e.g., shared view of order-to-cash process, to provide some process visibility.
Multi-enterprise applications, e.g., shared execution of vendor-managed inventory, to centralize process control. This maximizes process visibility since both trading partners are participating in the same process (not just exposing a limited view of an internal process from one to another), but this is a big thing to do and requires a great deal of trust between the trading partners.
Multi-enterprise BPMS and rules, e.g., shared compliance management, in order to centralize the process and rules definition. This increases flexibility considerably, but again requires a great deal of trust and collaboration between the trading partners in order to make this work.

Organizations are going to have to implement more than one of these styles of multi-enterprise integration over the next few years as this field evolves. And if you’re already using B2B, B2B-enabled middleware or BPM, portals, SaaS or a variety of other technologies, then you already have some of the infrastructure in place to get started at this. The support for B2B versions of many of the standard BPM functionalities is just not there yet, however: practically no one is doing B2B process simulation, for example.

He ended up with some recommendations for multi-enterprise BPM strategy, such as synchronizing multi-enterprise and internal BPM projects, and developing a shared B2B infrastructure, with a focus on enabling shared process visibility (via BAM) and shared process control (via business rules).