How do we ensure a BPM project succeeds? People, technology or tools?

For a while now, BPM vendors and analysts have had a real drive towards out of the box generic tools and solutions. So much development cost and consultancy time has, and is, being spent trying to fit processes into pretty flow charts, and more worryingly into BPM vendor designers. There is massive development work and tools for “designers”, “connectors” and “integrators” but do these tools actually help a business implement BPM? More importantly do they actually help the business realise the main goals of a BPM solution, such as customer experience, efficiency gains, productivity gains and an overall reduction in end to end process cycle times?

Currently there seems to be two trends in BPM, the first is focused on tools and quick automations (lean is a good example) and not on the actual people who make a process work. The second, concentrates on endless improvement of processes through flow charts, through people, and doesn’t utilise technology or tools very well at all….

Why so much hype on tools?

It is a current trend in both business and IT that things must be “generic” or “off the shelf” products. It seems not many organisations like the idea of developers being involved, developing processes or components that work for their organisation. Many would rather they can purchase something off the shelf and have it configured for their needs, even if this restricts their systems performance and capabilities.

I am not a great fan of many “tools” in BPM simply because many tools look great in demonstrations but don’t actually provide anything in the real world. Of course there are exceptions, tools that help me calculate through-put of a process, help identify bottle necks etc are all good, but tools such as “connectors” and “designers” are just too restrictive. However, I am a strong believer in technology, technology is massively important in terms of BPM and any IT based solution. Technology can deliver more to your business and in many cases, can give you that competitive edge.

 The problem I have with such focus on tools is that the real issues are often overlooked / lost. Often a constant drive for tool means we actually lose sight of the people that make the business work. If we constantly try to think of them in a production line, then we dumb down their capabilities and restrict the service they can provide to the business and to customers.  Also, do we actually need all of these tools? Are some more bad than good? Are some just pointless? (Yes in many cases to all three)…

On a side note, it’s also worth noting that I have seen many “configurations” of systems and tools which basically have developers writing code or modifying code so that a tool meets the customer’s requirement. Isn’t that defeating the point? Tool configuration can get pretty expensive…

Should we be hung up on technology?

Many will say No here, and that we should be focusing on the business needs. As I said, there seems to be two trends in BPM. Keep in mind though, if you select a technology or platform that is too restrictive, then it will have an impact on your business processes, staff and ultimately business itself. No matter what solutions you are looking to utilise, you must have the technology and its capabilities in mind at all times. So we should be hung up on BPM technology and just what the platform can deliver.

Businesses should also have technology in mind across the complete enterprise, some form of technology strategy and roadmap should be in place, easing administration, implementation and making system integration easier.

Alignment with IT capabilities

Business strategy and processes have to be aligned to IT capabilities, and not the other way round. If IT or a technology doesn’t have the capabilities to deliver what you need, then the business will have to make do. Is this right? Probably not, so this is why a good focus on technology is needed, maybe not tools, but the underlying technology. But let’s look at this from a different point of view. Many times I have been involved with projects where IT capabilities have actually highlighted different and more efficient ways of working to the business. The business requirements then change to ensure they can take advantage of the IT capabilities. BPM is probably the most important area of IT where business and IT professionals need to communicate clearly with each other, and actually be involved every step of the way, together…

Does the flowchart and designer tool limit our capabilities?

Whenever we talk about BPM people want to “map” and draw lovely flowcharts to explain a process. This is great at a high level business point of view, but almost always, flowcharts will not show everything that actually goes on. In addition, you can’t really use these to go and explain to each staff member just what they should be doing in terms of work and how they work.

I don’t have a problem with using flow charts to illustrate a process, what I have a problem with is building solutions based on flowcharts / maps via some form of designer tool. This way of working is far too restrictive, in terms of integration, process capabilities and empowerment of staff. The designer is a great tool and way of working for demonstrations. It quickly illustrates how BPM can work for an organisation, and shows how easy it can be to implement. However, it has so many short comings that it actually restricts the way the business can work.

I have talked about the designer a number of times, and the fact that we don’t actually need a designer. We should be using intelligent processes and processes that are capable of being highly adaptive.  If you haven’t read this previous post, please have a read through my thoughts on mapping tools: https://andrewonedegree.wordpress.com/2010/03/24/adaptive-bpm-no-mapping-tools/

In short, the designer tool limits capabilities greatly. This is the prime tool that people get hung up on, yet it is a tool I say we do not need.

Being adaptive and the empowerment of staff are the keys to success…

Technology is important. When looking at BPM solutions, think “what can this technology do for us in the real world”, don’t get carried away with pretty designers, fancy tools etc. Technology is important, the tools not so….

If you can leverage a solution that is highly intelligent and highly adaptive, then you increase your process efficiency gains greatly. In addition, you put the people that make your business “tick” at the centre, empowering them to work more efficiently and in a fashion that benefits your customers and you as a business. Think, if your staff members are working away and they come to a point in the process where they need to do something different, if they have a technology that allows them to do this, and to build it into the process for future users, then your customer will receive a great service and your process has grown and captured more of what is going on.

Adaptive BPM solutions sit oddly enough in the middle of the two trends within BPM. The technology and tools available ensure that the processes are constantly evolving; the technology and the available tools show this to the business. Designers and decision makers can then re-engineer these processes, look for efficiency gains and then re-implement. In addition, the people at the centre of the process are empowered and not restricted in the way they can work…

Final thoughts…

To succeed with BPM, always keep in mind the technology, the people, the process and available tools. I suggest you prioritise these as follows:

• Technology – Is it adaptive? Can it empower staff? Can it integrate?
• People – Can these people work with enough freedom?
• Process – How can we reduce processing time?
• Tools – What tools will help me make decisions

BPM: Do we detect a process or invent it?

This was a question on ebizq.net at the start of the month, and when I first read it thought “I wonder how many people go for invent, or talk about abstraction, or the fact that workers are cogs in a process…” You can see the discussion here:

http://www.ebizq.net/blogs/ebizq_forum/2010/08/are-business-processes-detected-or-invented.php

 I have read through the discussion, and haven’t really wanted to make further comments because I felt that the discussion moves away from the question far too much. Typically us BPM thinkers like to “abstract” everything so we are not talking about a single process example, rather something that can be used across all processes within any business or market sector. However, though this is great, and I always go for abstraction and generic based thinking, it really doesn’t help a) answering straight forward questions like this one and b) making life easier for business decision makers in adopting BPM.

So what are the arguments for invention of processes and those for detection?

Invention

There are few times that as a business, you get to “invent” a brand new process, something that the business has never done before. The only time you may do this is if you are a new start up, or a company that has spread its wings into new markets, or a company that is re-structuring the way it operates. With this in mind, many process inventions aren’t actually new, rather they are tweaks of existing “known” processes. But let’s think “BPM” implementations and getting the process created. In this case I include designing processes as invention, processes that we are aware of and have had the luxury to address, refine and then define as a business process. These are invented / designed processes.

Typically a BA (Business Analyst) will have knowledge of a particular process. This is then analysed and then re-designed with maximum efficiency in mind. This can be communicated through a number of tools, visual aids and BPM type languages, but I won’t get bogged down with that. Rather, the process is now designed and ready to be implemented in our BPM platform.

For many, this is the best or only way to implement BPM solutions. So even though these processes are tweaks or conversion from existing processes they are “invented”.  There are many arguments that to design / invent a process, you must first detect it and have knowledge of it, I think this is simply an obvious statement. When talking BPM processing, Invention Vs Detection I take as how these processes came to light and how they end up in our BPM platform. As ever, let’s keep things simple.

Detection

It is common knowledge that organisations don’t know all the processes that they execute, it is also common knowledge that trying to design and implement all processes in a BPM platform will mean you only actually implement a small amount of processes carried out. So what does this mean in terms of invention? Well it means that invention alone will account for a fraction of the processes. So if you believe invention is the only way we can use BPM, then your organisation is missing out the benefits of BPM across any number of processes. Invention addresses known processes, we need something else to allow our BPM platform to detect and find the other processes out there.

Employees are paid good money to act as knowledge workers, they make key decisions and yet for many in the BPM world they are viewed as simple “cogs” in a process machine. If you take this view of people in the process, then you have to state that processes are invented rather than discovered. Since we know that designed and invented processes don’t make up all the processes out there, we know this thinking is simply wrong. This means that detection is key to successfully implementing a good BPM platform, and is key to making the most of your investment.

So how do we detect processes? There are many ways, some argue chasing a paper trail is good, which is true to an extent, however many processes may be in a person’s head and don’t involve paper. How do you detect these? Some talk about desktop activity, yet again this doesn’t capture the complete truth either, missing manual activities…So what is the answer.

I would argue that you need a BPM platform that is flexible / adaptive enough to allow your knowledge workers to update it. Even with designed processes, we see that elements have been missed or need tweaking. In such cases, knowledge workers with an adaptive platform, discover new processes / sub processes. They then update the process to make it “correct” (if they have permission and if indeed their updates are needed). The same applies to processes that are completely unknown. In these cases, knowledge workers detect unknown processes. These are then created within the BPM platform and made available for all, again if they are needed. Detected processes can then be reviewed and streamlined / re-invented because we now have knowledge of them.

The key to detection is choosing a BPM platform that is adaptive and trusting your workers knowledge.

Conclusion…

The question implies one is better than the other, or that in reality one thing happens without the other. The truth is, as an analyst or an organisation implementing a BPM platform, we do, and need both, “invention” and “detection”.

Invention is the starting point for implementing BPM. It is also the ultimate goal, to be able to design your processes to maximise efficiency, however in reality, this cannot be done for the majority of processes, simply because they aren’t known yet and/or the amount of time spent on analysis would be vast. So, in order for us to get as much knowledge about processes, and to therefore really maximise BPM in an organisation, we have to view detection as a massively important feature of the long term success of BPM.

This detection requirement is why I am a strong advocate of adaptive processes and adaptive platforms. It is also why I don’t like “lean” type solutions, or solutions that rely heavily on design based maps. These types of solutions typically presume that all processes are invented, and we know this simply isn’t the case…

Does BPM need a W3C type Standard? No way!

I have read a lot about the need for BPM to become more standardised, similar to the way in which HTML has a “standard” that is followed. Now, I have already posted about some of the limitations HTML has, and the problems we have with HTML running in different browsers, however, if we tried to do something similar with BPM, the problems will be far far greater than any of those a web developer faces with HTML and CSS…

Standards stifle innovation and hamper evolution

This is a simple statement and it is very true. There are many benefits of working to standards, and I embrace standards in general, however, having standards set in stone for how something works, or is defined, is very different to say, having standards on naming conventions when coding…

The problem with working as a standard is that when someone thinks out of the box, and they want to implement their great idea, they instantly have to break the “standard” to do it. Let’s take HTML as an example. The HTML standard simply doesn’t include everything we come to expect from the web today, this is why Flash was developed in the first place. I know HTML 5 is to be the new standard in years to come, but this looks to be yet another number of years away (and that is a different post). In the mean time, what do we do…Oh that’s right, we abandon the standard and use something proprietary, Flash or Silverlight to get the job done. Once HTML 5 catches up, oh I will more than likely still use Flash or Silverlight as they have moved on yet a further 10 years too…..You also have to remember that Flash has been around for years and years now, so we have worked with RIA for sometime without the HTML standard as such….

The HTML standard needs to work to some extent (even with Flash and Silverlight) because the architecture of the web. We use third party browsers to render and display our web pages, and HTML is the mark-up that describes to the browser what to do. So in this case, sure we need a standard of sorts so that the browsers know what to do with the HTML, and vice versa, designers and developers know what HTML to write that works how they want in a browser….

However, in the world of BPM this really isn’t a good option. BPM is very generic, and can encompass so many things. By stifling organisations to adhere to a particular standard will only stop BPM evolving quickly enough to keep up with business requirements. Take social BPM, if we had to adhere to standards, would Social BPM be where it is today, or would we have a “break away” number of platforms that deliver Social BPM functions and not adhering to the BPM standards….As I said, standards stifle innovation and evolution….

The designer has become the standard

Unfortunately the process designer has become the “norm” or “standard” for how we define processes in a BPM platform. Again, this is far too restrictive and something I have spoken about in a number of posts now. I won’t go over this ground again here, but if you are interested read

https://andrewonedegree.wordpress.com/2010/01/14/intelligent-bpm-maps/

https://andrewonedegree.wordpress.com/2010/03/24/adaptive-bpm-no-mapping-tools/

BPM needs to step back and away from the designer as it currently works. Please don’t miss understand, I am happy to see processes shown graphically, however, I don’t believe this graphical representation (made up front) should be how the system runs. For one thing, this presumes our BA has everything correct, it also presumes that the process will not change based on user requirements and finally, it presumes limited integration (at best). Unfortunately the designer is a great tool for demonstrations and showing processes running quickly, however it is not a great tool once a business buys into BPM and finds out just how restrictive this way of thinking and working is…

Is there a place for standards at all in BPM?

YES! The only place where standards should be introduced is that of integration and API. It shouldn’t matter what technology your BPM platform is built on, be it .NET, Java etc, its API, should be technology and platform independent. This means the standard for an API should be XML Based Web Services. In addition, it should be a standard that the BPM platform itself is built on its own API, ensuring that integrators can gain access to everything they need from the BPM platform via its API (I hate to see platforms – not just BPM – that have a limited API). I wouldn’t take this standard further (though I am sure some would call for specific calls to be used to do x,y and z).

With this type of standard, BPM can be used within other LOB applications, it expands the potential use of BPM and provides businesses with a level of abstraction for business rules that makes their systems far more agile and, if your BPM platform allows it, adaptive….This must the goal for BPM moving forward…

Adaptive BPM…No Mapping tools…

I have had many a conversation with Max J. Pucher with regards to processes, definitions, traditional BPM, maps, UI’s etc etc. Many points on which we have agreed, and many we haven’t. However, discussion is good for the soul but also in expanding your thinking – nothing is better than bouncing ideas off of another person, and I have found that some of Max’s comments and blog posts (you can read his personal blog here http://isismjpucher.wordpress.com/) do challenge my own way of thinking…

One of the key areas and things he talks about is “adaptive processes” and how processes can be spawn without a traditional BPM map, adapting based on user actions or requirements (when authorised). This effectively allows a new variant of processing to be created at a user level, based on their requirement to process that particular piece of work, there and then…. Now at first I didn’t really follow the points being raised that well, in addition, I couldn’t really grasp the real benefits, all I could see are the negatives. However, this has got me thinking more and more, and how potentially this could work with our own workFile ECM BPM implementation…

Intelligent Maps…

I am a strong believer in intelligent maps, allowing developers to define the actual engine of the process and therefore giving them all the tools they need to integrate the solution with other LOB applications, making the BPM solution ultimately more powerful and useful to the end user. I am not going to change my thoughts on this. However, with intelligent maps I propose that the “map” is the driver behind the process, yes, but this is more of an “engine” rather than the complete car, so to speak…Many BPM products place far too much emphasis on the process map and the business analyst who is trying to define the actual process, for me this is far too restrictive and reduces the intelligence within the actual processing engine (or map) and its capabilities to integrate and automate…

However, Max comments and blog posts have got me thinking, can an intelligent map be adaptive at run time? Can an intelligent map allow a user to spawn new variants or sub-processes?

Adaptive intelligent maps…

Let’s work on some assumptions (I know these are great, but we need a point to start). Let’s presume that 40% of a process has been mapped out in full by a BA. This has been translated by our developer on our BPM platform as an intelligent map, and our BPM solution is running fine. Lets also presume that allocation to “unstructured” case management makes up around another 20% of our requirement. This leaves 40% of a particular group of processes that have slipped through our system to an extent (they could always be assigned to our unstructured case management). As Max explains, in his posts, an adaptive process can cater for the rest, effectively allowing these new processes to emerge from the designed or identified process (by our BA).

When you think of an adaptive map / process in this context, you can see there is real potential and benefit to this “adaptive” thinking…Though I don’t subscribe to everything “adaptive”, I do find this idea of “emerging” processes very compelling…

Where does it fit? Lean? Adaptive? Traditional BPM?

So where does “adaptive” processes fit. The answer, I am not sure. However, it is obvious that adaptive has a lot to offer and bring to the BPM market, more so than Lean for example. With this in mind, only this week I started to get our technical director looking at how we can make our own BPM and intelligent maps more adaptive, responsive and able to provide the capabilities for new processes to emerge….Though this isn’t the complete “adaptive” picture as Max paints, I feel it is a step in the right direction and one that brings benefits from the “adaptive” and “traditional” BPM corners…In addition, can ECM be more adaptive? The answer, YES….