Feats Instead of Processes

In my last post on Software Capabilities and Feats I said that feats are better [to model in a software capability] than processes, because processes are merely organized, consistent, managed ways to accomplish the feat.

A process is one way to accomplish a feat. The feat is the result you want.

Process is constrained by capabilities. So when I am modeling new capabilities, I should not be constrained by existing capabilities. When I introduce the new capability into the wild, the process will need to “re-form” around the new capability.

A process has steps. If we build software capabilities to support a process, we treat the steps of the process like “feats”. I can model a capability to make that step faster or more effective. That assumes that the step is necessary. In order to decide whether a process step is “necessary” I need to understand how it contributes to the valuable result. I need to understand why I do the step.

If that step only exists because of the lack of capability in the current state, why not create the capability that eliminates the step. Semantically, this involves a negative. When my reason for having a step is “negative”, the step exists to support a lack of capability. This means that we have to ask ourselves why the process “needs” this step. This is different than asking “Why we do” the step.

Negative Reasons for process steps:

Because we…

  • don’t have the data to evaluate or enforce the rule, we need an extra human review step.
  • can’t translate the information into that vendor’s structure, we need to manually type the data into another system.
  • don’t trust the data quality from that system, we need to review data from other systems as well.
  • can’t present information in a summary form, we need to export to a spreadsheet to summarize.
  • don’t have a way to send the data, we need to manually send a spreadsheet to the customer.
  • can’t federate the data from multiple sources, we need to manually compile reports from several systems.
  • don’t have a way to push exceptions to associates, so associates need to run reports, find exceptions, and create tickets for resolution.

These examples from my experience, are the evidence that process is formed around capabilities, and not the other way around. When we understand this, we can then start to talk about what value a human adds the the feat.

Before computers were ubiquitous, we had two jobs that all but have vanished from the planet. Bookkeepers and Secretaries. While we all understand that e-mail, voice mail and electronic calendars or group ware, have all but replaced secretaries, we also realize that managers and executives now spend much more time typing then they did. Likewise, bookkeepers used to manually tabulate sales receipts and payments every day to report gross revenue, cash flow, accounts payable, accounts receivable, daily profit and loss for thousands of companies. Their summary data would be reported and aggregated from their department to division to business unit to corporation. Because of all the manual tabulating and summarizing it could take days to get the monthly reports together. Today, any business with more than three employees probably uses QuickBooks or some other basic accounting system that does this without the need for extra staff.

Those thousands of process steps those employees did for decades in the height of the industrial age were swept away very early in the information age. Evidence that it is not the process we care about, but the result. The goal of your next capability is to find a way we can get the result faster, more consistently, more accurately, for less cost.

No Comments

Leave a Reply