In December of 1983 I accepted a job offer to work for AT&T in Kansas City, Missouri. Prior to that I was employed with Southwestern Bell in San Antonio, Texas. As the old Bell System was being torn apart and the local operating companies were being separated from the System, there was shuffling employees between the two entities. It also was rumored that the organization I worked with in San Antonio was going to be moved to Houston and there was no way I wanted to live in that city. Just the wrong kind of climate for me and further from my family’s summer home in Grand Lake, Colorado.
I had just finished earning an additional bachelors degree in business with a major in accounting from Incarnate Word College. It tuned out that the Mid-Western Region of AT&T thought that was a plus for a person to manage the engineering department’s construction budget so I was offered the position. I accepted and moved to KC the first week in December, 1983.
Once on the scene in their brand new high rise building I discovered that the engineering department used a mainframe computer to do the engineering functions. All equipment, both forecast costs and actual expenditures, were in the system. I needed to understand how the system worked and how the engineers interacted with it. There was a very large three ring binder all engineers had that showed how the system worked and what and how each person was to interact with the system. It was entirely done in written text.
There was no way I could just read the binder and understand how the process worked so I scheduled appointments with someone in each group of engineers. After doing countless interviews it dawned on me that how the engineers used the computer system was nothing like the binder told them to do it. When I asked several of the men I had talked with they told me that the system, if used as designed, didn’t work for them. To be successful they needed to do workarounds and change the order of steps to get a equipment budget out twice a year.
I wasn’t sure just what to do. Eventually I decided to make my own 3 ringed binder showing how the computer system was “actually” used by the engineers. If I had know about process flowcharts at the time I might have drawn some but instead I had to write out longhand how the system was used. You see, on average, most folks understand flowchars better than pages and pages of text. There are exception so it’s usually done both ways.
_________ New example follows ____________
One of the last projects I did while working as the small business assistance center director in the community college was at a rural community hospital. I had been contacted by the hospital’s director wanting some help in reducing the number of medication errors in the facility.
Fortunately for both the patients and hospital, there had not been any fatalities due to medication errors but there had been under doses, over doses, wrong medications, no medications and timing problems.
One of the first things the director did was give me a walk through the facility and introduce me to many of the medical staff and a couple of the doctors. The following day I just stood around and watched how the process worked and talked to several of the nursing staff about how things worked and some of their concerns. At the end of day I asked the charge nurse to recommend a small group of the staff involved in administering medications who would be interested in working as a group to work on the problems. She put together a team of members from all aspects of the floor personnel, pharmacy and she agreed to start meeting once each week to flowchart the medication process.
The next week the group met in one of the training rooms and I explained what we were going do and I demonstrated how to flowchart a simple process. We then started developing what they called the “Medication Delivery Process.” I’m sure the group was amazed how much work it took to develop an accurate flowchart of the process. After a couple of meetings the group began to function as a team and the process flowchart began to take shape. During week three a nurse, new to the team, came on board and things became rather interesting. The group dynamics changed due to her strong personality.
This nurse was very into her job and as we worked through the process it became obvious to her where some of the medication errors were coming from. She wanted to immediately implement process changes to fix things. It took considerable patients on my part to remind her (over and over) that when you change things you have to remake the flowchart. I had been trained to have flowchart teams complete the visual process chart as the process presently worked, start measuring certain points in the process then use the data and its findings to make changes in the process, one at at time. Make a change, redraw the flowchart, collect data, analyze the data and make process improvement changes then repeat the process all over again.
Once the team understood how to do the process improvement process using the methods they had learned it was not necessary for me to hang around so I left for the summer to live at the family cottage in the Rocky Mountains.
I went on Youtube.com and found a couple of short videos on process flowcharting.
The first one comes from Ireland so don’t let the accent throw you. It will give you a basic understand of the pieces of flowcharts.
This one is done by Cindy Allen-Stuckey and her web site Making Performance Matter can be found at: http://makingperformancematter.com
Here is her short video on flowcharting: