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?

    Process 2.0 – Collaborative and Adhoc

    Most Business Analysts have a reasonable idea about how to develop a Business Process. We don’t all do it the same way (far from it), however the general approach is usually much the same, it goes something like this…

    1. Gather requirements from the business
    2. Design and validate a process model
    3. Implement the new process with the business
    4. Move on ..

    What will this look like in the world of Process 2.0?

    I recently asked the BPM Collaboration community about Process and Google Wave (check out the forum thread to follow the discussion). Bernie Clark provided me with a link to a great YouTube video prepared by the SAP Research centre, it is titled “Gravity, the best example of Google Wave”. This is well worth 7 minutes. Well done to the research team for a quality presentation.

    Using this kind of collaborative process development, the Business Analyst becomes more of a facilitator and educator about the way to build processes, without needing to get too involved in the business. With this kind of approach, an organisation would be capable of developing and deploying Business Processes in record time!

    Add to this, adhoc process modelling. This concept, introduced to me as a new feature in the webMethods 8 product suite, provides the ability for knowledge workers to model processes as they are being executed. Generally there is marginal value in mapping a complex process that is not executed regularly, especially where human judgment is involved!

    However, if you can capture the process as it is completed, then you can measure what has been done and learn from the experience in the future.

    My first reaction to adhoc processes was, “It is hard enough to get people to map processes and execute them, what incentives would be needed to encourage adhoc mapping?”.

    What if we mixed both collaborative and adhoc process modelling?

    Free BPM?

    A post on the BPM Insights Blog listing Free BPM Modelling Tools recently caught my eye.

    Firstly I thought it would be good to have a simple list of all of the available tools, so I have compiled a list, see the Process Tools (Free) category on my Process on the Web page.

    Secondly, it would also be good to compile reviews of these tools, as I have found it difficult to assess the value that I am going to receive using one of these tools. Therefore, I will be looking for existing reviews, or to review some of the tools myself, in upcoming posts.

    Do you know of any free tools that I should add to the list?  Or do you have any good reviews (maybe one you wrote yourself) of a free Process Tool?

    What should come first, AS-IS or TO-BE?

    Most process modelling methods start with analysis of the existing processes, an as-is model.  One of the challenges with as-is modelling is deciding how much work to do.  Very detailed as-is models can be time consuming (costly) and may drain the organisations tolerance for Process Management activities very quickly.

    As-is modelling can also be quite hit-and-miss as the analysts try to decipher what the current process actually looks like, this can often be because there is not a single as-is process, there are many.

    The main purpose of an as-is model is to give a Process Project the information it needs to work out where improvements are needed and what is the starting point for change?

    On the other hand, to-be modelling is a description of future desired processes. To-be modelling requires analysts to be creative in solving problems and designing processes to achieve business outcomes, often with not so perfect information about what the organisation wants to achieve.

    I find it fascinating to sit in a room and watch a selection of staff have a to-be model presented to them, you can see the defences rise – and everyone thinks it is not going to work – for different reasons.

    So it doesn’t sound like either will work? not true.

    My approach is to start with high-level to-be modelling. This often involves developing a future state, Process Architecture – aligning the organisations strategic goals with it’s process management goals. Further detail can be added about key processes in the form of IGOE Process Scope models  (more on these in future posts).

    When agreement has been reached on the future state, then we can go back and look at the as-is. This is limited to the processes that will transition into the new architecture and only to the level of detail required to find the areas of process improvement and develop the change plan to implement the new to-be models.

    With this approach there are plenty of stops along the way to make sure that everyone is in agreement.

    When you do Process Modelling, which type of analysis do you do first? How effective is it?