Successes in Process Automation

The Adelaide BPMLink presentation this evening provided an interesting insight into achieving process improvement through the implementation of a technology platform and the adoption of dynamic processes. I have previously written that I do not favour either of these approaches; however I am having a re-think!

Jane and Marc from Bradham Consulting discussed a process that they successfully implemented using the Handysoft BPM suite and more specifically utilising the BizFlow Office Engine. The business process dealt with very sensitive material that needed to be handled differently depending on the nature of the content; dynamically determined tasks allowed for each instance of the process to be automated while still being controlled and audit-able.

One of the lessons learnt from this exercise was the need to also educate the participants in IT to ensure they have the required level of maturity. I have often through that a big part of the facilitation activities for improving processes is to educate the participants on process management thinking; IT is now an additional important step.

Marc gave us another tip – to help the participants understand the process; get them to draw it.

The team mentioned that there was a large amount of effort put into developing the forms, including incorporating the “reality” processes that were not part of the original analysis. This mirrors my own experience, where I have seen traditional BPMS solutions full short because they do not handle the interface between the user and the automated process – and that is where the majority of the business rules and logic can reside.

My final thought was that the project demonstrated a good use of technology to solve the business problem; which was not necessarily improving the business process. BY doing this well, the organisation is now better equipped to embrace real process management. I’m shifting my approach, how does this compare to yours?

Avoid creating more Corporate Debris

It would probably not take you long to look through the records of any organisation and find some items, probably lots of items, that are Corporate Debris.

There are two types of debris left behind by projects, specifically by Process Projects;

  1. Process models, descriptions, requirements, design, strategy and good intention that have never been utilised, and
  2. Previous versions of the above artefacts that have been replaced or updated; however the original versions are still being used or are accessible within the organisation.

I have seen too many examples of enthusiastic projects that have created a new process, procedure or strategy that has not been adopted or sustained in the business after the project has been completed. I had one experience where I was shown a department’s “Process Library”. It was sitting in a series of well presented folders in a small cupboard in the Directors office – that’s as far as the project had got to real change.

The best case scenario is that a lot of money is wasted as the project has clearly not achieved it’s outcomes; however the more common worst case is that the opportunity lost is followed up by disappointment and scepticism that a process project can never be successful.

The end users are often victims of corporate debris as they find various versions of “the truth” in knowledge libraries and they struggle with which processes or work instructions they are meant to be following. If there is a renewed attempt to improve the process, they will often start from step one because no-one is sure which of the previous versions of analysis to use and just how correct were they?

At the 2009 Process Days conference I sat on a panel that discussed the value of Process Modelling. My contribution was to state that process modelling was only valuable if creating the models generated share understanding and the result was actually going to be used. I asked for our process models to be living.

I wish I had found this George Box quote last year, “All models are wrong, some are useful”.

How to build “living process models”

There are a number of simple Information Management principles that should be applied to organisational information like;

  • Recognise corporate information and manage it’s lifecycle – Creation to Removal
  • Be ruthless – Just because it is stored electronically, it doesn’t mean you can ignore it!
  • If it is important corporate information – hold someone accountable for managing it!

    There is much more that goes into an Information Management strategy; however that’s another Business Process for another article!

    A living process model is a representation of your Business Process that is constantly referred to and updated by the people who are living and breathing the process. If I ask anyone who is involved in the process what documentation are they using to guide their work; I should always be pointed to an artefact that is linked to the current Business Process model.

    Keeping Process Models up-to-date is often an issue. The workers are not going to maintain the process information if an update involves a 12-week review cycle. Imagine a world where the living process can be updated within 1 day, with 1 reviewer!

    There are 2 keys things that are needed to achieve living processes;

    1. A process modelling platform that allows you to publish the current process diagrams to everyone, with all of the relevant information relating to actually doing the process activities, and a process to keep it up to date.
    2. Adopting enterprise processes to design, share, improve, measure and be responsible for all living business processes.

    It sounds easy? What would you need to do to bring your business processes to life?

    Why Processes need Projects and Projects need Processes

    In a recent post, and some back and forth with The Process Ninja, we discussed the Good and Bad of Process Projects; this led me to think about my days learning about process and projects, both of which I am quite passionate about.

    Whether you call it a project or not, the only way to make a significant change in an organisation is through a project, as defined “A temporary endeavour … undertaken to meet unique goals and objectives”; however I believe a project is not where a Business Process is made!

    How are Business Processes conceived and enacted?

    Business Processes have existed in organisations forever, and they will exist regardless of any specific Process Management activities. A Process Management initiative is about improving the way a Business Process is defined, resourced and operated. Therefore, a process project is really about creating capabilities to support the Business Process, not the process itself!

    A common theme across my favourite BPM methodologies (Process Renewal Group and BPTrends) is that;

    First the organisation understands it’s processes at the enterprise level;
    Then, governance at the enterprise level decides to improve a particular process;
    A process project is born.

    Contrast this to a more traditional approach, where a project is created to improve an area of the business and one of the many outputs of the project is to model the related processes!

    So what’s the difference? Firstly, improving the Business Process is why a project exists – so doing process analysis and design is fundamental – not just another output, then once the to-be future process is well understood, then the project is about building capability. This is why a project is necessary – we are changing the organisation to be able to enact the new process!

    Roger Burlton defined six areas of capability that projects build to support processes, they are;

    1. Human Competency
    2. Business Rules
    3. Organisation
    4. Facilities
    5. Technology
    6. Motivation

    The outputs of the project are to build the required capabilities to support the business process, e.g. The required people skills, decision model, organisational structure, capital equipment, computer systems and reward structures that match the requirements of the business process.

    This leads me to a key point; A project does not implement a Business Process; instead the organisation uses the outputs of the project to execute the process the way it has been designed!

    • Projects are created to improve a Business Process (or part of one).
    • Project OUTPUTS are the capabilities that support Business Processes.
    • Improved Business Processes are OUTCOMES of Projects.

    Have you found the Problem?

    On one side of my world is the process management brick-wall, the other side is the chasm of process theory. Criss-crossing the terrain are the fast flowing reality rivers. This is often what it feels like when I am trying to get buy-in for developing a Business Process Management program.

    Why is selling BPM so difficult?

    Over the past few years, nearly every BPM conference, user group or meeting of the Australian BPM Roundtable has had a session about executive buy-in, selling BPM or simply, Why don’t they get it?

    At the February Australian BPM Roundtable, Andrew Spanyi gave an interesting presentation on Leading Process Change (registration is required to access the BPM Collaboration.com site). One of Andrew’s rare practices for leaders is to have A Compelling Case for Change. Too often BPM is interesting but not compelling.

    What is often compelling to leaders is single-points of process improvement; I cannot change the organisation – but I can fix the process in front of me. Andrew covers this in his summary, “No one single successful process improvement, innovation or transformation effort is likely to convey lasting competitive advantage; Process Management across the enterprise does!”

    Therefore, there needs to be a compelling reason to do Process Management at the enterprise level – which may be much easier to find in a struggling organisation than in one that is already successful. So what are some of the common problems the may be compelling?

    1. A desire to create “one” organisation – when it is recognised that silos of operations are dysfunctional and there is a desire to create consistent processes across the organisation.
    2. Reducing costs – when there is a need for far cheaper processes.
    3. Improving customer value – often after a poor customer satisfaction survey identifies the need to vastly improve the service and value being delivered to customers.
    4. Poor financial or sales performance – a need to adopt a different approach to save the company!
    5. Increasing visibility – executives want increased visibility of the performance of the organisation, usually coming from a renewed strategic approach.
    6. Fad – a desire to implement process management or a process management system to be adopting an architectural or business approach that is thought to be desirable.

    This was just a short list off of the top of my head. I want to explore this further at the Australian Process Days conference “birds of a feather” sessions; please add a comment; sharing problems that we an discuss at the conference session.

    Finding the Business Problem

    One approach to finding the business problem is to use an analysis tool to understand where your organisation is and where do they want to be, in relation to Business Process Management. The measured desire for change can represent the problem to be solved.

    One way to determine the desire for change is to conduct an audit (survey) of key stakeholders and use the information to develop a process model, where is process management in the organisation today (as-is) and where do we want to be (to-be), what are the requirements (KPI’s) and what change is needed to get us there (the process project).

    This can be done using an existing BPM Maturity Model, which is not an area I have had much experience in; however my initial experience has been that finding and adopting a suitable tool is not easy; either to find or to use. What’s your experience?

    Good Projects versus Bad Projects?

    A passionate spiel from The Process Ninja entitled, “Lessons from a Process Project Failure“, hit home with me as I was reading it today. Craig has reflected many situations that I have also experienced with projects, especially the paradox when a project is celebrated as a success when the end result has been less than ideal.

    Don’t get me wrong, I think it is important to celebrate the achievements of the organisation; however the issue is that the lessons are not learnt and the failings of the project are destined to be repeated.

    The most disappointing project failures I have seen have been where the initial benefits sought included a strategic vision that the new process would be delivered to increase customer value and maximise enterprise value – by the end of the project both of these ideals have been de-scoped and the organisation is often left with another process implemented in isolation, committing the organisation to a maintenance and integration burden and not adding any real value to the customer. Innovation has most likely been lost to “just making it work”.

    I often start a project with big picture thinking; “What is the best way this process can be done for the organisation, the customer and our part of the business”, how do you think I go? Generally I don’t get very far, it’s a great idea to be strategic; however the project owner has already scoped and budgeted the project – there is rarely enough money or brain power to do it right. “That’s OK, we’ll pick the rest up the next time around”; but we never do.

    The worst part is that the people who are really passionate about Business Processes end up delving down into the analysis or the system and are never heard from again, paradise lost.

    There are a number of solutions to this problem, including integrating portfolios, projects and process management. The solution I will be looking at involves adopting Process Thinking across the organisation… If a project is hard, how can we achieve such a deep change in thinking?

    What does BPM mean .. in reality?

    When I use the word PROCESS in a meeting or presentation; is everyone thinking the same thing? Even when I had just put a definition up on the wall only minutes earlier?

    The answer to that question is probably: “No, of course everyone has interpreted it differently!”

    This is an on-going challenge for anyone involved in organisational change, and a key source of resistance and conflict. I think BPM is the toughest type of organisational change as it crosses all areas of the business, introduces a new way to manage what we do and a new way of thinking.

    Even on this website, I will use terminology in a different way to my peers, and it will cause comment and conflict! To help you out I have added a new page to the Executive Guide to BPM that provides a Glossary of BPM Terms in the way that I use them. The glossary will never be finished, I will continually add to it. I hope it helps.

    What process terms are causing conflict?

    One term that I have problems with is SERVICE, or BUSINESS SERVICES. What is a service? How does it relate to processes, work practices and IT systems?

    A related question was asked on the BPM-Collaboration website, “What is the difference between a process and a service?”. This generated an interesting discussion (registration to the website is required to access).

    I see a business service as a discrete function that is provided to abstract over a sub-process or software solution, e.g. Create a New User. Multiple business processes can utilise the business service without any knowledge of how it is implemented, only that it will achieve the desired result. The functional manager of the service can then change the implementation without needing to change any of the referring processes.

    If all of the functional requirements of a business process are met in this way then they become very easy to sustain; however there is a requirement for strong governance and change management to ensure each business services continues to deliver the agreed results.

    One solution to the terminology problem is to adopt an organisational Process Taxonomy, describing the meaning of all of the terminology used. When this is linked into a Process Methodology that is trained and adopted across the business, then you will have a much better chance of achieving real common understanding. My glossary may be a good place to start!

    Do you have any word based war stories to share? How would you achieve common understanding?