Your Workflow Needs a Guide!

In the last installment the first item in the Workflow Quiz asked if there was documentation for your workflow architecture, and if it is was up-to-date. It turns out that many of you don’t know if there is current documentation on your production workflow, even though it is the backbone of your company. This isn’t too surprising. Every production workflow has many moving parts, often installed at different times but different stakeholders. Once software tools are installed the processes that use the tools may never be documented, with the user manuals for each component considered the documentation. The truth is, that isn’t a documented workflow.

A truly documented production workflow identifies all of the touch points, from the point where a job is brought on board to the workflow process, through each step until the final delivery requirements are met.

Documenting the workflow begins with what defines a job and the onboarding process for each type of job. That last point is important. There are organizations that maintain several onboarding processes because there are different processing paths based on security requirements, how much processing the job needs to enter production, how many stops there are along the workflow path, and even how it exits the workflow. If that sounds like your department, take the time to document all of the variations.

What does “document” mean in the context of workflow? That is where you may find disagreement among your colleagues. For some a drawing with a few process names meets the brief of documenting the workflow. For others, a binder with all of the software manuals and some written notes on custom scripts is more than sufficient. Neither meets the requirement of a documented workflow.

The lack of documentation is most keenly felt when bringing new people into the department, during mergers and acquisitions, when new software is added to the process, and when a catastrophe occurs that causes the disaster recovery partner site to be activated or jobs moved to alternate locations within the company. That is when everyone starts to look for the process documentation that will help. So that should be your starting point. What does someone new to the environment need to know about how a job moves through the process?

Think in terms of both text and graphics. You need the diagrams that show the handoff points, and the explanations of what the processes are, what the software components are, what the custom scripting components are, and what they reach out to on the outside of the workflow. You do need to know where the user manuals are for any product you have purchased, but beyond that you must find a way to document all of the custom scripting that is often the glue in a production workflow.

And then the hard part happens. Someone has to be assigned accountability for keeping it current. And a best practice is to make the use of the workflow documentation a critical part of any disaster recovery drills. (You do those, yes?)

This might sound like something only the big players need to worry about. The truth is that a well-documented workflow is critical for any size company, and with it comes increased productivity, greater confidence, and an excellent place to start when it is time to enhance the current workflow!

I’m done preaching. If you have stories to share reach out to me! @PatMcGrew on Twitter, on LinkedIn, or Pat.McGrew@InfoTrends.com all reach me.