IRMBPM – Column 2

Wanted: UK/European Customer Case Studies For IRM BPM London, June 2013

Each year for the past few years, I’ve been a speaker at the IRM BPM conference in London; this year, it’s June 11-13 at the Radisson Blu Portman Square, and is co-located with the Enterprise Architecture conference. There’s always a good lineup of speakers, including half-day workshops, keynotes and breakout sessions on a variety of tracks.

This year, they’re looking for a few more UK and European customer case study presentations at the conference. If you have an interesting BPM initiative going on in your organization that you’d like to present, or if you’re a vendor and have a customer who might fit the bill, contact conference co-chair Roger Burlton, rburlton (at) bptrendsassociates.com. The call for speakers ended in December, but I know that they have some spots available for customer case studies.

BPM Framework For Product Development At Ericsson

Michael Andersson of Ericsson presented a breakout session on their BPM framework for product development in a global environment. Although many people are familiar with them as a handset manufacturer, Ericsson’s biggest business is to create and service communication networks that provide the infrastructure for telecom operators (their customers), and provide solutions to the telecom operators to pass on to the end consumers. With 100,000 employees and several product development locations around the world, they are actually the 5th-largest software development company in the world (by sales) as well as providing hardware solutions.

Their classical way of working, which is the same in many large-scale project-driven development efforts, was very waterfall-like: long release cycles based on static requirements, requiring extensive testing and very inflexible to change requests. They are moving to a more agile approach with frequent small deliverables, which is easier to test and deploy, and allows for more customer interaction during development.

The interesting part is that they’re using BPM for their product development cycle, which is not an application that I see very often: they have created a BPM framework within their product development ecosystem, which acts as a toolbox for managing and collaborating on requirements and the product development lifecycle. The ecosystem provides different perspectives to allow the different types of stakeholders to see a view of product development that is meaningful to them.

He walked through each of the perspectives (what I would consider tools or capabilities, not perspectives in the EA sense) and explained the use and audience for each; they all center around the product development framework portal. This framework provides guidance for different product development practices, and contains all knowledge for how they operate when developing products: product development principles; directives and guidelines (rules and policies); process flows (value chains); process components (procedural processes); performance measurements; and enabling resources in terms of information, IT and organization. Although most of this is provided top-down on an organizational basis, the process components (processes) are provided by the operational units doing product development in a more socially collaborative way.

A big benefit of the framework is to provide context for the engineers working in product development who might previously have only considered their own processes, and not how those relate to value chains, which in turn is a representation of the customer requirements. It also provides the platform for collaboration and sharing with other engineers in other geographic locations and business areas, or provides an interface to collaboration tools that are already in use.

This was really about BPM as a methodology, not a tool or system to be implemented; as Andersson said in his summary, you probably want to do BPM, but you may not want to call it BPM.

Best Practices For Modeling Processes And Rules With @Ronald_G_Ross

Ron Ross presented in the first breakout session of the BPM track, discussing best practices for creating better (and fewer) process models by modeling business rules together with processes. I’ve talked on this subjet quite a bit, although I come at it from the process modeling side whereas Ron is from the rules side. His business partner, Gladys Lam, was also in the audience; their book Building Business Solutions: Business Analysis with Business Rules and Ron’s earlier book Business Rule Concepts covers these concepts in much more detail.

I used to joke that process modelers tend to create process models wherein the business rules are just huge networks of flow logic directly in the process, whereas rules modelers create process models with a single task that just calls a rules engine. Ron isn’t going quite that far, but definitely advocates reducing the modeling of rules directly in a process notation (as BPMN gateways, for example) to create more concise and smarter process models. Rules should be expressed in business language; rules models are fundamentally different than process models, although the decisions made in the rules models can then be used within the process model. In his example, an insurance claim process included a conditional flow path when the claim is valid, but doesn’t explicitly show what rules are applied to determine if a claim is valid – that’s a job for the rules model.

He discussed some different patterns for harvesting rules from processes – conditional flows, maximum inter-task timing, and minimum inter-task timing – and introduced their RuleSpeak guidelines for expressing the resultant business rules in concise business language. He made a distinction between behavioral rules and decision rules; the former relies on a governor to watch for the rules being met or violated (often implemented in processes as an interrupting event of some sort), while the latter is about applying a decision at a point in a process. In short, rules are the embodiment of your business policies that ensure that you get consistently achieve the right results; in the rules world, processes are just a way of connecting the rules.

The key is to externalize the rules from the processes, and (primarily) model the high-volume standardized transactions. Low-volume, specialized processes don’t need to be modeled prior to execution, but can be informed and guided by rules: this is the basis of adaptive case management. This moves the need for agility into business rules – which are typically easier to change on the fly – and both simplify and stabilize business models.

Innovating Organizations With @ismiro

Michael Rosemann from Queensland University of Technology gave a joint keynote at IRM BPM/EA. He proposes that current BPM and EA approaches provide only limited support to corporate innovation: as he put it, we just put 100 people in a brainstorming session and hope that one of them has a good idea. Instead, we have to consider having ambitions and plans to achieve innovation, and support a conscious innovation competence and innovation process with the methodologies of BPM and EA. In other words, we need to be aware of how we innovate successfully.

He started with the concept of what drives innovation: first of all, a current problem, and a vision of a goal. This reactive approach is what he calls core innovation, but often represents only incremental innovation; this is often what we see in process improvement techniques such as Lean. His recommendations for problem-driven innovation: capture goals in your enterprise architecture; identify capability gaps; consider processes and problems; and involve all stakeholders in problem identification.

Next, he discussed constraint-driven innovation, with is much more transformational. He discussed some examples, such as the mobile-driven innovations that we’re seeing in several different markets: mobile payments via mobile phones in Kenya, and a virtual grocery store in South Korea that allows shoppers to scan displays in subway stations that look like the grocery shelves and have their shopping cart of products delivered to them at home. Instead of looking at classic process improvement techniques, which tend to be incremental, consider the constraints: in Kenya, there are few banks but many mobile phones; in South Korea, people have no time for shopping but need to pass through the subway station on their way to work. Unfortunately, standard process models don’t model key constraints and context very well, so we need to increase the context-awareness of EA and process models, and understand how contextual changes impact architecture and process in order to address this. When we live in countries that have many fewer constraints, it can be beneficial to do “reverse innovation” where we go offshore to look for constraints in order to drive innovation, then bring that innovation back to locations of fewer constraints, where the competition are likely much less innovative. An interesting way to improve competitive differentiation in a rich market.

Third is opportunity-driven innovation; his example is a crème brulee vendor in San Francisco who tweets his location daily; this idea has caught on like wildfire in Toronto, where I live, with local gourmet food trucks that relocate each day. This type of innovation captures the “affordances”, such as ability to geolocate and publish that information, and are often driven by emerging technology such as social media. Interesting how much mobile phones are part of this type of innovation these days: the other example that he mentioned was an airport using the movement of mobile phone Bluetooth signals to track queuing time in security lines.

Considering both the transactional and transformation innovation, we need to start considering innovation as a process; currently EA and BPM practices don’t support his very well, since we don’t necessarily understand that innovation is a process, or how to go about describing that process, and we don’t model constraints and context very well. If we do understand innovation as a process, it’s often just the transactional, incremental innovation that is problem-driven, not the more transformational constraint or opportunity-driven type.

He described four ways to innovate:

Enhance current practices, by eliminating steps (often wait steps, but sometimes by virtualizing a real-world experience and offering at a lower price), resequencing (e.g., move payment to end of a cycle and move to usage-based pricing), and specializing (e.g., offering higher-priced alternatives that eliminate waiting). Whenever pricing is involved, in fact, you can always start looking at usage-based and time-based pricing innovation patterns; Rosemann has a number of different patterns that can be applied to help drive innovation.
Derive better practices, through learning from others with similar processes, potentially in other industries. By considering who else has the same sort of problems; applying process improvements in mortgage applications to improve job application processes, for example, which applies filtering at the start of the process in order to reduce the number of instances that require more time-intensive consideration later in the process. He listed a number of derivation patterns to consider: pre-approval, triage, usage-based pricing, automation, and brokering.
Utilize potential practices, by considering the unused cycle time for any given resource, and finding a use for it; examples of this are people who offer their home driveway as a parking space for commuters while they’re off at work themselves. There are a lot of idle resources out there at any given time, whether people, vehicles, computing time or physical space; the key is to find the utilization differential in your enterprise architecture, and find ways to use those underused resources. Identifying and using those resources is a big part of becoming consciously competent. In some cases, that means becoming a broker between the underused resources and the potential consumers of that resource.
Create new practices, based on creative lateral thinking, not traditional pattern-based thinking. Consider that creativity is the unconventional generation of new ideas, whereas innovation is the process that carries those ideas through to new products and services.

He ended with a summary of the innovation dimensions and techniques; I believe he has a paper published on this, which I’d love to read. Lots of great ideas here for driving innovation at any level in any type of business.

IRM BPM And EA 2012 Kicks Off With @cybersal and @rogerburlton

I gave my Social BPM session yesterday on the pre-conference workshop day, but today is the official opening of the combined business process management and enterprise architecture conference in London. This is the second year that these two conferences are being held together, with attendees welcome to join either track plus some joint keynotes between them. Lots of great stuff on the agenda.

The day started with a joint keynote by Sally Bean, who runs the EA track, and Roger Burlton for the BPM side. They discussed the overlap between the two areas, and how EA and BPM are collaborative practices that enable business change: EA as more of the strategy and planning, with BPM taking over at the planning, execution then feedback of performance information to close the loop. They went through a diagram of activities across the spectrum, highlighting which were primarily EA or BPM, and which were done in both areas.

Just a quick keynote, ending up with the announcement that Sally Bean is stepping down from the conference chair position, after organizing the EA conference for several years. No word of who will be taking over this role for next year, but hers are big shoes to fill.

Social BPM At IRM BPM London

I’m in London this week at the IRM BPM conference. Today, I’ll be taking my Making Social BPM Mean Business 3-hour seminar for its first real outing (although I’ve presented most of this material in other contexts, just not in this combined form); over the next several months, I’ll be presenting this at three other conferences, but it’s always changing because there’s always something happening in this area.

Tomorrow, I’ll be moderating a panel on business architecture, where I’ll have the chance to discuss what it is, what the value is, who should be involved, and the skills required with John Gøtze, Neil Ward-Dutton, Mike Rosen and Martin Frick.

If you’re here, track me down and say hi.

Strategic Synergies Between BPM, EA and SOA

I just had to attend Claus Jensen’s presentation on actionable architecture with synergies between BPM, EA and SOA since I read two of his white papers in preparing the workshop that I delivered here on Wednesday on BPM in an EA context. I also found out that he’s co-authored a new red book on EA and BPM.

Lots of great ideas here – I recommend that you read at least the first of the two white papers that I link to above, which is the short intro – about how planning (architecture) and solution delivery (BPM) are fundamentally different, and you can’t necessarily transform statements and goals from architecture into functions in BPM, but there is information that is passed in both directions between the two different lifecycles.

He went through descriptions of scenarios for aligning and interconnecting EA and BPM, also covered in the white papers, which are quite “build a (IBM-based) solution”-focused, but still some good nuggets of information.

Workshop: BPM In An EA Context

Here’s my presentation slides from the workshop that I gave on Wednesday here at the IRM BPM conference in London, entitled Architecting A Business Process Environment:

Architecting a Business Process Environment

View more presentations from Sandy Kemsley

As always, some slides may not make much sense without my commentary (otherwise, why would I be there live?), but feel free to ask any questions here in the comments.

BPM Rapid Development Methodology

Today at the IRM BPM conference, I started with a session by Chris Ryan of Jardine Lloyd Thompson on a rapid development methodology with BPMS in their employee benefits products area.

They’ve been a HandySoft customer since 2004, using BizFlow both for internal applications, and for external-facing solutions that their customers use directly; they switched off a Pega project that was going on (and struggling) in one of their acquisitions and replaced it with BizFlow in about 4 months. However, they were starting to become a victim of their own success, with many parts of the organization wanting their process applications developed by the same small development team.

They weren’t doing their BPM solutions in a consistent and efficient fashion, and were using a waterfall methodology; they decided to move to an Agile development methodology, where the requirements, process definition and application/form design are all done pretty much simultaneously with full testing happening near the end but still overlapping with ongoing development. They’ve also starting thinking about their processes in a more service-oriented way that allows them to design (sub)processes for specific discrete functions, so that different people can be working on the subprocesses that will make up part of a higher-level process. This has tracking implications as well: users viewing a process in flight can look at the top level process, or drill down into the individual functions/subprocesses as required.

They’ve established best practices and templates for their user interface design, greatly reducing the time required and improving consistency. They’ve built in a number of usability measures, such as reducing navigation and presenting only the information required at a specific step. I think that this type of standardization is something rarely done in the user interface end of BPMS development, and I can see how it would accelerate their development efforts. It’s also interesting that they moved away from cowboy-style development into a more disciplined approach, even while implementing Agile: the two are definitely not mutually exclusive.

This new methodology and best practices – resulting in a lean BPM team of analysts, PMs, developers, testers and report writers – have allowed them to complete five large projects incorporating 127 different processes in the past year. Their business analysts actually design the processes, involving the developers only for the technical bindings; this means that the BAs do about 50% of the “development”, which is what all of the BPMS vendors will tell you should be happening, but rarely actually happens in practice.

From an ROI standpoint, they’ve provided the infrastructure that has allowed the company to grow its net profit by 46%, in part through headcount reduction of as much as 50% in some areas, and also in the elimination of redundant systems (e.g., Pega).

They’ve built a business process competency center, and he listed the specific competencies that they’ve been developing in their project managers, analysts, developers and “talent development” (training, best practices and standards). Interestingly, he pointed out that their developers don’t need to have really serious technical skills because the BizFlow developer really doesn’t get that technical.

He finished up with their key success factors: business involvement and user engagement, constant clear communications amongst stakeholders, and good vendor support. They found that remote teams can work well, as long as the communication methods support the user engagement throughout the process, since Agile requires constant review by users and retuning of the application under development throughout the lifecycle, not just during a final testing stage.

Great success story, both for JLT and for HandySoft.