A workflow defines a business process. It defines a sequence of operations where each operation contains one or more actions which define the sequence of data to be collected or displayed. A workflow defines a sequence of operations that must be executed to complete a task and all the details around this including:
- Who can perform each operation?
- How long should it take?
- What instructions must be presented to the operator?
- What tools are required?
- What material is required?
- What data must be collected?
- Etc.
Examples of workflows are:
- Routing to manufacture a new lot.
- Rework process to be followed in the event of a non-conformance.
- Repair process to be followed in the event of a customer return.
A workflow consists of:
- The workflow header information: Configured in the New Workflow screen and includes information relating to the product (if applicable) and type of workflow. The level of control to be applied to the workflow is determined by the workflow type it belongs to.
- The workflow design: Configured in the Design Workflow interface and is the end-to-end process to be performed and consists of a set of operations which contain elements such as actions, instructions, tools, skills, etc.
Major and Minor Workflow Versions
Workflows are versionable to support change control.
Workflows have a major and minor version. Minor up-versions can be used to minimise approval admin where a change does not change the version of the finished good being produced or require an associated change to the BoM/recipe. For example, to update instruction text to improve clarity, without changing the method of manufacture.
Major versions can be used to enforce broader recipe and BoM approval for changes that change the version of the finished product or require broader changes to BoMs. For example, to change a process to sub-contract an element of manufacturing would need a change to both BoMs and workflow.
Workflow controls
A workflow can be controlled or non-controlled. The Workflow Type that the workflow uses determines its control level.
Controlled workflows are typically used in regulated environments where strict control is required. No edits are permitted to an approved workflow version and any changes to workflow require a new version to be created for approval. Controlled workflows are not allowed to reference uncontrolled shared entities such as shared expressions.
Non-controlled workflows are used to minimise administration where strict control is not required. Edits to approved workflow versions can be made without requiring a new version or explicit approval process.
Workflow classes
There are three workflow classes: product-specific, shared and template.
- Product-specific are standard workflows that apply to a single product.
- Shared workflows can be used for multiple products when they share common processes. A common use case for shared workflows is non-conformance or rework processes that are common to many parts. The products that a shared workflow applies to are defined by the recipes created/approved.
- Template workflows serve as a base for creating product-specific workflows. New products can inherit a copy of template workflows without having to recreate it from scratch. This will create a product-specific workflow which can then be tailored to a particular product.
Approval processes
Workflows may have the following statuses:
- Draft: The workflow is in draft.
- Pending Approval: The workflow is pending approval.
- Approved: The workflow was approved.
- Pre-production: Workflows of this status may only be used for pre-production jobs and by users with the appropriate test permissions. For more information.
- Pending Virtual Test: Workflows of this status may only be used for virtual test jobs by users with the appropriate permissions.
- Obsolete: An obsolete BoM version prevents the creation of new items based on that BoM version. However, existing items will continue to reference an obsolete BoM version and if in WIP, may be completed.
For more information on statuses, see Approval and Test Statuses.
Workflow versions of a controlled type are created in draft status and then submitted for approval by changing to pending approval status. They must then be approved by a user with the appropriate permissions which will change the status to approved before being used in production. Separate recipe approval may also be required. It is not possible to edit an approved version of a controlled workflow without creating a new workflow version.
Workflow versions of a non-controlled type may be created directly in approved status (by a user with appropriate permissions) without the need for separate approval. Some changes are permitted to approved versions of non-controlled workflows without up-versioning.
Obsolete status and job management
Workflow versions can be set to obsolete status. This prevents the creation of new items based on an obsolete BoM version. However, existing items will continue to reference an obsolete BoM version and if in WIP, may be completed. If live jobs must be stopped when a workflow is obsoleted, then these jobs should be put on hold to prevent further work.
Shared workflows
Workflows of “shared” class can be referenced by multiple products. The products valid for a workflow are defined by the approved recipes that reference the workflow: see below.
Managing workflows
To create a usable workflow, you need to:
