Tag: BrainStorm2007

BrainStorm BPM Day 2: Dan Madison

Last session of the day for me: I’m headed off to the airport following this, although I realize that the probability of a flight in or out of Chicago being on time when it’s snowing is near zero. With some luck, I’ll make it home tonight. The only thing that I’m missing is some sessions where the vendors get to show off their products, and a final wrapup keynote.

This session by Dan Madison is on Creating the “To Be” Process, something that I often do with customers, and I’m always looking to learn new tips and techniques from others who do the same thing. This session is part of the Organizational Performance symposium, the first of those that I’ve attended these two days.

He suggests a number of “lenses of analysis” to look at processes and derive the “to be” processes from the problems seen in that process.

First, create a customer report card, which for each ranked criteria, shows the current process performance (usually around quality and timeliness), what the best possible performance in that process would look like, and the two main competitors or outsourcers.

Second, look at the things that frustrate the people who are currently participating in the process, since there’s a high correlation between frustration and quality problems: frustration has the ability to act as a lens focussed on problem areas. Once frustrations are identified, the process participants tend to generate a ton of ideas on how to fix the problems, and there’s a huge amount of buy-in for changing the process from the grassroots level. I’ve definitely seen this with my customers. There was an audience question about how to keep this from becoming a bitch session, and Dan said that he uses some basic rules if things start to go that way: only process problems are discussed, not people problems; and each person can only bring forward their three main frustrations.

Third, look at the time required for each type of work in the process: processing, waiting, rework, moving, inspecting and setup. He finds that processing — the actual work — is typically only 2-20% of the time, which indicates that there’s a huge amount of inefficiency in the process. Of that small percentage, even all of that may not be time that adds value to the process. If you’ve automated your process with BPM, then you can gather this information with your system, but if your processes are still manual, then figuring out how your process breaks down will be manual, too.

Fourth, a cost lens such as activity-based costing; ABC calculates what it really costs to deliver a specific product or service by looking at the labour, overhead and material costs of each step in a process.

Fifth, a quality lens such as Six Sigma for measuring defect rates or some other relevant quality measure.

Last, take a look at benchmarks and best practices, by looking at your direct competitors and what they’re doing; and by looking at companies that have a process similar to your problem process and are considered to be world class, regardless of their industry.

He then moved on to design principles for the to-be process:

  • Design the process around value-adding activities.
  • Provide a single point of contact for customers and suppliers.
  • If the inputs coming in to the process naturally cluster, create a separate process for each cluster.
  • Ensure a continuous flow of the “main sequence.”
  • Bring downstream information needs upstream.
  • Involve as few people as possible in performing a process [our old adage of reducing handoffs lives!].
  • Ensure 100% quality at the beginning of the process.
  • Use co-located or networked teams for complex issues.
  • Redesign the process first, and then automate it.

Putting it all together, creating the to-be is the synthesis of:

  • Customer feedback
  • Worker frustrations
  • Time analysis
  • Cost analysis
  • Quality analysis
  • Benchmarking and best practices
  • Design principles
  • Information technology

Dan’s obviously experienced at this: he does it as a consultant, he teaches process mapping and improvement at the local university, and he has a couple of books that he’s written on it. I haven’t read his books, but I’ll be checking them out soon.

BrainStorm: Meeting my peeps in Chicago

I’m starting to see more and more familiar faces at these BPM conferences, and this one is no exception: I’ve met Gregg Rock and Tom Dwyer of BPMInstitute.org at a couple of conferences now, finally met Brett Champlin at the last Gartner conference, and Bruce Silver and I meet up so often that our spouses are starting to get suspicious. 🙂  There’s also the people who work for the vendors — I seem to see many of the same ones at every show, and these shows must be some small form of purgatory for them.

It’s also fun to meet people who I’ve only met online previously, and I’ve had a couple of those experiences here in Chicago. David Novick, who added a comment to my blog that turned into an email conversation, recognized me in one of the sessions — I guess that Rannie’s new headshot of me is paying off. At lunch, I happened to sit at the same table as Barbara Saxby from Ramco, who was on a webinar that I moderated last month. And Jean Campagna of Resolvit found me yesterday evening at the vendor showcase/drinks party to say that her colleague was sending me a hello: apparently her colleague back at the office has been reading my blog to Jean over the phone.

BrainStorm BPM Day 2: Ken Orr

For the first breakout session of the day, I attended Ken Orr’s talk on Business Process Driven Enterprise Architecture. He started out with some observations: improving business processes is essential for enterprises; business architecture is critical; modelling is critical; and business processes are hard to manage in the real world and especially in big organizations. Nothing earth-shattering here, but excellent points.

He made a great analogy by talking about IT levees — fragile yet critical applications and systems where you know that they’re a weak point but just never find the time or money to fix them — and understanding when they’re going to break. Apparently, a year before Hurricane Katrina, there was an exercise that modelled exactly what would happen if a force 4 or 5 hurricane hit New Orleans, but nothing was done; when Katrina hit, the levees failed exactly as modelled. Orr talked about mission critical spreadsheets as being one class of IT levees that are all set up to fail at the wrong time.

He talked about how enterprise architecture is like city planning, where your deliverables are things like a city plan, a zoning plan, a building code and an approved building-materials list. Sticking with the disaster analogies, he talked about how building codes are the result of disasters, and the obvious analogy with software and system disasters is pretty clear.

He covered off their enterprise architecture framework briefly, but used it mostly to discuss how the different layers in a framework interact: in short, technology changes enable business changes, and business changes drive the need for technology changes. He also talked about determining what type of business that you’re in, that is, what business processes are you really doing, so that you can figure out whether or not you should be in those businesses as well as how to improve them. Funnily enough, he really answered part of the question that I asked in the panel in the previous session with respect to getting an end-to-end business process view, but that’s sort of expected from an enterprise architecture person since EA can be a key tool in doing just that. In his terminology, what I’m talking about is a value stream, defined by James Martin in The Great Transition as “…an end-to-end set of activities which collectively create value for a customer.”

Update: I forgot to add “Orr’s rules of modelling”, which he gave after I had shut down my laptop, so were just scribbled on a piece of paper:

  1. It’s more important to be clear than correct. If you’re clearly wrong, someone will correct you. If you’re obscurely correct, you may never know.
  2. It’s not important that your first model is correct, only that your last model is correct.

BrainStorm BPM Day 2: Transforming to a Process-Driven Enterprise

Following our morning break in the beautiful but sadly lacking in hot water (for tea) vendor showcase area is a panel moderated by Tom Dwyer on Transforming to a Process-Driven Enterprise, featuring speakers from Adobe (Ashish Agrawal) and BEA (John Lauck, former president of Fuego before it was acquired by Fuego) as well as the last session’s speaker, Jeremy Alexis. Surprisingly, the speaker from Adobe didn’t show up until 13 minutes after the panel was supposed to start, but many of us think that Adobe is pretty late to the BPM space anyway.

I’ve been tagged by Tom to ask a question early on in order to get things rolling, which means that I’m paying more attention than usual. 🙂 Panels are difficult to blog about because they’re so unstructured and there’s no visual aids, but there’s often some conversational gems that pop up.

The first question was about the business-IT divide, which resulted in a completely expected reply: if you don’t get the business and IT people together, then BPM initiatives will almost certainly fail. Lauck just referred to “SOA” derisively as a buzzword, which was a bit unexpected and did make me laugh — wonder what his current bosses think about that — and then took a swipe at BPEL.

I then popped up and asked how organizations can move from being functionally-focussed to having an end-to-end view of their processes that will move from local optimization to global optimization. Unfortunately, the two vendors appear to have thought that I asked the question “how can I sell more software to my customers”, because they both spoke about how you start with small projects, then roll out other projects across the enterprise and possibly find some efficiencies via shared services. In fact, Lauck said that if you have “grandiose plans” (his words) like modelling your end-to-end processes, then you’ll just be modelling forever. Okay guys, but you’re not answering my question: everyone’s talking about moving from functional silos to process-centric views, but how do you actually do it? Shared services is not equivalent to finding a global optimum. Tom must have known that I wasn’t satisfied, because he came back to me and asked if I wanted to clarify. By then, I was itching to have the microphone back, and said explicitly that I hadn’t asked them how they could sell more software, but that’s the question that they answered, and said that I was interested in Alexis’ view on this since it is really a question about how companies innovate. He responded that leadership is key, which is a sort of motherhood and apple pie statement, and talked about the importance of change management. Okay, that’s closer, but still doesn’t answer the initial question.

A third question came up about how transitioning to a process-driven organization creates winners and losers, and how companies deal with losing people who just don’t fit into the new world order. I think that the question was really about people who can’t adapt to the new way of thinking, which is essentially a change management issue.

BrainStorm BPM Day 2: Jeremy Alexis

As an engineer, I love to hear about design, and I really liked Jeremy Alexis’ talk on a Framework for Making Better Decisions during Product Definition. He teaches at the local Institute of Design (and has a blog about one of his design courses) and acts as a design consultant, and started out by talking about the problem with McDonalds’ ketchup packages — love it, even if it has nothing to do with BPM.

He moved on to some interesting graphs of patterns of good decision quality, and some fatal flaws in decision making:

  • Overconfidence
  • The endowment effect, where the owner of something feels that it is worth much more than it actually is (all Web 2.0 companies should pay attention to this)
  • Loss aversion, such as fear of losing market share if a product is changed
  • Horizontal flight/vertical flight: in areas of uncertainty, we tend to ignore what’s important and focus on what we feel more comfortable with
  • Groupthink, where not enough outside ideas are introduced and a small group believes that what they have developed is the right thing

He presented some ideas about decision making at the “fuzzy front end” of product definition, that is, during discovery and scoping, where there are few good tools for making decisions, unlike during later points in product definition (business case, develop, validate and launch) where there are a number of robust tools for decision making. He had some great findings from research on decision making at these early stages, such as its ad hoc and unstructured nature and its internal focus, and how these can make things go terribly wrong. Since there are a lot more ideas in the pipeline at the front end, it’s pretty necessary to determine the winners and losers as early as possible.

Alexis showed us a high-level generalization of what really happens during the front-end discovery and scoping parts of product definition, which tends to just create more of the same rather than actually drive innovation. He then discussed a new approach — create an innovation strategy, triage concepts as they are created, and use a consistent approach to evaluate triaged ideas — and drove into detail on each of these steps. He brought together a number of interesting concepts, such as the 10 different types of innovation plotted against a company’s “ambition level” to see which types of innovation that organizations at different levels of innovation ambition should attempt.

He ended up by stating what we in the technology industry already know: that the ultimate goal of most startup companies creating an innovative product is to be acquired rather than taking their company public, and that many large companies are counting on acquiring their innovation rather than developing it themselves.

BrainStorm BPM Day 2: Andrew Spanyi keynote

I didn’t come to Chicago specifically for the snow, but it didn’t disappoint me nonetheless: big wet snow dripping down, just enough to get me wet crossing the road from my hotel to the Drake.

We started the day with a keynote by Andrew Spanyi, who I didn’t give a great review earlier this year for his talk at ProcessWorld, and it seems to be a very similar talk that he gave there about business process governance although he’s promising some new research data. Also, this time it’s at the beginning of the day rather than the end, so I likely have a better attention span. Besides, he’s a fellow Canadian (although transplanted to the US), so he knows how to pronounce “process” 🙂

He starts out with his 2003 and current definitions of BPM, the latter of which adds (no surprise) the words “management practice”, before putting in a plug for his two books.

The study that he did through Babson College was a “mindset” study, which explored the role of executive mindsets in enabling a BPM focus, with the hypotheses that if a firm has embraced business process thinking, then they’d have an enterprise-level business process relationship map, they’d measure things from a customer’s point of view, they’d have assigned process owners with accountability for cross-functional processes, and they’d have a plan for business processes within the organization.

Only a third of the 18 respondents (five, by the sounds of it), however, reported that they actually had all of these things (I have a question as to whether 18 data points is a statistically sufficient sample size, but then I never was all that good at stats). There were some common characteristics in these five companies: a supportive and vocal CEO, passion about performing for their customers, some sort of competitive or environmental threat, and a receptive culture within the organization.

The companies often used a framework to help them bootstrap their efforts, which allowed them to develop their process management models and plan in a relatively short period of time, and they were enjoyed a fair degree of success as corporations.

He went back to a subset of the original sample set for a follow-up survey — nine companies, four of which were in that earlier “leaders” category — and found that they still identified the same challenges. Some lessons learned emerged from this:

  • Change management is key and takes longer than you think.
  • IT enablement is critical to make all this happen, often by taking away the old tools and replacing them with newer tools.
  • Build an organization-agnostic view of the process.

The outcome from all of this is that the organizations are seeing more cross-departmental collaboration (and less finger-pointing) due to the end-to-end view of the business processes, and that there’s a much bigger focus on the processes rather than departments — ultimately, this process-centric view is what’s going to drive success.

In the Q&A, he made the statement that BPM and BI must converge, and that companies that he talked to in the survey said that they wouldn’t buy software unless it had both — and intriguing statement that I would have loved to hear more about.

I still found that Spanyi covers too much ground in a short period of time, and flips through his slides too quickly to absorb a lot of the information: there was one five-point slide with some pretty critical summary information, maybe 20 words in total on the slide, and I could only jot down the first three points before he flipped to a rather meaningless graphic where he stayed for two minutes. However, he’s obviously knowledgeable about this stuff and I liked his talk this time around.

BrainStorm BPM Day 1: Tom Dwyer closing keynote

Tom Dwyer of BPMInstitute.org/BrainStorm Group finished up today’s formal sessions with Enabling Business Process Innovation.

As he pointed out, innovation is what drives company growth, and he listed the types of innovation that can be seen in organizations:

  • Business model, e.g., use of shared services centres
  • Process and services and markets, e.g., electronic channels
  • Operations, e.g., self-service

He covered a number of good examples of some strategic industry initiatives in a number of different industries, and discussed innovation concepts in general before drilling down to process innovation specifics.

He spent some time discussing process-driven companies, which is a topic that everyone seems to be talking about lately: not just analysts and vendors, but customers are starting to ask about this as they see the advantage of managing end-to-end processes rather than chopping them up into functional silos.

He moved on to redefine the acronym “BPO” — universally recognized to mean “business process outsourcing” — to mean “business process organization”. Yikes. There were some great points here for process-driven companies, but the BPO acronym was completely distracting. He had a graph that charted the course to business process excellence, which was a sort of maturity model: “just get by”, “look for efficiencies”, “drive business agility” and “leverage process capital for market leadership”. He also listed some of the artifacts and results of becoming process-driven, from documented process flows, a rules repository and process metrics to customer satisfaction measures. As the scheduled end-time passed, the presentation dove into a discussion of SOA and attendees started to bail out, but Tom wrapped it up with some useful summary points on how innovation helps to create a competitive edge.

The presentation was much too dense with text and statistics for any time of the day, but especially for the last timeslot of the day — the energy level in the room was pretty low. It’s too bad, because Tom had a lot of great information here.

BrainStorm BPM Day 1: Neal McWhorter

I switched streams to the business rules symposium for the last breakout session of the day, The End of Requirements, because the description sounded too good to miss:

Business wants control of the business back. For years we’ve lived with a process where the business creates “requirements” and IT creates a business solution. While business processes are the lifeblood of an organization, rules are where the volume of business changes are. If the business is going to take back control of its own fate it all starts with making sure that the business rules they own are really under their control after they go into production. The current requirements process simply can’t handle that. It’s time to embrace a Business Engineering-based approach and move beyond the requirement-centric approach that we’ve love to hate.

He makes the distinction between knowledge and behaviour: rules is about (reusable) knowledge, and processes are about behaviour. For example, you might have a rule that would allow you to determine if a customer was a “good” customer, and you might use that knowledge in a process to provide a discount. He discussed different views of rules and how they integrate with processes:

  • Rules as structural knowledge about business entities
  • Rules as business judgements
  • Rules that trigger events

Unfortunately, McWhorter didn’t ultimately talk about how the business is going to get control of the business rules, or how it’s going to work once they do, which is what I was expecting from the session description. He did finish up with a call to arms to bring a design function back into the business side — sort of like what business analysts are supposed to do, but don’t because they don’t have any design training — which would allow proper designs to be created before things are ever passed on to IT.

BrainStorm BPM Day 1: Peter Gilbertson

Peter Gilbertson is a  senior business analyst at CUNA Mutual, and his session was on Talking Process to Executives: Process, Tools and Techniques to Sell your BPM Project, which is about how to “sell” your BPM project to the people who write the cheques. Although he’s looking at it as an internal person selling to his own executives, I’m often in the position of helping people like him create exactly this sort of rationale to carry up the food chain and thought that it would be worthwhile to hear what they did.

He started by talking about their business review process, which is not really specific to BPM projects:

  • Build the business model, especially important for communication and education because they had a whole crop of new executives from the insurance industry, whereas CUNA deals with both insurance and investment products.
  • Determine industry benchmarks, by identifying key “success levers” and comparing themselves with their competitors.
  • Document core processes, which is where a lot of people start; Gilbertson felt that if they hadn’t done the first two steps, then the core processes wouldn’t have made sense to the executives.
  • Develop performance measures, but took the usual tabular data views of things such as customer service metrics and converted them to graphs to make the business health and trends more obvious.
  • Determine gaps, which they did using a pipe analogy: there were spots where the pipe leaked, or wasn’t big enough, or didn’t fit with other pipes. I liked the analogy, and Gilbertson said that it was immediately obvious to the executives and allowed them to move easily into process improvement specifics.
  • Develop strategy, again using an analogy: “shoot the moon” with a space shuttle and booster rocket visual. In order to show how the decisions were derived, they also created a decision tree to show the path to the strategy recommendations.
  • Create plan, which is the detailed execution plan and timelines.

He summed it up in his top 10 tips:

  • Start at 10,000 feet and parachute down
  • Show “industry standard” business models
  • Focus on (and show how) the customer gets served
  • Explain how you make money
  • Walk through high level processes
  • Pinpoint areas for improvements
  • Use visual (e.g., graphs, charts, pictures, etc.)
  • Use consultants or industry experts to build credibility [I liked this one 🙂 ]
  • Create a detailed plan to execute project
  • Continually communicate, educate and position the project

This was really about how to present the material to executives, with very little on how to create the material, but there were some good points: use visual analogies where appropriate, feed them small bits of information at a time, and show why and how that the decisions are being made.

BrainStorm BPM Day 1: BPMS vendor panel

Bruce and I changed between the same two sessions, although he was leading both sessions and I was sitting back blogging. This one is a panel of four BPMS vendors, Global 360, IBM, Savvion and BEA, to discuss What’s Next for BPM Suites. I arrived a few minutes late and didn’t catch all the names, although I recognized Pat Morrissey of Savvion. This was my first tough decision of the day, since I also wanted to attend the Business Process versus Business Rules panel, especially considering that the panel that I’m in could turn out to be just regurgitation of the vendors’ marketing materials. There’s always the chance, however, that one of them will blurt out something unexpected.

The word “mashups” just came out of the IBM person’s mouth, in response to a question about collaboration; this has nothing to do with their BPM offering of course, which doesn’t really have any collaborative aspects (if you discount the FileNet Team Collaboration Manager product, which she likely hasn’t even heard of) but they are offering a mashup tool so I suppose that triggered when she heard “collaboration”. She’s not the only vendor to drag the conversation off topic and down the rathole of their own product’s functionality, but she’s definitely the most effective at it.

There was a bit of a discussion about Web 2.0 at the end of the session, with the BEA person making a key point that one of the big issues is that Web 2.0 consumer applications are changing user expectations, which in turn drives the inclusion of social networking features into BPMS’ — a point that I’ve made here before and will be discussing at the Shared Insights conference next month.

Bruce finished up by asking each vendor to summarize what they thought was the next thing in BPMS:

  • Global 360: “process intelligence”, which appears to be their latest marketing buzzphrase
  • IBM: “frameworks for implementing BPMS”, since they like to sell frameworks plus lots and lots of professional services to make them work
  • Savvion: “process management that actually works” (on a global scale, as opposed to always being the next big idea or in a pilot stage)
  • BEA: “convergence of BPM and SOA” and “better collaboration”

All-in-all, I didn’t learn much in this session about what’s next for BPM suites, and it was much too polite: the vendors only very gently disputed each other’s opinions, and in fact rarely even directly addressed each other. It did give me a chance to get my queued blog posts published, and now I’m all caught up and ready for lunch.