|
|
| ||
|
|
||
An intranet energized Sandia National Labs pumps up its internal Web with a powerful workflow system for handling electronic transactions.
By Beth Schultz Sandia National Laboratories began sharing information over an intranet long before most people ever heard the word. Now, three years into its venture, the organization is just about ready to get down to business. It's not that Sandia's employees don't use their Web for business purposes. It has definitely become a part of their everyday work lives. But with the planned launch of several Web-based workflow applications next month, this U.S. Department of Energy (DOE) multiprogram science and engineering lab will take a giant leap toward its goal of conducting all internal business processes electronically. Activities such as filling out timecards, submitting purchase requisitions and filing expense reports will soon be Web-based transactions at the Albuquerque, N.M.-based lab, which is operated by a subsidiary of Lockheed Martin Corp. Some of these transactions are straightforward. The employee fills out a form, hits the submit key and that's that. Others aren't so simple. Those transactions requiring approvals, sometimes at multiple levels of the corporate hierarchy, are, Sandia thinks, perfect workflow fodder. It's early yet, but Web-based workflow will pervade Sandia, says Mike Eaton, chief information officer. "Anyone will be able to get on the workflow train.'' Sandia had built its basic intranet infrastructure by early 1996 when the organization set its sights on Web-based workflow. It had done so for two reasons: cost and platform independence. A workflow infrastructure project team began investigating client/server-based workflow packages. They found that, at $500 to $1,000 per user, they were too expensive. "Multiply that by 8,000 people, and you're talking millions of dollars,'' says John Herzer, a senior programmer/ analyst on the team. What's more, he adds, most didn't support all three of the platforms -- Windows, Unix and Macintosh -- in use at Sandia. Scouring the marketNot wanting to develop a robust workflow engine, the team began looking for Web-based workflow products. It found only one. Action Technologies, Inc., of Alameda, Calif., had boosted a Webified version, called Metro, of its client/server workflow package. Sandia adopted it.Actually, adapted is probably a better word. Sandia's workflow team customized much of the Metro package to reduce dependence on the vendor, says James Hutchins, leader of the workflow infrastructure project. Rather than deferring to Action's use of Microsoft Corp.'s SQL Server as a data repository, Sandia decided to integrate its Sybase, Inc. SQL Server database with Metro. To do so, the workflow developers built a Common Gateway Interface (CGI) program. The program stores and retrieves most of the content entered and viewed by users via HTML forms in the Sybase database. A CGI script acts as a transaction center for business forms returned to the Web server. The script extracts the data, stores it in the database and calls Metro's APIs to record what has happened so that Metro can decide the next step in the process. In this model, HTML/JavaScript forms call Sandia's Workflow CGI program, which validates fields against the Sybase tables and stores new transactions in the appropriate tables. The Workflow CGI program then calls Metro, passing on the key fields needed to retrieve the transaction again from the database. Similarly, the HTML form generated when users access their workflow workboxes is passed to the Workflow CGI program, which then extracts the full set of application data from the database and reconstructs the application's HTML form. The custom work helped the team bring Metro cleanly into Sandia's infrastructure, Herzer says. In addition to tying Metro into its Sybase human resources database, the team had to link it to a Kerberos server and Simple Mail Transfer Protocol-based e-mail backbone. Headed overseasThe team's first stab at Web-based workflow was for a foreign travel request application, which went online last November. It served as a prototype for the routing approval needed before DOE submission."This isn't a real high-use application, but it's important,'' Herzer says. The DOE requires any Sandian planning a trip abroad to obtain permission. This approval could be nightmarish: A foreign travel request typically requires seven signatures before it even gets to the DOE, says John Abbott, a senior programmer/analyst. Say a scientist has been invited to deliver a paper at a conference in France. Before the scientist says au revoir, he's got to sign off on the request himself, assuming he has had a secretary fill out the official form. He then must get approval from his group manager, director and vice president, as well as from the case manager and two security analysts. The first security analyst needs to okay the request at the beginning of the process and the second needs to review the approvals prior to sending the request to the DOE. In the Web-based scenario, the routing list would be determined when the scientist fills in his Social Security number. Sandia runs that identifier against the HR database to determine routing. Each person in the process is notified via e-mail that participation is required. Upon receiving notification, the person would click on a link and be taken to a Web page that would list the items in that person's workbox. He or she would click on the foreign travel request item, verify the data and indicate approval or disapproval. In another bit of custom work, the team has built proprietary extensions into the Web server that override Metro's security scheme. When the scientist's manager logs on to her Web-based workbox, for example, a Java applet requests that she enter her user ID and password plus a Kerberos password, which is encrypted before being sent. The Web server confers with the Kerberos server for authentication. The team expected that bringing the foreign travel request application into the Web-based workflow model would reduce the process from a week or more to a day or two. For the most part it has, but the foreign travel application also pointed out a major limitation of the workflow implementation. If someone in the approval chain is out of the office for the day, on vacation for two weeks or otherwise incommunicado, the travel request form would sit waiting for that person. "The shortcoming of workflow products is that they're person-centric rather than process-centric,'' Hutchins says. "They tie the process to an individual's desktop by ID.'' The team decided to change that by building what it calls the roles/delegation of authority (R/DA) interface. The idea is not only to allow delegations, but also to determine who plays certain roles and when those roles need to be performed. The team knew, in fact, that it could not bring other workflow applications onto the Web without the R/DA. "With R/DA, workflow becomes role-centric, so you could assign something to the manager of Project 4815 rather than to someone,'' Hutchins says. Personnel action and purchase requisition applications coming during the next two months will be the first Web-based workflow processes to use the R/DA interface. R/DA would determine what role someone needs to play based on certain input. For the latter application, if our scientist wants to buy supplies costing more than $5,000 but less than $200,000, he'd have to get his manager's approval. For a purchase of more than $200,000 but less than $2 million, he'd need manager and director approvals. If the requisition is for more than $2 million, a vice president also needs to sign off on it, says Abbott, noting that the figures aren't actuals. If an approval is needed, the system will determine to whom the information gets routed. If that person is not available, responsibility for the approval can be delegated to someone else. R/DA comprises a data entry part for designating roles and delegations and a Java-based engine that interfaces with the application. Application developers load the engine into their programs, Abbott explains. The workflow team relies on HR to keep its database up to date so the R/ DA interface stays in sync with the organizational chart. For the roles defined externally, or somewhere besides the HR database, the team updates the R/DA system nightly, Abbott says. After the team brings up personnel action and purchase requisitions, it will retrofit the foreign travel application with R/DA and look for other opportunities. "We look at areas where there appears to be discontent, where the processing is too slow or ineffective, or where there are lots of approvals required,'' Herzer says. On tap are workflow implementations of some manufacturing processes, a quality survey and unsatisfactory customer reports, for example. All of these have fairly rigid routing schemes, but the team also is looking at less structured workflow, Herzer says. For example, an engineer might want to use the workflow process to pass around a drawing, but would not need to rely on a formal routing structure. The R/DA will help in all instances. CIO Eaton considers it a real enabler for Sandia's expanded use of Web-based transactions. "It puts the bedrock in place,'' Eaton says.
How to Advertise | Copyright
Home |
NetFlash |
This Week |
Industry/Stocks
|