SharePoint and BPM White Paper

On the BPM Focus web site, you can find our research paper exploring the implications, holes and joys of attempting broad-based BPM deployments using SharePoint. It is on Page 5 of the White Papers area (you will need to be registered to access the paper … free of course)

A short summary/excerpt:

Some already see the potential for SharePoint as a strategic weapon. They recognize the capability of the platform to enable collaboration amongst employees as they respond to the varying demands of customers and the market. They clearly see the need to ensure documents and data are managed effectively. But they also see the slippery slope of “SharePoint Sprawl” and the brick walls created by the product’s rudimentary process support facilities. Under the covers, SharePoint’s reliance on Windows Workflow Foundation (WF) as its process support mechanism severely constrains the platforms capabilities, inhibiting process architecture and leading to manually coded workarounds, which in turn, drive complexity and increased Total Cost of Ownership (TCO). Adding a comprehensive SharePoint-oriented Business Process Management (BPM) Suite to the mix solves many of the critical issues associated with widespread deployment of the platform.  Having embraced the SharePoint platform, organizations are discovering that, especially from a process point of view, SharePoint leaves a lot to be desired – particularly when compared with specialist BPM tool sets.  The key point is it that it is entirely possible to leverage the best parts of SharePoint – its Content Management and User Interface/ Collaboration features – and still benefit from best in class BPM capabilities.

This paper sets out to highlight potential issues for the strategist on the path ahead, highlighting the options, techniques and practices needed to overcome them. We first characterize the strategic goals of organizations and the technology strategies within them and then move on to assess the strengths and weaknesses of the SharePoint platform. We then get into the meat of the discussion, exploring how the firm can most effectively achieve its business objectives and support its business processes by further leveraging its SharePoint investment through the addition of a Business Process Management (BPM) suite.

You Can’t Make A Baby In A Month By Getting 9 Women Pregnant

While talking about the Obama stimulus package, Warren Buffet recently said “You Can’t Make A Baby In A Month By Getting 9 Women Pregnant” (he was referring to the fact that some things take time). And continuing on that theme, this article asserts that neither do many small incremental improvements make for “Business Transformation” – changing the culture takes time!

In his blog a few weeks back, Phil Gilbert raises a number of important questions: (paraphrasing)

1. What is Culture – and why can’t we change our BPM behaviors?
2. Why do BPM people promise fast incremental, continuous improvement, and then go and start every program by ‘boiling the ocean?’
3. How do we get from “Project” to “Program”?

He was talking about the fortitude required to take BPM to the long term – where the (existing) culture is the single biggest impediment. One could interpret Phil’s post as suggesting that cultural change is akin to “boiling the ocean” (attempting to fix everything at once); a strategy that is destined to fail.

But in order to move beyond putting a band-aid on a broken process (Project to Program), you need to take a step back and really set out to engage the hearts and minds of the business itself. And that implies challenging the established behaviors – creating a new vision of how to run the business – one where Process is part of the bloodstream; where the customer is king and effective processes deliver the great experiences they expect. Moreover, it also means challenging the way in which the organization is run (using processes to manage rather than just managing processes); indeed every facet of how the organization delivers value to its stakeholders.

Just because the new tools and technologies of BPM allow fast incremental, continuous improvement as a means of business change, does not mean we should do this everywhere – we shouldn’t! Sure, to get the initial project up and running, you need to stick to the core 30% of functionality that delivers 70% of the value and then iterate from there, spiraling toward better performance and a better fit with the underlying business need.

But getting the attention of the organization (taking the BPM challenge to the wider enterprise) and changing the established behaviors requires different tactics. Modeling the desired behaviors again and again just wont do it. Or putting it another way, endlessly tweaking existing processes within the current architecture fails to deliver – what you will get is “Better Sameness” not “Transformation”. Hoping that the pain of it all will enable the organization to develop an inner moral strength – one that is powerful enough to overcome the challenges associated with this transition misses the opportunity to re-energize.

The greatest obstacle to culture change is that once a culture has developed, the assumptions that led to it are so deeply engrained, that no one recognizes them and therefore, no one challenges them. In order to change a culture, it is first essential to identify the right underlying assumptions of the current culture and challenge them head on – before trying to implant a new culture.

It’s Wells – not Oceans!

So, what to do? Well, the good news is that a big, transformational vision does not involve “boiling the ocean”. The best way is to ‘Find a Well’ (the analogy being the Well of Life needs no external drivers – it is a life-giving source).

I have spent many years as a business strategy consultant helping organizations find effective, long-term, sustainable business strategies. I help them find a Well that shareholders, suppliers, customers, partners, the market and the community can all draw upon to enrich and energize their business and satisfy their needs.

What do these Wells look like? They are the values that are at the heart of that business area. Collectively, these values give direction, guidance and are rich source of ideas and new ways of doing things. So, we do not need to boil the ocean, just discover what drives and inspires the business and its people to adopt new ways of doing things and developing new behaviors.

In this approach, internal drivers that everyone values (because they see the relevance to their own business and business success) replace externally imposed behaviors (as the means of creating culture). Values come from an eternal spring – energizing again and again – hence sustainability is not an issue.

The even better news for BPM is that it is almost certain that any properly facilitated Business Strategy Workshop should lead to a Transformational Vision (the Well), with “Great Customer Experiences” as the source of Competitive Advantage.  Why is this good news for BPM? – because Great Customer Experiences rely on carefully designed Business Services, supported by effective Business Processes that provide the foundation for staff in delivering these experiences.  

At last – BPM and Incremental Improvements!

A full program will then spring from the facilitated development of the transformational vision and values. Now, having begun with the development of a transformational vision it is possible to build a program of projects; driven from the same source and fully aligned with the agreed business strategy. Those projects are built and driven by the business themselves; for the business.

However, as each individual project is taken forward the power of BPM technology then becomes clear.  BPM allows business process developers to re-iterate their designs and carry out successive re-designs – all aligned with this vision. The Center of Excellence (or IT function) provide some of the resources for those projects, but the real work, on the behaviors of the employees and the experience delivered to the customers, is carried out by the people in the business. Since they are involved in designing their own processes to support their customers, they develop a much stronger sense of ownership.

When it comes to cultural change, it is just not possible to impose a solution. You have to engage the business properly, which means winning their hearts and minds. Start with fast incremental improvements using BPM whilst convincing yourself you are being ‘business driven’ and you will end up with better sameness. Others will ask whether it worth all that effort?

On the other hand, begin with a transformational vision and your program will be truly business driven and energized. You can then move toward that vision, using the full power of BPM technology, as you continuously improve your new services and new ways of working. And your customers will become raving fans (and your staff will like it too)!

The Elephant In The Room

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?

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.

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.

Gartner BPM Summit Report

Well the book (BPMN Modeling and Reference Guide) is out, and we sold out at the Gartner BPM Sumit last week (we launched the book there). People would come up, thumb through it, think about it perhaps but then buy a copy. Several of them came back an hour or so later and bought more copies … with phrases like “this is actually designed for people to read …”, “the rest of my team need to read this …” and “I must get my boss a copy of this.” And then some of the vendors popped their heads above the parapet – one of the larger names in this space is now talking about buying 2000 copies (one for each member of staff I guess), and two others walked off with half a dozen copies for their colleagues. So all up, we were pretty pleased.

My “BPM and Modeling” track session was well attended (a couple of hundred delegates), and only 3 people fell asleep. Of course, it was directly after lunch, and modeling is not exactly the most rivetting of topics, although I did try to make it as interactive as possible (given the situation). I reiterated a central tenet of my approach to process modeling – in the early stages of a BPM initiative it is important to contrast modeling approaches to drive understanding (rather than slavishly following just one technique such as BPMN). The key point is that you need to be able to change your perspective … to see things differently if you want to really understand the process. Of course, when it comes to implementing a process using on a BPM Suite, then you need to resort to BPMN to get clarity into the execution model.

On Friday morning, I filled the (relatively small) room at the “BPM and Process Architecture” power breakfast, which was always going to be a difficult task given that the night before was the vendor parties (free booze). Anyway, several people complemented on an interesting session afterward. I had tried to communicate the set of methods we use to move from thinking about Strategy to through to implementation. This session included an overview of techniques to support the clarification and definition of:

• What business are you really in, and what business services you need to support that vision.
• From that, what is an effective Process Architecture -i.e. what processes do you need to support those business services and how do they communicate with each other, etc. (referencing the RIVA Process Architecture method).
• And from there, how do you get to the SOA-based IT Services that are needed to support those business processes (i.e. how they are implemented). What service interfaces are required for each component, etc.

The problem is that, when it comes to process architecture there are very few reliable approaches … certainly functional decomposition falls down a hole here. Most rely on what I call the “black art” approach. They make the mistake of linking Process Architecture to the current mechanisms for apportioning blame (the organizational chat) – i.e. the Process Architecture should be independent of the organizational structure. If you change the way the departments and business units are structured, this shouldn’t force a refactoring of the processes.

I ended the session with a short overview of Case Handling approaches … an area that I feel is poorly understood (especially by vendors who have little incentive to change the status quo). Case Handling is really a design pattern enabling a balance between control and adaptation (efficiency and flexibility), where users are left in control, yet the organization can still provide support for the vagaries of customer interaction (see “Customers and Business Processes – Difficult Domains to Integrate” on page 2 of the papers available on the BPM Focus web site for more detail there).

I attended a few other sessions, but found new insights a bit few and far between (for me that is, too educated I guess). I only caught the last third of the opening keynote (I was told I didnt miss much earlier), and found myself taking notes (as much as anything on the language used and the phraseology for concepts). I sat through an entire session on Customer Interaction and BPM (which I felt missed the mark entirely … but still managed to salvage a few points here and there). I enjoyed Dan Roam’s session (keynote on day 2) on modeling on the back of a napkin (using simple rich pictures to communicate). I felt that the session on BPM and SaaS (Michelle Cantara) didn’t go far enough (stopping well short of talking about the implications of the cloud on the way work will happen in the future). But there were other sessions on that (competed with my modeling session), so no doubt they got more into that aspect then.

The Vendor Showroom floor was the usual zoo – with people wandering on and off stands or generally ignoring the vendors while they consumed their deserts or coffee. This format just doesnt work for either the vendors or the delegates who want information on what the products really do. Contrast that with the BPM Technology Showcase we are running on October 14-16 in DC. The last one of those in Nashville was a roaring success as people got up close and personal with what the technology can really do for you.

Otherwise, I seemed to be either signing books or getting button-holed by folks in the hallway.