Stile e strumenti di gestione precedenti
I progetti venivano gestiti in Redmine, dopo un lieve miglioramento dal cliente con un paio di modifiche utili. Altri reparti dell'azienda utilizzavano Microsoft Dynamics NAV per organizzare il loro lavoro e conservare i dati; pertanto, i sistemi (Redmine e NAV) sono stati interconnessi per abilitare e automatizzare la comunicazione tra i reparti.
Da un punto di vista tecnico, il funzionamento si è svolto nel modo seguente: Una volta impostato e definito un nuovo progetto in NAV, era prevista un'opzione per trasferire questi dati in Redmine, creando in tal modo un nuovo progetto con determinati attributi.
Redmine è diventato un utile strumento che ha contribuito all'organizzazione del lavoro in questa azienda. I progetti su cui JIRI Models lavorava erano molto simili e la struttura del progetto in Redmine è stata mantenuta semplice. I progetti erano suddivisi in 4 o 5 task (o attività) che risultavano essere identici o simili per ogni progetto. Durante il suo ciclo di vita, un task passava attraverso più assegnatari a seconda di chi fosse l'incaricato a svolgere un'azione sulla parte di lavoro impacchettato nel task stesso. In questo modo, un task veniva analizzato e monitorato solo dal suo attuale assegnatario. Per tenere traccia dei task veniva utilizzato il filtro predefinito “I miei task” nella dashboard personale di Redmine.
Nonostante il sistema abbia funzionato in maniera efficace per un po' di tempo, si è rivelato insufficiente per rimanere al passo con i piani e le strategie innovative della gestione aziendale. In particolare, tali strategie erano mirate a migliorare la trasparenza e la chiarezza dell'intero processo, capacità di prevedere o individuare le cause di ritardi sul progetto e rivolgersi ai responsabili, nonché attuare un'efficiente pianificazione di gestione delle risorse e così via. I vantaggi previsti sarebbero stati senza dubbio un processo di consegna più rapido e agevole e un ottenimento di dati solidi per sviluppare altri strumenti e meccanismi interni, al fine di incrementare la motivazione e la soddisfazione dei dipendenti.
Prima che l'implementazione fosse avviata, i gestori di JIRI Models avevano già una chiara idea di quale fosse il nuovo processo in via di implementazione e come sarebbe risultato idealmente il flusso di lavoro. Innanzitutto, ci siamo focalizzati sull'implementazione di tali processi nel sistema creando una struttura di task e definendo chiaramento il relativo flusso e le autorizzazioni, nonché l'interfaccia utente per ciascun gruppo di utenti, in modo da garantire che le giuste informazioni arrivassero in tempo alle persone. Inoltre, nella fase di implementazione abbiamo collaborato con vari partner esterni di JIRI Models per impostare e migliorare la connessione tra Easy Project e Microsoft Dynamics NAV. L'implementazione ha richiesto una lunga pianificazione e progettazione a priori. Ciò era dovuto al fatto che l'intero processo di produzione era in corso su Redmine, il quale sarebbe stato sostituito dal Easy Project subito dopo l'installazione in modo da non interrompere la continuità dei dati.
Modelli di progetto e integrazione API
Tutti i progetti presentano una struttura analoga. A differenza di Redmine, Easy Project consente di creare modelli di progetto che vengono utilizzati come base per un nuovo progetto. In tal caso, il vantaggio più significativo dell'utilizzo dei modelli è la possibilità di mantenere la struttura dei task, le relazioni corrispondenti e la descrizione di ciascun task. Abbiamo impostato una connessione tra Easy Project e Microsoft Dynamics NAV. Quando si crea un nuovo progetto in NAV, viene selezionato il "tipo di progetto" corrispondente in un campo personalizzato. Queste informazioni vengono inviate a Easy Project, il quale sceglie automaticamente il modello di progetto per la nuova configurazione e i dati NAV vengono trasferiti lì.
Funzioni essenziali e dashboard personali di Easy Project
Abbiamo sfruttato le funzioni fondamentali offerte da Easy Project e abbiamo impostato diversi tipi di task con diversi flussi di lavoro. Ciò significa che gli stati possibili per un task variano in base al tipo di task stesso. Inoltre, la sequenza dello stato viene definita per aiutare gli utenti a identificare il passaggio successivo e gli stati possono essere utilizzati in modo diverso a seconda del ruolo dell'utente, ricoprendo quest'ultimo diverse responsabilità. Gli stati e i tracker (tipi di task) sono utilizzati per l'impostazione della dashboard personale in modo da filtrare i task rilevanti per ciascun utente. Per esempio, un supervisore può monitorare lo stato dei task da eseguire, tenere traccia in modo separato di quei task che richiedono un feedback o un'approvazione, identificare coloro che sono in ritardo, ecc.