Projekt kundreskontraportalen

1. Projekt kundreskontraportalen Malmö stad

2. Malmö – en mångfald av möten och möjligheter • Malmö är regionens tillväxtcentrum • Här bor över 311 000 invånare • Ökande befolkning för tjugoandra året i rad • Ca 26% av stadens invånare är födda utomlands • 169 nationaliteter representerade • Ung befolkning: ca 47% är under 35 år

3. Raindance i Malmö stad • Produktionsstart: oktober 2006 • En installation med 40 ramföretag varav 25 förvaltningar • 8000 användare varav 2500 beställare • Unix-server och Oracle databas

4. Malmö stads ekonomisystemslösning • Leverantörsfakturaportalen • Internfakturaportalen • Anskaffningsportalen • Kundfakturaportalen • Bokföringsportalen • Budget och Prognos • Projektmodul • Tidmodul • Frågor och Analys • Rapporter • Efterkalkyl • Koordinator – ej produktionssatt • Huvudbok, reskontror • Anläggningsredovisning • Utdataplattform – UDP • Konsolidering- kommunen • Cognos BI - avvecklas • QlikView • Stratsys

5. Kundreskontraportalen • Raindance helt nya kundreskontra – från grunden • Raindance användarförening har bidragit med en del av sin timpott (750 timmar/år) • Kärnan används för att framöver bygga en ny leverantörsreskontra och internreskontra • Att byta ut sin reskontra ska drivas som ett projekt där CGI hjälper till eftersom det är ett helt nytt arbetssätt

6. Deltagare i projektet Projektledare: • Louise Hökmark, CGI • Per Nilsson, Malmö stad Projektmedlemmar: • Processgruppen för kundfakturor, Malmö stad • Sandra Staffas, CGI • Pilotförvaltning i Malmö stad

7. Processorganisation i Malmö stad • Kommungemensam processorganisation för stadens ekonomiprocesser som kallas för Effecto • Uppdraget är att förbättra, utveckla och effektivisera kommunens ekonomiprocesser

8. Effecto – processorganisation Styrgrupp Ekonomichefer Processledar-grupp Inköp Redovisning Bokslut Kundfakturor Budget Uppföljning Prognos Leverantörs- fakturor Gemensam kravhantering Avveckling av handkassor Anläggnings- redovisning

9. Projektets upplägg • Förstudie – systemimplementering – driftsättning • Uppstartsmöte i januari • Processorganisationen för kundfakturor deltog i uppstartsfasen

10. Projektets upplägg • Inventering av nuvarande upplägg gjordes under ett antal planeringsmöten under januari-februari • Problem och brister i nuvarande kundfakturaportal och kundreskontra lyftes • Prioritering av utveckling i KRP fastställdes • CGI visar lyhördhet för de utvecklingspunkter som Malmö stad lyfter

11. Projektets upplägg • Pilotförvaltning i lämplig storlek valdes ut • Valet föll på grundskoleförvaltningen • Uppstarts- och planeringsmöten med pilotförvaltningen under mars-april • Mallar togs fram för upplägg i testmiljö

12. Testuppsättning • Kundtyper • Fakturatyper • Kunder • Verifikationstyper • Tabeller på fakturor och kunder • Konvertering (fakturor och kunder)

13. Testuppsättning • Vi kommer att testa i 2014 vår • I denna version är det första gången som KRP är helt fristående från KR • Vi har i skrivande stund inte fått tillgång till ”vårt” upplägg, planerat till fredagen den 16 maj

14. Pilotförvaltningen • Grundskoleförvaltningen • Viktigt med en engagerad och driven pilotförvaltning, vilket vi verkligen har i projektet • Specialanpassad konfiguration, t.ex. kundtyper

15. Pilotförvaltningen • Några av deras ytterligare önskemål: • Bättre kontroller i kundregister • Svårare att göra ”fel” så att verksamheten kan göra mer – införa kontrollsteg i workflow • Tydligare information om kunders betalningsvanor • Skapa en enkel och tydlig process • Underlätta för verksamheten

16. Förbättringar • Kopiering av fakturor • Behörighetshantering, roller • Utdata – UDP, rapporter, direktuppdaterat • Helkreditering och delkreditering – attest och periodisering

17. Förbättringar • Betalningscentral – lägga inbetalningar under utredning • Anpassade vyer och min sida • Ny funktion för avbetalningsplan

18. Förbättringar • Nya statusbegrepp • Periodisk fakturering • Masshantering • Sökning

19. Önskad utveckling • Bilagor, utskriftsalternativ • Osäkra fordringar • Skyddade adresser • Bättre hantering av flera olika faktureringsadresser

20. Teknik • Kräver BAS 4, UDP, AXT-utskrift • Databas: Oracle eller Microsoft SQL-server • I övrigt krävs samma som för Raindanceportalen (Tomcat + java på webbservern) • Kontakta er teknikkonsult • Inga större insatser i vår tekniska miljö

21. Planerade aktiviteter • Vår: • UDP – behovsinventering • Tester • Beslut om produktionssättning till hösten • Höst: • Produktionssättning på pilotförvaltning • Utvärdering och ställningstagande kring utrullning • Komplettering av funktionalitet (räntehantering, osäkra fordringar) • Höstversion 2014 med ytterligare funktionalitet

22. Vi väntar på… • Jobbhantering • Komplett räntehantering • Konteringsregler • Artikelregister

23. Vi väntar på… • Anståndshantering • Konteringsmallar och favoriter • Export/import av konteringar

24. Workflow • Fakturan passerar i systemet enligt uppsatta regler. • Flödet kan t.ex. vara granska – kontera - attestera • Flödet kan initieras baserat på belopp, kunder, fakturatyp, olika tabelltyper • Attestflödet baseras på attestregelverk och en utvald koddel, t.ex. kostnadsställe

25. Workflow

26. Workflow • CGI liknar flödet vid en ”bröllopstårta”

27. Workflow • Begreppet cirkulation finns inte längre, men möjlighet att skjuta fakturan vidare i flödet • ”Att – göra” lista • Viktigt att arbeta med ersättarfunktionen i attestregelverket • Ha inte attestregler som ser exakt likadana ut!

28. Att tänka på • Bygger på nytt workflow, nytänk! • I nuläget inte helt integrerat med övriga Raindanceportalen • Gäller inte intern kundfaktura

29. Integrerad KRP

30. Att tänka på • Integrationer måste byggas om • Allt inte färdigutvecklat, kommer kompletteringar 2014 höst och även 2015 – möjlighet att påverka! • Underskatta inte den tid och de resurser som krävs för att delta i den här typen av projekt

31. Avslutning • Spännande att vara med och utveckla • Samarbete som både CGI och kund kan tjäna på

32. Frågor!