Lindbak Retail Systems - et selskap i LindbakGruppen

1. Lindbak Retail Systems - et selskap i LindbakGruppen PUG møte Lillehammer 7. – 8. april

2. LindbakGruppen • Etablert i 1958 • 137 medarbeidere • Omsetning ca. 259 millioner kroner (2004) • Kontorer i Trondheim, Oslo, Bergen, Molde og Namsos • Fire datterselskaper: • Lindbak AS (salg av kontorutstyr) • Lindbak Distribusjon (import og distribusjon av kopi/print) • Lindbak Stormarkeder (driver Binders-butikk i Trondheim) • Lindbak Retail Systems • www.lindbak.no

3. Lindbak Retail Systems AS • Programvareutvikling siden 1968 • Kontorer i Trondheim, Oslo og Bergen • God lønnsomhet over mange år • En av Norges ledende totalleverandør av butikkdata • Solid kompetanse og lang erfaring fra en rekke leveranser innen dagligvare og faghandel • Komplett styringssystem for… • Kjedeledelse, regionalt hovedkontor, varehus og butikker • Fleksible, åpne og avanserte kasseløsninger (POS) • Dekker hele Skandinavia: • Egen avdeling samt forhandlere i Sverige • Også kunder i Danmark

4. Forretningsidé • Salg, installasjon og support av egenutviklede og forhandlede administrative styrings- og informasjonssystemer for drift og ledelse av butikker og detaljhandelskjeder

5. LRS – et selskap i vekst

6. InfoPOS PRO (Professional) • Komplett styringssystem for dagligvare og faghandel • Den ultimate løsning for kjedeledelse, hovedkontor og kjedestyrte butikker • Brukervennlighet og fleksibilitet i alle ledd – fra kasse til kjedekontor InfoPOS SE (Spesial Edition) • Styringssystem for butikker og frivillige kjeder • Utviklet for sko-, sport- og motebransjen • Spesielt egnet for butikker som selv i stor grad styrere sortiment og innkjøp InfoADB for Samvirkelag • Fleksibelt, effektivt og brukervennlig arbeidsverktøy for regnskap, fakturering, lønn/personal, medlems- og skrankeløsning samt avansert ledelsesrapportering. Våre produkter

7. Kundereferanser Båtbutikken

8. Antall installasjoner

9. Erfaringer fra et moderniseringsprosjekt PUG møte Lillehammer 7. – 8. april

10. Agenda • Hvorfor utvikle ny løsning? • Valg av teknologi • Dynamics prosjektet • Forprosjektet og samarbeidet med Progress Empowerment senteret i Rotterdam • Totalprosjektet • Viktige nyheter/endringer • Veien videre…

11. Hvorfor utvikle ny InfoPOS løsning? • Svakheter ved dagens løsning (InfoPOS PRO 8.0) • Utviklet i Progress ADM1, uegnet for tilpasning til ”tynn” løsning, lite åpen for omverdenen • Mye av lite strukturert kode (ingen bruk av structured procedure) • Krever database lokalt i hver butikk (dersom bakromsløsning) • Utfordringer m.h.t. databasekonsistens HK – butikk • Tidkrevende oppgraderingsrutiner • Omfattende å gjennomføre større endringer (med DB-endringer) • Påtrykk fra kunder • (For) mye datatrafikk • Enklere tilgang til data (tilgang til HK data i butikk) • Tendenser i markedet • ”Tynne” dataløsninger etterspørres og tilbys i de fleste sammenhenger. • Datautveksling med 3. parts systemer • Tilrettelegge løsningen for ASP/BSP drifting • Også i LRS regi

12. Valg av teknologi • Hvorfor valgte vi Dynamics fra Progress • Naturlig å fortsette med Progress verktøy, • Vi forventet mye gjenbruk av kode (rapporter, ”batch” jobber, generell forretningslogikk) • Kunne bygge videre på eksisterende kompetanse • Dynamics er en meget moderne verktøyplattform • Progress Dynamics var ”voldsomt” i skuddet på slutten av 2003 • Basert på Progress sin siste versjon - OpenEdge 10 • De aller fleste skjermbilder lagres i repository database (mindre kode på disk) • Forenklet vedlikehold og videreutvikling • Progress Empowerment senteret bistod oss i dette valget

13. Dynamics prosjektet – forprosjektet • Samarbeid med Progress via deres Empowerment senter i Rotterdam • LRS ble pilotkunde i gjennomføringen av deres nye konsept for et moderniseringsprosjekt • Deltagere i de første faser (forprosjektet) – Odd Erik Eide og Per Holm fra LRS, samt Tom Nøkleby fra Polygon SW • Prosjektet ble inndelt i ulike faser • Avklaringer rundt status i dagens løsning (InfoPOS 8.0), samt kompetanse og opplæringsbehov for våre involverte ressurser (Assessment – oktober 2003) • Status – verken løsning eller personell spesielt tilpasset (programmering for) 3-lags arkitektur (lang vei å gå) • Gjennomførte workshop for oppfriskning av Dynamics kompetanse • Dynamics kurs gjennomført våren 2003

14. Dynamics prosjektet – forprosjektet • Gjenbruk av kode (Harvest – november/desember 2003) • Bruk av UML-verktøy (Enterprise Architect) • Beskrivelse av gammel og ny løsningen • Meget arbeidskrevende • Nyttig hjelpemiddel for beskrivelse av nye moduler (Jobbserver) • Forsøk på bruk av hjelpeverktøy utviklet av Progress fungerte dårlig • Den delen av prosjektet som fungerte dårlig • Mye tid ”kastet bort” på lite meningsfullt arbeid • Progress sitt ambisjonsnivå for dokumentering var alt for høyt, spesielt siden LRS hadde full kontroll med den gamle løsningen • LRS sin målsetting var i utgangspunktet en konvertering av eksisterende funksjonalitet med noen få, men viktige endringer

15. Dynamics prosjektet – forprosjektet • Utviklingsprosjektet startet i januar 2004 • Iterasjon 1 – ”Proof-of-concept” (januar  31/3-2004) • Utvikling av 1 enkelt og 1 komplisert vedlikeholdsprogram, 1 rapport, 1 batchjobb, utvikling av 1. versjon av jobbserver • Støtte fra ”mentor”, Robbert Dees, fra Empowerment senteret (fungerte meget godt) • Telefonkonferanser flere ganger i uka, samt flere oppfølgingsbesøk hos LRS • Meget bratt læringskurve • Avsluttet med estimering av totalprosjektet og beslutning om å gå videre

16. Status Empowerment programmet • Positive erfaringer • LRS fikk betydelig oppmerksomhet • Tilnærmet ubegrenset tilgang på mentor en lang periode • 1 uke i Rotterdam med 3 personer • Praktisk vinkling og oppfølging fungerte meget godt • Innføring i nye metoder/verktøy • Ikke fullt så positivt • Det nye konseptet for et moderniseringsprosjekt var uferdig • For mye ble til underveis og/eller ble overlatt til LRS å finne ut av • Det manglet en ”White book” • Hjelpeverktøy virket ikke, mye manuell jobbing • Forsøkte å lage en felles løsning for alle type kunder • Alt for stort og unødvendig (for LRS) fokus på gammel løsning • Dette er justert i ettertid, blir lagt opp etter hver enkelt kunde

17. Dynamics prosjektet • Estimert til ca 4000 utviklingstimer etter iterasjon 1 • Iterasjon 2 (april  31/8-2004) • Empowerment senteret (v/Robbert) deltok ”løselig” i første del • Iterasjon 3 (september  15/11-2004) • Iterasjon 4 (november  31/12-2004) • Planlagt ferdigdato for estimert utvikling 31/12-2004 • Planlagt i Q1 2005 • Perfeksjonering av rutiner for deployment • Konverteringsrutiner fra InfoPOS 8.0 (gammel versjon), inkl installasjon av ny Progress versjon (OpenEdge 10.0B) • Brukerdokumentasjon, skifte fra Win95 til html (dagens standard) • ”Porting” av ny/endret funksjonalitet i gammel versjon til ny. • Utfordring å holde krevende eksisterende kunder fornøyde • Det ble gjort svært mye, til dels store endringer i gammel versjon i 2. halvår 2004 • Optimalisering av den eldste koden fra iterasjon 1 og 2

18. Prosjektorganisasjonen • Internt LRS • Utvikling 4 personer • Test/kvalitetssikring 2 personer • Dokumentasjon 1 person • Miljø/Deployment 1 person • Innleide konsulenter • Planlagt med 2 utviklere i 50 % stilling iterasjon 2  4 • Bjørn Kroghrud fra Progress Norge har deltatt hele veien og har vært en meget verdifull ressurs • Tom Nøkleby fra Polygon SW deltok primært 1. halvår 2004 • Adm. prosjektleder i 1/3 stilling i hele prosjektets levetid • Utvidelser fra september 2004 • 2 utviklere på tilnærmet heltid • 1 person på test/prosedyrer på tilnærmet heltid

19. Omfang av prosjektet • Ca 250 skjermprogram (inkl. rapport/”batch” bestilling) • Måtte lages helt på nytt • Ca 125 rapporter • Gjenbruk av mye kode • Ca 50 ”batch” program • Gjenbruk av mye kode • Totalt antall program fra gammel versjon • ca 1000 skjermbaserte program • ca 1250 rapport/batch program • ca 720 include filer • Resultat i ny versjon (InfoPOS PRO 9.0) • ca 750 program • ca 350 include filer

20. Omfang av prosjektet • Totalt antall timer: 11 500 • 2003: 1300 timer • 2004: 8100 timer • 2005: 2100 timer • Fordeling av timer • Kompetanseheving/teknologi: 2000 timer • Utvikling: 6750 timer • Testing: 2000 timer • Prosjektledelse: 750 timer • Direkte kostnader • Eksterne konsulenter: NOK 5 mill. (ca 6000 timer)

21. Nye verktøy • Dynamics og OpenEdge 10 fra Progress • Enterprise Architect • UML (Unified Modeling Language) • Prosessbeskrivelse med utgangspunkt i ”Use-Case” (brukerens opplevelse) • Meget nyttig for beskrivelse av nye, komplekse moduler • Jobbserver • Sharepoint fra Microsoft • Utviklingsportalen, strukturere og tilgjengeliggjøre informasjon • TestTrack Pro • Rapportering av feil erfart i test • Beskrivelse av fix, klar for ny test

22. Status i Dynamics prosjektet pr 31/3-2005 • Prosjektet er overlevert til linjeorganisasjonen i LRS • Alle eksterne konsulenter er ute av prosjektet • All planlagt koding er ferdig • Så lenge LRS har 2 levende programversjoner vil det være behov for ”porting” av ny/endret funksjonalitet • Testing er i all vesentlighet avsluttet • Over 500 feilmeldinger er meldt, korrigert og retestet OK • Dokumentasjon tilgjengeliggjort på Utviklingsportalen • Prosjektet er godt dokumentert • 100 % systemdokumentasjon for hvert menyvalg • Utrulling • Rutiner for utrulling fra utvikling til test • Rutiner for utrulling fra test til produksjon (gjenstår noe) • Rutiner for utrulling av InfoPOS PRO klient • Automatisk oppgradering av InfoPOS PRO server

23. Status i Dynamics prosjektet pr 31/3-2005 • Kvalitetssystem innført i løpet av prosjektet (”fra teori til praksis”) • Systemdokumentasjon • Testprosedyrer • Prosjektstyring • Gjenstående som ferdigstilles i april 2005 • Ferdigstille rutiner for overføring fra test til produksjon • Ferdigstille rutiner for konvertering av database fra gammel løsning til ny løsning (inkl. bytte av Progress versjon) • Ferdigstille brukerdokumentasjon • Innføring av ”nice-to-have” funksjonalitet • Showstopper? • Tynn klient ”fryser” og må termineres • Synes å være et Appserver problem (ikke relatert til Dynamics) • Progress jobber hardt med problemet (første fix løste ikke problemet)

24. Erfaring med bruk av Dynamics • Høy brukerterskel for utvikler (spesielt for LRS med erfaring kun fra ADM1) • Det enkle er veldig enkelt, det kompliserte meget utfordrende • Utmerket prototyp verktøy, kort vei til kjørbar løsning • Enkelt å flytte rundt på objekter innen en container • (For?) striks oppbygging med krav til at browsere/viewere må ha kobling til SDO m/nødvendige linker

25. Erfaring med bruk av Dynamics • Utvalgsbilder for bestilling av rapport/”batch” jobb • Startet med en løsning knyttet til temp-db og bruk av mange SDF, som viste seg å fungere for dårlig (performance) • Konverterte til egenutviklet løsning der skjermbilder konstrueres på klientsiden basert på input fra rapport/”batch” programmet. • Omskriving av et betydelig antall rapporter • Tilfredsstillende performance som må bevises i praksis • Mye tid brukt til tuning av store, kompliserte program, samt oppsett av optimal caching • Mangler • Dynamisk dialog-box • Bruk av OCX’er i dynamiske viewere • Det burde være unødvendig med statiske objekter bortsett fra logiske prosedyrer og superprosedyrer (som ideelt sett også burde vært lagret i repository) • Bruk av ProDataset

26. Jobbserver • Utfører prosessering av bestilte rapporter, etikettutskrifter og ”batch” jobber forøvrig • Utviklet i Progress • Startes automatisk som egen service • Klienten bestiller jobben som sendes til sentral server • For rapporter varsles brukeren når den er ferdig • Klienten sjekker med jevne mellomrom om det er noe nytt siden sist • Alle rapportene genereres i VsView i PDF-format og i (uformatert) Excel-format • Både PDF-fil, Excel-fil og etikettutskrift som XML-fil lagres i en blob i databasen • Bruker henter opp utskriftene fra en browser • Statusbrowser for ”batch” jobber

27. Automatisert utrulling • Serveroppdatering på HK • Det lages en pakke/release bestående av: • Endringer på dynamiske objekter (alle endringer i repository databasen i XML-format) • Alle statiske objekter • DF-fil med databaseendringer • Kilentpakke • Programvaredistribusjon via GoAhead • Klientoppdatering • Pakke laget med WebClient assembler • Komprimert • Hentes fra Web server på HK hos kunden

28. Web-basert utrulling

29. Viktige database endringer • Extent (tabell i tabell) er fjernet fra alle tabeller • Erstattet med enkeltposter (for eksempel pr uke/måned) • Store tabeller fra gammel løsing er ”brutt opp” • Delvis splittet opp i enkeltposter pr transaksjonstype • Spesielt finansiell statistikk (kasserer, kasse) • Delvis splittet opp i flere relaterte tabeller • Feltnavn • Fjernet bindestrek i feltnavn • Konsekvenser • Mer fleksibel løsning • Medførte tildels store endringer i forretningslogikk

30. Nytt brukergrensesnitt InfoPOS PRO 8.0 InfoPOS PRO 9.0 ――►

31. Systemkrav • PC for WEB-klient • OS: Windows XP (Windows 2000 kan benyttes) • Prosessor: 1 GHz eller mer (anbefalt minimum) • Minne: 256 MB RAM eller mer (anbefalt minimum) • Progress WebClient: 21 MB • InfoPOS PRO 9.0 klient: 140 MB • LAN eller bredbåndslinje mot server med appserver/database, minimum 1 Mbps • Server på HK • OS: Windows 2000 eller Windows 2003 • Jo kraftigere server, jo bedre ytelse

32. Veien videre…. • Pilotinstallasjon i mai 2005 • Oppgradering av eksisterende kunder påbegynnes høsten 2005 og skal være utført innen utgangen av 2006 • LRS har startet opp nytt forprosjekt for utvikling av ny løsning for kasse i .Net/C# • 3-lags arkitektur der kassene kan være tynne klienter til en felles database i butikk eller på HK • Utviklingsavdelingen som p.t. består av 14 skal i løpet av kort tid ansette 3 nye medarbeidere • 1 adm. prosjektleder og gruppeleder for test/kvalitetssikring • 1 utvikler i kassegruppe (.Net/C#) • 1 utvikler i butikk/hovedkontorsløsningen utviklet i Dynamics (OpenEdge) • Arbeidssted i Trondheim

33. Veien videre med Progress Dynamics? • Progress Newsletter March 2005 • Progress Dynamics 2.1B • With this release, Progress Dynamics Version 2 becomes Functionally Stable. Functionally Stable Phase products are fully supported but do not receive new features. Technical Support continues to work with customers to resolve issues and Service Packs continue to be issued that further increase product stability and performance • Vi ser konturene av nok et konverteringsprosjekt en gang i fremtiden • Hvor lenge kan LRS beholde en løsning basert på en teknologi som Progress har besluttet å ikke satse på framover

34. Spørsmål? ?