Efter det att Sema Direkt fått och registrerat ärendet hos sig skickar de det vidare till SlbSema EDI-grupp. Detta är den sista instansen innan ärendet ”går bakåt igen”. Det finns ett undantag och det är om ärendet gäller en utrikeskund. I detta fall skickar SlbSema EDI-grupp ärendet vidare till utrikesgruppen. Detta är dock något som ligger utanför vår problemdomän och inget vi hanterar i vår prototyp. I SlbSema EDI-grupp arbetar man precis som STAB-IT, det vill säga en person tar emot nya ärenden och delegerar dem till andra. Man är ansvarig antingen en förmiddag eller en eftermiddag i taget och detta sker efter ett rullande schema. Kommunikationen är väldigt informell och medlemmarna i gruppen pratar med varandra om de behöver hjälp, detta fungerar eftersom de sitter på samma kontor, ibland till och med i samma rum. Den som är ansvarig är ansvarig för all övervakning, det vill säga också loggar från andra program och email. Oftast är det så att vissa typer av ärenden löses av samma person, denna uppdelning baserar sig på tidigare hantering av kunden.
Ofta har EDI-gruppen ingen speciell brådska att lösa ett ärende utan det kan ligga några dagar. Det beror på att ärendena sällan är akuta och finns det viktigare saker att göra så görs de sakerna först. Eftersom mängden ärenden ännu inte är stor är detta inte ett problem –
44 Detta resultat diskuteras i kapitlet Diskussion och Designimplikationer under rubriken ”Kommunikation mellan organisationerna och grupperna”.
ärendena blir sällan liggande särskilt länge. EDI-gruppen menar att de oftast ser direkt om det är akut ärende och i sådana fall fixas det genast. Även om man har en person som är ansvarig för utdelningen eller lösande av ärenden händer det ibland att de andra går in och kollar om några nya inkommit. Det har hänt att två personer gått in och löst samma problem, men det är mycket sällan.
Som vi skrev tidigare använder SlbSema EDI-grupp såväl Blankett 1 som Blankett 2 som underlag för nya beställningar. Detta trots att den andra blanketten ursprungligen är skapad av SlbSema i syfte att få en enklare blankett än Blankett 1 att arbeta med, då denna anses rörig och svår att överblicka och framförallt till stora delar innehåller för SlbSema oväsentlig information.
SlbSema EDI-grupp lägger upp nya ärenden i AMTrix som kan ta emot, konvertera och vidarebefordra meddelanden av olika format som EDIFACT, XML och flata filer, eller av olika filöverföringsprotokoll, som OFTP, FTP, SMTP eller X.400/435. Med andra ord fungerar lösningen som en slags tolk mellan olika typer av system och plattformar (Frontec, 2002). Via AMTrix förs också information automatiskt över från kundernas beställningar till de interna systemen för fakturering, transporthantering och produktionsplanering.45 När SlbSema har lagt upp beställningen i AMTrix och är klara på sitt håll och kunden på sitt, vill STAB-IT att kunden skall skicka in information för att se att allt stämmer och då skickas testfiler via till exempel SMTP, FTP eller OFTP. AMTrix hämtar då den inskickade
informationen från korrekt plattform och så kontrolleras om informationen stämmer och att det inte blir några fel från AMTrix in i Schenkers system. I detta sammanhang kan det åter igen nämnas att det aldrig från SlbSemas sida funnits något önskemål om att vårt system skall ha någonting med AMTrix att göra, utan att SlbSema EDI-grupp även i fortsättningen skall sköta detta handläggande, medan önskemålet har varit att det nya systemet skall understödja detta på ett bättre sätt än de tidigare manuella rutinerna har gjort.
Om en kunds uppgifter ändras på något sätt, till exempel telefonnummer eller dylikt, ändrar EDI-gruppen dessa uppgifter i AMTrix. Detta sker dock bara om Schenker meddelar dessa uppgifter till SlbSema. Det är därmed inte säkert att de uppgifter som står i AMTrix är uppdaterade och aktuella. Detta är inget avgörande problem, då man, om det vid upprepade tillfällen skulle hända att något med EDI-överföringar går fel, kontaktar STAB-IT och ber dem titta efter vad felet kan tänkas vara. Det ligger alltså på Schenkers ansvar att informera SlbSema vid förändringar av kunduppgifter.
I ett tidigt skede av vår undersökning trodde vi att de beställningar som kom till EDI-gruppen skrevs ut och förvarades i pärmar, något som fanns beskrivet i den första modellen som presenterades för oss.46 Efter att ha talat med en medlem i gruppen kom det dock fram att så inte alls är fallet, och personen menade istället att detta sällan eller aldrig skedde. Personen trodde att bara en av medlemmarna i gruppen hade för vana att skriva ut dokumenten och spara dem. Efter att ha frågat den omnämnde gruppmedlemmen kom vi fram till att inte heller den medlemmen gjorde några utskrifter. Med andra ord ansåg sig ingen i gruppen behöva några som helst utskrifter! Det var vid dessa initiala intervjuer som vi insåg att vårat problemområde såg annorlunda ut mot hur det hade presenterats för oss.
45 Mer att läsa om AMTrix finns i kapitlet Varför EDI är intressant under rubriken ”Hur EDI fungerar hos SlbSema”.
Om EDI-gruppen vill söka på en beställning eller en kund använder de prionumret. Därmed använder de alltså det kundnummer som egentligen är Schenkers interna beställningsnummer och inte det som EDI-gruppen har själva, det så kallade remotenumret. Remotenumret är ett unikt AMTrixnummer som SlbSema äger. Varje kund har sitt egna AMTrixnummer. Varje ny kund får ett eget unikt nummer, men SlbSema har för vana att återanvända gamla
overksamma nummer. Om någon kund inte längre är aktuell eller har varit overksam en längre period, kan en ny kund få överta en gammal kunds nummer. STAB-IT får listor av SlbSema med nummer som går att använda, det vill säga sådana nummer som för närvarande är lediga. Avgörandet om en kund inte längre är aktiv ligger hos STAB-IT, eftersom det är de som administrerar kunderna och också de som avgör om numret inte används längre.
Anledningen till att remotenummer återanvänds är helt enkelt att hålla antalet nummer nere. För närvarande är de största numren fyrsiffriga. För att återgå till EDI-gruppens
utsökningsmöjligheter, så använder de alltså Schenkers prionummer och inte sitt egna. Har man inte det numret går det även att leta rätt på en kund med hjälp av dess namn, men det kräver att man går in i ytterligare en applikation, Watchdog. Där söker man på kundens namn och får på så sätt tillgång till prionumret. Sedan går det att i AMTrix söka rätt på
beställningen i fråga. Det är med andra ord en krånglig process där EDI-gruppen är tvungen att använda sig av flera program för att ta reda på något som borde vara möjligt att finna i ett. STAB-IT fyller i remotenumret på Blankett 1 för att underlätta hanteringen för SlbSema, eftersom avgörandet om något nummer skall återanvändas ligger hos Schenker. Trots detta förs numret inte över till Blankett 2, vilket är ett väldigt intressant faktum eftersom
remotenumret endast är intressant för SlbSema och inte alls för Schenker.
För att klargöra skillnaden mellan de olika kundnummer som figurerar på blanketterna, prionummer, kundnummer och remotenummer, vill vi citera STAB-IT:
Kundnummer och prionummer skiljer sig åt genom att prionumret är kundens unika EDI-beställningsnummer, medan kundnummer är kundens unika nummer. Remotenummer är SlbSemas nummer på kunden.
När ett ärende är löst sätts statusen på ärendet till ”pClose” och SlbSema EDI-grupp skickar tillbaka det till Sema Direkt. I Vantive sätts då en tid och ett datum. Om det efter att detta har skett händer att något ändå är fel, rapporteras detta inte till Sema Direkt, utan felet rättas till ”utanför systemet” efter att STAB-IT kontaktat SlbSema via email eller telefon. I det fall att problemet är av större magnitud läggs ett nytt ärende upp. Det inträffar inte ofta att något går fel, men det händer. Det bekräftades vid ett intervjutillfälle, där en medlem i EDI-gruppen, som satt i samma rum när vi intervjuade en annan medlem, som reaktion på att den
intervjuade sa att det i princip aldrig inträffar sådana fel, menade att han just fått in ett sådant från Sema Direkt. ”pClose” betyder dessutom att ärendet bara är färdigt hos SlbSema, inte hos Schenker. Den som slutgiltigt bestämmer att ärendet är färdighanterat är den person som står som ”Ansvarig för indatakontroll” på Blankett 1. Denna person är en medlem i indatagruppen som skall finnas på varje kontor. De sköter kontakten med kunden vid eventuella problem eller fel. En LEA säger:
Enligt [EAR] är [Indatagruppen] viktig som allra sista instans, då beställningen godkänts och lagts upp i AMTrix. [Indatagruppen] är den som ansvarar för vad som står i datan.