Workforce Automation

Business Challenge

In the increasingly complex business environment, employees often perform tasks where they could use software support. Examples include claims processing in insurance, field repair in utilities, and account management in direct sales. In these cases, there are two primary issues. First, the enterprise wants to make sure that employees follow specific policies. Second, employees need access to a variety of documentation to support their tasks . Workforce automation software can address both issues by guiding employees through the official process and electronically delivering the documentation they require.

It's certainly possible to build such solutions on top of existing application platforms and use HTML as the electronic delivery vehicle. But this approach has two drawbacks: (1) enterprises often have difficulty updating the processes encoded in the software in response to changing business conditions or feedback from employees, and (2) HTML is somewhat limited in its ability to support the delivery of a wide array of documentation to mobile workers. The browser-centric nature of HTML does not necessarily suit the devices used by these workers, and the previously discussed searching constraints make it difficult for workers to locate the documentation they need.

XML Benefit

XML can address both issues. To deliver more flexible processes, XML can serve as the format for dynamically configurable process descriptions. A general workforce automation schema enables the enterprise to encode process flow as XML documents that the system then uses to drive the guidance of worker tasks. If a new type of process arises, creating a new process description immediately enables support for that process. If employees identify the opportunity for improved efficiency of an existing process, updating the process description instantly pushes out the improved model.

As discussed in Chapter 5, XML-based CMSs have a number of advantages. They enable improved searching of the available documents, and they can accommodate a wide variety of ad hoc and structured information. Moreover, the separation of content and presentation possible with an XML content strategy better accommodates devices of different form factors. Many important job tasks involve mobile workers who primarily maintain contact with the enterprise through tablet-based PCs, portable initial assistants (PDAs), or cellular phones. Device-specific XSLT stylesheets enable applications to format content easily for the appropriate form factor using the same XML content.

Architecture

As Figure 7-1 shows, the workforce automation architecture combines elements of workflow systems and content management. When a worker executes a step in a job task, he fills out a form that notifies the task manager component of his status so, by comparing the status of the XML-formatted rules in its repository, it can determine the next step. In addition to processing the task step, it retrieves any specific supporting content from the CMS and then returns this supporting content as well as the status form for the next step in the task. If the worker needs additional supporting content, he can directly query the CMS.

Figure 7-1. Workforce Automation Architecture

The application can easily support different client devices using XSLT stylesheets. Customizing the content conceptually occurs in two steps. Based on where the worker is in the process and his personal preferences, the Web server may apply an XSLT filter to the raw XML content to generate a more focused content document. Then, based on the type of device the worker has, it applies a presentation XSLT to generate an HTML, WML, VoiceXML, or other type of document.

Key Features

This type of workforce automation application uses XML for behavior as well as content. This technique is emerging as one of the most revolutionary benefits of XML. The trading partner coordination application in the next section takes this technique to the extreme.

Development Process

Obviously, supporting worker job tasks with software requires a thorough understanding of those tasks. The analysis takes place in two phases. First, you must analyze the general information requirements faced by the worker when performing a class of tasks. You must fulfill these requirements by acquiring or commissioning the appropriate content, installing it in a CMS, and providing the necessary metadata to facilitate searching. You must also construct the appropriate filter and presentation stylesheets

Once you have satsified the general information requirements, you can begin modeling specific tasks. Usually, you will use a flowchart or other design tool to construct the model, and this tool will then generate an appropriately formatted XML process description. Because these XML documents are for all intents and purposes code, you should manage them through a standard source code respository. As processes evolve , analysts will probably spawn many different versions of each process that you want to track over time. Eventually, you can build up a library of process descriptions that will greatly decrease the time required to deploy new ones.

Schema Source

Creating process definition schemas is extremely difficult, so you probably want to rely on either the schemas from a workforce automation package or a more general workflow specification such as BPML, WSFL, or XLANG. In either case, a graphical modeling tool will make sure that you construct descriptions that conform to the schema. As for content document schemas, you will probably start with generic content schemas from the CMS or industry standards body but then customize them to support the specific information requirements of your workers.

Document Life Cycle

Obviously, the instruction for executing processes and the content to support those processes must both persist. However, their life cycles are slightly different. Humans generate both types, but machines consume process documents, whereas humans consume content documents. Their respective evolutions differ as well. Process documents evolve in accordance with changes in enterprise business policies. Content documents evolve in accordance with changes in worker information requirements. Because the process descriptions are operational data, as discussed in Chapter 5, you probably want to store them in a native XML data store or data server. The filter and presentation stylesheets act as both operational data and content. Depending on the number of stylesheets and system loads, they may have to reside in a native XML data store or data server as well.