Antecedent managementstijl en tools
Vroeger werden de projecten beheerd in Redmine, wat door de klant enigszins werd verbeterd met een paar nuttige aanpassingen. Andere afdelingen van het bedrijf gebruiken Microsoft Dynamics NAV om ze te organiseren en de gegevens daar te bewaren, de systemen (Redmine en NAV) waren onderling verbonden om de communicatie tussen de afdelingen mogelijk te maken en te automatiseren.
Technisch werkte het op de volgende manier: Nadat een nieuw project was opgezet en gedefinieerd in NAV, was er een optie om deze gegevens over te dragen naar Redmine, waardoor er een nieuw project met bepaalde attributen ontstond.
Redmine is een nuttig hulpmiddel geworden dat heeft bijgedragen aan het organiseren van werk in dit bedrijf. De projecten waaraan JIRI-modellen werken, lijken erg op elkaar en de projectstructuur in Redmine was eenvoudig gehouden. Vroeger waren projecten onderverdeeld in 4 of 5 taken en deze waren identiek of vergelijkbaar voor elk project. Vroeger werd een taak tussen meerdere toegewezen personen tijdens de levenscyclus doorgegeven, afhankelijk van wiens beurt het was om een actie uit te voeren op het deelwerk dat in deze taak is verpakt. Zo werd een taak alleen opgemerkt en gecontroleerd door de huidige toegewezen persoon. Om taken bij te houden werd het standaardfilter "mijn taken" in het persoonlijke dashboard van Redmine gebruikt.
Hoewel het systeem een tijdlang goed werkte, bleek het onvoldoende te zijn om de innovatieve plannen en strategieën van het management van het bedrijf bij te houden. Deze strategieën waren vooral gericht op meer transparantie en duidelijkheid in het hele proces, het vermogen om de oorzaken van vertragingen in het project te voorspellen of te achterhalen en de verantwoordelijke mensen aan te pakken, evenals op de implementatie van een efficiënte planning van middelenbeheer, enz. De verwachte voordelen zouden zeker een sneller en soepeler leveringsproces zijn en het verkrijgen van solide gegevens om andere interne hulpmiddelen en mechanismen te ontwikkelen om de motivatie en tevredenheid van de werknemers te vergroten.
Voordat de implementatie begon, hadden de managers van JIRI-modellen al een duidelijk idee van het nieuwe proces dat ze gingen implementeren en hoe de workflow er idealiter zou moeten uitzien. Allereerst hebben we ons gericht op het implementeren van dit proces in het systeem door een structuur van taken te creëren en de stroom en machtigingen en de gebruikersinterface voor elke groep gebruikers goed te definiëren om ervoor te zorgen dat de juiste informatie de juiste mensen bereikt in tijd. Tijdens de implementatie werkten we ook samen met verschillende externe partners van JIRI-modellen om de verbinding tussen Easy Project en Microsoft Dynamics NAV op te zetten en te verbeteren. De implementatie vereiste vooraf veel planning en ontwerp. Dit was te wijten aan het feit dat het hele productieproces in Redmine liep, dat direct na de implementatie door Easy Project moest worden vervangen om de continuïteit van de gegevens niet te onderbreken.
Projectsjablonen en API-integratie
Alle projecten hebben een vergelijkbare structuur. In tegenstelling tot Redmine Easy Project kunt u projectsjablonen maken die worden gebruikt als basis voor een nieuw project. In dit geval is het belangrijkste voordeel van het gebruik van sjablonen de mogelijkheid om de structuur van de taken, de relaties en de beschrijving van elke taak daar te behouden. We hebben een verbinding tot stand gebracht tussen eenvoudig project en Microsoft Dynamics NAV. Wanneer een nieuw project wordt aangemaakt in NAV, wordt het relevante "type project" geselecteerd in een aangepast veld. Deze informatie wordt verzonden naar Easy Project, dat de projectsjabloon voor de nieuwe installatie automatisch kiest, de gegevens van NAV worden daar overgedragen.
Easy Project kernfuncties en persoonlijke dashboards
We hebben gebruik gemaakt van de kernfuncties die Easy Project biedt en verschillende soorten taken met verschillende workflows opgezet. Het betekent dat de mogelijke statussen voor een taak verschillen naargelang het type van deze taak. Ook is de volgorde van de status gedefinieerd om de gebruikers te helpen bij het identificeren van de volgende stap en kunnen de statussen anders worden gebruikt, afhankelijk van de rol van de gebruiker, aangezien deze verschillende verantwoordelijkheden hebben. De statussen en trackers (soorten taken) werden gebruikt voor de persoonlijke dashboardinstelling om relevante taken voor elke gebruiker te filteren. Een supervisor kan bijvoorbeeld de status van de uit te voeren taken volgen, om die taken afzonderlijk bij te houden waar feedback of goedkeuring van zijn / haar kant nodig is, om te identificeren welke vertraagd worden, enz.