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

31 3.6.7 Opsætningsark: Opbygning af dimensionsgrupper 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 fejl. En dimensionsgruppe kan kun oprettes indenfor en enhed og ikke på tværs af enheder. Dimensionsgrupper kan benyttes som supplement til både det klassiske og det procesorienterede hierarki. Det skal blot understreges, at omfanget af administration til oprettelse og vedligeholdelse af grupper stiger i takt med at flere grupper oprettes. Som udgangspunkt kan brugerne i IndFak se og vælge alle værdier, når ordrer og fakturaer skal konteres. Ved at lave en dimensionsgruppe kan institutionen styre brugernes adgang til dimensionsværdier. Således vil konteringen kunne håndteres hurtigere og risikoen for fejlkontering reduceres. Det vil sige, at brugere tilknyttet en bestemt dimensionsgruppe udelukkende har adgang til de tilknyttede værdier, når de skal kontere ordrer eller fakturaer Opsætningsark: Opbygning af Indkøbsgrupper Modsat de andre grupper er indkøbsgruppen rettet mod de organisatoriske enheder og ikke brugerne i IndFak. En indkøbsgruppe oprettes, når en gruppe af organisatoriske enheder ønsker at modtage kataloger fra de samme leverandører. Fordelen ved indkøbsgrupper er bl.a., at der kun er en indholdsansvarlig i IndFak, som skal kvalitetstjekke katalogerne. Leverandøren skal ligeledes kun sende ét varekatalog af sted for at ramme en lang række kunder. Dette anvendes bl.a. i forbindelse med kataloger på SKI- og FM-aftaler. Kataloggrupper Brugere af IndFak med indkøberrollen kan som udgangspunkt tilgå alle kataloger, som er uploadet til institutionen. Ved at lave en Kataloggruppe kan institutionen styre hvilke kataloger den enkelte bruger skal have lov at tilgå. Brugere, som er placeret i en kataloggruppe, har kun adgang til de kataloger, som er tilknyttet kataloggruppen. En institution kan herved styre kataloggruppen efter hvilke leverandører, brugerne kan indkøbe fra. Hvis der f.eks. er ét eller flere indkøbsteam i institutionen, som er ansvarlige for at indkøbe kontormøbler, IT udstyr, konsulentydelser m.m., kan dette styres i form af kataloggrupper. Hvis en bruger ikke er tilknyttet en kataloggruppe og brugeren har rettigheder til at tilgå IndFak markedspladsen, kan denne bruger tilgå alle de varekataloger, som er tilgængelig for institutionen. Link-Out grupper Brugere, der i IndFak kan tilgå leverandørernes web-shop via Link-Out fra IndFak, kan som udgangspunkt tilgå alle leverandørernes web-shops, der et tilgængelige for institutionen. Ved at lave en Link-Out gruppe kan institutionen styre hvilke web-shops den enkelte bruger skal have lov at tilgå. Det ses f.eks. ofte, at det kun er et begrænset antal brugere, som skal have adgang til web-shops hos IT leverandørerne. Brugere, som er placeret i en eller flere Link-Out grupper, har kun adgang til de web-shops, som Link-Out grupperne repræsenterer. En institution kan herved styre, hvilke leverandørers web-shops brugerne kan købe ind fra. Tekstordregrupper Brugere, der i IndFak må afsende tekstordrer, kan som udgangspunkt sende til alle leverandører, som er sat op til at kunne modtage disse. Ved at lave en tekstordregruppe kan institutionen styre, hvilke leverandører den enkelte bruger må sende tekstordrer til. Brugere, som er placeret i en tekstordregruppe, har kun adgang til de leverandører, som gruppen repræsenterer. Hvis en bruger ikke er tilknyttet en tekstordregruppe og har rettigheder til at afsende tekstordrer, kan denne bruger afsende tekstordrer til alle tekstordreleverandører.. 31

32 3.6.9 Opsætningsark: Stamopsætning Stamopsætning er der angivet de standardopsætninger (angivet med x) som opsættes i IndFak. Her kan implementeringsteamet ændre på standardopsætningen, hvis der er områder der skal være anderledes i brugerinstitutionen. Det er vigtigt, at der tages stilling til hvert opsætningsfelt, da et valg og et fravalg har betydning for hvordan en proces i IndFak kan håndteres. Den første manuelle opsætning, som den ansvarlige skal foretage, er at opsætte firmaindstillinger. Det specielle ved firmaindstillinger i forhold til alle øvrige indstillinger i IndFak er, at disse indstillinger er gældende for hele firmaet og alle brugere. For alle andre indstillinger kan man differentiere indstillingerne ved at lave opsætninger for de enkelte organisatoriske enheder. 32

33 4 Klargøring og test Følgende afsnit har til formål at guide implementeringsteamet gennem denne fase af implementeringen, og sikre at implementeringsteamet løbende får viden om, hvor dokumentation kan findes, hvilke opgaver der skal håndteres og hvem der skal håndtere en given opgave. Det helt konkrete formål med denne fase er, at få opsat en løsning som illusteret i nedenstående figur, som viser en opsætning hvor IndFak og Navision Stat begge er opsat hver for sig, men hvor de to systemer er integrerede og derfor kan modtage og afsende dokumenter til hinanden. Da vejledningsmaterialets fokus er IndFak systemet vil dette afsnit hovedsagligt beskrive de opgaver der ligger i forbindelse med opsætning og konfiguration af IndFak. Opgaverne med at få opsat Navision Stat og infrastrukturen mellem de to systemer, er kun ganske kort beskrevet i vejledningsmaterialet, da vejledning omkring denne opsætning skal findes i anden dokumentation. Målgruppen for dette afsnit er følgende ressourcetyper: Implementeringsansvarlig Indkøbs- og fakturaansvarlig Teknisk ansvarlig En stor del af arbejdet for implementeringsteamet i denne fase af implementeringen er projektstyring, da der i denne fase af projektet er en række aktører som skal varetage forskellige opgaver. Samtidig skal det påpeges, at der i ugen op til at institutionen går i drift er en vigtig koordineringsopgave for implementeringsteamet, da de forskellige aktører i denne periode er afhængige af hinanden og gennemførelsen af en række forskellige opgaver 4.1 Aktiviteter i fasen Implementeringsteamet skal i denne fase af projektet ikke selv udføre mange opgaver, men har derimod en stor opgave i at sikre, at de mange opgaver, som skal håndteres, bliver varetaget af de forskellige aktører. 33

34 4.2 Klargøring af testmiljø Formålet med IndFak opsætningstest er at institutionen tester egen opsætning, processer og funktionaliter i testmiljø. I testen er der ingen integration til Navision Stat eller vareleverandører, derfor skal testdata indlæses og følgende forudsætninger skal være på plads: Specifikke stamdata der ikke er til rådighed via overførsel fra NS til test, skal hentes som udtræk fra NS eller angives i opsætningsark Indlæsning af testdata og kontoplan fra NS Indlæsning af opsætningsark i test Efter at institutionen har klargjort deres opsætningsark, skal institutionens implementeringsteam sende en endelig version til IndFak konsulenten som vil indlæse opsætningsarket i IndFak testmiljø. Når systemkonsulenten har indlæst opsætningsarket, vil han derefter logge på IndFak for at lave et standard kvalitetstjek af den indlæste data. Hvis indlæste data giver anledning til spørgsmål eller på anden måde ikke lykkes, vil Økonomistyrelsens(ØS) implementeringsteam kontakte institutionen. Testmiljøet er tilgængeligt for institutionen så længe ØS har en driftsaftale med systemleverandøren om at brugerinstitutionerne kan tilgå dette miljø Testdata til IndFak Når institutionens opsætningsaktiviteter for områder som f.eks. indlæsning af opsætningsark, regnskabs- og dimensionsindstillinger er på plads skal der indlæses testdata til IndFak, så testbrugerne herved har mulighed for at teste at dokumenter som f.eks. ordre, fakturaer og kreditnotaer kan sendes rundt i den opsætning der er lavet for institutionen. Der er udarbejdet en standard testpakke som institutionerne kan bestille at få læst, pakkens data indhold, testcases og formål er beskrevet nedenstående. Testpakke Formål Formålet med at indlæse kataloger, fakturaer, kreditnota mm. er,at sikre institutionen kan teste at de væsentligste processer og funktionaliteter.. For at sikre at de væsentligste processer og funktionaliteter nu også bliver testet er der udarbejdet en række testcases. Testcases Hvis en institution ønsker at teste på områder som ikke er dækket af testpakken, så har institutionen mulighed for at bestille testdata og testcases på øvrige områder, denne bestilling skal i så fald gives til den implementeringsansvarlige for den pågældene institution, Der er udarbejdet testcases på den generelle anvendelse af IndFak indenfor de forskellige arbejdsområder, fx markedspladsordre, tekstordre og fakturabehandling. Disse testcases udleveres på workshop 2. Det skal være muligt for institutionen at teste følgende Roller og afhængighed 34

35 Katalogordre Tekstordre Stående ordre Faktura Dimensionsgrupper Varekataloger/Ordrer Testpakken indeholder 3 varekataloger udvalgt fra FM-aftalerne og som er særligt egnede til test. Der vil samlet være over 1500 varelinjer tilgængelig fra leverandørerne: Lyreco, Kinnarps og Papyrus. Ud over de tre nævnte leverandører af kataloger, vil der som minimum blive oprettet tre yderligere test-leverandører, som kan anvendes i forbindelse med udarbejdelsen af tekst- og stående ordrer. Ønskes der andre varekataloger end de her nævnte eller flere testleverandører, skal du henvende dig til din systemkonsulent, som kan oplyse dig om mulighederne. Faktura Der udarbejdes standard fakturasæt, som kopieres til alle institutioner, hvor der bl.a. vil være behov for ændring af ean-nr, navn osv. til hver institution. Pakken består af både OIO UBL og OIO XML faktura samt OIO UBL kreditnota. Der vil være 90 faktura i alt fordelt på 30 OIO UBL, 30 OIO XML (elektronisk) og 30 OIO XML (Scannet). Derudover vil der være 30 OIO UBL kreditnota. Fakturaerne vil variere på beløb og leverandør fordelt på minimum tre forskellige. Ønskes der flere eller specifikke faktura anvendt i testen, skal du henvende dig til din systemkonsulent, som kan oplyse dig om mulighederne Stamdata indlæsning til test I det etablerede testmiljø vil der ikke være integration mellem IndFak og Navision Stat (NS). Da stamdata i form af kontoplan (finanskonti og dimensioner) fødes i Navision, vil disse stamdata ikke overføres automatisk til test. I forbindelse opsætning af testmiljø til IndFak er det nødvendigt at der laves et udtræk fra institutionens Navision, så denne kan blive sat op i IndFak. Dette for at testen af IndFak kan være så realistisk som muligt og afspejle virkeligheden. I forbindelse med test af IndFak er det nødvendigt at institutionen har udfyldt dimensionsmodellen i opsætningsark. Her vil det fremgå hvilke dimensionstyper er der bruges og hvilke eventuelt ikke bruges selvom de ligger i NS. Et eksempel på dette er dimensionen Budget som ikke kan slås fra i stamdataudtrækket, men den bruges ofte ikke af institutionerne. Nb. Kreditorer er en del af stamdata i NS. I test vil der være indlæst et standard testdatasæt (fiktive fakturaer mv) med tilhørende kreditorer/leverandører. I produktion vil det være institutionens egne kreditorer som automatisk overføres. 35

36 Udtræk af stamdata fra Navision kan foregå på to måder. Uanset metode fremsendes oplysninger til IndFak konsulenten som sørger for indlæsning. Der oplyses stamdata fra hvert NS regnskab. 1. Stamdata i Excel-fil a. Excel-fil indeholdende alle finanskonti, dimensioner og dimensionsværdier. b. Besked til Navision konsulent om udtræk fra den pågældende institution c. Bemærk specielle tegn i NS ex. skal filtreres fra inden kopiering d. Navision finanskontoplan kopieres ind i faneblad 1i Excel e. Anvendte dimensionskoder kopieres ind i faneblad 2 i Excel f. Navision dimensionsværdier tabel 349 kopieres ind i faneblad 3 i Excel g. Til-fra summer og spærrede konti fjernes enten i Navision eller Excel h. Udtræk fremsendes til IndFak konsulent som indlæser i test Eksempel Test og træning Når IndFak er opsat på et testmiljø skal institutionen nu gennemføre en række testcases, institutionen har her en række muligheder for at sikre, at deres opsætning bliver testet ordentlig igennem. Formålet med opsætningstesten er at sikre at institutionen har en opsætning som understøtter best-practice processerne, så brugerne i institutionen kan modtage og sende dokumenterne rundt som det i analysearbejet er blevet besluttet. Når institutionen har testet de testcases igennem som denne har valgt i samarbejde med implementeringsteamet, kan implementeringsteamet påstarte at koncentere sig om at få påstartet arbejdet med at få institutionen opsat på IndFak produktionsmiljøet. Institutionen kan finde testmateriale/workshoppræsentationer på 36

37 Bruger: eprocurement Password: rapport Workshop og øvrig uddannelse Før implementeringsteamet påstarter opsætningstest af IndFak opsætningen, skal disse personer have træning for at kunne gennemføre testen tilstrækkeligt. Når der påbegyndes afprøvning af IndFak i testmiljøet bør teamet være uddannet til at kunne løfte følgende opgaver: 1. Håndtere elektroniske fakturaer og kreditnota 2. Lave elektroniske ordrer 3. Forståelse for opsætningsprincipper Det anbefales at implementerings/afprøvningsteamet har mindst et gruppemedlem som har opbygget kompetencer indenfor følgende roller: Indkøber Fakturafordeler Disponent Varemodtager Rekvirent Kompetenceopbygning af implementeringsteamet vil finde sted på workshop 2 eller ved tilmelding til øvrig uddannelse. 37

38 4.3 Klargøring af IndFak produktion (transition) Efter gennemført opsætningstest fremsendes opsætningsark til indlæsning i produktion, hvis der i forbindelse med testarbejdet har været ønsker til ændringer af setup skal dette indarbejdes i opsætningsarket inden indlæsning af dette dokument påstartes. Opgaven for implementeringsteamet i denne fase er derfor, at sikre at følgende hovedopgaver vil være varetaget: Opsætning og konfiguration af IndFak Opsætning og konfiguration af Navision Stat Opsætning og konfiguration af infrastruktur Kompetenceløft for at sikre korrekt anvendelse af IndFak Transitionsfasen aktiviteter og aktører Når en institution er klar til at tage IndFak i brug skal implementeringsteamet sikre sig, at der åbnes op for at indgående- og udgående data kan transporteres frem og tilbage mellem IndFak og f.eks. NS og vareleverandørerne. Denne opgave kræver en del koordinering da denne opgave kræver at en lang række interessenter varetager en række tekniske opsætninger og at disse opsætninger håndteres koordineret. I de nedenstående afsnit er de forskellige interessenter oplistet og en kort beskrivelse for hver opgave der skal håndteres. Institutionen o o o Implementeringsteam LRA-ansvarlig (Adgang til UDDI) Bogholder 1. Økonomistyrelsen KMD edi o o o Projektleder Implementeringskonsulent Transitionskoordinator o Hosting NS Omlægning af dokumenter Evenex o o o o o KMD-Hosting som står for hosting af Navision Stat for nogle institutioner. TMI som står for hosting af Navision Stat for nogle institutioner. CSC som står for hosting af Navision Stat for nogle institutioner. Egen IT drift INDFAK systemleverandør 38

39 For at hjælpe implementeringsteamet med at kunne gennemføre transitionsopgaven er der udarbejdet en transitionsplan. Formålet med dette bilag at give alle de involverede parter et styringsværktøj, der skridt for skridt hjælper med at sikre, at de forskellige opsætninger bliver gennemført i rette tid af rette aktør. Økonomistyrelsen har i hvert implementeringsteam en transitionskoordinator tilknyttet. Transitionskoordinatoren vil sørge for opgaverne bliver løst i forhold til UDDI registreringen mv. Transition (overgang til drift) 16 dage Opsætning af NS kreditorer, kontoplan -(stamdatarapport) 10 dage Bogholder Uddi registrering. Inst LRA og ØS 10 dage LRA ansvarlig Transitionskoordinator Bestilling og modtag udvidet stamdatafiler 5 dage Transitionskoordinator Opsætning af prod. (Indlæsningsark, stamdatafiler, konfigurer regnskabsinstillinger) 2 dage Implementeringskonsulent UDDI aktiveringsdato (Åbn for indgående til IndFak 1 kr. bilag fremsendes) 0 dage Implementeringskonsulent Oprydning af bilag i gl. wfs 4 dage Slutbrugere Transportlag til NS opsættes (Evt. UDDI på skygge-ean slettes) 2 dage Transitionskoordinator Styringsparameter opsætning i NS - klargøring 1 dage Bogholder Implementeringskonsulent Opsætning af stamdata i Navision (bogholder for institutionen) For at stamdata kan fremsendes fra Navision til IndFak skal stamdata i form af kreditorer og kontoplan være oprettet korrekt. Det betyder at stamdatarapport i Navision skal være fejlfri for at overførslen kan finde sted. Vejledning opsætning af Navision Stat 5.x 39

40 4.3.3 Omlægning af dokument udveksling Afsendelse af OIOXML via INDFAK til Navision Stat modtager - VANS/OIOSI Ste p Beskrivelse Bemærkning Relevant vejledning Link til vejledning Leverandør sender faktura via egen VANS operatør til en modtager baseret på modtagerens officielle EAN nummer Modtager VANS, dvs KMD kontrollerer om modtager skal modtage på et VANS endpoint eller et OIOSI endpoint (KMD gateway funktionalitet) Hvis OIOSI endpoint, slår KMD op på UDDI med modtageres officielle EAN nummer og dokumenttype for at finde modtager url og understøttede officielle profiler Afsendende VANS kontrollerer i EDIR hvilken VANS der 'ejer' modtager EAN nummeret og sender til VANS operatøren Alle Navision Stat institutioner på NS 5.x er registreret hos KMD VANS Alle Navision Stat institutioner er registreret som OIOSI endpoint, som følge af UDDI registrering 4 Hvis modtager anvender INDFAK vil url'en tilhørende det officielle EAN nummer pege på Evenex for alle officielle profiler, og KMD vil sende fakturaen til Evenex (INDFAK) Jvnf. modtagers valgte UDDI registrering UDDI registreringsvejledning vision-stat/officiellefrigivelser/navision-stat-52 5 Efter kontering og godkendelse på INDFAK, slår INDFAK op med modtagers officielle EAN nummer og dokumenttypen på UDDI for en returnering af url og alle understøttede profiler 6 INDFAK udvælger url registreret for den uoffcielle NS - profil som peger på Navisions url, og sender derfor fakturaen videre til den IIS, hvor Navision Stat er installeret Hvis andre end INDFAK skulle finde på at sende på den uofficielle url, er der i Navision indsat en spærring, der betyder at Navision kun accepterer IND- FAK som afsender på den uofficielle url UDDI registreringsvejledning vision-stat/officiellefrigivelser/navision-stat-52 7 Navision Stat modtager fakturaen på IIS'en, hvorfra den via OES transportlag overføres til Navision Stat databasen OES transportlagsvejledning 5.2 NS SystemInfo for opdatering af OES transportlag til NS vision-stat/officiellefrigivelser/navision-stat-52 vision-stat/officiellefrigivelser/navision-stat

41 Afsendelse af OIOUBL via INDFAK til Navision Stat modtager - OIOSI Step Beskrivelse Bemærkning Relevant vejledning Link til vejledning Leverandøren slår op på UDDI med modtagerens officielle EAN nummer og dokumenttype for at finde modtager url og alle understøttede officielle profiler Hvis modtager anvender INDFAK vil url'en tilhørende det officielle EAN nummer pege på Evenex for alle officielle profiler, og afsender vil sende fakturaen til Evenex (INDFAK) Efter kontering og godkendelse på INDFAK, slår INDFAK op med modtagers officielle EAN nummer og dokumenttypen på UDDI for en returnering af url og alle understøttede profiler INDFAK udvælger url registreret for den uoffcielle NS - profil som peger på Navisions url, og sender derfor fakturaen videre til den IIS, hvor Navision Stat er installeret Navision Stat modtager fakturaen på IIS'en, hvorfra den via OES transportlag overføres til Navision Stat databasen Alle Navision Stat institutioner er registreret som OIOSI endpoint, som følge af UDDI registrering Jvnf. modtagers valgte UDDI registrering Hvis andre end INDFAK skulle finde på at sende på den uofficielle url, er der i Navision indsat en spærring, der betyder at Navision kun accepterer INDFAK som afsender på den uofficielle url UDDI registreringsvejledning UDDI registreringsvejledning OES transportlagsvejledning 5.2 NS SystemInfo for opdatering af OES transportlag til NS emer/navision- Stat/Officielle- frigivelser/navision- Stat-52 emer/navision- Stat/Officielle- frigivelser/navision- Stat-52 emer/navision- Stat/Officielle- frigivelser/navision- Stat-52 emer/navision- Stat/Officielle- frigivelser/navision- Stat-5201 Beskrivelsen her er enslydende hvad enten leverandøreren vælger at afsende fra eget ERP system, hvor Nemhandel er understøttet, vælger at bruge nemhandel klienten eller vælger at sende fra Virk.dk 41

42 4.3.4 UDDI registrering Varetages af transistionskoordinator i samarbejde med institutionens LRA ansvarlige Det er derfor nødvendigt at ændre i UDDI. Her er det, at du som LRA-ansvarlig er vigtig, da en evt. bestilling af funktionscertifikat, forud for en UDDI ny-registrering, skal ske fra den PC, hvor den LRA-ansvaliges certifikat er installeret. Selve UDDI registreringen kan foretages af en medarbejder med et almindeligt medarbejdercertifikat. Før der kan UDDI registreres, vil jeg bede dig tjekke følgende: A) Kan du logge på Webregistreringstool, med dit medarbejdercertifikat? Tjek ved at klikke på dette link: B) Kan du logge på Teamviewer og komme til pkt. 5 i nedenstående vejledning? Tjek ved at klikke på dette link: (Dette for at teste, om vi kan gennemføre UDDI via fjernovertagelse af din PC. OBS: koden ændrer sig for hver gang, man forsøger at logge sig på). 42

43 4.3.5 UDDI aktivering Ved UDDI aktivering sendes de indgående dokumenter til IndFak. Har man et andet fakturahåndteringssystem sendes der ikke længere bilag til dette. Mange institutioner ønsker dog at færdigbehandle bilag i tidligere system og sende til Navision Stat inden de går i drift på IndFak. Færdigbehandling af bilag i eksisterende workflowsystem har ofte en varighed på 4 dage. Herefter kan transportlaget ændres så bilag ikke længere sendes fra gammelt wfs, men fra IndFak. 43

44 Følgende mail udsendes omkring UDDI aktivering og idriftsættelse Emne: UDDI aktiveringsdato + IndFak idriftsættelsesdato Dette er en saml til Evenex, mysupply og NS implementeringsteam. Til Evenex: Nedenstående til brug for backend. Til NS-team: Nedenstående UDDI er gennemført dd. Til mysupply: Til venlig orientering. Til RejsUD: Til videre foranstaltning Cc: IndFak konsulent, Projektleder Vedr. UDDI omregistrering med nyt indkøbssystem er gennemført dd.: Regnskab Departementet Bogføringskreds EAN CVR Aktiveringsdato for UDDI , kl IndFak idriftsættelsesdato , kl Til orientering: Da institutionen har ønsket en oprydningsperiode i gl. system, er der foretaget en UDDI ny-registrering uden indkøbssystem på: Tidligere skyggeean Aktiveringsdato for UDDI , kl UDDI slettes igen Efter (når transportlag sættes op eller efter at brugerrettig-hederne i Eprocurement er ændret til Controller) 44

45 4.3.6 Opsætning af transportlag Krav til IndFak er at institutionen er på Navision Stat 5.0 eller senere version. Opsætning af transportlaget er både i forhold til dokumenter sendt fra IndFak til Navision og fremsendelse af stamdata fra Navision til IndFak. Manual for opsætning af transportlag til Navision 5.2 skal følges 45

46 Følgende mail sendes vedr. opsætning af transportlag Emne: Bestilling af Transportlag Til: Helpdesk Cc: Projektleder, IndFak konsulent Transportlag: A. Hosting leverandør bedes opsætte transportlag for udvidet stamdataeksport og eksport af transaktionsdata, så transportlaget endeligt træder i kraft den , kl Eksport at stamdata bedes straks-initieret når transportlaget er opsat, så IndFak bliver opdateret med nyeste NS data. (Ved opsætning af transaktionsdata, bedes Postingdate sættes til 2 mdr. før transportlaget træder i kraft, for at undgå Vendor fejl). Info vedr. B. Hosting leverandør kan påbegynde opsætning af transportlaget den kl (På dette tidspunkt, er det aftalt med institutionen, at der er ryddet op i deres nuværende fakturahåndteringssystem er dette ikke tilfældet, vil bilagene blive behandlet manuelt). Regnskab Departementet Bogføringskreds EAN CVR Aktiveringsdato for UDDI , kl IndFak idriftsættelsesdato , kl Endpoint URL Funktionscertifikat: Funktionscertifikat er genbrugt fra tidligere UDDI. Til orientering: Da institutionen har ønsket en oprydningsperiode i gl. system, er der foretaget en UDDI ny-registrering uden indkøbssystem på: Tidligere skyggeean Aktiveringsdato for UDDI , kl UDDI slettes igen Efter (når transportlag sættes op eller efter at brugerrettig-hederne i Eprocurement er ændret til Controller) 46

47 4.3.7 Udvidet stamdatafil a. Stamdatafejlrapporten i NS-testmiljø køres for, at tjekke om der er fejl b. Stamdatarettelserapporten køres og retter gængse fejl c. De resterende fejl rettes manuelt d. Udvidet stamdatafil bestilles hos NS hosting/drift e. Hosting sender udvidet stamdatafil til konsulent pr. mail f. IndFak konsulent indlæser fil i IndFak Detaljeret beskrivelse findes i vejledning ovenfor for opsætning af transportlag Nedenfor følger en beskrivelse af hvordan man kan lave et stamdataudtræk fra Navision 5.1 Stamdataudtrækket kan logges som en fil. Det kræver at der i Navision er opsat i NSTS integrationstabellen LogDocumentAsFile skal være JA. Så kan de resulterende dokumenter typisk findes her på serveren (afhængig af den aktuelle stistruktur) Ex. C:\Inetpub\wwwroot\Transportlag\5.1\TSIOController_5.1\log Jobbet ligger typisk her: C:\Program iles\transportlag\5.1\tsstamdataudvideteksport_5.1\ bin\tsstamdataudvideteksport.exe Stamdata til IndFak produktion, her skal metode 2 pkt a-c følges inden eksport kan finde sted Når transportlaget og eksport af Masterdata Advanced er sat op så Navision vil sende stamdata til IndFak via UDDIopslag på IndFaks EndPointID. 47

48 IndFaks EndpointID er indskrevet i konfigurationsfil i transportlaget (ikke i NS). Så længe transportlaget eller UDDI-registreringen ikke er blevet gennemført eller sat op, vil stamdataeksporten fejle, men filen kan stadig findes i mappe for stamdatafil Opsætning af IndFak produktion På baggrund af test fremsender institutionen opsætningsark til IndFak produktion til implementeringskonsulenten. Herefter indlæser konsulenten opsætningsarket, modtaget stamdatafil og sikrer at IndFak er opsat til UDDI aktiveringsdatoen (indgående bilag til IndFak) Opsætning af styringsparametre i Navision Samme dag som transportlag opsættes, skal der ændres nogle styringsparametre i Navision for at bilag lander korrekt i indbakken i NS Er beskrevet i Vejledning til opsætning af Navision Stat 5.x 48

49 5 Idriftsættelse Idriftsættelsesfasen, fjerde trin har til formål at sætte institutionen i drift på IndFak og implementeringsteamet sætter øvrige brugere i gang på systemet. Målgruppen for dette afsnit er følgende ressourcetyper: Implementeringsteam Bogholder Evt. udvalgt afprøvningsteam (Gruppe af personer som skal afprøve opsætning i produktion) Formålet med denne fase er at have en periode hvor IndFak bliver afprøvet af en mindre gruppebrugere i produktion før resten af organisationens slutbrugere sættes på. Før implementeringsteamet går i drift på IndFak skal teamet være uddannet til at kunne løfte følgende opgaver: Håndtere elektroniske fakturaer, kreditnota og evt ordrer i IndFak Kunne anvende væsentlige funktionaliteter i IndFak Have udvidet kendskab til opsætningsmuligheder i IndFak Være i stand til at formidle og igangsætte resten af organisationen Det er derfor vigtigt at implementerinsteamet tilmeldes et kursus og har modtaget undervisning før fase 4 ibrugtagning påstartes, det er dog samtidig vigtigt at brugerne ikke modtager undervisningen tidligere end 10 arbejdsdage før de skal arbejde med IndFak. I denne fase tages IndFak systemet i brug på produktionsmiljøet. Der ligger i denne fase en tilslutningsprøve, for at sikre systemet virker i en reel driftssituation for hele organisationen. Tilslutningen er delt op i to Tilslutning del 1 Tilslutning del 2 49

50 5.1 Gennemførelse af tilslutningsprøve del 1 Tilslutningsprøven foregår i produktion og betyder at der nu arbejdes med rigtige fakturaer, som skal sendes til betaling i Navision og rigtige ordrer som sendes direkte til vareleverandørerne. Formålet med at have en mindre gruppe af personer til at afprøve IndFak i et produktionsmiljø er, at sikre at systemet fungerer og at brugerne dermed får en god oplevelse af IndFak fra første færd. Processen Når IndFak åbner, skal institutionens fakturaansvarlige sikre 3-4 rigtige og forskellige typer fakturaer behandles helt færdig, og at fakturaen bliver modtaget korrekt i NS. Kontakt jeres bogholderfor at sikre at fakturaen er kommet til Navision og er beriget med korrekte oplysninger. Herefter at fakturaen kan bogføres og sendes til betaling. ØS implementeringsteam orienteres løbende om processen og yder driftstøtte Evt. afgivelse af ordre processen afprøves på et udsnit af ordrer hos den indkøbsansvarlige inden resten af institutionens rekvirenter/indkøbere sættes på systemet Når I er sikre på, at fakturadelen fungerer, som det skal, giver I brugerne besked om adresse til IndFak og øvrige logon-oplysninger I første del af tilslutningen af IndFak på produktionsmiljøet er muligt at få identificeret hvorvidt der er fejl og/eller uhensigtsmæssigheder i institutionens opsætning inden resten af organisationen sættes på Udvælgelse af kontaktpersoner (superbruger) Som en del af IndFak implementeringen skal den enkelte institution også udpege en kontaktperson eller superbruger. Brugeren er ikke en rolle i systemet, men en procesrolle med nogle opgaver, som bør være en del af den udvalgte persons arbejdsbeskrivelse. Formålet er at have en bruger, som har en bred forståelse for IndFak, hvad angår ordrer og fakturaer samt de tilhørende processer. Det anbefales, at der udpeges flere kontaktpersoner, så der til hver en tid har en eller flere at henvende sig til, når der er behov for afklaringer omkring IndFak. En kontaktperson skal kunne yde support til andre brugere i egen organisation, og det er således også denne bruger som indmelder supporthenvendelser til Økonomistyrelsens Rådgivning og Support. Personen bør derfor også besidde formidlingsmæssige kvalifikationer, som gør, at vedkommende evt. kan oplære andre brugere. Følgende karakteristika kan være gældende for en kontaktperson: Anvender IndFak hyppigt (i hhv. faktura og/eller ordremodulet) Hjælper kollegaer med spørgsmål til anvendelsen af IndFak Sørger for at nye kollegaer får den rette uddannelse i IndFak 50

51 Indsamler information omkring en problemstilling i IndFak og indmelder til Økonomistyrelsens Rådgivning og Support Procedure for support og fejlhåndtering I forbindelse med at IndFak tages idriftsættes er det vigtigt, at institutionen afprøver hvorvidt supportfunktionen virker, der bør minimum testes på følgende to trin i den samlede supportproces. 1. Afprøve intern support: Sikre at supportsager sendes via superbrugerne i institutionen jf. servicehåndbog 2. Afprøve ØS Rådgivning og support: Sikre at R&S modtager en supportsag og sikre at institutionen modtager et svar som afhjælper den fejl som institutionen mener at have fundet. Processen for vil alt andet lige gå hurtigere hvis indmeldingen til Rådgivning og Support er udført korrekt a) Send en mail til [email protected] med IndFak i overskrift b) Beskriv hændelsesforløbet så præcist som muligt. c) Noter nummeret på det dokument du arbejder med (Ordrenummer, fakturanummer eller lign.) d) Medsend et skærmbillede af, hvordan fejlen ser ud i IndFak eller Navision. e) Tilføj i sagen hvis der er fundet en midlertidig løsning Driftsstøtte Der er i forløbet indarbejdet en driftsstøtteperiode på 14 dage, her kan aftales en driftsstøttedag hvor konsulenterne kommer ud til institutionen. 5.2 Tilslutning del 2 Tilslutning del 2 udføres med i en aftalt periode inden overdragelse til reel drift. I denne periode vil det stadig være en del af implementeringen og først efter endelig Punkter som indgår i den anden del er: Slutbrugere tager IndFak i brug Supportsetup er afprøvet Svartider er tilstrækkelige Funktionaliteter virker efter hensigten Tilpasning af institutionens opsætning dage med et stabilt system etc. Opfølgning og rapportering af driftsperiode Ibrugtagning hos slutbrugere Når implementeringsteamet har gennemført første del af tilslutningen sættes de resterende brugere på. Det kan gøres ved af samle de kommende brugere til et igangsætningsworkshop eller udsende materiale. Der er udarbej- 51

52 det en generisk folder og præsentation som implementeringsteamet kan tilpasse til egen organisation. Følgende punkter kan indgå i præsentationen. Adgang og login i IndFak Information om valg af opsætning Udmelding om kontaktpersoner Uddannelse af slutbrugere (elearning) Det er institutionens implementeringsteams opgave at resten organisationen sættes på IndFak, dog kan anvende materiale som indgår i implementeringspakken Overdragelse For at implementeringen kan overdrages til drift vil punkter som svartider og at systemet virker efter hensigten indgå. I forbindelse med overdragelse vil I som institution skulle udfylde en overdragelsesblanket, som er en del af infoark der blev udfyldt da projektet startede. 52

53 6 Forankring 6.1 Overdragelse til driftsorganisation 6.2 Dokumentation indsamling af implementeringen 6.3 Evaluering 6.4 Leverandøraktivering og fase 2 53