Documentation issues

Details

Category: Workflow

Published on Tuesday, 11 September 2007 23:18

Written by Anon.

Hits: 9415

Workflow is dynamic. You can change the business process without sending everyone to be retrained so bear this in mind with your documentation. Your documentation should be written to ensure that any changes which are made  can be done easily and without upsetting any aspects of the process.

Documentation for the operational user can be made available online with a URL included in the work item description. This documentation should contain help-line numbers, what to do if you receive a work item intended for someone else (you've left the department), FAQs, whether the user may create ad hoc attachments (the other users must be aware of the possibility if you want to make use of this functionality)...

Documentation for administrators should include how to perform periodic health-checks, how to add a new user to the process (and how to remove someone), what to do when a user is absent for a short period of time, contingency plans, list of counterparts in different parts of the process if the process is cross-application.

Technical documentation must include a complete catalogue of all workflows, tasks, business objects and roles used in the process. There is ample room within the system for documentation about the individual components but of particular importance  the events. These must be documented in the system, explaining how they are triggered (E.g. program xxx, status changes...). The workflow documentation should explain how the workflow is triggered (E.g. event, program...). Subflows should be labeled as such. Synchronization issues should be documented carefully so that changes can be made without jeopardizing the process

• < Prev
• Next >