Start a Discussion
BPM
user-pic

Is process documentation a waste of time?

Vote 0 Votes
As Theo Priestely writes here: "if you were new to the world of process and heard that a competitor took several years just to document their processes but not do anything clever with it you'd either walk away despondent or rubbing your hands in glee at their sloth." What do you think?

15 Replies

| Add a Reply
  • I totally agree with Theo's point: "If you can spend time designing and capturing process artefacts in a repository you might as well do it in something that’s going to allow you to drive that benefit even further."

    In software development the term overengineering refers to unnecessary development work that is being done by developers that have the tendency to implement unnecessary abstractions. This is often done for good intentions to make the sofware better or cleaner.

    I believe the same principle applies to business process modeling. A lot of BPMN modeling is done for the sake of creating a nice looking diagram. Too much effort is spent on figuring out details and things like exception paths that often require an ad hoc solution.

    For many processes, there is no need to start with a long study. Just get going and automate the basics of the process. Then apply small improvements as you go.

  • We are going back to basics as understanding the process becomes essential for all players in the business. However creating a standalone document reflecting the view of the author is only valid if users agree and there is something in it for them i.e. not just another IT management fad that has little meaning to them?

    However if the process is displayed in an easily understood graphical picture which is the process and can react quickly to change then their interest may become real. Such collaboration on the process and its future has benefits for all. Users will become empowered as the process becomes theirs. The business has clear ownership of knowledge not just the process outcomes but how the process actually works; not just as in depicted in a one off static version?

  • One has to define what process documentation means.

    The main reason that companies are documenting processes is for compliance and because the audit people want to look at them. Everyone knows that the processes are not executed as documented, because the business would simply not work. It may be a waste of time and money but it is hard to bypass those requirements.

    If it is the upfront as-is analysis that is then used to create a to-be definition, then it is mostly a waste of time and moreover a waste of money. First of all the as-is will not be complete and second, the to-be will be wrong.

    What an adaptive process approach enables the business to do is to create an infrastructure that allows each department to define its work goals and then simply add tasks, dependencies, content and rules until the work to achieve a goal has been performed. Yes, rules may be not done by the everyday business user. Then one can save the work performed as a process template. Bingo, here is your process documentation.

    And not only can you modify and adapt the process conintuously, but for each actual execution there is a perfect audit record that contains the flow-diagram of what ACTUALLY WAS performed in this process when and by whom. Documenting processes up-front becomes completely unnecessary.

    Well, if you have this piece of process where you must enforce compliance or where systems require certain orchestration, feel free to define it upfront and lock it against modification. This goal-achieving process fragment is now fixed and maybe mandatory but all other elements and pieces of the complete process remain flexible and adaptable.

    So yes, standalone and generic process documentation is a waste of time, but depending on how bureaucratic your business or the regulator is, you may have no other choice than to do it.

  • Theo has a point. I recall he has mentioned something along the lines of "by the time your BPM activities are 'done', the market has moved on." As a proof of concept or even part of business as usual CoE activities, there must be a better way to carry on showing immediate results on a regular and not focusing on reports and other menial 25 page reports on the feasibility of adding an additional activity to the process.

    We have to pick our battles to bring BPM forward.

  • I'm going to stick my neck out there and suggest that process documentation isn't a wast of time. I'm not suggesting that organizations engage in the interminable BPI efforts that we all observed during the 90's.

    However, without documentation, you don't have a baseline. Without a baseline, how do you determine ROI?

    I would argue that you can't! Hence documentation, even that outside of SOX 404, ISO 9000, Basel II requirements, are essential.

  • Absolutely agree, but have been declared a fool so many times on Linkedin discussion about this opinion that I almost started believing that documenting processes is really something you can't live without...

    'But you have to know the as-is, before you can improve and implement a process'. Yes, and, as stated above, at the time you are ready all your customers are gone.

    Turning 'has been' process maps in 'nice to have' process maps. That's not BPM in my opinion.

    BPM is daily business. Treat it that way. Make people aware of your processes, it's results and goals. Give them the freedom to act. And if they think they need to document a process for that; ok that i probably has value.

    But also as said above. Most visio-therapists are not interested in executing processes, but more in collateral damage that comes with doing business, like compliance, audit etc. If you will get in jail when you not document your processes; just do it and live on.

  • Nothing much to add here except to say that make this subject a part of your selection criteria when you purchase your BPMS. And if you already have a solution in place make sure this is the top of mind on your vendor's road product road-map. We don't like to read documentation so let's do everything we can to make sure our process models are (and I know the perfection of this particular grail still eludes us) self-documenting.

  • The Process documentation effort, done in isolation, without linking it to the enterprise transformation process on tactical (to improve operation) and strategic planes (to achieve higher goals) is wasted.
    Also processes are changed by changing the resources that execute them. The people and technology layers must be included in the documentation because today one changes applications rather than just processes. An abstract process description is a job half done.

    The process documentation is necessary but in the context of a grander effort of transformation which includes the people organization and technology alignment.

  • Look I’m all for documenting process for the arguments stated by DeHenry, Kelly and the rest. Peter, a follow up question to this would be, to see people’s thoughts on documenting processes and procedures. As of now in my organization we have had big debates on this issue. Regulators want procedures, and some want both processes and procedures. I am of the opinion that if a have level 5 process maps why do I need procedures? It’s a duplication of work which we work so hard to eliminate waist. Unfortunately regulators and auditors are winning the battle, and my team is documenting processes and procedures.

  • One other thing I would like to add regarding Theo’s comment. When a big organization documents processes and they do not use them. This organization is not a process centric organization and they were probably following a consultant recommendation with no idea on Why to document the process? and the purpuse of processes :)

  • Can I suggest that the question could be; how do you short-cut the documentation to match the execution cycle of a process model?

  • Process documentation, is extremely important, however, organisations do a phenomenally poor job of maintaining it. and that is because the lack of documentation is only typically noticed when the situation becomes critical. e.g. training a new employee, regulatory or financial audit, processes are outsourced, a system needs changing.

    Process documentation is seen as a best, endeavours exercise, rarely ever as a mission critical task, unless some significant event occurs as noted above.

    However documentation comes into it's own during times of change, system change, personnel change, ownership change such as outsourcing. In all of these scenarios it is almost impossible to implement the change with out having an accurate view of the process. The lack of up to date documentation usually results in large effort by HR, IT or external consultants to come in and update, rewrite, or recreate documentation, often at great expense.


    Currently most organisations update documentation only when required and for the most part that is a pragmatic approach, with the resources available and the other priorities vying for time and money.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT