I received a comment on a post from last February. In part, Hiram asked an interesting question:
"We want to start process mapping but just don't know where to start. ... Can you recommend any good resources (books, papers, websites, etc) on process mapping that give a good description of the OVERALL process? I'm especially interested in knowing what to do after the process is mapped."
A fair overview can be found in the Wikipedia entry for Business Analysis.
Office processes can be mapped and improved just like the manufacturing flow can be mapped (the later being called a Value Stream Map in many cases).
There are actually a number of techniques and graphic conventions for doing a process map. I used to consult and employ IBM's DesignFlow conventions. LEAN manufacturing advocates use mapping symbols similar to those in Gary Conner's book Lean Manufacturing for the Small Shop. Some advocate using industrial engineering standards, like ASME Standard 101 Operation and Flow Process Charts.
A common characteristic in these techniques is the identification of transportation of work, delays, and queues (or storage). If you have a "lean" orientation, transportation and waiting represent prime targets for elimination (just a few of the wastes to be reduced).
As this paper points out, there are a handful of reengineering methodologies, all have a similar framework. In Short; Plan, As-IS, To-Be, Implement, Measure Results, and Repeat. The charting techniques usually play a major role in the As-Is phase.
Just mapping the process tends, in practice, to be a flowcharting exercise. It isn't always done to a very great depth but it should be as deep as possible. One trick is to use swim lanes for each actor or role. Then display the process steps in the respective swim lanes. One lane might be the receptionist opening the mail and sorting it into stacks (probably at her/his) desk. Then a clerk (another lane) picks up the stacks and delivers the mail to various inboxes. The inboxes each have their own process lane.
It doesn't take long to have a complicated diagram, but that's OK. It forces you to ask the question, why is the invoice bouncing around between these various departments?
Identifying the problem is only half the journey. Creative solutions and getting at the root cause of some procedures (we've always filed the fly-paper report etc) takes team work and brainstorming. But if you don't take the time to do the As-Is you'll miss a lot, and probably doom your new system or procedure because you've left something out.
Case in point: streamlining the process by having the receptionist do data entry, but forgetting that John in distribution adds a tracking number that is the database "key" for the (separate) distribution system. The receptionist may need to have access to the distribution system.
Ran across this bibliography, fairly impressive list. Some have links to other sites. It is part of the National Archives Site (NARA ALIC). Plenty of literature on Business Process Reengineering / Change Management in the bibliography.
My temptation is to say start with a process you can change, i.e. you have the signature power to make it happen. Decide what metric will define success (time, quality, waste etc). Don't leave the key measure of success to a vague "improve the process."
Then work it as a team. Everyone knows a secret part of the process that some people don't know. Your getting close to success when someone says "I didn't know that happened in xxxx, I thought yyy did it."
The more people know the whole picture, the better the redesign/improvement will be.
