JOHNSTON, IOWA Anyone who has undertaken any project that impacts how a product or service moves through the supply change has probably run into issues related to workflow.
In order to actually do a workflow analysis, it is important to understand the basic fundamentals of systems. Systems are defined as anything that has independent parts that either interact or are interdependent—and workflow is the path or flow of work within the systems. Virtually all systems go through what can be thought of as "lifecycles," which are created based on needs; over time they evolve as the needs they were created to meet change.
Workflow analysis is the process by which we observe the entire system to understand the processes and interaction of the components and workflow management involves taking what is learned from the analysis and using that information to modify the system to improve workflow. Improvements are typically ways to streamline processes to reduce costs or improve throughput. So ideally, workflow analysis and management should be an ongoing process that is constantly looking for ways to improve existing systems or replace systems with ones that better meet the needs.
Many of us have heard the statement "If it ain't broke, don't fix it!" I personally have heard this statement when suggesting a change in the way things are done. Typically the statement comes from one or more of the people that will be most directly affected by the proposed change. Their initial reaction is to resist, causing conflict and stress. If the system in place is doing the job, it is "better" or "easier" to put workflow analysis and management into the "too hard pile" because the hassle factor outweighs the perceived benefit.
The analysis itself can be somewhat disruptive and unnerving for the people involved. For example, in the early 1990s when I was the manager of engineering for WSAZ television in Huntington, W.V., we had an interesting opportunity present itself to us. WSAZ is an NBC affiliate and at the time we were pretty much a manual operation with master control operators sitting at the Grass Valley 1600 switcher pushing buttons and loading tapes. There was a tremendous amount of very repetitive and easily automated work in this system but unfortunately budgets were typically very tight. One of our senior master control operators was promoted to technical director for our newscasts.
Another senior master control operator had an opportunity to become a full-time paramedic which was his real career desire. Doing some basic workflow analysis, I was able to come up with a plan to automate the master control operation and reduce the required staffing by two positions and use the funds from those positions to demonstrate a very short payback for the capital investment needed to automate. From my point of view we had an absolute win-win situation because we were able to automate and no one was losing their job and within the master control system, I was correct.
But there are systems within systems and as we started to plan for automation the impact on traffic received a lot of pushback. As I analyzed how commercial spots moved through the system I found many convoluted and unnecessary steps. When I suggested changes, there was a little panic in traffic and some of the staff thought they might be at risk; and since traffic wasn't under engineering "I really had no authority to change our way of doing business," I was told. I remember leaving that meeting after making a statement that change was coming and the traffic folks could either participate in planning for the change or get run over by it. I was much younger and less tolerant then.
So changing one system can have ripple effects and while some of the consequences are predictable, others are not and the villain in all of this will be the person responsible for the initial change; and not many people want to be the bad guy.
So in the end, the primary reason workflow analysis and management is so difficult is not that the process is hard to do, but that people involved on both ends have concerns like self preservation and how they are perceived. As a result, it is not uncommon to hear and see stations where they do things the way they've always done them because they are not convinced that the change is worth the effort. Add to that fact that many of the workflow changes being proposed are driven by enhancements in technology that may indeed improve workflow but may require people to change their behavior.
As another example, a few years ago IPTV changed traffic software from Scout to Protrack. Changing traffic software is always a challenge and this was no exception. What made it even more difficult was that until just a year or so from when the software change happened, IPTV had on staff an extremely intelligent code writer who had—with Scout's permission—decompiled the software and wrote custom applications within Scout. This allowed maximum flexibility but unfortunately also meant that we had an application that was completely different than any other Scout installation. When the code writer left the station, we ended up with an unsupportable mission-critical application but it was something that the users were very familiar and comfortable with.
In comes Protrack which like all off the shelf systems was purposely written with rigid structure to ensure basic compatibility for support and commonality of operation which is essential for good computer-based workflow. The problem manifested itself when the operators had to change how they worked and some resented the need to change. It was only a problem from the operator's perspective because they were accustomed to a traffic system that would have its behavior modified to meet their needs and now they were working with a system that required them to modify their behavior.
DON'T WAIT
If there is any blame to assign for letting workflow analysis and management become this albatross, it really rests in the leadership, me included. We tend to let things go until the point where change is required and by that time the issues are generally so large and numerous that the required changes are generally dramatic and all-encompassing and as a result, are very disruptive. If instead we make the analysis and management an on-going process, bite the bullet and recognize that we're not in a popularity contest, recognize that our organizations and systems don't exist to keep us employed but are to meet needs of others such as viewers and customers we would make many minor course corrections and very few major ones.
The end result is that we would all be a lot more comfortable with the future and a lot less stuck in the past. When Gary Sgrignoli does his seminars on 8-VSB and digital measurements, he is frequently in a room full of fairly cantankerous engineers that are pretty well set in their ways and not always open to embracing the change that is required in the DTV workflow. He quotes retired Army Chief of Staff General Eric Shinseki who said "If you don't like change, you're going to like irrelevance even less." Stay relevant!
Bill Hayes is the director of engineering for Iowa Public Television.
