Tänään on tarkoitus katsoa hiukan taaksepäin ja jakaa ajatuksia Odoon  käyttöönotto/kehitystavoista. Itse olen työhistoriani aikana ollut tekemisissä kahden alla olevan metodin kanssa: 
 
1. Perinteinen lähestymistapa eli vesiputous-menetelmä 
2. Ketterä kehitys 

 
Vesiputous 
 
Vesiputous jakautuu eri vaiheisiin heti kättelyssä. Alkaa vaatimusmäärittelystä, jossa samalla suunnitellaan projektin aikajanat. Kun vaatimusmäärittely on tehty, niin seuraavaksi suunnitellaan prosessikaaviot ja näiden pohjalta laaditaan projektin roadmap eli ”tiekartta”. 
 
Tiekartan luomisen jälkeen, kolmas vaihe koostuu erpin kehittämisestä ja implementoinnista. Nuo on jaettu pienempiin kokonaisuuksiin/tehtäviin, jotka jaetaan eri ryhmien kesken osaamisen mukaan. Projektin aikana sisäinen testaus tehdään normaalisti, jotta vältytään virheiltä/bugeilta myöhemmässä asiakastestivaiheessa. Tämän jälkeen asiakas aloittaa ohjelmiston testauksen ja kun asiakas on tyytyväinen niin projekti saatetaan tuotantoon. 
 
Vesiputous menee siis näin: 
 
Vaatimusmäärittely – Suunnittelu – Kehitys – Testaus – Asiakastestaus – Projektin toimitus. 
 
Kuulostaa yksinkertaiselta, eikö? Noh: vesiputousmallin kautta toteutettaessa tärkein kantava voima on raskas dokumentointi, jonka avulla aikataulut ja projektin toteutusvaatimukset voidaan asettaa selkeästi ennen aloittamista. Tästä johtuen on olemassa riski, että speksin yllättävät muutokset vaikuttavat kehitykseen ja projektin kulkuun. Kehityksessä kun voi syntyä erilaisia ongelmia, jos esim. yrityksen prosesseissa tapahtuu muutoksia kehitysvaiheen aikana eikä alkuperäinen speksi enää vastaa todellista tarvetta. Täten, vesiputousmallissa ei välttämättä pystytä sopeutumaan muutoksiin/haasteisiin kovin kevyesti eikä ainakaan liian joustavasti. Tästä syystä hieman joustavampi lähestymistapa (erityisesti räätälöityyn kehittämiseen) on ketterä kehitys eli tuttavallisemmin Agile. 

Ketterä kehitys eli Agile 

Agile-menetelmässä keskitytään enemmän projektin tehtävien suorittamiseen joustavan tiimiyhteistyön ja asiakaskommunikoinnin/asiakastestauksen kautta. Agilessa ei tuoteta raskasta dokumentointia vaan mennään kevyemmillä tehtäväkohtaisilla spekseillä ja pyritään pääsemään toivottuihin tuloksiin jo hyvin aikaisessa vaiheessa eli toisin sanoen saadaan toimiva ohjelmisto/erppi aikaiseksi lyhyemmässä aikataulussa verrattuna vesiputoukseen. 
 
Ketterässä menetelmässä projekti/haluttu scope jaetaan pieniin tehtäviin (esim. konffaukseen/kehitykseen), jotka tunnetaan myös iteraatioina. Mennään lyhyillä sykleillä, jotka kestävät 2-4 viikkoa. Agilen työprosessi näyttää käytännössä tältä: 
 
Vaatimusten määrittäminen – Suunnittelu ja kehitys – Asiakasdemo – Uudelleenarviointi – Vaihetoimitus ja sitten alkaa alusta. 
 
Esim. usea Odoo-projekti alkaa näin: asennetaan CRM, käydään sillä asiakasvaatimukset läpi, määritellään muokkaustarpeet (jos niitä löytyy ylipäätään), toteutetaan ne, asiakas testaa ja hyväksyy tulokset = asiakas pääsee nauttimaan CRM:n hyödyistä heti alkuvaiheessa (sen jälkeen vuorossa on vaikka myyntimoduuli, varasto jne).  
 
Agilen tapauksessa asiakkaan osallistuminen on erittäin tarpeellista, sillä jokaisessa pienessäkin vaiheessa tarvitaan asiakastestausta, jotta nähdään vaatiiko kehitysprosessi muutoksia tai mukautuksia. Ketterä menetelmä pyörii jatkuvan iteroinnin ympärillä projektin kokonaisvaatimusten täyttämiseksi. Agile-kehityksen kiistaton etu on, että asiakas saa toimivan ohjelmiston jo varhaisessa vaiheessa, kun kehitys tapahtuu pala kerrallaan mikä pienentää ROI-riskiä parantaen sijoitetun pääoman tuottoa ja antaa asiakkaalle jatkuvan kuvan hankkeen etenemisestä (vesiputousmallissa hyödyistä päästään nauttimaan käytännössä vasta kun projekti on valmis kokonaisuudessaan). 
 
Projektin ketterässä toimittamisessa riskit ovat verrattain pienet, mutta on huomioitava, että ketterässä kehityksessä ohjelmistoa kehittävän toimittajan on oltava erittäin kokenut antaakseen oikeat aikataulut projektille ja mukautuksille. Toinen tärkeä seikka, joka on otettava huomioon ketterän menetelmän soveltamisessa on se, että Agile on erittäin riippuvainen asiakaspalautteesta ja asiakkaan osallistumisesta. Jos asiakkaalla ei ole aikaa investoida, voi olla vaikeaa tehdä kehitystä Agilen kautta. 
 
Summa summarum: valitse vesiputousmalli jos projekti on suoraviivainen vaatimuksiltaan eikä siinä juuri ole kustomoitavaa. Jos tiedetään, että sovituksia/räätälöintiä on tulossa ja haluat päästä nauttimaan nopeammin erpin hyödyistä niin valitse Agile.  

Me ERPWarella implementoimme Odoota  pääosin Agilen kautta eli haluamme saada asiakkaalle toiminnanohjauksen käyttöön joustavasti ja mahdollisimman vähällä byrokratialla keskittyen tulokseen keinojen sijasta. Kerromme mielellämme lisää, ota yhteyttä matalalla kynnyksellä!