Wed, 13 Dec 2006
This is the second (long-time-in-coming) installment in our AppleScripting the Workflow series. In our previous article and its companion tutorial we looked at the power of AppleScript and it's basic syntax. This time we are going to look at the biggest task involved in workflow automation: Workflow analysis.
Workflow analysis is a fancy name for the process of identifying the tasks and the required results that make up your workflow. Workflow is the process you follow to produce your product. For our purposes that may be a website, catalogue, flyer, magazine or any other concrete product that you digitally generate.
So, to analyze a workflow we need to start somewhere. Top or bottom, you pick. We can either start at the top and work our way down or start at the bottom and work our way up. The point of the exercise is to identify our Projects, Phases, Steps, and Tasks.
At the top of our hierarchy is the Project. It may be to produce a catalogue, photo portrait or magazine ad. Whatever it is, it defines the end result of your process. You may produce several types of projects in your organization, so each will need to be identified with its own project workflow.
Depending on the complexity of your projects they will have at least one step, and possibly several. Some of the steps may be complex enough to require several tasks to complete them. Its is not really important how you organize the information you gather but rather that you gain a intimate understanding of:
Many projects are complex enough that it helps to organize our steps and tasks into phases - for instance our Catalogue may have Marketing input, Graphic design, Production, Proofing, Approval, Print as its phases.
Depending on the scope of your projects and the size of your organization this step may be difficult. If you are the chief cook and bottle-washer then you already perform all the tasks so gathering the information will be easy. However most organizations are more segmented than that, so information gathering may be more difficult.
It is key that you solicit feedback from the people in your organization who actually perform the tasks. We like to use a public wall, perhaps in a boardroom, that can get covered with sticky-notes. That way those involved can see and contribute to the big picture. Different colour notes can be used to define the tasks and their products, requirements, and dependencies.
We've found that sticky-notes work better than a whiteboard because it is easier to reorganize things when new interdependencies are identified. It's also a good idea to post a legend that defines the format of the information required on each note.
Once you have reached a consensus on the accuracy of your project wall, its time to start capturing that in a more durable form. There are many products out their that can help, but one of our favorites is the Omni Group's OmniGraffle.
Using OmniGraffle it is easy to create flow-charts and diagrams of our project workflows that makes the information easy to read and understand.
Once you've captured all of the information and understand all of tasks at play, its time to begin to identify likely candidates for automation. That is what we will look at in the next installment. So until then...
Get notified when there are new articles.
We're not the only ones with bandwidth and a need to share. Here are some of our favorite technical resources on the web.
We've been lifetime subscribers to MDJ for, like, ever. Insightful, biting and timely. Well worth the cash.
Need software? Versiontracker will help you find it.
High on news, low on press releases. I like the layout too.
Great layout, like the writing style. Gruber writes for MacJournals too.
Need to learn about the deeper levels of Mac OS X? Mac OS X Labs can help.
Heterogeneous, Heterogeneous, Heterogeneous!