I first thought of graduate school about six  years ago. It wasn’t the sort of option I generally considered; I might gut out an MBA to acquire a polished resume and an improved professional network, but the idea of going back to school for new ideas and approaches seemed almost counter-intuitive, given how little I used my undergraduate degree. When I wanted to move forward, I’d always turned to professional opportunities. But I was a systems management geek, and I’d been trying to beat down a wall that wasn’t budging, and maybe it was time to think outside the box.

 

Systems management, the breeding ground for workflow automation tools, is a rude and unglamorous area within information technology (IT) organizations. When I began my career at Charles Schwab back in 1987, I could document my success by the fact that I received offers to move to higher profile positions in the line of business applications, the assumption being that anyone with talent wouldn’t want to waste time working in problem or change management systems. Trading automation, reconciliation, statements: these applications were the life blood of a financial company that invented discount trading and first exploited technology for cost and competitive advantage. In my first year, I really did want the glamour and investigated the offers, but I quickly realized that these applications weren’t nearly as much fun.

 

Financial transactions have a boring workflow. They have the lifespan of a mayfly with the regularity of a test pattern. There’s only one way through their life cycle. Systems management workflow can be nearly as brief or of Methuselan span, and the spice of that life can vary dramatically: an outage that costs millions of dollars an hour, or a routine program bug that can safely annoy its users for months. Simply defining the various stages of the life cycle can be an interesting task, and that’s just the first step in sculpting a system that guides and assists work while logging its activity. Glamour be damned, I decided; brokerage transactions lead a sterile existence. I stayed in systems management, eventually leaving regular employment to freelance as a consultant.

 

When I first began, the corporate world had barely scratched the surface of workflow automation potential. Customer service and IT help desks were the primary focus in those days, and only very large companies were making serious investments in these processes. There were so many other processes, and so many other companies, that the opportunities to design interesting work flow automation seemed endless. I was looking forward to the day that I could eliminate 90% of the secretarial work of a law firm; consolidate work product at a county, state, or federal government level; consolidate intra-school or intra-library communication; or completely automate administration, sales, and service for small businesses. I couldn’t wait.

 

I am still waiting.

 

In 1985, my IBM mentor who first noticed my interest in this area gave me a five year old Red Book on setting up a help desk for IT organizations. I still have that book around somewhere; I could hand it to any manager building a help desk today and they wouldn’t even notice it was 20 years old. Nothing has changed. This despite a booming industry in enterprise resource planning (ERP) products and services and a strong corporate interest in defining, measuring, and controlling work product. More companies are investing in the products and services, but no advances have been made in efficiency, process improvement, or even the underlying service provided. The same players are still asking the same questions about the same processes, needing the same explanations, often resisting the same solutions, reinventing the wheel time and again—with the enthusiastic support of the vendors, who also reinvent themselves every five years or so. This is not an industry that respects its own history.

 

In those same 20 years, the financial transactions that I found tedious had had not hours, but days shaved off their execution time, costs reduced by the same degree, and the timeliness and accessibility of information to both business and customer had been steadily improved. The automation was so complete that the roles of both requester and agent could be played by software, and often are. No one ever refers to financial software programming as ‘workflow automation’, even though it’s an entirely accurate description. Workflow automation seems to be a term restricted to processes that resists automation, not those that accept it.

 

I also realized that the same attributes I disliked had everything to do with the reason these processes were developing and progressing. The short unvarying life of financial workflow was what made it amenable to standardization, which readied it for technology. The workflow could be a commodity; the same business model could be implemented anywhere.

 

It took me longer to figure out why financial work and its kin had such a short life. I didn’t yet know what to call it, but it was clear to me that all players in a financial transaction had the information they needed to participate. The customer can provide identification and service needed. The agent can provide the service. The customer and agent are playing a common interest game.

 

In comparison, a more complex workflow such as customer service has a very sloppy playing field. The customer knows who he is, but doesn’t always know what he wants. The agent may or may not be able to determine what the customer wants, and may or may not be able to proceed, depending on a variety of factors. The customer and agent are not playing a common interest game. The customer wants his problem fixed. The agent wants to keep his job and improve his salary, and is not rewarded on the basis of the quality of support provided, either directly or indirectly, and behind that truth is an entire tale of self-defeating belief systems that would require a second statement of purpose.

 

It’s the variance that makes these processes so attractive to me. When the process is unbalanced, it is far more interesting to design and implement a system that rewards all participants with the results they desire. But each system is expensive, and each system is custom. Every year a new vendor comes out with a product that just has to be “dropped in”, and every year consultants make a substantial sum customizing the product for the companies who purchased it because it could be “dropped in”, and then demanded that it fit their individual process. Build a system for one company on those terms and it has next to no applicability for the next; the only collective benefit is the analyst’s acquired experience, which isn’t pooled, but used as a resume bullet item. Custom systems are expensive, which decreases the likelihood that more customers will invest in them or keep them updated.

 

We are a long way from achieving a standard process flow. We haven’t even collectively identified this failure as a problem: there is always a product to blame, another product to turn to. Yet until we can turn a complex workflow into a commodity, I don’t think we will advance in these areas of information collection, and we'll never be able to convert it to a commodity until we resolve the information gaps and disparate objectives.

 

I decided to leave consulting and go into product design. I had a wonderful time, but ran into another wall. Many organizations have flawed belief systems and incentives; there is strong resistance to a true paradigm change, despite measurable improvement. This was undoubtedly true of financial transactions once, but there was a clear cost advantage that rewarded ruthless disregard for employee comfort level. I had discovered another component to the lack of progress. I ultimately failed to convince my employer to design effective products, given the resistance of their client base. I was not surprised, of course, and left product design to return to consulting, sadder and wiser.

 

During those years, I also hung out at a rather eclectic online forum, where I was first introduced to game theory. My understanding of it barely scratches the surface, but is sufficient to realize that multi-user applications are games whose outcomes are determined by the mix of players acting in their own self-interest as they understand it. Problems occur when the various players have conflicting incentives.

 

I had intuitively made similar observations that helped me to design systems that avoided those outcomes. Is there a field in microeconomics that started with the desired outcome and designs games that give everyone incentives to lead to that outcome? A few questions led me to mechanism design, or the theory of incentives. I discovered an entire vocabulary to explain the observations I had made over the past decade, as well as my ability to predict and design for desired outcomes.

 

But where does one proceed? Is it possible to re-educate such a large community? Will re-education even help, if the solutions are too expensive to make the benefits worthwhile? Can the answers be found in technology, by building technology that standardizes process cheaply and effectively, making the advantage of adopting it outweigh the preference for expensive one-offs?

 

I don’t think there is any one answer. My years in systems analysis have taught me that there are no answers, only an endless series of “if...then” with an occasional “do”. There may not be any answer; it may be that the current situation is the best that can be expected.  But I expect to have fun trying.