DSB's mobilprojekt: SAP- og C#-folk talte sort til hinanden

Det var ikke tekniske problemer, men nærmere besvær med udviklersamtalen, der gav de største udfordringer for udviklerne af DSB Firsts løsning til online indrapportering af materielfejl, Q Rapport.

Udvikler på projektet Søren Rindal Nielsen fortæller her, hvordan systemet blev implementeret på trods af store problemer med kommunikationen mellem SAP-folkene og C#-udviklerne.

• Hvad går projektet ud på?*

Togførerne skal kunne indrapportere fejl og mangler på materiellet i togene, mens de kører i toget.

Det kan være fejl, hvor en dør binder, eller et sæde er gået i stykker, men det kan også være en klargøringsfejl, hvor der for eksempel mangler toiletpapir i en af vognene.

Vi haft et system til det i mange år, men det har hidtil været baseret på offline PDA'er. Da foregik det på den måde, at togføreren kunne indtaste oplysningerne i PDA'en, men fordi de ikke kunne meldes ind online fra toget, kom oplysningerne ofte 6-8 timer forsinket ind til værkstedet. Og så bliver beskeden om, at der ikke er papir på toilettet, hurtig for gammel. Der betyder det meget, at man kan reagere hurtigt.

Med den nye løsning, Q Rapport, kan togføreren indrapportere oplysningerne online fra mobiltelefonens browser, så værkstedet modtager fejlmeldingen med det samme, og passagerne i sidste ende oplever en bedre standard i toget.

Q Rapport er udrullet i januar i forbindelse med lanceringen af DSB First (kystbaneområdet og Sverige, red.)

Hvad er din rolle i projektet?

Jeg har lavet nogle af kravspecifikationerne på Q Rapport, og så har jeg kodet en del af datavejen. Jeg har arbejdet sammen med anden udvikler, som har stået for browserdelen. I alt har vi brugt cirka 500 timer på at implementere løsningen.

Hvilken teknologi er det baseret på?

Frontend'en og backend'en i Q Rapport er baseret på .Net og programmeret i C#. De er hægtet sammen på den måde, at frontend'en laver et webservice-kald over mod backend'en, som så producerer en fil med oplysningerne om fejlmeldingen. Det er en klartekst-fil i fastbreddeformat, lige som man havde det for tyve år siden. Og det er så den, som SAP-systemet på værkstedet indlæser. DSB er en SAP-virksomhed, som bruger systemet til alt fra HR og indkøb til at registrere, hvad der sker med togene.

Overordnet består Q Rapport af tre dele, som er en frontend, en backend og SAP-systemet på værkstedet.

Frontend'en er en ret simpel webside, som togføreren tilgår gennem browseren i mobiltelefonen. Her kan man indtaste et materielnummer og en lokation, så man kan sige præcis hvor i toget, fejlen befinder sig. Togføreren angiver en kategori og to delkategorier og skriver eventuelt også en tekstkommentar. Frontend'en er holdt helt enkel, fordi det skal virke i den browser, telefonen kommer med. Samtidig kan forbindelsen i toget være ret så dårlig i visse områder, så der bruges ikke billeder eller lignende, ganske enkelt for at spare bits.

Backend'en er et system, som DSB bruger til alt muligt. Vi kalder det Driftsteknisk Opfølgning, og det er et system, som fortrinsvis indeholder hændelser på driften, forsinkelser og nedbrud og så videre. Det er så integreret op mod SAP. Q Rapport er stort set samme slags system, og derfor har man samlet datavejen her, hvor fejlmeddelelserne afkodes og sendes til værkstedet. Q rapport er så en del af Driftsteknisk Opfølgning og fungerer som en automatiseret vej gennem det, så alle de ting, som det normalt er mennesker, der sidder og gør, foretages automatisk med Q Rapport.

Q Rapport er en ren DSB-First-løsning, hvilket hænger sammen med DSBs infrastruktur. Det interessante er, at Q Rapport, som er online, er billigere end resten af DSBs løsning, som er baseret på offline synkronisering.

Hvilke problemer har I oplevet?

Vi har ikke oplevet nogle kodetekniske problemer, men mere problemer af praktisk karakter.

Arbejdet C#-udviklerne og SAP-udviklerne imellem har været to forskellige kulturer, der mødes. C#-udviklerne kan sagtens snakke om systemet indbyrdes, og det samme kan SAP-udviklerne, men når de to mødes, er der en kulturforskel, som gør, at man kan bruge utroligt lang tid på at forstå, hvad hinanden vil.

Det er et spørgsmål om, at man har svært ved at hyre faste SAP-folk. De er meget mere projektorienterede, hvor de er der i en periode, og så er de væk.

Det giver sig udtryk i, at man mangler ord over for hinanden, fordi alt det, vi C#-udviklere opfatter som nøgleord i vores verden, har en anden nuance i SAP. Vi har oplevet, at vi ofte har brugt lang tid på at diskutere et problem, indtil der er en, der siger, 'nå, var det bare det, I ville?'.

Det kan for eksempel være nuanceforskelle i den måde, materialenummeret er repræsenteret. Hos os er de fire cifre, og i værkstedet hos SAP-folkene er det tolvcifret.

Det gælder selvfølgelig begge veje, og SAP-udviklerne har det på samme måde over for os. De ser tingene i deres kode, og vi ser tingene i vores. Med tiden udviskes kulturforskellen lidt, men i sin essens består den.

Derudover har vi også haft problemer med, at mobilforbindelsen forsvinder i visse områder. Som det er lige nu, ved togføreren, hvor på strækningen der udfald på forbindelsen, så han ikke sender på det tidspunkt. Derfor arbejder vi hen mod en Occasionally Connected Application, som er netværksopmærksom. Det er altså en mellemting mellem en synkroniseringsløsning og en onlineløsning, som tjekker netværket status og først sender af sted, når der er forbindelse.

Hvilke gode råd kan du give videre?

Det er helt basalt omkring systemudvikling, at man skal overveje integrationerne først. Hvad er det, der skal forbindes til hvad i systemet? Det er der, udfordringen ligger.

Ellers risikerer man, at man har lavet et system, hvor de enkelte stumper virker fint men ikke ramt hinanden, så det samlede system ikke virker og derfor bliver dyrere i sidste ende.

Og så er det vigtigt at erkende på tværs af de forskellige kulturer, at man er sammen om opgaven og virkelig sikrer sig, at man har forstået hinanden. Det er vigtigere end noget andet.