IT-verktyg för kundservice, entreprenörsuppföljning och fakturering. RVF Utveckling 2005:03 ISSN 1103-4092

IT-verktyg för kundservice, entreprenörsuppföljning och fakturering RVF Utveckling 2005:03 ISSN 1103-4092

RVF Utveckling2005:03 ISSN 1103-4092 RVF Service AB Tryck: Daleke Grafiska 2005 Upplaga: 1000 ex

Förord Rationella och överskådliga verktyg för kundservice, entreprenörsuppföljning och fakturering är viktiga hjälpmedel för alla kommuner. Det finns skiftande förutsättningar vilket ställer olika krav på de IT-baserade systemen. RVFs arbetsgrupp för Beställarfrågor har initierat en kartläggning av medlemmarnas behov av sådana system. Ett underlag för kravspecifikationer har utvecklats och rekommendationer för principer och krav på systemen har utformats. Projektet har genomförts av Sven Sjölander, IT-Fabriken Sverige AB. Projektledare har varit Karl-Åke Hansen, Kretsloppskontoret i Göteborg. Malmö i mars 2005 Håkan Rylander Ordf. RVF:s Utvecklingskommitté Weine Wiqvist VD RVF

Författarens förord Beställargruppen inom Renhållningsverksföreningen (RVF) har initierat ett projekt för att kartlägga medlemmarnas behov av IT-stöd för kundservice, entreprenörsuppföljning och fakturering. Denna rapport baseras på en utförd enkätundersökning bland RVF:s medlemmar, en marknadsundersökning baserad på frågor till leverantörer av IT-systemen, samt diskussioner inom en styrgrupp. Arbetet har utförts i samarbete av en extern konsult och en styrgrupp med medlemmar från fyra olika kommuner. Karl-Åke Hansen, Göteborg Kristina Elsisdotter, Stockholm Lena Ahlcrona-Söderholm, Malmö Lena Östberg, Sundsvall Konsult: Sven Sjölander, IT-Fabriken Sverige AB

Innehållsförteckning 1 Rapportens uppdelning...4 2 Inledning...4 2.1 KEF-system...4 2.2 KEF-funktionskarta...5 2.3 Grundläggande begreppsmodell...5 2.3.1 Nyttan av en standardiserad och detaljerad begreppsmodell...7 2.4 Använda förkortningar...8 3 KEF-grund...9 3.1 Grundläggande begreppsmodell...9 3.2 Taxa...9 3.2.1 Taxekonstruktion...9 3.2.2 Taxesimulering...10 3.2.3 Taxekalkyl, taxesimulering för enstaka kunder/tjänster...10 3.3 Fakturaunderlag...10 3.4 Ruttplanering och körlistor...11 3.4.1 Import av körlistor och hämtningstider...11 3.4.2 Ruttplanering...11 3.4.3 Ruttoptimering...11 3.5 Tömningsregistrering...12 3.6 Avvikelse- och reklamationshantering...12 4 Fakturering/kundreskontra...12 5 Informationsåtkomst och klientprogram...13 5.1 Personal, huvudprogrammet (klientprogrammet)...13 5.2 Entreprenörer, informationsutbyte...15 5.3 Kunder, informationsutbyte...15 6 Externa informationskällor och informationssystem...16 6.1 GIS...16 6.2 FIR...17 6.3 Företags- och kommuninvånarregister...17 7 Informationsuttag...17 7.1 Standardrapporter...18 7.2 Export av data...18 7.3 Framtagning av egna rapporter...18 7.4 Integration mot andra program...19 7.5 Generera adressetiketter och brev...19 8 Övrigt...19 8.1 Stöd för andra verksamheter...19 8.2 Anpassningar av ledtexter och attribut...19 8.3 Behörighet...20 8.4 Historik...20 8.5 Databas och operativsystem...21 8.6 Drift och support...21 8.7 Status på nuvarande system...21 9 Övergripande principer...23 9.1 Fakturering...23 9.2 Kommunikation med entreprenörerna...23 9.3 Databaskrav...23 9.4 Web-funktionalitet...23 10 Grundläggande krav på ett KEF-system...24 2

10.1 Fakturering...24 10.2 Rapportering till ekonomisystem...24 10.3 Grundläggande objekt...24 10.4 Enreprenörskommunikation...24 10.4.1 Beställningar...24 10.4.2 Återrapportering av utförda hämtningar...24 10.4.3 Entreprenörsavräkning...24 10.5 Taxan...25 10.5.1 Taxekalkyl, taxesimulering för enskild kund/tjänst...25 10.5.2 Viktbaserad taxa för hushållsavfall...25 10.6 Körlistor...25 10.7 Konvertering av data...25 11 Utökad funktionalitet för ett KEF-system...26 11.1 Begreppsmodell och databasrealisering...26 11.2 Web-baserad kundinformation...26 11.3 Ruttplanering...26 11.4 GIS-koppling...26 11.5 FIR-koppling...27 11.6 Koppling till företags- och kommuninvånarregister...27 11.7 Ägarbyteshantering och bevakning...27 11.8 Kommunikation med andra program...27 11.9 Övrigt...27 12 Verksamhetsstödjande krav...28 12.1 Taxekonstruktion och taxesimulering...28 12.2 Nycklar och portkoder...28 12.3 Entreprenörsavtal...28 3

1 Rapportens uppdelning Denna rapport är uppdelat i tre huvuddelar. Inledning I kapitel [2] finns en förenklad begreppsmodell, funktionalitetskarta och en kort ordlista. Sammanställning av enkätundersökningen, leverantörsvaren och styrgruppens kommentarer I kapitel [3]-[8] beskrivs olika kravställningar rörande ett KEF-system baserade på enkätundersökningen till RVF:s medlemmar, fyra olika leverantörers svar och diskussioner inom styrgruppen. I samband med de olika kravställningarna följer stycket Slutsats av leverentörssvaren, där slutsatser baserade på leverantörssvaren återfinns. Rekommendationer inför upphandling I kapitel [0-12] delas kravställningarna in i Övergripande principer, Grundläggande krav, Utökad funktionalitet och Verksamhetsstödjande funktioner. Här återfinns styrgruppens rekommendationer inför en upphandling. 2 Inledning Denna rapport baseras på en utförd enkätundersökning bland RVF:s medlemmar, en marknadsundersökning baserad på frågor till leverantörer av IT-systemen, samt diskussioner inom en styrgrupp. Enkätundersökningen skickades ut till 213 kommuner, varav 110 svarade. Marknadsundersökningen baseras på svaren från samtliga fyra tillfrågade leverantörer. För att enklare diskutera funktioner och begrepp har en grundläggande funktionskarta och en förenklad begreppsmodell tagits fram. Rapporten hänvisar ofta till begrepp och uppdelningar i dessa. 2.1 KEF-system Med namnet KEF-system avses ett IT-system för stöd till Kundservice, Entreprenörsuppföljning och Fakturering. 4

2.2 KEF-funktionskarta Notera att ett verkligt realiserat system inte behöver följa denna uppdelning. 2.3 Grundläggande begreppsmodell Den nedan beskrivna begreppsmodell kan ses som ett första förslag för att erhålla en gemensam branschstandard. I begreppsmodellen anges ett antal olika objekt, tillsammans med en förklaring och typiska attribut. Begreppsmodellen är ingen komplett modell, utan mycket kraftigt begränsad. Det skall inte ses som att ett visst system måste behöva följa de angivna benämningarna. Varianter av och tillägg till begreppsmodellen förekommer givetvis. 5

Objekt Beskrivning Typiska attribut Kund Betalningsansvarig för en levererad tjänst kundnummer, namn, person/organisationsnummer, kundtyp, faktureringsadress, telefonnummer (flera), fax, email, Betalare, förvaltare fakturamottagare Anläggning Tjänst Den part som sköter betalning åt en eller flera kunder Ett antal tjänster till en viss fastighet för en specifik kund. En anläggning bör kunna knytas till en viss given fastighet (eller flera) En eller ett antal av en viss produkt på en viss geografisk plats. En produkt kan ses som en kombination av behållartyp, avfallstyp, hämtningsintervall. I en tjänst kan även ingå betalningssätt, momspliktig Namn, person/organisationsnummer, faktureringsadress, telefonnummer(flera), fax, email Anläggningsnr, fastighet, adress Produkt (behållartyp, avfallstyp, hämtningsintervall, taxa), avstånd, placeringsbeskrivning, datum senaste hämtning, entreprenör hämtningsförhållandet Behållare En viss given behållare BehållarID, behållartyp, avfallstyp, volym, markering att streckkod finns, markering att transponder(tagg) finns Soprum, hämtställe Nycklar, portkoder Entreprenör Den fysiska platsen (soprum är speciellt viktigt, se nycklar nedan) där behållarna för en viss tjänst är placerad. Flera tjänster kan ha flera samma soprum/hämtställe. Notera även att olika kunders anläggningar kan dela på ett soprum/hämtställe Information kring mottagna nycklar och portkoder för att komma till ett visst soprum/hämtställe. Nycklar och portkoder skall kunna registreras att de används till flera soprum/hämtställen. Ett system som hanterar denna information måste givetvis garantera tillräcklig informationsskydd för att hindra felaktigt användning av informationen Vald entreprenör. Varje enskild produkt bör kunna kopplas till en specifik entreprenör Adress, Platsbeskrivning, Hämtförhållande NyckelknippeID, nyckelid, mottagen av, mottagningsdatum EntreprenörsID, Namn I ett program visas ofta information från flera objekt samtidigt. Till exempel när kundinformation visas kan även kundens anläggningar och tjänster presenteras. D.v.s. ett objekt är inte samma sak som informationen i ett programfönster. 6

2.3.1 Nyttan av en standardiserad och detaljerad begreppsmodell Möjligheter finns för en framtagning av en standardiserad och detaljerad begreppsmodell. Den förenklade modell som togs fram för detta arbete tyder på att det både finns ett intresse av detta och möjligheter till det. En framtagen begreppsmodell bör även innefatta modell för ruttplanering (framförallt körlistorna) och taxan (inkl taxekonstruktion). En branschgemensam kommunikation och informationsstandard skulle medföra lägre utvecklings- och anpassningskostnader. Grunden till detta är en standardiserad begreppsmodell En framtagen begreppsmodell kan bland annat användas till: Avsevärd förenklad kravställning vid upphandling av system Stöd för att ställa funktionalitetskrav på taxekonstruktion, taxesimulering, ruttplanering mm Standardisera importfunktioner av data såsom hämtningsdata (med eventuella dag, tider, vikt etc) Standardisera exportfunktioner av data såsom körlistor Generell standard format av data baserad på objektsmodellen Gemensamt format för konvertering av data vid byte av system Generell start av program med parametrar/data. För enkelriktad kommunikation med Word, Excel, Ekonomisystem, GIS-moduler mm. Standardisera gränssnitt för avancerad kommunikation mellan GIS och FIR Standardiserad kommunikation med leverantörerna och deras system Leverantörerna ställer sig positiva till att delta i ett arbete med framtagning av en standardiserad begreppsmodell. 7

2.4 Använda förkortningar CFD Centrala Fastighets Data. Officiell information från lantmäteriets databas. FIR En lokal fastighetsdatabas. Normalt med data från CFD. FNR Id-nummer för en fastighet GIS Geografisk Informations System KIR KommunInvånarRegister VPN Virtuellt Privat Nät, Uppkoppling mellan två nätverk över Internet (t ex en dator hemifrån kopplas samman med nätverket på arbetsplatsen, som om den vore direkt ansluten dit. WebService Programenhet som kan anropas av andra program. Fungerar över Internet och är bland annat avsett för att möjliggöra kommunikation mellan olika system och parter. 8

SAMMANSTÄLLNING 3 KEF-grund KEF-grund inbegriper de specifika funktionerna som finns för ett system för Renhållningsverksamhet. Ett komplett KEF-system måste kompletteras med funktioner för fakturering, rapportutskrifter mm. 3.1 Grundläggande begreppsmodell En förenklad begreppsmodell med objekten Kund, Betalare/Förvaltare/Fakturamottagare, Anläggning, Tjänst, Behållare, Soprum/hämtställe, Nycklar/portkoder och Entreprenör beskrevs i enkätundersökningen och användes i dess frågor. Begreppsmodellen har också flitigt använts i diskussionerna inom styrgruppen. Kommentarerna till begreppsmodellen i enkätsvaren var mycket positiva. Även leverantörerna verkar vara villiga att delta i ett arbete för att skapa en standardiserad begreppsmodell. En utbyggd begreppsmodell bör även innefatta taxan (taxekonstruktion), ruttplaneringen (körlistor), samt eventuellt fakturaunderlag. Slutsats från leverentörssvaren: Leverantörerna av KEF-system anser att den presenterade begreppsmodellen är relevant och att de uppfyller denna. Objektet nycklar/portkoder är ej är standard i alla system idag. Detsamma gäller att objektet soprum/hämtställen skall kunna referera till flera kunders anläggningar. 3.2 Taxa Prissättning på taxebaserade tjänster/produkter skall utgå från ett antal grundläggande parametrar som kombineras till olika priser för respektive tjänst/produkt. Funktionen skall finnas för att hantera pristillägg för olika hämtförhållanden (draglängd etc) och bör kunna hantera säsongstaxor. Individuella priser på tjänster/produkter som inte baseras på taxan måste kunna anges. Frågan i enkätundersökning om behovet av kombinationsrabatter rönte ett relativt lågt intresse. Eventuellt kan taxekonstruktionen och taxesimuleringen göras i externa program. Import/export av relevant data måste i sådant fall göras. 3.2.1 Taxekonstruktion En tjänst utgör en kombination av behållartyp, avfallstyp, hämtningsintervall och hämtningsförhållande. Priset eller taxan för dessa bör därför utgå från parametrar för behållartyp, avfallstyp och hämtningsintervall. 9

Parametrarna bör också göra åtskillnad mellan kostnader för direkta rörliga kostnader för produkten, påslag för gemensamma kostnader inom verksamheten och för styrande påslag/rabatter. IT-stödet för taxekonstruktionen är bristfällig. Endast en av fyra leverantörer anser sig uppfylla 1:a stycket helt. 3.2.2 Taxesimulering Funktioner för taxesimulering är viktiga vid ändringar av taxan och undersökningar vad tänkbara beteende hos kunderna påverkar verksamheten och intäkterna. Taxesimuleringen bör dels visa direkta påverkan på olika produkters priser, men också simulera tidigare perioders faktureringar för att studera hur det slår för enskilda kunder eller grupper av kunder. Taxesimuleringen skall givetvis också sammanställa de beräknade totala intäkterna för verksamheten med den nya taxan. Notera att taxesimuleringens flexibilitet påverkas av taxekonstruktionens uppbyggnad. Med det stigande antalet tjänster blir behovet allt större av goda verktyg för taxesimulering och taxekonstruktion. Olika former av taxesimulering förekommer i systemen. Funktionaliteten och användarvänligheten kan skilja sig mycket åt. Detaljerade krav och önskemål bör ställas inom detta område. 3.2.3 Taxekalkyl, taxesimulering för enstaka kunder/tjänster Funktion för att bestämma priser på olika tjänster (kombination av tjänster, hela anläggningen etc) utan att dessa skapas, bör finnas i ett KEF-system. Målet är att i diskussion med kunder kunna föreslå olika lösningar och enkelt bestämma priset för dess lösningar. Ja, systemen har taxesimulering för kunder. Funktionaliteten och användarvänligheten kan skilja sig mycket åt. 3.3 Fakturaunderlag Varje KEF-system måste kunna skapa fakturaunderlag. Vissa system fakturerar dessa själv, medan andra exporterar det till andra system. Möjligheter till samlingsfaktura av en kunds anläggningar bör finnas (alla anläggningar eller grupper av anläggningarna). Det bör även finnas möjligheter till att dela en anläggningsfaktura mellan flera kunder. Kunder bör kunna faktureras även om de ej har en anläggning eller tjänst. Ovanstående krav kan tillgodoses. 10

3.4 Ruttplanering och körlistor Ett KEF-system måste kunna visa både utförda och planerade hämtningar hos kunderna. 3.4.1 Import av körlistor och hämtningstider Ett KEF-system skall/bör ha funktioner för att importera körlistor och/eller planerade hämtningstider. Import kan ske av körlistor från entreprenörer eller körlistor framtagna i andra system. Detta är ett krav om entreprenören själv ansvarar för ruttplaneringen. En av fyra leverantörers system saknade funktioner för ruttplanering (inklusive import). 3.4.2 Ruttplanering Om verksamheten sker helt eller delvis i egen regi måste KEF-systemet ha funktioner för ruttplanering. Funktioner för ruttplanering måste kunna ta hänsyn såväl till hämtställens geografiska placering (adress), avfallssorter och hämtningsintervall. En av fyra leverantörer saknade funktioner för ruttplanering och en hade enbart möjligheter till utskrift och export. Notera även att graden av funktionalitet (och komplexitet) för ruttplanering kan skilja avsevärt mellan olika system. 3.4.3 Ruttoptimering Ett system kan också tänkas ha stöd för ruttoptimering. Med detta avses automatisk generering av optimala rutter för sophämtning, utifrån information om placeringen (lämpligen given adress). Systemet kan också exportera information och ruttoptimeringen ske i annat system. Därefter importeras resultatet tillbaka till KEF-systemet. Funktioner för ruttoptimering måste kunna ta hänsyn såväl till hämtställens geografiska placering (adress), avfallssorter och hämtningsintervall. För optimeringen måste även diverse GIS-information finnas tillgänglig. Eventuellt är detta snarare en funktion som bör återfinnas i GIS-system. Export av relevant data bör då göras till sådana system. Systemen saknar stöd för detta. En leverantör hänvisar till att detta kan lösas med hjälp av externa system och export/import. 11

3.5 Tömningsregistrering Ett KEF-system måste kunna registrera genomförda tömningar. Krav ställs på att systemet skall stödja identifiering av enskilda behållare och att registrering av tömning kan ske med eller utan vikt. Om en viktbaserad taxa för hushållsavfall används är denna funktion central. Finns hos de större leverantörerna och är under utveckling av fler. Alla system klarar ej detta idag. 3.6 Avvikelse- och reklamationshantering Funktioner för att hantera avvikelser och reklamationer skall/bör finnas i ett system. Systemets förmåga att snabbt kunna ge information till kunden och registrera reklamationer och erhålla avvikelseinformation från entreprenören är väsentlig. Sammanställningsrapporter är även av stort intresse. Systemen har olika typer av stöd för detta. 4 Fakturering/kundreskontra En avgörande fråga för ett KEF-system är var och hur faktureringen sker och kundreskontran hanteras. Tre alternativ finns KEF-systemet innehåller såväl fakturering och kundreskontra KEF-systemet fakturerar, men andra systen hanterar reskontran KEF-systemet genererar enbart fakturaunderlag, som andra system fakturerar utifrån. I flertalet av systemen sköts fakturering och kundreskontra i KEF-systemet (alternativ 1 ovan) En dominerande majoritet av svarande på enkätundersökningen önskade att systemet själv klarar av fakturering och kundreskontran. Funktioner måste då finnas för anslutning till postens och bankerna OCR-tjänster och hantering av autogiro och e-faktura. Även önskemål om funktioner för att ha export/synkroniseringsmöjlighet av kundreskontran till andra system fanns. Notera att det kan vara förenat med stora kostnader och tekniska problem att integrera ett KEF-system med annat system som hanterar fakturering och kundreskontra. Detta speciellt om man i KEF-systemen vill kunna se fakturastatus, se den verkliga fakturan och ha gemensamma kunder med andra system (med ändringsmöjligheter av kunden i KEFsystemet). Notera att om KEF-systemet själv fakturerar bör det finnas olika möjligheter att skicka fakturorna till kunden. Fakturering kan ske med egna utskrifter per brev, via fil till utskriftsservice, autogiro mm. Ett växande intresse hos större kunder är att även kunna få faktura i XML- eller EDIFACT-standard. 12

Två av leverantörerna erbjuder både fakturering och kundreskontra, medan övriga två enbart fakturering. Samtliga leverantörer har erfarenhet av kommunikation med andra system för hantering av kundreskontra. All kommunikation med externa system torde kunna anses vara kundanpassade lösningar. För att erhålla en bred bas av kunder torde leverantörerna behöva erbjuda en integrerad kundreskontra. Notera att det inte har varit möjligt att inom ramen för detta projekt genomföra en detaljerad kravformulering på fakturahantering och kundreskontra. 5 Informationsåtkomst och klientprogram Ett KEF-system och dess information skall kunna göras åtkomlig för verksamhetens personal, entreprenörerna och kunderna. De olika grupperna har olika krav på åtkomstmöjligheter. 5.1 Personal, huvudprogrammet (klientprogrammet) Systemets viktigaste användare är den egna personalen. Här behandlas all information om kunder, anläggningar, fakturor mm. Klientprogrammet (ett eller flera) för personalen måste därför stödja åtkomst till de olika funktionerna som beskrivs i denna rapport. Med klientprogram menas här ett vanligt program eller web-sidor med motsvarande funktionalitet. Enligt enkätundersökningen anses det tillräckligt att klientprogrammet endast går att köra i Windows-miljö. Intresset är stort att programmet är Web-baserat. I mer än hälften av svaren angavs att kommunikation över Internet skall kunna ske (mellan klienten och KEF-servern). Hos de mindre kommunerna var kravet/önskemålen på Web-baserade system klart lägre. Om ett program skall vara Web-baserat eller vara ett vanligt program innehåller egentligen flera olika frågeställningar. Nedan belyses detta kortfattat. Generellt anses det att man med ett vanligt program kan erhålla bättre användargränssnitt och samverkan med andra program (såsom Office-pakatet) jämfört med ett Web-baserat. Nackdelen är att de kräver installation och normalt ej går att kommunicera över Internat. Vissa program är dock gjorda för att kommunicera över Internet. Det blir även vanligare med program som själv (automatiskt eller efter fråga) uppdaterar sig (över Internet). Ett Web-baserat program kan använda sig av olika tekniker. Med Java eller ActiveXkomponenter är programmet (åtminstone delvis) ett vanligt program som laddas via HTML. Med ActiveX-komponenter (eller.net komponenter) blir systemet enbart körbart på Windows. 13

Tabell med en mycket schematisk bild över olika tekniksätt och funktionalitet Programtyp Vanligt klient program Klient program som kan kommunicera över Internet via http HTML med ActiveXkomponenter Supportad plattform Fungerar över Internet/intranet Fungerar med brandväggar säkerhetsspärrar Windows Nej, om inte Nej, programmet fungerar ej datorn kopplas över Internet. upp mot kommunens nät via VPN. Windows Ja Ja (finns dock möjligheter att spärra i brandväggar) Windows Ja Troligen, beror på konfigurationer (ActiveXkomponenter kan stoppas i brandväggen eller i webbläsaren) HTML med Java Alla Ja Troligen, beror på konfigurationer(java-applets kan stoppas i brandväggen eller i webbläsaren) Ren HTML Alla Ja Ja Nej Sammanfattning Vanlig klient ger bästa möjligheterna till ett rikt användargränssnitt En webbaserad lösning ger lättast installationsförfarande och möjliggör åtkomst över Internet. Se ovan i tabellen för mer information kring installationsförfarande, supportade plattformar och körning över Internet. Med Java-teknik och ActiveX-komponenter kan en webbaserade lösning erhålla ett rikare användargränssnitt och eventuellt jämställas med ett vanligt program. Lösningar med Java och ActiveX kräver att eventuella säkerhetsspärrar tolererar detta. Det är därför ej lämpligt med sådana komponenter mot slutkunder eller andra parter där kommunen ej kan ställa krav. Kravställningar Att enbart ange att en systemlösning skall vara Web-baserad är ej tillräcklig. Om ActiveXkomponenter,.Net-komponenter, Java-Applets får ingå i systemet bör anges. Hela program kan eventuellt också accepteras om de klarar att köra över Internet och installeras automatiskt eller med ett minimum av support. En alternativ lösning för åtkomst till KEF-systemet är också VPN-lösningar. Notera att möjligheten att köra över Internet påverkas av hela kommunens IT-strategi och säkerhet. Programtypen på klientprogrammen varierar. Vanligast är vanliga program eller Weblösningar med ActiveX-komponenter. De stora leverantörerna saknar idag webbaserade lösningar. En tendens är dock att olika former av webblösningar kommer för hela eller delar av systemen. Kräver installation på klienten Ja, automatiska uppdateringar kan dock vara integrerat i programmet. Ja, automatiska uppdateringar kan dock vara integrerat i programmet. Nej, ActiveX-komponenten laddas ned automatiskt Nej, Java-Applets laddas ned automatiskt 14

5.2 Entreprenörer, informationsutbyte Kommunikationen med entreprenören är en central del i ett KEF-system och kraven på denna är mycket hög. Tre huvudprinciper för kommunikation med ungefär lika stort intresse i enkätundersökningen var: Kommunen och entreprenörerna kör i samma system, men med olika behörighet Kommunikation via transaktioner (via ftp etc) Direktöverföring mellan KEF-systemet och entreprenörens system via WebService eller liknande Notera att hur detta skall lösas även är en säkerhetsfråga som berör driftsform (var placeras servern) och kommunens IT-policy och säkerhet. Informationsöverföring till entreprenören krävs för: Körlistor, alternativt hämtningsinformation Fritextmeddelanden Anläggningsförändringar (ex. ny eller upphörd behållare, ändrad tömningsfrekvens) Reklamation från kunden (missad hämtning) Beställning av tillfällig extra tjänst (extra hämtning, grovsopshämtning) Informationsöverföring från entreprenörer till KEF-system krävs för: Kvittens/uförandebekräftelse på ovanstående Körlistor, alternativt hämtningsinformation Fritextmeddelanden Ej utförd tjänst, avvikelse (ej utsatt, blockerad behållare) Tömningsregistrering, BehållarID, klockslag, fordonsid, ev. vikt Uppdatering av hämtningsinformation Vid behov kan ett Webbaserat gränssnitt användas för vissa funktioner. Störst intresse för detta fanns för information rörande enskilda missade hämtningar och ej utförda tjänster. Det ansågs viktigt att entreprenörer skall kunna erbjudas programvara till rimlig kostnad som klarar kommunikationsbehovet mot kommunen. Om kommunen och entreprenören kör i samma system löses detta automatiskt. Licensfrågor till entreprenörerna behöver beaktas oavsett om det är speciella programvaror eller om det är inloggning mot befintligt KEF-system. Notera att flera kommuner saknar eget KEF-system. Detta sköts istället direkt av entreprenören. Endast en leverantör använder sig av filöverförda transaktioner och övriga använder sig av behörighetsanpassade system. 5.3 Kunder, informationsutbyte Kunderna bör ha tillgång till information om sina anläggningar via Internet och kunna utföra enklare uppgifter såsom beställningar, flyttningsanmälan, rapportera missade hämtningar, läsa 15

fakturor mm. I listan nedan anges procentsatsen hur stor del av de svarande som anser att respektive funktion skall finnas. Uppgift % Rapportera utebliven hämtning eller annat problem etc. 78 Begära ändring av tjänst 71 Beställa extra tjänster 76 Anmäla flyttning 84 Ansökan om autogiro (elektronisk signatur) 71 Läsa sin räkning 68 Se sina anläggningar och övriga tjänster, exempelvis tömningsdatum och vikt 70 Se allmänt meddelande från kommunen 71 Se kundspecifikt meddelande från kommunen 54 Tio procent av de svarande ansåg att åtkomst för kunden ej var aktuellt över huvud taget. Webbaserade tjänster för kunderna bör baseras på ren html. Leverantörerna har eller kan ordna ovanstående funktioner. 6 Externa informationskällor och informationssystem Systemet bör kunna samverka med andra informationssystem/källor. Samverkan med andra system kräver god datakvalité i samtliga system. Att i ett senare läge rensa för felaktiga eller saknade personnummer, organisationsnummer, adresser och namn ger stora problem. Omorganisationer av kommunens verksamheter kan också medföra sammanslagningar av informationssystem eller samverkan med nya system. Om namn kontrolleras mot person respektive företagsregister och fastighetsbeteckningar och adresser kontrolleras mot CFD-data ökas datakvalitén avsevärt. Notera att funktioner enligt ovan bör vara stödjande och inte alltid tvingande. Historiska (importerade data) och olika specialfall måste kunna hanteras. Viktiga nycklar i externa system ID Betydelse Personnummer Organisationsnummer FNR-nummer Fastighetens ID i CFD Fastighetsbeteckning Fastighetens beteckning i CFD (kan dock ändras) AdressID Id på adress (en av fastigheternas adress) 6.1 GIS Ett KEF -system bör ha möjlighet att presentera GIS-information och också upprätthålla den renhållningsspecifika informationen (t ex behållarnas placering). 16

I många fall är funktionerna väldigt bra och tjänar in investeringar snabbt. Viktigt framförallt för tillfällig tömningspersonal och för anläggningar med mindre frekventa tömningar (slamtömningar etc). I förberedande syfte kan ett KEF-system lagra X- och Y-koordinater för behållare utan att det har någon GIS-koppling. Detta kan i ett senare skede användas av ett GIS-verktyg. Notera att det i GIS-system ofta finns funktioner för ruttoptimering baserat på adresser. Notera att då GIS-informationen oftast finns i andra system kan samverkan mellan systemen göras på olika sätt och med olika hög grad av samverkan/integration. Detta område utvecklas för närvarande hos leverantörerna. Viss funktionalitet kan finnas tillgänglig i systemen idag. Möjligheterna ofta relaterade till vilket GIS-system kommunen kör i för tillfället. 6.2 FIR Det finns olika FIR-system på marknaden. De baseras dock på gemensam data (CFD fastighetsinformation). I FIR-systemen finns såväl id-nummer (FNR) till fastigheterna och id till samtliga adresser. Önskvärt är att anläggningar registreras för såväl fastigheten och adress. Ett KEF-system bör/skall ha möjligheter att presentera information från FIR-system. Speciellt ägarinformationen är av stor vikt. En tänkbar funktion är också automatisk varning (baserad på data från FIR-systemen) att ägarbyte skett som ej registrerats i KEF-systemet. Notera att då FIR-informationen finns i andra system kan samverkan mellan systemen göras på olika sätt och med olika hög grad av samverkan/integration. Detta område utvecklas för närvarande hos leverantörerna. Vissa leverantörer har redan idag god funktionalitet inom området. Möjligheterna beror också till vilket FIR-system som koppling skall ske till. 6.3 Företags- och kommuninvånarregister Ett KEF -system bör ha möjligheter att kunna kontrollera namn, adress mm mot ett kommuninvånarregister (KIR) och eventuellt även mot ett företagarregister. Detta för att öka datakvalitén och eventuellt förenkla inmatning av uppgifter. 7 Informationsuttag Rapporter och dataexport är en central fråga i ett informationssystem. Möjligheterna att i egen regi utveckla rapporter och exportera data till andra system och program är ett mycket starkt önskemål. För de större kommunerna är detta i princip ett krav. En öppen (och väldokumenterad) databas är grunden för full flexibilitet inom detta område. 17

Även leverantörernas vilja att bistå med kunskap och utbildning för att underlätta detta arbete är viktigt. 7.1 Standardrapporter Ett KEF-system skall innehålla ett antal standardrapportera. Nedanstående rapportområden kan ses som exempel på vad som skall finnas i ett KEFsystem. Statistik - Antal behållare och produkter per taxa med summering av årsintäkt Sammanställning av och utförda tjänster per kund/anläggning för angiven tidsperiod Antal behållare per körtur, geografiskt område, dag m.m. Periodisering av taxesatta tjänster. Simulering av förväntade intäkter med hänsyn tagen till debiteringsperioder Utförda övriga tjänster - Summering av utförda tjänster per kund/anläggning/entreprenör för angiven tidsperiod Reklamation/avvikelse - Statistik över klagomål och ej utförda tjänster Entreprenörsavräkning Antalet rapporter i systemen skiljer sig åt. 7.2 Export av data Export av data är centralt för att samverka mot andra system, externa program och rapportverktyg. Att ur KEF-systemet extrahera delar av information för bearbetning i andra sammanhang är viktigt, inte minst vid framtagning av rapporter. Export av data kan till exempel vara i formen av enklare filer (tab-separerade), komplexa filer (t ex i XML), enstaka databastabeller, eller flera kopplade databastabeller. Enkätundersökningen visade på ett visst intresse ge externa program möjligheter att läsa direkt i databasen. Genom att tillgång normalt ges till databasen, kan export av data ordnas. Leverantörerna är öppna med databasmodellen mot kunder. I vissa fall kan tillgång till den ges vid offerttillfälle eller är fritt tillgänglig. Leverantörerna stödjer arbetet med att kunden själv skall kunna exportera egna data på olika sätt. En av leverantörerna gör detta via en förenklad databaskopia. 7.3 Framtagning av egna rapporter De stora kommunerna kräver i princip möjligheter att själva utveckla egna rapporter. I enkätundersökningen angavs utan jämförelse Excel som det populäraste verktyg som rapportverktyg. Rapporter kan utföras direkt mot data i KEF-systemet eller mot exporterad data. (se 7.2 Export av data). 18