Success with job shop operations (Part II) – How to collect data at workflow steps

Welcome to part II of a blog series on success with Job Shop Operations.

Given an environment capable of providing workflow scheduling facilities (RALB), we can move on to data collection (i.e. monitoring).

The purpose of collecting data at workflow steps is to:

a) Build up a repository of data for after-the-fact performance assessments,

b) Enrich data you collect via automatic calculations to minimize manual effort (e.g. physical unit conversions of measurements), and

c) Provide decision support in respect of possible branching downstream from workflow steps.

In some cases, the only data recording required at workflow steps is to indicate, via a checkbox, “Done”. This results in automatic posting to the repository, with a today/now date and timestamp plus an electronic signature of the person performing the step.

In other cases, a data collection form at a workflow step could comprise 50-100 data elements.

Clearly, data collection needs vary from workflow to workflow and from step to step.

At a practical level the environment needs to have an embedded Form Painter of the “drop and drag” type.  In order to make this usable by ordinary users, there should be no requirement to build database tables/fields.  The ideal setup is a protocol that mirrors what a person might do drawing up a form on a blank piece of paper using an ordinary pencil.

Once you have a data collection form, you simply attach it as an attribute to any process maps\steps that need that form. When you compile the process map, steps automatically post to user InTrays (because “skill” is also a process map\step attribute) – one click at a step posts the pre-attached form(s).  No need to hunt for forms!  Some organizations need 5 forms, others need 200.  It takes about ½ hour to 3 hours to design and build a new data collection form. No big deal.

The trend toward data collection using mobile devices greatly simplifies data collection such that it no longer needs to be a distraction from the performance of work.

Data flows from the User Interface to the Repository need to be automated.  I.e. click at a step, see any attached forms, record data, save/commit. End of.

Stay tuned for a Part III blog post on dynamic decision support during data collection for job shop operations.  Part IV will focus on interoperability.

Once you have read Parts I, II, III, IV you will have a blueprint for selection of a Case management system that accommodates process discovery, mapping, roll-out and run-time monitoring/tracking.   Add data analytics to this and you can close the loop by adding “process improvement”, giving you “Job Shop Operations 360”.

Anderson Cooper has it, you can have “360″ too.


Courtesy to Walter Keirstead. This blog is also available on

pixelstats trackingpixel

By Karl Walter Keirstead @ Civerex | September 6, 2013

Leave a Reply

Your email address will not be published. Required fields are marked *