REVIDERT FORPROSJEKTRAPPORT VSYS VirkesHandel Vedlegg til kravspesifikasjon og utviklingsavtale Saksbehandler: Trond Karlsen Versjon 2.0 Revisjonshistorie: Versjon Beskrivelse Dato 2.0 Retter kosmetisk feil i revidert rapport. 27.1.2015 1.3 Revidert for å være vedlegg til kravspesifikasjon og avtale 26.1.2015 1.2 Omarbeidet kapittel 5.2 og oppdatert kapittel 10 10.7.2014 1.1 Omstrukturert innhold. Forberedt rapporten for utvidet forprosjekt Versjon 1.0 godkjent av styringsgruppen. Innholdet oppfyller prosjektmandatet. 27.6.2014 17.6.2014 1.0 Ferdig for distribusjon til avsluttende møter 13.6.2014 SKOG-DATA AS Økernveien 94, 0579 Oslo 81 55 55 81 firmapost@skogdata.no Din samarbeidspartner innen forretningskritisk IT - når kontinuitet er viktig!
Forord Versjon 1.0 av forprosjektrapporten ble godkjent at styringsgruppen 17.6.2014 og gir svar på prosjektets mål (ref 2.2). Styringsgruppen ba styret i SD om å utvide forprosjektet, noe styret besluttet 23.6.2014. Forprosjektrapporten er oppdatert med de punktene som styringsgruppen har bedt om. For å øke lesbarheten er rapporten omstrukturert fra og med versjon 1.1. Versjon 1.3 En del av de tekniske beskrivelsene er flyttet bak i rapporten som vedlegg. Ikke noe av innholdet i versjon 1 er fjernet. Revisjon av prosjektet gjennomført av Imano anbefalte å ta revidert forprosjektrapport inn som en del av avtalegrunnlaget. Innhold 1 OPPSUMMERING 4 2 INNLEDNING 6 2.1 VSYS 6 2.2 Forprosjektets mål 8 2.3 Gjennomføring 9 2.4 Styringsgruppe for forprosjektet 9 2.5 Arbeidsgrupper i forprosjektet 9 2.5.1 Omfang, Avgrensning og arbeidsprosesser 9 2.5.2 Infrastruktur, arkitektur, sporing og revisjon 10 3 IDÉ, BEHOV OG KRAV 11 3.1 Krav og ønsker til ny løsning 11 3.2 Omfang og avgrensning 13 3.2.1 Omfang 13 3.2.1.1 SDs løsning 13 3.2.1.2 Lokale kundeløsning 14 3.2.2 Avgrensning 15 3.2.2.1 Register Feil! Bokmerke er ikke definert.feil! Bokmerke er ikke definert.15 3.2.2.2 Oppgjør 15 3.2.2.3 Innmåling 15 3.2.2.4 Avvirkning (Entreprenør) 15 3.2.2.5 GIS-løsninger 15 3.2.2.6 Transport 15 3.2.3 Støttesystemer 15 4 LØSNING 17 4.1 Dagens løsning 17 4.2 Morgendagens løsning 17 4.2.1 Arkitektur 17 4.2.1.1 Moduler og versjoner 19 Side 2
4.2.2 Arbeidsprosessene 19 4.2.3 Beskrivelse av morgendagens løsning 24 4.2.3.1 Brukeropplevelse og brukervennlighet 24 4.2.3.1.1 Distribusjon av måledokument 24 4.2.3.1.2 Distribusjon av fraktbrevet 25 5 GEVINSTREALISERING 27 5.1 Kost/nytte vurdering 27 5.2 Kritiske forutsetninger for gevinstrealisering 28 6 VEIEN VIDERE 31 6.1 Føringer 31 7 VEDLEGG A LØSNINGSARKITEKTUR FOR MODERNISERT VSYS 32 8 VEDLEGG C AKTIVITETER OG FUNKSJONER I ARBEIDSPROSESSENE 40 8.1 Innkjøp fra skogeier 41 8.1.1 Planmodulen versjon 1 42 8.1.2 Planmodulen versjon 2 42 8.1.3 Planmodulen versjon 3 43 8.1.4 Produksjonsmodulen versjon 1 43 8.1.5 Produksjonsmodulen versjon 2 47 8.1.6 Produksjonsmodulen versjon 3 49 8.2 Innkjøp industri 50 8.2.1 Planmodulen versjon 1 51 8.2.2 Planmodulen versjon 2 51 8.2.3 Planmodulen versjon 3 51 8.2.4 Produksjonsmodulen versjon 1 51 8.2.5 Produksjonsmodulen versjon 2 55 8.2.6 Rapportering og analyse versjon 1 58 8.2.7 Rapportering og analyse versjon 2 58 8.3 Salg/leveranse 59 8.3.1 Planmodulen versjon 1 60 8.3.2 Planmodulen versjon 2 60 8.3.3 Produksjonsmodulen versjon 1 61 8.3.4 Produksjonsmodulen versjon 2 65 8.3.5 Rapportering og analyse versjon 1 67 8.3.6 Rapportering og analyse versjon 2 67 8.4 Produksjon/avvirkning 68 8.4.1 Planmodulen versjon 1 69 8.4.2 Planmodulen versjon 2 69 8.4.3 Produksjonsmodulen versjon 1 70 8.4.4 Produksjonsmodulen versjon 2 72 8.4.5 Rapportering og analyse versjon 1 73 8.4.6 Rapportering og analyse versjon 2 73 Side 3
1 Oppsummering En «kontrakt» er en avtale (juridisk dokument) mellom to handelspartnere. I VSYS VirkesHandel vil en kontrakt bli registrert som en salgordre hos leverandøren og en innkjøpsordre hos kjøper. Det vil alltid være et 1:1 forhold mellom salgsordre og innkjøpsordre mellom to handelspartnere. Et selskap (handelspartner) vil ha innkjøpsordre mot sine leverandører og salgsordre mot sine kjøpere. Disse kan også knyttes mot hverandre slik at flere innkjøpsordre kan bidra til å oppfylle en salgsordre. Løsningen er basert på arbeidsprosessene (se avsnitt 4.2.2) for omsetning: Innkjøp fra skogeier Innkjøp industri Salg / leveranse Produksjon / avvirkning Arbeidsprosessene er enkle og oversiktlige og blitt svært lik standard prosesser for kjøp og salg, men inkluderer det som måtte være spesielt for omsetning av råvarer i verdikjeden fra skogen. Det er fokusert på roller/funksjoner så som innkjøper, selger og produksjonsplanlegger og løsningen vil ha moduler for Innkjøp, Produksjon/Avvirkning og Salg/Leveranse. Løsningen skal gjenbrukes for hvert omsetningsledd. Det betyr at Innkjøp skal dekke funksjonalitet både for første omsetningsledd (som normalt er en salgsorganisasjon), for siste omsetningsledd (som normalt vil være forbrukende industri) og for eventuelle mellomliggende handelsledd. Det samme gjelder for Salg/leveranse. Enkelte aktører kan velge å utvikle egne lokale løsninger for IT-støtte til hele eller deler av leddene i verdikjeden. Dette stiller høye krav til valg av teknologi og arkitektur for ny løsning. Skog-Datas strategiske valg av teknologi og arkitektur for modernisering av VSYS er lagt til grunn for løsningen. Arkitekturen har sterk fokus på integrasjon gjennom utveksling av informasjon basert på e-dokumenter fra papinet og StanForD. Et annet viktig prinsipp i Skog-Datas strategiske valg av teknologi og arkitektur for modernisering av VSYS, er lagdeling (SOA). Forretnings- og datalaget er skilt fra brukergrensesnittet. Brukergrensesnittet kan være utviklet som standard Windows-applikasjoner, som web-løsninger eller som apper (mobile enheter) og kaller på servicer for å kontrollere og lagre data i databasen. Denne arkitekturen støtter 100% opp under enkelte kunders ønske om å utvikle egne brukergrensesnitt eller integrere med lokale løsninger og lagre data «i skyen» (i modernisert KO sentralt i SDs driftsmiljø). Sporing tilbake til opprinnelse er en høyt prioritert del av løsningen. En råvareforbruker skal kunne dokumentere råvarens opprinnelse. Dokumentasjon i forbindelse med sertifiseringsordninger har vært drivende og er så viktig at prosjektet anbefaler at handelsveien er åpen og vises for alle aktørene i en vareleveranse. For å sikre sporing, bruker løsningen begrepet «leveransobjekt» eller bare «leveranse» om en bestemt mengde av en bestemt vare. En innkjøpsordre kan deles i flere leveranser og leveransene kan knyttes mot en eller flere salgsordre. Normalt vil en innkjøpsordre mot en skogeier deles i to leveranser, en for skurtømmer og en for massevirke. En leveranse kan kobles og refereres gjennom mange handelsledd. Sporing krever disiplin, spesielt på logistikksiden. Side 4
I arbeidsprosessene er det tatt høyde for produksjon for lager (midlertidig kjøper). Råvarer kan måles inn og mellomlagres på tomt, terminal eller kai (lager). Systemet tillater at disse leveransene i etterkant knyttes til en salgsordre (lastes på et tog eller en båt med kjent varemottager). For å opprettholde sporingsinformasjonen kreves full kontroll av varene under lagring. Hvordan brukeren opplever VSYS VirkesHandel, er en kritisk suksessfaktor. Hoveddelen av brukerne benytter i dag rolleportaler som inneholder tilgang til andre VSYS-løsninger enn kontrakt. Rolleportalene er Skogbruksleder-web (SL-Web), Kjøper-web (KP-Web) og Skogeier-web (SE-Web). Disse må opprettholdes i en modernisert løsning selv om de pr. definisjon ikke er en del av dagens KO-løsning. For dagens brukere er rolleportalene grensesnittet mot kontraktssystemet. Portalen min.vsys.no (http://min.vsys.no) er opprettet i forbindelse med modernisering av VSYS. Denne portalen vil bli Skog-Datas brukergrensesnitt mot modernisert kontrakt og erstatte SL-Web og KP-Web. GAP-analysen viser at brukerne med modernisert løsning ikke vil miste funksjonalitet i forhold til dagens løsning, men løst på en annen måte. Brukerne vil ikke finne de samme skjermbildene, men de samme funksjonene. I tillegg vil modernisert løsning også inneholde forenklet planstøtte og styring av produksjon/avvirkning. Produksjonsløyper kan planlegges og produksjonsordre sendes til entreprenørløsningene (SDs Entreprenørweb eller kundenes egne entreprenørløsninger). Modernisering av KO har noen konsekvenser for andre omliggende løsninger. Det er tatt hensyn til dette i anslaget, unntatt tilpasning av lokale løsninger. Konsekvensene er beskrevet i kravspesifikasjonen. Side 5
2 Innledning 2.1 VSYS VSYS, forkortelse for Virkessystemene, er en portefølje bestående av mange systemer og moduler. Utviklingen startet på 1990-tallet (VS90) og Progress ble valg som verktøy. På det tidspunktet var Progress et godt valg med en driftssikker database og et avansert utviklingsverktøy. VSYS har vært, og er, et solid og driftssikkert system. VSYS er et felles sentralt system med mange knytninger mellom delsystemer og moduler. Fristilling har som mål gjøre hvert delsystem til en selvstendig løsning for å gi et enklere vedlikehold og mulighet til å modernisere og bytte ut løsninger uavhengig av hverandre. Samtidig med fristilling har det vært naturlig å modernisere løsningen for å møte nye krav fra kundene ut fra funksjonalitet og teknologi (f.eks. å kunne benytte mobile enheter). Fristilling og modernisering startet med Transportløsningen (TR-Plan og TR-Prod). Transportløsningen var den som teknisk var «mest selvstendig» og lettest kunne skilles fra de øvrige løsningene i VSYS. Nøkkelen til videre modernisering og fristilling, sett fra et systemteknisk ståsted, er kontraktsløsningen. Denne forprosjektrapporten omhandler modernisering av kontrakt. Under arbeidet med kontraktsløsningen er det bestemt å ta inn modernisering av registerløsningen i spesifikasjonsfasen. Tabellen under viser status for resten av VSYS-porteføljen i prioritert rekkefølge. System Status Framover WEB-løsninger (SL-Web, KP- Web, SE-Web) Web-løsninger (EP-Web) Innmåling (IM) Mye av innholdet i disse rolleportalene vil bli erstattet med min.vsys.no i KO moderniseringen. Øvrig funksjonalitet i WebSpeed må vurderes. Systemet er i WebSpeed. Hele IM er i hovedsak Progress. Det er laget noen registreringsmetoder i andre språk og på andre enheter. Det er gjennomført et forprosjekt i 2013 (august) på fristilling av IM. Delvis realisering av dette er med i modernisert KO, men omfatter ikke modernisering med utskifting av Progress-kode. Beregningen i dag er omfattende og uoversiktlig. Prinsippet må være å skille alle registreringsmåter/input ut som egne moduler slik at beregningen blir standard og felles for alle typer input. Modernisering av det som ikke er KO-funksjonalitet, må vurderes av brukerne. Denne løsningen henger tett sammen med produksjonsmodulen i modernisert KO. En modernisering vil bestå av: Ny web-basert rutine for registrering av måledokumenter Arkivløsning for måledokumenter Ny beregningsmodul (.net) SQL-database Standard grensesnitt basert på papinet FotoWeb, håndterminaler osv er registreringsmetoder som ikke benytter Progress. Side 6
Returpapir Virkesbasen / VirkesInfo (VB / VI) Transportoppgjør Pris/Avregning (PA) VØK/FIMAS OPTRA XDOC DD (Datadistribusjon) Alt er i Progress. Overføring til SQLserver for datavarehus Virkesbase (VB) er datakilden for VirkesInfo (VI) og flere andre moduler i VSYS. Mange av de andre systemene henter data fra VB. VI er forsøkt avviklet, men inneholder en del detaljerte rapportmuligheter som ikke finnes andre steder. For daglig rapportering og analyse brukes datavarehus. I prinsippet er alle data tilgjengelig i datavarehus-løsningene. VI er en rapportgenerator. Rapporter kan bestilles fra VI (Progress GUI) og fra WebSpeed (web). Rapporter kjøres i batch på Linux. Systemet er i Progress. Løsningen brukes både til transportoppgjør og til entreprenøroppgjør. Hele systemet er i Progress. Inngår ikke i VSYS-familien men er et spesialsystem utviklet for et utvalg kunder. Gammel løsning for ruteberegning og koordinatfesting. Brukes i dag kun ifm flistransport. Utveklsling av XML-dokumenter til eksterne kunder (Viken). System for intern datautveksling i VSYS. Endringer/oppdateringer i flere av databasene i VSYS trigger utveksling og duplisering av data. Brukes hovedsakelig ifm med datavarehus, transport-gis og HT (Håndterminaler). Returpapir henger tett sammen med IM og det vil naturlig å modernisere RP sammen med IM. Virkesbasen, i en eller annen form, overføres til SQL database. Den vil være et arkiv og kilde for bl.a. nye datavarehusløsninger som måtte komme. VirkesInfo avvikles (ikke en del av dette ptrosjektet). Naturlig å tenke en modul for beregning og en modul for oppgjørsdokument. Det vil også være naturlig å se resultatet av SDCs modernisering. I denne forbindelse må vi huske at SDC lager en sentral felles løsning basert på et standard ERP-system. Naturlig å tenke en modul for beregning og en modul for oppgjørsdokument. Det vil også være naturlig å se resultatet av SDCs modernisering. I denne forbindelse må vi huske at SDC lager en sentral felles løsning basert på et standard ERP-system. Eventuell fornyelse til.net må avtale direkte med de berørte kundene. Avvikles i 2014. All flistransport overføres til TR- Tur. Avvikles. Ved overgang til papinet overføres datautvekslingen til VSYS Databuss og til eksterne kunder via 3. part meldingssentral (Logiq). I modernisert løsning brukes standardisert meldinger for utveksling av data. Alle systemer skal lever ferdige meldinger til VSYS Databuss og motta meldinger fra andre systemer fra den samme databussen. Side 7
OLGA Transportweb Registrering av målekvittering på e-post Distribusjon av programkode til servere og klienter. Gammel transportløsning. Er fortsatt i bruk for bestilling av enkelte rapporter. Rutine for å legge inn e-post adresse for mottak av målekvittering. DD avvikles og erstattes av nye løsninger basert på SDs strategi for modernisering av VSYS. Moderniserte løsninger vil distribuere programkode på annen måte. Systemet avvikles samtidig som siste Progress-kode er erstattet. Avvikles i 2014. Avvikles ifm modernisert KO. E- post adresse for mottak av målekvittering skal være en opplysning i KO som overføres til IM i måleoppdraget. 2.2 Forprosjektets mål Forprosjekt for modernisert KO ble vedtatt i styret i Skog-Data 20.2.2014. Nivå Virksomhetsmål Rammer Beskrivelse Styringsgruppen skal innen 25. juni 2014 gi styret et grunnlag for å kunne gå videre eller stoppe arbeidet med ny omforent kontraktsløsning i VSYS Arbeidsgruppene skal innenfor følgende rammer nå prosjektets resultatmål: Skog-Datas strategier for infrastruktur og arkitektur ligger til grunn for arbeidet. Ny kontraktsløsning skal gi informasjon videre til øvrige systemer slik at virke blir solgt, transportert, målt og gjort opp. Ny kontraktsløsning skal gi brukerne økt kostnadseffektivitet ift i dag Ny kontraktsløsning skal være entydig ift integrasjon mot tredjepartløsninger, eksempelvis egne «front-end» løsninger i CRM. Ny kontraktsløsning skal utvikles på en plattform hvor det er sikker tilgang på kompetanse i markedet Ny kontraktsløsning skal ha et enkelt brukergrensesnitt Ny kontraktsløsning skal ha et klart skille mellom forretningstransaksjoner og logistikktransaksjoner Ny kontraktsløsning skal bygges på èn funksjonsorientert arbeidsprosess Resultatmål Kostnadsanslag for spesifikasjonsfasen Kostnadsanslag for utviklingsfasen og implementering Kost/nytte ved å gjennomføre utvikling og implementering Konsekvenser ved å ikke gjennomføre hovedprosjektet Gapanalyse mellom dagens funksjoner og anbefalt løsning Side 8
Forslag til gjennomføring av hovedprosjektets faser 2.3 Gjennomføring Forprosjektet deles opp i to faser, fase 1 og fase 2. Fase 1 handler om å avgrense det videre arbeidet innenfor rammen for prosjektets mål. Fase 2 skal omfatte kartlegging og forslag til arbeidsprosesser, forslag til infrastruktur og arkitektur og krav til sporing. Samt også kost/nytte vurdering, herunder anslag på spesifikasjonsfasen, utviklingsfasen og implementering. Det er styret i SD som fatter de formelle beslutninger omkring gjennomføring, implementering og finansiering av hovedprosjektet. 2.4 Styringsgruppe for forprosjektet Styret oppnevnte en styringsgruppe bestående av: Navn Terje Negård Morten Kristiansen Even Gulli Per Kveseth Per Skaare Tom Johnsen Terje Negård Rolle Leder Medlem Medlem Medlem Medlem Medlem Sekretær 2.5 Arbeidsgrupper i forprosjektet Forprosjektet har vært gjennomført som work-shops i to arbeidsgrupper. 2.5.1 Omfang, Avgrensning og arbeidsprosesser Navn Svend Bøhler Jostein Smemo Jon Gultvedt Bjørn Næsvold Torleif Tiedemann Hans Haave Finn Arne Bjørnstad Anne Bjørnstad Bjørg Tangen Narve Opsahl Ingar Brennodden Øyvind Aursnes Stølen Trond Karlsen Rolle Prosjektleder Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Sekretær Side 9
2.5.2 Infrastruktur, arkitektur, sporing og revisjon Navn Trond Karlsen Magnus Mestvedt Terje Brende Thomas Husum Magne Bakken Olof Sidèn Simen Roligheten Trond Harald Sand Trond Karlsen Rolle Prosjektleder Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Prosjektmedarbeider Sekretær Side 10
3 Idé, behov og krav Aktørene opplever i dag en del begrensinger i VSYS Kontrakt ifm nye omsetningsformer, for eksempel kravet til å fylle opp hele togsett med virke. Det er et ønske fra aktører i bransjen om fristilling, blant annet fordi man vil gjennomføre egne CRM prosjekter. Aktørene er da avhengige av grensesnitt til KO for å nyttiggjøre seg av kontraktsdata i CRMløsningene. Dagens løsning skiller ikke på logistikkaktiviteter og forretningstransaksjoner. Dette skaper lite effektive arbeidsprosesser. Det oppleves som tungvint å måtte til leverandørkontrakten når det skjer omdisponeringer etter at handelsveien etter dagens regler er satt. Verdikjeden risikerer en situasjon med flere individuelle løsninger. Individuelle løsninger kan føre til uklare grensesnitt noe som gir mindre effektiv arbeidsflyt i verdikjeden. Verdikjeden kan også oppleve flere løsninger og derved ende opp med større IT-investeringer enn nødvendig. En ny og fristilt kontraktsløsning har klare krav og forutsetninger for integrasjon (grensesnitt) med andre systemer i verdikjeden. Løsningen skal være funksjonsorientert der brukere kan velge å ta i bruk en eller flere funksjoner og legge grunnlag for kostnadseffektive prosesser hos bruker. VSYS Virkeshandel må kunne håndtere asynkron (ikke sanntid) og synkron (sanntid) integrasjon/kommunikasjon. Skog-Datas teknologistrategi ligger til grunn for prosjektet. 3.1 Krav og ønsker til ny løsning Gjennom arbeidet med forprosjektet er det avdekket krav og ønsker for et modernisert KO-system. Det er lagt vekt på å tilfredsstille dette så langt det mulig i utforming av forslag til ny løsning. Forenklet system i forhold til i dag. I hovedsak er det prosessen rundt omdisponering det her er tenkt på. God integrasjon med forretningsprosessen. Forretningsprosessen skal legges til grunn slik at ny løsning støtter denne. Forretningsprosessen skal ikke tilpasse seg systemet. God integrasjon mot omliggende systemer. En modernisert KO må kunne kommunisere effektivt med omliggende systemer, både med resten av VSYS og med andre løsninger. Integrasjon skal skje gjennom standard e-dokumenter basert på papinet og StanForD. Mer et innkjøps- og planleggingssystem enn et kontraktsystem. Kontrakten er et juridisk signert dokument. IT-løsningen skal støtte «effektueringen» av kontrakten. Riktige data som verdikjeden trenger, må inn i et felles system. Mange aktører er avhengig av de samme opplysningene. Ønsket er å få tilgang til disse på et sted. Minst mulig dobbeltregistreringer i verdikjeden. Når opplysninger er registrert et sted, bør disse flyte videre til andre funksjoner og aktører. Må kunne håndtere leveranser selv om kjøper (varemottager) ikke er kjent (før kjøper er kjent). Blir som å produsere for lager. Dersom varene holdes samlet og adskilt på lager, er det ønskelig å kunne koble mot en salgskontrakt i ettertid og beholde sporingsinformasjonen. Gi grunnlag for produksjonsplanlegging. Innkjøpsordre som er merket med «driftsavtale», skal vises i planer for produksjon. Side 11
Må kunne legge inn en «kladd» uten at det blir en kontrakt (tenke pipeline mulighet, tilbud, avtale). Status på innkjøpsordre og salgsordre forteller hvor i prosessen de er. Må kunne håndtere rundvirke, flis, biovirke og returpapir, med andre ord råvarer. Må kunne håndtere mange handelsledd. En vare skal kunne omsettes gjennom flere ledd og opplysninger om vareleverandør og varemottager skal flyte gjennom hele omsetningskjeden. Må tenke funksjoner i løsningen og funksjonene kan bli utført på forskjellig tidspunkt hos forskjellige klienter (organisasjoner). Klienten (kunden) må «eie» data inntil de frigjør opplysningene. Opplysninger deles med andre gjennom en bevisst handling (manuell eller automatisk basert på definerte regler) ved utveksling via standardisert e-dokumenter. Sertifiseringsinformasjon er en egenskap knyttet til avtalen/leveransen og ikke til varekoden. Alt måles inn som standard sortimenter. Det vil være en fordel om alle data knyttet til en skogsdrift kan «arkiveres» samlet på et sted. Et sentralt arkiv der avtaler, transaksjoner (måledokumenter, fraktbrev osv.) og data fra produksjonen (hogstmaskin-filer) samles pr. innkjøpsordre. Varemottager (kjøper) har ingenting med vareleverandør (skogeier) å gjøre. Endring av varemottager skal ikke føre til endringer i dokumenter mot vareleverandør. Varemottager er knyttet til salgsordren eller leveranseobjektet og vises ikke på avregning eller andre dokumenter mot vareleverandør. En vare skal kunne kjøpes som en varekode og selges som en annen. Systemet skal lagre oppgjørsgrunnlaget for innkjøpsordre og salgsordre adskilt. Eksempler er virke innkjøpt som sams og som selges som sagtømmer og massevirke. Separat måling for innkjøp og salg håndteres også på denne måten. En vare skal kunne kjøpes i en enhet og selges i en annen. Eksempler er innkjøp i tonn og salg i MWh. Brukerne må oppleve ny løsning som en forenkling. Dette vil være en suksessfaktor. Daglige brukere benytter rolleportalene Skogbruksleder-web (SL-Web) og Kjøper-web (KP-Web) for å jobbe mot kontraktsystemet. Rollekonseptet må opprettholdes for å ivareta «alt på et skrivebord». Side 12
SD-løsning Kunde-løsning SKOG-DATA AS 3.2 Omfang og avgrensning 3.2.1 Omfang MKS MKS MKS MKS MKS MKS MKS GIS GIS GIS GIS GIS GIS GIS Register Register Register Register Register Register Register R&A R&A R&A R&A R&A R&A R&A Oppgjør Oppgjør Oppgjør Oppgjør Oppgjør Oppgjør Oppgjør Produksjon Produksjon Produksjon Produksjon Produksjon Produksjon Produksjon Plan Plan Plan Plan Plan Plan Plan CRM CRM CRM CRM CRM CRM CRM Innkjøp Produksjon / Avvirkning Salg / Leveranse Transport Måling Innkjøp Produksjon Salg / Leveranse CRM CRM CRM CRM CRM CRM CRM CRM Plan Plan Plan Plan Plan Plan Plan Plan Produksjon Produksjon Produksjon Produksjon Produksjon Produksjon Produksjon Produksjon Oppgjør Oppgjør Oppgjør Oppgjør Oppgjør Oppgjør Oppgjør Oppgjør R&A R&A R&A R&A R&A R&A R&A R&A Register Register Register Register Register Register Register Register GIS GIS GIS GIS GIS GIS GIS GIS MKS MKS MKS MKS MKS MKS MKS MKS 3.2.1.1 SDs løsning SDs løsning omfatter de grønne boksene i figuren. Modernisert KO skal inkludere løsning for Innkjøp, Produksjons/Avvirkning og Salg/Leveranse. Løsningen skal gjenbrukes for hvert omsetningsledd. Det betyr at Innkjøp skal dekke både første omsetningsledd (som normalt er en salgsorganisasjon) og siste omsetningsledd (som normalt vil være forbrukende industri). For hvert ledd i verdikjeden skal systemet ha en modul for plan med funksjonalitet for enkel planstøtte, en modul for produksjon og en modul for rapportering og analyse. Plan Produksjon Innkjøp Produksjon/Avvirkning Salg/Leveranse Det skal være en enkel planmodul ihht til kravspesifikasjonen. En innkjøpsmulighet (kladd) regnes i denne sammenhengen som en plan. Innkjøpsplaner kan også importeres fra andre kilder. Administrasjon av innkjøpsordre (avtaler eller kontrakter) mot leverandører. En Produksjonsplaner kan oppdateres ut fra innkjøpsordre i «Innkjøp Produksjon». Produksjonsfunksjonen håndterer produksjonsordre mot entreprenør og mottar produksjonsresultater fra Plandelen skal være en enkel løsning. Salg og leveranse håndterer salgsordre mot neste omsetningsledd. En salgsordre skal kunne Side 13
innkjøpsordre skal kunne kobles mot / referere til en salgsordre hos foregående omsetningsledd. entreprenør. Det er ikke et verktøy for entreprenører til å styre sin virksomhet. kobles mot en innkjøpsordre i neste omsetningsledd og den skal også kunne kobles mot innkjøpsordre i Innkjøpsmodulen. Innkjøp skal gjenbrukes i alle omsetningsledd. Brukerdialogen (brukergrensesnittet) kan bli forskjellig avhengig om det kjøpes rundvirke, stående skog, biovirke, industriflis eller returpapir. Dette vil bli avdekket i utviklingsfasen. Salg og leveranse skal gjenbrukes i alle omsetningsledd. Brukerdialogen (brukergrensesnittet) kan bli forskjellig avhengig om det selges rundvirke, stående skog, biovirke, industriflis eller returpapir. Dette vil bli avdekket i utviklingsfasen. R&A Rapporter knyttet til Innkjøpsmodulen. Mulighet til å opprette datavarehus. Rapporter knyttet til Produksjonsmodulen. Mulighet til å opprette datavarehus. Rapporter knyttet til Salgsog leveransemodulen. Mulighet til å opprette datavarehus. Rolletankegangen må være i fokus. Brukerne ønsker «alt på et skrivebord». Ny løsning må realiseres slik at dette kan oppfylles. Skogbruksleder-web (SL-Web), Kjøper-web (KP-Web) og Skogeier-web (SE-Web) er ikke en del av VSYS KO, men utgjør i hovedsak det brukergrensesnittet som benyttes daglig. I SDs strategiske veivalg for modernisering av VSYS, inngår portalen min.vsys.no. Sett fra min.vsys.no vil modernisert KO dekke underområdene Plan og Produksjon. Som et ledd i modernisering av KO, må dagens rolleportaler (SL-Web og KP-Web) erstattes med min.vsys.no. 3.2.1.2 Lokale kundeløsning Enkelte aktører velger å utvikle egne lokale løsninger for IT-støtte til hele eller deler av leddene i verdikjeden. Det skal være mulig å utveksle informasjon mellom kundeløsninger og SDs løsning. Enkelte aktører vil velge å utvikle egne brukergrensesnitt mot SDs løsninger. Data lagres da i SDs løsning (i skyen sett fra aktørens side). Produksjon Plan Innkjøp Produksjon / Avvirkning Salg / Leveranse Plan Produksjon Side 14
Inn Ut SKOG-DATA AS Figuren bygger på valgt arkitektur med lagdeling (SOA). App GUI WEB? Web service Forretningslag Datalag som i figuren over er vist som 3.2.2 Avgrensning Løsningen stiller nye krav til omliggende systemer noe som vil føre til tilpasninger andre steder i VSYS. Tilpasningen i andre løsninger inngår i prosjektet. De blå boksene i figuren viser hvilke systemer som påvirkes av modernisert KO. 3.2.2.1 Oppgjør Endringer i oppgjørsløsningen (Pris/avregning) er ikke en del av prosjektet. Nye funksjoner i kontraktsløsningen vil kreve endringer i input til oppgjør. Det å kjøpe i en varekode og selge i en annen eller kjøpe og selge i forskjellige enheter, vil kreve at input til avregning (mot innkjøp) og input til faktura (mot salg) kan være forskjellig. 3.2.2.2 Innmåling Fristilt modernisert KO medfører fristilling fra Innmåling. Innmåling skal ikke lenger gjøre oppslag i kontrakt for å kontrollere opplysninger. Innmåling skal motta et Måleoppdrag som inneholder de opplysninger som er nødvendig for at måler skal kunne foreta mottakskontroll og utføre måleprosessen. Referanse til måleoppdraget skal følge Transportoppdraget som utstedes av Salg/Leveranse. Dette sikrer entydig referanse mellom en levert vare (lass) og salgsordre/innkjøpsordre. Innmåling må utvides med en databasetabell for måleoppdrag og programmene må endres til å utføre oppslag i denne tabellen i stedet for å gjøre oppslag i kontrakten. 3.2.2.3 Avvirkning (Entreprenør) Modernisert KO skal administrere produksjonsordre mot entreprenør og motta produksjonsdata fra entreprenør. Modernisert KO omfatter ikke løsninger for entreprenør. 3.2.2.4 GIS-løsninger GIS vil være støttesystem i modernisert KO. Prosjektet omfatter ikke tilpasninger i GIS-løsninger for å kunne benyttes sammen med modernisert KO. 3.2.2.5 Transport Transport må kunne ta imot referanse til Måleoppdraget og legge denne opplysningen inn i fraktbrev (og QR-kode). 3.2.3 Støttesystemer De oransje boksene viser støttesystemer som skal kunne spille sammen med modernisert KO. Støttesystemer omfattes ikke av prosjektet. Side 15
Side 16
4 Løsning 4.1 Dagens løsning Dagens KO-løsning bygger på provisjonsmodellen fra 20 år tilbake. Systemet legger leverandørkontrakten (kontrakten mellom skogeier og salgsorganisasjon / første omsetningsledd) til grunn. Systemet skiller ikke mellom logistikktransaksjoner og forretningstransaksjoner. Systemet er et «fellessystem» som betyr at data for alle aktører er lagret i en database og tilgang til informasjonen gis basert på hvilken rolle den påloggede aktør har i omsetningskjeden. En «kjøperkontrakt» er tilgjengelig for «selger» og «kjøper». Informasjon som legges inn av den ene aktøren er også tilgjengelig for den andre aktøren. Systemet er en integrert del av VSYS og brukes direkte i bl.a. P/A (Pris/Avregning). Aktører som ønsker å etablere lokale løsninger i tillegg til eller in stedet for KO, må likevel bruke systemet fullt ut på grunn av den sterke integrasjonen med øvrige systemer i VSYS. En leverandørkontrakt kobles mot en kjøperkontrakt. På leverandørkontrakten opprettes en leveringsplan (sortimenter/perioder) mot kjøperkontrakten. Ved omdisponering av varer, må det fra leverandørkontrakten opprettes nye leveringsplaner som kobles mot ny kjøperkontrakt. På hvilket tidspunkt leveringsplanen opprettes, varierer fra aktør til aktør. Planer/budsjett (innkjøpsplaner, salgsplaner og transportplaner) er i hovedsak basert på Excel. Regnearkene ajourholdes manuelt basert på tall hentet fra KO. Varer kan kjøpes inn til lager hos en salgsorganisasjon, f.eks. ved rotkjøp og ved kjøp av grot. Disse varene kjøpes på organisasjonens eget kjøpernummer og selges fra organisasjonens egne leverandørnummer. Råstoffet kan ikke lenger spores tilbake til sin opprinnelse i systemet (kun manuelt). Dagens løsning er sammensatt av VSYS KO og funksjonalitet lagt til web-løsninger, i hovedsak skogbrukslederweb (SL-web). Mye «finurlig» funksjonalitet med dertil behandlingsregler er realisert gjennom SL-web. Det samme gjelder spesialfunksjonalitet for den enkelte aktør. SL-web er blitt brukergrensesnittet for den daglige brukeren. Brukeren ser SL-Web og KP-Web som en del av dagens KO. 4.2 Morgendagens løsning Morgendagens løsning skal være et fristilt system men oppleves som «fullt integrert» med øvrige VSYS. Det skal være et sentralt system med full funksjonalitet for de som ikke ønsker å etablere lokale løsninger. «Det skal være fullt mulig å omsette virke på en effektiv måte uten måtte utvikle lokale løsninger». Modernisert KO skal bygge på SDs strategiske veivalg for fristilte løsninger i VSYS. Arbeidsprosessene hos aktørene er kartlagt og lagt til grunn for utforming av et modernisert system. 4.2.1 Arkitektur Modernisering av VSYS er en prosess som vil ta flere år og det er viktig å følge samme arkitektur. Prosessen startet med modernisering av transport. Arkitekturen påvirkes av erfaringer fra gjennomførte prosjekter og også av den generelle utviklingen. Teknologi og verktøy for brukergrensesnitt er det som endrer seg oftest og som er løsest knyttet til arkitekturen. Teknologi og verktøy for datalagring og datakommunikasjon har lavere endringshastighet og vil derfor ligge mer eller mindre fast. Side 17
Inn Ut Inn Ut Inn Ut Inn Ut Inn Ut Inn Ut Inn Ut Inn Ut Inn Ut Inn Ut Inndata Utdata Inndata Utdata Inndata Utdata Inndata Utdata Inndata Utdata Inndata Utdata SKOG-DATA AS Løsningsarkitekturen for modernisert VSYS er tatt inn som vedlegg (Vedlegg A Løsningsarkitektur for modernisert VSYS) til forprosjektrapporten. Arkitekturen for modernisert KO må ta hensyn til kravet om at deler av løsningen kan, hos enkelte aktører, bli realisert som lokale løsninger. Et annet moment er at ikke alle aktører vil benytte alle funksjoner. Ut fra dette må modernisert KO ses som 3 logiske systemer (Innkjøp, Produksjon/avvirkning og Salg/leveranse). KO Innkjøp KO Produksjon KO Salg/Leveranse Plan Produksjon R&A Plan Produksjon R&A Plan Produksjon R&A XML XML XML XML XML XML VSYS databuss Det betyr ikke at de må realiseres som 3 separate løsninger implementert hver for seg. I den sentrale løsningen vil de bli realisert som en løsning men med en databasestruktur som tar hensyn til at deler av løsningen ikke benyttes. Innen hver funksjon finner vi modulene «Plan», «Produksjon» og «R&A» (selv om ikke alle modulene vil inneholde funksjonalitet i standardløsningen, det er funksjonalitet som vil føre til ressursforbruk). Aktørene ser også for seg å ikke bruke alle modulene. Arkitekturen må logisk skille modulene innen en funksjon fra hverandre. KO Innkjøp KO Innkjøp KO Innkjøp Plan Produksjon R&A XML XML XML XML XML XML VSYS databuss Arkitekturen ivaretar nå den moduliseringen (fristilling av moduler og funksjoner) kundene ønsker. Den er kostnadsdrivende for den komplette løsningen på grunn av alle grensesnittene. Den kan framstilles som på denne figuren. Innkjøp Produksjon Salg/Leveranse App GUI WEB? Web service Forretningslag Datalag App GUI WEB? Web service Forretningslag Datalag App GUI WEB? Web service Forretningslag Datalag VSYS databuss App GUI WEB? Web service Forretningslag Datalag VSYS databuss App GUI WEB? Web service Forretningslag Datalag VSYS databuss App GUI WEB? Web service Forretningslag Datalag VSYS databuss App GUI WEB? Web service Forretningslag Datalag App GUI WEB? Web service Forretningslag Datalag App GUI WEB? Web service Forretningslag Datalag VSYS databuss App GUI WEB? Web service Forretningslag Datalag I prinsippet kan den enkelte aktør (kunden) velge hvilke moduler de vil benytte og om de vil utvikle egne brukergrensesnitt i tillegg til det brukergrensesnittet som standardløsningen vil inneholde. Side 18
Inn Ut SKOG-DATA AS Løsningen må kunne parameterstyres. Dersom en kunde/klient ikke skal benytte «Produksjon/avvirkning», vil funksjonalitet knyttet mot dette bli deaktivert («grå» valg i menyer og knapper). Alle brukere skal kunne lagre data i den sentrale løsningen selv om de utvikler lokale brukergrensesnitt. Dette oppnås ved fult ut å realisere lagdeling som beskrevet i løsningsarkitekturen for modernisert VSYS. Web service Forretningslag Datalag Alle web-servicer vil bli dokumentert og inngår i versjonshåndteringen av løsningen. Ny eller endret funksjonalitet i en versjon vil følges av nye versjoner av web-servicene. Eldre versjoner av web-servicene vil støttes i en periode selv om nye versjoner slippes, så sant de ikke er i konflikt med endringer i løsningen. Inndata og Utdata skal ivareta system-til-system datautveksling. Grensesnitt mot omliggende systemer (se avsnitt Feil! Fant ikke referansekilden.feil! Fant ikke referansekilden.4.2.3.6.1) ligger i disse modulene. Modulene må også tillegges funksjonalitet for å håndtere enkelte interne grensesnitt. Ettersom det skal være mulig å kombinere sentrale og lokale løsninger, bør slik logikk knyttes til inndata/utdata. Inndata til f.eks. «Produksjon/avvirkning» kan behandles likt av systemet om de kommer fra sentral eller lokal løsning. 4.2.1.1 Moduler og versjoner 4.2.2 Arbeidsprosessene I forprosjektet er arbeidsprosessene for innkjøp, produksjon/avvirkning og salg/leveranse kartlagt ut fra forskjellige «personas». Persona kan ses som en rolle, en typisk representant for en brukertype, og uttrykkes gjerne som «som Innkjøper av tømmer fra en skogeier i en salgsorganisasjon..». Ofte defineres flere personas og prosessen beskrives for hver persona. Mange ganger er det liten forskjell mellom forskjellige personas og arbeidsprosessen kan beskrives generelt, kanskje med noen alternativer for enkelte stepp. I forprosjektet er arbeidsprosessene beskrevet ut fra forskjellige personas. Målet for prosjektet er å enes om en felles arbeidsprosess. Etter bearbeiding står vi igjen med beskrivelse av: Innkjøp fra skogeier (salgsorganisasjon) Innkjøp industri Salg/leveranse Produksjon/avvirkning Innkjøp fra skogeier og innkjøp av andre råvarer (flis, returpapir osv.) kan kombineres i en beskrivelse, men mange av funksjonene vil da måtte ha flere alternativer og prosessen ville blitt komplisert å lese. Imidlertid er det de samme funksjonene som går igjen og kan gjenbrukes. Overordnet beskrivelsene av aktivitetene (innhold og funksjonalitet) er tatt inn som vedlegg (Vedlegg C Aktiviteter og funksjoner i arbeidsprosessenevedlegg C Aktiviteter og funksjoner i arbeidsprosessenevedlegg C Beskrivelse av aktiviteter og funksjoner i arbeidsprosessene). I utviklingsfasen vil det bli mer detaljert. Side 19
Side 20
Side 21
Side 22
Side 23
4.2.3 Beskrivelse av morgendagens løsning I et modernisert KO legges noen prinsipper til grunn. Et modernisert KO skal være et system for innkjøp og salg. Begrepene «Innkjøpsordre» og «Salgsordre» benyttes i stedet for «Leverandørkontrakt» og «Kjøperkontrakt». «Kontrakten» er bare et dokument i omsetningsprosessen. Informasjon mellom aktører skal utveksles på standardiserte e-dokumenter basert på papinet og StanForD. En aktør kan kjøre hele eller deler av sin løsning utenfor det sentrale miljøet. For å tilfredsstille dette må informasjonsutveksling mellom to aktører som begge kjører i det sentrale miljøet, også skje over standardisert e-dokumenter. Enhver oppdatering/endring av en innkjøpsordre eller en salgsordre som har betydning for den andre forretningspartneren (selger/leverandør for en innkjøpsordre og kjøper for en salgsordre), skal utløse en endringsmelding (e-dokument) som sendes berørt aktør. Systemet skal være klientorientert (aktørorientert). I det legger vi at hver aktør skal eie sine data. En salgsordre registrert hos en aktør blir ikke automatisk tilgjengelig som innkjøpsordre hos en annen aktør. Hva som kan inngå i et modernisert KO, framgår av kapittel 3.2 (Omfang og avgrensning) og kapittel 4.2.2 (Arbeidsprosessene). Det er i forprosjektet fokusert på funksjoner som skal løses og ikke på skjermbilder og innhold. Dette vil bli bestemt i utviklingsprosjektet gjennom dialog med mottaksprosjektet. 4.2.3.1 Brukeropplevelse og brukervennlighet Hvordan brukeren opplever VSYS VirkesHandel, er en kritisk suksessfaktor. Hoveddelen av brukerne benytter i dag rolleportaler som inneholder tilgang til andre VSYS-løsninger enn kontrakt. Rolleportalene er Skogbruksleder-web (SL-Web), Kjøper-web (KP-Web) og Skogeier-web (SE-Web). Disse må opprettholdes i en modernisert løsning. Sett fra min.vsys.no vil modernisert KO dekke funksjonene Plan og Produksjon. Det mest hensiktsmessige vil være: Funksjonalitet bortsett fra KO i SL-Web og KP-Web, flyttes til min.vsys.no. Skogbruksleder vil da fortsatt ha sin rolle-portal. SE-Web etableres som en rolle-portal i min.vsys.no eller etableres som lokale løsninger Rolleportalene må være en del av prosjektet for å ivareta brukeropplevelse og brukervennlighet. 4.2.3.1.1 Distribusjon av måledokument Måledokumentet er dokumentasjon til vareleverandør og varemottager. I praksis mottar første omsetningsledd måledokumentet, enten i tillegg til vareleverandør eller på vegne av vareleverandør som så distribuerer til vareleverandør (ofte som elektronisk tilgjengelig). Innmåling mottar et måleoppdrag og måleoppdraget forteller hvem som er mottager av måledokumentet og en liste over kopi-mottagere (øvrige aktører i handelsveien). Når handelsveien er åpen (slik som beskrevet over), vil alle omsetningsledd kjenne hele omsetningskjeden (handelsveien). Hvilket som helst omsetningsledd kan utstede måleoppdraget. Måleoppdraget vil inneholde hele verdikjeden og Innmåling kan sende måledokumentet til alle omsetningsledd. Side 24
4.2.3.1.2 Distribusjon av fraktbrevet Fraktbrevet er en del av logistikkdokumentasjonen og går til vareleverandør (evt. via første omsetningsledd på samme måte som beskrevet for måledokumentet) og varemottager. Side 25
Side 26
5 Gevinstrealisering Følgende er kommer fram i prosjektgruppen: Forventningen om nytteeffekten er størst hos salgsorganisasjonene. For industrien oppgis den største nytteeffekten å være at man unngår kostnader ved alternative individuelle løsninger som gjør at de må sette inn ressurser for å opprettholde totaloversikten på volum. Enkelte av salgsorganisasjonene har beregnet effekten ut fra en innsparing i dagens organisasjon, mens andre har sett den positive effekten av å kunne vokse i volum med samme bemanning. Av den beregnede nytteeffekten er det intern effektivisering som oppgis som den viktigste (mindre feil / dobbeltarbeid). Ny kontraktsløsning en forutsetning for sømløs knytning mot andre systemer hos den enkelte bruker (f.eks. CRM ). Nytteeffekten hos salgsorganisasjonene ble anslått til å være kr 0,75 kr 1.- pr m3. Det hefter imidlertid usikkerhet ved anslagene. I beregningen nedenfor er følgende ca. volumtall lagt til grunn: Mill m 3 Totalt volum 12,0 Viken Skog 2,0 Sum unntatt viken 10,0 Internmåling 1,0 Aktuelt totalvolum 9,0 Flis 2,0 2,5 Rundvirke 6,5 7,0 Vi har i de videre beregninger satt innsparingseffekten pr. år til totalt kr 8 Mill basert på en innsparing for verdikjeden på +/- kr 1.- pr m 3. 5.1 Kost/nytte vurdering Det er 3 dimensjoner av nytteverdi: Nytteverdi for verdikjeden Nytteverdi for brukerne (organisasjonen/kunden) Nytteverdi for Skog-Data Verdikjeden ønsker en sentral løsning med funksjonalitet for en effektiv omsetning av råvarer i verdikjeden fra skogen. Det skal være en utstrakt utveksling av informasjon mellom aktørene for å sikre korrekte data og unngå dobbeltregistreringer. Informasjon skal deles gjennom hele prosessen for å sikre enklere og bedre planlegging og oppfølging. En sentral løsning krever mindre driftsressurser enn individuelle løsninger. Side 27
For brukerne vil en modernisert løsning bety besparelser og effektivisering i egen organisasjon og enklere utvidelser med påbygging av lokale løsninger. Effekten vil være både kvantitativ og kvalitativ. Nytteverdien for Skog-Data er også nytte for verdikjeden generelt. En modernisert løsning vil føre til enklere vedlikehold Løsningen kommer over på en teknologi der det er enklere å skaffe kompetente ressurser (.net vs. Progress) En løsning basert på lagdelt arkitektur gjør det enkelt å tilpasse seg nye brukergrensesnitt og enheter Investeringen i en modernisert løsning må ses i et mer langsiktig perspektiv. Dagens KO har hatt en levetid på 15 år. Vi må anta at en modernisert løsning vil ha en levetid på i alle fall 10 år. Et anslag på realisering på 35 millioner og en innsparing på 8 millioner pr. år, vil gi en ROI på 4,4 år. Selv en ROI på 5 år vil være svært lønnsomt for verdikjeden. 5.2 Kritiske forutsetninger for gevinstrealisering En viktig forutsetning er at den enkelte kunde gjennomfører de nødvendige endringene i arbeidsprosesser og tilpasninger i organisasjonen. Hver kunde/organisasjon må sette opp en gevinstrealiseringsplan, en plan for hvordan de skal realisere sitt business-case. Uansett om effekten skal tas ut gjennom intern effektivisering, på vekst eller nye tjenester, må dette beskrives som et business-case. Business-caset er muligheten. Gevinstrealiseringsplanen må beskrive hvordan dette skal realiseres, hvilke endringer som må til for å få realisert effekten beskrevet i businesscaset. Hver kunde/organisasjon må så følge opp sin gevinstrealiseringsplan. Side 28
Side 29
Side 30
6 Veien videre Prosjektet omfatter både oppdatering av omkringliggende systemer, rolleportaler, utvikling av det nye systemet, opplæring og implementasjon. Omfanget og planer er basert på prosesskartene i denne rapporten. 6.1 Føringer Erfaringene fra tidligere prosjekter (slik de kommer fram i evalueringsrapporten av Tr.Prod) og råd fra profesjonelle prosjektstyringsmiljøer tilsier: - Produktet som skal leveres må være forankret hos kundene og være tydelig definert - Spesifikasjonen må være akseptert av kundene slik at omkamper unngås og endringsbestillinger håndteres profesjonelt - Kommersielle avtaler må være på plass før utvikling og implementering starter - Rollene i prosjektgjennomføringen internt og eksternt må være entydig definert - Kundene må organisere seg slik i spesifikasjons, - utvikling og implementeringsfasene at leverandør har kun ett kontaktpunkt i form av kundens prosjektleder. - Suksess forutsetter kompetente team hos Skog-Data og hos kundene - Kundenes akseptanse må gjennomføres underveis i spesifikasjons- og utviklingsfasene - Uenighet mellom kunde og leverandør må kunne løftes opp til en instans som har myndighet til å treffe beslutninger Side 31
7 Vedlegg A Løsningsarkitektur for modernisert VSYS Side 32
Side 33
Side 34
Side 35
Side 36
Side 37
Side 38
Side 39
8 Vedlegg C Aktiviteter og funksjoner i arbeidsprosessene Figurene fra kartlegging av arbeidsprosessene blir små og utydelig ved utskrift på A4. Figurene er derfor tilgjengelige som egne PDF-dokumenter i A3 format. I forprosjektet er arbeidsprosessene for innkjøp, produksjon/avvirkning og salg/leveranse kartlagt ut fra forskjellige «personas». Persona kan ses som en rolle, en typisk representant for en brukertype, og uttrykkes gjerne som «som Innkjøper av tømmer fra en skogeier i en salgsorganisasjon..». Ofte defineres flere personas og prosessen beskrives for hver persona. Mange ganger er det liten forskjell mellom forskjellige personas og arbeidsprosessen kan beskrives generelt, kanskje med noen alternativer for enkelte stepp. I forprosjektet er arbeidsprosessene beskrevet ut fra forskjellige personas. Målet for prosjektet er å enes om en felles arbeidsprosess. Etter bearbeiding står vi igjen med beskrivelse av: Innkjøp fra skogeier (salgsorganisasjon) Innkjøp industri Salg/leveranse Produksjon/avvirkning Innkjøp fra skogeier og innkjøp av andre råvarer (flis, returpapir osv.) kan kombineres i en beskrivelse, men mange av funksjonene vil da måtte ha flere alternativer og prosessen ville blitt komplisert å lese. Imidlertid er det de samme funksjonene som går igjen og kan gjenbrukes. I beskrivelsene av arbeidsprosessene er det også angitt hva som skal inngå i første versjon og hva som kommer i senere versjoner. Første versjon er å betrakte som en minimumsløsning eller basisløsning. Forklaring til figurene: De grønne boksene utgjør skjelettet i prosessen De gule boksene er aktiviteter. Mange av aktivitetene vil være IT-støtte som må utvikles. De blå boksene er alternativer. Overordnet beskrivelsene av aktivitetene (innhold og funksjonalitet) er tatt inn som vedlegg (Vedlegg C Aktiviteter og funksjoner i arbeidsprosessenevedlegg C Aktiviteter og funksjoner i arbeidsprosessenevedlegg C Beskrivelse av aktiviteter og funksjoner i arbeidsprosessene). Hvilken funksjonalitet som skal implementeres besluttes i utviklingsprosessen i nært samarbeid med mottaksprosjektet. Spesifikasjonene nedenfor er resultatet fra kartleggingsfasen og vil bli brukt som støtte i det videre arbeidet. Side 40
8.1 Innkjøp fra skogeier Side 41
Dette er hovedprosessen for en salgsorganisasjon, men den brukes også av industrien ved direktekjøp. 8.1.1 Planmodulen versjon 1 Versjon 1 vil ikke inneholde prioritert funksjonalitet for plandelen av innkjøp fra skogeier. Imidlertid vil «Registrere salgsmulighet» bli realisert da dette i praksis er en innkjøpsordre med status «Mulighet». 8.1.2 Planmodulen versjon 2 Beskrivelse av aktivitetene som inngår i versjon 2. Periodisert innkjøpsplan pr. område fordelt på FSC/ikke FSC Webløsning for å registrere en periodisert innkjøpsplan. Planen skal være en enkel tabell med varekoder og volumer. Databasetabeller for å lagre område (hode) og varekode/volum (detaljer) fordelt på perioder (måneder) Opprette, lese, oppdatere og slette innkjøpsplan. Hodet skal bestå av områdeid og plandato (gjeldende fra). Ved oppslag vises gjeldende avtale (datostyrt). Nøkkel er områdeid. Detaljlinjer med varekode og volum fordelt på perioder. Volumer skal være fordelt mellom sertifiseringordninger. Motta salgsønsker fra skogeier Service «Innkjøpsordre». 3. part løsninger skal kunne kalle service for å opprette en innkjøpsordre med status «Innkjøpsmulighet» Registrere innkjøpsmuligheter Webløsning for registrering (ajourhold) av innkjøpsordre. Service «Innkjøpsordre». Bruker skal kunne registrere en ufullstendig innkjøpsordre som en «salgsmulighet». Sende tilbud Webløsning for registrering (ajourhold) av innkjøpsordre. Attributt på innkjøpsordre som forteller om det er sendt et tilbud. Service «Innkjøpsordre». Sende tilbud på e-post til adressen som er lagret på innkjøpsordren. Tilbudet skal være en XML-fil med data fra innkjøpsordre sammen med et stylesheet for layout. Bruker skal kunne velge «Send tilbud» fra innkjøpsordre-bildet. Side 42
Forhandlinger Ingen IT-støtte 8.1.3 Planmodulen versjon 3 I versjon 3 lages en mulighet for å importere salgsmuligheter fra andre kilder. Hente muligheter fra skogbruksplan som innkjøpsmuligheter Webløsning for import av innkjøpsmuligheter XML-definisjon av Innkjøpsordre Lese XML-fil og opprette innkjøpsmuligheter ved å kalle service «Innkjøpsordre» Bruker skal kunne peke på en datafil og iverksette import. 8.1.4 Produksjonsmodulen versjon 1 Versjon 1 skal inneholde nok funksjonalitet til å få omsatt virke innkjøpt fra skogeier uten å utvikle lokaleller tilleggsfunksjonalitet. «Avtale» vil ha litt forskjellige aktiviteter avhengig av om man benytter en elektronisk avtale eller en papiravtale. Med en papiravtale må innkjøpsordren registreres i sin helhet mens det med en avtale som er registrert elektronisk, vil være mulig å komplettere det som allerede finnes i systemet. Elektronisk avtale kommer i versjon 2. Registrere (Ajourholde) innkjøpsordre Webløsning for registrering (ajourhold) av innkjøpsordre. Databasetabeller for lagring av innkjøpsordre (Hode, varelinjer og perioder). Service «Innkjøpsordre» med funksjon for å opprette, lese, oppdatere og slette innkjøpsordre. En innkjøpsordre vil bestå av hode og varelinjer. Innkjøpsordre kan innholdsmessig sammenlignes med dagens «Leverandørkontrakt». En innkjøpsordre kan ha status som: 1. Innkjøpsmulighet (kladd/prospect). Hvilke har vi mulighet til å jobbe med / potensielle leveranser. 2. Tilbud. Tilbud er sendt/overlevert skogeier. 3. Avtale. Tilbudet er akseptert og det er opprettet en avtale. 4. Avsluttet. Innkjøpsordren der avsluttet. Avvirking og leveranser er ferdig. Rydding i lagerverdier. Sluttavregning kjøres. 5. Arkivert. Innkjøpsordre med tilhørende informasjon er arkivert i sentralt lager. Regler for når en innkjøpsordre kan slettes, må etableres. Side 43