Autor Thema: Über das ewige Scheitern der Fahrgastinformation  (Gelesen 1568959 mal)

0 Mitglieder und 2 Gäste betrachten dieses Thema.

hema

  • Geschäftsführer
  • *
  • Beiträge: 16386
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #570 am: 24. Mai 2015, 19:31:39 »
Aber das RBL wurde in der Wiener Entwicklungs- und Einführungsphase eh jahrelang von einem jungen Gartenbau-Ingenieur und Tulpenexperten mit brauchbaren MS-Office-Kenntnissen betreut und begleitet! Auch zwei, drei Jahre Betriebserfahrung am Schreibtisch konnte er schließlich mitbringen. Ist ja nicht so, dass der Betrieb da irgendwelche Leute in entscheidende Funktionen einsetzt die mit der Materie und den Internas nicht vertraut sind!    8) >:D
Niemand ist gezwungen meine Meinung zu teilen!

Sonderzug

  • Fahrer
  • ***
  • Beiträge: 272
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #571 am: 24. Mai 2015, 20:16:26 »
Die Fehler des Wiener RBL liegen zu hundert Prozent sicher nicht an der deutschen Software. Und auch wen man es nicht glauben will, sooo kompliziert ist so ein RBL-System softwareseitig gar nicht, komplex sicher, aber ansonst eigentlich eher simpel strukturiert.

Genau  :fp: Leider hast du keine Ahnung, warum das System so oft ausfällt, die letzten 10 male bz. waren es immer Fehler der deutschen nach Updates.

@ 13er Und was soll der Chef von denen schon sagen, nein Hr 13er ... unser Produkt ist immer das Beste schuld san natürlich die Wiener.

Man kann alles besser machen, nur eine Frage des Geldes und beim RBL hatte man am Anfang ein Basisprogramm welches aber schnell an der Grenze war. Die Wiener Linien wollten immer mehr, was man erst Programmieren musste, so hat man es immer wieder erweitert mit Updates und Schnittstellen. Mittlerweile ist es so umfangreich das die Fehlersuche halt dauert.

13er

  • Verkehrsstadtrat
  • **
  • Beiträge: 27735
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #572 am: 24. Mai 2015, 20:51:10 »
@ 13er Und was soll der Chef von denen schon sagen, nein Hr 13er ... unser Produkt ist immer das Beste schuld san natürlich die Wiener.
Ja, schon klar, das wird er nicht sagen. Aber ich habe trotzdem das Gefühl, dass es nicht (nur) am Hersteller liegt. Wenn ständig nach Updates etwas nicht funktioniert, dann muss das nicht unbedingt heißen, dass das Programm so schrottig ist, sondern es kann auch daran liegen, dass das eigene System bereits dermaßen verfahren ist, dass die Software da halt nicht mitkommt. Die Firma kann das auch nur unter Idealbedingungen testen. Und wie Tatra schon richtig erwähnt hat, gäbe es dafür ja Testsysteme, auf denen man Updates zuerst ausprobiert. Kein seriöser Softwareentwickler aktualisiert einfach so einen wichtigen Server und schaut danach, was nicht geht, sondern probiert es zuerst auf einem identischen Testsystem aus, damit das Update am Produktionssystem dann im Idealfall in ein paar Minuten erledigt ist.

Andererseits habe ich einen kleinen Einblick in die Software bekommen und das ist einfach ein riesiger Stapel Java-Scheiße, ein Haufen auf dem anderen. Genau so, wie man halt vor 10-15 Jahren programmiert hat...
Mit uns kommst du sicher... zu spät.

Sonderzug

  • Fahrer
  • ***
  • Beiträge: 272
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #573 am: 24. Mai 2015, 21:07:56 »
@ 13er Und was soll der Chef von denen schon sagen, nein Hr 13er ... unser Produkt ist immer das Beste schuld san natürlich die Wiener.
Ja, schon klar, das wird er nicht sagen. Aber ich habe trotzdem das Gefühl, dass es nicht (nur) am Hersteller liegt. Wenn ständig nach Updates etwas nicht funktioniert, dann muss das nicht unbedingt heißen, dass das Programm so schrottig ist, sondern es kann auch daran liegen, dass das eigene System bereits dermaßen verfahren ist, dass die Software da halt nicht mitkommt. Die Firma kann das auch nur unter Idealbedingungen testen. Und wie Tatra schon richtig erwähnt hat, gäbe es dafür ja Testsysteme, auf denen man Updates zuerst ausprobiert. Kein seriöser Softwareentwickler aktualisiert einfach so einen wichtigen Server und schaut danach, was nicht geht, sondern probiert es zuerst auf einem identischen Testsystem aus, damit das Update am Produktionssystem dann im Idealfall in ein paar Minuten erledigt ist.

Andererseits habe ich einen kleinen Einblick in die Software bekommen und das ist einfach ein riesiger Stapel Java-Scheiße, ein Haufen auf dem anderen. Genau so, wie man halt vor 10-15 Jahren programmiert hat...

Dein letzter Satz sagt alles dazu.

Es sind mittlerweile soviele Schnittstellen und Erweiterungen, dass schon bei Updates seitens der Deutschen auch auf gewisse Schnittstellen vergessen wurde und bis der Fehler dann gefunden wurde dauerts.

Das von Tatra angesprochene Verfahren wird jetzt zum Glück bei neuen Programmen praktiziert. Aber wie schon gesagt das Programm ist so oft erweitert worden und angepasst worden das es leider auch sehr komplex ist und es keiner mehr ausser den jetzigen Anbieter mehr angreifen will.

Man hat damals jene Programme welche es gegeben hat angeschaut und dieses wurde als am besten geeignet verkauft. Zeiten ändern sich sowie die Anforderungen auch.
Siehe Ulf was damals innovativ war mangels anderer Vergleichsanbieter ist heute Wartungsintensiv. Aber auch da siehe Bombardier ist man neue Wege gegangen, nur dauert einiges in so einem Unternehmen leider länger.

Linie 41

  • Geschäftsführer
  • *
  • Beiträge: 11667
    • In vollen Zügen
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #574 am: 25. Mai 2015, 09:14:34 »
Andererseits habe ich einen kleinen Einblick in die Software bekommen und das ist einfach ein riesiger Stapel Java-Scheiße, ein Haufen auf dem anderen.
Muahahahahaha... Genau so, wie in dem Projekt, in dem ich gerade arbeite.

P.S.: Real programmers program C in any language.
Ich verstehe das Konzept dahinter nicht und bin generell dagegen.

HLS

  • Referatsleiter
  • *
  • Beiträge: 9640
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #575 am: 25. Mai 2015, 10:43:03 »
@Sonderzug: So ein System lasse ich aber auch nicht von einem Hobby-Tüftler betreuen, sondern suche mir eben Fachpersonal. Klar das dieser sich nicht nur mit dem standart Einstiegsgehalt abspeisen läßt, wenn er am freienn Arbeitsmarkt fast aussuchen kann was er verdienen will.

Es kommt also wieder zu dem, was Hema, ich darf zitieren,
Aber das RBL wurde in der Wiener Entwicklungs- und Einführungsphase eh jahrelang von einem jungen Gartenbau-Ingenieur und Tulpenexperten mit brauchbaren MS-Office-Kenntnissen betreut und begleitet! Auch zwei, drei Jahre Betriebserfahrung am Schreibtisch konnte er schließlich mitbringen. Ist ja nicht so, dass der Betrieb da irgendwelche Leute in entscheidende Funktionen einsetzt die mit der Materie und den Internas nicht vertraut sind!    8) >:D
schrieb.
Es gibt ja ähnliche Probleme auch immer wieder beim Hastus und dem Selfservice, bei letzterem meine vor nicht all zu langer Zeit einer zu mir, dass dieses Program weit weniger kompliziert ist als Java und das, so sagte man mir, wird den Studenten schon in den ersten Semestern beigebracht.
Jetzt frage ich mich also schon, wenn das jeder erste/zweit Semestler packt, warum nimmt man sich dann nicht einen Stdenten, der könnte es vermutlich schneller und besser beherschen.
Es gibt aber eh unseren 13er, der könnte das vielleicht besser erklären als ich, da für mich EDV nicht unbedingt das Thema Nummer 1 ist.
"Grüß Gott"

Ich fühle mich nicht zu dem Glauben verpflichtet, dass derselbe Gott, der uns mit Sinnen, Vernunft und Verstand ausgestattet hat, von uns verlangt, dieselben nicht zu benutzen. Dieter Nuhr

haidi

  • Geschäftsführer
  • *
  • Beiträge: 14475
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #576 am: 25. Mai 2015, 13:49:32 »
Die nötige Software zu beherrschen ist durchaus notwendig, aber wichtiger ist es, die Probleme zu erkennen, die Sache zu durchschauen und zu verstehen, worum es dabei geht. Programmieren selbst kann dann fast ein Affe.
Microsoft is not the answer. It's the question and the answer is NO.

invisible

  • RBL-Disponent
  • ***
  • Beiträge: 1577
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #577 am: 25. Mai 2015, 15:10:41 »
Die nötige Software zu beherrschen ist durchaus notwendig, aber wichtiger ist es, die Probleme zu erkennen, die Sache zu durchschauen und zu verstehen, worum es dabei geht. Programmieren selbst kann dann fast ein Affe.

Ganz so ist es dann auch nicht. Es schadet keineswegs, wenn der Programmierer und der Softwarearchitekt einen Plan davon haben, was die Software letztlich tun soll. Dieser wird nur meist eine andere "Sprache" als die Anwender sprechen um das weltliche Problem in die abstrakten Konzepte einer Programmiersprache zu gießen; für die "Übersetzung" der Anforderungen ist das Projektmanagement zuständig - das ist also ebenfalls ein sehr kritischer Punkt.

Nun gehe ich allerdings davon aus, dass der Softwarehersteller durchaus bereits Erfahrung im ÖV-Bereich hat, also - abgesehen von einigen Wienerischen Fachausdrücken - nicht unbedingt aneinander vorbeigeredet wurde.
Dazu kommt, dass in Wien ja wie bereits angesprochen nicht nur das RBL Probleme macht, sondern auch vergleichsweise simple Systeme wie das Hastus. Das legt dann doch den Verdacht nahe, wo das Problem eher zu suchen ist.

Ich weiß nicht, wer das System bei den WiLi betreut und welchen Hintergrund er hat. Aus der Praxis vermute ich mal, dass es sich letztlich um einen Endanwender mit ein wenig Zusatzausbildung handelt. Und *das* könnte durchaus die Wurzel des Übels sein. Es hat schon einen Grund, warum die Systemadministratoren (zumindest für etwas komplexere Systeme) sinnvollerweise eher aus dem Software-Bereich kommen sollten: sie müssen im Grunde die ähnlichen Gedankenschritte wie die Softwareentwickler machen, um konkrete im Betrieb auftretende Probleme auf die der Programmierung zugrundeliegenden Konzepte übertragen zu können. Und dazu braucht man halt zumindest Basiswissen in Sachen Software (in diesem Fall vielleicht sogar eher Telematik, da wir es ja mit vielen kommunizierenden Subsystemen zu tun haben).
Liebe Fahrgäste: Der Zug ist abgefahren.

Sonderzug

  • Fahrer
  • ***
  • Beiträge: 272
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #578 am: 25. Mai 2015, 20:33:59 »
@Sonderzug: So ein System lasse ich aber auch nicht von einem Hobby-Tüftler betreuen, sondern suche mir eben Fachpersonal. Klar das dieser sich nicht nur mit dem standart Einstiegsgehalt abspeisen läßt, wenn er am freienn Arbeitsmarkt fast aussuchen kann was er verdienen will.
 
Es gibt ja ähnliche Probleme auch immer wieder beim Hastus und dem Selfservice, bei letzterem meine vor nicht all zu langer Zeit einer zu mir, dass dieses Program weit weniger kompliziert ist als Java und das, so sagte man mir, wird den Studenten schon in den ersten Semestern beigebracht.
Jetzt frage ich mich also schon, wenn das jeder erste/zweit Semestler packt, warum nimmt man sich dann nicht einen Stdenten, der könnte es vermutlich schneller und besser beherschen.
Es gibt aber eh unseren 13er, der könnte das vielleicht besser erklären als ich, da für mich EDV nicht unbedingt das Thema Nummer 1 ist.

Lieber HLS für dich zur Information, diese Arbeiten werden sowieso nur vom IVU "Fachpersonal" gemacht, das einzige was die besagte „Hobby-Tüftler“ betreuen ist die Einspielung neuer Pläne in das RBL und was die IVU ihren Mitarbeitern zahlt obliegt nicht den WL, ich glaub da gibst du mir recht.
 
Zum Hastusthema, nicht allzu langer Zeit, irgendwo einmal gehört zu haben, über drei Ecken und es könnte sogar ein Kleinkind programmieren…... Hört sich alles nach der alten Laier an welche von einer bestimmten Person in RDH immer und immer wieder im Pausenraum wiederholt wird, die Person kennst du sicher 8). Aber auch hier kann ich nur sagen die Anwender (WL) können nur Dienste eingeben und sowie den Dienstplan, alle programmiertechnischen Belange können nur die Kanadier machen und diese werden sowie die Deutschen für alles was gewünscht wird gut bezahlt.

invisible

  • RBL-Disponent
  • ***
  • Beiträge: 1577
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #579 am: 25. Mai 2015, 22:07:38 »
@Sonderzug: So ein System lasse ich aber auch nicht von einem Hobby-Tüftler betreuen, sondern suche mir eben Fachpersonal. Klar das dieser sich nicht nur mit dem standart Einstiegsgehalt abspeisen läßt, wenn er am freienn Arbeitsmarkt fast aussuchen kann was er verdienen will.
 
Es gibt ja ähnliche Probleme auch immer wieder beim Hastus und dem Selfservice, bei letzterem meine vor nicht all zu langer Zeit einer zu mir, dass dieses Program weit weniger kompliziert ist als Java und das, so sagte man mir, wird den Studenten schon in den ersten Semestern beigebracht.
Jetzt frage ich mich also schon, wenn das jeder erste/zweit Semestler packt, warum nimmt man sich dann nicht einen Stdenten, der könnte es vermutlich schneller und besser beherschen.
Es gibt aber eh unseren 13er, der könnte das vielleicht besser erklären als ich, da für mich EDV nicht unbedingt das Thema Nummer 1 ist.

Lieber HLS für dich zur Information, diese Arbeiten werden sowieso nur vom IVU "Fachpersonal" gemacht, das einzige was die besagte „Hobby-Tüftler“ betreuen ist die Einspielung neuer Pläne in das RBL und was die IVU ihren Mitarbeitern zahlt obliegt nicht den WL, ich glaub da gibst du mir recht.

Zum Hastusthema, nicht allzu langer Zeit, irgendwo einmal gehört zu haben, über drei Ecken und es könnte sogar ein Kleinkind programmieren…... Hört sich alles nach der alten Laier an welche von einer bestimmten Person in RDH immer und immer wieder im Pausenraum wiederholt wird, die Person kennst du sicher 8). Aber auch hier kann ich nur sagen die Anwender (WL) können nur Dienste eingeben und sowie den Dienstplan, alle programmiertechnischen Belange können nur die Kanadier machen und diese werden sowie die Deutschen für alles was gewünscht wird gut bezahlt.

Je nachdem wie die Schnittstelle aussieht kann man auch schon beim Einspielen neuer Daten viel Mist bauen. So "bombensicher" kann man oft gar nicht programmieren, dass der kreative Anwender nicht doch einen Weg findet das System in die Knie zu zwingen. Meist geschieht das dann, wenn jemand mit irgendwelche Tricks versucht, das System zu Aktionen zu bewegen, die im Systemdesign gar nicht vorgesehen sind. Das kann ein paar Mal gut gehen, weil sich z.B. inkonsistente Daten, die dadurch intern entstehen, zufällig nicht in die Quere kommen; und dann macht man irgendwas komplett anderes (von dem man als Anwender eben nie im Leben vermuten würde, dass es einen Zusammenhang gibt) und plötzlich zerlegt es das ganze System "völlig überraschend".

Natürlich könnte man alles mit entsprechendem Aufwand softwareseitig abfangen - meist ist es aber halt billiger, die gültigen Eingabedaten in der Dokumentation festzulegen und die damit beschäftigten Mitarbeiter entsprechend zu schulen. Aber dann müssen sie sich halt auch dran halten. Beim Auto akzeptiert ja z.B. auch jeder, dass ein Hinweis in der Bedienungsanleitung ausreicht, man möge in seinen Diesel bitte kein Superbenzin einfüllen; das könnte man ja auch technisch verhindern, nur steht der Aufwand halt in keiner Relation zum Nutzen.

Ich arbeite als Softwareentwickler und früher auch als Sysadmin; was da oft an "kreativen" Eingabedaten daherkommt überrascht mich immer wieder aufs neue. Das ist - um bei diesem Vergleich zu bleiben - oft nicht mal mehr Superbenzin sondern ein Wasserstoff-Nitro-Gemisch. Und es ist auch immer wieder schwer, der Chefetage klar zu machen, wie viel Zeit dadurch verloren geht (denn der Anwender geht sich natürlich beim Chef beschweren, wenn man ihm den Sauhaufen mit Hinweis auf die Doku zurückschmeißt).
Und alles oft nur, weil die Anforderungen zuerst unvollständig formuliert wurden (was praktisch immer passiert wenn man nicht grad mit der NASA arbeitet, und sogar bei der kommt's ab und zu vor) und dann die Anwender - wenn sie das bemerken - an den Entwicklern vorbei irgendwas herumprobieren, statt der Doku zu vertrauen, dass das halt _wirklich_ nicht implementiert wurde. Oft ließe sich das Fehlende in einem einzigen Meeting sauber nachdefinieren und mit wenig Aufwand implementieren (und wäre damit sogar insgesamt billiger, als die Zeit die fürs Herumprobieren und die daraus folgenden Ausfälle draufgeht). Ganz im Gegenteil: meist ist die Herumspielerei sogar sehr kontraproduktiv, weil sie den Fokus von der eigentlichen Ursache weg auf die danach auftretenden Probleme lenkt und man dann versucht diese zu beheben (eben weil - siehe oben - der Anwender mangels Fachwissen nicht versteht wie irgendeine lang zurückliegende Aktion Auswirkungen auf das aktuelle Problem haben kann und dementsprechend nur das aktuelle Problem an den Hersteller meldet, ohne diesem auch den Kontext mitzuteilen). Dass die Kunden dann oft auch noch mit der Problemmeldung warten, bis die Kacke wirklich schon am dampfen ist (weil man in Standardsituationen das Problem halt irgendwie umschiffen konnte, im Ernstfall dann aber halt wirklich ansteht) und dann alles auch noch möglichst schnell gehen muss und eh schon alle gereizt sind macht die Sache dann meist auch nicht einfacher.

Wie gesagt: ich weiß natürlich nicht, ob das in Wien tatsächlich das Problem ist, aber es wäre zumindest ein für mich aus meiner Praxiserfahrung in diesem Bereich sehr plausibles Szenario (das auch durch Eigenwerbungen wie die altbekannten "kreativen Tüftler" genährt wird). Natürlich hat daran auch der Hersteller oft eine gewisse Mitschuld, wenn er die Anforderungen an die Anwender/Admins nicht genau definiert oder den Kunden (aus einem falschverstandenen "der Kunde ist König"-Denken) nicht auf Probleme auf seiner Seite hinweist.
Und selbstverständlich bauen auch Softwareentwickler selbst genug Mist - das will ist hier gar nicht abstreiten. Auch hier hab ich - gerade bei Systemen, die von Firmen kommen, die eher mit Regelungstechnik (also einstmals noch ganz "analog" und ohne Computer) angefangen haben - schon sehr grausame Sachen gesehen. Da kommt oft Software heraus, die tatsächlich eher an einen verdrahteten Schaltkasten erinnert - und da drin wirds natürlich immer unübersichtlicher, wenn man einfach immer neue Drähte und Relais dazustoppelt, statt mal anzufangen _Software_ nach zeitgemäßen Methoden zu entwickeln.
Liebe Fahrgäste: Der Zug ist abgefahren.

HLS

  • Referatsleiter
  • *
  • Beiträge: 9640
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #580 am: 25. Mai 2015, 23:21:18 »
Lieber HLS für dich zur Information, diese Arbeiten werden sowieso nur vom IVU "Fachpersonal" gemacht, das einzige was die besagte „Hobby-Tüftler“ betreuen ist die Einspielung neuer Pläne in das RBL und was die IVU ihren Mitarbeitern zahlt obliegt nicht den WL, ich glaub da gibst du mir recht.
Ich würde mich auch fürstlich für meine Programme bezahlen lassen, wenn ich sowas entwickeln könnte.
Ich würde aber auch den Hersteller odentlich zur Kasse bitten, wenn er mir nicht das gibt, was ausverhandelt wurde.
Wenn ich also z.B. alle paar Tage einen Komplettausfall an meinem Laptop oder Handy oder Auto hätte, hätte der Verkäufer sein Produkt schon zurückbekommen.
Um das jetzt auf die diverse Software umzulegen, mit denen die WL zu tun haben, würde ich das SAP als allererstes gehn Hersteller schicken und zum alten System zurückkehren, da eben die Parameter nicht erfüllt werden, ebenso beim Hastus bzw. Selfservice, dort kommt es in der Regel pünktlich zum Wochenendbeginn zum Ausfall und mit Pech dauert es bis Montag Vormittag.

P.S. das Hobby-Tüftler sollte im oberen Beitrag natürlich in Anführungszeichen, scheinbar hat die automatische Korrektur im Handy zugeschlagen.  :-\
Ich gehe jetzt mal von aus, dass es doch einen Fachmann für die Systeme gibt, dann muß man aber nach mindestens einem zweiten und dritten suchen, um die Systeme 365Tage bereuen zu können und nicht, wie es eben scheint, nur von Montag bis Freitag.
"Grüß Gott"

Ich fühle mich nicht zu dem Glauben verpflichtet, dass derselbe Gott, der uns mit Sinnen, Vernunft und Verstand ausgestattet hat, von uns verlangt, dieselben nicht zu benutzen. Dieter Nuhr

denond

  • RBL-Disponent
  • ***
  • Beiträge: 1848
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #581 am: 26. Mai 2015, 00:09:07 »
Ganz so ist es dann auch nicht. Es schadet keineswegs, wenn der Programmierer und der Softwarearchitekt einen Plan davon haben, was die Software letztlich tun soll...
Sie werden sicher einen Plan haben. Nur muß man - um den Plan verstehen zu können - zuerst einmal vermittelt bekommen, wie die Züge auf der Strecke d'raußen fahren, was man mit den Zügen alles anstellen (Kurzführen, Fahrtverlängerung, Ablenken, Umleiten, Verstärken etc.) kann, vor allem auch, was man mit dem Personal machen kann. Danach werden sie sicher den Betriebsablauf auch verstehen können und dementsprechend programmieren.

Nun gehe ich allerdings davon aus, dass der Softwarehersteller durchaus bereits Erfahrung im ÖV-Bereich hat, also - abgesehen von einigen Wienerischen Fachausdrücken - nicht unbedingt aneinander vorbeigeredet wurde.
Dazu kommt, dass in Wien ja wie bereits angesprochen nicht nur das RBL Probleme macht, sondern auch vergleichsweise simple Systeme wie das Hastus. Das legt dann doch den Verdacht nahe, wo das Problem eher zu suchen ist.
Die Leute vom Softwarehersteller haben durchaus Erfahrung im ÖV-Bereich. Nur muß man davon ausgehen, daß z.B. in Deutschland niergends in einem so dichten Intervall wie in Wien gefahrenen wird, denn bei vielen Betrieben wird in einem 10' oder 20' Intervall gefahren. Auch wird dort nicht so oft "Kurzgewendet" wie in Wien. Sie waren echt von unserer Intervalldichte wie z.B. Linie 43, 49, 6, 67, 13A überrascht. Sie sahen es aber auch als Herausforderung an, gaben sich echt Mühe, diese Linien zu beherrschen. Wenn man aber in die Entwicklung - die Softwareentwickler waren noch nicht einmal mit dem Einen fertig - kam schon die Nächste Sache dran. Noch ein Beispiel: Man sagte auch von Anfang an, die Codierstecker sind veraltet, das geht mit dem RBL allein viel einfacher. Nein, die Codierstecker müssen bleiben. Ich meine jetzt nicht die Weichensteuerung - da bin ich nach wie vor ein Gegner davon, die Nichtbeachtungen der falschen Weichenstellung beweisen es immer wieder, manchmal gehen sie auch ins Aug' - sondern ganz einfach den Zug auf der Linie im System Info. Da wäre noch mehr möglich. Wieder behinderte man sich selbst...  Jetzt ist ja der, der ssssooo auf die Codierstecker pochte, doch im Ruhestand... 

Es gäbe z.B. nichts Schöneres, als das ein Bediensteter auf ein Fahrzeug aufsteigt, seine Personalnummer eintippt, das System erkennt für den heutigen Tag seine Linie, seine Dienstgruppe, bringt auf einem Display sein entsprechendes Gruppenbuch, jede Verspätung, Kurzführung oder Ablenkung bekommt er so eingetragen oder sogar ein verspäteteter Dienstschluß wird abgespeichert und: der Bedienstete wird abgerechnet und bekommt am Monatsende - durch RBL verrechnet - seinen entsprechenden Lohn.  ;)  Natürlich kann man auch noch Zusätzliches eingeben und zur Verrechnung bringen. All das wäre auch möglich.    ...und muß nicht so ein Dilemma durchmachen wie voriges Jahr, wo die Gehaltverrechnung umgestellt wurde. Das war der Gipfel des Ganzen. Das ist, war ganz einfach eine Frechheit gegenüber dem Arbeitnehmer...   Aber jetzt sind wir von der FG-Info schon zu weit weg.


13er

  • Verkehrsstadtrat
  • **
  • Beiträge: 27735
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #582 am: 26. Mai 2015, 16:06:59 »
DFIs und Vorweganzeiger sind wieder mal alle ausgefallen...
Mit uns kommst du sicher... zu spät.

Wiener Schwelle

  • Zugführer
  • *
  • Beiträge: 681
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #583 am: 27. Mai 2015, 15:52:49 »
Obwohl der SEV für die Linie 60 ur bis 26.5.2015 angekündigt war, ist es heute und jetzt noch auf der Homepage lesbar.
Für diese tolle Fahrgastinformation gibts  :ugvm: :ugvm: :ugvm: :ugvm:, auch wen der ESC vorbei ist.

13er

  • Verkehrsstadtrat
  • **
  • Beiträge: 27735
Re: Über das ewige Scheitern der Fahrgastinformation
« Antwort #584 am: 29. Mai 2015, 00:24:01 »
Das RBL ist zum dritten Mal in zwei Wochen heute am Abend komplett abgestürzt. Alle Anzeigen geben nur FBB aus. iTip gibt Plan- und Phantasiezeiten zurück.
Mit uns kommst du sicher... zu spät.