Archive for July, 2008

BP3 at OMG ThinkTank 2008: Chicago & Amsterdam

Thursday, July 31st, 2008

Lance and I are going to be at OMG ThinkTank in October (October 6-7, 2008), and then again at OMG Think Tank in Europe (November 11-12, 2008).  Lance is hosting a Round Table on Managing Complexity, and I’ll be hosting a Round Table on how process execution is being impacted by ERP/SOA/Web2.0. This year Think Tank is going to have much more of a business focus around BPM, which is welcomed news! Not that the technical side hasn’t been very well represented — and with great content.  Nearly all of the BPM events hosted each year have technology as the center of gravity. Looking forward to seeing how this goes over. The round table sessions are without a doubt the best part of Think Tank. A round table is where you usually have about 6-10 true industry experts and/or very active BPM practioners from mainstream companies sit around a table and provide their experiences based on the topic of the RT.

Last year at the conclusion of the event, everyone agreed Think Tank should expand this vehicle as it was chock full of some great insights and collaboration. Most of the time the topic left the table and was picked up at breaks and after session get-togethers to continue the discussion. The purpose of the leader of the RT is to bring some very good knowledge and experience on the topic, but to primarily facilitate discussion; it is not a platform to monologue the content.

If you have the chance I would highly recommend considering going to Think Tank this year in either Chicago or Amsterdam. You can check out the previous year’s event here.

Lombardi’s Blueprint Summer Release

Wednesday, July 23rd, 2008

Overview and What’s New

We had a chance to see Lombardi’s latest Blueprint release at Driven last week.  We’ve used Blueprint before in earlier versions, but after revisiting it this time around, there are definite, significant improvements.  I thought we’d share our early experiences with Blueprint here, and specifically our reaction to some of the new features added.  What’s new? Visio import and a good export/import into Teamworks are big pluses. Word export is another new feature, and of course PowerPoint generation has been there from virtually Day 1.  Archiving and a revamped project screen were also introduced.

The New Stuff

Visio importing has long been the “holy grail” for process modeling tools.  If I had a dollar for every time someone asked me if a particular BPM product could import Visio models directly I would be rich!  However, Visio import into a process execution environment isn’t always all its cracked up to be.  Visio diagrams tend to be quite unstructured, whereas BPMN is very structured, and executable BPMN is even more structured in form.  Moreover, Visio models don’t have enough information attached to them to be immediately executable.  It is possible to run into issues of “who owns this model” once you import the Visio (the business may have the expectation that they can keep making modifications and “reimport” into Teamworks, for example).  At some point, the implementors must take over the model and own it to produce something executable.  I’ve been working on some models for OMG certification and I thought they would be a fun (albeit simple) set of examples to import into Blueprint for a test drive.  Blueprint imports these easily and accurately.  I went back to the archives and tried importing some really awful process diagrams circa 2004.  The results weren’t pretty (the original wasn’t pretty), but Blueprint imported the models nicely (a visio diagram with 10 tabs and one process per tab).  Going to the Diagram View I was able to sort out the diagram into swimlanes and go from there.  Interestingly, when I imported a diagram WITH swimlanes defined, Blueprint created those swimlanes and participants for me.

Word export works great, but didn’t work so well on my Mac.  On Windows it produces a professional document that is a good appendix or a good starting point for the doc.  It also eliminates the need to maintain two separate documentation formats – you can use Blueprint as your source and export when you need a Word doc snapshot.  Moreover, you can “snapshot” the process in Blueprint as well, so that if you need to reproduce the Word export later, you can…

The diagramming is much improved, from process mapping to actual BPMN
diagramming.  The new clickable controls are more intuitive (though I had to unlearn some previous notions because I’ve been using Blueprint since the early Betas).  As before, quick double-click on any item takes you to a pretty robust editing interface for adding participants, owners, experts, inputs, outputs, problems, documentation…  Its the Process Diagram (BPMN) view that has really changed over time.  Clicking on any line allows adding a new activity, gateway, subprocess or event.  Blueprint successfully removes the need to obsess over placement of each item in the diagram. It tends to organize things in neat right-angles, taking care of horizontal and vertical placement within a lane (you pick the lane though). 

Project Details Page – This page is so different as to feel like a new page.  You can export powerpoint, word, excel process data, and BPDM all from a simple project page.  From this page you can also move a process to a different project, archive it, or copy it.  The value of these things is more obvious after you import ten processes from Visio!

The Tried and True

The PowerPoint generation is a nice whiz bang feature (only available in the paid-for version).  It lays out the first section nicely: goals, followed by process mapping, followed by opportunities. I’d like to see it turn out a process-diagram view as well, but that may be a little tricky to squeeze into a small space.  The appendix is aptly named for its content, which is a blow-by-blow layout of participants, inputs, outputs, and problems with each step of the process.  I found the color scheme in this section a little jarring compared to the relatively slick look of the rest of the powerpoint.  All-in-all, its a great timesaver.  It ran so fast for me that I thought it hadn’t actually done anything the first time I ran it, ad I can pull together a reasonably professional presentation out of it using the generated slides as a starting point, and putting my own slides referencing ROI or Business Case up front, along with some concluding slides about the opportunities presented and how to tackle them.

BPMN Diagramming.  I actually like the diagramming portion better than
Teamworks!  And collaborating on the same process isn’t just possible,
its actually cool.  You almost look for an excuse to try to be logged
into the same process at the same time so you can try to step on each
other.  Blueprint handles all the conflicting edits really well.  I’m
impressed!  And I understand a good deal of the diagramming techniques
in Blueprint may be adapted for Teamworks in Teamworks 7, which is an
exciting development for Business Process implementors. 

The handling of Revision History is a clear advantage over Visio or any other tool I’ve worked with.  As far as I can tell, every change I make is tracked as a revision, such that I can recover lost work if I accidentally delete something important by restoring from those automated snapshots.  But I can also create my own Snapshot and name it, a point in time to be easily remembered going forward.  This takes the risk out of collaborative authoring, and out of revisions in general, because you don’t have to be worried about version history.  Cycling between versions is simple and fast, so finding the right one isn’t too stressful.

Room for Improvement?

The product has a clean interface and a good look overall.  But there are a few parts I’m not too excited about (yet) that mostly have to do with teeing up projects.  First, when prioritizing problems, you can select severity (low medium high) and frequency (low medium high) but you don’t have the ability to track how observable the problem is.  A problem that is very difficult to detect is much more serious than a problem that is easy to detect, and implies a different type of solution approach.  It might seem too complicated for some, but no reason you can’t ignore the third column by leaving it always at “low” if the notion of detection/observing is too complicated.

Second, the overall analysis screen leaves something to be desired.  It wasn’t immediately obvious to me that the impact scores I was looking at were the impacts of solving one problem across the set of higher level business goals I had established.  Once that was clear, I found myself wondering how these impact scores were derived.  To the layman it doesn’t appear that there is any structural relationship between a timing problem and my goals, but if I give them both high weight then the impact score will be higher against that goal…. So it isn’t immediately clear to me if the idea is to look at this page and then revisit your scores, or if it is really supposed to guide me in determining which parts of the process to look at.  But as long as the correlation is a black box, I don’t trust it.

Third, a process as we know has multiple dimensions to it; it’s not just the activities and relationships. Blueprint would benefit from adding Lean Flow data elements like WIP, Cycle Time, Throughput Time, Takt Time, Lead Time, and Number of Operators to each activity and to the process as a whole and have these values actually calculated, not just string values (perhaps an advanced user view or analysis view). Blueprint would then be much more effective in prioritizing and triaging process improvement, i.e. It would close the loop on the qualitative aspects (Severity, Frequency, and the missing Detection) and now provide quantitative elements as well such as time and volume. Again, this would really address the need to represent the many dimensions of business processes.

But for the primary purpose of capturing process maps and diagrams and capturing living documentation about those processes, Blueprint looks like a great tool.  Its come a long way in one year, and I look forward to seeing what else is coming down the pipeline. The progress so far is encouraging for what is to come.

BP3 at Gartner’s Business Process Management Summit 2008

Friday, July 18th, 2008

I will be working with a partner colleague to lead a workshop, as part of Gartner’s Workshop Series, this year in Washington DC. I didn’t get a chance to make last year’s session but heard anecdotally it was well represented. This year Dr. John Alden from Capability Measurement and I will be delivering a workshop on BPM Measurement: Principles and Practices. This workshop is all about starting or improving measurement in companies BPM initiatives. Something I can tell you is woefully lacking and as a result companies may not be getting all of the “bang for the buck” they really should on these projects and programs. The synopsis is as follows:

Participants will learn how to start or to improve existing measurement activities in a BPM initiative. The workshop will be divided into two parts:
1) a “measurement principles” presentation
2) a facilitated “practice oriented case study” discussion
In the first section, the content will cover:
- Current landscape for BPM measurement – trends and issues
- Measurement and its link to strategy
- Practical frameworks for guiding measurement programs and their lifecycle(s)
- How the maturity of business processes affects BPM measurement capability and analytics
- Where to start if you are new? How to improve if you are already involved?

In the second section, the participants will engage in group discussion designed to provide for tangible outcomes, e.g. something useful to take back home. Participants will evaluate their own preparedness for BPM measurement and develop a measurement roadmap tailored to the maturity of their business processes.

You can learn more about the Summit and Register here at Gartner BPM Summit

Hope to see you there!

Why use BPM over other workflow tools?

Thursday, July 10th, 2008

An interesting question was raised at the recent Lombardi Driven 2008 Conference.

The question was (and I paraphrase):

I am new to Teamworks, but I have a number of content management, asset management, approval and other systems that all have workflow features. How do I know which workflow tool to use and where does BPM fit in the whole picture?

I got to thinking about this question, and the simple fact is.
Pretty much any enterprise class application suite that manages any business assets, will include some form of task routing or workflow feature. They must have in order to define and enforce the business rules for the assets in question.

So, it’s pretty easy to understand how someone new to BPM has a hard time determining what is special about BPMN diagrams and BPM in general. Especially if you are being introduced to BPM from the perspective of the vendor tool.

So, what is the answer?

In my opinion, the appropriate tool really depends on the domain of influence for the application.

Let’s take a portion of a simple on-boarding (everyone loves on-boarding) process.

In the above process there are at least three systems that would likely have a workflow engine as part of their feature set:

  • Document Management System.
  • Identity Management System.
  • Badge/Access Control System.

Likely, it would be possible to build out approval, escalation and task assignment for the entire process in any one of the above tools. It may not be pretty, or efficient, but quite possible.

So, let’s ask the question again.
What is the appropriate tool, and where does BPM fit?

I think it is obvious the management of offer/acceptance letter and employment contract should be handled using the workflow of the document management tool. This is what it is designed to do, the tool has direct access to the document repository and the rules governing the handling of the documents are likely to already exist within the system.
Accordingly, badge access and system accounts (email, login, salesforce.com etc) should be created in the badge access and identity management systems for the same reasons.

But the marshaling of these process steps, this is the role of a BPM engine.

In the process above, we don’t want to start the badge or user account process until the acceptance letter is received. Equally, we want to be able to place CSF and KPI measurements against each of these process steps.

  • All activities are necessary to successfully complete the on-board process.
  • All activities could likely be optimized
  • All are in the critical path.

This is the purpose of BPM, to provide end to end visibility, integration and control of a complete process, not just the pieces that make up a process.

Like I said, this is my own opinion, but I was happy to hear that this was the consensus from the other experts in the room at Driven as well.

Standardizing core processes…shouldn’t this be easy!?!

Friday, July 4th, 2008

If your company has already ventured down this road you probably realize that standardizing processes, especially core business processes is in fact NOT easy. There are many reasons why this is a heck of a lot harder than one may think. Let’s start with the big question first – What do we mean by standardization and what is the real business objective in doing it (i.e. who is asking for it)? I have seen quite a few flavors of this over my career; most recently I spent the better part of a year working with a very large insurance company who wants to standardize their claims process across all of their products and regional markets.

When I asked “why standardize?” I received different answers from lots of different people. “We want to make the claims process cheaper and more efficient,” while another person said “We want to be able to centralize the processing of claims,” and yet another “We want the customer to have the same experience in their claims handling regardless of where they are or who they talk to.”  Are they all saying the same thing in different ways? Are these really the same objective? Perhaps, but I and a few others were not convinced. The implication of this question is huge as this will without a doubt dictate what approach will be needed to achieve the goal. Yes, it’s those details again that quite often nobody really wants to face but without them then the whole exercise is just academic and everyone can just standby for a journey that could take a decade to realize, all the while managing ongoing change as the business climate shifts (i.e. competition, regulations, new markets, etc.).
So what does “standardizing” really mean? If we look at the definition of standard and exclude “a grade of beef below good” as one of them, then we see “a basis for comparison; a reference point against which other things can be evaluated”. So said in more of the context of a business process, it is to achieve a baseline measurement and reference model for process performance. So this has less to do with centralizing a process and much more to do with achieving a consistent performance profile to meet customer and/or business requirements.

So then another big question hits home. Do we really need everyone to perform the tasks in the exact same way? Or can it be that we don’t really care how they do things at a procedural level as long as they consistently meet the needed SLA’s, thus making the measurement the real standard? Maybe think of the latter like a technical standard such as J2EE, as long as a software vendor can deliver the functions required that make it J2EE compliant, it doesn’t matter how they actually implemented it. And as we all know there are very big differences between J2EE products. That becomes yet another big question. At what level of a process, if you think in terms of value-streams, should be considered the standard and what can be tailored in any fashion just as long as it can deliver to the specified requirements?As you can see, this whole notion of process standardization creates some very big questions that any company pursuing this strategy will have to answer, and it is not easy. From experience I can tell you that achieving the benefit of standardization does NOT unequivocally equal everyone at all levels of a process doing things the same way.

In fact, that is usually why this work can get very, very hard. Rationalizing activities from an end-to-end standpoint without knowing quantifiably what the performance standard needs to be is a recipe for some major headaches. So maybe another way of approaching standardization is by backing in to it, such as we need to process x-type claims in 72 hours in all markets we serve. Focusing on it from a measurement standpoint is the best way to understand at what levels of a process and more importantly what are the few key activities at those levels which really need to be rationalized. Versus what I have seen so many times, a blanket objective of everyone who is involved in the process must do things the same way. If you are reading this post, then you have probably been in those meetings where you need everyone to agree on “how the process should work”, now multiply that effect by 100 when you begin talking standardizing across products and geographies.
Ironically, everyone agreeing and doing the same work doesn’t guarantee that the measured result will meet the standard, but that is often the implicit assumption in such endeavors…

Happy 4th of July everyone, and think about our armed forces today. Our deepest thanks go out to all of you.

Building the distributed team

Friday, July 4th, 2008

We just had our first internal videoconference between HQ and our Atlanta office.  Well, that’s how we like to refer to Flournoy when we’re not calling him BP3-East.  We made the decision to invest in Videoconferencing equipment because it is really important to have high fidelity communications both internally and with our customers.

When I was at Lombardi we built a distributed geographic technical team based on the belief that high-value, high-touch interactions with customers were crucial to building lasting customer relationships.  That’s a really hard thing to do right when you are starting from a base of 2 or 3 staff members, and don’t have the national network of people to draw on.

At BP3 we’re going to attack this in two ways.  First, we’ll hire geographically again, I have no doubt.  We have a better national network to tap into this time around, and some of our colleagues from Austin have moved to other cities, and might be able to help us find the right people.  Second, we’re going to invest in videoconferencing equipment.  We think it will enhance the quality of our offsite work with customers, and likely it will somewhat reduce the need for travel expenses.  It also sends a powerful message to our team that we’re interested in their quality of life and their ability to do good work remotely.

Videoconferencing still isn’t cheap (can’t wait til its under $1000/seat), but I was pleasantly surprised at how affordable it is compared to what it cost 10 years ago, for a better product.  And with the cost of travel increasing, videoconferencing looks more and more affordable by comparison.  Oh, sure, you can go the <insert favorite IM chat client> route, but the fidelity of such video connections is generally terrible, and certainly not good enough to show someone at a remote location what you’re drawing on your whiteboard.  We went with a Lifesize system.  Its high-def, the quality is fantastic (720p), and with remote control, the person on the other end can zoom into our whiteboard to see what you’re drawing.  Voice is included in the video/audio stream, so there’s no need to place a separate voice call.  And there’s no per-call charges because it all goes over IP (over your network).

We’ve been pleasantly surprised at how many of our customers have videoconferencing setups as well.  Often these are underutilized assets, but there’s no reason for that to be the case on our projects!

I want to thank good friend Megan Lueders for giving us a demo of the system and getting us to take this seriously.