Implementering af IndFak

Transkript

1 Implementering af IndFak September 2011

2 Indhold 1 Introduktion Indledende afsnit Formål og målgruppe Opbygning af materialet 5 2 Etableringsfasen Formål og målgruppe Formøde (ministerområde) Udarbejde projektcharter Implementeringsplan (aktivitetsoversigt) Issuelog (emnelog) Opstartsmøde Sammensætte implementeringsteam Infoark (kontaktoplysninger) 10 3 Design- og analysefasen Formål og målgruppe Analysetilgangen Best practice processer og roller Ordreproces: Ordre behandling Ordreproces: Varemodtagelse Faktura behandles manuelt Fakturaen håndteres automatisk (match) Introduktion til profiler Rekvirent -profil Disponent- profil Indkøber-profil Indholdsansvarlig-profil Fakturaansvarlig-profil Opbygning af hierarki i IndFak Overordnet hierarki og administrativt fællesskab Hierarki for en virksomhed (institution) Opsætningsark og udfyldelse Overblik over opsætningsark Opsætningsark: Organisatorisk hierarki Opætningsark: Registrering af brugere Opsætningsark: Registrering af roller (systemroller) Opsætningsark: Dimensioner Opsætningsark: Adresser Opsætningsark: Opbygning af dimensionsgrupper Opsætningsark: Opbygning af Indkøbsgrupper Opsætningsark: Stamopsætning 32 2

3 4 Klargøring og test Aktiviteter i fasen Klargøring af testmiljø Indlæsning af opsætningsark i test Testdata til IndFak Stamdata indlæsning til test Test og træning Workshop og øvrig uddannelse Klargøring af IndFak produktion (transition) Transitionsfasen aktiviteter og aktører Opsætning af stamdata i Navision (bogholder for institutionen) Omlægning af dokument udveksling - fra UDDI registrering UDDI aktivering Opsætning af transportlag Udvidet stamdatafil Opsætning af IndFak produktion Opsætning af styringsparametre i Navision 48 5 Idriftsættelse Gennemførelse af tilslutningsprøve del Udvælgelse af kontaktpersoner (superbruger) Procedure for support og fejlhåndtering Driftsstøtte Tilslutning del Ibrugtagning hos slutbrugere Overdragelse 52 6 Forankring Overdragelse til driftsorganisation Dokumentation indsamling af implementeringen Evaluering Leverandøraktivering og fase

4 1 Introduktion 1.1 Indledende afsnit IndFak står for Indkøb og Fakturering og er betegnelsen for et nyt fælles it-system, hvis hovedformål er at understøtte de statslige institutioners og de statslige selveejende institutioners indkøbs- og fakturahåndteringsprocesser. IndFak understøtter Best Practice og ved at standardisere processerne ud fra Best Practice, kan der, alt andet lige, opnås betydelige procesmæssige besparelser til gavn for institutionen og vareleverandørerne. Nedenfor er oplistet nogle af de vigtigste grunde til at anvende IndFak: IndFak understøtter Best Practice og giver de institutionerne et brugervenligt indkøbs- og fakturabehandlingssystem, som er integreret med Navision. IndFak bygger på OIOUBL-standarden, der giver mulighed for bedre elektronisk kommunikation mellem kunde og vareleverandør på en række områder ved dokumentudveksling I IndFak kan alle modtagne fakturaer, der matcher en afsendt ordre, blive behandlet automatisk. IndFak er et fælles statsligt it-system, hvor fælles indkøbsaftaler med tilhørende varekataloger kan oprettes og vedligeholdes centralt Udviklingen og vedligeholdelsen af IndFak sker fra centralt hold, hvor Økonomistyrelsen er kontraktholder. IndFak understøtter centraliseringen af en række administrative funktioner i ØSC. 4

5 1.2 Formål og målgruppe Målgruppen for vejledningsmaterialet er institutionernes implementeringsteam. Formålet med nærværende vejledningsmateriale er at beskrive de opgaver, en institution bør gennemføre for at få en vellykket IndFak-implementering. Dokumentet er et opslagsværk og indeholder en række anbefalinger og uddybende forklaringer om følgende elementer, der har betydning for opsætning af IndFak: Ved at følge vejledningsmaterialet og tilhørende bilag vil implementeringsarbejdet medføre, at institutionen får opsat IndFak, så det kan underbygge en effektiv proces fra indkøb til at en faktura sendes til betaling i Navision Stat (NS). Udover håndtering af fakturaer kan systemet også understøtte best practice fra aftaleindgåelse og indkøb (eordre). Implementeringsteamet skal se vejledningsmaterialet og de relaterede bilag, som en samlet implemteringspakke for IndFak, hvor bilagene er værktøjer, som skal benyttes undervejs i implementeringsprocessen. Følgende bilag, som er udarbejdet i forhold til vejledningsmaterialet, er oplistet nedenfor: 1. Projektcharter (ministerområde) 2. Generisk implementeringsplan 3. Tjekliste til IndFak implementering incl. NS 4. Præsentationer 5. Uddannnelsesmateriale 6. Best Practice og gap fit 7. Opsætningsark 8. Transitionsplan 9. Procesdiagrammer Det er derfor vigtigt, at institutionen en vurdering af, hvordan de bedst muligt kan implementere og benytte IndFak. Implementering af IndFak er på sigt et forretningsprojekt og skal ikke betragtes som et isoleret system pdateringsprojekt. Det er vigtigt, at institutionernes implementeringsteam gør dette klart overfor ledelsen og resten af organisationen. 1.3 Opbygning af materialet Implementering af IndFak sker i 5 trin, som det fremgår af figuren nedenunder. 5

6 Fase 1 Etablering Sammensætte et implementeringsteam Afholde et opstartsmøde Sikre at implementeringsteamet har kendskab til de bilag, der skal arbejdes med i forbindelse med de øvrige fire faser se bilag 1-9. Udarbejde en tidsplan for implementeringens fire øvrige faser, som skal afstemmes i implementeringsteamet og tilpasses ind i Fejl! Henvisningskilde ikke fundet.. Sikre bestilling af nødvendige konsulentressourcer Fase 2 Design og analyse Institutionens arbejdsgange i IndFak og sammenholdes med Best Practice (Gap/Fit analyse) Fremtidens organisation, rolle, opsætning defineres, tilpasses og afklares for design Udfylde og sende opsætningsark til test Fase 3 Klargøring og test Sikre at opsætning af testmiljø og produktionsmiljø Integration til NS sikres Bestilling af kataloger Test og træning Fase 4 Idriftssættelse Gennemføre tilslutning og igangsætte slutbrugere Teste supportfunktionen er på plads Uddannelse af brugere Kommunik ud til brugerne inden IndFak tages i brug Fase 5 Forankring Overdragelse af IndFak til brugerinstitution Overdragelse af supportansvar til ØS Rådgivning og Support Dokumentation indsamling af implementeringen Leverandøraktivering og fase 2 6

7 2 Etableringsfasen 2.1 Formål og målgruppe Etableringsfasens formål er at forankre implementeringsprojektet i egne organisation og afklare i hvor høj grad opgaver kan centraliseres evt. på ministerområdeniveau. Aktiviteterne er følgende: Udarbejde projektcharter og implementeringplan på ministerområde Sammensætte et implementeringsteam og opgaver Afholde et opstartsmøde (dagsorden og præsentation) Opstartsfasens målgruppe er implementeringsansvarlig og inddragelse af institutionens ledelse til forankring af projektet i egen organisation, samt afklaring af opgaver som skal ligge centralt. Ministerområde (projektejer) Institution (projektejer) Institution (projektleder) Institutionen skal udvælge de personer, som skal udgøre implementeringsteamet. Antallet afhænger af personernes kompetencer, og antallet kan derfor sagtens være færre eller flere end fire. Hvis ikke institutionens interne ressourcer selv kan løfte alle opgaverne, kan en løsning være, at tage kontakt til det ministerområde som institutionen er tilknyttet og forhøre, om der her er placeret kompetencer, der kan hjælpe med at løfte opgaven. Ansvaret for implementering af IndFak er placeret hos institutionen selv, og det er op til den enkelte institution at stille med et stærkt implementeringsteam. Er der ikke de påkrævede ressourcer internt i institutionen, bør institutionen indhente eksterne ressourcer. Hvis eksterne ressourcer benyttes forventes det, at institutionen stadig er ansvarlig for implementeringsprojektet, og ikke overlader dette til 3. part. 7

8 2.2 Formøde (ministerområde) I etableringsfasen er det vigtigt, at få et godt indblik i den opgave, der er i forbindelse med implementeringen. Mødet forventes at afholdes på overordnet niveau og kan ligge på ministerområdet. Nedenstående oplistede spørgsmål bør besvares før opstartsmødet igangsættes. - Understøttelse af fakturahåndteringssystem i dag? - Anvendes eordre fra nuværende system? - Vil I benytte ordredelen i IndFak og hvornår? - Har I særlige områder eller aftaler der handles ind på? ( FM, SKI, Lokale) - Er der områder som vil blive centraliseret? (Indkøbspolitik, administration) - Vil ministerområdet tage del i implementering? - Hvilke opgaver skal implementeringsteamet løfte? (Forankring, best practice) - Hvor går implementeringsteamet hen hvis de skal bruge hjælp 2.3 Udarbejde projektcharter I etableringsfasen afklares implementeringsprojektet på overordnet niveau (ministerområde) og beslutninger angives i projektcharter, som fungerer som et aftaledokument igennem hele implementeringen. 2.4 Implementeringsplan (aktivitetsoversigt) Fejl! Henvisningskilde ikke fundet., som styringsværktøj og opslagsværk i bestræbelserne på at sikre, at implementering af IndFak kan gennemføres inden for den fastsatte tidsramme. 2.5 Issuelog (emnelog) De spørgsmål som dukker op under implementering angives i en emnelog for institutionen. Det for at sikre at der bliver fulgt op på eventuelle udeståender og hvem som har ansvaret for de noterede opgaver. 2.6 Opstartsmøde Opstartsfasen starter formelt ved at institutionerne indenfor samme ministerområde samles til et opstartsmøde, hvor projektforløbet og materialerne bliver introduceret. Det er vigtigt at implementeringsteamet i opstartsfasen indgår aftaler med eventuelle eksterne ressourcer som skal inddrages i implementeringsopgaven. På opstartsmødet vil der være mulighed for at demonstrere IndFak systemet og de processer som det understøtter. 2.7 Sammensætte implementeringsteam Alle institutioner skal inden første workshop sammensætte et implementeringsteam, som skal sikre, at IndFak bliver implementeret korrekt hos institutionen. Hovedformålet er, at de fire ressourceansvarlige i implementeringsteamet får et godt indblik i den opgave, der er i forbindelse med implementeringen. Nedenstående oplistede spørgsmål bør besvares før analyse og designfasen igangsættes: 8 Hvilke opgaver skal implementeringsteamet løfte

9 Hvad ligger der i opgaven Hvordan skal opgaverne løses Hvem skal løse opgaverne Hvornår skal opgaverne være løst Hvor går implementeringsteamet hen hvis de skal bruge hjælp Vejledningsmaterialet beskriver nedenfor de fire ressourceansvarlige profiler, som skal være repræsenteret i implementeringsteamet: Det er ikke et krav, at institutionens fire ressourceansvarlige fordeles på fire personer. Antallet af ressourceansvarlige kan reduceres, hvis flere af kompetencerne vælges samlet hos én person. Implementeringsansvarlig Der skal i implementeringsteamet være en implementeringsansvarlig, som har det overordnede ansvar for, at implementering af IndFak overholder de tidsrammer, der er angivet i den generiske implementeringsplan. Ud over det tidsmæssige ansvar er det også den implementeringsansvarliges opgave at sikre, at der er allokeret de fornødne ressourcer til at udføre de opgaver, som er beskrevet i vejledningsmaterialet og den generiske implementeringsplan. Indkøbsansvarlig Den indkøbsansvarlige har til opgave at sikre, at arbejdsprocesserne, i forbindelse med håndtering af ordre, bliver gennemgået, beskrevet og optimeret, og at institutionen så vidt muligt følger Best Practice. Den indkøbsansvarlige skal ligeledes sikre, at der opbygges en organisation, som er tilpasset de behov og krav, som institutionen har til håndtering af indkøb. Det er derfor den indkøbsansvarlige, som bistår den implementeringsansvarlige og evt. ledelsen i udvælgelsen af de personer, som skal arbejde med ordrehåndtering i IndFak. Fakturaansvarlig Den fakturaansvarlige har til opgave at sikre, at arbejdsprocesserne, i forbindelse med håndtering af faktura, bliver gennemgået, beskrevet og optimeret, og at institutionen så vidt muligt følger Best Practice. Den fakturasansvarlige skal ligeledes sikre, at der opbygges en organisation, som er tilpasset de behov og krav, som institutionen har til håndtering af fakturaer. Det vil derfor også være den fakturaansvarlige, som bistår den implementeringsansvarlige og evt. ledelsen i udvælgelsen af de personer, som skal arbejde i IndFak. Teknisk koordinator (ansvarlig) Den tekniske koordinator har ansvar for at koordinerer ressourcer og opgaver med aktører jf. transitionsplan (klargøring, test og idriftsættelse) - It drift Skal sikre at de tekniske krav er opfyldt, for at kunne køre IndFak, tilføje domæner til firewall mv. jf. Tekniske krav og anbefalinger. - LRA ansvarlig (Lokal Registrerings Autoritet) Administrator-rolle, der med et medarbejdercertifikat skal UDDI registrere i forbindelse med idriftsættelse. UDDI er et fælles register der sikrer korrekt modtager ved udveksling af dokumenter til og fra IndFak 9

10 - Navision Hosting (KMD, CSC, TMI eller lokal) Skal opsætte transportlag mv. samt igangsætte eksport af stamdata og transaktionsdata mv. 2.8 Infoark (kontaktoplysninger) Kontaktoplysninger på i institutionen og hvilke regnskaber som skal oprettes. Har betydning for transitionsfasen beskrevet i afsnittet klargøring og test og idriftsættelse. 10

11 3 Design- og analysefasen 3.1 Formål og målgruppe I Design og analysefasen, trin 2, afholdes en workshop (workshop 1), der har til formål at definere institutionens fremtidige struktur og arbejdsprocesser. Denne vejledning indeholder en række anbefalinger, der skal gøre det nemt for de lokale implementeringsansvarlige at definere den kommende struktur og den måde IndFak skal konfigureres på. Institutionens beslutninger bliver indtastet i et opsætningsark, der bliver grundlaget for opsætning af IndFak. Den valgte opsætning bliver af institutionen testet i Klargøring og test-fasen, og når institutionen har godkendt opsætningen, bliver den frigivet og IndFak kan tages i brug. Sammenhæng mellem systemroller, procesroller og profiler Beskrivelse af 2 modeller til opbygning af hierarkier i IndFak og fordele og ulemper ved de 2 modeller Opbygning af dimensionsgrupper Beskrivelse af, hvordan opsætningsark skal udfyldes Målgruppen er de medarbejdere, der beskæftiger sig med implementering af IndFak, som f.eks. den lokale implementerings-, indkøbs- og fakturaansvarlige. 3.2 Analysetilgangen 11

12 3.3 Best practice processer og roller Det er Implementeringsteamets opgave at gennemgå best practice og sikre at de har en klar forståelse af hvad der ligger i hver proces. Målet med afsnittet er at implementeringsteamet for hver arbejdsproces tager et aktivt valg om hvordan processen skal håndteres. Nedenstående - angivet med mørkeblåt - er de arbejdsopgaver som IndFak understøtter procesmæssigt 1. Aftaleindgåelse 2. Leverandør -oprettelse 3. Rekvisition 4. Ordreafsendelse 5. Lager 6. Varemodtagelse 7. Fakturamodtagelse 8. Kreditnota 9. Udlæg 10. Bogføring 11. Betaling 12. Kreditnota Økonomistyrelsens Best Practice findes på Følgende procesroller indgår i forløbet - Rekvirent - Indkøber - Varemodtager - Disponent - Fakturafordeler Ordreproces: Ordre behandling I IndFak kan en ordreproces afvikles ved, at der er 1, 2 eller 3 typer af brugere involveret. Antallet afhænger af de roller og øvrige rettigheder, brugerne har fået tildelt. Set fra et procesmæssigt perspektiv er der i IndFak fire forskellige proces scenarier, som er mulige for at gennemføre en ordrebehandling, inden ordren sendes afsted til leverandøren. 12

13 3.3.2 Ordreproces: Varemodtagelse Når det bestilte produkt eller ydelse er leveret af leverandøren på rette sted, kvalitet, stand og pris, skal der foretages en varemodtagelse i IndFak. Hvis der ikke laves en varemodtagelse i forbindelse med ordreprocessen, vil IndFak ikke forsøge at lave automatch mellem en faktura og en ordre. Der er i IndFak indbygget en regel om, at en række faktorer skal være opfyldt, før et fakturamatch er muligt. Der er to typer af brugere, som kan lave en varemodtagelse i IndFak, den ene type bruger er brugere med rollen rekvirent og den anden type brugere er dem, som har fået tildelt rollen varemodtager. Følgende faktorer skal være opfyldt før en ordre og en faktura kan matches: Der skal være afgivet en elektronisk ordre Der skal laves en varemodtagelse Der skal modtages en faktura, som stemmer overens med de data, som er angivet i den elektroniske ordre og den elektroniske varemodtagelse Faktura behandles manuelt I IndFak kan en manuel fakturaproces afvikles ved, at der er 1, 2 eller 3 brugere involveret i fakturaprocessen, antallet af brugere afhænger af, hvilke roller og øvrige rettigheder brugerne har fået tildelt. Set ud fra et procesmæssigt perspektiv, er der i IndFak fire forskellige proces scenarier, som er mulige for at gennemføre en manuel fakturabehandling, inden fakturaen kan sendes afsted til Navision Stat Fakturaen håndteres automatisk (match) Dette scanarie er som nævnt det som efterstræbes, da en institution vil opnå mange procesbesparelser ved, at IndFak automatisk udfører de opgaver, som brugerne ellers skulle have varetaget. IndFak kan herved automatisere selve håndteringen af fakturaen, hvis institutionens brugere i forbindelse med ordreprocessen har håndteret deres opgaver korrekt og leverandøren ligeledes. 13

14 3.4 Introduktion til profiler IndFak har mange opsætningsmuligheder. Økonomistyrelsen har på baggrund af best practice defineret en række procesroller, der definerer hvordan indkøbs- og fakturahåndteringsprocessen bør organiseres. Procesrollerne afleder dermed de systemroller, der skal benyttes ved oprettelse af nye medarbejdere, hvilket betyder, at en procesrolle kan bestå af flere systemroller. En medarbejder kan have flere procesroller, og for at gøre det nemt at organisere opgaverne er der defineret en række profiler, der er sammensat af procesrollerne, der med fordel kan varetages af den samme person. Følgende profiler er defineret: Rekvirent Disponent Indkøber Indholdsansvarlig Fakturaansvarlig Rekvirent -profil Profil: Rekvirent Arbejdsopgaver: Rekvirentprofilen har behov for køb af en vare/ydelse. I princippet er alle medarbejdere i en virksomhed rekvirenter og kan komme med ønsker om køb af varer og ydelser, men kan ikke bestille noget medmindre en medarbejder med prokura godkender indkøbet. Rekvirenten har desuden læseadgang til alle enhedens ordrer og fakturaer, kan søge blandt dem og kan trække statistik. Procesrolle Rekvirent Controller Systemrolle Rekvirent Statistik Controller Disponent- profil Profil: Disponent Arbejdsopgaver: En disponent godkender en faktura til betaling, er ansvarlig for at der er dækning til at gennemføre indkøbet og at kontering er korrekt. Disponenten har desuden læseadgang til alle enhedens ordrer og fakturaer, kan søge blandt dem og kan trække statistik. Procesrolle Disponent Controller Systemrolle Godkender Statistik Controller 14

15 3.4.3 Indkøber-profil Profil: Indkøber Arbejdsopgaver: Indkøber har mulighed for at omdanne en rekvisition til en ordre, kontrollere at kontering er korrekt, og sende ordren til leverandøren såfremt indkøberens prokura tillader det. Indkøberen er desuden ansvarlig for varemodtagelse og for at sikre, at de leverede varer/ydelser er i overensstemmelse med aftalerne. Indkøberen har desuden læseadgang til alle enhedens ordrer og fakturaer, kan søge blandt dem, kan trække statistik og kan lave favoritlister. Procesrolle Systemrolle Varemodtager Varemodtager Indkøber med tekstordre Indkøber med prokura Indkøber med forhandlede priser Indkøber Controller Favoritlistemanager Statistik Controller Indholdsansvarlig-profil Profil: Indholdsansvarlig Arbejdsopgaver: Indholdsansvarlig er en indkøber med udvidede beføjelser, der skal fungere som superbruger overfor kollegaer, hjælper organisationen til at blive dygtigere på indkøbsområdet, sikre at de aftaler og kontrakter der er repræsenteret i IndFak er opdaterede. Desuden skal det overvejes, om den indholdsansvarlige også skal have procesrollen systemadministrator. Systemadministratorrollen er defineret under fakturaansvarlig-profilen. Procesrolle Varemodtager Systemrolle Varemodtager Indkøber Indkøber med tekstordre Indkøber med prokura Indkøber med forhandlede priser Favoritlistemanager Controller Statistik Controller Indholdsansvarlig Kontraktadministrator Prislistemanager Kontraktadministrator 15

16 3.4.5 Fakturaansvarlig-profil Profil: Fakturaansvarlig Arbejdsopgaver: Fakturaansvarlig har til opgave at søge for at fakturaerne bliver godkendt til tiden, oprette nye kreditorer, behandle fakturaer der afvises ved match. Fakturaansvarlig er ligeledes en superbruger, der hjælper kollegaer, hjælper organisationen til at blive dygtigere på fakturahåndteringsområdet. Fakturaansvarlig har desuden læseadgang til alle enhedens ordrer og fakturaer, kan søge blandt dem og kan trække statistik. Procesrolle Fakturafordeler Systemrolle Fakturamanager Systemadministrator Systemadministrator Gruppeadministrator Controller Statistik Controller 16

17 3.5 Opbygning af hierarki i IndFak Overordnet hierarki og administrativt fællesskab I forbindelse med opbygning af hierarki på et overordnet niveau, kan der være behov for at opbygge organisationerne med en overordnet virksomhed i form af koncern eller lignende. Overordnet hierarki på koncernniveau Administrativt fællesskab (anbefales) Hierarki med overordnet virksomhed på koncernniveau I IndFak er det muligt at have en overordnet virksomhed som login og herefter vælge de underliggende virksomheder (institutioner). Det kunne eksempelvis være et ministerområde med et fælles login og herefter kunne vælge mellem de institutioner som er opsat indenfor det ministerområde. Dette har dog nogle mangler hvis en institution senere skal flyttes fx ved ressortændringer. 17

18 Hierarki oprettet på koncernniveau Fordele Hvis den samme bruger er oprettet med en rolle i de forskellige institutioner fx disponent, så de ikke skal logge ind flere gange Hvis dokumenter skal sendes til en anden institution, kan dette ske via fakturafordeler i toppen (dog skal bilag som leverandøren har sendt forkert afvises jf. opgavesnit) Ulemper Hvis en eksisterende institution skal flyttes til eller fra koncernen, så vil data eller historik ikke følge med over Virksomhed i administrativt fællesskab Hvis institutionerne i IndFak er oprettet som separate virksomheder kan disse tilføjes et administrativt fællesskab fx på koncernniveau. Den Administrative Fællesskabers skal ses som en sky hvor alle enheder der er oprettet i IndFak kan tilføjes. Herved er det muligt at centralisere arbejdsopgaver og have et login på tværs af de organisationer der er tilføjet i det enkelte fællesskab. Generelt set kan man sige at anvendelse af Administrativt fællesskab bør overvejes i situationer, hvor brugere skal have adgang til flere institutioner eller i situationer hvor leverandørvarekataloger er fælles mellem institutionerne og skal godkendes centralt. Nedenfor ses relevante cases hvor Administrative fællesskaber kan lette arbejdsgangen: Bogholderi, hvor et administrativt fællesskab er bogholderfunktion for flere institutioner. Centralt indkøb, hvor et administrativt fællesskab er indkøbsafdeling på tværs af flere institutioner Central kataloggodkendelse, hvor et administrativt fællesskab godkender leverandørvarekataloger på vegne af flere institutioner 18

19 Rådgivning og support, hvor et administrativt fællesskab er supportfunktion på tværs af flere institutioner Statistik, hvor der er behov for statistik på tværs af institutioner Institution tilknyttet adm. fællesskab Fordele Fleksibilitet ved at tilføje og flytte institutioner i fællesskabet historik bevares Varekataloger og indkøb kan administreres via indkøbsgrupper på koncernniveau muligt at v videresende kataloger til underliggende institutioner Support, statistik og systemadministration tværs af enheder som ligger i det administrative fællesskaber. Ulemper Dokumenter kan ikke flyttes eller sendes til en anden institution. Leverandøren skal sende til den rette institution fra start Hierarki for en virksomhed (institution) Dette afsnit vil beskrive følgende 2 modeller for opbygning af det organisatoriske hierarki for en virksomhed i IndFak: Den klassiske organisation Det procesorienterede hierarki (anbefales) Ved design af den fremtidige struktur er der mulighed for at kombinere de 2 modeller. Den hierarkiske opbygning er bestemmende for, hvordan dokumenter efterfølgende udveksles mellem brugere i IndFak. Opbygning af det organisatoriske hierarki i IndFak sker gennem organisatoriske enheder. En organisatorisk enhed skal forstås som en enhed, der oprettes i IndFak, hvor en række af institutionens brugere med tildelte roller skal placeres. De organisatoriske enheder er de kasser, som til sammen udgør det samlede hierarki/struktur. Det er til enhver tid muligt at oprette underliggende organisatoriske enheder, hvis der er behov herfor. En hovedregel i forbindelse med opsætning af et organisatorisk hierarki er, at der ikke må være mere end fire niveauer. Bemærk at IndFak kun kan håndtere en hierarkisk struktur, svarende til en organisation som er opbygget som et stamtræ. Når det organisatoriske hierarki skal opsættes, er en anden vigtig hovedregel, at dokumenter kun kan sendes op og ned i hierarkiet, men ikke på tværs Den klassiske organisation Den klassiske organisation er en kopi af firmaets struktur, således at der bliver oprettet en IndFak enhed svarende til hver enhed i firmaet. Lad os tage udgangspunkt i et firma bestående af 3 enheder (A til C) og en række underafdelinger illustreret i figuren nedenunder. Firmaet har 3 niveauer (niveau 1 til 3). 19

20 Det betyder, at en bruger, der er placeret i organisation A kan herved videresende dokumenter som f.eks. faktura til følgende organisationer og brugere: Brugere i organisation A (altså brugere i egen organisation) Brugere i organisationerne A1, A2 og A3 Brugere i organisationen Firma Men en bruger der sidder i organisation A1 kan ikke sende en faktura til varemodtagelse eller godkendelse i A2. Der er en enkelt undtagelse for afsendelse af dokumentudveksling på tværs af det organisatoriske hierarki, da der i IndFak er lavet en særregel for afsendelse af dokumenttypen: rekvisitioner. Rekvisitioner er den eneste dokumenttype, som kan sendes på tværs og som dermed kan sendes til hvilken som helst organisation indenfor samme firma/regnskab. Ydermere skal der være oprettet en bruger med rollen indkøber, som er en forudsætning for, at dokumentet kan sendes til en specifik modtager. Det klassiske organisationshierarki Fordele Genkendelighed. Fordele ved denne model er at brugerne nemt kan relatere sig til opbygningen og deres egen afdeling. Overblik over fakturaplacering. På søgebilledet kan fakturafordeler altid se hvilken afdeling en faktura er placeret i. Den traditionelle opsætning betyder, at fakturafordeler, vil kunne afgrænse søgning til en specifik afdeling. Reduceret risiko for brugerfejl. Brugeren vil kun kunne vælge andre brugere i deres egen afdeling og afdelingen over, hvis de er på 2. niveau i eksemplet. Det reducerer risikoen for, at der ved en fejl sendes til en forkert bruger. Det giver mere afgrænsede menulister med brugere i det daglige arbejde. Styring af godkendelse. Tilgængelige disponenter kan begrænses pr. afdeling. Dermed sikres, at en bruger i f.eks. Personaleafdeling kun kan vælge én disponent. Afgrænsning af dokumentsøgning. Disponent og indkøber vil kun under søgning kunne se de fakturaer, der ligger i deres egen organisatoriske tilknytning. Indkøberen kan dog stadig kun se detaljeret visning af de fakturaer, de selv har varemodtaget eller godkendt, uanset organisering. Ulemper Begrænsning i distributionsmuligheder. En faktura kan ikke sendes direkte til en anden bruger på tværs af afdelinger. En faktura skal sendes retur til fakturafordeler, med en kommentar om evt. anden indkøber, som kun fakturafordeler, kan videresende til. Øget brugeradministration. Store institutioner og institutioner med stor udskiftning eller hyppige organisationsændringer vil have større administration. 20

21 Mindre egnet til understøttelse af fakturaflow på tværs af organisationsdiagrammet, eksempelvis ved projektarbejde. Kan for nogle institutioner medføre tunge og ikke hensigtsmæssige processer, som hverken understøtter Best Practice eller den procesgang som egentlig ønskes i institutionen Det procesorienterede hierarki Opsætning af et hierarki kan godt udelukkende bestå af én organisatorisk enhed. I en opsætning, hvor der kun er oprettet én organisatorisk enhed i IndFak, vil det betyde, at alle brugere er oprettet i den ene enhed og kan sende dokumenter til hinanden. Ved det procesorienterede hierarki opbygges det organisatoriske hierarki efter brugerroller, hvilket betyder, at de organisatoriske enheder oprettes med det formål at placere en række personer, som skal have de samme IndFak brugerroller. En institution kan herved godt vælge kun at lave et design, hvor der kun er én organisatorisk enhed pr brugerrolle for alle de personer, som skal bruge IndFak. I så fald skulle man placere alle indkøbere i én organisatorisk enhed, alle disponenter i én organisatorisk enhed og så fremdeles. Opbygningen af organisationsstrukturen har betydning for hvilke data, den enkelte bruger kan se, og hvordan forretningsdokumenter som kan sendes rundt i systemet. Det procesorienterede hierarki er illustreret i nedenstående figur Når man vælger at opbygge det organisatoriske hierarki efter den procesorienterede model, opbygges godkendelseshierarkiet ikke efter hvor i det formelle organisationsdiagram de enkelte medarbejdere fysisk er placeret i, men snarere i forhold til hvilken rolle den enkelte bruger skal have i den pågældende ordre- eller fakturaflows. I hierarkiet er alle indkøbere og disponenter samlet i hver sin enhed. Denne opsætning vil betyde, at man har designet en løsning, hvor alle indkøbere kan sende dokumenter til hinanden og samtidig til alle disponenter. Hvad angår disponenterne så kan de også sende til hinanden og kan også sende ordren retur til indkøber. Det procesorienterede hierarki Fordele Fuld fleksibilitet ved fakturadistribuering og fejlplacering. Denne fleksibilitet er især en meget vigtig faktor, hvis institutionen har mange fakturaer, der behandles på tværs af de organisatoriske enheder. Ikke alle fakturaer er påført referenceperson. Her kan der, ligesom beskrevet ovenfor, opstå behov for at sende en faktura til en anden afdeling. Det samme gælder ved afsendelse af ordre. Her vil indkøberen også kunne sende direkte til en anden indkøber, uafhængig af hvilke afdeling han fysisk er placeret i. Sikring af arbejdsgangene gennemføres som det ønskes i institutionens ledelse. Opbygningen sikrer, at en arbejdsproces kun kan håndteres på ganske få måder. Ved f.eks. at oprette en afdeling dedikeret til en bestemt fakturagodkendelsesproces sikres kvalitet og konsistens i arbejdsgangen. Samtidig kan denne organisering gøre det lettere at fokusere på evt. stikprøvekontrol 21

22 af fakturaer. Denne type organisering afspejler godkendelsesprocessen i højere grad end den traditionelle. Minimal brugeradministration. Brugeradministrationen lettes, da brugere har roller i færre enheder og alle som standard placeres samme sted. Ulemper Mindre detaljeret overblik over indkøb, der kan ikke i IndFak laves et statistikudtræk, der viser hvad en enkelt organisation i institutionen har købt. Mindre detaljeret overblik over fakturaer, der kan ikke i IndFak laves et statistikudtræk, der viser hvilke fakturaer en enkelt organisation i institutionen har behandlet og sendt til betaling. Alle godkendte fakturaer indeholder dog komplet historik over hvilke personer, der har foretaget hvilke handlinger i systemet. Historikken mistes aldrig. I denne model vil brugerne have mulighed for at sende til mange kollegaer. Det giver konkret en længere dropdownliste over mulige indkøber og disponenter at vælge imellem. Det kan være forvirrende, hvis brugeren ikke ved hvem disponenten er og øger risikoen for at forkert bruger vælges. Det er dog nemt for en bruger at returnerer et dokument, hvis brugeren ikke mener at skulle behandle det tilsendte dokument. 22

23 3.6 Opsætningsark og udfyldelse Opsætningsarket har til formål at indsamle alle de nødvendige data, der skal til for, at IndFak kan tages i brug. Opsætningsarket skal ses som en skabelon, hvor implementeringsteamets beslutning om valg af struktur og opsætning nedfældes. Det er bl.a. data, der skal fortælle hvor mange brugere der skal oprettes, hvilke rolle brugerne skal tildeles, hvor brugerne skal placeres og hvor mange regnskaber institutionen skal have oprettet etc.. Når implementeringsteamet har udfyldt alle obligatoriske felter i opsætningsarket, skal arket indsendes til systemkonsulenten, som har til opgave at få indlæst dette i IndFak Overblik over opsætningsark For at gøre det let for implementeringsteamet er der for hvert tekstfelt i opsætningsarket lavet hjælpebeskrivelser, der skal gøre implementeringsteamet i stand til at udfylde samtlige obligatoriske felter. Der skildres i opsætningsarket mellem to typer af felter: Obligatoriske felter: dette er felter, som skal udfyldes før opsætningsarket sendes til indlæsning. Disse felter er markeret med en blå farvekode. Valgfrie felter: Dette er felter, som ikke er obligatoriske at udfylde. De valgfrie felter er markeret med en grøn farvekode. Figur 12: Opsætningsark Brugere Inden implementeringsteamet starter med at udfylde opsætningsarket følger her en kort introduktion af hvordan excelarket er opbygget og en forklaring på de to farvekoder (blå og grøn) som benyttes for henholdsvis fanebladene og kolonnerne i opsætningsarket. Farvekoder: Der arbejdes med to typer af farvekoder i opsætningsarket: grøn og blå. Farven blå symboliserer at data er obligatorisk at udfylde for at opsætningsarket kan indlæses i IndFak. Den grønne farve symboliserer at data er valgfri at udfylde. 23

24 Faneblade: Som det fremgår af figur 12 er farvekoderne anvendt på fanebladene så implementeringsteamet nemt og hurtigt kan danne sig et overblik over, hvilke faneblade der er påkrævet at udfylde data i og hvilke som er valgfrie at udfylde. Hvert faneblad skal betragtes som værende opsætningsområder, der isoleret ikke kan stå alene. Hvert faneblad er angivet med et sigende navn for det opsætningsområde fanebladet repræsentere. De første to faneblade i opsætningsarket er f.eks. navngivet organisationer og brugere. Når fanebladet er udfyldt, har institutionen f.eks. taget stilling til hvordan dette skal opsættes. Når de obligatoriske kolonnefelter i dette faneblad er udfyldt, er dette opsætningsområde dermed på plads. Kolonner og kolonnefelter: Som det fremgår af figur 12 har hver kolonne, ligesom fanebladene, en farvekode så implementeringsteamet nemt og hurtigt kan danne sig et overblik over hvilke kolonner, der er påkrævet at udfylde data i og hvilke som er valgfrie at udfylde. Udover at hver kolonne har fået en farvekode er der også for hver kolonne lavet en hjælpetekst. En række kolonner er navngivet med samme navn i flere faneblade. Årsagen til at en kolonne er angivet med samme navn i flere forskellige faneblade skyldes, at der mellem en række af fanebladene er et afhængighedsforhold, fx brugere og roller som er beskrevet i senere afsnit. Id Fanenavn Indhold 1 Organisationer Viser hvilke organisationer i systemet der er oprettet for instirutionen 2 Brugere Kobler bruger sammen med disponeringsgrænse og standardorganisation 3 Roller Kobler bruger sammen med standardorganisation og rolle i IndFak 4 Fuldmagter Oversigt over brugere med fuldmagter og fuldmagtsgrænsen 5 Dimensioner Overblik over dimensioner oprettet i systemet. Værdier overføres via stamdataoverførsel fra Navision Stat 6 Adresser Viser organisationerne i IndFaks fysiske adresse 7 Dimensionsgrupper Opbygning af Med en dimensionsgruppe forstås en gruppe af brugere, der har adgang til udvalgte konti og dimensioner. Dimensionsgruppe kan benyttes til at begrænse brugernes adgang til udvalgte konti/dimensioner, og dermed reducerer risikoen for fejkontering. 8 Indkøbsgrupper Grupper for hvem som kan indkøbe på bestemte varegrupper 9 Stamopsætning Standardopsætning i IndFak Opsætningsark: Organisatorisk hierarki Implementeringsteamet skal tage stilling til hvordan institutionens organisation skal opsættes i IndFak. Første trin er at definere, hvor mange organisatoriske enheder institutionen skal opdeles i og tage stilling til, hvordan disse skal struktureres. Opbygning af det organisatoriske hierarki kan ske efter modellerne i afsnit 5. Opsætningsark: Registrering af faneblad Organisationer I forbindelse med organisationsopsætningen skal implementeringsteamet gøre følgende: Definere det organisatoriske hierarki og de enkelte organisatoriske enheder 24

25 Knytte EAN-numre til organisationsstrukturen Knytte regnskaber til organisationsstrukturen Knytte CVR numre og P-numre til organisationsopsætningen Definere nummerserier Ud fra ovenstående beskrivelse skulle implementeringsteamet nu være i stand til at udfylde kolonnefelterne i fanebladet organisationer Kolonne: Organisationsnavn og hovedorganisation Den hierarkiske struktur, som er illustreret i ovenfor er resultatet af data, som er skrevet ind i opsætningsarket. I Fejl! Henvisningskilde ikke fundet., skal implementeringsteamet under fanebladet organisationer registrere organisationsnavn og hovedorganisation. Dette er den egentlige opbygning af det organisatoriske hierarki. Logikken i opsætningsarket er, at der i tekstfeltet hovedorganisation indtastes den organisatoriske enhed, som skal fungere som forældre for en underliggende organisatorisk enhed. I de tidligere skitseringer af et organisatorisk hierarki har det været firma som har været hovedorganisation, hvorfor det i så fald er firma som skal indtastes i det første kolonnefelt i opsætningsarket. Figur 17: Sammenhæng mellem opsætningsark (Organisationer) og det klassiske organisationshierarki illustreret i figur 16.1 Som det fremgår af figuren er hovedorganisationen i det organisatoriske hierarki, som er ved at blive opbygget, navngivet Firma. Samtidig kan det ses, at hovedorganisationen har tre underliggende organisatoriske enheder nemlig organisation A, organisation B og organisation C. For at oprette en underliggende organisatorisk enhed, 25

26 skal der altså i feltet hovedorganisationen skrives, hvilken organisatorisk enhed som skal fungere som forældre, og i feltet organisationsnavn skal der angives, hvilken organisatorisk enhed som skal fungere som underliggende enhed. Kolonne: EAN Nummer I forbindelse med indtastning af EAN nummeret, som skal være 13 karakterer, er det vigtigt, at implementeringsteamet sikrer, at det er et validt EAN nummer, hvor cheksummen er korrekt. Hvis EAN nummeret ikke er indtastet korrekt, vil Opsætningsarket ikke kunne indlæses til IndFak. Kolonne: CVR nummer I forbindelse med indtastning af CVR nummeret, som skal være 8 karakterer, er det vigtigt, at det er et validt CVR nummer med korrekt checksum. Samme regler er gældende for indtastningen af et P nummer. P nummeret angives i samme felt som CVR nummeret i opsætningsarket Opætningsark: Registrering af brugere De følgende underafsnit beskriver ganske kort de forskellige procesroller og profiler, som brugerne skal have tildelt for at kunne gennemføre arbejdsprocesserne ordrebehandling, varemodtagelse og fakturabehandling. Faneblad: Brugere og roller Efter at implementeringsteamet som minimum har udfyldt de obligatoriske felter, kan det som tidligere nævnt være en fordel at udfylde de felter som går igen i de øvrige faneblade da dette oftest sikrer, at felterne udfyldes ens. I forbindelse med at fanebladet organisationer er udfyldt, kan de obligatoriske felter som mangler at blive udfyldt i fanebladene brugere og roller nu også blive udfyldt. Nedenfor er skitseret hvilke kolonnefelter der kan udfyldes og i hvilke faneblade disse kolonnefelter står oplistet. Kolonnefelt Organisationsnavn Standardorganisation Faneblad Roller Brugere Dette afsnit og de øvrige afsnit der beskriver de forskellige faneblade, skal ses som et supplement til opsætningsarkets Fejl! Henvisningskilde ikke fundet.hjælpetekster. Formålet med disse afsnit er at give implementeringsteamet en overordnet forståelse af hvordan fanebladene skal udfyldes. Dette afsnit vil helt konkret forholde sig til, hvordan fanebladet Brugere skal udfyldes. Med udgangspunkt i foregående afsnit skal implementeringsteamet nu træffe beslutninger som f.eks.: hvilke personer der skal have adgang til IndFak og hvilke roller disse ressourcer skal have. Herudover skal der tages stilling til hvilke brugernavn og password brugerne skal have etc.. 26

27 Figur 14: Opsætningsark - Brugere Efter at implementeringsteamet, som minimum, har udfyldt de obligatoriske felter (lige med undtagelse af standard organisation), kan det være en fordel at udfylde de felter, som går igen i de øvrige faneblade da dette oftest sikre, at felterne udfyldes ens. Nedenfor er skitseret hvilke felter, der kan udfyldes i en række faneblade. Kolonnefelt Brugernavn Mappe Roller 27

28 3.6.4 Opsætningsark: Registrering af roller (systemroller) I fanebladet Roller skal alle obligatoriske kolonnefelter udfyldes med undtagelse af Organisationsnavn, da dette felt ligesom standard organisation, først skal udfyldes i forbindelse med valg af den organisatoriske opsætning, som ligger i næste opsætningsfase. I figur 15 ses et eksempel på hvordan kolonnefelterne i fanebladet Roller skal udfyldes. Systemrollerne afledes af profilerne, der er beskrevet i foregående afsnit. Figur 15: Opsætningsark - Roller Kolonnefeltet organisationer skal, som tidligere nævnt, ikke udfyldes før senere i implementeringsfasen. Der findes 22 forskellige systemroller i IndFak, som en bruger kan tildeles. Når en bruger tildeles en systemrolle betyder det, at brugeren tildeles en række rettigheder og ansvarsområder i IndFak. De væsentligste systemroller uddybes nedenunder. 28

29 Rekvirent Godkender Prislistemanager Indkøber med linkout Indkøber med forhandlede priser Favoritlistemanager Fakturamanager Superuser Systemadministrator Gruppeadministrator Kontraktadministrator Kontraktvisning Controller og statistik 29 En rekvirent har et konkret behov for en vare eller ydelse. Rekvirenten har som udgangspunkt kun et begrænset kendskab til indkøb. Systemrollen rekvirent lave en rekvisition i katalogmodulet eller lave tekstrekvisitioner, der sendes til indkøbere. Rekvirenten kan gives rettigheder til at kunne lave link-out til en ekstern webshop, hvor varer kan returneres til IndFak. Rekvirenten kan kontere en rekvisition. En rekvirent kan kontere fakturaer uden en tilhørende indkøbsordre. En bruger med systemrollen rekvirent kan også varemodtage en faktura uden tilhørende indkøbsordre. En godkender kan have opgaver i forbindelse med både ordre- og fakturahåndtering. Brugere med rollen godkender er ansvarlige for godkendelse af en faktura til betaling og om en ordre kan godkendes (indenfor godkenderens prokura-grænse) eller afvises. En prislistemanager er man ansvarlig for, at katalogerne i IndFak har korrekt indhold, så der er overensstemmelse med indkøbsaftalerne. Prislistemanager er den eneste, der kan godkende eller afvise det elektroniske varekatalog. Brugerne med denne rolle er ansvarlige for, hvilke varer og ydelser der skal frigives overfor de øvrige brugere. Indkøber med link-out, kan tilgå leverandørens eksterne webshop, hvor varer kan hentes til IndFak. En indkøber med forhandlede priser kan købe ind direkte fra katalogmodulet og kan behandle rekvisitioner fra en rekvirent. Favoritlistemanager vedligeholder favoritlister på samme måde som en bruger, men har endvidere mulighed for at publicere favoritlisten som en gruppefavoritliste, således at den bliver tilgængelig for alle Hvis IndFak ikke automatisk kan fremsende et dokument til en modtager, kan fakturamanagerens finde og sende til den rette modtager.. Fakturamanager kan se status for alle dokumenter og videresende fakturaer til varemodtagelse eller godkendelse hos de relevante rekvirenter og disponenter. Forud kan finanskonto og dimensioner påføres af fakturamanageren. Fakturamanageren har adgang til alle dokumenter indenfor organisationen og kan således flytte et dokument fra en bruger til en anden. Systemadministrator kan bl.a. Oprette, fjerne og vedligeholde organisatoriske enheder Tildele brugere rettigheder og roller Superuser kan bl.a. Oprette nye brugere og tildele adgangskoder Tildele brugere systemrollen systemadministrator Oprette nye enheder under en brugerorganisation Angive opsætningsindstillinger, der gælder for hele brugerorganisationen. Gruppeadministrator kan bl.a. udføre følgende opgaver: Oprette og vedligeholde grupper som skal tilknyttes indenfor en organisation Tekstordre (brugerstyring af hvem der må afsende ordre pr. mail og hvilke leverandører, som skal kunne modtage ordre via mail) Kontraktadministrator kan oprette og vedligeholde kontrakter i kontraktmodulet og sikre, at disse er synlige for brugere med rollen kontraktvisning. Kontraktadministrator kan ligeledes lave opsætning i forbindelse med stående ordrer i kontraktmodulet. Kontraktvisning giver brugeren adgang og læserettigheder til kontraktmodulet Det er systemrollen controller, der giver adgang til de ordrer og fakturaer, som man typisk ser fra Navision-siden. Systemrollen controller er således en læseadgang til IndFak. Controller skal yderligere tildeles rollen Statistik for at kunne trække rapporter.

30 3.6.5 Opsætningsark: Dimensioner I fanebladet dimensioner udfyldes de dimensioner som IndFak brugerne skal have adgang til og registrering af en enkelt dimensionsværdi og beskrivelse af denne værdi. Udfyldelse af dimensionsmodelnavn gøres ved at angive et navn i feltet dimensionsmodel. Kolonnefeltet dimensionsmodelnavn oprettes med det formål, at lave en gruppering af dimensioner og dimensionsværdier, som en udvalgt gruppe af organisatoriske enheder og herved brugere skal have adgang til. De organisatoriske enheder som kobles til dimensionsmodellen vil have adgang til, at kunne påføre de dimensioner og dimensionsværdier, som er angivet i dimensionsmodellen. Det anbefales, at implementeringsteamet navngiver regnskabsnavn ved at angive det navn som Navision Stats kontoplan er oprettet med og med angivelse af årstal. Denne fremgangsmåde anbefales da dimensionsmodelnavn i IndFak har tilsvarende funktion som kontoplan har i Navision og derved giver en klar forståelse af sammenkoblingen. Figur 20 Der skal ikke udfyldes nogen relationer i form af kolonnefelts henvisning til de øvrige faneblade, medmindre at implementeringsteamet endnu ikke har udfyldt kolonnefeltet dimensionsmodelnavn Opsætningsark: Adresser I fanebladet adresser skal der udfyldes følgende tre typer af adresser: Faktureringsadresse Leveringsadresse Juridiskadresse Der skal heller ikke i fanebladet adresser udfyldes nogen relationer i form af kolonnefeltshenvisning til de øvrige faneblade. I forbindelse med fanebladet: adresser skyldes det, at adresserne oprettes så det er muligt at tildele eller fravælge adresserne for hver enkelt organisatorisk enhed, hvilket betyder, at en bruger med rollen systemadministrator i IndFak kan styrer hvilke adresser brugerne i de enkelte organisatoriske enheder har adgang til. Kolonnefelt Nummerserienavn 30 Faneblad Organisationer