|
|
| (13 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]].'' |
| | | | |
| Riga 7: |
Riga 5: |
| | 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]]). | | 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]]). |
| | | | |
| − | == Creation and basic settings ==
| + | Workflow configuration steps. |
| − | | + | * [[Workflow configuration steps - Master data|Master data]] |
| − | The list of ''[[glossary|workflows]]'' and functionalities to update and create new ''[[glossary|workflows]]'' are by default made available, by default, at the following menu entry: '''''General/WorkFlow/WorkFlow Engine'''''. The list of available ''[[glossary|workflows]]'' appears as in the screen below.
| + | * [[Workflow configuration steps - Creation and basic settings|Creation and basic settings]] |
| − | [[File:Workflow list screen.JPG|left|thumb|850x850px|Workflow list screen]] | + | * [[Workflow configuration steps - Statuses|Statuses]] |
| − | | + | * [[Workflow configuration steps - Transitions|Transitions]] |
| − | In the screen some commands are made available by means of specific buttons:
| + | * [[Workflow configuration steps - Fields|Fields]] |
| − | | + | * [[Workflow configuration steps - Grants|Grants]] |
| − | {| class="wikitable"
| + | * [[Workflow configuration steps - Form|Forms]] |
| − | ! Command !! Performed functionality
| + | * [[Workflow configuration steps - ASM Views| ASM Views (optional)]] |
| − | |-
| + | * [[Workflow configuration steps - Decision matrixes|Decision matrixes (optional)]] |
| − | |'''DELETE''' || Deletes one or more selected ''[[glossary|workflows]]''.
| + | * [[Workflow configuration steps - Groups association to workflow|Groups association (optional)]] |
| − |
| + | * [[Workflow configuration steps - MDMM| MDMM (optional)]] |
| − | |-
| + | * [[Workflow configuration steps - Notifications|Notifications (optional)]] |
| − | | CHANGE STATUS || '''''Bold and italic'''''
| + | * [[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)]] |
| − | | ADD NEW || '''''Bold and italic'''''
| + | : [[More|[More]]] |
| − |
| |
| − | |-
| |
| − | | COPY || '''''Bold and italic'''''
| |
| − |
| |
| − | |}
| |
| − | | |
| − | 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 ===
| |
| − | | |
| − | The li
| |
| − | | |
| − | 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.
| |
