Dal 1996, architetture, metodologie, sviluppo software

Nel numero:

227 aprile
, anno 2017

Business Process Automation

VIII parte: Concludiamo la simulazione con Bizagi Studio

Eustachio Nicoletti

Sono sposato, ho due figlie e, per non soffrire troppo la situazione di minoranza, ho imposto la presenza in famiglia di Balu‘: un derivato setter inglese maschio. Sono laureato in Informatica e certificato PMP-PMI. Nella mia carriera professionale ho ricoperto i ruoli di responsabile di prodotto, responsabile di unità di business, tecnico-pre sales, progettista, delivery manager, business process analyst, software architect e project manager. I principali ambiti applicativi in cui ho maturato esperienze sono automazione dei reparti di neonatologia, human capital management, gestione dei processi della qualità, per aziende e organizzazioni piccole, medie e di dimensione internazionale. Attualmente lavoro come Business Process Analyst e Project Manager presso una azienda di Reggio Emilia esperta nello sviluppo di Sistemi Informativi per la Qualità.

MokaByte

Business Process Automation

VIII parte: Concludiamo la simulazione con Bizagi Studio

Picture of Eustachio Nicoletti

Eustachio Nicoletti

Introduzione

In questo ultimo articolo della serie sulla Business Process Automation, concludiamo la simulazione effettuata con Bizagi Studio cominciata nel numero precedente. Si tratta, come ricorderete, della creazione di un processo automatizzato di richiesta ferie, che vedremo nei dettagli in questo lungo tutorIntroduzione

Nell’articolo precedente, abbiamo cominciato ad affrontare un caso pratico, relativo al processo di Vacation Leave Request, ossia la classica “richiesta di ferie” che una generica organizzazione ha deciso di automatizzare. In particolare, abbiamo realizzato il modello del processo con Bizagi Modeler, e lo abbiamo importato in Bizagi Studio per realizzare il modello dei dati.

In questo numero, concludiamo appunto la nostra panoramica sull’automazione dei processi e sull’uso della suite Bizagi, portando a termine il nostro esempio.

 

Creazione delle “forms”

Una volta che è stato realizzato il diagramma del processo e il suo Data Model, siamo pronti per realizzare le form associate alle attività di tipo utente del processo. Le form sono usate per inserire e visualizzare le informazioni e consentire così l’interazione tra l’utente finale e il processo automatizzato.

Per realizzare le form del processo si deve selezionare Define Forms nella vista Process Wizard:

Figura 1 – Vista Process Wizard: Define Forms.
Figura 1 – Vista Process Wizard: Define Forms.

Attività: Register Leave Request

La prima form del processo che si deve realizzare è quella relativa all’attività di Register Leave Request. Questa dovrebbe avere il seguente aspetto finale:

Figura 2 – Attività Register Leave Request: form da ottenere.
Figura 2 – Attività Register Leave Request: form da ottenere.

 

Per realizzare questa form, procediamo come di seguito indicato.

Dopo aver selezionato Define form nel Process Wizard, verrà visualizzato il Form Designer, un diagramma che permette di selezionare solo le attività di tipo User Task. Quelle che non hanno ancora una form associata sono evidenziate con un punto esclamativo (figura 2).

Selezionando l’attività Register Vacation Request verrà visualizzata la finestra mostrata in figura 3.

Figura 3 – Form Designer.
Figura 3 – Form Designer.

 

Figura 4 – Register Vacation Request: Form Designer.
Figura 4 – Register Vacation Request: Form Designer.

 

Clicchiamo sul tab Controls per includere un Group. Facciamo quindi drag and drop dell’elemento Group sulla sezione DROP HERE; quindi, nel campo di inserimento che appare, scriviamo Request Information e selezioniamo l’icona di check.

Figura 5 – Inserimento di un Group.
Figura 5 – Inserimento di un Group.

 

Clicchiamo sul tab Layout per inserire un layout, che è un elemento che aiuta a distribuire le informazioni e renderle visivamente più accattivanti. Facciamo drag and drop del layout 50%-50% nella sezione DROP HERE del gruppo definito nel passo precedente.

Figura 6 – Inserimento di un Layout.
Figura 6 – Inserimento di un Layout.

 

Ora selezioniamo il tab Data per includere gli attributi nel layout, mediante drag & drop di ciascun elemento, partendo dall’attributo Request Date.

Figura 7 – Inserimento attributo Request Date.
Figura 7 – Inserimento attributo Request Date.

 

Il campo deve essere in sola visibilità, quindi clicchiamo sul campo e poi nella icona Gear che appare sul lato in alto a destra dell’attributo; nella finestrella delle proprietà che appare, scegliamo Editable e selezioniamo il valore No.

Figura 8 – Attributo Request Date: definizione proprietà Editable.
Figura 8 – Attributo Request Date: definizione proprietà Editable.

 

Andiamo a fare la stessa operazione per il campo Employee.

Figura 9 – Attributo Employee: definizione proprietà Editable.
Figura 9 – Attributo Employee: definizione proprietà Editable.

 

L’attributo Employee è relativo all’entità di sistema WFUSER, perciò è necessario posizionarsi sul campo della proprietà Display attribute e selezionare fullName.

Figura 10 – Attributo Employee: definizione della proprietà Display attribute.
Figura 10 – Attributo Employee: definizione della proprietà Display attribute.

 

Andiamo a ripetere le stesse operazioni per gli attributi Star Date, End Date e Business Days Requested, indicando che sono Required. Selezioniamo infine il tasto Save.

Alla fine il risultato che avremo ottenuto sarà quello di figura 11.

Figura 11 – Attività Register Leave Request: form ottenuta.
Figura 11 – Attività Register Leave Request: form ottenuta.

 

Attività: Approve Leave Request

Per realizzare la form relativa all’attività di Approve Leave Request seguiamo i seguenti passi.

Selezioniamo l’attività Approve Leave Request nel Form Designer, selezioniamo il bottone Copy From e, nella finestra che appare, selezioniamo l’attività Register Leave Request; infine selezioniamo il tasto OK.

Figura 12 – Copy Form.
Figura 12 – Copy Form.

 

Nella form che abbiamo ottenuto, definiamo gli attributi Start date, End date e Business days requested come non scrivibili (Editable = No).

Aggiungiamo un nuovo gruppo sotto quello esistente che nominiamo Approval Information, nel quale aggiungiamo i seguenti attributi senza usare nessun layout.

  • Available days: non scrivibile
  • Approved: obbligatorio
  • Reject reason
  • Rejection comments
  • Employee´s Supervisor: posizioniamoci sull’attributo Employee del data model. Espandiamolo e facciamo drag and drop dell’attributo idBossUser – fullName sulla form. Definiamolo non scrivibile. Cambiamo il display name facendo doppio click sul controllo e scrivendo: Employee’s Supervisor

Infine selezioniamo il tasto Save. Il risultato ottenuto sarà quello presentato in figura 13.

Figura 13 – Attività Approve Leave Request form ottenuta
Figura 13 – Attività Approve Leave Request form ottenuta

 

Attività: Request Vacation Leave

La form per l’attività Register Vacation Leave conterrà le informazioni della form del Supervisor, con tutti i campi in read–only, e deve comprendere i controlli che le Risorse Umane devono completare.

Per realizzare questa form seguiamo i seguenti passi. Selezioniamo l’attività Register Vacation Leave nel form Designer, quindi selezioniamo il bottone Copy From e successivamente l’attività Approve Leave Request. Rendiamo non scrivibili tutti i controlli nella form risultante.

Aggiungiamo un nuovo gruppo sotto quelli esistenti che nominiamo Register Leave Request, e a questo aggiungendo il layout 50%-50%. Nella sezione risultante aggiungiamo gli attributi Administrative task date e Payroll code definendoli entrambi obbligatori. Selezioniamo infine il tasto Save. Il risultato ottenuto sarà quello di figura 14.

Figura 14 – Attività Register Vacation Leave form ottenuta.
Figura 14 – Attività Register Vacation Leave form ottenuta.

 

Attività: Inform Reject Reason

Per realizzare la form per l’attività Inform Reject Reason seguiamo i passi che vediamo di seguito.

Selezioniamo l’attività Inform Reject Reason nel Form Designer, quindi selezioniamo il bottone Copy From e successivamente l’attività Approve Leave Request. Rendiamo non scrivibile tutti i controlli nella form risultante. Selezioniamo infine il tasto Save e chiudiamo la form.

Avendo definito le form di tutte le attività di tipo User Task, selezioniamo l’icona “Define Forms” in alto a destra nel form Designer che ci riporta nella vista Process Wizard.

Figura 15 – Define Form Diagram.
Figura 15 – Define Form Diagram.

 

Business Rules

Il successivo step nell’automazione del processo è la definizione delle Business Rules. Le prime regole da definire sono le Transition Rules. Queste regole valutano le condizioni e decidono quale ramo del flusso viene seguito. Le Transition Rules restituiscono vero o falso e sono associate ai Gateway.

Andremo di seguito a creare la regola per il gateway Leave request approved?: se la richiesta è approvata, il task successivo nel flusso di processo è Register vacation leave, altrimenti il successivo task è Inform Reject Reason.

Transition Condition

Per creare una Business Rule si deve selezionare Define Rules —> Define Expression nella vista Process Wizard.

Figura 16 – Vista Process Wizard: Define Expression.
Figura 16 – Vista Process Wizard: Define Expression.

 

Verrà aperto il Rule Editor che visualizzerà le transizioni che non hanno regole associate.

Figura 17 – Rule Editor.
Figura 17 – Rule Editor.

 

A questo punto per creare la regola per il gateway Leave request approved?, seguiamo i seguenti passi:

Selezioniamo la transizione Yes, che raggiunge l’attività Register vacation leave, cliccando sulla transizione stessa. Tre opzioni verranno proposte per definire il percorso:

  • Always: quando viene selezionata questa opzione, Bizagi percorrerà sempre questo path ignorando gli altri sequence flow.
  • Else: quando viene selezionata questa opzione, Bizagi percorrerà questo path se nessun altro path è valido. È il path di default. È una buona regola definire sempre un sequence flow di default.
  • Based on the result of an expression: quando viene selezionata questa opzione, Bizagi valuterà una espressione per percorrere o meno il path selezionato.

Selezioniamo Select Based on the result of an expression. Verrà visualizzata la lista di expression precedentemente create. Poiché non ci sono expression create, clicchiamo su New.

Figura 18 – Expression Manager.
Figura 18 – Expression Manager.

 

Verrà visualizzato il Boolean Expression Editor. Qui facciamo il drag & drop dell’attributo Approved dal Data Model al condition item. Selezioniamo la funzione is Equal, scegliamo l’opzione True, quindi il taso OK.

Figura 19 – Boolean Expression Editor.
Figura 19 – Boolean Expression Editor.

 

Selezioniamo il path che dal gateway raggiunge il task Inform Reject Reason Task. Selezioniamo l’opzione Else e poi il tasto OK.

Figura 20 – Expression manager selezione dell’opzione Else.
Figura 20 – Expression manager selezione dell’opzione Else.

 

A questo punto ritorniamo al Process Wizard cliccando sulla freccia verde che compare in alto a destra sullo schermo.

Figura 21 – Define Expression Editor.
Figura 21 – Define Expression Editor.

 

Activity actions

Creiamo ora le rules che automaticamente valorizzano i campi Request date e Employee: in tale maniera, quando viene creato un case (istanza di processo), Bizagi lo valorizza rispettivamente con la data di oggi e l’employee che ha fatto il login al sistema. Queste regole saranno create nella prima attività del processo.

Per creare questo tipo di regole di business si deve selezionare Define Rules —> Activities Actions nella vista Process Wizard.

Figura 22 – Vista Process Wizard: Activity Actions (Events).
Figura 22 – Vista Process Wizard: Activity Actions (Events).

 

Verrà aperto l’Activity Actions (Events) che visualizzerà le attività dove queste regole possono essere aggiunte. A questo punto per creare le regola sopra indicata, seguiamo i seguenti passi.

Selezioniamo l’attività Register Vacation Request, poi selezioniamo l’opzione On Enter, quindi l’icona       Add e su Expression.

Figura 23 – Activity Actions aggiunta di una Expression.
Figura 23 – Activity Actions aggiunta di una Expression.

 

Verrà visualizzata la lista delle espressioni create. Poiché non ci sono espressioni di questo tipo create precedentemente, clicchiamo su New.

Figura 24 – Activity Actions Expression Manager.
Figura 24 – Activity Actions Expression Manager.

 

Sarà visualizzato l’Expression Editor. Compiliamo i campi Display Name, Name e Description sulla sinistra come mostrato nella figura che segue; queste informazioni ci permetteranno di identificare l’Expression quando occorrerà.

Figura 25 – Activity Action: aggiunta di una Expression.
Figura 25 – Activity Action: aggiunta di una Expression.

 

Clicchiamo con il tasto destro del mouse sulla freccia e selezioniamo Add Expression, digitiamo Type Applicant and Date, quindi selezioniamo il tasto OK.

Figura 26 – Activity Action: definizione del nome dell’Expression.
Figura 26 – Activity Action: definizione del nome dell’Expression.

 

Clicchiamo con il tasto destro del mouse sul modulo appena creato e selezioniamo Properties.

Figura 27 – Activity Action definizione delle Properties dell’Expression.
Figura 27 – Activity Action definizione delle Properties dell’Expression.

 

Sarà visualizzato l’Expression Editor. Clicchiamo su Data Model e selezioniamo l’attributo Employee, quindi selezioniamo il tasto OK.

Figura 28 – Activity Action: selezione di un attributo dal Data Model.
Figura 28 – Activity Action: selezione di un attributo dal Data Model.

 

L’attributo Employee è stato aggiunto all’Expression. Ora inseriamo il segno “=” accanto a <VacationLeaveRequest.Employee> e selezioniamo il tasto Function. Nella lista Category selezioniamo Case creator e poi User Id, quindi selezioniamo il tasto OK.

Figura 29 – Activity Action associazione di una funzione all’attributo.
Figura 29 – Activity Action associazione di una funzione all’attributo.

 

A questo punto posizioniamo il cursore sulla successiva linea, apriamo il Data Model e selezioniamo l’attributo Request date, quindi clicchiamo su OK.

Figura 30 – Activity Action: selezione di un attributo.
Figura 30 – Activity Action: selezione di un attributo.

 

L’attributo Request date è stato aggiunto. Ora inseriamo il segno “=” accanto a <VacationLeaveRequest.RequestDate> e selezioniamo il tasto Function. Nella lista Category selezioniamo Date&Time e poi Today, quindi selezioniamo il tasto OK.

Figura 31 – Activity Action: assegnazione funzione Today ad attributo.
Figura 31 – Activity Action: assegnazione funzione Today ad attributo.

 

Selezioniamo il bottone di OK su tutte le finestrelle che vengono visualizzate sino a raggiungere, Activity Actions Editor, dove clicchiamo sulla freccia verde che compare in alto a destra per tornare sul Process Wizard.

 

Assegnazione delle risorse

L’assegnazione delle risorse responsabili per ciascuna delle attività del processo è il successivo step dell’automazione di processo. Di seguito sono indicate le assegnazioni che dovremo fare:

  • Vacation Request è un processo interno quindi deve essere accessibile a tutti i collaboratori dell’organizzazione; pertanto Register Vacation Request, la prima attività che permette di creare dei nuovi case del processo, deve essere accessibile a chiunque e assegnata al creatore.
  • Il supervisore del collaboratore deve sempre completare l’attività Approve Leave Request.
  • L’utente che ha inserito la richiesta deve sempre completare l’attività Inform Reject Reason.
  • Lo Human Resources Assistant deve essere sempre responsabile dell’attività Register Vacation Leave

Per realizzare l’assegnazione delle risorse si deve selezionare il quino passo nella vista Process Wizard.

Figura 32 – Vista Process Wizard: Performers.
Figura 32 – Vista Process Wizard: Performers.

 

Verrà aperto il Define Performers che evidenzierà con un punto esclamativo le attività che non hanno nessuna risorsa assegnata.

Figura 33 – Define Performers diagram.
Figura 33 – Define Performers diagram.

 

Per ciascuna attività, vediamo come si fa ad assegnare una risorsa.

Attività: Register Leave Request

Questa attività deve essere assegnata al creatore dell’istanza del processo. Bizagi fa questo di default e quindi non dobbiamo fare nulla.

Attività: Approve Leave Request

Seguiamo i passi che illustriamo di seguito. Anzitutto, selezioniamo l’attività cliccando su di essa: si aprirà la finestrella di assegnazione Performers.

Figura 34 – Finestra per assegnare Performers.
Figura 34 – Finestra per assegnare Performers.

 

Selezioniamo il link Add Conditions. Nella finestrella visualizzata, selezioneremo il Supervisor. Per fare questo, selezioniamo User Id e poi Select Expression.

Figura 35 – Attività Approve Leave Request: Performer Condition.
Figura 35 – Attività Approve Leave Request: Performer Condition.

 

Verrà visualizzata una lista di espressioni (figura 36).

Figura 36 – Attività Approve Leave Request Expressione Manager.
Figura 36 – Attività Approve Leave Request Expressione Manager.

 

In questa lista selezioniamo CurrentAssigneeBoss e clicchiamo su OK. Questo consente di assegnare il task direttamente al Supervisore del creatore del processo. La finestrella Performer Condition si presenterà come segue:

Figura 37 – Attività Approve Leave: Performer assegnato.
Figura 37 – Attività Approve Leave: Performer assegnato.

 

Selezioniamo il tasto OK e poi ancora OK per salvare l’assegnazione

Attività: Register Vacation Leave

Per l’attività Register Vacation Leave, occorre anzitutto ripetere i primi due passi eseguiti per l’attività precedente.

Questa attività è eseguita da uno degli impiegati del dipartimento di HR che occupa la posizione di Human Resource Assistant ma, dato che non abbiamo nessuna posizione, andiamo a creare quella che ci interessa. Nella finestrella Performer Condition, selezioniamo User Property = Positions, quindi Entity Value, Value = Organization quindi New.

Figura 38 – Register Vacation Leave: Performer Condition.
Figura 38 – Register Vacation Leave: Performer Condition.

 

Digitiamo Human Resource Assistant nel campo che viene visualizzato, quindi selezioniamo Save e il tasto OK in tutte le finestrelle che appaiono per salvare l’assegnazione.

Figura 39 – Attività Approve Leave creazione posizione
Figura 39 – Attività Approve Leave creazione posizione

Attività: Inform Reject Reason

Inform Reject Reason deve essere assegnata alla persona che ha creato l’istanza (case) di processo. Ripetiamo gli stessi primi quattro passi eseguiti per Approve Leave request. Selezioniamo Case Creator nella lista che appare quindi selezioniamo OK per salvare la condizione.

Figura 40 – Attività Inform Reject Reason: assegnazione creatore.
Figura 40 – Attività Inform Reject Reason: assegnazione creatore.

 

Clicchiamo OK sulla finestrella Performers per salvare l’assegnazione. Chiudiamo il diagramma Define Performers selezionando la freccia in alto a destra.

 

Integrazione con altre applicazioni

Per integrare il processo Vacation Leave Request con il sistema paghe, saranno usati i Web Services. Nello specifico sarà richiamato un web service che espone un servizio che restituisce il numero di giorni di ferie disponibili per lo specifico collaboratore. Per realizzare l’integrazione tra un processo di Bizagi e un altro sistema si deve selezionare il sesto passo nella vista Process Wizard —> Define Integration Interface (Optional).

Figura 41 – Vista Process Wizard: Integrate.
Figura 41 – Vista Process Wizard: Integrate.

 

Verrà aperto il diagramma Define Integration Interfaces che evidenzierà con un punto esclamativo solo le attività di tipo Service.

Figura 42 – Define Integration Interfaces diagram.
Figura 42 – Define Integration Interfaces diagram.

Invocare i web service in Bizagi

Supponendo di avere una connessione internet, seguiamo i seguenti passi per invocare il servizio. Clicchiamo sull’attività Verify Available Vacation Days; nella finestrella che appare, nel campo URL digitiamo http://www.Bizagi.com/VacationService/Vacations.asmx

Figura 43 – Web service connector: inserimento URL.
Figura 43 – Web service connector: inserimento URL.

 

Selezioniamo il bottone Go per vedere i metodi disponibili e attendere sino a quando l’operazione non termina. Selezioniamo il metodo e quindi il bottone Next; ricordarsi che il sistema interfacciato e l’Interface Name prendono un nome di default che volendo possono essere cambiati.

Figura 44 – Web service connector: selezione del metodo.
Figura 44 – Web service connector: selezione del metodo.

 

Nella finestra che viene visualizzata, dobbiamo configurare il web service. Sono mostrate due tabelle: sulla sinistra il data model di Bizagi e sulla destra le informazioni che il metodo del web service si aspetta.

Figura 45 – Web service connector: configurazione del metodo.
Figura 45 – Web service connector: configurazione del metodo.

 

Poichè l’username del collaboratore è utilizzato per ottenere i giorni di ferie disponibili, espandiamo la tabella di Bizagi sulla sinistra sino a quando troviamo lo username del collaboratore, quindi clicchiamo su questo attributo e poi sull’attributo id:String sulla destra, per connettere automaticamente i due item, quindi selezioniamo Next.

Figura 46 – Web service connector: Input parameters.
Figura 46 – Web service connector: Input parameters.

 

Nella successive finestra andiamo a selezionare dove, nel data model del processo, la risposta del web service deve essere salvata.

Figura 47 – Web service connector: output data.
Figura 47 – Web service connector: output data.

 

Nello step finale andiamo a configurare cosa fare se si presenta un errore. Selezioniamo l’opzione Throw Exception dalle Action list e quindi sul bottone Finish per chudere il wizard di definizione dell’interfaccia.

Figura 48 – Web service: error handling.
Figura 48 – Web service: error handling.

 

Chiudiamo il diagramma Define Integration Interface (Optional), selezionando la freccia in alto a destra, per tornare al Process Wizard.

 

Work Portal

Avendo realizzato tutti i precedenti passi, siamo ora pronti per configurare il Work Portal e vedere il nostro processo in esecuzione. Andiamo quindi a selezionare il settimo passo nella vista Process Wizard —> Run Porcess:

Figura 49 – Vista Process Wizard: Execute.
Figura 49 – Vista Process Wizard: Execute.

 

Verrà aperta una finestra in cui dobbiamo selezionare l’icona verde.

Figura 50 – Run Process.
Figura 50 – Run Process.

 

Si aprirà la finestra di login di Bizagi.

Figura 51 – Pagina di Login di Bizagi.
Figura 51 – Pagina di Login di Bizagi.

 

Utenti

Per proseguire con l’esecuzione dei processi, abbiamo bisogno di creare degli utenti di prova. Andremo a creare gli utenti direttamente dalla web application. Sotto è la lista degli utenti che andremo a creare.

User Password Domain Immediate Supervisor Job Title
Supervisor Supervisor domain
Employee Employee domain Supervisor
Assistant Assistant domain Human Resources Assistant

Supervisor

Per creare l’utente Supervisor accederemo nell’applicazione con l’utente amministratore (si veda figura 51). Poi seguiamo i seguenti passi. Selezioniamo Admin Menu e poi Users.

Figura 52 – Selezione voce di menu: Users.
Figura 52 – Selezione voce di menu: Users.

 

Nella finestrella visualizzata, selezioniamo New User e compiliamo quindi tutti i campi obbligatori che appaiono e nel tab Basic Information deselezioniamo i check box Expired Password, Locked Account and Send Mail with Password to User.

Figura 53 – Definizione utente Supervisor.
Figura 53 – Definizione utente Supervisor.

 

Employee (Applicant)

Per creare l’utente Employee seguiamo i passi fatti per il Supervisor. Per indicare il supervisore di Employee, andiamo nel tab Configuration User e clicchiamo l’icona Search.

Figura 54 – Assegnazione di Supervisor a Employee.
Figura 54 – Assegnazione di Supervisor a Employee.

 

Quindi selezioniamo il tasto Select in corrispondenza dell’user Supervisor.

Figura 55 – Selezione Supervisor.
Figura 55 – Selezione Supervisor.

 

Assistant

Per creare l’utente Assistant seguiamo gli stessi passi fatti per Supervisor. Per assegnare una Posizione all’Assistant, dopo aver selezionato l’organizzazione nel tab Organizations, è sufficiente selezionare Human Resources Assistant nella sezione delle posizioni dell’organizzazione selezionata.

Figura 56 – Assegnazione della posizione ad Assistant.
Figura 56 – Assegnazione della posizione ad Assistant.

 

Parametri

Prima di eseguire il processo dobbiamo definire le ragioni di un possibile rifiuto della richiesta. I passi da seguire sono descritti di seguito. Selezioniamo Admin Menu e poi Entities. Nella finestrella che viene visualizzata selezioniamo Entities

Figura 57 – Selezione menu Entities.
Figura 57 – Selezione menu Entities.

 

Selezioniamo l’entità Reject Reason e aggiungiamo le ragioni cliccando sul “+“.

Figura 58 – Assegnazione valori a Reject Reason
Figura 58 – Assegnazione valori a Reject Reason

 

Inseriamo le seguenti ragioni di rifiuto:

  • Commitments make it impossible to take vacations on that date
  • No replacement available
  • Important event in request date
  • No available days
  • Other reasons

Al termine, le ragioni per il rifiuto delle ferie inserite nel nostro sistema saranno quindi quelle mostrate in figura 59.

Figura 59 – Valori assegnati a Reject Reason.
Figura 59 – Valori assegnati a Reject Reason.

 

Quindi clicchiamo su Close.

 

Test del Work Portal

Siamo ora pronti per eseguire il processo. Apriamo il Work Portal, entriamo nell’applicazione inserendo le credenziali dell’utente Employee.

Figura 60 – Accesso al Work Portal come utente Employee.
Figura 60 – Accesso al Work Portal come utente Employee.

 

Clicchiamo su New e selezioniamo il processo Vacation Leave Request.

Figura 61 – Creazione di una nuova richiesta di ferie.
Figura 61 – Creazione di una nuova richiesta di ferie.

 

Completiamo le informazioni per l’attività, quindi selezioniamo Next per continuare con il processo. Saremo informati che non abbiamo informazioni pendenti per il processo; infatti ora la richiesta è passata di competenza a Supervisor.

Figura 62 – Inserimento informazioni da parte dell’Employee.
Figura 62 – Inserimento informazioni da parte dell’Employee.

 

Facciamo logout dall’applicazione, quindi login con le credenziali dell’utente Supervisor. In questo modo possiamo vedere la situazione dall’altro punto di vista, quello di chi deve autorizzare la richiesta.

Figura 63 – Tasto di logout.
Figura 63 – Tasto di logout.

 

Il case sarà visualizzato nella Inbox del Supervisor come task in pending.

Figura 64 – Inbox del Supervisor.
Figura 64 – Inbox del Supervisor.

 

Selezioniamo il case, compiliamo tutte le informazioni dell’attività, approviamo la richiesta e clicchiamo su Next.

Figura 65 – Inserimento informazioni da parte del Supervisor.
Figura 65 – Inserimento informazioni da parte del Supervisor.

 

Facciamo logout dall’applicazione, quindi login con le credenziali dell’utente Assistant. Selezioniamo il case del processo in pending, compiliamo tutte le informazioni dell’attività, approviamo la richiesta e clicchiamo su Next. Saremo informati che non abbiamo informazioni pendenti per il processo.

A questo punto la richiesta risulterà chiusa e il processo completato.

 

Conclusioni

Abbiamo completato con questo articolo la descrizione di una simulazione d’uso del modulo Bizagi Studio.

L’automazione dei processi, modellati secondo precise regole (BPM) e grazie a un adeguato linguaggio descrittivo, è un’attività importante per le organizzazioni di dimensioni medie e grandi che così possono ridurre gli sprechi e garantire una maggiore semplificazione delle procedure.

In questo, la suite Bizagi, che abbiamo analizzato in questa serie, risulta uno strumento potente e flessibile al servizio della Business Process Automation.

 

Eustachio Nicoletti

Sono sposato, ho due figlie e, per non soffrire troppo la situazione di minoranza, ho imposto la presenza in famiglia di Balu‘: un derivato setter inglese maschio. Sono laureato in Informatica e certificato PMP-PMI. Nella mia carriera professionale ho ricoperto i ruoli di responsabile di prodotto, responsabile di unità di business, tecnico-pre sales, progettista, delivery manager, business process analyst, software architect e project manager. I principali ambiti applicativi in cui ho maturato esperienze sono automazione dei reparti di neonatologia, human capital management, gestione dei processi della qualità, per aziende e organizzazioni piccole, medie e di dimensione internazionale. Attualmente lavoro come Business Process Analyst e Project Manager presso una azienda di Reggio Emilia esperta nello sviluppo di Sistemi Informativi per la Qualità.

Facebook
Twitter
LinkedIn
Picture of Eustachio Nicoletti

Eustachio Nicoletti

Sono sposato, ho due figlie e, per non soffrire troppo la situazione di minoranza, ho imposto la presenza in famiglia di Balu‘: un derivato setter inglese maschio. Sono laureato in Informatica e certificato PMP-PMI. Nella mia carriera professionale ho ricoperto i ruoli di responsabile di prodotto, responsabile di unità di business, tecnico-pre sales, progettista, delivery manager, business process analyst, software architect e project manager. I principali ambiti applicativi in cui ho maturato esperienze sono automazione dei reparti di neonatologia, human capital management, gestione dei processi della qualità, per aziende e organizzazioni piccole, medie e di dimensione internazionale. Attualmente lavoro come Business Process Analyst e Project Manager presso una azienda di Reggio Emilia esperta nello sviluppo di Sistemi Informativi per la Qualità.
Tutti gli articoli
Nello stesso numero
Loading...
Nella stessa serie
Loading...