Bundeswehr muss für neue Software 40.000 Eigenentwicklungen anpassen
In seinem Jahresbericht hatte der Wehrbeauftragte des Bundestages am (gestrigen) Dienstag auf Probleme der Bundeswehr mit ihrer Instandhaltungs- und Ersatzteilmanagementsoftware SASPF des deutschen Konzerns SAP hingewiesen: So muss zum Beispiel bei einem Eurofighter-Geschwader während der Serverwartung der Flugbetrieb eingestellt werden.
Da sollte man diesen Merkposten im Auge behalten: Die bundeseigene Informationstechnikgesellschaft BWI, der zentrale IT-Dienstleister der Bundeswehr, wird diese Software demnächst auf eine neue Version umstellen.
Die Mammutaufgabe ist absehbar:
Damit die automatischen Updates des Herstellers greifen können, müssen SAP-Kunden ihre individuellen Anpassungen, die sie an der Software vorgenommen haben, soweit wie möglich auf den SAP-Standard zurückführen. Die Bundeswehr verfügt über circa 40.000 solcher Eigenentwicklungen – selbst für erfahrene SAP-Experten dürfte dies eine bisher nicht dagewesene Größenordnung darstellen. Zudem müssen über 60.000 Bundeswehrangehörige, die bereits heute mit SASPF arbeiten, für den Umgang mit dem neuen System geschult werden.
heißt es in einer Anzeige, die BWI am (heutigen) Mittwoch auf einem Online-Portal für IT-Anwender veröffentlichte (Screenshot oben).
Das Bundesunternehmen hat diese Anzeige nicht nur geschaltet, um auf die groß angelegte Software-Umstellung in den Streitkräften hinzuweisen. Sondern natürlich auch, um in diesem Umfeld um Fachkräfte zu werben. Die überall gefragt sind, weil die Umstellung der SAP-Software nicht nur die Bundeswehr betrifft, sondern ebenso eine Vielzahl von Unternehmen. Die Argumentation:
Wer mit seinen IT-Kenntnissen etwas bewirken will, ist bei der BWI mit ihren Kunden Bundeswehr und Bund an der richtigen Adresse.
Interessant wird neben dem fachlichen Aspekt auch der politische Umgang mit diesem Komplex. Denn die BWI ist im Zuge der Berater-Affäre im Verteidigungsministerium ebenfalls in die Kritik geraten: Von der Leyen will neues Millionen-Budget für Berater, titelte Spiegel Online im Dezember angesichts einer geplanten Aufstockung des BWI-Budgets. Der Haushaltsausschuss des Bundestages verschob denn auch erst einmal die Entscheidung über zusätzliche gut 340 Millionen Euro für das Bundesunternehmen.
Allerdings: Ein Großteil dieser Millionen hat mit umstrittenen Beraterverträgen nichts oder nur wenig zu tun. Das Geld ist unter anderem für Hardware für die Truppe vorgesehen – und mancher neue Drucker oder Computer könne nun nicht beschafft und ausgeliefert werden, weil die Mittel dafür noch nicht freigegeben seien, hieß es aus dem Unternehmen.
Auch die SAP-Umstellung mit dem enormen Bedarf an IT-Expertise und Schulung von Bundeswehrangehörigen wird voraussichtlich einiges kosten. Mal abwarten, ob und sich der Streit um die externen Berater auch an dieser Stelle auswirken wird. Die bestehenden Probleme der Truppe mit dieser Software wird das vermutlich nicht verringern.
(Danke für den Leserhinweis auf die Anzeige)
(Foto: Screenshot der BWI-Anzeige)
@ E.I.
Danke für den Link zur Stellenanzeige der BWI über das neue Projekt SAP S/4HANA
Aus dem Text der BWI:
Ich bin ja nun schon ein paar Jahre aus dem Geschäft und außerdem war ich nur SASPF Anwender und nicht Entwickler. Wenn ich mir jedoch angeschaut habe wie schwierig es für die Bw war die über 300 spezialisierten Softwarelösungen durch SASPF im praktischen Betrieb abzulösen, wie lange es gedauert hat (ca. 10 Jahre), wie die Bw z.B. bei der Instandhaltung von Lfz immer noch mit SAP-Programm IH-Planer kämpft, dann kann ich mir nicht vorstellen, dass die Umstellung auf die neue Version funktionieren wird.
Wenn es wirklich 40000 solcher Eigenentwicklungen gibt (besser Anpass- und Ergänzungsentwicklungen), um aus der Standardsoftware wieder eine Spezialsoftware zu machen, die bei der Umstellung auf S/4HANA alle neu programmiert werden müssen, dann ist die Umrüstung auf die neue Programmversion zum Scheitern verurteilt.
Das wird die BWI natürlich anders sehen, denn sie hat von 2007 – 2016 ca. 7 Mrd Euro für den Betrieb der IT-Systeme der Bw erhalten, hat gut bezahlte Vorstandsposten und hat als mittlerweile 100 %iger bundeseigener Betrieb kein finanzielles Risiko.
Was diese Umstellung, auch mit der Ankündigung zukünftig von seiten SAP noch schneller die Programmversionen zu wechseln, für die Bw bedeutet mag ich mir gar nicht ausmalen.
Zur Erinnerung der Start der Aufklärungsmission der deutschen Tornados in Incirlik hat sich zum damaligen Jahresbeginn um 2 Wochen verzögert, weil erstmal ein neues Systemupdate für SASPF für die gesamte Bw zum Jahreswechsel gefahren werden musste.
Soweit ich das beurteilen kann wäre dieses neue Betriebsystem für die BW gar nicht notwendig, denn all die angepriesenen Vorteile des neuen Systems, wie kürzere Datenauswertungszeiten, Anbindung einer größeren Anzahl von Sensoren usw. mögen bei einer industriellen Produktion eine Rolle spielen, aber nicht bei der Betriebsführung für die Bw.
Die militärischen Systeme wie Schiffe, Waffen, Flugzeuge usw. sind ja alle nicht mit SASPF ausgestattet sondern haben eigene Softwaresysteme, ziehen also aus dem schnelleren System keinen Nutzen.
Es bleibt was es ist, ein gigantisches Wirtschaftsförderungsprogramm für SAP und die Bw muss mit der schlechten Software für ihre spezifischen Prozesse leben oder eben stillstehen.
Mir stellt sich grundsätzlich die Frage ob SAP etc. Nicht eine kritische Gefährdung der Einsatzbereitschaft im tatsächlich en Ernstfall Landesverteidigung darstellt. Wenn bereits der Friedensbetrieb kaum Überwindbare Hürden in der Selbstverwaltung darstellt, wie sieht es dann in einem Ernstfall bei gezielter Cyber Bedrohung usw. Aus? Muss der Feind gar keinen Schuss mehr abgeben?
Anders gesagt: wie viele Angriffspunkte bietet ein derart bastardisiertes Software Produkt wie saspf+40000 selbstfabrizierter Einzellösungen?
Vom Einsatz/Landesverteidigung her denken?
@Georg: „Soweit ich das beurteilen kann wäre dieses neue Betriebsystem für die BW gar nicht notwendig, denn all die angepriesenen Vorteile des neuen Systems, wie kürzere Datenauswertungszeiten, Anbindung einer größeren Anzahl von Sensoren usw. mögen bei einer industriellen Produktion eine Rolle spielen, aber nicht bei der Betriebsführung für die Bw.“
Leider doch, SAP unterstützt ab 2025 das ERP nicht mehr. Und ohne Herstellerunterstützung kann man so ein System nicht laufen lassen.
Werferfehler
@T.W.: Wenn bei den Eurofightern der Flugbetrieb eingestellt werden muss solange ein Softwareupdate läuft: Ist das bei anderen fliegenden Staffeln auch so? Ich kann mir kaum vorstellen, dass nur ein Flugzeug davon betroffen sein könnte.
@Georg
„Soweit ich das beurteilen kann wäre dieses neue Betriebsystem für die BW gar nicht notwendig (…)“
Soweit ich das weiß, hat SAP bereits angekündigt, dass mit der Einführung von SAPs S/4HANA der Support für das bisherige, von der Bundeswehr genutzte System eingestellt wird!
Wenn ich das darüber hinaus richtig sehe, ist SAP S/4HANA ein cloudbasiertes System, es dürfte daher interessant sein, wie die Bundeswehr das in Bezug auf IT-Sicherheit in den Griff bekommen will!
Na, das wird ja spannend – in der Nutzung eines luftfahrzeugtechnischen Unternehmens im Zweischichtbetrieb ist und bleibt SASPF in Hinsicht auf Nutzerfreundlichkeit und Verlässlichkeit eine Katastrophe. Man stelle sich vor, dass der Geselle in der Autowerkstatt nach einem Ölwechsel (15 min) noch eine halbe Stunde im ERP-System das Öl aus dem Lager abbuchen, neues bestellen und die Arbeit dokumentieren müsste, anstelle zwei weitere Ölwechsel durchzuführen. Bei Systemausfällen und -einschränkungen wird ihm dann auch noch geraten, die Arbeiten in der nutzungsschwachen Zeit (vor 07:00 oder nach 21:00 Uhr durchzuführen)…
@Georg
SAP in Bausch und Bogen zu verurteilen, ist natürlich ebenso verkehrt, wie es die Strategie „Hurra, wir liefern uns komplett einem Konzern aus“ bei der Umstellung war. SAP ist nicht umsonst Platzhirsch in diesem Geschäft. Das Problem ist ein bundeswehrtypisches: Man kauft Standardsoftware von der Stange (aus bekannten Gründen) und biegt sie so lange auf die eigenen Prozesse um, bis nichts mehr davon Standard ist – anstatt sich mal zu fragen, warum der Rest der Welt das anders macht und mal die eigenen Prozesse zu durchleuchten.
Die Umstellung ist schon deswegen notwendig, weil die Altsoftware mitte nächsten Jahrzehnts aus dem Support läuft, die Implikationen für die IT-Sicherheit sind offensichtlich.
Dass die „militärischen Systeme“ versionsunabhängig keinen Nutzen aus SASPF ziehen, ist Teil des Problems, nicht der Lösung. Davon abgesehen ist es eine gute Idee, sich mal zu fragen, wieviel die Bundeswehr noch gebacken kriegt, wenn die nichtverbunkerten SASPF-Rechenzentren mal in Rauch aufgegangen sind.
Zitat:
„…So muss zum Beispiel bei einem Eurofighter-Geschwader während der Serverwartung der Flugbetrieb eingestellt werden….“
Nur weil etwas nicht gemacht wird, heißt das nicht das es nicht möglich ist.
In der Bereichsvorschrift
C1-271/0-7000, Nutzung von SASPF und nationalised Engineering Support System für den Flugbetrieb und die Instandhaltung des Waffensystem EUROFIGHTER
ist unter Abschnitt
2.6 „Nichtverfügbarkeit von SASPF“
geregelt wie in so einem Fall zu verfahren ist.
Wenn ich von lese, dass ein fliegender Kampfverband nicht aufsteigen kann, weil eine Verwaltungssoftware nicht funktioniert, stelle ich mir die Frage wie die Bundeswehr eigentl. im V-Fall mit derartigen Problemen umgehen würde. Angefangen von einem Ausfall der Serverarchitektur durch Feindeinwirkung bis hin zur Organisation des Flugbetriebes selbst. Ist die Bundeswehr ohne SASPF eigentlich noch einsetzbar? Das Thema schlägt doch im Grunde genau in die Kerbe, die der Wehrbeauftragte mit dem „Bürokratiemonster“ angesprochen hat.
Bevor hier die „Für was ein Update, die Bundeswehr braucht das doch alles nicht“-Diskussion los geht, SAP ist ein Unternehmen in der freien Wirtschaft. Also solches arbeitet SAP gewinnorientiert und das bedeutet auch, dass es unrentabel ist alte Versionen der eigenen Software weiter Support zu leisten. Deshalb kündigen Firmen wie SAP alte Softwareversionen ab und leisten nur Support wenn der Kunde dementsprechend dafür zahlt. Da SAP aber keine extra Ressourcen bereit halten will/kann, setzt es die Preise für Support für alte Software sehr hoch an. Dadurch ist es für den Kunden, in diesem Fall die BW, günstiger ein Update oder Upgrade auf die neue Version durchzuführen.
Zusätzliche Einnahmen durch die unendliche Anzahl an Software-Consultants die das Projekt unterstützen sind natürlich ein positiver Nebeneffekt.
Kurz, es ist billiger Software up-to-date zu halten als alte Software zu betreiben, vom Sicherheitsaspekt mal ganz abgesehen.
Wenn die Anwendungen für das Update zurückgesetzt werden müssen laufen sie doch nicht mehr?
Wäre es nicht einfacher, tabula rasa zu machen und S/4 HANA auszurollen ohne auf SASPF aufzusetzen? Ich hoffe nur, die Übernahme der Datenbestände klappt.
Da die Firma SAP den Support für R3 beenden wird und alle Kunden auf S/4 umstellen müssen, ist die Frage, ob das Sinn macht hinfällig. Leider ist es so, dass die Bundeswehr einen Großteil der Eigenentwicklungen gar nicht wirklich nutzt. Mit S/4 muss jetzt das nachgezogen werden, was man bei der Einführung SASPF trotz besserem Wissen ignoriert hat, nämlich dass die Prozesse sich der Software anpassen müssen und das Verbiegen der Software auf Bw-eigentümlichkeiten nicht mehr geht. Ich fürchte, dass dies wieder nicht gelingen wird. Auch bei S/4 wird die Bundeswehr genau wie andere Größe Firmen Eigenentwicklungen machen müssen. Das ist normal und es lohnt sich nicht, sich darüber aufzuregen. Was allerdings viel zäh läuft ist, dass der Führung der Bw nicht klar ist oder klar gemacht wird, was da auf die Bw zukommt. Ich glaube da herrscht immer noch der Glaube vor, dass es hier nur um ein Update geht.
Dass die Logistik und was auch sonst noch alles grundsätzlich IT-basiert funktioniert, ist ja gut und richtig. Ich frage mich allerdings, ob es vor dem Hintergrund „survival to operate“ auch am einzelnen (Waffen)System und in einer vernetzten Einheit/einem vernetzten Verband auch noch den berühmten Schalter gibt, mit dem „Wirkung“ auch rein manuell durch den Soldaten gesteuert erfolgen kann. Ein Flugzeug muss nach meiner Meinung auch ohne Verbindung von außen fliegbar sein und auch abheben. Und wenn es darf kein LKW stehen bleiben oder ein Kran nicht bedienbar sein, wenn die elektr. Steuerung einen Treffer abbekommen hat. Manchmal ist weniger Elektronik einfach mehr. Ich brauche kein elektronisch angesteuertes Hydraulikventil am Kipper, wenn es auch mit einem handbedienten geht. Bei den ganzen tollen geschützten Fahrzeugen frage ich mich immer, wie viel die vertragen und zumindest noch fahren können. Es nützt mir als Insasse wenig, wenn der Karren mich vor der Detonation einer Mine schützt, ich aber danach nicht mehr vom Fleck komme. Dass jeglicher Schutz seine Grenzen hat und dies alles immer ein Katz-und-Maus-Spiel ist, weiß ich natürlich. Ich möchte aber nicht vor einen Kdr, geschweige denn vor Angehörige treten müssen mit der Aussage „DIe Kameraden sind gefallen, weil die Klimanalage einen Querschläger bekommen hat und der Bordcomputer deshalb die Bremse nicht mehr frei gab.“
@JMWSt und andere
Ihre Frage ist zwar berechtigt, an dieser Stelle geht es aber nicht um die Technik im Betrieb von Flugzeugen, Gefechtsfahrzeugen etc, sondern um die Steuerung von Instandsetzung, Ersatzteilen usw. – wir sollten das ein bisschen getrennt halten, weil es sonst ein allübergreifendes Thema wird, wo das hier anstehende Problem dann eines von mehreren ist und die Debatte recht unübersichtlich wird.
SAP lebt davon, dass Firmen deren Produkt mit entwickeln und man diese Produkte auf Firmen mit gleichem Geschäftsmodell umklappt.
Die Bundeswehr besteht aus Tausenden von firmenähnlichen Organisationsteilen die es nur bei der Bw gibt. Daraus folgert, wenn keine andere Armee unser System verwendet, gibt es in diesem Modell kaum einen Mehrwert und wir sind ständig am Entwickeln.
Als Kunde und die Bw ist in vielen Bereich Kunde, muss man das Ordermanagement des Lieferanten verwenden. Die Bw versucht ihr System, im Besonderen in der Logistik, auf die Versorger/Lieferanten umzuklappen und das funktioniert im Moment kaum und in der Zukunft nicht. Man sieht es am Beispiel des Autonomic Logistics Information System (ALIS) der F-35 Lightning II. Das Gleiche geschieht bei CH 53K, CH47 und selbst bei Putzmittellieferanten.
Mit SASPF sind wir nicht integrierbar mit unseren Partnern und Zulieferern in Europa (und USA). Der Zentralismus, die Planwirtschaft im BMVg ist der Grundfehler. Verschiedene Systeme und Dislozierung können zu mehr Resilienz und Schlagkraft führen, wir sind eben keine Firma. Der Glaube man könne ohne dass Verantwortung, Kompetenz und Entscheidungsbefugnis jeweils dort zusammengeführt ist wo es am effektivsten ist. Auftragstaktik und vom Einsatz/Wirkung (LV/BV) her denken müssen wieder Grundlage werden und nicht der Prozess von oben.
Die Aussage die Prozesse der BW müssen an das System SAP bzw. SASPF angepasst werden habe ich erstmals 2001 bei einem Vortrag über die Einführung von SAP in die Bw gehört. Bereits damals habe ich ungläubig den Kopf geschüttelt, dass all die Instanzen, die z.B. einen Vorgang abzeichnen müssen bevor er im Computer gebucht werden kann auf ihr Mitzeichnungsrecht verzichten werden.
Heute, 18 Jahre später haben wir also statt der 2001 angekündigten 3 Anpassentwicklungen nach Aussage der BWI ca. 40000 Anpassentwicklungen erlebt. Soweit zur Aussage die Bw-Abläufe müssen sich der Standardsoftware anpassen und nicht umgekehrt.
Vor dem SAP-Zeitalter hatten wir ca. 300 spezialisierte Einzelsoftwareanwendungen in der Bw. Für diese Software hatten wir in der Bw eigene Systembetreuer und in den Ämtern Nutzungsbeauftragte die sie auf Augenhöhe mit der Industrie weiterentwickelten. Wir hatten eine Fachschule für Wirtschaftsinformatik auf dem Lechfeld, bei der z.B. alle IT-Offiziere des milFD ausgebildet wurden, wir hatten auf dem Lechfeld eine eigene Ausbildungseinheit für IT-Fachpersonal bei der auch die schwierige Programmiersprache „Ada“ ausgebildet wurde und wir hatten die Programmierzentren von Heer, Lw und Marine für alle Arten von Waffensystemen, bei denen Softwareupdates für die verschiedenen Waffensysteme ausgetestet werden konnten.
– Alles abgeschafft und zur Industrie outgesourced –
Und ja, man kann auch ohne SASPF Anbindung eine Flugzeuginstandsetzung betreiben, aber wie lange kann man dies durchhalten – 1 Tg, – 2 Tg, – 1 Woche oder 1 Monat?
Vielleicht so mittels „Witchboard“ wie es die US-Navy macht ?
https://www.youtube.com/watch?v=1JAvunVOR44
Nach meinen Dafürhalten ist die jetzige BW viel zu sehr von SAP abhängig um durchhaltefähig ihren Auftrag durchführen zu können. Vielleicht denkt man mal darüber nach, ob die dezentralen 300 Einzelsoftwarelösungen für spezialisierte Anwendungen, eigenversorgbar und betreubar, nicht die bessere Alternative für die Bw wäre.
Das Einzige das darunter leiden würde, das BMVg könnte auf Knopfdruck keine Controllingberichte mehr über den Zustand der Truppe abrufen, aber auch bei dieser Anwendung gilt der alte EDV-Grundsatz, Mist rein – Mist raus !
Die Auswertung die oben ankommt ist nur so gut wie die Datenpflege, die unten in der Truppe und den Ämtern betrieben wird.
Und wenn ich da höre was da alles an instandsetzbares Equipment mit Wartungsplan aufgenommen wurde, wundert mich nichts mehr.
@Akki | 31. Januar 2019 – 7:25
„und biegt sie so lange auf die eigenen Prozesse um, bis nichts mehr davon Standard ist – anstatt sich mal zu fragen, warum der Rest der Welt das anders macht und mal die eigenen Prozesse zu durchleuchten.“
Naja, eine Antwort darauf könnte halt sein: weil es eben die (militärische!) Welt auch nicht so macht und das aus gutem Grund…
@Ölfuß | 31. Januar 2019 – 9:08
„Mit S/4 muss jetzt das nachgezogen werden, was man bei der Einführung SASPF trotz besserem Wissen ignoriert hat, nämlich dass die Prozesse sich der Software anpassen müssen und das Verbiegen der Software auf Bw-eigentümlichkeiten nicht mehr geht.“
Ist das so? Ich hoffe vielmehr, dass wir es wieder so machen. Nur diesmal von Anfang an mit Schwung und dann halt auch mit dem notwendigen Geld um sich die Umprogrammierungen zeitgerecht leisten zu können.
Die Bw ist nun einmal nicht VW und es bringt uns nichts, wenn wir perfekt funktionierende auf SAP-Standard abgestimmte Prozesse haben, die uns aber militärisch schaden.
Die Bw ist nicht dafür da SAP zum laufen zu bringen. Die Bw ist dafür da Streitkräfte kampf- und einsatzfähig aufzustellen und zu erhalten. Dafür sind die Prozesse zu optimieren. Alles andere ist nachrangig.
Und wenn es dann halt mehr Geld kostet, dann ist das halt so…
@Koffer: Durchaus möglich, dass das so ist. In diesem Fall wäre der Fehler bei der Auswahlentscheidung für das Produkt gemacht worden.
Nach meiner Beobachtung kommt der Löwenanteil der Sonderlocken, Rucksäcke und Erker, die die Bundeswehr gerne an Industrieprodukte anbauen lässt, weniger aus dem operativen Bedarf, sondern aus den Ecken „Haben wir immer so gemacht“ und „Wir machen das aber besser/genauer als alle anderen“. Normal reicht uns nicht.
@Koffer | 31. Januar 2019 – 10:29
Contra. Entweder die Bw (bzw. BMVg) ändert ihre Prozesse so, dass sie größtenteils zu SAP passen. Oder man verzichtet auf SAP und sucht sich andere Software-Lösungen.
Aber SAP regelmäßig auf die bestehende Bundeswehrwelt anzupassen, ist organisatorisch und finanziell Wahnsinn und nicht zu verantworten. Dieser Aufwand übersteigt sämtliche Vorteile, die die einheitliche und zentralisierte SAP-Welt mit sich bringt; sowohl kurz- als auch mittel- und langfristig.
@Tom | 31. Januar 2019 – 10:57 u. Akki | 31. Januar 2019 – 10:53
Ich kann nicht beurteilen, ob es zu SAP eine Alternative gibt. Möglicherweise wäre auch eine Teil-/Teillösung das richtige. Also SAP nur dort, wo es funktioniert ohne massive Änderungen und ansonsten Insellösungen…
Aber militärische Prozesse an Software-Anzupassen ist viel zu gefährlich. Bei uns geht es um Kriegs-/Einsatztauglichkeit alles andere muss dahinter zurück stehen.
Es ist übrigens beides:
1) SAP wird auf Bw-Spezifika angepasst.
2) Bw-Prozesse müssen sich an SAP anpassen, weil letzteres nicht beliebig verbogen werden kann.
Ergebnis: das Schlechteste aus beiden Welten. :-/
SAP ist in Hinblick auf LV/BV weder Personell noch bzgl Schlagkraft zukunftsfähig. All die Entwicklungen der tausenden von Zulieferern zu mit Eigenmittel zu dublizieren ist nicht durchhaötbar.
Wir die Soldaten zum Kampf, nicht zur Verwaltung.
Kennzahlen für das BMVg zu bilden geht auch ohne SAP, nennt man dann Meldung.
Bei der Einführung von SAP haben die BWI, die Berater und insbesondere SAP haufenweise Geld verdient und die Bw abhängig gemacht.
Wir.Lernen.nichts
Das Kind ist ja quasi schon in den Brunnen gefallen. Im Sinne, dass SASPF eingeführt und die eigenen Kompetenzen outgesourced wurden.
Jetzt würde ich, wenn ich was zu sagen hätte, S/4HANA zwar einführen, aber viele Dinge auch wieder rückgängig machen. S/4HANA kann ja gerne in den Ämtern und Kommandobehörden eingeführt werden. Aber für Arbeitsebene braucht man den Mist nicht.
Und da die Truppe jetzt auch gerne cybert, könnte man parallel verlorene Kompetenzen für Inhouse-Entwicklungen wieder aufbauen. Und wenn die Ämter dann die Daten gerne in SAP haben wollen, dafür gibt es standardisierte Schnittstellen in HANA.
Dann hätte man nämlich den Vorteil, dass man seine 300 Fachanwendungen an den Bedürfnissen der Truppe ausrichten und entwickeln kann. Die muss man auch nicht als lokale Anwendungen entwickeln. Vieles kann man recht simpel als Webanwendung auf irgendeinen Server oder in eine BW-Cloud schmeißen.
Und es hat den Vorteil, dass diese Anwendungen nicht mit jedem neuen SAP Update komplett nachgezogen werden müssen. Und man kann mittels vorhandener Schnittstellen die Daten für die Ämter in SAP pushen, wenn man es denn braucht.
Aber: Man wird ja noch träumen dürfen
@ Koffer
„….die Bw ist nun einmal nicht VW und es bringt uns nichts, wenn wir perfekt funktionierende auf SAP-Standard abgestimmte Prozesse haben, die uns aber militärisch schaden.“
VOLLTREFFER!
Ich hatte seinerzeit für zwei Unternehmen gearbeitet, welche sowohl im HERKULES-Projekt, als auch im Standard-Anwendungs-Software-Produkt-Familien-Projekt federführend waren.
Als gelernter Fallschirmjäger war mein erster Gedanke zu SASPF: „Sind DIE wahnsinnig? …..aus meinem Bereich kommt niemand ins Projekt!“ Unverantwortlich.
@ Tom | 31. Januar 2019 – 10:57
Das Problem ist das die Bundeswehr mit der Einführung von SAP nicht gut beraten war.
Die Lösung wäre die Bundeswehr kauft sich für die IT einen neuen Hut !
Eine mir sehr gut bekannt Software ist PSI Penta ( Programm mit der Walnuss ), in dieser neuen Software Lösung kann man SAP vorübergehend als Hilfsprogramm einpflegen.
Die Software PSI Penta wird in meiner Region auch als Energiemanagement Software in Kraftwerken eingesetzt und während der Serverwartungen gehen bei uns nicht die Lichter aus.
Das bei einer Serverwartung der Flugbetrieb nicht fortgeführt werden kann, da sollten sich die Verantwortlichen mal an Kopf fassen, ob sie noch was merken !
Weshalb muß auf taktischer Ebene – bis einschließlich Division – überhaupt mit SAP gearbeitet werden (Ausnahme ggf. FGG 1 (*))?
Unter der Prämisse „Übe (arbeite) wie Du kämpfst“ sollte eher ein FüInfoSys die erforderlichen Prozesse abbilden, welches auch im Grundbetrieb genutzt wird.
Das kann dann gerne mit Office-Produkten angereichert werden. Spezialanwendungen (z.B. bei GeoInfo) gibt es ja ohnehin.
(*) wobei es gerade dort viele Abfragen in den unterstellten / nachgeordneten Bereich gibt, die man eigentlich „auf Knopfdruck“ direkt ermitteln können müßte.
Der WB hat die Büchse der Pandora geöffnet mit der Erwähnung des Themas SASPF.
Nach meiner Meinung ist SASPF als einer der Hauptfaktoren (neben den diversen Reformen der Struktur) der derzeitigen Situation der Bw völlig unterschätzt.
Im vorangegangenen Thema zum Jahresbericht habe ich mich etwas Laienhaft ausgedrückt, gemeint habe ich aber dieses nun anstehende SAP Update. Die Folgen der SASPF Einführung
generell und der nun anstehende Plan mit den weiteren Auswirkungen auf die Bw wären eigentlich einen U-Ausschuss wert.
@Nokrazul
‚hatte Ihren Beitrag, der meinen Gedanken vorweg nimmt, beim Verfassen noch nicht gesehen.
Es muss doch grundsätzlich bei einer neuen Generation der Software die Frage gestellt werden, für welche Anwendungen ist die „Standardsoftware“ von SAP sinnvoll in der Bw anzuwenden ?
Da fällt mir als Erstes der SAP-Bereich HR, Human Resources also die Personalplanungssoftware für den S1-Bereich und höher ein. Personalverwaltung im zivilen Betrieb und bei Militär erscheint mir nicht grundsätzlich unterschiedlich sein. Aber würde es nicht reichen an die HR-Software die Trainings (vor SASPF, die Lehrgänge) an den Schulen mit Länge und Zeitpunkt zu hinterlegen ?
Ist es tatsächlich notwendig den kompletten Lehrplan bis auf Feinzielebene mit einer Anpassentwicklung (eine von den 40000) an SAP HR Personalverwaltung anzubinden. Das ist ein Dokument bis zu 100 Seiten (je nach Lehrgangslänge) das Zeile für Zeile in Eingabemasken für SAP eingegeben werden muss. Das braucht an einer Truppenschule niemand, da reicht zur Lehrgangsplanung ein Excel-Blatt.
Ein anderes Beispiel ist die SAP-Software IH-Planer, gedacht um Produktionsanlagen der Industrie regelmäßig zu warten.
Die Instandsetzung eines Kampfflugzeuges läuft aber anders ab, da gibt es Zeitaustauschteile, Unverträglichkeiten von Kompenten abhängig von deren Serialnummer und Softwarestand, planbare und nicht planbare Instandsetzung, Zuarbeit bei bestimmten Arbeiten von externen Stellen und die Anforderung und Bereitstellung von Ersatzteilen usw.
Dies alles liese sich vielleicht noch mittels Manpower regeln. Was aber überhaupt nicht geht, ist das die Software das letzte Wort hat ob ein Flieger einsatzklar ist oder nicht.
Programmierer neigen dazu die Anwender der Software zu entmündigen, d.h. sie rechnen immer mit dem DAU (Dümmsten Anzunehmenden User) und berücksichtigen nicht das Derjenige, der die Berechtigung hat an einem Kampfflugzeug zu arbeiten mehr Wissen und Übersicht hat, als das SAP-Programm.
Wie dem auch sei, das Verhältnis BW und SAP kann man am Besten mit einem Witz beschreiben.
Ein Mann geht zu einem Schneider um sich einen Anzug anfertigen zu lassen. Der Schneider ist ein Pfuscher und macht ein Hosenbein zu kurz, einen Ärmel zu lang, die Jacke zu eng usw.
Als der Kunde zur Anprobe kommt fallen all die Mängel auf. Der Schneider empfiehlt dem Kunden immer einen Ausfallschritt zu machen, damit das zulange Hosenbein nicht auffällt, für den zu langen Ärmel empfiehlt er die Schulter hochzuziehen und wegen des zu engen Sacko die Luft anzuhalten. Als der Kunde so aus dem Geschäft mit hochroten Kopf auf den Gehsteig tritt sehen ihn zwei Passanten.
Voller Mitleid sagt der Eine, „es ist schon hart wenn man ein Krüppel ist“ und der Andere anwortet, „aber er hat einen guten Schneider, der hat dies mit dem Anzug gut hingekriegt“ !
@Akki
>>eine gute Idee, sich mal zu fragen, wieviel die Bundeswehr noch gebacken kriegt, wenn die nichtverbunkerten SASPF-Rechenzentren mal in Rauch aufgegangen sind.
Das ist in der Tat eine Frage, die sich mir auch stellt – nicht nur bzgl. fundamental bedeutender Rechenzentren. Ein ähnliches Beispiel ist das Outsourcen der Eurofighter-Ersatzteil-Logistik an Airbus verbunden mit der Zentralisierung der Ersatzteilbevorratung im MASC Manching:
http://www.bundeswehr-journal.de/tag/military-air-spares-center/
Bestimmt wirtschaftlich im Friedensbetrieb, aber im LV-Fall mehr als heikel!?!
Jetzt mal ganz ehrlich, diese Meldung überrascht doch hoffentlich niemanden. Wir haben seit ca. 1,5 Jahren ein neues Beurteilungssystem in der Schublade liegen und können es nicht einführen, weil die SAP-Anpassungen im PersWrtSys so umfangreich sind. Hieß es 2018 noch, das die Umstellung per 2019 erfolgen soll, ist aktuell nun von 2021 die Rede. Und das geht es um ein Thema mit unmittelbarem Bezug zu Menschen, und nicht nur zu Material. SAP bzw. unser Umgang damit bei Anpassungsprozessen ist eine Katastrophe.
Es ist eigentlich ganz einfach.
Wenn SAP funktioniert, dann ist es genial.
Wenn SAP nicht funktioniert und das passiert selbst in guten Firmen unter besten Bedingungen, dann funktioniert garnichts mehr.
Militär wird für den Augenblick vorgehalten, wenn der böse Feind alles daran setzt, dass nichts mehr funktioniert.
SAP hat bei Miltär nichts, aber auch garnichts verloren.
Das erste was fehlt, wird das Netz sein und das Meldemittel der Wahl der Meldeblock mit Bleistift (der kann nicht einfrieren oder so, Das war mal das Argument)
PS: Diese Beratungsleistung ist kostenfrei.
Gegen Ende meiner Dienstzeit ( zum Glück … ) durfte ich noch die Einführung von
SAP / SASPF in die fliegerische Hubschrauberausbildung in Achum / Bückeburg miterleben.
In 38 Jahren sammelt man ja schon die eine oder andere Erfahrung, aber das war mit Abstand der größte ( und sehr teure !! ) Krampf, den ich währenddessen erlebt habe.
Bestehende, bewährte und funktionierende Verfahren wurden durch eine für die zivile Luftfahrt bestimmte Software ersetzt, und jegliche Flexibilität konsequent abgeschafft.
Davor z.B. hatte eine Unterschrift eines Prüfers nach Behebung einer (kleinen) Störung im Bordbuch ausgereicht, das Lfz wieder weiterfliegen zu lassen.
Mit SAP musste sich man einen Zugangspunkt zum Bw – Internet ( ‚Intranet‘ ) suchen. Im Idealfall am Platz in der nahen Flugzeughalle, oder bei einem ‚Flugtag‘ auf einem zivilen Platz in der nächsten Kaserne ( … ), bei Auslandsflügen odr irgendwo ‚im Gelände‘ weiß ich nicht, wo, ist mir zum Glück nicht mehr passiert.
Dort die Daten ins System eingeben und von diesem die Flugfreigabe bekommen. Außer, auch passiert, möglicherweise abgelehnt, weil es Sonntag war … .
Der muß sein: https://www.heise.de/forum/heise-online/News-Kommentare/SAP-Ziele-fuer-2015-uebertroffen-und-optimistisch-trotz-Umbaus/Doch-noch-ein-SAP-Witz/posting-24436981/show/
Egal wie man es betrachtet, es wird schwierig.
Ich hatte mal das Vergnügen, einer Emigration von SAP weg beizuwohnen.
Das hat etwa 8 Jahre gedauert und beide Varianten wurden 3 Jahre parallel betrieben.
Es war grundsätzlich im Ende sinnvoll, weil danach die Kosten stark gesunken sind, neben einigen anderen Vorteilen. Sowas kann sich nicht jeder leisten und viele sind mit SAP zumindest nicht unzufrieden. Kommt auf den Fall an. Viele Spezialanwendungen, die vom Standard nicht abgedeckt werden, das schreit eigentlich nach einer eigenen Lösung.
Bitte keine Nachfragen zur Firma und verwendeter Software, weil NDA.
Generell sehe ich es so, das kritische Infrastruktur mit quelloffenen gut dokumentierten Lösungen betrieben werden sollte, damit man nicht bei einer Pleite auf dem Schlauch steht. Sowas wie den Verteidigungsfall sehe ich da noch gar nicht.
Geht eine Firma pleite ist sie weg und man hat eine proprietäre Lösung, wo man nicht reinschauen kann (bei Hardwarewechsel geht nichts mehr, Sicherheitslücken werden nicht geschlossen, neue wünschenswerte Funktionen lassen sich nicht mehr integrieren) oder sie wird aufgekauft und man hat keine Ahnung welche Agenda der neue Besitzer hat.
Bei einem Nutzer wie der Bundeswehr wäre es unter Umständen fatal, sollte nach so einem Besitzerwechsel der neue beispielsweise in China (Extrembeispiel, Spionage geht ja jetzt schon, wer kann für alle Programmierer seine Hand ins Feuer legen) sitzen.
Programmcode kann man schon jetzt nur sehr bedingt vertrauen.
Ich vermute mal, das auf Seiten der BW keine Expertise (Roland Berger und Co sind da nicht die richtigen Ansprechpartner) vorhanden ist um, selbst bei Offenlegung des Programmcodes, diesen prüfen und bewerten zu können.
Generell finde ich bei einem Nutzer, der bei einem Totalausfall seiner EDV (Virenattacken, Rechenzentrum zerstört, Strom weg und Diesel alle, Verbindungsstörungen, EMP > nach EMP ein kann noch zwei drei und vier kommen, durchaus auch ohne Fallout und Druckwelle) weiter handlungsfähig bleiben muß und gleichzeitig damit rechnen muss das dieser Fall eintritt, gedruckte Handbücher, Klemmbrett mit Stift und Laufzettel gar nicht mal so schlecht.
Als ich dort noch meinen Wehrdienst abgeleistet habe gab`s das auch alles.
Viele der beschriebenen Probleme gab es da, zumindest dort wo ich war, noch nicht.
@Georg | 31. Januar 2019 – 14:16
„Ist es tatsächlich notwendig den kompletten Lehrplan bis auf Feinzielebene mit einer Anpassentwicklung (eine von den 40000) an SAP HR Personalverwaltung anzubinden. Das ist ein Dokument bis zu 100 Seiten (je nach Lehrgangslänge) das Zeile für Zeile in Eingabemasken für SAP eingegeben werden muss. Das braucht an einer Truppenschule niemand, da reicht zur Lehrgangsplanung ein Excel-Blatt.“
Volle Zustimmung! Es ist ja sogar beabsichtigt alle Ressourcen zu hinterlegen (benötigte Hörsäle etc. etc.). Aus einem betriebswirtschaftlichen Blick kann ich das ja gut verstehen, aber Bw-technisch ist das kompletter Unfug. Eine Excel-Tabelle oder ein für die jeweilige Truppenschule „programmiertes“ Miniprogramm reicht da vollkommen aus. Ist flexibler in der Nutzung und wesentlicher weniger aufwändig in der täglichen Pflege.
@Georg: Und die Instandsetzung eines Schiffes läuft auch anders ab (geringste Zahl an Einheiten im Vergleich mit Lw und H, Besatzung bleibt an Bord, andere Vorschriftenlage).
Aber egal, ME-Antrag heißt dann IH-Antrag, sonst ändert sich nix. Wie Raiders.
Vielleicht sollte die Marinedruckerei ein paar zehntausend ME-Antragsdurchschläge drucken. In Roffhausen findet das MUKdo vielleicht auch noch Restbestände von Olympia…
Was uns die Einführung von SASPF an Mannstunden in Eigenleistung gekostet ist mit Sicheheit nicht bekannt. Wir könnten wohl tausende DP sinnvoller verwenden, wenn wir auf Arbeitseben (außer beim S4) keinen mehr haben. Als Ersatz für abgesetzte Rechner in der Bw internen Matbewirtschaftung mag SAP ja ein sinnvolles Werkzeug sein. Am Waffensystem hat das nichts verloren, da benötige ich vernünftige Kom Mittel und WaSys bezogene IT.
@Koffer | 31. Januar 2019 – 17:44
„Eine Excel-Tabelle oder ein für die jeweilige Truppenschule „programmiertes“ Miniprogramm reicht da vollkommen aus. Ist flexibler in der Nutzung und wesentlicher weniger aufwändig in der täglichen Pflege.“
So sollte es ja auch sein. Bzw. ist, je nach Projekt, Stand der Technik. Stichwort Microservices und Container. Aber ich gehe noch den Schritt weiter und würde sagen, dass man das nicht in irgendeinem Amt, extern oder im Zentrum für CyberCyber entwickeln sollte, sondern direkt vor Ort. Stichwort User-Centered-Design. Also sprich, den Nutzer in den Fokus setzen.
Ein Beispiel:
Ich gehörte auch mal zur fallenden Zunft. Und in der fallenden Zunft war eine der originären Aufgaben des Kompanietruppführers das Pflegen der Sprungkarteien. Inkl. der lästigen Quartalsmeldungen der abgelegten Sprünge an S3 und höher.
Jetzt kann man dieses sicherlich in SAP bei der Entity „Soldat, fällt, manchmal“ hinzufügen. Jedem KTF Sdt(man hat’s ja delegiert und nicht selbst eingetragen) dann noch einen geschwurbelten SAP Zugang geben, die Sdt dann noch schulen und generell aus dem ganzen Dingen einen Krampf machen. Kosten wären exorbitant höher, weil SAP bzw. ABAP macht man nicht mal eben so. Die Leute, die das können, sitzen nicht mal eben in der Division, sondern lassen sich das in der Regel als Externe richtig gut bezahlen.
Was man allerdings auf Divisionsebene machen „könnte“, wenn man denn „wöllte“: Zwei halbwegs fähige Programmierer da hinsetzen und denen ein bisschen Freiraum geben. Dann tappern die ab, zur nächsten KTF/Spieß/Chef Besprechung in Btl XY, setzen sich da hin und fragen „Wat wollt ihr denn eigentlich? Wat braucht denn ihr?“ Und nach Erkenntnisgewinn tappern die wieder ab und fangen an, einen Container zu bauen ( z.B. mal Docker googlen ). Und zwar nur für je diesen einen Zweck: Z.B. der Pflege der Sprungkarteien. Sonst nichts! Da wird ein Webserver reingeschmissen und ne Datenbank. Wenn das Dingen fertig ist, wird es bei irgendeinem Amt oder Rechenzentrum angemeldet und steht fortan im Intranet zur Verfügung. Mit ein bisschen was User und Rechte Management auch allen anderen springenden Teilen.
Ergo: Quartalsmeldungen fallen weg, wenn man das ein wenig intelligent macht fällt viel tippen weg und man kriegt immer einen schönen Reminder, wer noch seine Pflichtsprünge zu erfüllen hat, bzw. die Schulen können sehen, wieviele Kapazitäten sie für Nachschulungen reservieren müssen.
Kosten? Naja, die zwei Programmierhansels.
Zeit? Also ich kann einen Docker mit Webserver und DB, mit einer grundlegenden Tabellenstruktur und einer einfachen Funktionalität ( also in unhübsch und sch** zu bedienen, aber funktional ) in einem halben bis 3/4 Tag bauen. Und dann wird der immer schön weiterentwickelt im Sinne von Continuous Integration. Sprich, es kommt jede Woche ein neues Feature oder ein Bugfix hinzu.
Vorteil? Man ist irrsinnig nah an der Truppe und deren Bedürfnisse. Man ist hochgradig flexibel. Man braucht irgendwelche Updates von SAP nicht zu fürchten, weil alles, was im Container drin ist, bleibt so wie es ist. Container sind in der Regel hochgradig skalierbar, austauschbar und können redundant eingesetzt werden. Man hat einen Microservice, der nur für eine Aufgabe zuständig ist. Heißt, man muss keine monolitische, eierlegende Wollmilchsau um fünf Ecken verbiegen. Zudem ist das ganze Zeuch noch Open Source.
Schön wär’s, oder :-)
@Nokrazul | 31. Januar 2019 – 21:20
Genau das!
@ akki 31. Januar 7.25 Uhr
Sie bringen das Dilemma auf den Punkt. SAP heißt: Standard Anwendungs Programm. Das verlangt zwingend vereinheitlichte Abläufe (koste es, was es wolle). So habs ich für meine Zerti gelernt. Und das in der Bundeswehr die Abläufe eben nicht Standard im Sinne von SAP sind, zeigen die ca. 40.000 Anpassungsentwicklungen.
Meine Schlußfolgerung daraus lautet, SAP hätte niemals bei der Bundeswehr eingeführt werden dürfen, weil es für diese Vielfalt nicht geeignet ist.
@AMSI / Koffer
Zu SASPF für (fliegende) Waffensysteme:
Wenn in einem fliegenden Verband die Verbindung zum Intranet ausfällt, dann brauchen wir dank SASPF auch keine Fallschirmjäger mehr. Ich bezweifele sehr stark, dass Sie dann noch ein Absetzflugzeug finden, dass sich noch in die Luft bringen lässt. Spätestens bei einem Wechsel eines in der Lebenslaufakte geführten Teils endet auch das Notverfahren „Logbuch“ das derzeit z.B. bei den Wartungsfenstern Anwendung findet. Früher wurde auf Papier dokumentiert und man flog bis zur nächsten großen Inspektion. Theoretisch ginge das auch beim Logbuchverfahren, praktisch ist aber selbst bei Altsystemen ohne dynamische Betriebswertefortschreibung sowohl der Arbeitsaufwand als auch die Fehlerwahrscheinlichkeit so hoch, dass man es besser ganz bleiben lässt wenn das Lfz danach nicht gleich für Monate am Boden stehen soll. Ganz großes Kino für eine Armee.
Zu SASPF an Schulen:
Für die meisten Schulen der Bundeswehr ein Wahnsinn! Unkritische Ressourcen müssen mit einem Wahnsinnsaufwand gepflegt, Stundentafeln in mühevoller Handarbeit mit Mausschieberei erstellt werden um dann doch wieder Excel Stundenpläne zu erstellen weil das didaktische Modell z.B. wegen eines Feiertags das Schießen oder den Geländedienst auf die letzen zwei Stunden des Freitags und den nächsten Montag Vormittag verteilt. (Ironie an) Ich warte nur noch darauf, dass man die Feinziele für jede Stunde nutzt um für fliegende Waffensysteme der Nachweispflicht gem. DEMAR zu entsprechen. Am Besten kurz bevor wir auf Hana umstellen. (Ironie aus)
@moth
Schade! Sehr schade! Alle, die sich gleich bei der Einführung aus dem Projekt mit derartigen Bemerkungen rausgehalten haben, sind meiner Meinung nach mitschuldig an der Misere. Selbst militärische Minimalforderungen, die jedem sofort einleuchten müssten (Autarkie für abgesetzte Einheiten und die Möglichkeit, problemlos bei Ausfall des Systems weiter arbeiten zu können) sind so nicht gefordert worden. Stattdessen ist ein Standardpaket ausgerollt worden und erst danach hat man mit Schrecken festgestellt, was das bedeutet. SASPF hat viele Vorteile in der Etappe und bei den Logistikern, aber nur dort gehört es hin. Nicht in die vorderste Linie eines Kampfverbandes / Geschwaders. Oder halt mit einer sinnvollen Benutzeroberfläche die ein normaler Techniker / Soldat auch ohne einen sechswöchigen Lehrgang versteht und die vielleicht die Daten lokal zwischenspeichert bis man irgendwann mal wieder am Netz hängt.
@Schnuckel
Mal Butter bei die Fische:
Ich kann mir immer noch nicht vorstellen, dass ein Flug einer Trall oder eines 400ers an SAP scheitert. Sicher, im Friedensbetireb dürfen die Teile nicht ohne 57 Megabyte Formulardaten erhoben zu haben abheben. Aber ich bin der festen Überzeugung, dass, wenn die Trall oder der 400er am KIA stehen und die Granaten rechts und links einschlagen, der Pilot stumpf die Karre anlässt und losfliegt. Ich gehe nicht davon aus, dass dann ein SAP oder ein Logbuch einen Flug verhindern würde. Liege ich falsch? Verbessern Sie mich, wenn ja.
@ Schnuckel
Leider muss ich Ihnen in Bezug auf die fehlende Autarkiefähigkeit von SASPF widersprechen. Zumindest beim Heer und Marine war (und ist dies) dies eine Forderung seit Anbeginn der Einführung. Beim Heer wegen „first Entry Einsätzen“ und bei der Marine wegen des Bordbetriebes auf See.
Leider, aber das habe ich nur gehört, wurde das s.g. Projekt „Mobile Engine“ welches diesen abgesetzten Betrieb ermöglichen sollte so gegen 2008 eingestellt. Angeblich hatte man der Führung im „Generalserklärung“ dargestellt die Mobile Engine wäre eine Version von SASPF die auf einem Notebook überall funktioniert – mehr brauch man wohl nicht zu sagen.
Gerade die Autarkiefähigkeit wäre n.m.K. ein Alleinstellungsmerkmal des militärischen SAP, aber die Datenintegrität und die Wiederzusammenführung der Datenstände die zeitweise losgelöst voneinander bearbeitet wurden ist kein triviales Problem bei z.B. den Datenmenge in der Wartungssteuerung moderner Lfz.
@Schnuckel
So ist es. Raus aus den Kampfverbänden mit SASPF die Schnittstellen müssen mind eine Ebene zurück und nicht im den Einsatz/Mission. Da muss es reichen, dass es welche gibt, wo auch immer die sitzen, die man anrufen kann und dann dürfen diese die erforderlichen Daten pflegen.
@Schnuckel
„…Theoretisch ginge das auch beim Logbuchverfahren, praktisch ist aber selbst bei Altsystemen ohne dynamische Betriebswertefortschreibung sowohl der Arbeitsaufwand als auch die Fehlerwahrscheinlichkeit so hoch, dass man es besser ganz bleiben lässt…“
Das die Betriebsführung im Notbetrieb aufwendig ist habe ich nicht bezweifelt, aber es ist geregelt wie in einem solchen Fall zu verfahren ist. Mit der Einstellung „…dann lassen wir es lieber…“ ist niemanden geholfen. Fakt ist: wenn der Stecker SASPF gezogen ist heißt das nicht zwangsläufig das der Flugbetrieb steht. Es ist nur niemand Willens das Notverfahren anzuwenden.
Eine C-160 die 2-3 Wochen durch Afrika gondelt wird auch nicht täglich in SASPF gebucht.
@ amsi
Zitat:
„Eine C-160 die 2-3 Wochen durch Afrika gondelt wird auch nicht täglich in SASPF gebucht.“
Ja aber an der C160 die 2 – 3 Wochen durch Afrika gondelt werden auch keine überwachungspflichtigen Teile nach Lebenslaufakte in Afrika gewechselt !
@ all
Eigentlich ist die Lösung des Problems doch ganz naheliegend.
Wir hatten ja schon 30 Jahre DV-Systeme vor SASPF zur Steuerung, Planung und Dokumentation von Flugzeuginstandsetzungen im Einsatz. Das System der Technischen Betriebsführung auf dem Abgesetzten Rechner (AR).
Wenn wir nach Goose Bay verlegt haben, dann haben wir den AR und die ganze Peripherie in einen 20 Ft Container eingebaut und die einzelnen Terminals für die Arbeitssteuerung, Lebenslaufakte, usw wurden per Telefonleitung und Modem an den AR angebunden und der AR war mittels Telefonleitung oder Datenleitung an eines der Rechenzentren der Bw in Deutschland angebunden. Alteingeführte IBM Technik die einfach funktioniert hat und Spezial-Software, die für die Lw entwickelt und gepflegt wurden.
Im Prinzip muss eine Erneuerung der Betriebsführungssysteme auf eine „Abgesetzte Rechner Lösung“ hinauslaufen. Der notwendige Datenbestand muss vor Ort an der Stelle des Geschehens, des Flugbetriebes liegen und alle 24 Stunden kann während der Nacht ein Abgleich zwischen dezentralen und zentralen Datenbestand gefahren werden.
Wenn S/4 Hana eine cloudbasierte Lösung darstellt, die ständigen Zugriff auf einen Zentralrechner bei SAP oder der BWI erfordert, dann ist diese Lösung per Definition schon nicht für die Bw geeignet, denn im Konfliktfall werden als ersten die Datenverbindungen, die Netze angegriffen, wie man am Beispiel Baltische Staaten und Georgienkrieg 2008 usw. sehen kann.
Wir sind nicht die USA, die ihre Netze weltweit auch im Konfliktfall schützen können !
@amsi | 01. Februar 2019 – 8:29
den fehlenden Willen findet man teilweise nicht nur bei den Notverfahren.
„wenn man etwas will sucht man Wege, wenn man etwas nicht will sucht man Gründe“
„Alle sagten: Das geht nicht. Dann kam einer, der das nicht wusstet und hats einfach gemacht“
Erlebt man leider täglich, nicht nur bei SASPF, auch in unserer Gesellschaft.
Ich denke das könnte mit ein Hauptproblem sein.
@Nokrazul
Zumindest bei den Altsystemen haben Sie natürlich Recht. Wenn rechts und links Granaten einschlagen, dann steigt man ein und fliegt los. Damit kann ich problemlos eine Maschine aus dem Einsatzgebiet zurückholen. (Wenn das nicht ginge, dann hätten wir ja auch nicht jahrzehntelang mit Papierlösungen fliegen können) Es fehlen dann aber die Betriebswertfortschreibungen, die TCI Zeiten und Alles, was ich brauche um das Lfz auch langfristig sicher weiter zu betreiben. Wenn es nur um einen einzigen Einsatz geht, dann bekommen wir das hin. Wenn wir die Luftfahrzeuge aber noch etwas länger betreiben wollen, dann wird es nach einem Ausfall von SASPF (oder noch schlimmer: Der Verletzung der Datenintegrität durch z.B. Hacker) spannend für die Zukunft. Früher hatten wir die Daten auf Papier und konnten problemlos und sicher weiterfliegen. Zusammen mit einem Ersatzteilpaket war sogar ein völlig autonomer Betrieb, zum Teil über Monate möglich. Die EBM war dann das einzige, was der Heimatverband zur Info bekommen hat (Gutes Beispiel: Einschiffungen der Marine)
@OldGuy
Fähigkeiten wie Autarkie waren gefordert aber es gab kaum jemanden, der aufgeschrien hat, als sie doch nicht kamen. Viele hatten damals noch davon geträumt, dass die alten EDV Systeme (z.b. AMPS / Netlog) irgendwann aufgrund ihrer Überlegenheit SASPF ablösen würden. Aber gerade dieses Stillhalten hat dazu geführt, dass wir keine Autarkielösung bekommen haben.
Und zum Thema der Komplexität: Wenn ich z.B. sechs Hubschrauber mit einem Ersatzteilpaket nach Mali schicke, dann erscheint es in der heutigen Zeit schwer vorstellbar, dass es wahnsinnig kompliziert sein soll, die Datensätze auf einen lokalen Server zu exportieren und nach dem Einsatz die Datensätze mit den neuen Betriebswerten zurückzuschreiben. Genau das haben wir ohne SASPF nämlich in Papierform gemacht: Es wurde ein Ersatzteilpaket zusammen mit der GSD (Gerätestrukturdatei) an das Kontingent übergeben und die haben damit gearbeitet. Und hinterher wurde einfach alles wieder im Heimatverband eingepflegt. Wirklich kein Hexenwerk.
@amsi /E.I
Ja, die Verfahren sind geregelt, allerdings auch mit klaren Einschränkungen was Störungen oder Wechsel von Equipments angeht. Dann endet nämlich das Notverfahren gem. Vorschrift. Das hat nichts mit fehlendem Willen der Techniker zu tun. Und wenn ich es trotzdem mache (wie z.B. mit der EUA Lösung oder weil der Verteidigungsfall ausgerufen wird und wir auf alle Vorschriften pfeifen) dann verliere ich Betriebswerte und TCI Zeiten. Sofern man davon ausgeht, dass eine Krise oder ein Spannungsfall nicht mehrere Monate anhält, kann man das ggf. sogar machen. Wenn ich mich aber für einen echten Ernstfall vorbereite und auch ein paar Monate nach ersten virtuellen IT Schamützeln noch einsatzbereit sein möchte, dann ist das aus meiner Sicht suboptimal.
Es geht mir also nicht darum, SASPF generell zu verteufeln. In vielen Bereichen ist das ein echter Segen! Aber ohne Not bewährte und krisensichere EDV / Papierverfahren in der vordersten Linie durch ein sehr viel aufwändigeres System mit unsicherer Verfügbarkeit zu ersetzen, finde ich einfach nicht gut. Ich glaube auch, dass viele hier den notwendigen Aufwand selbst für einfachste Arbeiten in SASPF deutlich unterschätzen.
Ein kleines Beispiel: Wenn ein Lfz landet und der Pilot einen defekten Rechner meldet, der vom Mechaniker bestätigt wird, dann hat der Mechaniker früher zwei Zettel ausgefüllt, den alten Rechner ausgebaut, einen neuen im Lager empfangen und eingebaut. Fertig.
Mit moderner EDV wünscht man sich vielleicht, dass man die Seitennummer scannt, das defekte Gerät auswählt, einen Ausfallgrund angibt und vom System erfährt, wo man das Ersatzteil (mit notwendigem Einbausatz) abholen kann. Danach scannt man noch das neue Gerät und bestätigt den Austausch.
Sowas ist in SASPF Fiction! Hier existieren selbstgeschriebene, über 30-seitige DIN A4 Anleitungen wie und wo man PSP Element, Rückführungscode, Charge, Zustandscode usw. raussuchen muss um den Wechsel zu dokumentieren. Wohlgemerkt alles händisch in einer DOS-nahen Maske, ohne Scanner und teilweise ohne Plausibilitätsprüfung.