Forums

How do you create a business process work flow? Are there any special requirements/best practices? Seems pretty simple to me, but maybe I am missing something.

In a recent O3 with my boss I was describing a goal I had rolled-down to my staff: specifically, creating a business work flow for the design process - aka all the steps required to get a project from concept to construction. (I am a civil engineer so think water and sewer pipeline design if that helps.)

My boss asked the question: "Do your staff know how to do a process work flow?" I was taken aback for a brief second because I have never had any training in this, but have always thought it to be rather simple and intuitive. I answered, "If not, they will by the time we are done" - which assumes I know how to do it.

My thought was to simply have my staff 1) meet with everyone involved with various steps, 2) build a list of all the steps, 3) figure out predesessor/successor relationships, 4) create a flow chart of actions, probably including some deliverables, milestones, or phase gates, 5) assign RACI for each action, 6) include typical durations for certain steps where relevant, 7) have all relevant parties review, 8) repeat any of the above steps as needed, until 9) the trio I assigned it to reach consensus, I approve, and my boss approves. The only challenge/difficult task I see here is managing people drama - which is part of management skills I expect of the staff I assigned this to.

Am I oversimplifying?

"Do they know how to create a business process workflow?" - My first thought was actually, "Doesn't everyone?"

I don't think this is a quick/short task - but it seems like something that uses only basic management skills.

Am I missing something?

Andrew J Baer's picture

My first thought would be that it's probably been done by somebody else in your company before, hopefully by the same department.  You can also give a confirmation brief to your boss in what you see as involved with the task.  

Otherwise, it sounds like you're already on the right path based on my own experiences.  Just give your staff the What and the Why, ask for input.  If everybody seems on board, then formally give out the task with the full 5Ws.  If you get a lot of blank stares or strange answers, have a little quick coaching session with the group. 

Hope that helps.  Please, let us know how it goes. 

rgosden's picture

Yes, it sounds easy enough to do. However.... As soon as you actually talking to people things will go awry. Two people doing the same job will give you two different versions of how thingvs work. You will find someone creating a document thinking it is used for a particular purpose, with the recipients having different ideas about its purpose. You will find gaps that are papered over by hallway conversations. You will find several people extracting the same data from the same system and then using it to make conflicting decisions. And that I'd just the happy path! As soon as you have to account for rework, special cases, vacation coverage, etc. you will be thoroughly into spaghetti land.

So: be prepared to have multiple discussions with many people, and also be prepared to have to rework some portions of the process.

cruss's picture

I have been given a similar task to document some of the processes my team engages in (Application Support and Administration) and have found there is an important distinction to make between making a Process Flowchart and a Action Checklist. The process flowchart should show the "high level" process, usually laid out in a series of boxes and arrows, as each part of the process progresses into the next. This concentrates on decisions, inputs, outputs, and ultimately deliverables of the process. Then for each of those boxes that represent someone actually doing work, there can be a checklist of the steps they take to do that function. If can be a somewhat complex checklist with a few 'if this' statements. If you get to that part and seem to need a separate flowchart for all the possible branches that action requires then you may not have broken down your original process into enough detail, or it really may be your process touches on another one that needs to be flowcharted and documented separately.

I have seen people in the past make the process documentation too complex or hard to follow when steps that need to be in a checklist try to show up on the overall flowchart. Separating them keeps the process flowchart readable while allowing the detail of the actions to be documented as well.

Good luck!

Canyon R

mtrowley's picture

The Environment Map is a simple technique a colleague of mine developed a few years back, and is based on the IDEF standard, but is mega simple and can be done by anyone with a pen and paper.

Using the headings;

  • 'Input'
  • 'Output'
  • 'Mechanisms (people, systems, tools)'
  • 'Controls'
  • 'Infrequent requests for assistance'

You can write them, or I like to put them into something that looks like a flow charts on a white board so they are easy to see (doing on your own, a large piece of paper is still best).

Seperately have the headings;

  • What works well
  • What needs attention

Information is best collected in a group enviornment, and you can ask people either to silently write on post it notes, or you can ask people to shout out their ideas and thoughts and you fill in those things. Most are pretty obvioius, but note, 'Controls' are things like policies, governance, regulations etc. and 'infrequent requests for assistance' might be things like calling on facilities to book a room, or HR to deal with a grievance issue.

This can be done at any level from an organization through to a single process. But I would suggest starting with the whole team at a high level. This will help you priortize your improvement efforts.

For example, if, as a result of this activity, you find out you have 10 processes, and 2 of them are causing 80% of the problems, you can do a detailed flow diagram of them (I like swimlane diagrams as it makes it clear who is doing what, gives a sense of timeline, and no specialist process modelling skills are needed).

In any case, if you ever draw a box as a process step, I suggest using 'verb' 'noun' structure e.g. 'Create Report', 'Update Customer File'. You can put an easy check in by using the words 'To' and 'The' e.g. To Create The Report, To Update the Customer File. I've seen some horrible process maps by ignoring this simple standard.

Hope that helps.

Thanks

Matt

techmgr's picture

I create and manage IT processes so here's a few things to think about from my experiences. It might sound obvious that everyone would know and agree on the purpose of the process. But until you have to put it in writing, expect to have many different opinions. The performance of the process against this purpose should be easily measurable. Again, expect highly variable understandings of words like "fast" or "efficient". Be careful around hand offs. Paper handoff? What box does it go in? Ticket handoff? Do the teams that interface in the process both use the same ticket system? Do they actually check their ticket queue often? Who's responsible for the completion of the handoff? If Team 1 sends an email that their part is done and that Team 2 can proceed, and Team 2 never acknowledges, is Team 1 responsible to follow up? Finally, who owns the process? What single person is accountable for the end-to-end workflow, for making sure that the purpose or objective of the process is continually met within acceptable levels of process performance?

if this sounds overly complicated, that's only because a process requires people. And people are complicated and have many other things to do. One more thing - aim for getting it 80% right at the outset, and schedule a future review of the process to make adjustments after people have lived with the process for a while. 

Jeanne