|
|
| (23 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 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.
| |
| − | | |
| − | As example of Worflow status diagram see the image below
| |
| − | [[File:workdflow status diagram.JPG|alt=|thumb|500x500px|Workdflow Status Diagram|none]]
| |
| − | | |
| − | | |
| − | === 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 status changes
| |
| − | * Ticket Solution group changing
| |
| − | * Ticket activity changing.
| |
| − | | |
| − | Each notification can be addresses to diffrent subjects.
| |
