Det er nu tid til at behandle alle de funktionsforslag der er fremkommet under de mange bruger-interviews og lave en afgrænsning, sådan at det kun er funktioner af relevans, der herefter arbejdes videre med.
Herunder bliver hver foreslået funktion behandlet hver for sig og der vurderes i hvert tilfælde om den teknisk og organisatorisk er mulig at implementerer.
Denne afgrænsning er fremkommet i tæt samarbejde med Asger Jensen og Søren Hebsgaard (se mødereferat af 12.09.2000 bilag XXX side XXX).
Dette er en meget brugbar funktion og er blevet foreslået af samtlige adspurgte brugere, men den er urealistisk af implementere rent teknisk og organisatorisk. Kalenderen ligger fysisk i en database i hovedkvarteret i USA og den er ikke mulig at få adgang til. Selv hvis det var muligt, er det helt sikkert at databasestrukturen vil blive ændret i fremtiden, da kalenderen ikke er et officelt produkt, og når den engang bliver det, vil den nok være ændret en hel del.
Der er dog en anden mulighed, der kan benyttes. Man kan tage dele af kalender web-interfacet ved brug af web-stripperen i PtG, og på den måde overføre den til WAP. Men dette er et helt projekt i sig selv og vil også skulle laves om når kalenderen på et tidspunkt bliver ændret.
Konklusionen er at denne funktion, selvom den er meget hot og efterspurgt, ikke er mulig at implementere og den afgrænses hermed.
En simpel funktion, dog meget brugbar og relevant, og der er adgang til databasen hvor oplysningerne ligger i. Der er dog ikke oplysninger gemt i databasen om hvilke faglige ressourcer de enkelte medarbejdere besidder. Dette kunne løses ved at oprette en lokal tabel til at gemme de enkelte medarbejderes faglige ressourcer i, men der er ikke stor sandsynlighed for at den vil blive holdt ajour, hvilket er yderst vigtigt. Grunden til at den ikke vil blive holdt ajour skyldes at chancen for at den enkelte medarbejder går ind og opdaterer i tabellen ikke er særlig stor, hvilket hænger sammen med at den ikke vil blive en del af Oracle's eksisterende system.
Konklusionen er at denne funktion vil blive implementeret, dog uden mulighed for at søge efter ekspertise.
Endnu en meget brugbar og efterspurgt funktion, men den er ligesom kalenderfunktionen ikke mulig at implementere rent teknisk og organisatorisk. Time-registreringssystemet er et lukket system. Det er ikke muligt at få adgang til databasen. Det er heller ikke muligt at tage dele af time-registrerings web-interfacet med PtG's web-stripper, da det er en java-applet.
Konklusionen er at denne funktion, selvom den kunne have gjort hverdagen nemmere, ikke er mulig at implementere og den afgrænses hermed.
En ekstrem relevant funktion, som har en meget stor værdi for sælgerne. Den database hvor oplysningerne ligger i, er der adgang til. Det er dog ikke muligt at skrive til databasen, så tilmeldinger må foregå via e-mail, som sendes til en medarbejder med fuld adgang til databasen. Det er dog ikke noget problem, for sådan foregår det også idag.
Konklusionen er at denne funktion vil blive implementeret og eventuelle tilmeldinger vil komme til at foregå via e-mail.
Denne funktion er allerede implementeret som en selvstændig service til PtG af vores kontaktperson Asger Jensen. Det er derfor ikke nødvendigt at udvikle den igen. Asgers version kan integreres med MAOV-systemet, så brugeren ikke ser dem som to adskilte funktioner.
Konklusionen er at denne funktion allerede er udviklet og derfor bare skal integreres i det endelige system.
Dette er meget relevante oplysninger at have og det er muligt at få adgang til dem. De oplysninger der vil blive tilgængelige er fortsat: Hvilke produkter har en konkret kunde, hvor mange licenser og hvilken platform de kører på.
Så konklusionen er at denne funktion vil blive fuldt implementeret.
Det så fra starten af ikke ud til at det ville blive muligt at implementerer denne funktion, da det rent teknisk ikke var muligt at få adgang til de relevante data. Det viste sig dog senere at Christian Fabricius fra salgsafdelingen gerne ville stå for at vedligeholde en en database med prislisten, som MAOV-systemet får adgang til. Dvs. hvergang den eksisterende prisliste bliver opdateret, så sørger CF for at kopier disse data over i prislisten, som MAOV-systemet har adgang til. Prislisten kommer kun til at indeholde priser på produkter, og ikke konsulent-ydelser, som der ellers også var udtrykt ønske om. Grunden til at konsulent-ydelserne ikke er med i prislisten er at det er en kompliceret sag at beregne dem, med mange faktorer og vurderinger der spiller ind. Det er altså ikke bare en fast pris ligesom det er tilfældet med produkt-licenser.
Så konklusionen er at denne funktion alligevel vil blive implementeret, dog uden priser på konsulent-ydelser.
En meget praktisk funktion, der er yderst brugbar når man er ude af huset. Databasen med oplysningerne er lige til at få adgang til, og den bliver løbende opdateret af Human Ressource afdelingen (HR).
Så konklusionen er at denne funktion vil blive fuldt implementeret.
Dette er en meget værdifuld funktion at have til rådighed, da man med denne funktion kan være progressiv overfor kunden, dvs. være på forkant med eventuelle aktuelle sager. Informationerne der skal bruges for at denne funktion kan blive en realitet, er der adgang til.
Så konklusionen er at denne funktion vil blive fuldt implementeret.
Der er et stort behov for denne funktion og den vil uden tvivl have stor forretningsmæssig værdi, men det er ikke muligt at få adgang til den relevante database.
Der er dog en anden mulighed, der kan benyttes. Man kan, ligesom med kalenderfunktionen, tage dele af "Sales Online" web-interfacet ved brug af web-stripperen i PtG, og på den måde overføre det til WAP. Men dette er også et helt projekt i sig selv.
Konklusionen er at denne funktion, selvom den ville have haft stor forretningsmæssig værdi, ikke er mulig at implementere og den afgrænses hermed.
Denne funktion er ikke relevant for Oracle. De kender deres kunder (navngivne kunder), og de bliver kreditgodkendt inden de kan oprettes som kunder hos Oracle. Endvidere er det jo software Oracle sælger, så der er ikke noget materielt tab hvis en kunde ikke betaler.
Konklusionen er at denne funktion ikke er relevant at implementere og den afgrænses hermed.
Dette bliver muligt ved at sende e-mails til hinanden. Man skal dog ikke skrive sit action-point som e-mail manuelt, men bare vælge et action-point i en menu. Resten vil så automatisk blive udfyldt. Det laves sådan at man selv modtager en e-mail (cc), så man kan huske hvilke action-points man har tildelt hvem.
Konklusionen er at denne funktion vil blive fuldt implementeret.
Efter denne gennemgang af hver enkelt foreslået funktion kan det konkluderes at der er 8 funktioner tilbage, som det er relevant at arbejde videre med. Det skal ikke forstås på den måde at de funktioner, på nær en, som er blevet afgrænset ikke var relevante. De er meget relevante, men kan bare ikke lade sig gøre at implementere på nuværende tidspunkt. De vil dog senere kunne tilføjes systemet, hvis de relevante data bliver tilgængelige.