|
|
(20 versioni intermedie di uno stesso utente non sono mostrate) |
Riga 1: |
Riga 1: |
− |
| |
− | == Introduction ==
| |
| 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]].'' | | 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]].'' |
| | | |
| 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]]''. | | 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]]''. |
| | | |
− | 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. | + | 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]]). |
− | | |
− | == New process ==
| |
− | | |
− | A process is caractetized by:
| |
− | * Type. itmSUITE® call it ''[[Glossary|Ticket type]]''.
| |
− | * Status ''[[Glossary|Workflow status]]''
| |
− | * 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.
| |
− | * Which one of the idenfied ''[[Glossary|Workflow status]]' is a Final Status?
| |
− |
| |
− | 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 Roles ===
| |
− | | |
− | At workflow level a user can be configure with 17 ''[[Glossary|roles]]''. ''[[Glossary|Roles]]'' can be:
| |
− | * 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 9-legacy status: | |
− | | |
− | * Default
| |
− | * Opened
| |
− | * Defined
| |
− | * Runinng
| |
− | * In Charge
| |
− | * Completed
| |
− | * Closed
| |
− | * Reopened
| |
− | * Cancelled
| |
− | | |
− | this status are called legacy, because the system act in a particular way when they are reached by ''[[Glossary|ticket ]]''
| |
− | | |
− | The ''[[Glossary | Administrator]]'' can create others ''[[Glossary|status]]'' that will be used to drown the desire workflow
| |
− | | |
− | === Define a Transition ===
| |
− | | |
− | Transition are the connection between ''[[Glossary|status]]''. Definie a transition means:
| |
− | * select starting ''[[Glossary|status]]'' , say Defualt
| |
− | * select ending ''[[Glossary|status]]'' , say Opened
| |
− | * choose the ''[[Glossary|role]]'' authorized to perform this transtion, e.g. Creator
| |
− | We can create a One-way transition or bi-directional transition.
| |
− | | |
− | Many [[Glossary|roles]] can be enabled to perform a single transition.
| |
− | | |
− | === Form Designer ===
| |
− | | |
− | User interact with the workflow via ''[[Glossary|Ticket form]]''. To create a Ticket form the ''[[Glossary|administator]]'' can :
| |
− | | |
− | * Identify the necessary standard field
| |
− | * Create custom field
| |
− | * Create Form layout
| |
− | | |
− | Form designer , think a form as a blank page, than the ''[[Glossary|administator]]'' can create Sections, and devide it in columns and compose the page inserting the fields.
| |
− | | |
− |
| |
− | === Grant Management ===
| |
− | | |
− | ''[[Glossary | Administrator]]'' can keep Visible or Mandatory some field based on ''[[Glossary | Ticket Status]]''and
| |
− | ''[[Glossary | Resource role]]''
| |
− | | |
− | For example, ''[[Glossary | Ticket creator]]'' see the necessary fields to define an issue, but ''[[Glossary| Service desk operator]]'' that keep in charge the issue has available the first set of fields plus the once necessary to Categorize and Analyse the issue. When the ''[[Glossary | Ticket ]]'' will be completed the ''[[Glossary | Ticket creator]]'' should have the orignal set of fields plus the solution.
| |
− | | |
− | == Enable Services ==
| |
− | | |
− | A worflow can be live only if one o more services used the configured process. So that each workflow need at least on service. Service can act a little bit diffrently form one to enother, eg: some fields are hide for the Service A and visible per the Serive B; but all should be based on the same sets of ''[[Glossary|status]]'', having the same ''[[Glossary | Ticket ]]'' fields.
| |
− | | |
− | | |
− | == Manage Notification ==
| |
− | | |
− | Sometime when the workflow ''[[Glossary|status]]'' changes some ''[[Glossary|roles]] ''or person should be informed. This is possible due to Notification.
| |
− | | |
− | | |
− | Notification can be manage for Event like:
| |
− | * Ticket ''[[Glossary|status]]'' changes
| |
− | * Ticket ''[[Glossary|Solution Group]]'' changing
| |
− | * ''[[Glossary|Ticket Activity ]]''changing.
| |
| | | |
− | Each notification can be addresses to different subjects.
| + | Workflow configuration steps. |
| + | * [[Workflow configuration steps - Master data|Master data]] |
| + | * [[Workflow configuration steps - Creation and basic settings|Creation and basic settings]] |
| + | * [[Workflow configuration steps - Statuses|Statuses]] |
| + | * [[Workflow configuration steps - Transitions|Transitions]] |
| + | * [[Workflow configuration steps - Fields|Fields]] |
| + | * [[Workflow configuration steps - Grants|Grants]] |
| + | * [[Workflow configuration steps - Form|Forms]] |
| + | * [[Workflow configuration steps - ASM Views| ASM Views (optional)]] |
| + | * [[Workflow configuration steps - Decision matrixes|Decision matrixes (optional)]] |
| + | * [[Workflow configuration steps - Groups association to workflow|Groups association (optional)]] |
| + | * [[Workflow configuration steps - MDMM| MDMM (optional)]] |
| + | * [[Workflow configuration steps - Notifications|Notifications (optional)]] |
| + | * [[Workflow configuration steps - Ticket activities|Ticket activities (optional)]] |
| + | * [[Workflow configuration steps - Ticket message templates|Ticket message templates (optional)]] |
| + | * [[Workflow configuration steps - Unique workflow key|Unique workflow key (optional)]] |
| + | : [[More|[More]]] |