Beslutsstödssystem

för ett

transportföretag

Title: Decision Support System for a public transport company

Authors: Ken Larsson, Kerstin Törngren

The purpose of this undergraduate thesis is to conduct a preparatory study to find out if a Decision Support System (DSS) could be used both for management decisions and for decision support in the actual production of transport services.

Our domain is Roslagsbanan, a public transport company. This company is responsible for maintaining a light-rail service in the north-eastern sector of greater Stockholm. The railsystem has 39 stops and covers approximately 66 km of track.

A greater part of the administration is performed with the aid of computer systems, although there is no co-ordination between the different systems. For the production part of the company we are focusing on the work of the dispatcher, whose work is done with the help of 6 different computer systems. There is no co-ordination between them. This lack of co-ordination makes the work more complex.

We have been studying the possibility of introducing a DSS that could work as a co-ordination tool for the dispatcher and at the same time be used by the management for the rest of the company. To accomplish this we have analysed the present situation and the workprocesses being performed. In order to do this we have interviewed personnel working at Roslagsbanan, from this we have compiled a list of requirements that need to be met by a DSS. The most important being the capability of reading databases on various platforms, i.e. PC, UNIX and IBM, and that it can be used in both Windows and UNIX systems. It is further required that the DSS is capable of performing real-time updates of its own database and that it also can export data to other systems. With these requirements we have evaluated eight different DSS´s.

We have found a couple of DSS that could perform these functions and these are worth studying in greater detail to determine which of these would be the best system for Roslagsbanan. In conclusion we have proposed some examples of the design of a future DSS. Additionally we have found that the supervision and control system used by the dispatcher could by itself co-ordinate the different computer systems currently being used in the dispatchers central. It could also provide some data needed by the management, thus making it possible to use a standard DSS for the management’s use.

Figur 1. EIS- eller beslutsstödssystemet

Figur 2. Informationsfunktioner i MSS

Figur 3. Schematisk beskrivning av data warehouse

Figur 4. Jämförelsematris

Bilaga 1. SL Tåg AB Organisationsschema 26

Bilaga 2. Exempel på startbild i ett beslutsstödssystem 27

Bilaga 3. Exempel på utformning av skärmbilder i beslutsstödssystem 28

Bilaga 4. Exempel på skärmbild i nuvarande tågledningssystem 30

Bilaga 5. Exempel på tågjournal 31

Bilaga 6. Exempel på utformning av skärmbild i tågledningscentral 32

Bilaga 7. Exempel på utformning av skärmbild i turfördelningen 33

Bilaga 8. Förslag till övriga förändringar 34

Det är inte ovanligt att man i ett företag finner ett flertal olika datasystem för olika uppgifter. I ett företag kan det förekomma bland annat separata ekonomisystem, personaladministrativa system, försäljningsadministrerande system och produktionssystem.

Vid framtagande av beslutsunderlag, både för företagsledare på olika nivåer och operativa beslutsfattare behöver man kunna sammanställa uppgifter från dessa delsystem. Med hjälp av ett beslutsstödssystem kan man hämta in data från de olika systemen och genomföra eventuella transformeringar av dem samt bearbeta uppgifterna för framtagning av rapporter.

Beslutsstödssystemen är från början utvecklade för att stödja företagsledningen i dess arbete genom att förenkla framtagande av beslutsunderlag. Dock skulle åtminstone delar av dessa data kunna användas även i den operativa verksamheten för att underlätta det praktiska arbetet. En sådan användning ställer förmodligen andra krav på systemet.

Vi behandlar i denna undersökning förutsättningarna för användning av beslutsstödssystem i ett offentligt tjänsteföretag. Framförallt koncentrerar vi oss på frågan om hur man skulle kunna underlätta operativa beslut i realtid. Den del av beslutsstödssystemen som behandlar företagsledning i allmänna termer kommer vi enbart att behandla översiktligt. Företaget som vi använder som exempel är Roslagsbanan. Orsaken till detta val är tvåfaldigt, för det första är Roslagsbanan ett tjänsteproducerande företag, där produktionen består av tjänster (resor), man tillverkar inget som går att lägga på lager. Roslagsbanan är också ett exempel på en komplex operativ beslutsmiljö, tekniskt avancerad med flera okoordinerade datasystem.

Roslagsbanan ingår i företaget SL Tåg AB och ansvarar för trafikeringen av den nordöstra spårbundna lokaltrafiken mellan Stockholm Östra och Kårsta, Österskär respektive Näsbypark (66 km och 39 hållplatser). Förutom produktionsenheten Roslagsbanan finns det inom SL Tåg AB stabs- och servicefunktioner som är av betydelse för trafikproduktionen (se bilaga 1).

Förutom Roslagsbanan består SL Tåg AB av Saltsjöbanan samt verkstadsenheter vid respektive järnväg.

För att producera lokaltrafiken är Roslagbanan beroende av SL Bansystem AB som ansvarar för den fasta tekniken i form av bana, banunderhåll samt rullande materiel. Dock ansvarar trafikföretaget för löpande underhåll och smärre reparationer av det rullande materialet. Verksamheten bedrivs till övervägande del i fastigheter som ägs av SL Fastigheter AB.

Även internt inom Roslagsbanan finns det ett behov av samarbete och utbyte av informationer för att underlätta den dagliga verksamheten. På ledningssidan finns det behov av olika statistikuppgifter som skall ligga till grund för beslut och planering, både på kort och lång sikt. I den dagliga produktionen är det främst trafikledningen som är beroende av ett stort antal separata datasystem och manuella system, vars uppgifter skall ligga till grund för löpande operationella beslut. Det finns i dagsläget inget samordnande system som tar fram dessa uppgifter. För framtagande av olika statistiska uppgifter är man beroende av manuella rutiner, som utförs av ett begränsat antal befattningshavare vilket innebär risk för störningar vid frånvaro.

Vid trafikledningen, som i och för sig har flera moderna datasystem till sin hjälp, måste befattningshavaren hålla uppsikt över 5-6 olika tekniska system. Vid åtgärder i ett system måste man i vissa fall även manuellt vidta åtgärder i andra system. I vissa fall måste man också konsultera manuella system för att få fullständiga beslutsunderlag.

Problemet är att det finns ett behov av att utbyta informationer mellan olika befattningshavare och mellan de olika datasystemen och detta är inte implementerat i något av de nuvarande datasystemen på Roslagsbanan.

Vi skall i denna förstudie undersöka om ett beslutsstödssystem skulle kunna användas för både produktions- och ledningsbeslut. Detta system skall från Roslagsbanans befintliga datasystem kunna samla in, bearbeta och presentera behövlig information.

Det bör betonas att detta arbete inte utförts på uppdrag av Roslagsbanan och de slutsatser vi redovisar kommer med nödvändighet inte att användas. Vi har valt Roslagsbanan som ett exempel på en komplex operativ beslutsmiljö, med ovanliga problemställningar. En teknisk miljö som samtidigt uppvisar en datasystemssituation som troligen inte är allt för ovanlig, flera olika okoordinerade datasystem i samma företag.

I förarbetet har ingått litteraturstudier, inklusive studium av fackartiklar om användning av beslutsstödssystem, insamling av grundläggande data om tillgängliga system, inklusive sökning på Internet. Efter teorigenomgång har vi utarbetat en grov handlingsplan. I detta arbete har vi arbetat med framförallt operativa beslutssituationer, se organisationsschema i bilaga 1. Vi har koncentrerat arbetet på de funktioner som i organisationsschemat är markerad med dubbel ram, de som markerats med streckad ram berörs över huvud taget inte i arbetet.

För framtagning av kravspecifikationen har vi genomfört intervjuer på Roslagsbanan. Dessa intervjuer har framförallt syftat till en kartläggning av det nuvarande datasystemen. Som en del av detta har vi också önskat ta reda på planerade förändringar. Vi har också analyserat arbetsrutiner för att kartlägga eventuella samordningsbehov. Detta steg har innefattat en undersökning av marknaden för att undersöka vilka färdiga beslutsstödssystem som finns, i detta arbete har vi utnyttjat sökningar i databaser, bland annat Libris på Universitetets bibliotek och Internet.

Efter sammanställning av kravspecifikation har vi insamlat data om de olika beslutsstödssystemen, genom telefonkontakter, studiebesök, broschyrmaterial och sökning på Internet. De beslutsstödssystem som vi undersöker har sammanställts från den referenslitteratur som studerats, i vissa fall har systemen utgått eller ersatts av nya versioner. Vi bedömer att de undersökta systemen är ett representativt urval av befintliga system, som täcker in allt från helt färdiga system, exempelvis Nyckel 97, till rena utvecklingsverktyg, exempel på detta är SAS Systemet.

I utvärderingen utför vi en jämförelse mellan Roslagsbanans behov och tillgängliga system. Våra rekommendationer redovisar dels tänkbara system, som uppfyller de tekniska krav som vi funnit, och som kan användas både för operativt beslutsstöd och företagsledning, dels förslag på tänkbara utformningar för några av funktionerna. Detta skall kunna ligga till grund för en detaljerad utvärdering inför ett eventuellt slutgiltigt val mellan dessa system.

I kapitel 2 går vi in på en detaljerad beskrivning av nuläget. Denna beskrivning är uppdelad på de olika funktioner som berörs i arbetet, med en redovisning av vad som är specifikt för just denna del av företaget.

I detta kapitel redogör vi även översiktligt för det väsentligaste om beslutsstödssystem, en kort historik med beskrivning av funktioner i stort och en vardagsbeskrivning, som även den som inte är förtrogen med beslutsstödssystem skall kunna tillgodogöra sig.

I kapitel 3 redovisar vi en kravspecifikation. Denna är uppdelad efter de två huvudområden vi arbetar med, management och operativ ledning. Den operativa delen är vårt huvudsakliga område så denna del är ytterligare indelad i tre huvudområden, presentation av tågdata, resandeinformation och övrigt.

Jämförelsekapitlet, kapitel 4, inleds med en översikt av de system vi undersökt. Med utgångspunkt från kravspecifikationen jämförs sedan kraven med systemen i en matris. De system som vi med utgångspunkt från kravspecifikationen bedömer vara lämpliga alternativ beskriver vi sedan mer ingående i kapitel 5.

Arbetet har en heterogen målgrupp, nämligen personer med så vitt skilda kunskaper som till exempel data- och systemvetenskap, redovisning, organisation eller yrkeskunskaper inom tågledning. För att göra det möjligt för alla dessa att ta till sig innehållet i denna uppsats försöker vi att även förklara saker som för personer med fackkunskaper ter sig som självklara.

Som ett exempel förklarar vi i kapitel två beslutsstödssystem, dels med en kort historisk och teoretisk sammanfattning. Denna gör inga anspråk på att vara heltäckande och uttömmande utan har som syfte att kort förklara fenomenet som sådant. Till detta är fogad en beskrivning på det vardagliga användandet för att ytterligare belysa dess funktion.

För sina respektive arbetsuppgifter har så gott som samtliga funktioner inom verksamheten någon form av datorstöd. För en effektiv och smidig produktion fordras ett väl utvecklat och fungerande samarbete. Trafikledningscentralen är till exempel beroende av information från rangeringen avseende iordningställande av tåg och planerade tågsättsbyten. Rangeringen är i sin tur beroende av trafikledningen för att få tillgång till spår. Likaledes är trafikledaren beroende av turfördelningen för information om bemanning av tågen. Dessutom finns ett behov av tillgång till resandestatistik, för att planera antalet vagnar i tågen.

Vid trafikledningen kommer det att finnas inte mindre än sex datasystem, som dessutom är fysiskt separerade, nämligen:

• Adtranz, ett lokalt ställverk som sköter signaler och växlar
• Cactus, ett fjärrstyrnings- och övervakningssystem
• Linaria, PC-baserat system för resandeinformation
• Dataövervakning av eldistributionen
• Ett datorstyrt radiosystem som är under installation
• Persondatorsystem med lokalt nätverk som är under uppbyggnad

Cactus är ett UNIX-baserat övervakningssystem, som också används till att styra de lokala ställverken. Med hjälp av Cactus har tågledaren alltid aktuell trafikinformation, dels vad det gäller tåglägen men även växel- och signalstatus samt om vägbommar är fällda eller ej. Det är via operationer i Cactus som tågledaren leder trafiken, till exempel bestämma på vilket spår ett ankommande tåg skall tas in på Stockholm Östra.

Tågledaren har en översiktlig bild av järnvägen i form av sju monitorer och två arbetsmonitorer. Det finns två arbetsplatser, där det praktiska arbetet utförs. På dessa arbetsmonitorer tar tågledaren fram aktuell bandel och beordrar tågvägar etcetera (bilaga 4).

Tågtrafiken är programmerad i Cactus, och i teorin skall systemet själv kunna styra trafiken, förutom vid Stockholm Östra, där man på grund av belastningen valt att leda trafiken manuellt. I praktiken visar det sig dock att tågledaren måste ingripa manuellt framförallt under högtrafik men även vid trafikstörningar som kan uppträda när som helst under dygnet.

Vid förseningar och spårändringar måste tågledaren manuellt ändra i passagerarinformationen. När en försening inträffar registreras detta automatiskt i systemet (Cactus) och tågledaren anger orsak med en kod. Denna information lagras i systemet och tas fram i samband med redovisning av förseningsstatistik.

Systemet för information till resande består av ett PC-styrt nät av monitorer, placerade både på Stockholm Östra och i tunnelbanan. Informationen i detta system baseras på tidtabell och planerade avgångsspår. Denna information bearbetas på SL:s dataavdelning. Tillfälliga ändringar, förseningar och spårändringar, måste dock införas manuellt under drift, vilket tågledaren utför. Vid till exempel en försening registreras denna avvikelse automatiskt i Cactus, efter att tågledaren angivit orsak går han till en annan dator och skriver in ändringar i informationssystemet till passagerarna.

För övervakning av eldistribution finns ett datorsystem, i praktiken är enbart driftstörningar av intresse, och systemet varnar om någon av de sex matarstationerna inte fungerar.

Det nya radiosystemet som håller på att införas kommer att styras av en dator i tågledningscentralen, detta innebär att varje underavdelning kan upprätthålla intern radiotrafik utan att störa andra avdelningar. Vid trafik över avdelningsgränser eller från avdelning till tågcentralen måste tågledaren manuellt tilldela en radiokanal.

Det lokala nätverket som är under uppbyggnad skall anslutas till SL:s PC-nätverk och möjliggöra bland annat utbyte av e-post med tunnelbanan för information om förseningar etcetera.

Allt som allt finns det ett 20-tal monitorer som trafikledaren har att hålla uppsikt över, och fem helt separata datasystem, inte enbart logiskt separata utan även fysiskt separerade. Cactus och Adtranz arbetar som en enhet, Cactus hämtar information från Adtranz och åtgärder i Cactus blir utförda i Adtranz. Till detta kommer ett antal helt manuella rutiner. Vid ledningscentralen finns bland annat en tågjournal, bestående av en bunt papper. Varje avgång och ankomst bockas av i journalen (se bilaga 5).

När behov av spårändring uppstår för tågledaren in en bläckändring i tågjournalen. Denna ändring behöver tågledaren för att minnas att beordra tågvägar till rätt spår. Den dator som styr informationsmonitorerna behöver även uppdateras med nya uppgifter.

Om personal saknas vid ett tågs avgångstid kan tågledaren i journalen se vilket turnummer som skall bemanna tåget. Med utgångspunkt från turnummer kan man i personalschemat få information om vem som skall bemanna den turen, och via inskrivningslistan se om personen har kommit. Om man skulle behöva kalla in reserv eller få kontakt med personal som ej kommit måste man ta fram personens telefonnummer från personalpärmar.

Turfördelning och personalplaneringen ansvarar för bemanning av tåg, trafikledning och rangering. För bemanning av tåg i framförallt rusningstrafik är man beroende av personal från verkstadssidan, som förutom sina ordinarie uppgifter även arbetar som tågförare. Personalplaneringen arbetar på lång sikt medan turfördelning ansvarar för bemanningen av kommande 14 dagars period, samt löpande schemaärenden. Utanför ordinarie kontorstid ansvarar tågledaren för akuta personalfrågor.

Den långsiktiga personalplaneringen görs i ett datasystem, anslutet till ett stordatorsystem inom SJ. Detta system används också för lönehantering. Utifrån grundscheman, med kända avvikelser, visar systemet eventuella vakanser och overksam personal under kommande månad. Personalplaneraren ansvarar för bemanning av dessa vakanser. Det går att utföra detaljplaner för nästkommande månad, det går överhuvudtaget inte att se information som ligger längre fram i tiden, vilket begränsar systemets användbarhet för exempelvis semesterplanering. Avvikelserapportering måste göras senast 5 dagar efter månadsslut.

Det är bara personalplaneringen, lönekontoret och turfördelningen som har tillgång till datasystemet, övriga schemaärenden distribueras som utskrifter till berörda. För tågpersonal rapporteras avvikelser direkt till systemet av turfördelningen, för övrig personal på Stockholm Östra lämnas tidrapporter för manuell registrering.

När tåg är försenade får turfördelaren ingen automatisk information om behov av eventuell extrapersonal för kommande avgångar. Oftast fungerar detta dock genom att tågledaren manuellt informerar turfördelningen om situationen.

Inom trafikplanering planerar man tågtrafiken. Här utarbetas tidtabeller, statistik och underlag för passagerarinformationen. Dessutom ligger det på funktionen att planera för trafikändring i samband med banarbeten. Eventuella abonnemangsturer skall också planeras in i den ordinarie verksamheten.

För att få underlag till statistik hämtas information från övervakningssystemet Cactus och ett automatiskt registreringssystem som är installerat i sex vagnar. Detta system som heter ATR registrerar bland annat tid och antal resande. Statistiken sammanställs i månadsrapporter.

Ekonomi- och vagnsavdelningen använder SL Datas datasystem. För ekonomifunktionen används en ekonomimodul för bland annat bokföring.

Vagnsavdelning använder tunnelbanans system, FDS. Där registreras bland annat vagnskilometer och periodiskt underhåll. Alla reparationer noteras dessutom i systemet. Vid tillsyn och underhåll nollställs respektive mätare automatiskt. Rangeringen är en servicegrupp åt trafiken och verkstaden. Till arbetsuppgifterna hör bland annat att byta ut tåg vid behov, då beställer man spårändringar hos trafikledningen. I skötselhallen vid Stockholm Östra genomförs periodiskt underhåll i form av tillsyn, var 2 500e vagnskilometer, städning, yttre tvätt och enklare reparationer.

Till rangeringens uppgifter hör också att planera hur vagnarna går så att behovet av underhåll blir fördelat över veckodagarna. Rangeringen skall alltid veta var varje enskild vagn befinner sig och hur långt varje vagn går varje dygn. Vid Mörby verkstad genomförs underhåll i form av översyn, var 10 000e vagnskilometer, samt något mer omfattande reparationer.

Förutom detta finns det på olika ställen i organisationen persondatorer för det dagliga arbetet. Vissa av dessa har anslutits i någon form av arbetsgrupp (workgroups) men har icke några gemensamma system i övrigt. Det pågår en uppgradering av detta system till ett Windows NT-baserat lokalt nätverk som via fiberoptik är sammanbundet med SL:s övriga lokala nätverk.

Med termen beslutsstödssystem avses en samlingsbeteckning på i grunden ganska olika system. De har samtliga sitt ursprung i de så kallade beslutsstödjande marknadsföringssystem som i princip var anpassade kalkylark för användning i olika marknadssituationer, det som gjorde dessa möjliga var introduktionen av person- och minidatorer. Ur dessa rudimentära applikationer, främst avsedda för simuleringar, har beslutsstödssystemen utvecklats.

Figur 1 visar en schematiskt beskrivning av beslutsstödssystemet. Systemet samlar kontinuerligt in information från företagets olika datasystem, bearbetar och presenterar sedan dessa i överskådlig form. [Personal Nr 10 1994 s 28]

Det finns beslutsstödssystem som vänder sig till olika nivåer i organisationen. De första ansatserna från mitten av åttiotalet döptes till Management Information Systems (MIS) och avsåg främst information till högre chefer [Holmberg 1988]. I dessa system hanterades främst ekonomisk information från månadsrapporter och liknande. Med framväxten av plattare organisationer har också beslutsstödssystem anpassats till verksamhetens förändring. I dag är det vanligaste systemen någon form av Executive Information Systems (EIS), som kan utnyttjas på i stort sett varje chefsnivå i företaget [Orander 1994], och även ända ner till arbetsgrupper. I dessa EIS analyseras i första hand ekonomisk information löpande, där utfall även kan jämföras mot budget eller prognoser.

Som en följd av att systemen har fått karaktären av Everybodys Information Systems har det skett en vidareutveckling till Management Support Systems (MSS), som består av tre delar, se figur 2, dels ett fullständigt EIS dels besluts- och kontorsstöd. Kontorsstödet består framför allt av kommunikationssystem och beslutstödet främst av analys- och presentationssystem [Gibbons et al 1994].

I vardagliga ord är ett beslutsstödssystem en kombination av analys- och presentationsprogram. Själva grundidén är att även datorovana skall kunna ta fram aktuella rapporter utan hjälp från specialister. Systemet som sådant introducerar inte några nya uppgifter i företagets datasystem, allt finns redan där, även om de är utspridda i olika system, varav vissa kanske även i externa databaser. Systemet läser in utvalda data, bearbetar dem och lagrar dem i sin egen databas varifrån fördefinierade eller egendefinierade rapporter sammanställs.

Användarnas behov varierar, försäljningschefen vill kanske veta utvecklingen för en filial, personalchefen önskar få reda på utbildningskostnaderna per anställd, lagerchefen vill se vad som finns kvar i lager i förhållande till den prognostiserade orderingången. Normalt sett finns all information som behövs, men inte samlat på ett ställe. Han som normalt fixar sammanställningarna kan ju vara sjuk! I värsta fall får man en bunt utskrifter från de aktuella systemen, och får ägna helgen åt att manuellt ställa samman uppgifterna i användbar form.

I ett beslutsstödssystem kan varje befattningshavare som regel själv bestämma vilka rapporter som behövs, och enkelt förändra dem. Tillgängligheten på data kan självklart variera med användarens behörighet. Informationen skall kunna presenteras grafiskt på valbar detaljnivå. Om man tar ut en försäljningsrapport uppdelat på distrikt och varugrupper skall användaren själv kunna gå djupare (sk "drill down") för att analysera ett distrikt eller en viss vara i detalj.

Beslutsstödssystemet samlar, oftast med hjälp av batch-körningar, in utvalda data från företagets olika datasystem. Dessa data lagras sedan i beslutsstödssystemets egen databas och utgör underlag för rapporter. Inga data förändras i produktionssystemen.

Arbetet behandlar frågan om val av tänkbara beslutsstödssystem som klarar både operativa beslut och management beslut. Vi har även några konkreta förslag på design av möjliga gränssnitt för just denna verksamhet (bilaga 3, 6 och 7). De ekonomiska aspekterna av att välja mellan olika beslutsstödssystem behandlas inte. Vi behandlar ej heller de mjuka aspekterna av att välja ett lämpligt system, frågor som till exempel support, utbildning och manualer. Ej heller görs någon specifik anpassningsutveckling, eller bedömning av kostnaderna för detta.

När det gäller de informationskrav som företagets ledning och chefer är i behov av, med andra ord rena företagsekonomiska data, har vi enbart fastställt systemtekniska och övergripande specifikationer. Beslutsstödssystem är i grund och botten utvecklade för att arbeta med företagsekonomiska data därför torde det utifrån en systemteknisk specifikation vara relativt enkelt att finna flera tänkbara alternativ. För den operativa verksamheten skall beslutsstödssystemet arbeta med andra typer av data och presentera dessa på ett för verksamheten specifikt sätt. Detta medför att de operativa beslutens krav måste redovisas mer i detalj. Som vi tidigare nämnt i kapitel 1 har vi delat upp redovisningen efter de två huvudområderna, företagsledningen och den operativa ledningen.

För företagsledningsfrågor är bristen att det inte finns några möjligheter för exempelvis trafikchefen att löpande följa upp verksamhet och utfall utan manuella rutiner. Kravet på systemet är att samtliga nyckeltal kan studeras översiktligt eller i detalj med valfri tidsindelning. Data skall kunna presenteras både i form av budget, prognos och utfall. Uppdatering av data skall ske varje dygn.

Tekniska krav som systemet skall uppfylla är förmåga att läsa data från de förekommande miljöerna, UNIX, VAX, IBM och PC samt presentera analyser i Windows-miljö i det kommande nätverket.

De ekonomiska fakta som systemet skall kunna hantera är bland annat balans- och resultatrapporter, med jämförelser mot budget och/eller prognoser, och uppdelat på resultatenheter. Dessa fakta skall även kunna sammanställas och presenteras i form av ekonomiska nyckeltal. Förutom detta skall exempelvis personaldata kunna hanteras. Detta inkluderar till exempel statistik över övertidsuttag eller frånvaro, med möjlighet till uppdelning på personalkategorier. Personaldata inkluderar även lönestatistik och övriga personalkostnader. Dessa skall även kunna ställas i relation till övriga ekonomiska data. Även rena produktionsdata såsom förseningsstatistik skall hanteras av systemet. Samtliga rapporter skall kunna presenteras i en av användaren definierad grafisk form eller tabellform.

Bland övriga ledningsfunktioner finns personal- och trafikplanering samt ekonomi- och vagnsavdelningarna. Gemensamt för dessa funktioner är krav på tillgång till statistik avseende produktion eller ekonomidata för allmän kännedom. Varje enhet behöver dessutom kunna detaljstudera den egna enhetens resultat.

För personal- och trafikplanering behövs stöd för personaladministration, exempelvis schemahantering och närvarorapportering. Trafikplaneringen har dessutom behov av produktionsstatistik och mer detaljerad ekonomisk statistik för utarbetande av tidtabeller. Turfördelningen har behov av realtidsvisning av bemanningssituationen för att så tidigt som möjligt upptäcka frånvaro som påverkar aktuell trafik.

För beslutsstöd i den operativa ledningen möter vi en annan kravbild. Här är problemet att trafikledningen har flera av varandra helt oberoende system, som samtliga bidrar med fakta och/eller kräver åtgärder i den rutinmässiga ledningen av trafiken. Risken för felaktiga beslut bedömer vi som överhängande när trafikledaren har ett 20 tal monitorer att övervaka, samt minst 3 uppsättningar av tangentbord och pekdon att arbeta med, förutom de rent manuella uppgifter som finns på diverse listor och blad.

Med den operativa delen avser vi arbete i tågledningscentralen. Det är här de avgörande besluten för den dagliga produktionen fattas. Tågledaren har en dubbel roll. Dels skall han leda och samordna ett tekniskt system för att med maximal effektivitet prestera högsta möjliga produktion till lägsta möjliga kostnad. Samtidigt skall han säkerställa att samtliga säkerhetskrav infrias.

Ibland måste beslut tas med kort varsel för att inte äventyra säkerhetskraven, det är då viktigt att tågledaren har ett pålitligt och klart beslutsunderlag. Ofta består arbetet av ett mer monotont övervakningsmoment, där kraven på information är helt annorlunda.

Manuella listor och blad skall ersättas med data på skärm, detta kan ske med hjälp av gradvis expanderbara informationsrutor vid tågen i arbetsmonitor för turnummer och personal. Här kan tågledaren få information i valbar detaljnivå om vilken tur som skall bemanna tåget, och vilken person som har den turen just den dagen, inklusive personalens föregående tåg och följande tåg. Man kan även tänka sig möjlighet att komma åt vissa personaldata här, exempelvis telefonnummer. Tågdata skall även innehålla planerat ankomst- resp avgångsspår. Detta innebär att beslutsstödssystemet måste kunna exportera data från i detta fall personal- och bemanningssystem till Cactus.

Turfördelningspersonalen behöver också tillgång till bemanningsdata för respektive tåg enligt denna modell, med tillägg att alla tågförseningar skall utmärkas särskilt.

Beslutsstödssystemet skall kunna läsa data från de plattformar som innehåller de produktionsdata som behövs, nämligen UNIX, PC och IBM, samt kunna presentera i UNIX (trafikledningscentralen) och Windows (turfördelningen). På grund av att detta rör operativa beslut måste systemet kunna arbeta med realtidsuppdateringar, vid förändring i produktionsdata skall systemet automatiskt uppdateras. I trafikledningen skall data kunna exporteras till Cactus för presentation på arbetsmonitorer.

Data behöver enbart presenteras i textform, det är dock önskvärt att det finns grafiskt stöd för dialog- och informationsrutor samt inmatningsformulär som skall användas av turfördelningen för att rapportera förändringar. I den operativa verksamheten finns inget behov av stöd för framtagande av användardefinierade rapporter.

Vid eventuella spårändringar på Stockholm Östra skall passagerarinformationen förändras automatiskt genom överföring av data från tågledningssystemet till informationssystemet. Informationssystemet är nu tidsstyrt, det bör vara händelsestyrt, förändringar på informationsmonitorerna skall styras av tågrörelser ej av klockan. Eventuella manuella noteringar och ändringar skall kunna utföras från arbetsmonitorerna.

Användargränssnitt i arbetsmonitorer bör anpassas för inlägg av varning för eldistributionsstörningar. Det bör sedan vara tågledaren som väljer att hämta eldistributionsdata från separat monitor eller lägga in det i sin arbetsmonitor. Även det nya radiosystemet skall kunna manövreras från arbetsmonitor om operatören så väljer.

Utifrån den analys som vi gjort under 3.2 och 3.3 ovan kan vi så fastställa ett antal krav ett beslutsstödssystem måste eller bör uppfylla för att kunna användas både av företagsledningen och i tågledningscentralen. Dessa krav graderas i två nivåer, utslagsgivande krav och önskemål. De utslagsgivande kraven är krav som måste uppfyllas för att ett system överhuvudtaget skall kunna användas. Önskemål är krav som bör uppfyllas, det tillför systemet ett mervärde.

Med utgångspunkt från behovsanalysen ovan redovisas kraven nedan grupperade i sex huvudgrupper, klienter, plattformar som skall kunna läsas från, export av data, uppdatering av data och presentation i andra system, presentation av rapporter och hantering av olika typer av data. Kraven presenteras i fetstil och punktmarkerat. Se även figur 4, där kraven redovisas i en matris.

Eftersom trafikledningen arbetar i UNIX-miljö, och företagsledningen kommer att anslutas till ett PC-nätverk måste beslutsstödssystemet ha klienter för båda dessa miljöer. Detta även om beslutsstödssystemet rent fysiskt bara finns på den ena plattformen. Detta leder till att följande krav är utslagsgivande:

För att fungera skall beslutsstödssystemet kunna läsa data från olika system. Som regel kan ett beslutsstödssystem lästa de vanligaste databasformaten, oberoende av i vilken plattform data är lagrade. Produktionsdata lagras i detta fall i UNIX-, PC-, VAX- och IBM-miljö. De utslagsgivande kraven blir därför:

Det finns ett behov av att vissa data skall kunna läsas i ett system och sedan delges ett annat system, exportera data. Exempel på detta är inläsning av tågdata från Cactus, som vid förändrade avgångsspår eller tider måste exporteras till Linarias passagerarinformation för publikation på informationsmonitorer. Detsamma gäller vid avgångstillfället när informationen skall tas bort från monitorerna. Detta innebär att det utslagsgivande kravet blir:

För att vara användbart i trafikledningen måste beslutstödssystemet kunna uppdateras kontinuerligt, realtid, och kunna lägga ut presentationer i Cactus. Denna presentation måste vara transparent, och får ej ändra Cactus egna data. De system som data skall importeras till, exempelvis informationssystemet för passagerare, måste dock kunna förändras av beslutsstödssystemet. Alltså skall följande utslagsgivande krav ställas på systemet:

Eftersom användare arbetar olika, och arbetssättet dessutom varierar från en uppgift till annan är det ett utslagsgivande krav att användaren kan välja presentationsform, grafiskt eller i tabellform beroende på vad som presenteras eller användarens preferenser. Det är även viktigt att användaren på ett enkelt sätt spontant kan ta fram en rapport, ad-hoc, förutom de som definierats i systemet. Det vore därför önskvärt om varje användare efter en kortare introduktion själv kan anpassa rapporterna efter de egna behoven, och lagra dessa i form av en egendefinierad rapporter:

Det är vidare utslagsgivande krav på att beslutstödssystemet skall kunna hantera data av olika typ, ekonomiska, personalrelaterade eller rena produktionsdata:

De system som undersökts har vi valt med utgångspunkt från den referenslitteratur vi studerat. Några av de där nämnda systemen har utgått och därför inte behandlats. Vissa system har omarbetats, i dessa fall har vi behandlat de nya versionerna. De utvalda systemen torde vara ett representativt urval av på marknaden förekommande beslutsstödssystem, allt från helt färdiga till utvecklingsverktyg.

Den översiktliga beskrivningen av varje beslutsstödssystem utgår från de krav som vi har tagit fram i kapitel tre. Vi redovisar här de krav som respektive system eventuellt inte uppfyller.

Detta är ett system som är baserat på Windows-klienter, det kan läsa de flesta förekommande databasformat oberoende av den fysiska plattformen. Användaren skall själv kunna definiera sina rapporter och spara definitionerna för senare användning.

Eftersom detta system saknar klient för UNIX och inte kan uppdateras i realtid kan det inte rekommenderas för Roslagsbanans operativa verksamhet.

Pilot är ett system med Windows-klienter. Systemets server ligger i Windows-miljö, förutom ett analysverktyg vars server även kan ligga i andra miljöer. Systemet byggs upp med moduler för de funktioner man har behov av, om man behöver utveckla egna rapporter lägger man till en modul som heter Pilot Designer.

Systemet kan läsa in data från olika plattformar så länge som ifrågavarande databasformat kan hanteras av Pilot. Eftersom det saknar möjlighet till realtidsuppdatering och UNIX-klient kan detta ej heller användas i tågledningscentralen.

Cross Target har klienter för Windows och Macintosh miljö, även blandade miljöer. Det kan läsa data från samtliga plattformar som används inom Roslagsbanan. Den nya versionen, baserad på Java gör det möjligt att utföra interaktiva analyser i ett eventuellt internt intranet. [Hellberg Lann 1996]

Data manipuleras med en indexeringsteknik som transformerar produktionsdata från befintliga datafiler till en flexibel flerdimenstionell modell, denna kan ligga på en server eller i en lokal arbetsstation, användarens krav bestämmer detta. Denna lösning medger en fördelning av belastning mellan server och klienter i företagets nätverk. En modell som bara behövs hos en befattningshavare behöver inte belasta de gemensamma resurserna. Rapporter som behöver delas kan ligga i servern. Dock har den inte något stöd för realtidsuppdatering. Det saknas också klient för UNIX-miljö. Alltså kan Cross Target ej användas för operativt beslutsstöd.

För detta system finns klienter både för Windows och UNIX. Det kan läsa data från minst 16 olika databashanterare.

Gränssnittet är grafiskt med möjlighet att presentera data i tabell- eller diagramform. Gränssnittet tillåter direktmanipulering, man kan peka och klicka för att arrangera och strukturera presentationer. Det krävs inga programmeringskunskaper för att formulera frågor och rapporter eller exportera till andra system. Alla krav som vi ställt upp för den operativa och administrativa verksamheten uppfylls av GQL. Detta uppfyller alltså samtliga utslagsgivande krav.

ASW arbetar med en AS/400 DB2 relationsdatabas. ASW kan läsa data från i stort sett vilket produktionssystem som helst, oberoende av plattform. Dock finns det enbart klienter för Windows (inklusive NT och Windows 95), Mac eller OS2.

För att kunna exportera data behövs ett tillägg, i och för sig kan man med en applikation läsa direkt från ASWs egen databas. Det finns ej heller något stöd för realtidsuppdatering av databasen. För bearbetning av icke operativ information finns stöd för grafisk presentation.

Källdata kan vara både på transaktionsnivå eller summerade data. Efter inläsning lagras data enligt fördefinierade dimensioner. Man kan välja att lagra data exempelvis dagligen för senaste månaden, och per vecka för de senaste månaderna för att slutligen lagra per månad för tidigare år. Därigenom kan man genom att rensa bort med tiden onödig information förbättra prestanda. Systemet är ett färdigt system, inte ett utvecklingsverktyg, vilket gör att det går att installera utan programmering.

Till viss del skulle detta system passa för managementsyften, man kan läsa in data från de förekommande systemen, och presentera i den kommande PC-miljön. Dock går det inte att använda i tågledningen eftersom realtidsuppdatering och UNIX-klient saknas.

Focus utvecklades ur ett 4GL-verktyg för applikationsutveckling, och används främst för att utveckla anpassade EIS system (Executive Information Systems). Eftersom Focus kan läsa och arbeta med mer än 60 olika databasstrukturer kan snart sagt varje verksamhet utnyttja verktyget, oberoende av om data finns i olika format eller på olika plattformar.

Förutom de traditionella diagrammen kan man presentera data i geografiska kartor, med möjlighet att omorganisera eftersom verksamheten utvecklas, utan krav på att man måste gå tillbaka och konstruera om alla berörda presentationer. Det finns även stöd för intranetlösningar, WebFOCUS.

Focus finns enbart för Windows plattform, dock kan det läsa samtliga olika produktionssystem. Det skulle kunna passa för företagsledningens och turfördelningens behov, dock inte för de operativa beslutsstödet i tågledningen.

SAS Systemet finns för samtliga plattformar som behövs och kan läsa från samtliga system på Roslagsbanan. Det är i stort den aktuella verksamhetens krav som styr applikationsutvecklingen, man utgår inte från färdiga moduler utan utvecklar det som behövs för varje aktuellt företag. Utvecklaren bestämmer fritt vad för funktioner som skall användas.

Systemet är närmast att betrakta som ett utvecklingsverktyg där de individuella kraven styr utformningen. Man arbetar med ett så kallat Data Warehouse. Detta innebär i korthet att data läses från produktionssystemen, tolkas och lagras i systemet. Från detta datalager produceras sedan information, se figur 3.

Det finns stöd för realtidsuppdatering och export av data till andra system, vilket är ett krav för den operativa delen i tågledningen. Eftersom detta system uppfyller samtliga våra krav anser vi det vara värt att studera vidare.

Detta system kännetecknas av att det är ett nyckelfärdigt system, det vill säga det är lätt att komma igång, med färdiga moduler främst tänkt att kunna användas av dem som inte har så stor vana från datorer och i grundutförande för rena PC-nätverk. Det går att med tillägg läsa data från andra plattformar.

Användaren kan själv utveckla egna rapporter med systemet, ungefär som man gör en presentation i ett presentationsprogram. Rapportformatet kan sparas för senare bruk.

Eftersom det inte finns någon UNIX-klient kan det inte användas i tågledningen, och för företagsledningens bruk kan det enbart användas med de tilläggsmoduler som finns för läsning av övriga plattformar.

Figur D. Jämförelsematris

Måste ha/kunna - Är faktorer som vi bedömer vara kritiska, det vill säga faktorer som absolut måste infrias för att ett system över huvud taget skall komma i fråga för närmare undersökningar. En så kallad knockout faktor.

Bör finnas - Är faktorer som inte är nödvändiga, men som tillför mervärde till användbarheten.

Ja - Är krav som uppfylls

Nej - Är krav som inte uppfylls.

(Ja) - Är krav som kan uppfyllas med tilläggsmoduler eller dylikt.

Slutsatserna kommer i huvudsak att behandla den operativa ledningen, som är vår huvudinriktning. Företagsledningens och övriga funktioners behov anser vi kunna bli tillfredsställda av samtliga studerade system. Våra rekommendationer som rör saker utanför det egentliga arbetet finns i bilaga 8.

Vår inriktning har varit undersöka om ett beslutsstödssystem skulle kunna användas för att samla in informationer som finns i de olika nuvarande systemen. Detta för att kunna presentera dessa data i en översiktligare form och underlätta informationsutbytet mellan olika funktioner.

Som exempel på detta kan vi nämna tågledningscentralen, där information om elövervakningen precis som nu mycket väl kan ligga i ett separat system, dock vill vi att larm skall speglas in i arbetsmonitorn. Det bör sedan vara upp till tjänstgörande tågledare att välja om detaljer skall inhämtas från övervakningssystemets egen monitor eller om detaljerna skall tas fram på arbetsmonitorn.

För att inte behöva leta i manuella system skall bemannings- och tågdata kunna hanteras via Cactus. Det skall på ett enkelt sätt gå att få fram vilka som skall bemanna ett visst tåg. De tågdata som nu hanteras manuellt, avprickning av tågnummer och ankomst respektive avgångsspår vid Stockholm Östra skall kunna hanteras på samma sätt.

Det skall inte vara nödvändigt att manuellt behöva ändra i ett system på grund av att man utfört något i ett annat system. Ett förfarande som medför risk för inkonsistenta data. System som är beroende av andra system bör kunna fjärruppdateras.

För att möjliggöra en bättre arbetsmiljö i tågledningscentralen måste de nuvarande datasystemen på något sätt integreras. Vid en dylik integrationsprocess kan man som bieffekt även uppnå ytterligare rationaliseringar även för andra funktioner i företaget.

Vi finner att ett beslutsstödssystem skulle kunna utnyttjas av företaget till en mer effektiv ledning och planering. Både de kvalitativa och kvantitativa beslutsunderlagen skulle förbättras med användning av ett beslutsstödssystem.

Även vissa stabsfunktioner skulle med all säkerhet bli effektivare med hjälp av ett beslutsstödssystem.

Vi anser att GQL och SAS Systemet är möjliga alternativ av färdiga system som skulle kunna användas både för management och operationella beslutsstöd. De uppfyller båda samtliga de utslagsgivande kraven och är lämpliga kandidater för en vidare utvärdering. Vid en sådan utvärdering skall även mjuka faktorer såsom support, utbildning och manualer beaktas. En självklar del av den vidare utvärderingen är jämförelser av behovet av anpassningsutveckling.

SAS Systemet är det samlade begreppet för flera mjukvarukomponenter, där applikationens behov styr vilka komponenter som skall användas.

Det som är utmärkande för ett Data Warehouse är att ingående data har bearbetats för att uppnå kompatibilitet, exempelvis kan man läsa in datumuppgifter i olika format och omvandla dem till ett gemensamt format. Dessa data kan sedan användas till att presentera en samlad information från data som har sitt ursprung i flera av varandra oberoende datasystem.

Vid utvecklande av en applikation med SAS Systemet använder man de moduler som behövs, det finns bland annat moduler för att lösa olika typer av databaser, för olika typer av presentationer. Vid utvecklingsprocessen bestäms vilka data som behövs, vart de finns och hur de behöver transformeras. Utgångspunkten för vilka data som behövs är de informationsrapporter man önskar ta ut.

SAS Systemet stödjer samtliga miljöer som behövs för Roslagsbanan, både vad det gäller inläsning av data och presentation av informationen. Det har också stöd för realtidsuppdatering och kan exportera information till andra system.

Även GQL är uppbyggt kring ett Data Warehouse och med olika moduler där kraven på applikationen bestämmer vilka moduler som behövs. Det finns bland annat moduler för olika typer av diagram, inklusive tredimensionella, och tabeller.

Grundidéen har varit att göra ett system som är enkelt för informationsanvändaren att tillgodogöra sig. Det är till exempel möjligt att definiera en ny rapport genom att peka på de data man vill använda och dra det till den nya rapporten. För att delge andra befattningshavare är det inte nödvändigt att skriva ut den egna rapporten, det kan bifogas ett elektroniskt brev.

Det finns stöd för samtliga plattformar som behövs. Det finns ett enhetligt gränssnitt för de olika plattformarna. I och med detta kan applikationer flyttas från en plattform till en annan, och användaren känner igen sig.

SL Tåg AB Organisationsschema [Egen bearbetning från SL Tåg AB, Företagsmål, Stockholm 1995] Vi behandlar i uppsatsen i första hand de delar som är markerade med dubbel ram. De funktioner som är streckade behandlas över huvud taget inte alls.

Exempel på startbild i beslutsstödssystem, ASW - EIS [http://www.ibs.se/products_sv.html] startbilderna kan se olika ut, detta är endast ett exempel.

Exempel på skärmbild vid påloggning till Beslutsstödssystemet.

Exempel på personalrapport

Exempel på förseningsrapport

Endast tillgänglig i den tryckta utgåvan

Endast tillgänglig i den tryckta utgåvan

Endast tillgänglig i den tryckta utgåvan

Endast tillgänglig i den tryckta utgåvan

Vi redovisar i bilaga 3 förslag på hur en tänkbar design av beslutsstödssystemet för företagsledningen kan göras. Detaljerad utformning för respektive funktion skall utarbetas i samråd med användarna.

För tågledningscentralen är det viktigt att varje förändring görs i samarbete med tågledare. Grunden för utformningen måste vara rätt information vid rätt tillfälle. För mycket information kan resultera i att viktig information drunknar i sidoinformation. Vi redovisar i bilaga 6 några exempel på hur denna utformning kan ske. Dessa exempel skall ses som ett första utkast, som redovisar en princip för utformningen snarare än ett konkret förslag.

Ett eventuellt blivande beslutsstödssystem skall innehålla ett antal funktioner för stöd till den operativa beslutsfattaren, tågledaren. Dessa funktioner har det gemensamma att de skall presentera information i tågledarens arbetsmonitor. Denna information bygger på data från de idag helt åtskilda datasystemen som insamlats och bearbetats av beslutstödssystemet.

På tågdatanivå behöver tågledaren tillgång till bemanningsdata, dessa skall kunna tas fram vid behov. De bör utformas som någon form av dialogrutor där operatören kan välja lämplig detaljnivå. De nuvarande tågdata skall kompletteras med uppgifter om planerat ankomst- respektive avgångsspår, samt möjlighet att ändra dessa. Det skall även framgå vilket tågnummer tågsättet får när det vänder vid ändstation, och även detta skall kunna ändras vid behov.

Förseningsdata skall även vara tillgängligt från turfördelningen för att underlätta omplacering av tågpersonal vid eventuella förseningar (bilaga 7).

För att göra arbetet i tågledningscentralen mer rationellt måste beslutsstödssystemet kunna upptäcka eventuella spårändringar och vidarebefordra dessa data till informationssystemet för passagerarna. Detta för automatisk uppdatering. Larm från eldistributionssystemet skall kunna läggas in i arbetsmonitor, och tågledaren kan sedan välja om detaljerna skall tas upp i arbetsmonitorn eller om han vill använda elsystemets egen monitor.

När det gäller det nya radiosystemets bör man studera arbete med systemet när det kommit i drift. Vissa faktorer talar för någon form av integrering i Cactus, framförallt för att undvika ytterligare fysiska kontroller såsom mus och tangentbord. Andra faktorer talar mot en integration, Cactus skärm kanske blir för detaljrik och på grund av detta svår att arbeta med. Det finns också säkerhetsaspekter på att integrera för många system, som kan hanteras med att enbart tillåta andra system att öppna ett fönster i Cactus.

En annan framkomlig väg vore att utnyttja Cactus som samordnande system i tågledningen och använda ett färdigt standardsystem för beslutsstöd i övriga delar av verksamheten. Cactus har möjlighet att övervaka eldistributionssystemet och sköta passagerarinformationen. Det nya radiosystemet skulle också kunna manövreras från Cactus, övrig administrativ information kan visas i ett separat fönster i Cactus.

Nuvarande personaladministrationssystem har visat sig vara svårarbetat. Uppgifter presenteras i koder, till exempel betyder kod 9910 ‘fridag’, samt att det saknas fält för kommentarer. En konsekvens av nuvarande systemdesign är att uppgifterna förs över manuellt till lösblad, för att få bättre överblick.

Det finns alltså ett behov av mer rationell personaladministration, vårt förslag är att byta ut nuvarande personaladministrativa system. Vi är medvetna om att det har den förtjänsten att det innehåller grundläggande tjänstgöringdata och beräkningsmodeller speciellt anpassade till verksamheten. Till dess nackdel måste man nämna dess något otidsenliga utformning med begränsade möjligheter till statistikbehandling och översikt av data.

Vi föreslår att det nya systemet skall innehålla en inskrivningsrutin där personalen själv kan skriva in sig vid en terminal vid ankomst till arbetsplatsen. Därigenom kan tågledningen automatiskt få en varning om den personal som skall bemanna ett tåg ej har skrivit in sig. Genom införande av databearbetning av personalinskrivning kommer personalplaneringen att få ett tillförlitligare statistikunderlag. I nuvarande system måste man skriva ut data i ett system (personalplanneringen) och sedan manuellt registrera dessa data i ett annat (Excel kalkylark) för att bearbeta och ta fram statistik.

Närvararapportering skulle även kunna införas på andra avdelningar, till exempel Mörby verkstad, och därigenom ytterligare minska risken för felregistrering av manuella underlag enligt nuvarande rutiner.

Som bieffekt till ett modernare personaladministration kan även personalen ges möjlighet att själva skriva ut sina scheman för kommande tjänstgöringsperioder. Man kan även tänka sig att hantera ansökningar om tjänstledighet och semester elektroniskt i ett dylikt system.

Som kvalitetshöjande åtgärd bör man också studera möjligheten till införande av någon form av automatiska högtalarutrop till passagerare vid förseningar och spårändringar. Behoven av högtalarutrop är som störst när tågledaren har minst tid att utföra dem.