We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Is orthodox flowcharting nearing the end of its usefulness for BPM?

Vote 0 Votes
As Max Pucher writes in this excellent blog on the necessity of failure with IT, "Let's face it, orthodox process flowcharting won't survive the social and mobile revolution."  What do you think?

14 Replies

| Add a Reply
  • Probably not...

    There are lots of processes that require orthodox process flowcharting, the difference is now we also undertstand that there are many more processes (probably around 80%) within an enterprise where such process flowcharting doesnt work...

    That being said, I still find flowcharting useful in understanding the general jist of processes, and thats very important when you start looking across a complete enterprise...Im not saying these flowcharts should be used to build regid processes, rather they are loose flowcharts that enable us humans to quickly grasp whats going on within a general business process. The actual implementation (I strongly believe) needs to be adaptive and easy to change, when tied to flowcharts this doesnt happen...

  • I am not sure what Max means by 'orthodox' but flowcharting will not go away. That is like saying people will stop using Excel - people will find different ways to use Excel. And, they will find different ways to do process flowcharting.

  • I don't think the quoted phrase implies the current "usefulness" of sequential flowcharts:-)

  • Flowcharting won't go away, but the tools to accomplish it will continue to diverge based on purpose. The biggest part of flowcharting to date has been, "What do you do with it once you've captured all of that information?" The answer, for the most part, has been either to automate it or just hold onto the file until it needs to be updated. Both answers miss the point of having data that can be stored centrally, owned by relevant parties, and then distributed to the masses as a single source of truth.

    Flowcharting as a means to an end is alive and well, but flowcharting as the end product is gradually losing value as products come along that offer something much better than symbols-within-documents.

  • The referenced blog post really is an excellent post. He rightly takes credit for being more productive than other engineers by _not_ following the prescribed procedures for debugging the early mainframes.

    From this, I believe he draws the wrong conclusion. He believes that all formal proscriptive processes are bad (i.e. "flow charts"), and that every one of the 1000's of people trying to provide technical support should be free to use their own intuition and gestaltist understanding of the problem to quickly come to a resolution.

    You can probably see the problem. Unfortunately, not everyone is that smart or that skilled. The right conclusion to draw from his story should have been that _his_ methods should have been formalized into a repeatable process, so that all of the support staff could have been as successful as him.

    With the right tool, subject matter experts in numerous disciplines should be able to capture their knowledge into processes that can be followed by their less-skilled fellow employees.

  • Think most have missed the point. Max makes a specific reference to the social and mobile revolution on purpose, and most comments here have missed that and focused on purely the defacto methods of process mapping and it's current value in current contexts.

    Yes, orthodox flowcharting will still remain simply because the level of process and BPM maturity across the World right now is nowhere near where we want it to be to adapt to social and mobile concepts. But I really want it to evolve, and fast, but we're being constrained not by ideas but by vendors who simply don't understand the full extent of where social and mobile can take an organisation, analysts who want to keep us in one place because they can't evolve with it, and clients who listen to the analysts....

    I keep saying it goes well beyond adaptive case application and further into organisational makeup and flexibility. Like I've written before, you can't take 21st century ideas and expect an 18th century draconian business operating model to fit.

  • Absolutely agree with Max.

    It's about the results for your customer(s).

    When you should have followed your customer request like a gps, ofcourse you will see every result has been created by a process (sometimes process mining techniques are used for this)

    But a process might not be known upfront. Within boundaries of law, company strategy, I think it is very sound to let employees be creative and responsible as long as they deliver the results within the goals set for it.

    Ofcourse there are more processes then in this "knowledge world". You can imagine that some production processes need some tighter steering as they create a real tangible product instead of a collection of information.

    So every process has a result, but whether you can define the exact process upfront depends on the business you are in.

    Who was talking about flowcharting here?

  • I remember my first Chief Programmer saying to me "don't do: document" as I blithely fix bugs without creating a ticket.

    If I might be so bold as to bring his maxim up to date "don't document: automate".

    So in the sense of an orthodox approach, I agree, flowcharting is well past its time because in modern process automation tools, the process design is the execution template. When one changes the the design one is changing the executing process automation. This is the only way we can keep up with the dynamic changes happening in the business processes.

  • 1. I'm glad Max said "outside manufacturing." That's still a big part of the business world that many people in our industry (and posters here) ignore.
    2. There are also many regulated/financial/fill_in_the_blank processes that in my opinion are not a good fit for this bold new world of "flexibility."

  • I don't think that flowcharting as an activity will go away. The question is WHO is going to do flowcharting? As IT systems continue to get more complex, programmers and system architects will continue to use this technique. More and more, BPMN is becoming a programming technique.

    But if you focus on business users (which is the central point to Max' post) there is plenty of evidence that the flirtation with flowcharting for office workers is over. It is not a natural act for a business person, nor does it need to be. There are more important considerations. Twitter does not need flowcharting, nor does it need complicated "business rules".

    It is also true that the Agile approach to managing complex projects prioritizes creative-re-work over specified do-it-exactly-once, and another trend we are seeing is that social business is enabling far greater projects using an Agile approach. Retroactively review what process you went through, but don't bother attempting to draw one up front.

    So I agree with your proposition if you change one small thing: Is orthodox flowcharting nearing the end of its usefulness for BUSINESS USERS describing their own work.


  • Great question, as I sit here looking at an incomprehensibly complex flowchart a client provided me that describes a "standard" order intake process. Flowcharts are terrific tools for describing specific, homogeneous and repeatable processes. But when used ubiquitously, for dynamic systems or complex workflows, their static nature makes them inconsequential and often ignored. This is exacerbated when the necessity of human interaction, analysis or judgment enters the project or workflow, with its inherent need to capture the learning value of collaborative, social and continual process improvement and intervention. A telling way to check the applicability or usefulness of a flowchart is to ask a business user to look at one and then see how long it takes them to discern the process the flowchart attempted to capture. If it is a process in which that user is actually a stakeholder, the second question, if you haven't already lost them, is how well does this portray what you do today? In my experience, 75% of the time the business user needs several looks (and rotations of the flowchart) to determine the process being described. Worse, 90% of the time they'll tell me the process does not even come close to outlining what they actually do.

  • Thanks for all the valid comments and different perspectives and for those who went through the trouble to read my long posts. Therefore it is hard to capture the gist of it in one line, but it is interesting that it was this line that was picked up and commented on all over the Internet. This means that there is a valid consideration going on regarding this subject.

    I disagree with Michael Rowley that the knowledge process of complex problem solving or innovation (or any others for that matter) can be captured in a flowchart. That is exactly how IBM had its support manuals structured: We had to follow a flowchart and yes, a percentage of problems could be solved this way. But this is a kind of manufacturing process too. My job in Havant was too in manufacturing and it was impossible to put my way of doing things into flowcharts. Today, I can neither put the work of my software designers, developers, consultants, sales and support people into flowcharts. A tiny percentage of our admin work could be flowcharted and even there the exceptions are numerous.

    Yes, there are 20% of processes in a business than can be flowcharted AND will work this way. Flowcharts can be practical as high-level representations of connections between capabilities in end-to-end value streams. And so forth. There are manufacturing or like production processes.

    But the key point I am making is that flowchart-controlled processes do not assure goal and outcome achievement and are way to hard to adjust as needed for innovation and hitting objectives and targets. Thus they won't survive as a design means for processes in the social and mobile dynamics. I think they are practical as a view of how processes WERE/ARE BEING executed and COULD BE executed, but not as a means to control their execution. OK, so they won't disappear per se but they will no longer be the main means for a process creation effort.

    'What will be?' ought to be your next question and it has to be a business architecture, balanced scorecard, goal-oriented design effort that has to be made transparent as input to the people who will actually execute and create and adapt their processes on the fly. Because they too are made transparent (possibly as flowcharts too), process owners, management and executives can collaborate in adapting to meet the business needs.

  • I really love flowcharting. I've been on training for a mapping tool and now I earn a lot of money with flowcharting for my customers. The slogan of my proces improvement consultancy firm is:

    "On paper we will make your processes very efficient. The flowchart fits on one sheet"

    Happy flowcharting! ;-)

  • Come on Emiel, be more serious....

    I think companies must not forget the most important aspect of a process is it’s execution. That is where the results for your customers are created. And ofcourse most of the time this can be done better, but what I see often that “good” isn’t even defined.

    What do you need a flowchart for if you don’t even know if a process performs bad? Just for fun?

    So my initial steps would be
    -Define the result (for your customer) of the process
    -Define the goals belonging to this result (time, costs, quality)
    -Decide whether this process needs attention or not (do you have this information to make this decision?)
    -If it does, try to find what makes this process perform bad

    And sometimes I use a flowchart to get to know the flow of work (for my customer!) .

    But the causes of bad process performance might be in many other things like information, business rules, human resources, steering, supporting systems etc.

    Process management isn’t as easy as a flowchart might look like.

    Mmm new slogan for my company….

    “A process. Isn’t that just blocks with arrows between them? “

Add a Reply

Recently Commented On

Monthly Archives