Oplæg til forretningsgangsopdateringhomepages.knord.dk/erhvervscases/Erhvervscase_2005... · 7.1 Fremtidig lagerstyring hos PG – Lokationstyring ... Projekt ”Navision Attain”

KRAVSPECIFIKATION
Henrik Ziegler

Kravspecifikation Projekt ”Navision Attain”

Indholdsfortegnelse Side

1. Formål .................................................................................................................. 3 2. Generel beskrivelse ............................................................................................ 3 3. Forudsætninger................................................................................................... 4 4. Krav til udviklingsforløb ..................................................................................... 5 4.1 Design/udvikling .............................................................................................. 5 4.2 Test/review...................................................................................................... 5 4.3 Uddannelse ..................................................................................................... 5 5. De specifikke krav ............................................................................................... 6 5.1 Hvordan er de fundet ?.................................................................................... 6 5.2 Funktionalitet ................................................................................................... 6 5.3 Produktflow ..................................................................................................... 6 5.4 Totalliste (funktionalitet, opmærksomhedsområder)........................................ 7 5.5 Interviews, (funktionalitet, forretningstiltag) ..................................................... 7 6. Anbefalinger ........................................................................................................ 8 7. Beslutninger ........................................................................................................ 9 7.1 Fremtidig lagerstyring hos PG – Lokationstyring............................................. 9 7.2 Styklisteindhold ............................................................................................... 10 7.3 Stykliste”genbrug” ved forskellige produktionssteder ...................................... 10 7.4 Varenummerstruktur/opbygning (rå-/færdigvarer) ........................................... 10 7.5 Sprogversion ................................................................................................... 11 7.6 GLS PakkaTrans, Interline-software................................................................ 11 7.7 MultiPay .......................................................................................................... 12 7.8 MultiBank ........................................................................................................ 12 7.9 Systemadgang – ”oppetid” .............................................................................. 12 7.10 og 7.11 Kommentarer, Styregruppe ”Faktura i kassen” ................................ 13 7.12 Leverandøropfølgning .................................................................................. 13 7.13 Kvalitetsstyring ............................................................................................. 13 7.14 Betalingsbetingelser og rabatstruktur ........................................................... 13 7.15 Ordreforecast ............................................................................................... 13 8. Begrænsninger (funktionalitet der ikke er indeholdt i projektet)........................... 14 9. Brugeranalyse ..................................................................................................... 15

10. Opgaveliste ........................................................................................................ 16

Performance Group A/S, Projekt: Navision Attain Side 1 af 21 Dato: 03-02-05


11. Eksterne grænsefladekrav ................................................................................ 17 11.1 Hardware-grænseflade .................................................................................... 17 11.2 Software-grænseflade...................................................................................... 18 12. Tidsplan .............................................................................................................. 18 13. Ordforklaring ...................................................................................................... 19 14. Bilagsliste ........................................................................................................... 21



1. Formål

Formålet med Navision Attain konverteringsprojekt er: ”Vi ønsker at implementere Navision At-tain for at skabe en mere tidssvarende platform for Performance Group A/S samt sikre, at vi har den fornødne platform til fortsat vækst”. Kilde: kommissorium Hvorfor laves denne kravspecifikation?. Årsagen til dette skyldes alene, at Performance Group A/S ønsker at udarbejde en overordnet konverteringsplan for projektet, for deri at beskrive og synliggøre de ønsker samt krav til funk-tionaliteten i kommende Navision Attain i relation til virksomhedens forretningslogik og ar-bejdsgange. Kravspecifikationen vil ikke indeholde detailkrav eller detailplaner, idet projektet har til hensigt at opgradere nuværende ERP-version og ikke erstatte eller ændre ERP-kerne.

2. Generel beskrivelse Denne kravspecifikation er et dokument, der fortæller og giver en indsigt i hvad der skal laves i Navision Attain-konverteringsprojektet, men ikke hvordan det skal laves. Specifikationens væsentligste funktion er at danne grundlag for design-/udviklingsarbejdet for Navi Partner i samspil med Performance Group A/S og dennes organisation. Følgende produktflows har dannet rammerne for det videre udviklingsforløb, hvori forretnings-gange og arbejdsrutiner afspejler kravene til funktionaliteten i Navision Attain. Jvf. bilag 1 , Produktflow niveau I



3. Forudsætninger - at der er afsat de fornødne interne ressourcer hos PG, som er til rådighed i hele konverteringsprojektet.

- konverteringsprojektet ”Attain” har til hensigt at opgradere nuværende N3-version til en Microsoft Navision Attain-version med fokus på og brug af denne versions standard-/modul-funktionalitet. Som følge heraf vil der være forretningsgange i Performance Group

A/S, der ændres og hvor standard prioriteres højst frem for special- eller egenudvikling.

- at specialudvikling i nuværende Navison N3 version ikke videreudvikles.

- at der hos Navi Partner involveres yderligere mandskab i udviklings-/implementerings- fasen end Jørgen Jensen med det formål at overholde projektplanen herunder tidsplan samt opnå flere udviklingskompetancer, videnspredning i den fremtidige videre udvikling hos Performance Group A/S.

- at Navi Partner godkender og accepterer kravspecifikationen som værende en ikke bindende udviklings-/implementeringsplan, men et vejledende oplæg for konverteringen, der understøtter Navi Partners viden omkring Performance Group A/S’ forretningslogik og krave-ne til kommende funktionalitet.

- at kravspecifikationen og hertil hørende projektplan, tidsplan godkendes af styregruppe, projektgruppe og Navi Partner.

- at der ved ændring i eller ved tiltag til nye strategiske og forretningsmæssige ERP-relaterede

områder sker information fra Performance Group A/S’s ledelse til projektleder og Navi Part-ner med henblik på konsekvensbetragtning omkring projektgrundlaget ”Attain” og tilhørende kravspecifikation.



4. Krav til udviklingsforløb Det er Navi Partners og projektgruppens vurdering, at udviklings-, implementerings- og testfa-sen skal ske som parallelle faser fremfor afgrænsede faseinddelinger. Det er hensigten, at Navi Partner vil påbegynde design/udvikling primo august 2003 med ud-gangspunkt i den udarbejdede foranalyse, kravspecifikation og gennemførte interviews med projektgruppen samt funktionslederne. Navi Partner har som ERP-husleverandør hos Performance Group A/S igennem ca. 6 år op-nået indsigt og erfaring i Performance Group A/S’ forretningsgange og produktflow, hvilket gør det muligt at designe og udvikle ved hjælp af afgrænsede og funktionsadskilte moduler.

4.1 Design/udvikling Navi Partner vil benytte sig af en udviklingsmodel af typen ”Prototyping” (se ordforklaring) for at opnå den kvalitativt bedste løsning.

4.2 Test/review Der vil under hele design-/udviklingsfasen blive foretaget reviews (se ordforklaring) og test i samspil mellem Navi Partner og brugerne i organisationen. Dette bestyrker udviklingsforløbet, hvor eventuelle fejl, mangler eller ændringer i løsninger vurderes og tilrettes løbende. Som følge heraf opnås samtidig en løbende uddannelse af superbrugerne (PGD) og brugere i systemets funktionalitet.

Idet Navi Partner løbende udvikler ”små” selvstændige moduler og funktionaliteter, vil bruger-ne skulle teste og være medvirkende til eventuelle tilretninger samt dialog omkring ny og stan-dardfunktionalitet. Langsomt opbygges en viden og indsigt i funktionaliteter og eventuelt æn-drede forretningsgange.

Alt i alt vil alle brugere opnå den fornødne forståelse og indsigt i sammenhængene imellem tværgående moduler og funktionaliteter i relation til arbejds-/forretningsgange i virksomheden.

4.3 Uddannelse Se ovenstående. Superbrugere skal medio august 2003 deltage i et standard Navision Attain kursus afholdt af Navi Partner. Superbrugere (se ordforklaring) skal på forhånd før brugerne være gearet til at imødegå og hjælpe brugerne i spørgsmål omkring almindelig standardfunktionalitet. Administratorer (se ordforklaring) skal deltage på kursus hos Navi Partner. Samtidig vil Navi Partner og Performance Group A/S’ hardwareleverandør Topnordic A/S forestå den fornødne uddannelse i vedligeholdelsesprocedurer af database og klient-/serverkonfiguration.



Der er udarbejdet en brugerliste Jvf. bilag 12 , Medarbejderoversigt, der viser hvilke brugere, der arbej-der med hvilket funktionsområde afdelingsvis. Hensigten er at skabe et samlet overblik over hvilke uddannelsesmæssige indsatsområder, der skal iværksættes til hvilke perso-ner/afdelinger.

5. De specifikke krav 5.1 Hvordan er de fundet ? Metoden, hvorved kravene til kommende funktionalitet i Navision Attain er fundet, baserer på følgende:

a) foranalyse af forretningsgange/produktflow. Jvf. bilag 2, Foranalyse

b) interviews med ledelse og funktionsledere med foranalysen som interviewma-teriale. Jvf. bilag 3, Interviews

c) brugeranalyse, forventede succeskriterier for projektet. Jvf. bilag 4, Brugeranalyse

d) beslutningsmøder afholdt tværorganisatorisk med ledelse, funktionsledere og

brugere. e) afholdte demoer i Navision Attain i standardmoduler.

5.2 Funktionalitet Analysen af forretningsgange og produktflow har resulteret i skriftligt materiale jvf. A4-mapper. Analysen, A4-mapperne er opdelt i funktions- og arbejdsområder med direkte relation til orga-nisationen. Originalerne opbevares i Attain-lokalet, og der er tilsvarende lavet et kopisæt af alle A4 mapper til Navi Partner.

5.3 Produktflow Projektgruppen har valgt at synliggøre forretningsgangsbeskrivelser og produktflow ved hjælp af diagrammer. I A4-mapperne indgår disse diagrammer som konkrete beskrivelser af funktio-nalitet i nuværende Navision N3-version med tilhørende forretningsgange herunder manuelle som maskinelle. Diagrammerne er beskrivende funktionaliteter, der i sin helhed danner grundlag for design-/udviklingsfasen.

På diagrammerne er de maskinelle rutiner (i Navision N3) markeret med stiplede linjer. Under design-/ udviklingsfasen vil alle områder blive vurderet og besluttet, under hensynstagen til, hvilke manuelle rutiner, der skal indgå som standard-, tilrettede eller forblive som manuel funk-tionalitet. Tilsvarende er gældende for de i dag maskinelle.



Det er ikke muligt på nuværende tidspunkt i projektet at fastlægge, hvilke manuelle og maskinelle krav til forretningsgange, der direkte påvirkes eller ændres, idet sammenhængen og afhængigheden i kommende Navision Attain funktionalitet besluttes endeligt under udvik-lingsforløbet i samarbejde med ledelse og brugere – dog vil standardfunktionalitet blive priori-teret højest. Jvf. bilag 5, Produktflows

5.4 Totalliste (funktionalitet, opmærksomhedsområder): Ud fra hver forretningsgang/produktflow er der udarbejdet en funktionalitetsliste samt fundet opmærksomhedsområder. Heri indgår de ønsker og krav, der ud fra nuværende viden og erfa-ringer i Navision N3-version er gældende for kommende funktionalitet i Navision Attain.

Disse er samlet i en totalliste Jvf. bilag 6, Funktionalitetsliste/opmærksomhedsområder.

Alle ønsker og krav bliver løbende vurderet og besluttet i design-/udviklingsfasen. 5.5 Interviews, (funktionalitet, forretningstiltag) Der er afholdt interviews med ledelsen herunder også funktionsledere. I resultatet af disse in-terviews fremgår, hvilke ønsker og krav samt forretningsmæssige tiltag, som projektet skal ta-ge højde for.

Note: Der er til dato ikke fra ledelsen informeret om strategiske tiltag og forhold i Performance Group A/S til projektleder eller Navi Partner, der gør, at projektet har ændret beslutningsgrundlag, el-ler som påvirker projektets videre forløb.

Resultatet af disse interviews er samlet i et skema Jvf. bilag3, Interviews, hvori disse er opdelt i punkter og indgår som direkte kvalitetsfaktorer og succeskriterier for projektets mål.



6. Anbefalinger

Nedenstående anbefalinger er anmærket af projektgruppen. Anbefalinger for den/de fremtidige forretningslogikker samt arbejdsgange, der efter projektgruppens vurdering og anbefaling bør diskuteres og besluttes af styregruppe og ledelse efter afsluttet projekt ”Attain”. Anbefalingerne bygger på overvejelser i forbindelse med optimering og effektivisering af ar-bejdsgange, funktionalitet og økonomiske besparelser.

PDM (Product Design Management) PDM er et konstruktionsmanagement-software fra Gerber Technology, der i dag benyttes til grafisk konstruktion (stykliste) og udarbejdelse af dokumentationsmateriale for produkter (va-rer) i produktionsmiljø. I arbejdsgangen ved oprettelse og vedligeholdelse af varestamoplysninger herunder stykliste benyttes PDM som et udviklingsværktøj parallelt med Navision N3. Forskellen ligger i, at PDM er et Windows-baseret software med grafisk brugerinterface og grafisk printbar layoutdokumentation, hvilket ikke er muligt i Navision N3. Netop dette faktum er ligeledes blevet synliggjort i analysen af forretningsgange i teknisk afde-ling herunder varekonstruktion, vareoprettelse (stykliste). Her viser det sig netop, at de eneste væsentlige forskelle imellem PDM og Navision N3 i forhold til systemudnyttelsen er det grafi-ske layout og PDM’s mulighed for at arbejde med kladdestyklister (en stykliste, der ikke har driftmæssig betydning). Idet PDM og Navision N3 ikke har nogen dataintegration, betyder det meget dobbeltarbejde i form af indtastninger under både oprettelse og vedligeholdelse, hvilket øger risikoen væsent-ligt for fejlmuligheder og ufleksible vedligeholdelsesrutiner for personer i afdelingen. Anbefalingen er, at PDM enten bør opgraderes til en version WebPDM med mulighed for data-integration med tilretninger i Navision Attain (kræver dog stor databasestyring) eller det over-vejes at benytte Navision Attain standardstykliste-funktionalitet som udgangspunkt med tilhø-rende rettede kartoteker som dokumentationsinformation for produktionsmiljø og dermed afvik-le og udfase PDM. Licensforhold PDM er brugerlicensbaseret. Det betyder, at kun de brugere, hvortil der er indkøbt licens har adgang til systemet. Én PDM-licens koster kr. xx.xxx,00 pr. bruger, hvortil der kommer server-konfiguration og årlig abonnement og vedligeholdelse. Performance Group A/S har i dag 5 brugerlicenser. I overvejelsen af at afvikle PDM og i stedet benytte Navision Attain med tilretning opnåes føl-gende fordele: - optimering af arbejdsgange/rutiner. - minimering af fejl ved oprettelse/vedligeholdelse grundet dobbelte registreringer. - andre personer/afdelinger kan tilgå og indhente grafisk dokumentation. - økonomiske besparelser i vedligeholdelse af systemdrift og licensforhold.



Et løsningsforslag kunne se ud som følgende: Jvf. bilag 7, PDM løsningsforslag-diagram Kilde: Navi Partner, Jette Viggers, Henrik Ziegler Der er ikke på nuværende tidspunkt udarbejdet økonomiske konsekvensberegninger eller la-vet yderligere funktionalitetsløsning, men på baggrund af analysen af forretningsgange og in-terviews med både brugere og funktionsledere er der ingen tvivl om, at iværksættelse af et ud-viklingsprojekt/opgave efter afsluttet projekt ”Attain” (konvertering) vil have væsentlige benefits for virksomheden. Kollektionsprøver Jvf. bilag 8, Kollektionsprøver Kilde: Dorte Frederiksen

7. Beslutninger:

Følgende overordnede beslutninger er vedtaget:

7.1 Fremtidig lagerstyring hos PG – Lokationstyring Nedenstående nye funktionalitet i Navision Attain omkring produktion, produktionsplanlæg ning, indkøb og logistik er besluttet. En ny måde at styre og anskue fremtidens logistiske foret- ningsgange hos Performance Group A/S er hermed besluttet.

Skriv udarbejdet af Navi Partner.: I dag foregår lager- og lokationsstyring hos PG detaljeret i henhold til hver enkelt pro duktionsordre. Denne metode har imidlertid nogle problemer, og det bør derfor overvejes, om denne ekstra indsats ved lagerstyring skal erstattes af en anden metode.

Bl.a. har metoden vist sig problematisk i forbindelse med opstart af produktion uden for Polen, idet hvert nyt produktionssted har medført, at der skulle oprettes endnu flere lokationer.

I dag indkøbes råvarer i større portioner, men allerede på indkøbstidspunktet er indkøbet ”øremærket” til specifikke ordrer. Ofte er der tale om fiktive opdelinger af ordrerne, idet leve-rancerne rent fysisk ikke er opdelt pr. ordre. Der er altså mere tale om en teoretisk ”øremærk-ning”, idet varerne ikke kan individualiseres.

Det sker da også, at varerne alligevel må benyttes til andre ordrer end de tiltænkte, hvorved der sker yderligere lokationsflytninger.

Det er vel efterhånden de fleste hos PG bekendt, hvilke ulemper den nuværende metode har i form af mange på hinanden følgende lokationsflytninger, og deraf kraftig forøgelse af mæng-den af vareposter m.v.

Alternativet til denne metode kunne være at anlægge en totalbetragtning. Hvis den rigtige rå-vare og i den rigtige kvalitet er på rette sted og på det rigtige tidspunkt, og så mangelsituatio-ner ikke opstår, må lagerstyringen vel siges at være tilfredsstillende – det er jo netop dette be-hov den nuværende model har haft som formål.



Vejen til denne alternative model vil være at lade enhver behovsberegning foregå maskinelt, og med mulighed for at verificere oplysningerne og evt. foretage manuelle detaildisponeringer som en controller funktion. Hvorledes dette rent systemmæssigt skal designes skal naturligvis detailbeskrives.

Med denne alternative model vil PG være mere gearet til flere forskellige ”produktionsmodel-ler” og produktionssteder.

Konsekvenser for indkøb For indkøbsfunktionen vil anvendelse af total-metoden betyde bedre overskuelighed. Der vil blive bedre mulighed for indkøbssimulering og lettere opfølgning på indkøbsordrerne. Samtidig bliver der en mere korrekt leverandøropfølgning i forhold til aftalte samhandelsbetingelser.

Kilde:

Jørgen Jensen, Navi Partner - godkendt af Carsten Nielsen, Logistik. 7.2 Styklisteindhold Det forventes i udviklingsfasen, at teknisk afdeling, logistik samt økonomiafdelingen fastlægger rammerne, indhold og strukturen af varestykliste. 7.3 Stykliste”genbrug” ved forskellige produktionssteder. Produktion af én og samme vare vil for fremtiden kunne forventes. Altså en vare produceres på flere forskellige produktionssteder og på samme tidspunkt, herunder sæson. Beslutningen er, at styklisten og dermed standardkostprisen skal være den samme på tværs af produktions steder, også selv om eksempelvis sypris er differencieret pr. produktionssted.

Ændring i priser herunder stykliste og standardkostpris må kun foretages én gang pr. sæson.

Som følge af eventuelt tab eller fortjeneste af varedækningsbidrag, vurderes tilfældene enkelt-vis og indgår hermed som afvigelse. Kommentarer, Styregruppe: Vi forventer at vi fremover vil skulle ”source” mere end vi gør i dag, hvilket bla. betyder at samme vare kan blive produceret ved flere producenter. Opbygningen af styklisterne skal til-godese denne sourcingstrategi. 7.4 Varenummerstruktur/opbygning (rå-/færdigvarer) Der er afholdt møder omkring den fremtidige råvare-/færdigvarestruktur. Endelige beslutninger er endnu ikke truffet, men det forventes, at der d. 01-09-2003 foreligger en be-slutning om enten at bibeholde eksisterende varenummeropbygning/struktur eller der forelig-ger et konkret oplæg til den fremtidige varenummerstruktur og hertil hørende implemente-ringsplan.



7.5 Sprogversion På baggrund af, at Performance Group A/S og brand Newline repræsenterer en international kundeportefølje er det besluttet, at Navision Attain som sprogversion ved rapportering og lay-out skal tilgodese både dansk, engelsk, tysk og italiensk.

Den interne Navision Attain sprogversion i virksomheden skal være på dansk. Det forventes dog i fremtiden, at skift imellem dansk, engelsk, polsk, italiensk m.m. bliver akuelt med henblik på ekstern opkobling fra udlandske afdelinger e.lign.

Kommentarer, Styregruppe:

Alle interne rapporter og formularer til medarbejder og eksterne sælgere (også provisionsæl-gere) skal forefindes i følgende sproglag: Dansk og Engelsk Alle rapporter, formularer som sendes til eksterne (Kunder og levernadører) skal forefindes i følgende sproglag: Dansk, Engelsk, Tysk, Svensk og Italiensk.

7.6 GLS PakkeTrans, Interline-software I dag benyttes GLS PakkeTrans som hovedtransportør for danske og udenlandske små pak-keforsendelser. Navision N3 udveksler i dag forsendelsesoplysninger med softwareproduktet fra GLS PakkeTrans. Denne løsning, som anvendes i dag, er meget transportørafhængig og vedligeholdelsestung.

Som følge heraf er det besluttet at tilgodese og forbedre disse forhold.

Til Navision Attain er der udviklet i standardfunktionalitet et forsendelses-/labelmodul (”Pak-keTrans modul for Navision”), der gør det muligt at skabe en uafhængighed af en given trans-portør og samtidig optimere arbejdsgangene ved forsendelse, udskrivning af labels, overførel-se af transportoptions samt integrere salgsordrestyring med henblik på Track and Trace (efter-søgning og sporing af pakkeforsendelser).

Årsagen til, at modulet er navngivet ”PakkeTrans modul for Navision” skyldes, at GLS Pak-keTrans sammen med Navi Partner har udviklet dette modul, men uden afhængighedsmæs-sigt leverandørforhold. De stamoplysninger, der behøves ved indgåelse af ny samarbejdsaftale med anden transportør, kan direkte ændres på bruger-funktionalitetsniveau og er dermed ikke afhængige af specialsoftware m.m.

Jvf. bilag 9, PakkeTrans modul for Navision



7.7 MultiPay MultiPay er et lønmodul udviklet af Navi Partner. Det er besluttet at tilkøbe og benytte dette lønmodul fremfor eksisterende ”LessorLøn”-modul i Navision N3. Beslutningen er truffet af brugere og funktionsleder i økonomiafdelingen hos Performance Group A/S, ud fra en funktionalitet og økonomisk vurdering med tilhørende support-/vedligeholdelseskriterier.

MultiPay-lønmodul er på baggrund af funktionsområdet ”lønbehandling” finansmæssigt uaf-hængigt af den resterende økonomifunktionalitet i Navision Attain på nuværende tidspunkt i projektet. Derfor er det besluttet at idriftsætte MultiPay-lønmodul omgående med virkning fra første lønbehandling pr. den 01-05-2003 med konverterede lønposter fra LessorLøn i perioden 01-01-2003 til 30-04-2003.

MultiPay-lønmodul er indtil videre installeret i en lokal Navision Attain-database (placeret på en filserver) i økonomiafdelingen med adgang for kun én bruger (lønkontor og økonomiansvarlig).

Når konverteringen af Navison N3-version er implementeret, integreres MultiPay-

lønmodulet med finansmodulet i samme driftserver-database. Lessorløn-modul er fra den 01-05-2003 ikke længere aktiv.

Jvf. bilag 10, MultiPay

7.8 MultiBank MultiBank er et bankmodul udviklet af Navi Partner. Det er besluttet at tilkøbe og benytte dette bankmodul fremfor eksisterende ”NaviBanking” fra HotCom Informatik. Beslutningen er truffet af brugere og funktionsleder i økonomiafdelingen hos Performance Group A/S ud fra en funktionalitet og økonomisk vurdering med tilhørende support-/ vedligeholdelseskriterier.

MultiBank-modul er på baggrund af funktionsområdet ”bankbehandling” afhængig af den reste-rende økonomifunktionalitet i Navision Attain. Som følge heraf er det besluttet ikke at idriftsæt-te MultiBank-modulet på nuværende tidspunkt i projektet men afvente den resterende finans-implementering.

Jvt. bilag 11, MultiBank 7.9 Systemadgang – ”oppetid” Det er besluttet, at kravet til det tidsrum, hvor Navision Attain Serveren skal være tilgængelig for brugere af systemet skal være fra kl. 05.00 til kl. 23.00 hver dag inklusiv weekend, hellig-dage og ferier. Med andre ord er der 6 timer, hvori serveren er dedikeret til driftmæssige support-, vedligehol delses- og backupopgaver. Det skal dog anmærkes, at ved fremtidige tiltag som Web-integration, E-business m.v. skal ovenstående tidsrum (oppetid) revurderes og eventuelle hardwaremæssige tilretninger kon

figureres.



7.10 og 7.11 Kommentarer, Styregruppe: Vi mangler en bekræftelse på at der er taget højde for at ”faktura i kassen” og stregkode sy-stemet virker straks efter implementeringen. Kommentarer, PL: Ovenstående er bekræftet af NaviPartner og PL som fungerende og implementeret funktionali-tet i systemet ved idriftsættelses dato.

7.12 Leverandøropfølgning

Kommentarer, Styregruppe: Det er besluttet at ophøje leverandøropfølgning fra ønske til krav. Dette bevirker at vi skal ha-ve forretningsprocessen derom beskrevet. Deadline for aflevering af dette til PL er 15/9 2003. Ansvarlig for at få denne forretningsproces beskrevet er logistikchefen (CN).

7.13 Kvalitetsstyring Kommentarer, Styregruppe: Vi er enige i beslutningen om at udskyde implementeringen af kvalitetsstyringssystem til efter idriftsætning af Attain. Hvis det er muligt ønsker styregruppe at kvalitetssystemet implemente-res sammen med Attain eller straks i forlængelse deraf. Der skal derfor nedsættes en gruppe som skal arbejde med at få denne forretningsproces beskrevet. Beskrivelsen skal foreligge senest primo december 2003. Ansvarlig for at få nedsat gruppen, samt at få denne forretningsproces beskrevet er logistikchefen (CN).

7.14 Betalingsbetingelser og rabatstruktur Kommentarer, Styregruppe: Der skal nedsættes en arbejdsgruppe som skal beskrive og kortlægge de fremtidige betalings-betingelser og rabatstruktur. Deadline for aflevering af denne beskrivelse til PL er 15/9 2003. Ansvarlig for at få nedsat gruppen, samt at få denne forretningsproces beskrevet er salgsche-fen (SN).

7.15 Ordreforecast: Kommentarer, Styregruppe: Styregruppen ønsker at blive inddraget aktivt ved fastlæggelse af den endelige fremtidige for-retningsprocessen vedr. ordreforecasting, intern indkøb af færdigvarer, samt ophøjelse af in-tern ordre til ekstern produktionsordre. Aktion: PL

Vi er enige i begrænsningerne i pkt. 8 , dog ønsker vi at leverandør opfølgningen medtaget i projektet jf. også rettelserne i bilag 3.



8. Begrænsninger (funktionalitet der ikke er indeholdt i projektet)

Igennem den udarbejdede analyse af forretningsgange og produktflow, gennemførte inter-views samt eksterne behov og krav til kommende Navision Attain funktionalitet, er det blevet synliggjort, hvilke funktionalitetsområder og moduler, der ikke indgår i dette konverteringspro-jekt, men som er nedskrevet som områder for eventuelle senere udviklingsprojekter. Følgende funktionalitetsområder designes, udvikles, implementeres, eller investeres ikke i det-te konverteringsprojekt ”Attain”:

• CRM (Customer Relationship Management) • E-business (EDI, E-faktura, import/eksport af elektroniske salgsordrer, elektronisk faktu-

ra/kreditnotaudveksling) • Regnskabsaflæggelse/opbygning i elektronisk format (XRBL) **) • PDM, PDS, konstruktionsmæssig integration til Navision Attain • Web-integration (portaler, Web-server, Intranet, Extranet) • Leverandøropfølgning *) • Kvalitetsstyring *) • Indscanning ved modtagelse af rå-/færdigvarer *) • Variantstyring • Salgsprisliste layoutdesign *) • Vare-/debitor-/sælgerbudget *) • Transport-/speditionsløsning • Kommunikation, ekstern fjernadgang/opkobling til Navision Attain-server

* ) forretningsgange, forretningslogik skal først beskrives og besluttes yderligere af afdeling(er), hvoref-ter opgaven skal specificeres.

**) Navision Attain-revisorløsning fra Navi Partner er demonstreret og modul/funktionalitet afprøves. Beslutning om anskaffelse følger senere.



9. Brugeranalyse

Konvertering og opgradering af nuværende ERP-løsning er et projekt, der i en eller anden form påvirker alle i organisationen i den daglige arbejdsgang og rutine. Afhængigheden af sy-stemets drift og funktionalitet er for virksomheden generelt et krav.

For at imødegå alle brugere og virksomhedens kriterier samt sikre projektets succes, er der foruden analyser, interviews, funktionalitetsbeskrivelser og diagrammer m.v. udarbejdet en brugeranalyse. Denne er med til for både brugere, virksomhed, projekt og Navi Partner at syn-liggøre, hvilke deciderede kriterier, der skal til for at projektet anses for at være en succes.

Derfor er den følgende brugeranalyse foretaget: Jvf. bilag 4, Brugeranalyse

For at imødegå en hurtig og nemmere kommunikation imellem Navi Partner og resten af orga-nisationen i og under design-/udviklingsfasen er der udarbejdet en medarbejderoversigt med tilhørende stamoplysninger såsom navn, lokalnummer, afdeling, billede, lokaleoversigt, email m.m.

Jvf. bilag 12, Medarbejderoversigt



10. Opgaveliste

I forbindelse med udvilingsfasen er der oprettet i MS-Outlook 2000 - ”Alle offentlige map-per” – projekt Attain nedenstående opgaveliste. Brugere kan løbende oprette en opgave til udviklingen om eksempelvis problemer, op-mærksomhedsemner eller nye krav/ønsker. Samtidig vil alle brugere kunne følge disse opgavers status.



11. Eksterne grænsefladekrav

11.1 Hardware-grænseflade Grundet fremrykkelse af idriftsættelsesdatoen for projektet arbejdes der i disse uger med kon-krete løsningsforslag, der skal bistå en ny Navision Attain serverløsning, hvor målet er instal-lation og implementering primo september måned år 2003. Ved en serverinstallation i september måned opnåes en periode fra september til december måned til hardware- og netværksperformancetest. Navi Partner vil fra september måned sam-tidig benytte serveren som udviklings- og testmiljø. Alt i alt bevirker installationen af en serverløsning i september måned, at hardware, perfor-mance og konfigurationer testes inden endelig systemdrift den 01-01-2004. Der indhentes tilbud og løsningsforslag fra TopNordic A/S og Four Leaf A/S (IBM hardware specialister) i samarbejde med Navi Partner som rådgiver omkring Navision Attain serverda-tabase. Der er endnu ikke taget beslutning om, hvilken Navision Attain database, der skal anvendes. Valget baseres på en 1)Microsoft Navision Attain Database Server eller en 2)Microsoft Navi-sion Attain Database Server med Microsoft SQL Server Option for Navision Attain (server). Jvf. bilag 13, System Requierment Navision Attain 3.60 Det forventes, at Navi Partner i samarbejde med Performance Group A/S medio august må-ned beslutter, hvilken database, der skal anvendes. Følgende krav og kriterier indgår som parametre i valget af hardwareløsning:

- IBM serverprodukter. - High performance produkter. - Microsoft standard (OS) operativsoftware - Ved valg af SQL-database – Microsoft standardprodukt - Veritas Backup Exec-backup software - Systemadgang, oppetid fra kl. 05.00 – 23.00 - Mulighed for parallelle driftmiljøer (til udvikling og test) - Redundant, ”fail-over” hardwaredele (harddiske, strømforsyning, netkort) - Understøtter Powerware-UPS løsning. - System Management kompatible overvågningsenheder. - Leverandørsupport (4 timers standbyaftale, 2 timer vurderes) på hardware.

Følgende serverløsninger vurderes: 1. En rack singleserver-løsning med traditionel storage og backup. 2. En rack singleserver-løsning med SAN (se ordforklaring) og single backup.



Kommentarer, PL:

Følgende er besluttet den 05-08-2003 af Henrik Ziegler (PL), Peter Enevoldsen (PE) og Jørgen Jensen, NaviPartner:

- Database valget bliver ”Microsoft Navision Attain Database Server” uden SQL server-option baseret på en Microsoft Windows 2003 server.

- Der investeres i Rack Singel-serverløsning med parallel server til test- og udviklings- miljø.

11.2 Software-grænseflade Følgende Navision Attain-licens (p.t version 3.61) er til dato indkøbt med tilhørende opdate-ringsaftale : Jvf. bilag 14, Navision Attain licensfil Der vil under udviklings-/designfasen løbende blive besluttet, i hvilket omfang tilkøb af ekstra moduler, funktionalitet, brugere, tabeller, rapporter m.v. er påkrævet eller formålstjenstligt.

12. Tidsplan

Projekt-/tidsplanen er ændret i forhold til kommissorium.

Med gennemførte interviews samt analyser af forretningsgange/produktflow som beslutnings-grundlag, er det anbefalet af Navi Partner, Jørgen Jensen og Henrik Ziegler (PL) at ændre og fremrykke idriftsættelsesdatoen fra den 01-04-2004 til den 01-01-2004.

Denne anbefaling er indgivet af Henrik Ziegler (PL) til styregruppen på mødet tirsdag den 17-06-2003, hvor denne ændring af idriftsættelsesdatoen enstemmigt blev godkendt og besluttet af styregruppen. Jvf. bilag 15, Styregruppemødereferat 17-06-2003

Beslutningen er ligeledes mandag den 23-06-2003 blevet enstemmigt godkendt og besluttet af projektgruppen. Jvf. bilag 16, Projektgruppemødereferat 23-06-2003

Revideret styrings-/tidsplan er hermed udarbejdet. Jvf. bilag 17, Styrings-/tidsplan



13. Ordforklaring

Prototyping: Systemudviklingen sker ved hjælp af prototyper. Generelt kan prototyper opdeles i to kategori-er, nemlig prototyper, der skal indgå i det færdige system, og prototyper, der skal smides væk. Formålet er udelukkende at hjælpe med at komme til klarhed over, hvilke krav der skal stilles til det ”nye” system. En ”smide-væk-prototype” kan eksempelvis være papirudgaver af skærm-billeder, eller det kan være mere avancerede kørende systemer/modul-løsninger. Ved systemudviklingen med prototyper inddrages brugerne i en aktiv rolle, fremfor bare pas-sivt at godkende eller afvise det, som Navi Partner udvikler. Det vil være tilfældet, at brugerne selv designer eksempelvis i papirformat udskrifter, menuer og funktionalitet. Fordelene ligger i, at brugerne inddrages i systemudviklingen, hvorved kravene til systemet defineres og udvikles langt bedre. Endvidere ligger fordelen i, at konverteringen af systemet kommer til at fungere og implementeres hurtigt i Performance Group A/S.

Review:

Er små seancer, hvor brugere ud over projektgruppen medvirker i systempræsentation for at finde uhensigtsmæssigheder, indjustere stillede ønsker og krav i programdesignet eller funkti-onalitet. Review skal desuden medvirke til at understøtte kvaliteten i den endelige løsning herunder godkendelse af funktionalitet, skærmbilleder, rapporter o.l. Alt i alt er formålet med review:

- at påpege forbedringer. - at godkende funktionalitet/løsning. - at skabe ensartet kvalitet. - at uddanne brugere.

PL: Projektleder PGD: Projektgruppedeltagere Administratorer: Henrik Ziegler (Navision-opsætning & teknik) Peter Enevoldsen (Navision-opsætning) Finn Wammen (teknik)

Superbrugere: Dorte Frederiksen (produktion, planlægning) Henriette Forup (produktion, planlægning) Henrik Jensen (transport, spedition) Henning Jørgensen (lager, logistik) Jan Stigsen (indkøb) Mads Mikkelsen (teknisk afd.) Henrik Westergaard (salgsafd.)



SAN (Storage Area Network): SAN er et separat netværk til storage, der gør det muligt at tilslutte flere servere til flere storage enheder. En af de største fordele ved et SAN er, at data er konsolideret og samlet et sted, hvor-ved administrationen mindskes. Et SAN er skalerbart, og det er nemt at opretholde centraliseret administration efterhånden som virksomheden vokser. Eksempel:

Arbejdsstationer

Web server

Filserver

Appl.server

SAN

Optiske bokse

Backup-enheder

Disk-

systemer

Arbejdsstationer




14. Bilagsliste

1) Produktflow niveau I (der henvises i øvrigt til A4-mapperne) 2) Foranalyse (der henvises til A4-mapper i Attain-lokale)

3) Interviews 4) Brugeranalyse 5) Produktflows 6) Funktionalitetliste/opmærksomhedsområder 7) PDM løsningsforslag-diagram 8) Kollektionsprøver 9) PakkeTrans modul for Navision 10) MultiPay 11) MultiBank 12) Medarbejderoversigt 13) System Requirements Microsoft Navision Attain 3.60 14) Navision Attain licensfil 15) Styregruppemødereferat den 17-06-2003 16) Projetgruppemødereferat den 23-06-2003 17) Styrings-/tidsplan

Documents

Oplæg til forretningsgangsopdateringhomepages.knord.dk/erhvervscases/Erhvervscase_2005... · 7.1 Fremtidig lagerstyring hos PG – Lokationstyring ... Projekt ”Navision Attain”