application note - livelink 9x workflow best practices - version 1-1.pdf
Post on 03-Jan-2016
Embed Size (px)
Livelink: Workflow and Best Practices Application Note
Livelink: ECM Workflow and Best Practices
Page 1 of 21
Livelink ECM Workflows and Best Practices
Abstract: Application Note dealing with Livelink Workflows and best practices for workflow design, management and use.
Release Date: Winter 2006 (Version 1.1)
Livelink Version: 9.5, 9.6, 9.7
Audience: Administrators WF Map Designers FAQs
This application note was written in an effort to enhance product information that may not be covered in documentation to date and to expand on information that is presently provided either in Livelink Training Courses or Customer Support materials.
The following document is an attempt to compile a number of best practices, recommendations and suggestions for the designing, editing and managing of Livelink 9.x workflows. While most of these best practices applies to most Livelink 9.x systems, this documentation has been written against versions 9.5 SP1, 9.6 and 9.7. Where behavior of Livelink is known to differ between versions, every effort will be made to identify the differences. Where necessary, specific areas of the best practices will be covered as follows: Understand Process WF Map Design Map Editor Management Attachments Permissions Best Practices Troubleshooting Dates and Times Users and Groups Replacement Tags Loopbacks Sub Workflows Export Testing WF & LiveReports Process Automation Item Handler Step
The following document will touch on some topics and subject matter that is currently covered in Livelink Training courses, including the following: 9x-120: Workflow Design I 9x-220: Workflow Design II 9x-221: Workflow Design III (if planning to use Item Handler step) 9x-223: Forms (if planning to use Forms) 9x-224: e-Forms (if planning to use e-Forms) Some or all of these courses should be considered as required training for individuals who plan on designing and maintaining Livelink Workflow Maps. For those individuals who plan to merely initiate, interact with WF instances and packages or manage the maps, this basic information is covered in the 9x-101 Knowledge Fundamentals and the 9x-201 System Administration courses.
Livelink: ECM Workflow and Best Practices Page 2 of 21
Introduction The Livelink Workflow is a powerful mechanism for automating and monitoring business processes. Livelink Workflows provide a set of features and options that allows an infinite number of unique workflows to be developed. Understanding and Illustrating the Current Business Process Begin small. Start with a small, simple process that is used by a limited number of people and continue to work on it until it works perfectly. Next, select a medium yet basic process that is used by a few more people and on a more regular basis and .perfect this workflow. Finally, select a larger, more complex process. By the time this larger, more complex process is automated, both elements and the process of Livelink Workflows and its users should be well established. The first step at arriving at any solution is to understand the problem. This aspect should be considered the most important step of the process; without adequate clarity of the business needs, it is unlikely that the solution will be on target. To understand the business process it is necessary to break it down into recognizable individual parts that can ultimately be mapped to features within the software. Once the participants (users), packages (materials) and path (route) have been identified for a given business process, this information can then be applied to the design of the Workflow Map and related processes. Identify the business Participants. Participants or if you prefer, users, refers to the individuals or entities who perform steps or make decisions as part of the business process. For example, these could be editors, reviewers, decision makers and managers. Participants can be specifically named individuals, groups or defined as a functional role. Participants are not strictly performers in the process, but include persons who manage or monitor the process as well. Participants can also be other systems that you wish to send data to or receive data from, such as an SAP system. Packages may consist of supporting or related materials that are part of the business process. The term package refers to the data or materials that are routed, reviewed and stored as part of the business process. Examples of packages include documents, metadata elements, electronic forms and comments. Path or route refers to the routes that the packages take in the process. Paths in processes are dynamic in nature and are determined via data values or decisions made by workflow participants. Diagramming, is the next logical step in documenting the WF process, involves creating a visual representation of the process using suitable media such as whiteboard or in an electronic format that lends itself to editing like Microsoft Visio. Where possible each view and vantage point needs to be considered ranging from the end user performing the work, to the decision makers to the people who will be managing the WF and business process. If the resulting WF and related processes is not suitable, then people will not buy into it nor use it. From the information gathered so far, begin determining what functionality you will need to complete the work at hand. Can your project be completed using the tools immediately at your disposal or is additional functionality or modules required? For example: HTML or Web Forms, e-Sign for digital signatures, e-Forms to make use of advanced Form capabilities XML Workflow Interchange (XML WFIC) to transfer XML data to other systems. At this point it may be helpful to tabulate or map out what steps and WF items would be helpful in meeting various business requirements. Where additional modules are required, that too should be noted.
Settings & Discussion
Best Practices Abridged List
Start small Understand the Problem Identify Participants Identify Packages Identify Path Diagram the Process No ad-hoc WF Maps Use groups, not one user Consider WF Proxy Consider data
Understanding the problem to be solved is crucial!
Livelink workflow is best used for structuring, standardizing, and automating processes that are repeatable and critical to the business. The biggest value is realized when using Livelink to automate cross-functional processes where traditional manual processes are slow, error-prone, lack visibility or traceability, and suffer the inefficiencies of departmental communication. Livelink will excel at repeatable, structured processes. Where a process could be considered a one-off, then it may be necessary to examine other alternatives, however, you could use Livelink to create one-off-workflows.
Livelink: ECM Workflow and Best Practices Page 3 of 21
First Pass at Mapping out the Process to Livelink Steps Story Boarding The following guidelines should be used when developing flow charts documenting the WF process: Processes should be mapped left to right and top to bottom Each flow chart item or shape should contain one discrete event For complex processes, a main process should be diagrammed with sub-processes in separate diagrams Compartmentalize your processes where possible, for example there may be separate stages of a business process where documents are created, marked up, approved and then released or published. Designing the Solution Designing the solution involves mapping the process that you have outlined above into the specifics of the Livelink Workflow to match each of the aspects of the business process as outlined earlier to standard features of Livelink Workflow. Many of the process requirements that have been identified can be directly mapped to specific workflow features, such as participants to workflow performer types. Other workflow features that dont have direct mappings can be used to enhance the process that is already in place, such as instructions on each step assignment to guide the user. Participants to Performers Mapping of process participants to Livelink Workflow performers is a straightforward process. First, it should be determined if the Initiator step is appropriate for the design. In situations where different users initiate the workflow and the process involves review or approval of that users submissions, the Initiator step should be used. WF Steps that have a group of participants can simply be mapped to an existing Livelink group or a new group can be defined. When the customer has identified individual Participants for certain tasks in the process, some questions need to be asked. If the process is time-sensitive, it is not a good idea to have a single user indicated as a step performer, even if that individual will be performing the step 99% of the time. It creates a problem should the user be unexpectedly absent (as no one else can perform the task). In this situation, it is a good practice to create a Group to perform the step. Include in the Group the person who normally performs the step and some additional personnel, such that one of them will be able to perform the task when the regular step performer is unavailable. This way the process will not stall due to one individuals absence. An alternative to this approach is to make use of the WF Proxy (more on this later). Packages to Data Elements There are three basic types of data that may become part of the WF packages that flow through their business process. Correctly determining the type of data will help to determine how it should be modeled in the workflow process. Some o