|
|
|
| Teamwork and Transactions
by John Tibbetts and Barbara Bernstein InformationWeek, July 27, 1998
In this age of networked PCs, too many business apps are still designed tor individuals rather than groups. |
 |
|
|
|
| Teamwork and Transactions
by John Tibbetts and Barbara Bernstein InformationWeek, July 27, 1998
In this age of networked PCs, too many business apps are still designed tor individuals rather than groups. |
|
| Good progress on the teamwork front! Computers
keep getting better at working together. People are collaborating more
too, as today’s re-engineered businesses put employees, customers, and
affiliates in close touch with one another.
Unfortunately, computers don’t work with teams of people very well. The transactional applications that implement strategic business processes (and manage web-based e-commerce as well) remain adamantly non-collaborative. A single user engages with the HR system to instigate a NewHire transaction—even if multiple people have had a hand in evaluating the candidate. A single user places a book order with Amazon.com—even if she is submitting the consolidated requests of a whole academic department. Why, in this era of networked PCs, email, and the Web, are business apps designed for individuals rather than groups? It's a legacy problem. Transaction processing technology dates from the era when only the rare employee had the skills or the means to interact with the computer. This person translated into computerese the end results of a manual process—salary review, order placement, customer service request—that had likely passed through the hands of several different people. Today, each of these people is computer-savvy and fully wired. But it still takes printed forms, phone calls, emails, and strolls down the hall to get a transaction ready for submission, at which point a designated user sits down at the keyboard and engages in a one-on-one, real-time “conversation” with the automated system. What a waste to turn to the computer only after all the work is essentially done and the decision made! Why not use it to move the transaction-in-formation through the organization instead of moving papers and people? Imagine a NewHire application that begins with a scanned-in resume, gets routed among interviewers for their comments, carries exhibits as they are acquired (references, test scores, security clearances, etc.), and finally, if successful, passes through the TP monitor to the HR database to record the new employee. Imagine a claim system where a partially filled-out form is downloaded from the insurance company’s web site, added to by the patient, emailed to the doctor and from there to the lab, and then submitted to the insurer for review and payment, bouncing back to any of the collaborating parties if necessary for further clarification. Imagine a procurement system that circulates a wish-list among team members, submits it to an inspector (human or otherwise) for approval, and then transacts. These are examples of collaborative transaction processing, and all are technologically feasible today. Clearly, multi-party, long-running transactions present challenges that don’t exist when a single user interacts with enterprise resources in real time. But object technology provides the answer. It let us turn what is now a process (the transactional “conversation”) into a thing, which can be routed (perhaps via Workflow), added to, pended, refined to everyone’s satisfaction, and finally submitted to the back end. We find it helpful to call such this object a “Proposal,” since it represents proposed changes to enterprise resources. The Proposal object needs to contain both the data for the ultimate transaction and supporting information as well. It serves as a vehicle for communication among the collaborating parties, so it carries a layer of comments, questions, instructions. It represents work in progress, so it has to accept (and mark for eventual fix-up) the kind of incomplete or erroneous information that now stops transactions dead. It has to be able to check that any data it has downloaded from the enterprise data store (price list, availability information) has not changed in the interim. As they zip around gathering and structuring the input needed to make a transaction happen, Proposal objects provide the mechanism for automating collaborative processes. If your key business processes have multiple steps involving multiple people, and if you believe that computer systems can help these people work and communicate more effectively, then exploring collaborative transactions should be on your agenda. |
| Return to Kinexis Home Page |