Referater af alle afholdte møder er at finde i det følgende. De er sorteret i kronologisk rækkefølge.
Mødedeltagere: Søren Hebsgaard og MAOV-gruppen
Formål: Identificere brugere, og høre Sørens ideer og forestillinger.
Vi har snakket om muligheder og begrænsninger ved projektet.
Eksterne grupper
Kan ikke lade sig gøre alligevel, da Oracle ikke tillader eksterne personer adgang til deres net.
WAP begrænsninger
lille display
elendig indtastninger
simple opslag er det kanon til
Indtaste en ordre - urealistisk
Efterlad ikke en usikker kunde:
Hvis handelen ikke kan gennemføres pga manglende oplysninger, efterlades en usikker kunde
Der skal endnu et (dyrt) møde til.
Konkurrenten kan springe til og stjæle kunden
Nødvendighed af systemet
Hvor tit skal du ringe hjem når du er i marken
Hvor mange simple action-points skal du hjem og lave
Kan kunden føle sig usikker, når sælger forlader kunden pga. manglende info
Hvor mange af de ting er simple
Virkelig forretningsmæssig værdi
Undgå flere møder
Kortere cyklus - billigere og nemmere.
Bedre kundepleje
Udarbejd spørge-forarbejde - kontrol af Søren
Eventuelt spørgeskema - skal være kort.
Forskelligt hvor vigtige funktioner er:
Nice to have 80% (eMail typisk)
vs.
Need to have 20%
Funtioner der endnu er teknologisk umulige:
Konsulenter får adgang til deres dokumenter - ikke terminaler idag, men sansynligvis om et år.
Kalender-funktion: (typisk ønsket funktion)
Alle har sin egen kalender (papir/Palm), så det er andres kalender på WAP der er interessant (med booking)
Sidder ved møde og skal bruge en anden mand, kan han?
Lokations-bestemte tjenester - ikke realistisk p.t.
Tjenesten kun tilbudt når den er interessant.
Bestil en taxi med eet tryk, fordi fonen ved hvor den er.
Voice Over XML: Oplæsning af eks. eMails og talegenkendelse/verbale ordre - kanon i bil.
Afdelinger/navne som ville give mening
(find både folk der er meget interesseret, og folk som siger: "hvad skal jeg dog med det?")
Sælgere (ligger vandret før den første) - 80 pers.
Large Account - de tunge drenge
Jacob Broberg Jensen - Accountmannager - rolig nu type
Jesper Sachman - Salgschef - teknofreak
Peter Michael Jensen - Salgschef i dot.com
General Business
Thomas Christoph - Channel Account Maneger
Tonny Kolling Kristensen - Teknikmongol
Tina Lindholm - går efter bredt markede - større antal kunder
PSS
Michael Skårup Christensen - Nordisk behov - CRM afdeling mobilt - tænker bredt.
Jens Peder schou - gruppeleder
Supportere
Spørg Mogens
Bjørn Johannsen - Manager
Menig:
Anne Green - spørg eventuelt om andre - hvem er meget ude.
Remote DBA
Konsulenter - 250 pers.
Hvem-som-helst
Application consulting - oftest lange projekter
Technology consulting
Flere afdelinger
Dan kristensen Gruppeleder timerapportering
Hans Henrik Hoffmeyer
Operations (ikke væsentligeste) - 12 pers.
Kristian Bak (måske ikke tid)
Education
Karen Løkke Kristiansen
Marketing
Henrik Bustrup - alle kender ham
Egne spørgsmål:
Hvor ligger data, kan vi få SQL adgang...
- Tal med Asger - han viser også prototype/demoversion af MAOV.
Møder med brugere?
- Se ovenstående.
Test med WAP-fon?
- Brug emulator.
Portal to Go kursus - hvornår?
- Satser på uge 37 - internt kursus muligvis før.
Hvem er XML og JDev kyndig?
- Malte (spørgsmål og teknik) - brug hellere Asger, da han er tilknyttet projektet.
Mødedeltagere: Asger Jensen og MAOV-gruppen Formål: At kunne komme igang med den tekniske del af projektet.
Vi har snakket om tekniske krav og muligheder, og Asger vil gerne sætte os i gang med Portal-to-Go, og hjælpe os med at lave et simpelt "Hello World"-lignende program, der smider sit output fra en DB, igennem Portal-to-Go til en WAP-telefon. Asger har selv kodet en del op imod Portal-to-Go, som vi kan få lov til at studere for at lære det.
Egne spørgsmål:
Kan vi få lov til at se på noget Portal-to-Go?
Vi har set klient-siden, og dens træ-struktur, på en lille tour, og hvordan outputtet ser ud, både på WEB og WAP.
Kan vi se prototypen af det MAOV-lignende system der blev lavet for sjov?
Vi fik set et eMail-læse-system der kører over PtG. "Prototypen" lå ikke klar på serveren så den må vi se en anden gang. Den skal flyttes alligevel.
Hvilke databaser skal vi tilgå?
Vi får adgang til en DB som har nogle views med links til de andre databaser som indeholder de relevante oplysninger. Vi kan så læse det hele, men det er usandsynligt at vi får skrive-adgang. Vi får dog lov til at skrive oplysninger i vores egne tabeller i den lokale DB.
Kan vi få nogle servere til at køre den tunge del på, og kan vi få klient-delen af PtG?
Portal-to-Go ligger allerede på en server, med kørende udviklingsværktøjer. Vi har fået lov til at anvende den. Det vil sige at vi altså ikke selv får brug for vildt store hardwarekrævende maskiner. Klient-delen har vi allerede fået kopieret over. Det er desuden muligt at bruge JDK som vi er vant til, og som heller ikke er særligt krævende.
Mødedeltagere: Asger Jensen, Søren Hepsgaard og MAOV-gruppen Formål: At afgrænse funktionsforslagene til et par enkelte som er realistiske og brugbare.
Kalender for samtlige medarbejdere
Meget brugbar, men urealistisk teknisk og organisatorisk. Kalendersystemet er ikke et officielt produkt, vil ændre sig. At bruge det der er nu(strippe fra web) ville være et projekt for sig selv.
Telefonliste over medarbejdere
Simpel, der er adgang til alle data. Rent organisatorisk findes der ingen oplysninger om hvad hver enkelt kan.
Time-registrering
Igen meget brugbar, men ikke teknisk mulig = lukket land. Web-interface er java-applet.
Marketings-oplysninger
Ekstrem relevant, data er tilgængelige. Tilmelding skal ske pr. e-mail.
Adgang til sine e-mails
Kan godt lade sig gøre. Kun inbox er tilgængelig, ikke nogen andre folders. Det bliver muligt at svare på/sende e-mails, nogle standard tekster laves som hjælp.
Oplysninger om software-licenser
En stor ønsket funktion, der godt kan lade sig gøre. Snak med Betina Michelsen om db-link.
Prisliste (produkter og konsulent-ydelser)
En fed funktion, men ikke teknisk mulig. Viste sig alligevel at blive mulig efter møde med Christian Fabricius afholdt d. 17.10.2000.
Kontaktliste over kunder/partnere
Kan godt lade sig gøre. Snak med Rasmus Menchke om CDM-kundedb.
Oplysninger om aktuelle sager (support)
Dette er også muligt, men det er kun muligt at trække data ud om danske kunder.
Adgang til et udsnit af "Sales Online" systemet
Der er et stort behov for denne funktion, den har stor forretningsmæssig værdi. Men den er heller ikke teknisk og organisatorisk mulig. Man kunne muligvis strippe fra web, men det er et projekt i sig selv.
Har kunden betalt for tidligere køb
Ikke relevant for Oracle, kendte kunder, kreditgodkendes. Og desuden er det "kun" software der sælges.
Tildele action-points til kolleger
I relation til en kunde er det "Sales Online". Enkelt actions = send mail, cc en selv.
Endvidere blev der diskuteret en del om brugerinterface-design på mobileenheder. Hvordan skal man opbygge en applikation på sådanne devices. Man skal tænke meget over forskellige indgange til systemet.
Noget andet som Asger mener vil blive mere og mere anvendt er de såkaldte "intelligente agenter", der ligesom pusher data til brugeren. F.eks kan man få en agent til at sende trafikoplysninger til en på bestemte tidspunkter af døgnet.
Mødedeltagere: Jørgen Karrebæk og MAOV-gruppen Formål: Statusmøde.
Vi gennemgik alle vores dokumenter systematisk for Jørgen og han kom så med kommentare til dem. Følgende kommentare fremkom:
Kravmodellen
Der var uklarhed om hvad PDOM'en viste, vi kom frem til at den er et udsnit af det MAOV gør brug af, dvs. et virtuelt view over det MAOV gør brug af i det eksisterende system.
I funktionsafgrænsningen "Telefonliste over medarbejere" var det ikke klart nok beskrevet hvorfor det ville være umuligt at søge på faglige ressourcer.
Af mock-ups'ne var det helt nemt at forstå hvordan der navigeres rundt på i MAOV-systemet. For at gøre navigeringen på WAP telefonen mere forståelig, blev det besluttet at der skulle udarbejdes et navigations-diagram.
Analysemodellen
ICE-modellen var for uoverskuelig, det blev besluttet at dele den op i 2. En ekstern og en intern.
Design
Vi kom frem til den arkitektur vi bygger systemet op over er en lag-delt arkitektur. Dette skal dokumenteres mere grundigt.
Andre ting der blev diskuteret
Det skal gøres klart fra hvilke databaser der læses og skrives. Vi har kun læserettigheder til de eksisterende interne Oracle databaser. Det er kun muligt at skrive til vores egen database, hvor diversn brugeroplysninger skal gemmes. Man kan endvidere sige at det at sende en e-mail er en form for at skrive til en database.
I design skal de enkelte databaser og tabeller, som MAOV benytter, beskrives. Samt egen tabeller. Og det skal være helt ned på attribut-niveau.
Der skal skrives om teknologivalget i indledningen til design, fordi dette blev allerede valgt da projektet startede, og kan ikke ændres. Dvs. forskellige teknologier skal ikke overvejes under design.
Program-koden skal ikke vedlægges som bilag, da dette ikke har nogen mening. Den kan istedet vedlægges på CD, og så henvise til den i rapporten. Det skal dog ikke forstås på den måde at der ikke må indgå noget kode i rapporten, hvis relevant for nogle designovervejelser/implementationsovervejelser så inddrag gerne lige præcis denne kode.
Forklar om Oracle's politik (globale IT-strategi), og hvorfor systemet ikke er officelt accepteret, og problemerne herved.
Skriv om den måde vi designer og implementerer på, det foregår via en såkaldt round-trip metode, som er helt anerkendt.
Mødedeltagere: Diverse skolevejledere, andre projektgrupper og MAOV-gruppen. Formål: Præsentere vores projekter, og se hvor langt vi er nået. Følgende 3 projekt-grupper var mødt op ud af de 5 der skulle være kommet: 1. Gruppe: MAOV Thomas T. Pedersen Martin Atke Bentsen 2. Gruppe: Axapta XML Jakob Preysz Jørgensen Johan Nis Bjørn Peter G. Hansen 3. Gruppe: Cluster Morten Mali Vejledere: Flemming Rix Jensen Hanne Håkan Svend Aage Filtenborg Jørgen Karrebæk Erik Buch Jakobsen Vi præsenterede vores projekt ud fra: Hvad vi laver Hvilket firma Hvordan vores system hænger sammen Hvor langt vi er nået i tidsplanen Hvordan vi designer systemet Det blev diskuteret: PDOM - ikke beskrivelse af de faktiske databaser. Databaserne skal beskrives! De var lidt bange for at vi kun havde programmeret uden at dokumentere, hvilket jo ikke er tilfældet.
Det var et udemærket møde, og sjovt at høre hvordan det gik med de andre grupper. Det var dog ikke fordi vi havde noget at hjælpe hinanden med. 2. Gruppe arbejder også med XML, men da det er så vidt et begreb, var det ikke muligt at hjælpe hinanden teknisk på det punkt. 3. Gruppe har intet tilfælles med det vi laver, da det var en teoretisk beskrivelse af "cluster-systemer" (flere computere der samarbejder om at løse problemer).
Sammenligning af hvor langt vi er nået i forhold til "2. gruppe".
Vi er nogenlunde lige langt. De har dog skrevet mere end os, bl.a en del mere process-beskrivelse. Det er dog ikke grund til at vi skal bekymre os, da vi mistænker dem for at skrive om ting der ikke har relevans for vores projekt. Vi koncentrerer os om at udvikle et system, og dokumentere løsningen, uden at skrive for meget ævl om selvfølgeligheder. De har ligesom vi, fået implementeret en smule og fået hul igennem, så de ved at det kan lade sig gøre, men er langt fra færdige. De havde lidt problemer med at forklare deres design, men ellers gik det fint med dem. De har dog væsentligt flere stridigheder i gruppen en vi har...
...Efter mødet, snakkede vi lidt med vores egen vejleder (Jørgen Karrebæk).
Han gav os stadig indtryk af at vi er på rette vej. Han kan jo følge med på vores hjemmeside, og se hvad vi får lavet. Dagen efter modtog vi en e-mail hvori han kommenterede et par detaljer.
Mødedeltagere: Rasmus Mencke og MAOV-gruppen Formål: At få en overblik over CDM-database tabellerne.For at kunne lave kontakt- og aktivitets-funktionen i MAOV, kræver det en hvis viden om de tabeller disse funktioner skal få sine data fra. Disse oplysninger ligger i Oracle's CDM-database. Efter lang tids analysering af disse tabeller, og uden tilfredstillende resultat, kontaktede vi Rasmus, som skulle have en hel del viden om lige præcis denne database.
Vi præsenterede for Rasmus hvilken funktionalitet de to funktioner skal have, hvorefter han tegnede en model over de relevante tabeller og hvordan de hænger sammen. Dvs. hvilke attributter der linker de forskellige tabeller sammen.
Han viste os også nogle tilsvarende funktioner, som Oracle har på deres intranet. Så vi kunne få en smagsprøve på hvordan det ser ud på webben.
Mødedeltagere: Christian Fabricius og MAOV-gruppen Formål: Første test-snak. Umiddelbart test-resultat: Kan godt lide ideen med at den husker søgte kunder. Søgning på medarbejdere er hurtig, men på kunder er den langsom (må godt optimeres !!!) Har kunden aktive licencer Prioriter rækkefølgen af kunder, så dem med licenser kommer først. Skriv bynavn med når kunder listes, så man kan se hvor de kommer fra, og eventuelt en stjerne hvis de har licenser. HUSK: Der er både aktive og terminerede licenser. Der skrives for mange aktiviteter ud - sæt distinct på. TAR - fejlmeddelelse på Prioritet, dato for seneste opdatering, og hvem har bolden. Prioriteret orden. Prisliste mangler - CF vil selv oprette en prisliste tabel og vedligeholde den, så den kan komme med i MAOV. Action-points - Ring til mig!!! Lars Selsbæk - support-chef burde vide noget om TAR lselsbae@dk.oracle.com
Mødedeltagere: Bo Nielsen og MAOV-gruppen Formål: Skaffe konkrete oplysninger om hvordan man læser fra TAR-databasen.
TAR-databasen indeholder data om aktuelle sager en kunde har med Oracle som venter på at blive afklaret. Det er dog kun de sager der er aktuelle som MAOV-systemet skal have fat i. Hver TAR har en status i form at en tal-værdi, og det var den vi skulle have afklaret hvordan den skulle tydes.
Bo Nielsen er konsulent hos Oracle og ved hvordan TAR-databasen skal tydes. Vi blev henvist til ham fra Lars W. "Selsbaek", som vi blev henvist til fra Christian Fabricius (møde 17.10.2000).
Tabellen tar_head indeholder oplysninger om de enkelte TAR'er, og har felterne TAR_STATUS og BUG_STATUS, som begge bare er numre. De enkelte numre er forklaret i tabellen tar_status, som vi ikke kendte noget til, før dette møde. Når man linker de to tabeller sammen kan man få en tekst-beskrivelse af status for de enkelte TAR'er.
Der er dog de problem at der er to felter der skal linkes imellem tabellerne, og der skal derfor laves en dobbelt join, eller rettere sagt to "outer-joins". Bo Nielsen sammensatte en SQL-forespørgsel der henter de relevante oplysninger, og det er den vi har brugt i implementeringen.
Vi lavede derudover en gennemgang af felterne, og en af overraskelserne var at kontakt-personen som stod i databasen var kontakt-personen hos kunden, og ikke hvilken oracle-medarbejder der er tilknyttet den TAR.
Mødet varede ca. 20 minutter, og var aftalt uformelt, så det kunne være afbrudt af en kunde-henvendelse, hvilket det dog ikke blev.
Mødedeltagere: Asger Jensen og MAOV-gruppen Formål: Accepttest af MAOV-systemet af primær kontaktperson.
Asger synes det er et rigtigt godt system og yderst brugbart. De funktioner som prototypen manglede er blevet implementeret, og det er han meget glad for. Desuden ser han det som vigtigt for brugbarheden, at systemet husker den enkelte brugers seneste valgte kunder og medarbejdere, når det primært er en WAP-telefon systemet skal køre på.
Ham havde dog nogle kritikpunkter: - menupunkter der fører brugeren gemmen systemet manglede diverse steder - ville gerne have at man kan se hvilke personer der er tilmeldt en aktivitet - kontaktpersoner og aktiviteter måtte gerne hænge mere sammen Men udover disse kritikpunkter, så kunne han godt godkende systemet. Vi diskuterede desuden om hvad et db-link er.