Process Portfolio Analysis Webinar – in 2 hours

I have been ignoring the blog while I have been trying to get the book finished. What a struggle – somewhat akin to passing yourself and all your works through the eye of a needle. But it is getting there.

Anyway, I shoudl have posted here the details of the upcoming webinar we are staging with the Value Chain Group.

Managing The Roadmap – Process Portfolio Analysis

Register here

Modeling & The Current State (Modeling the “As Is” process is mostly a waste of time)

It seems a contentious point of view in Business Process Management – but when we come up to the “Understand Phase” (“As Is” or “Current State” model ), we recommend “time boxing” the work to ensure that the activity is kept at a suitably high level. The intention of this activity is really to create a baseline; a reference point for the BPM project.

Now those who continue with their “legacy thinking” perspective usually decide that it is important to create a detailed description of how work happens. They model everything in sight, trying to create an accurate representation of the work as it happens today. While this is good for the “billable hours” of consulting firms, it does little for the business managers engaged on a journey of change and discovery.

The point is that the amount of work expended here is usually wholly inappropriate to the benefit derived. If your intention is to change the way things happen, gathering a great deal of detail around current work practices is a waste of time. If you are going to improve things (with or without the use of automation), then you will be changing how the process is carried out … i.e. how things happen today will soon become a thing of the past.

Don’t get me wrong, it is absolutely essential to develop a baseline understanding of the ways things are done. It’s just a question of emphasis. The issue for those involved in the exercise is just what degree of detail is required. They should be asking “can we stop now?”

The real purpose of current state modeling is to establish a baseline – so that the team can establish a realistic business case (allowing them to track benefits and improvements during and after implementation), and to identify the areas that require attention.

This is more about a pragmatic assessment of reality and clarification of current performance metrics than it is about process modeling. The metrics in question are those that the customer of the process really cares about (not the detailed cycle times of some low-level sub-process). From a modeling point of view, the need is for enough structure to hang the metrics upon (and perhaps one level of detail below). Anything more than that is a waste of time and resources.

So how much detail do you really need? Well, I normally start with high level outline of the process – the major chunks and then draw a simple high level process model. I recommend a high level BPMN diagram, but I usually seek to contrast that model with a Role Activity Diagram (not the same as a flow diagram with swim lanes, RADs model how the Roles involve change state and synchronize their actions), and perhaps simple Object State Transition Network (how the things moving through the model change state).

With a high-level flow diagram or outline of the process, it is really very straight forward to develop these alternative views, but they really do help people see things differently. I often say that the problem with Flow Diagrams, is that “the more you look at them, the less they mean.” Flow diagrams always look correct – for example, in my recent book “BPMN Modeling and Reference Guide” (authored with Stephen White the main author of the BPMN specification itself), I have yet to receive a note from anyone telling us that we have a major flaw in one of the models (yes, there is at least one). It just looks correct (and this is a book where we tried our very hardest to make sure every model was “right”).

Incidentally, the best reference on RADs is Martyn Ould’s “Business Process Management – A Rigorous Approach.” And for OSTN, I prefer the IDEF3 perspective as it is relatively simple and easy to understand (UML also has similar modeling capabilities).

Coming back to the Understand Phase, in the workshops with the Subject Matter Experts (SMEs), I also seek to understand the volumes of work, any major exceptions and the percentages of items that follow the major paths from decision points. The other thing to understand is the numbers of employees involved in the work (FTEs and the amount of time spent on each area of the process).  From that information you can calculate the costs of undertaking the work and where the money goes. You also need to understand the roles involved, and the capabilities of the staff members who fulfill those roles. All of these become essential ingredients for the business case. Without it you are whistling in the wind (when it comes to asking for funding). Even if you already have the funding, you should do this anyway (it will certainly be needed later).

I could go on here at length, but the point I am trying to make here with this blog post is this … if your consulting provider is asking you to fund a detailed “As Is” phase of work, then you are throwing money away. They are more interested in lining their pockets than assisting the client. The only exception that I can think of is where the process is itself highly regulated (and a rigorous work definition is mandated by law). In such cases, I think you have to draw your own conclusions on how to avoid “analysis paralysis.”

BPM – Is it a Software Engineering Tool? A Technology? or a Management Discipline?

In his excellent posting, Keith Swenson makesmany good points. He points to the range of interpretations of BPM, and particularly highlights the issues associated with its interpretation by software engineers as just another piece of hype on the road to good programs. But I think there is another, perhaps more important strand that is buried in there. As Ketih points out, BPM is about the Management of Business Processes.

As we all know, everyone’s interpretation of the term Business Process is different. In my training (whether that be BPMN, or higher level training on BPM Methods), it is one of the first things I get people to write down (inside the first 5 mins), and not surprise, every definition is entirely different. And when those people are senior managers in a ciompany, their interpretation of the term is invariably what I call “Process as Purpose“. The point is that they see Processes as being more about the purpose than the constraint implied by sequencing of steps. They are there (at the training), because they see the importance of “Managing” their processes. Indeed that concept (Managing Business Processes) as central to the success of their companies.

[[ I am still down in Brazil, and I am really struck by the process sophistication of the people I am meeting. They all get it. I was more than surprised to find two "Business Owners" (people who own significant businesses), giving up 3 days of their time to come on a course around how to structure and run BPM programs. They were cherry picking from the broad range of techniques we covered, but ask yourself whether you could imagine the CEO or COO deciding that they should attend a public training course. That's what I am getting at about the sophistication of the Brazilian business climate. ]]

Coming back to Keith’s post, he describes a spectrum of BPM interpretation – from pure Software Engineering (where the SW Eng tries to reflect the needs of the business person’s Business Process); through Business Processes being modeled by a business person, then tossed over the fence to a Software Engineer to finish them off; to the Business Process as modeled by the business person, then being directly executed (what he called ”Pure BPM”). I am not quite sure I agree with the Pure BPM bit, but I do know what he is pointing to … where the processes of the firm are driven by models (without translation to some intermediate executable format (like say BPEL).

One of the comments on Keith’s post points to the challenges of getting business people to model their own processes and make the resulting collection of stuff useful. He described the usually resulting mess as an “expensive disaster”. And the reason for this is that business people dont usually have the sophistication to understand their business problem as a set of inter-releated processes that between them deliver on the “Process as Purpose” concept I referred to earlier.

Invariably, process modelers (whether IT or business) tend to see a process problem as a single process. They interpret the high level Purpose as a single implementation process (which invariably it is not). They make all sorts of mistakes such as mixing up the ”Handle an Instance” with the “Manage the Flow of instances”; they switch from batch mode to handling a single instance; they dont think about the interfaces between processes (handing information from one to another), etc. What they do is try and connect up everything that sounds like an Activity into one convoluted process.

Now software engineers are usually more adept at the necessary abstract thinking, but that doesn’t mean to say that business people cannot wrap their pretty heads around the notions. It is merely a reflection of the fact that they have not had adequate training. What is missing (across this entire industry) is better learning around “Process Architecture” – what “chunks” do you need and why. Poor chunking leads to unnecessary complexity (and even “expensive disasters”).

We are still stuck with decomposition as the prevailing mind set – where sub-processes are always contained within the parent. SOA concepts seek to get around this, but there is also a higher level “Business Services Oriented Architecture”. Processes should not be regarded as some sort of static hierarchy, they are more accurately regarded as a network of interacting instances. Think more jigsaw puzzle than org chart.

When I gave a “Power Breakfast” at the last Gartner BPM Summit on BPM and Process Architecture I had a packed room (it was starting at 7:30 in the morning so these people were keen). I described a set of methods that you could use to go from “What Business Are You In” to what “Processes Do You Need” right down to the SOA components if that is what you wanted to do (I would recommend looking at a BPM Suite first rather than going straight to the SOA software engineers paradise). I only saw one person out of the 90 or so get up and leave, and nearly everyone else gave me their card at the end of it. The room really was comprised of mostly Enterprise Architecture folks from the IT community, all of whom struggle with this transition.

Switching tacks – the vendors BPM Suites are unconciously making this architecture problem worse. With only a few exceptions (Pega, Itensil, BizAgi … I am sure there are others in this category too, these are the ones that spring to mind), vendors interpret the business process problem as being entirely seperate from the data and artifacts associated with the process (business people see them as intertwined). They regard the process relevant data as a set of named value pairs … the information required by Process A is declared on Process A, and must be recreated on Process B and then mapped from one to the other (if the processes need to communicate with each other). That means that there is an extra (unnecessary) layer of complexity for business people trying to reflect their business problem. Moreover, if you change one process, then you need to refactor all the interfaces. This is “software engineering” oriented thinking.

The other approach is to define your data structures (perhaps as an “Entity” defined as an exstensible set of XML artifacts) and then describe the views on those artifacts at the level of the data structure. Then it is merely a matter of associating your processes with the Data Entity, and all the different views become available. Process interfaces become an order of magnitude more accessible (to the business user), you can use any number of processes to support a single case of work, and again it helps move away from the software engineering mindset we find in so many BPM tools (which were often created to solve the problem of Enterprise Applicatin Integration … hence their association with Software Engineering).

Brazil seems full of “People Who Get It”

Last night I was “privileged” to go along to the Brazilian Quality Awards (Fundação Nacional da Qualidade) here in Sao Paulo. I was invited along to their national awards ceremony by FNQ. I am here running some training – BPM Process Modeling Fundamentals (BPMN) and Developing A Structured Approach To BPM – all hosted at the FNQ offices.

Now I don’t speak Portuguese, so the speeches went over my head (pity, as most of the audience sat in rapt attention). But what struck me was the seriousness and understanding of the business people I met – serious in the sense of processes are really important to them; and understanding in the sense of the journey they are on.

And some are well advanced on that journey. I mean, how many Executives (business owners) do you meet that really do understand the notion of truly managing their business through processes … let alone one who it turns out does not have any functions at all. His company has no Functional Managers, just Process Owners and associates working with them. Not many that I can recall.

Coming back to the Quality Awards, I can see it is really a serious business here. The speeches went before the dinner … and with no jokes (that made the audience laugh) until 50 minutes in, it was tough going (so that’s one SLA not well met).

But here in Brazil, they really seem to get the Connect, Communicate and Collaborate ideal, which was in sharp contrast with some of the power games played by the traditional (American/British) way of doing business. With the people I have met here in Brazil, I have been struck by the contrast with some of those I met on my way here.

I met a number of Senior Executives from brand name companies. Whether their parent companies get it or not (at the C level exec level), one thing is for sure, the local management talent know what it is all about to compete through process. A perspective that I felt was backed up by the quality of the Business Analysts I met on the courses so far. Make no mistake - Brazil is a rapidly growing market for BPM.

BPMN 2.0 – Marriage Made In Heaven or Trough of Disillusionment

Inside the OMG there has been a heated debate about whether BPMN 2.0 should become linked more explicitly to UML … so many heated exchanges to chew through. This blog posting was put together in that context.

It was originally Charles Box (and later Deming) who said: “All Models Are Wrong, Some Are Useful.” We should learn to live with that reality.

By modeling something, we are removing some aspect of the real world in order to represent it. And yet, the IT-oriented folks continue to flail about looking for one true modeling notation and set of semantics to rule them all (like string theory). As though how somehow everything must be translatable and interconnected. I think for most business folks – they don’t really care. They use models to communicate with each other … and yes, they use circles and arrows, and boxes and clouds, and … only a very few have the interest in making them all relate to each other.

It is only when we get down into the IT organization that all of this stuff has to be translatable and traceable … that all the classes and elements have to get along (be placed in some interconnected network of stuff).

We currently have a Business Process Modeling Notation (sans rigorous meta-model), we also have a Unified Modeling Language (avec rigorous meta-model)… both can be used to model processes (even businesses). But they are different and some folks feel the need to move stuff between these two approaches. We invented BPDM (another rigorous meta-model) as a mechanism for doing that sort of thing along with providing a competing BPMN serialization (to XPDL). But BPDM was deemed too hard by many (or too expensive to implement support for when you already have UML) … at least we have seen little appetite in the market by vendors for supporting it. Most of the BPM Suite/Workflow vendors out there are on XPDL.

The idea with BPDM was to create a semantic layer that would allow the translation between these modelling notations (and others). Or more precisely, that which can be translated should be able to be translated with “semantic integrity”. It would also allow for extension of the semantics for different needs. But for UML to work alongside this, would have meant a Profile for UML (or some other detailed integration at semantic level) – but the folks with the skills and expertise for this sort of thing chose not to invest their time and energy in developing such an interchange format (between UML and BPMN via BPDM).

But that’s all history now. What these well resourced players could sign up to was a future version of BPMN. So now we have BPMN 2.0 – with all the hope and promise of an effective marriage between orchestration (BPMN) and choreography (something that is needed for effective interchange of models but very few people understand fully).

The BPMN 2.0 RFP calls for: “A single specification, entitled Business Process Model and Notation (BPMN 2.0), that defines the notation, meta-model and interchange format … Extension of  BPMN notation to address BPDM concepts … [will need] changes that reconcile BPMN and BPDM to a single, consistent language. The ability to exchange business process models and their diagram layouts among process modeling tools preserving semantic integrity. Enhancements in BPMN’s ability to:

Model orchestrations and choreographies as stand-alone or integrated models. Support the display and interchange of different perspectives on a model that allow a user to focus on specific concerns.” Further … “Proposals shall specify conformance criteria that clearly state what features all implementations must support and which features (if any) may optionally be supported.”

At the same time, it now seems that BPMN 2.0 has to provide a high level modeling approach and traceability down through the stack (which means UML right). There are various other camps – all attempting to twist the specification in their own particular direction. I hear one group saying “let’s make BPMN reflect the needs of BPEL”; others saying well we should now make BPMN part of UML (I must get asked if that is going to happen at least once at every conference … always with a look of dread on the part of the person asking); others wanting stronger choreography support (personally I would like to see something emerge that could support a translation to Role Activity Diagrams which is a much more powerful approach to modeling how roles collaborate and inter-operate that what I have seen so far in BPMN 2.0).

So now that we are in the trough of disillusionment (the marriage vows have yet to be cemented, the RFP is but a hazy memory of a drunken engagement party). We have two different groups (power bases) lobbying for the ascendancy – well not really lobbying, lets just say they are struggling to work out what bits of each others proposals they like, what they can live with, and what they don’t like. And there is a lot more soul searching (work) to go on there.

Let’s recap on where we seem to be now:

• There is a Notation Specification with some (IMNSHO) half baked choreography support (along with an abstract syntax). It fixes some things and has missed the point on others.
• There is another Specification (that derives from the BPDM) which describes a more robust set of process semantics … let’s call that the Process Modeling Framework for the moment. This is still perceived as too difficult for some to wrap their heads around … but in the end it is where the UML piece will have to tie in (if someone is going to invest the effort).
• Then there is a specification that is supposed to outline the mapping from one to the other.

As far as I can tell – all three of these documents require significant further work to marry and align – personally, I can’t see this being finished in the near future. It won’t be just a one cycle delay.  And that’s before we take on the UML interface challenge (although I am sure someone stepping up to the plate on that one would be welcome, they would be doing it against a moving target). We also need to think about how we will embrace the current XPDL community (an upgrade path). And now it looks like we are now about to invent a couple of new modeling approaches, which of course some are already saying should somehow be like BPMN (or UML).

In the end, this stuff only makes sense in context of enabling businesses to work more effectively. BPMN 2.0 needs to give true model portability (with semantic interoperability). We need conformance levels (but first we need to decide on where the lines in the sand are for those different levels). We need to … stop broadening the effort and focus more on getting to the result.

It can’t be that hard – especially when we have all the “Wise Wizards at OMGee” working feverishly on the problem.

Back Home At Last

Well, I feel like I have been through the ringer … although I got “home” in the middle, I moved house to (SW France) and then immediately set off again. So I have been on the “the road” since mid-August. Hence only a few blog posts here and there (not as though I posted that many before). Now I am in one place for a couple of weeks its a chance to catch up and regroup. I have a load of notes from the various events I went to – my intention is to combine them into quick summaries of each one and post them here over the coming couple of weeks (before I head off again on another spastic bout of travel).

I also intend to pick up on the various postings around the future of BPMN 2.0 and what it needs to deliver, along with my perspective on the BPMN-BPEL debate that has broken out in the blogosphere.

One area I have been working will start to show through in the blog and the engagements we take on. We are calling it “The Center for BPM” – a group of accomplished associates coming together under the BPM Focus banner to really focus on what is possible with BPM and learn together with customers. Essentially, we offering services that help you deliver your outcomes!

Service mix from The Center for BPM

The Center for BPM comprises a network of tightly aligned experts in the BPM arena. We work with colleagues and customers to push the envelope of what is possible within the context of a BPM initiative and BPM technology. Our experts are quite literally, giants in their own respective field of expertise – internationally recognized and successful in their own right. We work together within the Center for BPM to share our perspectives, IP and expertise, learning together and creating new insights and capabilities. We collaborate as appropriate on individual assignments. So over the coming months you will see others coming here to blog about their own perspectives.

I suppose that is enough for now. I will soon start chewing through the notes and posting my own perspectives on these conferences.

Customer Experience – How To Get It Wrong

So now, exhausted after getting conferenced out over the last 3 weeks, I am on my way back across the pond. And I find myself once again confronted by the complete lack of thought on the part of my not so favourite airline (British Airways).  This posting is a bit of a rant … but it has a point. Designing an effective customer experience needs to be reflected in all your processes not just your marketing collateral.

As a regular traveller across the Atlantic, I normally fly Premium Economy as I can usually work and get things done (and that also has the added advantage of letting me actually have somewhere for my long legs). So over the years, I have risen to the lofty ranks of a Gold Card holder. And the benefits I get for that are … er … well I get to check in at the usually empty First Class line, and sit in their lounge (I don’t usually drink while on travel).

Now on the Washington to London flight, those with access to the lounge were always able to have their dinner before getting on the flight in the hope of getting some sleep on the 6 hour red-eye flight. Well not any more, it now seems that this privilege is reserved for those who have agreed to fork over the $4500 for each way (and that’s booking 3 weeks ahead).

Point being that, despite spending around $30-40K per annum with BA, I am now denied this meagre benefit (instead I have to head outside the lounge and spend $15 on a shitty hamburger).

As a Gold Card member you would think that this would entitle you to the odd upgrade – the reality over the last 18 months – nada. No upgrades unless you know someone on board, or get someone to pull strings for you back at the departing airport, or the once in a blue moon when they are really overbooked in the back of the business units (and nobody else is above you in the pecking order … i.e. has a permanent flag on their record saying they are “suitable for upgrade”).

So you start to ask yourself just what is the benefit of putting all of your business into an arrogant waste of space carrier like BA. Yes they “protect the brand” but that is of little consolation to you the regular traveller. And they piss you off with petty rule changes designed to save a few dollars – but in the process, they loose customers.

Where was the cost benefit analysis … let’s tease it apart. Per passenger that are in that category (i.e. gold card holder in Premium Economy), BA get to save perhaps $5 per person (remember they get to save the meal onboard). Lets say that applies to half of the PE travellers … say 12 people. They don’t get to save any staff costs really (same number of people standing around in the dining area). And with 2 flights per night to LHR, that say $120. Or put it another way, less than $1K per week. But along the way they loose a regular customer … and I am sure I am not the only one.

Time to switch back to United … while the service is not great, there are appreciable benefits associated with them. I am not saying their experience is much better, just that you don’t really expect much (and you dont have to pay a premium for it). BA’s marketing is that there is some real benefit … when the reality is there is virtually none (compared with competitors). Their cost cutting program has perhaps trimmed a few dollars here and there from the fixed budget, but they have also trimmed customers.

PegaWorld Keynote – Mhayse Samalya – President of Farmers Insurance

Update – you can view the Keynote itself here (requires registration).

This division of Farmers deals in the small business insurance market – a $95B market. When Mhayse joined Farmers, they had just 2% of that market. He saw it as an incredible opportunity – where 47% of business in the small commercial insurance sector, are with small business insurers. The question is why these small players succeed against a big player – it’s because they know their local community, they are part of it and know how to communicate with their customers.

Mhayse described his approach that really started with a clear Vision … He set out with objective of becoming #1 in their industry, and then laid out a strategy of how to get there.

The vision was to:

• Excel at the core
  
• Build deeper expertise
• Leverage predictive modeling
• Expand the appetite and sophistication of the organization,
  
• Create a targeted set of offerings for agents and their customers.
  

Only then did they start to think about how you deal with the small business opportunity and the efficiency end of things. Sure you need an efficient way of doing the business, but the primary focus of that vision was on growth and the customer experience.

He went on “You cannot expand the appetite for more … unless you can automate the way in which the business operates. I didn’t know what I was searching for – but I was looking for something that would help us … something that would give us a clear line of sight to the solution to the business problem. I had to understand what it was going to feel like. However we get there, we had to create the right sort of agent experience … we had to get them (agents) fully engaged to get the benefits of the gem we had in our hand. How do we reap the benefits … it has to be done in increments. I wanted to know where the short term goals and pointers were (pointers that would indicate we were being successful). Trying to get there all at once is probably going to end in disappointment. We had to do a set of projects, and do them quickly, while being flexible along the way.”

At this point I was really engaged … I hadn’t heard a business leader at this level talk about a BPM project in such an impassioned way. This was his project, and he had been driving it top down. Now I started recording the slides and some of the related phrases:

Create the right agent experience – we had to demystify that experience so that it really helps the agent – pre-filling information into forms and easing the user experience.

• Eliminate the useless questions and options
• Automated underwriting decisions
• Automated pricing … it used to take us far too long to price a policy.
• We had to increase the pass through rate … the time to get a bound policy.
• We were looking at (touching) 80% of the business that was passing through, and were closing just 20%. That should have been precisely the other way around.
• The question was how could we enable the local agent to be local in terms of how they work.

Focus first on Agent expansion and New Business Growth

• First support environment was delivered in 5 months.
• Restaurant product went countrywide in July 2007
• Rolled out the Auto policy facility in Oct 07
• And getting an “umbrella” policy available as an add on in June 2008

The results:

• 14 days to 14 minutes
• Close rate was up 5%
• New business was up 70% “do you want Fries with that”.
• Renewals up 60%
• Added over 1000 new agents (later updated in the flow of conversation to 1500 new agents).

We focused secondly on efficiency … not how many people we could chop out

• Endorsements
• Renewals …
• Focus on the desired business result
• Eliminate all the non Value Add steps, take out the noise and red tape.

Put the business change in the hands of the business

• Pulling together cross functional teams
• Finger pointing is the wrong way to go …
• Rapidly iterate
• We don’t always know exactly what we want
• We are sometimes representing other folks … like the agents that work for us
• Test, monitor and respond quickly.

Building the right team is critical

• Empowered … someone who is on my team that was also part of the IT organisation
• Dedicated cross functional teams – jammed them together, locked them in a room and told them they couldn’t come out.
• Wanted to have a partner with skin in the game. Developed a Customer Intimate relationship with Pega. Their compensation was linked to the delivery of our results. Now we really are on the same page.
• Get participation and engagement – with the agents.

Farmers had gone from low on the food chain … to the fastest growing at Farmers, the most profitable at Farmers, acquiring over 1500 new agents. They acquired a business along the way and have now grown to around $3B, representing 3% of the available business out there. Tied for first place.

Questions – How do you change the culture? At the end of the day it comes down to individuals. The traditional solutions were not going to get us to where we wanted to go. We have 1000s of people and unless you start to align the objectives, their compensation, etc. then you will have problems.

There has to be a common and shared vision – one that get both business and IT people excited. Too often there is an assumption in the business mindset that IT folks don’t have that sort of vision – that they don’t respond to the challenge. Point was that with the BPM program (still ongoing) they had proved that wasn’t true.

The key point for me was that he focused first on the Customer Experience. They had a strong visionary leader who publicly aligned himself with the overall success of the program. Theydrove partnership and engagement through cross-functional teams to achieve results The business results speak for themselves.

I just hope that Pega and Farmers agree to put the video up on the web so that we can point others to this powerful case study.Its one that every COO and CEO should see.

 

 

Alan Trefler – CEO Pega Opening Address

PegaWorld 2008

A great opening pop video – let’s see how far we’ve come. How far we’ve come is reflected in that a vendor gets to have more delegates at their own conference than the mighty Gartner. 850 people all gathered and sitting together to discuss their respective journey’s and approaches.

Alan starts off with a couple of anecdotes about history of Pega and how they started on Main St. Product has now gone through 4 from scratch rewrites – yet the core vision of the company is still very much aligned. A lot of M&A activity has led to an evolving landscape of customers – JP Morgan Chase now represents some 10 original Pega customers.

I see that Alan’s 6 Rs have been there for a very long time too (and I am still not sure that these 6 Rs do anything more than confuse poor Caddie the Customer). The core message – about Process Automation – where the business and IT learn to work together. All about allowing them to change roles, which is a little frightening for most. And a lot of this change of roles is about persuading IT folks to allow business people to get involved in real world implementations. It’s not about the IT and data, its about the business and their ability to get things done.

There is no layer to BPM – neither is there a rules layer … it is more like a DNA that needs to live in the body politic of the organization. Yes, how you control it and how insert it into the organization needs careful thought, but it is not some part of a stack on an IT architects chart.

Mind The Gap

The requirements specification is a dead and outmoded way of thinking about systems that hasn’t changed since the mid-sixties (something I have been saying for yonks). Its about allowing the business and IT people to work together, so that instead of starting with documents, the approach lets you generate documents as recordings of the state at that time in your thinking. It’s far more effective to use a model driven environment to support that – it’s also cheaper and quicker.

But the IT folks have human beings acting as some sort of typing pool to translate conversations about business intent into some sort of arcane language. Automating the programming is not sufficient – we (Pega) want to automate the business logic. You have to capture the entire user intent. This is not about putting a Pega system on the desktop, it’s about putting the user intent on the desktop.

Platform as a Service – enabling people to set up an entire Pega system for a part of their organisation, they can create their own SaaS enabled applications doing it easily and directly. To use Pega to put parts into your web site … to insert Pega functionality into your web site.

Another month, 3 conferences later …

Well here I am back at the Gaylord in DC. It seems like months since I was here last (yet it is less than one). In the meantime, I had good intentions of blogging about the BPM Think Tank experience (OMG Chicago Oct 6-7) … but that was swiftly followed by a workshop (Developing A Structured Approach for BPM) so I sort of lost site of all my notes. Its still on my agenda, but keeps getting pushed out by other things that must get done.

After that we had the BPM Technology Showcase – I sat in the sessions this time, shadowing a customer. It was really interesting to me to see some of the innovation that has been happneing. I have comprehensive notes from most of those sessions so I still intend to post stuff there.

Now here we are the following week in DC again, this time at the Pega event. I will post seperately on the notes I have been putitng together. I wont try and keep up with Sandy, but I am starting to marshall my thoughts and observations. What’s great about this conference is the really excellent conversations I have had so far … but that’s the nature of conferences, you never know who you will run into, or what you will talk about.