|
|
(34 versioni intermedie di 2 utenti non mostrate) |
Riga 1: |
Riga 1: |
| + | A ''[[glossary|workflow]]'' is a business process, made of a sequence of activities transforming inputs into outputs with the aim to achieve specific outcomes. With itmSUITE® it is possible to support the execution of ''[[glossary|workflows]] ''by means of its embedded ''[[glossary|workflow engine]].'' |
| | | |
− | == Introduction ==
| + | itmSUITE® makes available a set of predefined ''[[glossary|workflows]]'' by means of ''[[glossary|workflow cartridges]]''. These preset ''[[glossary|workflows]]'' can be modified and new ''[[glossary|workflows]]'' can be added. All ''[[glossary|workflow]]''[[glossary|s]] can be exported and re-imported by means of ''[[glossary|workflow cartridges]]''. |
− | What is a workflow?
| |
− | is a process applied to a Service. Two main information’s we need to know when we speak about a workflow:
| |
− | * Process implemented
| |
− | * Services enabled.
| |
| | | |
− | What is a process?
| + | This guide will go through the key steps needed to create a ''[[glossary|workflow]]'' from scratch, assuming the basic itmSUITE® configurations (''[[glossary|company]]'' and its related master data, ''[[glossary|services]]'', etc.) were previously completed (see [[itmSUITE® - Introduction to basic configuration#Introduction|Introduction to basic configuration]]). |
− | A process is characterized by statues linked each other with transitions. Each transition can implement rules, transition rule, that enable the user to perform or not this transitions.
| |
− | User interact with a process using an interface, form, and each field of the form can be used to compose a logical rule condition.
| |
| | | |
− | Before starting to create a new Workflow we should identify if there is a process like the one we wants to create already developed on the system. If yes, we can add our service to an existing workflow.
| + | Workflow configuration steps. |
− | | + | * [[Workflow configuration steps - Master data|Master data]] |
− | If the our process has statues or form field or transition rules that are not implemented we have to create new workflow.
| + | * [[Workflow configuration steps - Creation and basic settings|Creation and basic settings]] |
− | | + | * [[Workflow configuration steps - Statuses|Statuses]] |
− | == New process ==
| + | * [[Workflow configuration steps - Transitions|Transitions]] |
− | | + | * [[Workflow configuration steps - Fields|Fields]] |
− | A process is caractetized by:
| + | * [[Workflow configuration steps - Grants|Grants]] |
− | * Type. itmSUITE® call it ''[[Glossary|Ticket type]]''. | + | * [[Workflow configuration steps - Form|Forms]] |
− | * Status ''[[Glossary|Workflow status]]'' | + | * [[Workflow configuration steps - ASM Views| ASM Views (optional)]] |
− | * How ''[[Glossary|Workflow status]]'' are connecting. Is only a one direction transtion, from status A to B, or we can came back to A, bidirectional transition.
| + | * [[Workflow configuration steps - Decision matrixes|Decision matrixes (optional)]] |
− | * Which one of the idenfied ''[[Glossary|Workflow status]]' is a Final Status? | + | * [[Workflow configuration steps - Groups association to workflow|Groups association (optional)]] |
− |
| + | * [[Workflow configuration steps - MDMM| MDMM (optional)]] |
− | Once we have drawn our process we have to think which ''[[Glossary|Resource]]'' , or better witch ''[[Glossary|Role]]'' can be enabled to execute the transition. Then we can design the Form and give a grant to the ''[[Glossary|Resource]]. ''
| + | * [[Workflow configuration steps - Notifications|Notifications (optional)]] |
− | | + | * [[Workflow configuration steps - Ticket activities|Ticket activities (optional)]] |
− | === Workflow Roles ===
| + | * [[Workflow configuration steps - Ticket message templates|Ticket message templates (optional)]] |
− | | + | * [[Workflow configuration steps - Unique workflow key|Unique workflow key (optional)]] |
− | At workflow level a user can be configure with 17 ''[[Glossary|roles]]''. ''[[Glossary|Roles]]'' can be:
| + | : [[More|[More]]] |
− | * Static , Application Level type
| |
− | * Dynamic , Project / Service or Workflow roles type
| |
− | | |
− | Static ''[[Glossary|Role]]'' are the once assigned to the user, Dynamic role are configured to the resource due to is belonging to a ''[[Glossary|Service]]'' or a ''[[Glossary|Solution Group]]'' or a ''[[Glossary|Client Organization Unit ]]'' or because the resource act as Creator of ''[[Glossary|Ticket]]''
| |
− | | |
− | Here below the table with the role description:
| |
− | | |
− | {| class="wikitable"
| |
− | ! Role !! Type !! Note
| |
− | | |
− | |-
| |
− | |Requester || ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]''
| |
− | |-
| |
− | |Resource || ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]''
| |
− | |-
| |
− | |Project manager|| ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]''
| |
− | |-
| |
− | |Manager|| ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]''
| |
− | |-
| |
− | |Administrator|| ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]''
| |
− | |-
| |
− | |Assegnee|| ''dynamic'' || ''[[Glossary|resource]]'' that has assigned a ''[[Glossary|ticket activity]]''
| |
− | |-
| |
− | |Creator|| ''dynamic'' || ''[[Glossary|resource]]'' that create a ''[[Glossary|ticket ]]''
| |
− | |-
| |
− | |Master SG Member|| ''dynamic'' || ''[[Glossary|resource]]'' included in ''[[Glossary|Master Solution Gruop ]]''
| |
− | |-
| |
− | |Master SG Manager|| ''dynamic'' || Manager of ''[[Glossary|Master Solution Gruop ]]''
| |
− | |-
| |
− | |OU Manager|| ''dynamic'' ||Client ''[[Glossary|Organization Unit ]]'' manager
| |
− | |-
| |
− | |Owner|| ''dynamic'' ||''[[Glossary|resource]]'' responsible for the ticket ''[[Glossary|ticket ]]''
| |
− | |-
| |
− | |SG Manager|| ''dynamic'' ||Manager of ''[[Glossary|Solution Gruop ]]''
| |
− | |-
| |
− | |Solution group member|| ''dynamic'' || ''[[Glossary|resource]]'' that belong to ''[[Glossary|Solution Gruop ]]''
| |
− | |-
| |
− | |TA SG Manager|| ''dynamic'' || Manager of ''[[Glossary|Solution Gruop ]]'' assigned to ''[[Glossary|ticket ]]''
| |
− | |-
| |
− | |Third level solution group|| ''dynamic'' || ''[[Glossary|resource]]'' that belong to ''[[Glossary|Third Solution Gruop ]]''
| |
− | |-
| |
− | |Ticket requester|| ''dynamic'' || ''[[Glossary|resource]]'' that has been marked as requester into ''[[Glossary|ticket ]]''
| |
− | |-
| |
− | |Ticket worker|| ''dynamic'' || ''[[Glossary|resource]]'' that has in charge the ''[[Glossary|ticket ]]''
| |
− | | |
− | |}
| |
− | | |
− | === Workflow Status ===
| |
− | | |
− | itmSUITE® enable the user to create how many status is needed to deploy is workflow. When the user create the workflow, the system create for him 4-legacy status:
| |
− | | |
− | * Default ''[[Glossary|status]]''
| |
− | * Open ''[[Glossary|status]]'' | |
− | * Cancel ''[[Glossary|status]]'' | |
− | * Close''[[Glossary|status]]'' | |
− | | |
− | this status are called legacy, because the system act in a particular way when they are reached by ''[[Glossary|ticket ]]''
| |
− | | |
− | Then the administrator ''[[Glossary | resource]]'' can others status ''[[Glossary|status]]'' that will be used to drown the desire workflow
| |
− | | |
− | | |
− | === Define a Transition ===
| |
− | | |
− | TBD
| |
− | | |
− | As example of Worflow status diagram see the image below
| |
− | [[File:workdflow status diagram.JPG|alt=|thumb|500x500px|Workdflow Status Diagram|none]]
| |
− | | |
− | | |
− | === Form Designer ===
| |
− | | |
− | TBD
| |
− | | |
− | === Grant Management ===
| |
− | | |
− | TBD
| |
− | | |
− | | |
− | == Enable Services ==
| |
− | TBD
| |
− | | |
− | | |
− | == Manage Notification ==
| |
− | TBD
| |