Breakthrough Process Design

August 3, 2009

We find ourselves presented with situations where our clients are looking for “Breakthrough Performance” rather than mere “Process Improvement”. In her guest post on Jim Sinur’s blog, Elise Olding points out that many rush headlong into implementation looking for an elusive Magic Bullet (there aren’t any, but you could describe BPM initiatives as a Golden Gun). She quickly alluded to the need for a number of techniques including “Process Walkthroughs” (following the work item), through Sticky Notes or PostIt Sessions, down to and including sitting with the users and observing what they do.

While all these techniques are useful and interesting, they don’t go far enough to deliver the breakthrough improvements that customers seek. In business today, generally what is needed is not “Better Sameness” but “Transformation”. But existing processes usually focus on the needs of the company – delivering stronger management control, and reinforcing functional priorities.  

However, we believe that the best practice to deliver breakthroughs is quite different from any of these approaches. We start from a different place – the “Customer Experience” – a stance that is all about building competitive advantage. 

Process breakthroughs come from thinking about everything we do in terms of how what we do can assist in delivering a Great Customer Experience. This dynamic lens is dramatically different from the traditional process improvement approach. It has the effect of inspiring completely different insights and generating new ways of doing things (rather than paving the cow paths). Once you are standing in the shoes of the customer, you no longer see the functional bias that reinforces existing behaviors.

In the early 90s the CEO of Sony pointed out that, every manufacturer had all the parts needed for a Sony Walkman sitting on their shelves – but only Sony asked the customer what they wanted. As a result, they transformed the way we listen to music (even if they did miss the disruptive innovation of hard disk based players).

In the end, we believe that you have to build a “Transformational Vision” around what the customer values – be it an internal customer, supplier customer, partner customer or end consumer. So we will continue to use the “Customer Experience” lens as the best route to achieving breakthroughs in process performance.

Advertisements

Customer Experience and the Business Process

July 1, 2009

As you are probably aware, there is a real challenge for organizations in delivering an effective customer experience. The problem is that the Customer’s “Experience” is often an afterthought in most business processes. The emphasis is usually on the internal problem being solved, not the impact that this process has on the customer. Now some of you are probably saying that all our processes are customer focused. But the reality is that very often that internal efficiency and profit (upsell/cross-sell) are the primary drivers of customer facing processes.

As I type this post, I am experiencing just such a broken process – it’s the oxymoron known as Adobe “Customer Service”. So far I have been on the phone for 50 minutes as I discover that their Adobe ConnectPro product, while delivered as a “Service” in the cloud, does not have the other elements that live up to anyone else’s idea of what the word “service” means (either with or without the capital S).

In this little scenario, I am trying to get the ConnectPro account to accept the new Audio Bridge so that we can get seamless audio conferencing into the BPM TechShow. So far I have spoken to three people (inside Adobe) – Tech Support immediately got rid of me saying that I had to talk to Customer Service. After 30 minutes listening to reasonable Jazz at the poorest sound quality available, I talk to someone who then says I need to talk to a special agent … then I get the Supervisor of Customer Service that tells me … you guessed it, I need to talk to Tech Support. Strangely enough, I start to bleat about it, and the very nice sounding young man says he will connect me with the Tech Support Supervisor (immediately) … and now, after another 30 minutes, I am still listening to bad Jazz.

Why am I hanging on, just to see how long they take, and whether or not I can get resolution to this issue before my next call (I have missed the orginal meeting this was needed to support … so their bad/broken process has already impacted one of my own customer relationships).

I will also take the opportunity to feed back this “experience” to the relevant Product Manager at Adobe.

Of course, I shouldn’t have to be here anyway – the process that provisioned my account in the first place should have made sure the option was set up appropriately. That means that the partner (yes, you can not buy this stuff directly from Adobe) should have been trained to pick it up, or at least have an option to line up the provisioning automatically. Indeed, even trying to buy the product (i.e. give Adobe several thousand dollars) was a similar exercise in managing the frustration of being passed from pillar to post as nobody takes ownership.

The point is that the processes that handle the transactional side of the relationship are one thing (taking your money is normally pretty efficient these days … Adobe excepted), but all the related processes that go into delivering that customer experience are just as important. And I am not even an exception – in talking to the people who provisioned the audio bridge, it turns out that several others have had the same problem (i.e. it wasn’t set up right to start with).

Now after 71 minutes on this call alone (it’s my second), I am about to kill the call and try again – clearly the supervisor seems to be out to lunch (or else I was just routed back to that endless queue that will ensure this customer will sooner or later go away). But this time I will try a different route. Right now, I am so angry that if I had the option (time available), I would probably ditch Adobe in favor of a competitive product.

Having a free 1-800 number is no substitute for actually having an effective mechanism to deal with customers and their issues (i.e. work on the behaviors and culture of the people that customers interact with).

A good customer experience builds relationships, acts as a referral point for new customers, lowers sales costs, etc. And this post is proof that a bad customer experience is destructive to your brand. Bad experiences get talked about and passed on.

Within your BPM Program, you should start off with engaging the Executive Steering Group around the “Brand Customer Experience” – a broad statement that sets the tone for all customer interactions. From that point, it becomes one of setting up an engagement program with the business designed to first of all define the sorts of “Services” that customers can expect, and then from there, the need for processes that deliver that experience. Those processes are operated by people, who should be empowered (trained) to give that designed “Great Customer Experience” every time.

I will be discussing this overall method and technique in the Day 3 keynote (July 9th) of the BPM TechShow … but I doubt that anyone from Adobe “Customer Service” will be there.

Update: I called back tried a different route into a more general Tech Support group, and then finally was given yet another number to call (this one allegedly to talk to the relevant group for Adobe ConnectPro). After 17 more minutes of listening to bad Jazz sounds, I am now talking to someone. But it seems that the person on the other end is incapable of finding the answer. I get asked questions like “when did I purchase this?” … Irrelevant. Then I am asked for the Tech Support tracking number … strangely enough I dont have one. Then they want my street address in order to “validate” I am who I am … finally, after a further 20 minutes I get a tracking number. But can I look up on the Web to track that number … Noooo, I have to go through another exercise in ritual abuse (i.e. talk to Adobe Tech Support or what passes for Customer Service).

Update 2 – 6 days later. Since this post got noticed by Adobe I have had several conversations with interested parties. Of course, we offered to help them improve the customer experience … but it seems to be an issue they are taking very seriously. We’ll see where it all leads.


Virtual BPM TechShow Next Week

July 1, 2009

Following the success of our BPM Technology Showcase format in the real world (Feb and Oct 2008), and given the fact that nobody is allowed travel budget these days, make sure you check out the Virtual BPM Technology Showcase next week – Tuesday 7/7 through Thursday 7/9.

Over a three day period, we will be introducing 7 of the leading vendors in the BPM arena:

  • Appian (7/7)
  • Ascentn 7/8)
  • Fujitsu (7/7)
  • Global360 (7/9)
  • Itensil (7/7)
  • Savvion (7/8)
  • SRA (7/9)

Each vendor will talk to the value that their technology delivers and how customers have deployed their solutions. This is not some vague conference where nobody is allowed to talk about their true innovations and features. Neither is it a noisy showroom floor where folks are wandering around wondering when they can get a real demo of this hot new product. We have set out to structure the interaction between seller and potential customer. Each 45 minute session is followed by a detailed Q&A allowing you to get up close and personal.

Having said that, it is supported by 3 different keynote sessions where I will cover:

  • The BPM Techynology Assessment Framework (7/7)
  • Ensuring BPM PRoject Success (7/8)
  • The Customer Experience and BPM (7/9)

To find out more or register for the event go to the BPM TechShow site. And if you need a further incentive to take part, either Nathaniel Palmer or myself will be available for individual one-on-one sessions to help you fast track your BPM program.


Cases Managed The World Over

June 21, 2009

A recent spate of interest in Case Management is good to see (I always called it Case Handling but the concepts are the same). The OMG is about to vote on an RFP (Request for Proposal for a new standard) on Case Management. As some of my regular readers will realize, I have a special interest in the subject of Case Management.

Some of us have been talking about the problems of dealing with Cases for a number of years (e.g. this post in 2007). My own experience started with the development of what would today be called Case Management systems starting in the mid-80s and culminating in an Oracle-based object oriented repository in the early 90s – way too clever by half for that era so I canned it in 1992 and became an Analyst looking at other peoples products, writing white papers, etc. Since then I put together a number of white papers specifically talking about the issues of Case Management:

  • In 1996 a paper called “The Business Case for Case Handling” and although the vendors I referenced at the time have since disappeared (bought out), the issues are just as relevant today.
  • Over the last few years, I published a couple of papers that start to explore some of the related issues (these papers are available on BPM Focus with registration). In particular, these two papers address many of core concepts of Case Management.
    • “Process Innovation and Corporate Agility – Balancing Efficiency and Adaptability in a Knowledge-Centric World”
    • “Business Processes and Customers – Difficult Domains to Integrate”

So with this post, I am having my own stab at defining the issue. I have been invited several times by those in the OMG to take part in this particular enquiry, but hesitate to get involved as these things can act as an enormous time sink. So first let me point you at some other perspectives. In recent months, we have seen several bloggers discussing some of these ideas (touching on the need for adaptability and agility):

  • Jim Sinur of Gartner talks of “… Agile processes that are tapped into emerging events and contexts driven by organizational and community goals … the need for creating and managing unstructured processes. This kind of environment requires organizations and vendors to master goal driven processes.” In another post he said “Today most processes are Flow directed, but the future will likely require goal direction for at least a portion of the process. This is what we call unstructured processes that are composed of process snippets that are flow directed and portions that are completely dynamic. A combo looks to be the way forward.” See here, here and here.
  • Neeli Basanth Kumar (of Cordys) talks of Process Patterns in Adopting Case Based Solutions (he even uses one of my diagrams from a 97 paper – The Workware Evaluation Framework … where I tried to highlight the role of Case Management).
  • A discussion paper put out by Dennis Byron at ebizQ provides a sort of summary of some of the thinking of the vendors that replied to his request for information (originally it contained references to my thoughts and some of my graphics but that content was pulled after I pointed out the provenance). 
  • Bruce Silver commented on the RFP discussion going on at the OMG and postulated what he sees as the difference between “traditional BPM” and “Case Management”.

For me, it all comes back to the continuum of Process. On the one hand, we have the image of the organization as machine, with mechanistic “Procedures” used to control the work of the resources available. Most BPM initiatives are still stuck at this level, seeking to automate things and remove (human) resources from the equation. If Productivity = Value / Resources, this reductionist approach is all about reducing the resources involved in the deliver of a given value.

At the other end of the spectrum, we could consider processes as more like evolving “Practices.”  Think of what you do personally and see if this concept makes sense – some parts of what you do are defined in Standard Operating Procedures, other parts you interpret and apply your judgment. The more leeway you have to make decisions (in your job), the more knowledge you exercise in carrying out your job. Most knowledge workers are goal oriented, regarding procedures as a means to an end, rather than an end in themselves. Managers tend to be goal oriented.

We could think of high level processes as being about a “Purpose” – and how that Purpose is interpreted will inevitably be somewhere on that spectrum Procedure and Practice. Indeed, one finds that most business problems need a combination of both – hence the approach that has become know as Case Management. Now we’ve got this concept established, from a process perspective you could think of Case Management as applying to the Practices end of the spectrum. Workers here are goal oriented, and typically apply processes to achieve those goals.

Case Management is a very important “Design Pattern” for supporting flexible work Practices instead of more rigorous Procedures (where no adaptability or run time flexibility is needed). Different products take vastly different approaches to Case Management, all with the aim of providing flexibility and adaptability to the user, yet still providing support for the organizational objectives (processing more work, more efficiently and providing traceability).

Case Management proffers a way of mixing overarching support for that Purpose – normally through a high-level, outline procedure, which is then supported by a library of process fragments that can be bound into the parent as determined by the user. In some cases, the user has complete control of what should happen next; in others, the ability to progress from one phase of that high-level outline to the next is constrained in some way. Some products leave it very loosey goosey, others are all about constraining the user. Depending on how strong the need for adaptability is (in the target domain) the user may even have the ability to develop new process fragments to support a given need (imagine a Software Engineering project … it’s not always possible to predict every possible permutation). In others (say a Bank for example), it might be good enough to have the user select from a library of available sub-processes to bind to the parent. Indeed, in a Bank or Insurance company, it is unlikely that the run time adaptability would be allowed (the last thing you need is a clerk getting creative with a bank draft).

With careful architectural design, it is possible to create a Case Management environment out of many different BPMS products. But that implies that the end-user organization already have a clear idea of how such environments are constructed. In a sense, they create an application layer above the BPM Suite. 

My concern with the OMG RFP is that it is trying to standardize something that is poorly understood (as evidenced by the varying perspectives given in the OMG BMI mailing list). 

While the rest of this document goes on to outline my own views on Case Management, I believe that developing a standard in this area at this point would only result in hampering innovation. Having said that – there is a definite need for much more discussion and exploration of the domain of Case Management.

I believe that the approach proffered by Cordys represents just one way of approaching Case Management. There are others, and I do not believe that tying everyone down to one interpretation of Case Management at this point will be a good thing in the industry. Other vendors with Case Management approaches include:

  • Singularity
  • Cordys
  • Global 360
  • Sword (was Graham Technology)
  • Itensil
  • TIBCO
  • EMC Documentum
  • IBM (FileNet)
  • BizAgi
  • Pallas Athena
  • Pega
  • Polymita
  • HandySoft

All these vendors have some sort of capability that could be described as Case Management (and I am sure there are plenty of others that would put themselves on the list).

Finally those in the Process technology world are starting to see that a pure “one sized fits all approach” to the standardization of process definitions is entirely inappropriate when it comes to the needs of humans and knowledge workers. Moreover, Case Management approaches provide all sorts of benefits to companies in that they enable a far more flexible response to the needs of customers.

As different vendors struggle to work out the best approach, the last thing they need is to be tied down to a “standard” approach. In the end, it will be the Darwinian process of selection that will see the best products win out; not some imagined need for standardization and interoperation between wholly different approaches to the problem. 

Notes

Most BPM efforts could be characterized by their incessant focus on process standardization. They are predicated on the assumption that overall business effectiveness improves through better control. And while this is true for procedural, back-office problems, the reality is that customer facing and knowledge work processes are extremely difficult to standardize (if not impossible).

This is a real problem for long term BPM adoption. Ask yourself how many organizations you know in the BPM arena that have more than 5 or 10 processes “under management” (i.e. using a BPM Suite to ensure that things don’t fall through the cracks). And then think about how many spreadsheet are used in those same organizations to coordinate work.

In the paper “Customers and Business Processes – Difficult Domains to Integrate” I suggested that there were several different types of Case Management (Case Handling). These range from the traditional BPM Suite (which struggles to support the necessary adaptability), through what I called “Design Time Case Handling” on to “Run Time Case Handling”.

Case Management and BPM

Case Management and BPM

The vast majority of BPM Suites and Workflow tools assume that all activities/tasks/steps (and the potential paths through them), are modeled a priori (beforehand). Putting that another way, they focus on driving work between employees based on a model that maintains the status of a work item. The process model must exist up front, which presents the first hurdle of process discovery—i.e. ensuring those models are “correct.”

Further, in most products, all work of a given type share a common process description (rather than copying the model to support each work item). In such situations, the engine will normally allow the end-user little or no choice but to follow the pre-defined procedure.

Of course, the challenge is then for process modelers to predict all possible permutations in advance—something that is virtually impossible to achieve in customer facing situations. To get around show stopping scenarios, a few products incorporate features that provide the ability to bypass, redo, and rollback steps, while most rely on re-assignment of work to the supervisor (who must then step outside the system to resolve the problem). It does not take long before the supervisor becomes the bottleneck as cases mount up (those that do not follow the “happy path”).

Change is only possible through re-development of the common process model. New items of work then follow the modified process description (most products incorporate some form of version control). Change to an individual work item normally requires the deletion of all threads of work and the work item is then recreated under the new model (compromising any future audit). Alternatively, mechanisms must are needed to move an existing case to the new model.

These adaptability issues are not constrained to customer facing scenarios. For example, as government regulations change, the firm needs to revamp its process models to handle that change. There might be thousands of cases in the system, the vast majority of which will complete before the new regulations come into force. But imagine that there are still 100 cases outstanding at the point the new regulation comes into effect. For most products, it would simply be impossible for them to handle this problem in any sort of constructive fashion. Each of those work items would have to be manually stopped, and then restarted (somehow) under the new process definition that met the new government regulations. The only viable way of approaching the problem is to incorporate mechanisms to migrate individual instances to the new model.

For Case Handling support, the key differentiating factor (of the BPM Suite) is the ability to link multiple processes to a given case of work—the primacy is with the case of work, rather than the processes that are used to support it. Each case is usually “managed” by a relatively loose (high-level) parent procedure, but the worker can then add new procedural fragments to handle each different requirement of the work in hand. Effectively, the user is binding new procedural fragments to the case at run time; either by selecting them from a library, or by developing new ones.

Of course, this sort of approach is reliant on a BPMS that can facilitate such modifications to work in flight. For most products, it will also require great care in the design of the process architecture itself, and may involve the development of an external application.

(Some of these thoughts have been culled from my past White Papers on the subject of Case Handling)


Appian Anywhere SaaS Case Study

April 19, 2009

As many of you know, I have been pressing the metal to the floor on BPM in the cloud. So, I was interested to see the Appian Webinar last week (available on demand here). Some of you will remember that I developed a good chunk of process training for them to support users on the Appian Anywhere platform.

The session opened with the usual intro (not from me for once), pointing to all the usual reasons for doing BPM – efficiency, retain customers, compliance, etc. However, I was impatient to get to the SaaS opportunity, as I believe BPM delivered in the cloud enables a whole range of new possibilities.

Following the vendor neutral intro from Information Week, Samir Gulati Appian’s VP of Marketing, talked about their offering. Appian Anywhere has the same code based as the Appian Enterprise product, but deployed in the cloud and available on demand. AA has been out there for nearly 18 months or so (although I think it was only officially released earlier this year). It’s available in the Premium Edition where you get your dedicated server, SAS-70 type 2 application, etc., and the Standard Edition where you get shared (multi-tenant) access to an Amazon EC2-based service. From a pricing point of view, the Standard Edition is $35 per user per month. And while you are in evaluation mode, Appian provide a “Process Coach” to help get you up and running.

Samir talked about a few example customers of Appian Anywhere: ManuLife, who are using it to support their marketing function, driving better resource usage, managing interfaces to their third party suppliers, etc. The second example was Starbucks who are using AA to manage and track localised promotions, enabling visibility into what is going on.

The main part of the webinar was a case study delivered by John Cowles, Director of Operational Efficiency at Clayton Holdings. They are primarily involved in Credit Risk and Due Diligence work for the Mortgage industry (they don’t own assets, just provide services to others). Their customers are the Banks and Mortgage issuers. They could see the financial industry going in a downward spiral, and felt that things would get tighter. They realized that they needed to get better control of their own processes, and start monitoring/managing process performance. They also felt it was taking too long to get people up and running effectively.

Being a smaller company, they were a little nervous about getting into the BPM space, so thought they would try out the SaaS option. For them, it was a low risk; a low cost way to get started (John’s estimate was that it was only about 10-20% of the cost associated with buying a BPMS and installing in-house). And with limited IT availability, they felt the SaaS option represented the best way forward. They started zeroing in on Appian because they had the SaaS capability (at the time they were the only one out there with an On Demand offering). He liked their tenacity and the flexibility of the tool.

Once their instance was set up, it took just 6 weeks to get their first process up and running. He started developing a baseline of their current operation (always a sensible move). In his words, “you can’t improve anything unless you know where you are started. You could be wasting your time focusing on the wrong things.” Overall, he was looking for a 30% improvement in efficiency, while also seeking to reduce the variability in the way work was carried out. They followed a DMAIC approach, but it was a BPM project (not 6Σ). They were lucky in that they had the active involvement of a lot of senior business people (Executive Steering Group). Yet, their development and implementation team was small (2 people).

They have been doing a new release every month once they got their initial processes up and going. And ever since that first release, the business people themselves have developed more and more ideas on what they want to do. Initially, they actively avoided doing any integration at all. So it has only been very recently that they needed to involve IT.

I am not sure, but I think they are now addressing two areas of the business. John talked of having over 30 processes, with a lot of interdependencies between those processes; so I am guessing he was referring to the various sub-processes and chained processes that support the domain. 

From a results point of view – they are now doing more with less. He cited a new operation in a remote city where they had thought they would need 14 people to do a particular role, now they get by with just three.

For a case study, I thought it was a good one. It was good to hear someone really getting into the lessons learnt.

  • John quite rightly pointed to the need to “Focus on Change Management and Process Management early on … We had to prioritize, needed to step back and look at the bigger picture.” I found myself thinking that we could have had some interesting discussion over the Process Portfolio Management techniques that we have been working on with a Center for BPM Partner.
  • His second point was I think a good one “Limited or no system integration in the first release” … indeed, they left the integration till nearly 6 months before they got into that.
  • “Prototype everything” … sit down, work with them in design mode, and see what that looks like, prototyping all the time.

There were others, but those were the things that stood out for me. John also talked to the need for Process Visibility … “Need to step back and look at the metrics at a high level and then focus down on the critical areas … treat it like a compass.” I liked that last phrase as it gives a sense of what Process Visibility should really mean to managers.

As a BPM Case Study, I thought the session was a good one. However, I think it would have been even better if he had covered the game-changing capabilities of a SaaS delivered BPM solution in support of the process across the wider value chain. I think many managers are still stuck in the mode of optimizing their own processes rather than looking for the opportunities to support the wider problem. It’s a bit like stove pipes inside an organisation … but here, I am getting at the opportunities to radically improve the value chain, through the comprehensive integration of all the actors involved. Having said that, I am sure John is already thinking about the opportunities to deliver this sort innovation.


The Elephant In The Room

April 11, 2009

On Thursday, I was chatting with Jim Sinur over the big issues affecting our industry. I suggested that what we need at the next Summit was to get people to start seeing these big issues … the ones that BPM is only tangentially starting to address. So the ides was to have a combative session where we bounce around the big things that seem to go largely unmentioned. The idea is that we discuss the major trends and big problems associated with long-term success of BPM. So here are a few that I proffered on the call (you’ll notice these ideas are sort of related).

  1. Organizations are struggling to drive wider adoption of process management? The average number of Processes under Management in a typical BPM site is probably 5 or less; I think we would all agree that more than 10 is unusual. While there may be some cases of organization with over 20 or even 50, the reality is that there is little widespread adoption inside your average large organization (although some are starting to grapple with that problem). Why is that? Because the effort required to standardize the processes and deal with all the data and artifacts is just too great. Yet at the same time, the number of spreadsheets used to coordinate work in those same organizations is numbered in the thousands (or at least hundreds). Every one of those spreadsheets represents and opportunity to manage and improve organizational performance. There are lots of issues that are associated with the broad base adoption I am suggesting here … education and training are key.
  2. The emergence of Case Handling as a dominant design approach in the BPM. Today, too much emphasis is placed on the purely transactional, procedural end of the process spectrum. Not enough on the needs of workers. If you like, we need the same rigor that was applied to ERP implementation now to be applied to all the other stuff in the firm.
  3. Value chain optimization trumps behind the firewall efficiency! Some organizations are experimenting with processes that span organizational boundaries (i.e. outside the corporate firewall). This is driving innovation as firms come to grips that they are part of a wider value chain. Suppliers and partners need to collaborate, as they coordinate their efforts they are using processes to work with each other. In turn, I believe that this trend is going to drive adoption of SaaS-oriented BPM solutions.
  4. Innovation is occurring in both thinking, and technology to support the needs of knowledge workers (like you and I). Not only do we need more accessible products (who wants to rely on the IT department to hold your hand), but we need new ways of thinking about process and collaboration.

And then there are a few Problems we all need to deal with if we are to get success.

  1. Deal with the Politics First – it’s an absolute waste of time trying to move forward with a BPM initiative if you haven’t got your ducks in a row. I would posit that one of the reasons why a CoE approach tends to be more successful than one-off BPM projects is precisely because of the organizational buy-in required to create that sort of entity. However, the fact remains that a CoE is major overhead on your first BPM project; establishing a CoE is an evolutionary step on the path toward BPM Nirvana. Managers should address this issue early on to avoid disappointment. This is as much about ensuring that the process is rooted in the organization appropriately.
  2. It is people, not computers that drive innovation (contentious issue I know). BPM Vendors need to get off their soap-box; they need to avoid the “add water and stir” flavor in their marketing.
  3. Resource management – I mentioned it earlier, but there are just not enough good people with knowledge and expertise available. Where are the skills going to come from? I would suggest it is much better to train your own (growing your own capabilities) rather than assuming that some outsource provider will give you the resources at the right time. I bet you were thinking abotu your project team resources … I am talking about within the business itself. As an industry, we have spent so long conspiring to keep the business professional in the dark, yet now they need to grapple with how things get done around here (one of the best definitions of a Business Process I have heard was from Howard Rheingold … “The Way Things Get done Around Here”). Point is, you cannot outsource change.

Do some of these themes resonate. I am sure there are  other “Elephants In The Room” that the industry needs to grapple with. What do you think?


An Introduction to BPMN – Chapter 5 from the BPMN Modeling & Reference Guide

April 9, 2009

Recently, there have been a couple of blog postings on use of Signal events in BPMN. First was Rick Geneva and then a response from Dave French (waving hi to a fellow Kiwi).

Anyway it prompted me to look into my book (BPMN  Modeling and Reference Guide) and polish up a chapter for free distribution. So I put it on the BPM Focus web site (you’ll find it on Page 4 of the White Papers section). You’ll need to register to get access to the document, but dont worry that’s free. If you are already registered there, then you will just need to log in.

The reason for mentioning it within this context is the extensive use of Signals that I make within that Chapter.  I meant to post this some time ago, and of course it slipped. The discussion on Signals just reminded me to get it out there.