Slik unngår du den store ERP-smellen
Iterate er et firma som utfører iterativ systemutvikling. Et annet ord for iterativ kan være trinnvis. Vi mener at enhver ikke-triviell utviklingsprosess bør gjennomføres iterativt. Alternativet til en iterativ modell kalles ofte Big Bang, som vel kan oversettes med stort smell på norsk. Spektakulært kanskje, men potensielt ødeleggende og farlig.
Forretningssystemer, Multi Purpouse Systems eller Enterprise Resource Planning-systemer har fått et veldig frynsete rykte på grunn av store budsjettoverskridelser og store negative konsekvenser for bedrifters kjernevirksomhet. Hvorfor skjer dette så ofte? Vi tror at man har låst seg fast til at man må bytte alle bedriftens kjernesystemer på en gang. Hvorfor har man denne holdningen? Fordi de store leverandørene har sagt at slik er det. At man enten må skifte ut alt sammen eller så må man bruke store summer på å lage integrasjoner mot “legacy”-systemer.
Det er helt sant at det på overflaten ser ut som bortkastede penger å lage integrasjoner mot systemer man før eller siden skal skifte ut. Men vi hevder for det første at det ikke behøver å koste så mye, og at den kostnaden vil man få tilbake mange ganger i form av redusert risiko og raskere tilbakebetaling av sin investering.
OpenERP er et system som egner seg godt til en slik trinnvis innføring. Man kan starte med noen få moduler og så legge på mer funksjonalitet etterhvert som man tar i bruk flere deler av systemet. Overlever bedriften kanskje med dagens regnskapssystem en stund til, mens man kunne hatt stor nytte av et bedre CRM-system? Hva med et nytt lagersystem med gode sporings- og rapporteringsfunksjoner? Eller vil man gjerne ha et mer omfattende backend-system for nettbutikken?
Ikke slik å forstå at regnskapsfunksjonene er noe å kimse av. En måte å gjøre en trinnvis innføring på kan være at man fører et skyggeregnskap en periode, på siden av sitt vanlige system. Kanskje kan man da gjøre seg bruk av OpenERP sine funksjoner for analytisk bokføring der man kan enkelt kan spore kostnader til et prosjekt, en avdeling eller en kunde. Mulighetene er endeløse.
I Iterate vil vi gjerne utfordre etablerte sannheter. En etablert sannhet er at ERP-implementasjoner må være store, dyre og risikable. Vi mener at det ikke behøver å være slik. I forhold til de større leverandørene er OpenERP enkelt å sette opp, man kan starte med et minimalt sett med moduler. Hvis man trenger å integrere med eksisterende systemer kan man gjøre dette relativt enkelt. Å bytte ut virksomhetskritiske systemer er alltid noe som krever planlegging og koordinasjon, men starter man enkelt får man både raskere tilbakebetaling av investeringen og lavere risko.
Kanban i vedlikeholdsprosjekter
I systemutvikling er Kanban en metode som passer spesielt godt til vedlikeholdsprosjekter. Når man snakker om smidig utvikling tar man ofte for gitt at man vil jobbe Scrum. Erfaringsmessig fungerer ikke Scrum like bra i alle typer situasjoner. Når det gjelder vedlikeholdsprosjekter møter man mange utfordringer med Scrum. Mange av utfordringene kan løses ved å bruke Kanban-metodikken.
Hovedutfordringen med Scrum i et vedlikeholdsprosjekt er uforutsigbarheten som ligger i et slikt prosjekts natur. Kanban er laget for å håndtere uforutsigbarhet og passer derfor godt.
Kanban baserer seg, som Scrum, i stor grad på empiri og prosessforbedringsteori. Hovedtankene er tatt fra Lean og involverer prinsipper som ”Eliminate Waste”, ”Pull Scheduling”, ”Stop the Line” og ”Just in Time”. Reglene for Kanban er enklere og krever litt mer av team og kunde, men fungerer erfaringsmessig meget bra for vedlikehold av programvare.
Kanban-regler
Det er tre regler man må følge i Kanban:
- Visualiser arbeidsflyten: Som i Scrum er det viktig å visualisere flyt. Dette gjøres enkelt ved å benytte en tavle og Kanban-kort som representerer oppgavene.
- Reduser samtidig arbeidsmengde: Det er et mål å ha så korte køer som mulig. Det vil si at man skal redusere antall samtidige oppgaver. Dette sørger for at flere oppgaver blir løst på kortere tid og at man får en bedre flyt i arbeidet.
- Mål gjennomstrømningstid: For å kunne forbedre prosessen må man kunne måle resultatet av endringer. Ved å måle tiden fra et problem dukker opp til det er løst og satt i produksjon, kan man lett måle om endringer gjør denne tiden lengre eller kortere.
Kanban-kort
Et Kanban-kort representerer en oppgave. Man kan sette regler for at ingen kan jobbe på mer enn én oppgave av gangen, men man åpner for at flere kan jobbe på samme oppgave. Dette er aktuelt for eksempel i forbindelse med parprogrammering. Et Kanban-kort inneholder informasjon om hvilken oppgave det gjelder, gjerne en ID til et issue tracker-system, hvem som utvikler, hvem som tar QA, og revisjonsnummer fra versjonskontrollsystemet.
Kanban-tavle
En Kanban-tavle er veldig lik en Scrum-tavle. Det viktigste er at den visualiserer den faktiske arbeidsprosessen. På denne måten kan man lett se hvor køene oppstår Bildet under viser tydelig at man har altfor mange åpne QA-oppgaver.
Dette løses opp i ved å sette grenser for antall samtidige arbeidsoppgaver for å sikre flyt. Dette er gjort på bildet under.
Begrense antall samtidige oppgaver.
Det viktigste prinsippet for å sikre god flyt er å redusere antall køer og lengden på de køene man må ha. Dette må man eksperimentere med samtidig som man måler gjennomstrømningshastigheten for å finne de reglene og begrensningene som gir best flyt. I noen tilfeller kan det faktisk være at man må ha færre åpne oppgaver enn man er teammedlemmer. Kanskje kan et team på 10 personer bare ha 5 åpne oppgaver totalt. Dette vil måtte løses ved bruk av parprogrammering, noe som vil kunne øke hastigheten totalt sett.
Daglig møte
Daglig møte er ikke noe krav i Kanban, men en god skikk å ta med seg fra Scrum. En viktig forskjell er at man skifter fra å stille de tre klassiske spørsmålene fra Scrum og heller fokuserer på arbeidsoppgavene på tavla. Man går igjennom oppgavene og spør hver enkelt oppgave: “Hva kan vi gjøre for deg, kjære arbeidsoppgave, så du blir løst raskest mulig?”. Dette øker fokuset på oppgavene betraktelig og er med på å holde flyten oppe.
Hva skiller Kanban fra Scrum?
I korte trekk er det fravær av sprinter som er den største overgangen. Dette vil gi betraktelig bedre respons fra teamet og man vil kunne gjøre de viktigste tingene ferdig og produksjonsklare først uten å måtte vente på at alle andre oppgaver i sprinten skal bli ferdig.
Det åpner igjen for hyppigere utrulling av produksjonsklar kode, noe som minsker tiden før tilbakemeldinger kommer tilbake til utvikler, som igjen gjør eventuell feilretting enda raskere. En god sirkel, men andre ord.
Ulempen med Kanban er man ikke har sprintene som forutsigbare leveranser. Når man driver et vedlikeholdsprosjekt må man vurdere om man vil bytte ut denne forutsigbarheten med muligheten for raskere og mer effektivt vedlikehold.
Kanban sier heller ingenting om roller. Erfaringsmessig er rollene i Scrum godt definerte og fungerer fint sammen, så det er god praksis å fortsette med Produkteier og Scrum Master. I tillegg tar man med seg retrospektivet fra Scrum, som et hjelpemiddel for å forbedre prosessen.
OpenERP
OpenERP er, som navnet antyder, et åpen kildekode ERP-system som blir utviklet og vedlikeholdt av selskapet OpenERP i Belgia. Det at systemet er åpen kildekode innebærer at koden til systemet er fritt tilgjengelig og at man står fritt til å gjøre endringer i systemet så lenge man publiserer disse.
Dette har blitt gjort av mange som har tatt systemet i bruk. En fordel med åpen kildekode er at feil kan oppdages og rettes raskt, enten av kunden selv eller en systemintegrator. Dette til forskjell fra proprietær programvare der kun produsenten kan gjøre endringer. En ytterligere effekt av at det er åpen kildekode er at man ikke har lisenskostnader ved å bruke løsningen. Kommersielle support og vedlikeholdsavtaler kan tegnes med OpenERP og partnere.
- Generell regnskapsføring med budsjett
- Analytisk bokføring (for eksempel prosjektregnskap eller relatert til avdeling/ksted-dimensjon)
- Faktura (inngående og utgående)
- Lager (med forecasting i forhold til estimert ledetid på bestillinger og salg). Støtter både egne lager og fjernlager. Ferskvarer.
- Produksjon med multinivå bill-of-materials/oppskrifter
- CRM og salgsstøtte
- Dokumenthåndtering og interndokumentasjon (wiki). Integrasjon mot bl.a. Outlook.
- HR (lønn, personaloppfølging, ansettelseskontrakter)
Gjør brukbarhetstesten geriljabasert
Brukbarhetstesting avslører om et datasystem oppleves intuitivt i stedet for å virke irriterende, men testingen droppes ofte. Med geriljametoder er terskelen for å teste lavere, uten at det reduserer effekten.
Geriljabasert testing i praksis: Inviter noen venner på middag og test (på engelsk)
by Roebot (click image)
Hvis brukere slippes løs på et nytt system tidlig, øker sannsynligheten for suksess når systemet går på lufta. Brukbarhet handler om hvordan systemene er i praktisk bruk, og ikke om hva som er logisk og riktig for designere og programmerere.
Et nytt datasystem må først og fremst forankres hos de som skal bruke det. Start testing tidlig, og bruk enkle grep. Det er en billig måte å sikre at systemet oppfører seg i tråd med hva brukerne faktisk trenger.
Våg mer med automatisert testing!
På samme måte som en fjellklatrer må en utvikler ofte utfordre sine egne grenser for å komme fram til målet. Men det er vanskelig å nå toppen hvis klatreren ikke stoler på sikringen. Der fjellklatrere bruker tau og bolter, kan utviklere stole på automatisert testing.
Et utviklingsprosjekt handler om å innføre ny funksjonalitet. Jo større og mer uoversiktelig systemet er, desto mer skremmende kan det være å innføre ny funksjonalitet.
Utviklere kan bli redde for å innføre nye feil – enten i selve koden de leverer, eller i form av følgefeil som kan dukke opp helt andre steder. Frykten kan gå utover leveransefart og lyst til utprøving av nye ting som kan øke kvaliteten.
Endringsvillighet
Utviklingsprosjekter kan lande i en situasjon hvor testing av ny funksjonalitet tar for lang tid. Konkurransedyktighet innenfor programvareutvikling handler om å raskt kunne tilpasse seg endringer. Forretningsmuligheter kan forsvinne fordi man ikke klarer å levere raskt nok.
Innenfor programvareutvikling er testing av løsningen prosjektets sikkerhetsutstyr. Sikkerhetsutstyret bør være i orden og enkelt og bruke for at de som gjennomfører prosjektet skal kunne yte maksimalt.
Tre råd for godt enterprise-søk
Gratisverktøy gjør enterprise søk mer enn bra nok for vanlige norske bedrifter. Men for at søk skal levere verdi er faktisk relativt enkle råd viktigere enn prislappen på søkemotoren.
Det finnes ikke noe mer irriterende enn å klikke og lete rundt på nettet på jakt etter informasjon man ikke finner. En irritert kunde forlater et nettsted etter kort tid. Noe av problemet er at det er vanskelig å strukturere websidene slik at sidene er enkle å finne frem til for alle.
Bedrifts-søkemotorer, eller såkalt enterprise-søk, utgjør en slags universalløsning på problemet, siden brukerne er vant til å finne fram på internett med søk. En søkemotor har potensial til å gi brukere rask tilgang til alle former for informasjon, helt fristilt alle former for struktur.
Dette har åpnet et marked, som så langt har vært dominert av verktøy med høy lisenskost. Produktfunksjonalitet og ytelse har gjerne vært hoveddriverne for å få søket til å virke bra.
Gratis er bra nok
Men dette bildet har sakte, men sikkert forandret seg. Nylig skrev The New York Times at ”Lucene gir søkeprodukter fra leverandører som Microsoft, Google og Autonomy en real kamp om pengene”.
Mål, budsjett eller estimat?
I løpet av det siste året har jeg satt meg inn i Beyond Budgeting. Blant annet har jeg lest boken til Bjarte Bogsnes, som jeg fant meget interessant. Når jeg leser prøver jeg å trekke paralleller til IT-bransjen. Ved å sammenligne budsjetter med estimering fikk jeg en liten ekstra innsikt som jeg deler her.
I Beyond Budgeting omtaler man et av problemene med det tradisjonelle budsjettet – det er på en og samme tid både målsetning, forespørsel om ressurser og estimat. Ideen i Beyond Budgeting er at disse bør deles opp i tre separate tall:
- Estimatet – med det vi vet nå tror vi at vi kommer til å bruke så mye penger
- Målet – vi mener at det bør være bedre måter å gjøre dette på, dette er vår ambisjon
- Forespørsel om ressurser – estimatet er bare et estimat, vennligst sett av så mye penger til dette formålet
Her er målet lavere enn estimatet, og estimater er lavere enn ressursforespørselen. På denne måten får man utfordret estimatet, på samme tid som man ikke trenger å gå til ledelsen for å be om mer penger selv om man bommer noe på estimatet.
Parallellen jeg trekker er til estimering i IT-bransjen. For et gitt prosjekt eller en bestemt iterasjon blir vi bedt om å estimere tid- og ressursbruk. Kunne vi med fordel ha delt dette oppi flere ulike elementer, akkurat som for budsjettene i Beyond Budgeting?
I så fall ville selve estimatet ha vært vår beste gjetning. Vi kunne satt oss selv et ambisiøst mål, slik at vi kunne utfordre oss selv og finne kreative løsninger. Om estimatet skulle slå feil har vi allikevel litt ekstra å gå på, så slipper vi canossagang til den som sitter på ressursene. Estimater er jo tross alt bare estimater.
Ville du reagert om du så Dagfinn Høybråten røyke?
Etter NHOs undersøkelse om partienes næringspolitikk (nho.no, 18. aug. 2009), gikk vi gjennom programmene til de største partiene før valget. SV omtales i undersøkelsen som “minst opptatt av næringslivets behov”. Ved vår egen gjennomgang av SVs partiprogram, noterte vi oss imidlertid at SV “vil arbeide for at offentlig sektor bruker programmer basert på åpen kildekode”.
Etter vår vurdering er dette positivt for Norge og norsk næringsliv. Åpen kildekode er rimeligere, mer langsiktig, og mer egnet for innovasjon. Slik programvare er ikke belagt med dyre lisenser, den låser ikke brukeren til en gitt proprietær teknologi og den er mer fleksibel og lettere å videreutvikle.
OpenOffice er et eksempel på åpen kildekode-programvare som i økende grad brukes også av offentlig sektor i Norge. Dette gir utvilsomt store innsparinger. Microsoft er på den andre siden eksempel på et selskap som ansees som lukket og proprietært.
Det er derfor med en viss undring vi konstaterer at SVs store nettkampanje “oppavsofaen.no” til fulle benytter nettopp lukket og proprietær Microsoft-teknologi på sin webserver. Spesielt med tanke på at det finnes bedre og mer utbredte åpne alternativer.
Det er positivt at SV har slike ambisjoner på vegne av det offentlige, men det er både skuffende og lite troverdig når vi får et håndfast bevis på at de ikke tar sin egen medisin. Denne problemstillingen fremstår kanskje noe teknisk, men for oss som driver med IT til daglig, er dette som å få se et bilde av Dagfinn Høybråten dampende med en sigar i munnviken.
Når ledelsen i SV ikke klarer å etterleve sine egne prinsipper internt, hvordan skal de da klare å gjennomføre denne delen av partiprogrammet i det komplekse IT-landskapet i offentlig sektor?
- Informasjon om serverprogramvaren på SV sitt nettsted oppavsofaen.no. Informasjonen er hentet fra Netcraft.com.
Hvordan passer Lean inn i tradisjonelle prosjekter?
I den siste tiden har jeg hatt glede av å delta i en tankesmie om bruk av Lean i IT-prosjekter. I tankesmien har det deltatt både ingeniører, advokater og økonomer. Ideen har vært å få ulike perspektiver på hva som er de praktiske utfordringene i slike prosjekter, både fra leverandørsiden, kundesiden og det juridiske. I smien har vi hatt med Iterate fra leverandørsiden, Belief som representant fra kundesiden og Bull & Co fra juridisk.
Arbeidet har bestått i å sammenligne de tradisjonelle prosessene med de arbeidsmåtene Lean foreskriver. På den måten har vi klart å tegne et kart som beskriver veien frem til å utnytte potensialet til Lean i dine IT-prosjekter. Hva er potensialet til Lean? Riktig utnyttet kan det oppsummeres på denne måten:
- Lavere investeringer og dermed lavere risiko
- Tidligere Return-On-Investment og dermed mer lønnsomme prosjekter
- Bedre feedback og dermed bedre løsninger for sluttbrukeren
Arbeidet med dette skal resultere i et veikart fra tradisjonelle til innføring av Lean i organisasjonen. Det vil være fokusert på utfordringer fra de ulike ståstedene i tankesmien. Det ser ut til å bli i form av et frokostseminar torsdag 8. oktober 
Følg med!
Minimum Marketable Features
Minimum marketable features and incremental funding are used to partition the functionality of a computer system into units that are capable of delivering business value independently. By organizing a development project around MMFs and their internal dependencies, it is possible to have partially self-funding projects: As an MMF is completed, the business value that is saved or generated as it goes into production is used to fund the development of subsequent MMFs. Hence, we lower the up-front investment of our projects, and we reduce the development risks by continuously deploying functionality into production.
In short, we may say that using MMFs provide a financial model for lean thinking in software development projects. (For more info on this, refer to the excellent introduction given in “Software By Numbers” by Mark Denne and Jane Cleland-Huang, Prentice Hall, 2003).
