Tag Archives: Workflow

Workflow Tracking

The Financial Times reports that…

General Motors was forced on Friday to add a third batch of vehicles to its faulty ignition switch recall when it said 824,000 previously cleared vehicles might have been fitted with faulty switches during repairs.

The piece continues with the following…

The vehicles were recalled after GM established it could not be sure which batches of vehicles had been fitted with 5,000 of a batch of 95,000 faulty switches supplied to dealers and after-market suppliers. The remaining 90,000 switches were all fitted during repairs to vehicles covered by the previously announced recalls.

That sounds spectacularly painful.

CEO Mary Barra, trying to salvage GM’s reputation, states that they “are taking no chances with safety”, asserting that “trying to locate several thousand switches in a population of 2.2m vehicles and distributed to thousands of retailers isn’t practical.”

Well, maybe… It might not be practical in their present circumstances, but it is not outside the realm of the practical for what an organization with
mature workflow tracking processes in place might be able to do. A company the size of GM would seem almost certain to have at least made serious inroads into such things. Maybe this was an aberration? Or maybe this is a facet of their production operations for which they are only belatedly realizing the criticality of good tracking? Or maybe they have some processes that would help in a situation like this but lack the necessary cross-organization buy-in to execute on it reliably?

There are several related pieces to solving this kind of problem:

  • workflow decomposition
  • workflow element instrumentation
  • workflow element event modeling, to include maintaining provenance
  • workflow element event publication
  • logging of each type of event to an authoritative system
  • construction of Question Focused Databases that index those events usefully
  • definition and enforcement of choke point systems

Each of these things presents substantial challenges in its own right, both political and technical, but the pay-offs can be enormous. Implemented with sufficient generality, such mechanisms not only provide the forensics data to deal with the aftermath of crises, but also yield up the business intelligence to increase efficiencies, identify new opportunities, and detect small aberrations before they become full-blown disasters.

Shooting from the hip, simply working with a number of vehicles in the neighborhood of millions, and assuming recall repair costs around $1000, this single Black Swan Event for GM represents a mistake with a clean-up cost in the vicinity of one billion dollars, and those are only the directly observable costs, ignoring such ambiguous things as customer brand perception and workforce morale, things for which the ultimate costs to the company could dwarf the presently observable costs. So if GM had spent even one billion dollars positioning themselves to be able to know where faulty parts had gone, such an effort would have paid for itself in one fell swoop, and no doubt there would have been an epic amount of gravy to be had.

But let’s not trivialize things… Yes, you can get a lot of mileage out of teasing apart your workflows into well-defined discrete elements, generating provenance-maintaining events that include a UUID and timestamp at every step, and databasing that information intelligently. If, however, you’re a company like GM, your operations are quite sprawling, involving countless third party partners participating in an assortment of support roles. Somehow you have to bring together this mess of data despite having to work with various actors of varying cooperativeness. And even when you do figure out how to do that you still have the problem of all of your legacy systems out in the field giving you heartburn.

But let’s dream… What if every part were stamped with a UUID that could be reported later and linked to the events involved in its manufacture? What if the car itself were cognizant of all the components presently installed in it? What if the car had faculties for publishing the list of all installed components back to the manufacturer, perhaps doing so over wireless channels, thus obviating going to a service station? This would create the opportunity for the manufacturer to know, among other things, where “poison parts” had gone in an ecosystem of millions of cars, allowing them to pinpoint the relatively small number of vehicles with parts installed from known-bad batches, and to do so without the cooperation of the countless middlemen involved in the distribution and installation of such parts.

This is the future. It will be no small undertaking, involving no less than a fundamental re-imagining of how components are built and assembled into a logical whole as well as a careful rethinking of liability and privacy law, but it can be done, and it will be done, almost certainly within a decade, and the implications will be dramatic.