## Using HP AdminFlow to Automate Business Processes

### Tony Jones

Hewlett-Packard Company
371 Hoes Lane
Piscataway, NJ 08854-4107
Phone: (732) 562-6248
E-mail: Tony_Jones@hp.com

HP AdminFlow provides enterprise-wide, client/server based workflow management. The HP Consulting Organization provided assistance to a major telecommunications company in order to implement a foundation for automating administrative processes associated with line of business activities.

This paper describes how to use AdminFlow as part of a solution to reduce the operating costs associated with corporate-wide administrative processes. End-users can analyze workflows that are currently in progress and also workflows that have been completed. A user can see what steps in a process have been completed, by whom and when. With this level of detail, it is much easier to determine what point in a process may require intervention in order to have a timely and successful completion.

The topics discussed in this paper include:

- Introduction to HP AdminFlow architecture

- Techniques used to streamline time consuming, manual processes

Upon completion of the session, the participants will have a better understanding of how to:

1] Use AdminFlow as a foundation element in their current system architecture

2] Take advantage of core AdminFlow features to derive new solutions

3] Use AdminFlow to better manage existing processes, speed up processing time, and redirect

efforts from administrative chores to core business activities.

Introduction to HP AdminFlow architecture

AdminFlow is Hewlett-Packard's Business Administration Workflow System. AdminFlow provides all of the components that make up a basic workflow system, while providing tools to enable the integration of your existing applications into the system.

What is a Workflow?

A workflow, or a business process, is a set of activities and rules, which define how these activities should be completed. These activities and rules collectively achieve an objective, for example processing a Travel Request. Each activity within a workflow is an action, or set of actions, which represents one logical step within the workflow. An activity will generate one or more work items; where a work item is a unit of work sent to a participant for action. The participant might be a person, a machine or an application, and is referred to as a process participant.

Typically a workflow defines:

- the names of the activities.
- the flow from one activity to the next.
- the nature of the activities: whether they are general activities, milestone activities, decision activities
- activity routings to particular workers, work groups, or services.
- the data necessary to complete each activity.
- scheduled and actual start dates, end dates, and deadlines for activities.

  A workflow has a clearly defined start point, a set of one or more activities and a clearly defined end point. A workflow can be initiated by an employee, a business application (such as an electronic form from an Electronic Data Interchange system), an event (such as the time of year, a stock market event), or another workflow. Workflow management is the definition and automated control of business processes according to a set of rules.

  AdminFlow – A Workflow System

  AdminFlow is based on an object model compliant with the Object Management Group Common Object Request Broker Association (OMG CORBA) specification for a distributed object environment. It utilizes a fully recoverable, relational database running the AdminFlow Engine as a state machine built for speed and reliability.

  Within AdminFlow, the Process Engine decides what action needs to be completed as a result of workflow process definition and the Resource Executive decides who (or what) completes the action. In other words, the Resource Executive identifies the process participant. The Resource Executive makes this decision using the information about your organization that you provide to it, plus the rules that define how to obtain the information. These rules are referenced within the process definition. Having allocated a resource to an action, the Resource Executive returns the resource information to the Process Engine and the Process Engine sends the work item to the process participant.

  Separating the what activities from the who activities provides for maximum flexibility in the workflow system. For example, you can have multiple Resource Executives if one becomes a bottleneck for the Engine.

  AdminFlow supports more than the simple concept of a "role" and extends this to an organizational management hierarchy enabling rules such as "send this to the first person above the sender who is authorized to sign off $10,000." By employing both role and organizational services, AdminFlow allows the complete decoupling of the process from the people who do the work.

  AdminFlow also provides two types of client interfaces for users: a web client interface and an electronic mail client interface.

  AdminFlow can be considered as following a four-tier architecture, where the tiers are:

- AdminFlow Server comprising a single:
- Process Engine
- Resource Executive
- Oracle Resource Agent
- Data Dereferencer
- Template Server
- Audit Logger
- Process Monitor
- Workflow Clients (Web browser and e-mail)
- Worklist Server (for serving the Web browser interface), or E-mail Feeder (for serving e-mail users)
- Database

  This is an Oracle database and holds information relating to the Engine, Data Dereferencer, Audit Logger and Engine. A schema defining the data for these components is provided as part of your AdminFlow system. Typically, an AdminFlow implementation has one AdminFlow Server, one or more Worklist Servers, each on a separate system, and/or a number of e-mail users accessing the AdminFlow system through an E-mail Feeder.

  The following sections describe the AdminFlow components in more detail.

  Process Engine

  The Engine stores and manages all the information about the work in progress within your workflow system. It executes workflow definitions, identifying the activities that need to be completed. The Engine has the master store of the work items that are being processed in the system, therefore if a work item is lost for any reason it can be resubmitted by the Engine.

  Early workflow systems combined activity-related data, resource information and the processes, as one unit. Within AdminFlow:

- the workflow process is defined separately and loaded into the Engine.
- the Engine identifies the next activity to complete.
- the Resource Executive allocates resources to an activity as a separate service.
- activity related data, such as spreadsheets, is stored separately in a database and is made available through the Data Dereferencer (since this data is not required by the Engine for managing processes).
- users send and receive work items using Web or e-mail clients.
- E-mail systems are accessed through Transport Feeders and the Worklist Server provides access for users with Web browsers.

  Many simple workflow systems are based on messaging systems combined with electronic forms packages. The AdminFlow model using an Engine and Resource Executive in combination with e-mail systems and Web servers, provides a far more reliable and flexible system than the simple messaging-based workflow systems. This is because messaging-based workflow systems cannot use organizational services in the same way as AdminFlow does; they rely on specific e-mail addresses directly related to individuals to route work items. Therefore any changes in the organization require modifications to the e-mail addresses within the electronic form, making the system potentially unreliable and costly to administrate. In addition, you cannot collect status information from an e-mail-based workflow system, which means the system cannot recover from a failure, nor can it guarantee information is not lost.

  Having an Engine allows you to record events and statistical information about your workflows and as a result improve the workflow processes that you have designed.

  Process Definition

  In order to execute workflow processes, AdminFlow first needs the processes to be defined. You can enter process definitions using ProcessWise WorkBench. ProcessWise WorkBench provides a graphical interface that you can use to create and modify your process definitions. Process definitions must be in a form that the Engine understands, so by using a tool, such as ProcessWise WorkBench, you make sure that your process definitions are correct before they are loaded into the Engine and executed.

  A process definition can be a simple, single path, definition, or a more complex multi-path definition, which has decision points. When you create a process map, you define the data flow within the process, that is, the data items that you want to use for the process. You must define all the data items that are required to complete each activity. These data items and their characteristics are collectively known as a Case Packet. The fields shown in the figure below are items found in the Case Packet.

  The process definition also contains information about the resource that is responsible for completing each activity within the process. Resource Rules are used to identify suitable resources for an activity. For example, if an activity requires a resource of Manager, there should be a Resource Rule called manager to define how to find an employee’s manager. Some rules are provided with AdminFlow, and you can also define your own.

  You can also assign log levels within a process definition. These log levels specify the granularity at which activities are logged in the events database. The information logged provides the basis of the administration and monitoring tools supplied with AdminFlow.

  Data Dereferencer

  The Data Dereferencer provides two functions within AdminFlow.

  The first is to remove data not required by the Engine for processing work items before the work items are passed to the Engine. The Data Dereferencer then replaces this data when the Engine sends a work item out to be addressed.

  The second is to manage the custom forms required for particular activities, such as initiating a process.

  The application specific data and custom forms are stored in a repository. The Data Dereferencer provides the interfaces between the Engine and the repository. The following diagram shows the logical division between the application specific data and the custom forms. Both the application data and the custom forms are stored in the same database, but they are completely independent of each other.

  When a user is sent a work item, resulting from an activity, which needs a custom form, the Data Dereferencer adds the custom form for the activity. These custom forms are taken from the forms repository, where they were placed as part of defining the process.

  Work items are routed to each of the users, systems or applications that need to action them. The Data Dereferencer adds forms and attachments to and removes attachments from these work items. The Data Dereferencer removes the attachments before the work item is handed over to the Engine and replaces the attachments when the work item is routed from the Engine to the next participant in the workflow. This maximizes the efficiency of the Engine by removing all information not required by the Engine when processing work items. This also allows users to participate in workflows when they are off line as the work item is always complete, that is, all related forms and attachments are part of the work item.

  Resource Executive

  The Resource Executive is the AdminFlow component used by the Engine to assign resources to activities. These activities are specified when the process is defined, as part of the process definition.

  The activity definition includes information about the type of resource that should complete it. The Engine gives this information to the Resource Executive. From this information, the Resource Executive selects a Resource Rule, which can be used to identify a suitable resource. In the example of a Travel Request, the request might need to be sent to a manager who has authority to sign off the $5000 request. In this case, there is a Resource Rule to define how to identify this resource. The Resource Rule specifies which Resource Agents are responsible for resolving the function. These Agents then identify the traveler and their manager (who might need to be at a particular level to authorize the request) using organizational information in the Resource Repository. The Agents then identify the manager’s mail address from the Mail Directory and gives this information back to the Resource Executive.

  To summarize, rules specify which Resource Agents the Resource Executive should use to assign resources, and what those agents will do. What the agents are able to do is determined by the functions they provide. Through rules, the Resource Executive makes function calls to Resource Agents, which then perform the work defined in that function and return resource information to the Resource Executive. A function is a type of query on an information source, for example, mapping an employee number to an employee name.

  The figure below shows the web page that the appropriate manager would see:

  In order to make decisions about who, or what, should complete an activity, the Resource Executive and the Resource Agents need access to information about your organization, such as, employee numbers, employee names, organizational hierarchy information and contact addresses (for example, e-mail addresses). You need to decide how you are going to make this information available. You might decide to enter all your resource information, including the information that you have in your own organizational database, into the Repository Schema, or you might decide to split your resource information across the Resource Repository and your own database. This decision is based on the amount of data and how often it changes.

  As an example, if you have a small amount of static data, you would probably maintain this data in the Resource Repository, where it is automatically available to AdminFlow. However, if you have a large amount of data, or your data changes frequently, you can choose to keep it in your own repository, and supply your own Resource Agent functions to access the data in your organizational database. You can do this by modifying the Resource Agent functions supplied with AdminFlow. The Resource Repository and tools for entering information into the Resource Repository, are supplied with AdminFlow.

  Resource Agents

  Resource Agents are used by the Resource Executive to access specific repositories and manipulate resource information. The Resource Executive selects a resource (or resources) to complete an activity by executing rules. These rules contain a series of calls to functions, which are supplied by Resource Agents. You can provide rules, which specify the Resource Agent to use to resolve you own resource queries. Rules are also supplied with AdminFlow.

  Resource Agents interface to specific types of information source, for example, the Oracle Resource Agent uses the Oracle directory. The Oracle Agent is an example of an external agent. External agents are used to access data repositories that are external to the AdminFlow system.

  Oracle Resource Agent

  The Oracle Agent is used by the Resource Executive to obtain resource-related information from an Oracle database. This resource information might be, employee badge numbers, employee’s name, contact information or organizational hierarchy information. AdminFlow provides a basic schema for an Oracle database. The schema defines the data required for a typical AdminFlow system, and is used for the example processes provided with AdminFlow.

  Using the Resource Repository schema optimizes the communication between the source of information and the Resource Executive. Your organization’s existing databases will be optimized for its own applications, and might not provide all the information required by AdminFlow. However, if you think the information that you have in your existing database is suitable, you can use your own database by modifying the functions of the Oracle agent. You can also write your own SQL procedures for the Oracle agent and add them to the Oracle agent function table.

  Resource Repository Schema

  Before AdminFlow can execute the processes you define, it must be able to access the resource data required for these processes. This is necessary as the Resource Executive needs to access resource information when it assigns a resource(s) to a role. You must make sure that your resource data is available to AdminFlow. The Resource Repository schema defines a basic set of resource information, which is used in the example processes provided with AdminFlow.

  Note that it is very likely that your organization will need additional resource information for the processes that you define. The Resource Repository schema has some scope for being extended, but you might need to use your own information source as a repository for your resource information. The Resource Repository schema is not intended as an enterprise-wide information source.

  The Resource Repository schema is designed for a relational database. The advantages of using a relational database, such as Oracle, are that it allows you to upload from existing data sources, provides easy data replication to a central repository and easy access for management from HTML and Java.

  Workflow Clients

  For AdminFlow, a workflow client is a component that you can use to interface with AdminFlow to action your work items. There are other clients that you use to monitor and manage the AdminFlow system.

  AdminFlow provides two workflow client interfaces:

- A Web client interface through a Worklist Server, which provides a direct connection to AdminFlow.
- An e-mail interface through the E-Mail Plug-In, that provides both a direct connection, and can be used off line.

  Work items are sent from AdminFlow to your client. This is either to a queue at the Worklist Server, or a mail folder for an e-mail client. You can then request your current list of work items from your client as required. When you have completed a particular work item, it is returned to AdminFlow for processing.

  In order to start a process at your workflow client, you need a template for the process. You therefore need to have a copy of the templates for all the processes that you want to initiate locally at your workflow client. Updates to these templates are automatically sent to the workflow clients.

  You have the option of building your own AdminFlow clients or extending the functions of the clients supplied with AdminFlow. As an example, you could add a function to your client that allows you to suspend, or hold, a workflow and start a secondary workflow. You might want to do this if you have been asked to sign off a large amount of money as part an activity, and you want to obtain comments and votes from other people.

  The following web page would be presented to the appropriate travel agent:

  The same information does not have to be presented to each user. Fields in the form (case packet data) can be individually set to read-only or modifiable at any activity in the process. It is also possible to provide a different subset of the case packet data at each activity of the process and merge them together before completing the process. This allows process participants to focus on information that is relevant to them. The following figure shows the final result of the process. The initiator of the process would see this web page.

  Worklist Server

  The Worklist Server provides the Web interface to AdminFlow and gives you direct access to AdminFlow from your Web client. If no user-defined forms are supplied, the Worklist Server dynamically generates forms, referred to as META forms, to present the user. The Worklist Server stores work items for users in work lists and provides the framework for supporting and managing multiple users. In particular using the Worklist Server you can:

- Create accounts for your users.
- Set personal configurations for accounts.
- Initiate new processes.
- Participate in workflows.
- Track the status of individual work items.

  You can have more than one Worklist Server in your organization; for example, you could have a Worklist Server for an individual building, or business function. In order to keep network activity to a minimum, each Worklist Server holds a copy of the template work items for all the workflows that its users will want to initiate. These template work items are requested by the Administrator on behalf of the users of the AdminFlow system and processed by the Template Server.

  The Administrator for the Worklist Server is responsible for making sure that new and updated templates for workflows are always available for their users.

  Shared Worklist

  Work items can be sent to a shared work list or a personal work list, and individual users can have both. In the case of a shared work list, any one of a team of users can select individual work items from the shared work list. When the work item is selected, it is moved to the user's personal work list. All work items in a shared work list are visible to other members of the group. However, when a work item is selected from the shared work list, it is locked, so another user cannot access it. Shared work lists are useful for teams who are working on a common business function, for example, dealing with Travel Requests.

  Mail Client

  This is the e-mail interface to AdminFlow. You use an e-mail client to either access AdminFlow directly, or you can use e-mail when you are off line. For example, if you are using a laptop computer to work away from the office (subject to your e-mail system supporting disconnected clients).

  Work items are delivered to your e-mail client’s incoming mail folder, in box, or filing cabinet. Templates for workflows that you want to initiate are also delivered to your incoming mail folder; these templates are delivered to you automatically. When you open an e-mail message containing a work item and then open the work item attachment, the AdminFlow E-mail Plug-in is run to present you with the work item. When you have completed the work item, it is sent back through the e-mail system to AdminFlow. If you are working off line, the work item is sent to AdminFlow when you next connect to the network.

  The E-mail Plug-in:

- Displays the work item to you using the appropriate form
- The E-mail Plug-in presents you with a table of contents containing the contents of a work item, or the template of a work item.
- Allows you to make requests for templates for new and updated workflow definitions and stores the templates locally so you can initiate workflows using them.
- Invokes any programs associated with a work item, for example, Microsoft Excel, if the work item contains a Microsoft Excel spreadsheet.
- Provides information about the status of the processes that you have initiated.

  Management Clients

  There are several management client interfaces to AdminFlow, which enable you to manage all aspects of your AdminFlow system. These interfaces allow you to:

- Load resource information into the Resource Repository.
- Monitor workflows. There are three tools that you use to monitor workflows:
- Process Tracker
- Business Process Monitor
- System Monitor
- Manage the AdminFlow system.

  There is a web-based AdminFlow System Administration interface, which you can use for managing the AdminFlow system. Using this interface you can:

- start and stop the AdminFlow components.
- log information for the AdminFlow components.
- obtain status information about the Engine.

  Monitoring Workflows

  AdminFlow provides three interfaces to monitoring your workflows. These are graphical interfaces and you can display monitoring information as a bar chart or in the form of a process map. All the monitoring interfaces are Web-based. This means that you have the flexibility to modify the HTML files, and therefore the interfaces, to suit your own requirements. The AdminFlow Audit Logger maintains information about workflows. The audit information is divided into personal, process and system information as follows:

- Process Tracker, for information about your workflows.

  This allows you to track individual processes that you have initiated and are involved in. As an example, you might have two Travel Requests being processed. A summary of these processes is displayed to you on request. The Process Tracker is designed for particular users to track what is happening with their workflows. Tracking information is also accessible through the Worklist Server.

- Business Process Monitor, for the person who owns the process definition.

  This allows you find out everything about a particular process. For example, these might be all instances of a Travel Request processes, or all instances of an Expense Claim processes. You can also obtain statistics relating to the status of processes from this interface, for example information about backlogs.

  The Business Process Monitor is designed for use by the person who is responsible for the individual processes, and making sure that they fulfill the requirements they were designed to meet.

- System Monitor, for the person responsible for managing the AdminFlow system.

  This allows you to get performance statistics about the Engine. These enable you to determine how heavily the Engine is loaded. The System Monitor is designed for the person who is responsible for making sure that the AdminFlow system is operating smoothly.

  Each interface provides access to particular views, although there is deliberately some overlap between the interfaces and the views they provide.

  Audit Logger

  The Audit Logger records current and past AdminFlow events; AdminFlow provides a schema that defines the structure of these events. The level of logging information you require is specified when you define your processes.

  The Audit Logger stores event information in an Audit Logger database. Understanding the structure of the event database means that you can access it and, if you want to, generate your own reports based on the information in the database. The Process Monitor interfaces use the information stored by the Audit Logger to present information about the AdminFlow system.

  There is a buffer between the Audit Logger and the Engine. This is so the Audit Logger does not impact the performance of the Engine when writing event logs to the database. The buffer also means that events are not lost if the Audit Logger fails.

  Be aware that the Audit Logger might not be able to record events as fast as the Engine creates them, so there might be a delay between the event and when it is displayed in one of the monitoring interfaces.

  The Audit Logger stores the following information:

- Process Instance information, for example when process instances are started and when they complete.
- Node Instance information.
- Activity Instance information, for example, when they start, when they are sent and received, and when they finish.
- Performance Statistics, for example, the number of process definitions the Engine is dealing with at any one time.
- Information about the process maps, which is used for display purposes.

  Transport Feeder

  A Transport Feeder transports work items between the CORBA transport used by AdminFlow and another transport. The Transport Feeder passes these work items between transports without any additional processing.

  An example of a Transport Feeder is the E-mail Feeder, which provides an interface between the CORBA transport used by AdminFlow and the SMTP mail transport. The E-mail Feeder supports all the protocols in the data; as an example, if the work item is marked as urgent within one transport system, the work item is also urgent within the transport system that it is being sent to. Transport Feeders do not change any information in the AdminFlow work item as they pass the work item between the two transports. The Feeder places a wrapper around the work item making it suitable for the destination transport.

  The Resource Executive allocates Transport Feeders based on the address of the process participant. You can have one or more Transport Feeders for each transport. If there you have multiple Transport Feeders for the same transport, the Resource Executive uses load balancing to balance the load across the Feeders.

  Techniques used to streamline time consuming, manual processes

  When setting up your workflow information, you will need to provide "who", "what" and "when" information. For example:

- "who" information, is resource data within your organization, for example:
- e-mail addresses.
- organizational information, used by the Resource Executive to identify the employee’s manager
- employee records, used by the Resource Executive to map employee number to employee signoff and authorization information.
- rules to determine which resource to identify and also to define how to make decisions when there is more than one resource that can complete a task. As an example, an employee might have more than one manager who can authorize the Travel Request.

  Most of this resource information probably already exists in databases within your organization; for example, e-mail addresses in your e-mail directory. This resource information needs to be made available to AdminFlow.

- "what" information is held in a process definition, in this case the actions required for a Travel Request.
- "when" information is held in a process definition and defines the order in which the individual activities are completed, for example, a Travel Request must be authorized before any flights can be booked.

  References

  HP AdminFlow Overview Manual