samenwerken met 360 ERP

Wat je kunt verwachten lees je in deze bijsluiter

Je overweegt of hebt gekozen voor 360 ERP als implementatie- of supportpartner voor Odoo. Gefeliciteerd! We weten dat we ons nog moeten bewijzen en daar gaan we ons hard voor maken. Je kunt in ieder geval rekenen op daadkracht, expertise, inlevingsvermogen en constructieve discussies - want een tikkeltje eigenwijs zijn we wel. We geloven namelijk dat je alleen in een open en eerlijke samenwerking het beste resultaat neer kunt zetten voor de organisatie. We hebben het beste voor met onze klanten, op korte en lange termijn. Dát zit in ons DNA en mag je van ons verwachten. Wat je verder moet weten over onze werkwijze lees je hieronder.

Lees de bijsluiter voor gebruik: "standaard" bijwerkingen

Voordat je verder leest hebben we een belangrijke boodschap voor (nieuwe) klanten: we gaan je uitdagen. We houden namelijk van standaard (Odoo), en dat heeft een reden. Hoe dichter je bij de standaard functionaliteit blijft hoe meer profijt je ervan zult hebben op de lange termijn. Lagere opstartkosten, minder complexiteit, en makkelijker migreren naar nieuwe versies van Odoo. Onze ervaring bij vele andere projecten heeft ons dat geleerd.

Dus als we je uitdagen omdat we denken dat het anders en beter kan, vragen we je om een luisterend oor. Ook al is het niet precies wat je voor ogen had. We doen het omdat we om de organisatie geven en we willen dat je blijvend profiteert van de oplossing die we neerzetten. Daar gaan we samen voor! Dus wil je een échte best-of-breed neerzetten? Kom maar op!

Final note: We zijn zeker niet vies van goed maatwerk en leveren de beste kwaliteit die je zult vinden. 

Project Aanpak

Hoe we werken

360 ERP houdt van een gefaseerde en pragmatische aanpak waarbij we het totale project verdelen in bouwblokken. Elk bouwblok bevat één of meerdere Odoo Apps die één of meerdere processen van de organisatie automatiseren. Door deze aanpak wordt de druk op de organisatie gespreid en kan er meer aandacht worden besteed aan de individuele inrichting van de Apps. Ook kunnen we zo voortschrijdend inzicht over de processen opdoen en die direct toepassen in de volgende bouwblokken. Zo profiteert de organisatie snel van de mogelijkheden van Odoo én wordt het uiteindelijke resultaat beter.

Start: Project Initiatie Document

De meeste projecten bij 360 beginnen met een Project Initiatie Document (PID). In dit document brengen we het project in kaart zonder daarbij in te gaan op exacte details van de invulling. We kijken naar de requirements van de organisatie, het eventuele bestaande of toekomstige landschap (technology stack), mogelijke best-of-breed structuur en beschrijven de uitwerking van de oplossing in grote lijnen. Ook definiëren we de bouwblokken waarin het project uitgevoerd zal worden met een scope op doorlooptijd en budget.

Voorbeeld structuur van een 360 PID:

  • Projectdefinitie (motivatie en doelstelling)

  • Uitwerking van de oplossing

  • Projectaanpak en -organisatie

  • Omschrijving bouwblokken

  • Doorlooptijd en budget

  • Informatie over SLA

  • Ondertekening en Voorwaarden

Fasering

Verschillende bouwblokken, zelfde fases

1. Functioneel ontwerp

Voor complexe processen en maatwerk wordt een functioneel ontwerp gemaakt. Bij een relatief simpel bouwblok kan deze stap vervallen.

2. Realisatie

Modules worden geconfigureerd en de nodige inrichting wordt gedaan. Eventueel maatwerk wordt ontwikkeld en data wordt gemigreerd.

3. FAT

De Functionele Acceptatie Test: de opgeleverde functionaliteit van het bouwblok wordt getest door projectleden van de organisatie.

4. UAT

De User Acceptatie Test: nadat het bouwblok is goedgekeurd in de FAT testen key-users de processen die zijn opgeleverd.

5. Training

Volgens het principe van 'train the trainer' hebben de key-users al voorlichting gekregen van 360. Nu is het hun beurt om de eindgebruikers te trainen.

6. Go-Live

Het is zover: alles is getest, akkoord en de eindgebruikers zijn er klaar voor. We brengen het bouwblok live om écht gebruikt te gaan worden.

ROLLEN BIJ 360

WIE DOET WAT?

Architect

De aangewezen architect bij 360 is verantwoordelijk voor de grote-lijnen-logica van de oplossing. Bepaalt een eventuele best-of-breed inrichting en is verantwoordelijk voor de structuur van de technology stack. Beslist in overleg met de klant en consultant(s) hoe de oplossing eruit gaat zien. Werkt mee aan de inrichting waar de complexiteit hoog is. Is vooral aanwezig bij de project initiatie en uitwerking, beweegt daarna naar de achtergrond maar is aanwezig bij meetings van de stuurgroep.

Consultant(s)

De 360 consultant(s) zijn het meest aanwezig en verantwoordelijk voor de praktische uitvoering en inrichting van het project. Afhankelijk van de grootte en veelzijdigheid van de oplossing worden meerdere consultants ingezet om een bijdrage te leveren binnen hun eigen specialisme. Dagelijkse aanspreekpunt voor de klant tijdens het project. Schakelen met de architect voor support waar en wanneer nodig. 

Ontwikkelaar

De 360 ontwikkelaar schrijft de code voor eventueel maatwerk binnen de oplossing. Luistert naar de architect en consultant om de functionele en logische vereisten van het gewenste (deel)resultaat goed te begrijpen. Werkt samen met de consultant om opgeleverd maatwerk te testen en invulling te geven aan kleine details. Is normaliter niet aanwezig bij de klant maar wordt soms gevraagd als eregast bij een meeting wanneer de complexiteit hoog is.

Happiness Controller

De happiness controller, ook wel project manager genoemd, houdt de grote lijnen van het project in de gaten. Checkt met regelmaat in bij de klant en betrokken teamleden van 360 of de voortgang en invulling naar wens verloopt. Aanspreekpunt voor de klant bij uitzonderingen. Is de schakel tussen klant, architect en consultant(s) als de ketting gesmeerd moet worden. Uitstekend gezelschap voor een kop koffie wanneer alles op rolletjes verloopt.

ROLLEN BIJ de klant

De sparringpartners voor 360

Projectleider

Het primaire aanspreekpunt tijdens het (implementatie)project vanuit de klant voor alle stakeholders. Schakelt als decision maker en sparringpartner direct met de 360 architect, consultant(s) en happiness controller. Geeft richting en context aan het 360 team en key-users. Tussenpersoon en verbinder bij (best-of-breed) projecten waar meerdere leveranciers participeren. Aanwezig bij meetings van stuur- en projectgroepen, optioneel bij werkgroepen.

Functioneel Beheerder(s)

De uiteindelijke beheerders van de opgeleverde Odoo oplossing(en) binnen de organisatie. Worden getraind door 360 op beheeraspecten zoals gebruikers-/rechtenbeheer, inrichting, configuratie, workflows en optimalisatie. Na de oplevering eerste aanspreekpunt voor interne gebruikers. Meestal de uiteindelijke contactpersonen voor 360 bij support na oplevering.

Key-users

De aangewezen personen binnen de organisatie die bepalende kennis over en verantwoordelijkheid hebben voor een (deel)proces en/of afdeling. Veelal teamleiders of managers. Gaan uiteindelijk zelf met (een deel van) de software werken in de dagelijkse praktijk. Geven gedetailleerde input aan het team van 360 over de inrichting van een (primair) proces. Krijgen training van 360 en zijn verantwoordelijk voor het testen van opgeleverde functionaliteit binnen een bouwblok.