On a note related to the article on Alan Kaye I just posted, I just was reading Esther Dyson's abstract for this month's Release 1.0 on what the spreadsheet did for data, freeing users from models built on the mainframe and why we don't have a similar tool for processes. She says:
First story: My inbox is overflowing. I have 3158 messages in it, dating back to the last general cleanup, January 2004. I also have a folder called Memorial Day, which contains 1825 messages dating back to spring of 2002 and before: These are all the messages I was planning to handle over the 2002 Memorial Day weekend, but never got around to. I know that I can find them, even with Eudora's relatively slow search. But I want to know more: Which ones of the 3158 new ones should I be paying attention to and looking for?
Second story: A couple of weeks ago, analysts following Omnicom Group noted that the company plans to spend an extra $50 to 60 million in audit fees and internal costs (mostly IT, we assume) to comply with the new Sarbanes-Oxley requirements. Presumably it has all the data, but now it needs to make the processes explicit: Who's in the chain of command? Who made the decision to pay the bill? It wasn't made by the programmer who wrote the code.
Two stories, one theme: Getting control of business processes, not business data.
Indeed, data is relatively easy, and we have good tools for it: the calculator, the spreadsheet, and the giant financial number-crunching application. The spreadsheet gave users a tool not just to calculate, but to build complex models and, in fact, to do many things that previously could be done only by IT high priests. Better yet, the spreadsheet allowed them to build models that were intelligible to normal people. So-called power users could build the models, while other users could reuse or modify them, plugging in their own data and coefficients. Complementary graphing and other tools made the data more visible and meaningful to ordinary people who could not pick trends out of a sea of numbers. We also have the database, which acts as a back-end to those corporate applications and to the spreadsheets, allowing for easier sharing of data across applications and even among enterprises.
The first successful spreadsheet was called VisiCalc; where is VisiProcess?From Business Intelligence & Market Research with Technology Analysis- Release 1.0 Publication
Referenced Tue Jul 13 2004 11:47:52 GMT-0600
Esther also uses the term "meta-mail" to describe this. I've used a different term for a similar idea in the past: virtual networks of demand, a term I first heard from Duy Beck. Here's the idea:
Anytime you get an organization of more than a few people, you start hiring people with particular functional specialties to perform specific tasks. Therefore, getting anything accomplished, requires that you have a workflow (formal or informal) for getting things from one person to another in the right order, at the right time, etc.
Another way to think of this is as every person representing a little bit of production capacity with their own supply chain and demand chain. All of these internal supply and demand chains represent a "virtual network of demand." The goal of an organization is to find ways to efficiently and effectively service this network and keep it flowing.
From an IT perspective, when we install CRM systems, ERP systems, employee portals, workflow systems, personal computers, office suites, and the like, we're trying to service and automate this demand network. The problem is that we can't, yet, approach it from the standpoint of viewing each employee as a custom unit that has specific needs because of their role, their style of work, the way they learn, the way that they're most comfortable communicating, etc. We more or less give everyone a standard set of tools and require them to do their own customization. We just build a machine and expect people to be cogs in it, instead of viewing them as a big distributed P2P network. I think we'll see a trend in the future toward more and more fine grained approaches to this problem.From Phil Windley | Virtual Networks of Demand
Referenced Tue Jul 13 2004 11:49:43 GMT-0600
Do things like BPEL get us closer to this? I'm not sure. Its not that BPEL isn't a good thing, but that its just one piece and incremental at that. What made the spreadsheet so revolutionary is that it let non-programmers build sophisticated models by putting programming into a rigid enough box (no pun intended) that many of the gotchas we experience in programming were no longer relevant. I'm not sure BPEL (or other process oriented languages), even with a great visual programming front-end, represent this same kind of fundamental leap forward.
