@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 
. 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.
