Mehr Spaß mit Logistik-Software: Da steht der Heli
Die Hubschrauber, ohnehin ein Sorgenkind der Bundeswehr, standen in den vergangenen Tagen zumindest zum Teil am Boden – und es lag noch nicht mal an den Drehflüglern. Sondern an der Logistik-Software SAS/PF, mit der die ganze Wartung und der Nachschub organisiert wird. Die Geschichten kursieren schon ein paar Tage in der Truppe, jetzt mal der Sachstand aus offizieller Sicht:
Die ganzen NH90-Transporthubschrauber wurden gegroundet, weil die Software upgedatet wurde (wer kennt das nicht vom heimischen Windows-Rechner). Jedenfalls, so die Angabe des Verteidigungsministeriums, sei „im Rahmen einer planmäßigen Software-Umstellung SASPF bei der Wartungsplanterminierung eine unklare Datenlage hinsichtlich der Restlaufzeiten von Wartungsintervallen NH90 aufgetreten“.Und ohne die Software läuft nix, weil „die Überwachung der Restlaufzeiten der verbleibenden Flugstunden bis zur nächsten Inspektion und die verbleibenden Kalendertage bis zur nächsten Inspektion ausschließlich mit Hilfe einer Transaktion in SASPF durchgeführt werden kann“.
Mit anderen Worten: keiner wusste mehr so genau, ob die Maschine noch fliegen darf oder eigentlich zum TÜV muss. Das heißt, wahrscheinlich wussten es die zuständigen Mechaniker sehr genau, aber der Computer sagte was anderes.
Die offizielle Ansage: „Ein Flugbetrieb NH90 ist weiterhin technisch möglich. Dennoch verzichtet das Heer bis zur Abstellung des Softwareproblems aus Sicherheitsgründen auf den Flugbetrieb.“ Immerhin gibt es bereits einen Patch, also eine Korrektur des Software-Updates, der jetzt schnellstmöglich eingespielt werden soll. Voraussichtlich, so heißt es, sei „mit Ablauf des heutigen Tages“, also am heutigen Mittwochabend, alles wieder im grünen Bereich.
Etwas anders gelagert scheint der Fall beim Seaking: Da waren über die Software Ersatzteile bestellt worden, die leider falsch waren. Weil sie keine Zulassung für Luftfahrzeuge hatten. Ich hab‘ nach entsprechenden Hinweisen da ebenfalls einen Software-Fehler vermutet, aber das dementiert das Ministerium: Da habe es eine Fehleingabe ins System gegeben, dadurch seien die falschen Ersatzteile bevorratet worden. Da war dann SAS/PF also offensichtlich unschuldig.
(Archivbild 2006: SeaKing über See – Bundeswehr/MFG5)
@Neuhier
Sie haben vollkommen recht – ohne funktionierendem ERP geht heute laut Plan nichts mehr. Vor allem bei einem reduzierten Personalstamm, der Listen eben nicht mehr von Hand erstellen und kontrollieren soll. Und da ist das Problem: Ein System, das Bestände und Zustände falsch beschreiben kann, ist nur unnütz, teuer und gefährlich. Mein Frage hierzu ist, werden die Bordbücher, Klatten etc eigentlich noch von Hand geführt ? Wenn „Ja“, was ist dann der Sinn des ERP ? Und warum grounded man dann eine gesamte Flotte, statt Daten locker nachzuerfassen? Wenn „Nein“ – wie soll das im Einsatz funktionieren? Die Streitkräfte der USA sind afik immer und überall einsetzbar. Dies ist der vorrangige Sinn von Streitkräften – an dieser Prämisse hat sich auch ein ERP zu messen und unterzuordnen.
Ich finde es sehr interessant, dass endlich auch hier, durch einen Stillstand der NH-90 Flotte SASPF etwas ausführlicher thematisiert wird.
Man kann nur allen zustimmen, die ein voll integriertes ERP-System fordern und auch durchsetzen. Allerdings sollte das Ganze immer mit Sinn und Verstand implementiert werden. Wenn also jemand der Meinung ist, dass SASPF zwangsläufig alle SinN (Systeme in Nutzung, oder Altsysteme) ablösen bzw. ersetzen kann, dann ist er meiner Meinung nach schief gewickelt. Aber was soll man dazu sagen, die Bundeswehr muss ja immer die eierlegende Wollmilchsau haben. Darunter geht es nicht. Selbst SAP ist es sonnenklar, dass ihr R/3 nicht zwangsläufig für alle nur denkbaren Prozesse genutzt werden sollte und kann, sonst hätten sie sich nicht so viel Gedanken um die UNIT PI (Prozess Integration) gemacht, die es ermöglicht, auf relativ einfache Weise Spezialsoftware in die Prozesswelt von SAP zu integrieren. Das Zauberwort heißt also Schnittstelle. Was in jedem halbwegs vernünftigen Industriebetrieb Standard ist, nämlich Spezialsoftware für Prozesse die nicht aus dem Wirtschaftsleben kommen, an das R/3 mittels PI anzubinden, findet bei der Bundeswehr keinerlei Betrachtung. Da gibt es Menschen, die jegliche Anbindung von Software unterbinden, weil sie ihr System nicht „fremdtriggern“ lassen wollen.
Nochmal zurück zum Kunstbegriff „SASPF“, den man sich hätte sparen können. Warum benennt jemand sein SAP „Standard Anwendungs Software Produkt Familien“, wenn die Familie aus nur einem einzelnen besteht? Aus meiner Sicht war der Gedanke seinerzeit ein anderer, man wollte eine kaufmännische Gesamtlösung um ein vernünftiges Controlling machen zu können und wollte Spezialsoftware mit einbinden. Schade, dieses Ziel wurde leider nicht weiter verfolgt bzw. von Einzelnen sabotiert. Das Ergebnis sieht nun jeder, der in Bereichen, in der nahezu perfekt funktionierende Spezialsoftware durch SASPF ersetzt wurde.
Eine Spezialsoftware, die über 20 Jahre in ständiger Zusammenarbeit mit dem Anwender entwickelt wurde kann niemals adäquat durch eine Standardsoftware, Familie hin oder her, ersetzt werden.
Ich stelle mir die Frage, ob es passieren könnte, dass Lfz eingesetzt werden, die zwar Störungen physikalisch aufweisen oder bei denen Konten überzogen wurden, das in einem unterstützendem IT-System jedoch nicht aufgezeigt wird. Die Software wird man ja übersteuern können…!?
Ist da Handlungssicherheit gegeben? Ab wann redet man eigentlich von unklarer Papierlage in diesem Kontext?
Bringt die Software innerhalb der Bundeswehr den Nutzen für den sie eingekauft wurde? (Außer schaffen einer Work/Life-Balance unter dem Aspekt von Reduzierung des Ressourceneinsatzes, wie oben beschrieben… *Ironie
@mwk:
„Und warum grounded man dann eine gesamte Flotte, statt Daten locker nachzuerfassen?“
Diese Frage ist ganz einfach zu beantworten. SASPF ist für einige Waffensysteme mittlerweile das „urkundliche“ System. Allein mit einem Bordbuch ist es leider nicht getan. Jedes Lfz hat neben dem Bordbuch auch eine Lebenslaufakte und die wurde quasi bei den Lfz, die in SASPF überführt wurden auch durch SASPF ersetzt. Jetzt muss man sich mal ein komplexes „modernes“ Waffensystem vor Augen führen. Es gibt z.B. beim Cougar, der gottlob nicht in SASPF geführt wird, ca. 3000 Einzelkonten, die überwacht werden müssen. Das Ganze verteilt auf weit mehr als 1000 Einzelgeräte. Dies ist leider mit einem Bordbuch nicht zu überblicken. Dafür braucht man eben Spezialsoftware, die damit umgehen kann und hoffentlich immer so ausgelegt ist, das ein Ausfall nicht möglich ist. Wenn eine Software dies kann und zusätzlich auch noch ohne Probleme autark genutzt werden kann, dann, ja dann sind wir nicht bei SASPF, sondern beim Altsystem, das abgelöst werden soll/wird.
Mhh. In vielen anderen Bereichen wird (zu Recht) darauf verwiesen, dass die meist geforderte „Goldrandlösung“ nicht praktikabel ist. Bei dieser Software wird aber genau dies gefordert.
Das System hat, wie jedes System, seine Vor- und Nachteile. Insgesamt ist es aber deutlich besser als alles was vorher in der Bw eingeführt war. Es krankt IMHO an einigen Entscheidungen, die auf Seiten der Bw getroffen worden sind. So ist es z.T. unnötig komplex. Außerdem sind zuvor aufgestellte Grundsätze, wie „Organisationsänderungen vor Softwareänderungen“ zu oft nicht eingehalten und zusätzlich „Altsysteme“ in SASPF nachgebaut worden. Die Folge ist eine nochmals erhöhte Komplexität durch die vielen kundeneigenen Erweiterungen.
Zum eigentlichen Thema: Der beschriebene Fehler tritt nur unter sehr eingegrenzten und leicht vermeidbaren Rahmenbedingungen auf. Ein Workaround wäre damit recht einfach umzusetzen, aber man will halt grad nicht fliegen…
btw: Technisch sind die (Waffen-)Systeme der Bw von SASPF unabhängig. Ein rotes Kreuz in SASPF verhindert also keinen Start.
@as:
Es ist schon sehr offensichtlich, dass Sie kein „Betroffener“ in Sachen Instandhaltung am Lfz sind und dass Sie die/das Altsystem nicht wirklich kennen, d.h. nie wirklich damit gearbeitet haben.
Hätten Sie eine technische Einsatzsteuerung, eine L-Aktenstelle oder aber auch eine Arbeitsplanung vor und nach Einführung kennen gelernt (nicht nur gesehen) dann würden Sie keine solche Aussagen über SASPF und die Altsysteme tätigen. Übrigens verhindert zwar SASPF nicht den Start, aber die Anweisung, dass SASPF das maßgebliche System ist und somit bei unklarer Datenlage nicht geflogen werden darf. Sie glauben doch nicht wirklich, dass die Truppe, die ohnehin nur noch ein paar Flugstunden zur Verfügung hat auch noch auf diese freiwillig verzichtet?
Eines zeichnet SASPF auf jeden Fall aus, Excel hat in der Truppe einen nie geahnten Boom erlebt. Denn ohne inoffizielle Sparesysteme mit Excel wäre der Überblick vollends verloren.
Die komplette NH90-Flotte steht allen Ernstes wegen einer dummen Software-Panne beim SASPF-System. Hier in AG wird fleißig darüber diskutiert, weil – wenn auch nur temporär und eigentlich bereits im Ansatz vermeidbar – ein unvorstellbares Desaster. Sieht man dagegen in den Medienwald besteht „Null“ Echo. Die Sache ist wohl zu unspektakulär, es geht ja nicht um „Killerdrohnen, Spionage-UAV wie EuroHawk und TRITON, Beinahe-Abstürze wie in Termez, oder auch nur zum zigsten Male um das G36, oder die Kaserne wird geschlossen, jene doch nicht, usw. bis hin zu FKK“.
Oder anders gefragt, geht der Masse der Deutschen etwa die Verteidigungs- und Einsatzbereitschaft unserer Bundeswehr schon längst am „Arm“ vorbei? Betreibt eine Mehrheit unserer Parlamentarier als Lobbyisten nur noch Industrie- und Wahlkreispolitik, statt aktive und der aussenpolitischen Gesamtlage gerechte Verteidigungspolitik? Ist das alles etwa ein gegenseitiges „Einlullen“ von BMVg und Parlament durch wechselseitige Expertiselosigkeit, Realitätsverdrängung und bewußte Desinformation über unsere zunehmend zur Statistentruppe und zum Haushaltsmoloch werdende, sich nur noch selbst per 41-Stundenwoche, Attraktivitäts-. Teilzeit-, Wohlfühl- und Gender-Programme beschäftigende und zum reinen Selbstzweck sich degradierende Bundeswehr?
Wahrscheinlich „Ja“, wenn man die offizielle BMVg-Ansage “Ein Flugbetrieb NH90 ist weiterhin technisch möglich. Dennoch verzichtet das Heer bis zur Abstellung des Softwareproblems aus Sicherheitsgründen auf den Flugbetrieb“ so liest. Verdeutlicht und faktisch heißt diese BMVg-Ansage doch, „Die Software der kompletten NH90-Betriebssteuerung und -Logistik ist vorübergehend defekt, die stillgelegte betriebliche NH90-Hardware ist jedoch nach wie vor funktionstüchtig, aber aus Sicherheitsgründen wird auf eine Betriebsfortsetzung verzichtet“.
Wieder einmal so eine geradezu typische, absolut hohle und ziemlich dumpfe Platitüde des BMVg-PrInfo-Stabes und/oder des nachgeordneten PIZ-Heer. Was ein solches SASPF-Desaster im echten Einsatzfall bedeuten würde – da offensichtlich keinerlei offizielle Back-up-Lösungen oder Alternativen in der Bw vorhanden sind – wagt keiner anzusprechen und das interessiert anscheinend auch keine S.. im BMVg, im Parlament und in der Öffentlichkeit!
Ganz im Gegenteil, statt über Back-Up-Lösungen wie z.B. „IBM Tivoli Storage Manager for Enterprise Resource Planning (ERP)“ nachzudenken bzw. sich zu fragen warum – da sicherlich vorhanden – solche versagt haben, träumt man völlig unbeeindruckt im BMVg sowie in dessen Ämtern weiter von SASPF, auch beim SEA LION und das im weltweitem Bord- und Seeflugbetrieb! Und die parlamentarischen Kontrollorgane sowie die Führungsspitze des BMVg sehen offenbar in aller Seelenruhe und Gelassenheit dem Menetekel zu. Von einem Aufschrei gestern im Verteidigungsausschuß hat man jedenfalls noch nichts gehört!
@as:
Das kommt wohl sehr auf Sichtweise des Betrachters an!! An der Basis muss man damit Arbeiten!!
@Lippi:
„Das Problem ist eben nicht SASPF, in keinster Weise. SASPF ist ein ganz feines System, wenn man es bedienen kann.“
…
„Es gibt hier bei uns keinerlei Probleme, weder bei der Logistik mit SASPF noch in der Technik mit SASPF.“
Jetzt nennen sie bitte mal Ross und Reiter. Mir ist kein fliegender Verband der Luftwaffe und/oder der Marine bekannt, bei dem es nicht zu verheerenden Problemen seit der schrittweisen Umstellung kam. Bei C-160 haben sich die Durchlaufzeiten in den Docks bei der HPO zum Teil um Faktor 1,5 erhöht, weil die Ersatzteilversorgung einfach nicht zeitgerecht möglich ist. Können Sie sich vorstellen, was das für eine Flotte bedeutet, die nur begrenzte Dockplätze für eine HPO zur Verfügung hat, wenn ein LFZ die 1,5 fache Zeit im Dock steht und die auf einen Dockplatz wartenden und eingeplanten LFZ, die abgeflogen sind, nicht in die Inspektion kommen können? Ja, sie bleiben stehen oder werden für teures Geld zu Industrieinstandsetzung verbracht.
Der Überblick in einem System ohne wirkliches Statusboard oder einen Flugplan, der sämtliche Flugbewegungen eines Tages anzeigt, ist in einer technische Einsatzsteuerung in einem Einsatzverband mit SASPF nicht mehr gegeben, diese Kameraden sind einfach nur aufgeschmissen. Die Folge ist, dass sich hier Fehler einschleichen, die mangelnder Übersicht geschuldet sind. Es muss aber wohl wieder soweit kommen, dass auch hier erst materieller und personeller Schaden entstehen muss, bis jemand reagiert.
Dazu zwei Zitate aus dem Artikel „Ohne SASPF fliegt kein NH90“ auf luftwaffe.de:
„[…] die zentrale und einmalige Datenspeicherung sorgt für Transparenz und Effizienz.“
„Was die Einführung von SASPF im Zusammenhang mit dem neuen Hubschrauber aber wirklich bemerkenswert macht ist die Tatsache, dass selbst der „Klarstand“ der Flugtauglichkeit durch das System ausgewertet wird. […] Wenn dieses „intelligente“ System kein Beitrag zur Flugsicherheit ist. “
Eine Frage an die Fachleute hier:
Bedeutet das auf Deutsch gesagt, dass bei Problemen mit der Netzwerk-Anbindung einzelner Standorte im Ernstfall kein Hubschrauber mehr abheben darf bzw. die Piloten und Mechaniker den Klarstand ihres Fluggerätes nach Bauchgefühl oder improvisierten Listen beurteilen müssen?
Also: grundsätzlich ist Flugbetrieb auch bei Ausfall oder eingeschränktem Betrieb von SASPF möglich. Das wird auch über die BesAn zum Betrieb SASPF geregelt. Dafür werden aber bestimmte Voraussetzungen vorgeschrieben. Da näher darauf einzugehen würde hier zu weit führen, da das Ganze sehr komplex ist. Wichtig hierbei ist das ein Flugstundenvorrat des/der Lfz bekannt ist und eben „zu Fuss“ fortgeschrieben wird, bis SASPF wieder verfügbar ist. Die ganze Flotte vorübergehend an Masse zu legen ist natürlich bequemer, da die Nachpflege der Daten entfällt.
ZU SASPF bei C-160: bei längeren LTB´s über mehrere Tage werden die relevanten Daten nachgepflegt. Bei Störbehebung ausserhalb des Heimatgeschwaders ohne SASPF Anbindung wird nach Behebung der Störung die entsprechende Seite des Bordbuches an das Heimatgeschwader z.B per Fax (urkundlicher Nachweis!) übermittelt und nach Rückkehr in den Verband in SASPF nachgepflegt. Werden Lfz über längeren Zeitraum im Ausland ohne SASPF Anbindung betrieben (LtStp, z.B. Mali, Ghana etc.) werden relevante Daten täglich übermittelt und im Heimatverband gepflegt.
Ich bin wirklich kein Freund von SASPF. Vieles wird erschwehrt, vor allem dauert alles viel länger. Vorrang 1 Störung wurde mit Einführung von SAP quasi abgeschafft.
@Der_sich_immer_wundernde
Sie sprechen mir aus der Seele! Leider wurden diese und viele andere Probleme mit SASPF immer wieder aufgezeigt und gemeldet! Aus meiner Sicht werden sie leider ignoriert bzw. aus Unwissenheit schön geredet! An der Basis kämpft man seit Einführung SASPF täglich mit der Übersichtlichkeit, Datengenauigkeit, Kontenführung und langwierigen Eingabe von Informationen bzw. Flugplänen. Im Altsystem waren diese Probleme nicht ansatzweise gegeben.
@Der_sich_immer_wundernde
Stimmt, ich bin kein „Betroffener“ im Bereich Lfz-IH und ich kenne die entsprechenden Altsysteme nicht. Ich habe seinerzeit mit dem Altsystem der Instandsetzungstruppe (Heer) arbeiten dürfen und kenne das SAP der Bw recht gut.
Das Grundproblem m.E. nicht das System, sondern die oft unflexible Vorschriften-/Weisungslage. Mit SASPF kann man allerdings andere Probleme prima verstecken/verschleiern. Dieser spezielle Fehler war/ist leicht zu umgehen. Somit wäre die Datenlage anschließend eigentlich klar und ein Grounding nicht notwendig.
Zur Truppen-Excellösung: Teilweise fehlt es einfach nur Ausbildung (ja, die Erstausbildung BWI ist grottig). In Teilbereichen werden die Möglichkeiten von SASPF einfach nicht (gut) genutzt. In anderen Bereichen fehlt allerdings eine weitere Detailierungsebene.
Persönlich kann ich mit Excel in weiten Teilen ganz gut leben, man kann damit seine Daten sehr schnell ins System bekommen… :)
Nachtrag:
Das SAP der Bw ist ein logistisches System. Es soll die Flugbewegungen überhaupt nicht tracken, sondern die logistische Einsatzbereitschaft sicherstellen.
@as
Der große Unterschied zwischen einem Altsystem vom Heer und einem Altsystem der Luftwaffe/Marineflieger besteht darin, dass sich die „Fahrzeuge“ der Luftwaffe/Marineflieger in 3 Dimensionen bewegen und bei einem Systemausfall nicht einfach rechts ranfahren können.
Und ich glaube nicht, dass hier die Vorschriften/-Weisungslage das Problem ist, den die ursprünglichen Vorschriften/BesAn wurde ja für SASPF neu geschrieben (BesAn 310/4321). Und wenn man sich so eine BesAn mal durchliest, muss man sich schon sehr wundern. Übrigens, kann man hier unter Nummer 102 schön nachlesen, unter welchen Umständen ein Notverfahren bei Ausfall SASPF möglich ist.
Auch das mit der Ausbildung SASPF in der Materialerhaltung sehe ich etwas anders. Meine Erfahrung geht eher dahin, dass alle die eine Ausbildung genossen haben im Anschluss erst richtig frustriert sind, weil sie wissen was auf sie zukommt und weil sie ebenfalls wissen, dass offensichtlich kein Weg daran vorbei geht.
Ich schlage jedem, der von diesem System überzeugt ist vor, mal ein Praktikum in einem Einsatzverband in der Einsatzsteuerung zu machen und verantwortlich Luftfahrzeuge für den Flugbetrieb einsetzt. Viel Spaß dabei!
@ as
SASPF soll wenn vollumfänglich eingeführt eben NICHT nur logistische Einsatzbereitschaft sicherstellen. Die L-Akten der Lfz werden geführt, Flugpläne erstellt und bearbeitet, Wartung und Instandsetzung abgearbeitet, und sei es nur ein simpler PostFlight-Check wofür ich keine Logistik brauche. Aber wenn ich den Check in SASPF nicht pflegen kann hebt der Flieger auch nicht ab.
@as
zum Nachtrag:
„Das SAP der Bw ist ein logistisches System. Es soll die Flugbewegungen überhaupt nicht tracken, sondern die logistische Einsatzbereitschaft sicherstellen.“
Und genau diese Erkenntnis sollte sich durchsetzen!!!
Stattdessen wird den Fliegenden Verbänden SASPF als, natürlich neben vielen anderen Bestandteilen, Mittel zur Betriebsführung Technischer Gruppen verkauft.
Ich hoffe Sie verbreiten Ihre Kenntnis an die richtigen Stellen.
@Vtg-Amtmann: „… Oder anders gefragt, geht der Masse der Deutschen etwa die Verteidigungs- und Einsatzbereitschaft unserer Bundeswehr schon längst am „Arm“ vorbei?…“
Offensichtlich schon, da wir seit 70 Jahren keinen Krieg kennen kann auch niemand den evtl. Nutzen einer funktionierenden Landesverteidigung einschätzen. Dafür aber ne Menge schein-pazifistischer Blabla (z.B. „Soldaten sind Mörder“).
Und wenn ich die Diskussion hier so verfolge frage ich mich inwieweit die Bw überhaupt in der Lage ist dieses Land zu verteidigen. Sie macht eher den Eindruck einer Sandkasten-Armee bzw. Männer-Spielplatz.
Außerdem: Haben die Russen auch so eine funktionierende (*ggg*) Software wie wir? Haben die auch eine abgespeckte Lagerhaltung? Wohl eher nicht, sonst würden die mit ihren Fliegern kaum bis Gibraltar kommen.
@AMSI
L-Akte hat schon etwas mit Logistik (Instandhaltung) zu tun.
Flugplanerstellung/-bearbeitung in SAP wär mir neu. Mit welchen TAC macht man dies?
SASPF aus der Sicht der Truppe:
Zitat @ Rana: „SASPF ist im Vergleich zu AMPS eine untaugliche Steinzeitlösung mit vollkommen unrealistischen Ansätzen, wie üblich werden halt dann Prozesse entwickelt um das Gurkensystem am laufen zu halten und den Entscheidern weiterhin ihre ach-so-tolle Leistung vorzugaukeln!“
Zitat: @ Der-sich-immer-wundernde
„Selbst SAP ist es sonnenklar, dass ihr R/3 nicht zwangsläufig für alle nur denkbaren Prozesse genutzt werden sollte und kann, sonst hätten sie sich nicht so viel Gedanken um die UNIT PI (Prozess Integration) gemacht, die es ermöglicht, auf relativ einfache Weise Spezialsoftware in die Prozesswelt von SAP zu integrieren. Das Zauberwort heißt also Schnittstelle. Was in jedem halbwegs vernünftigen Industriebetrieb Standard ist, nämlich Spezialsoftware für Prozesse die nicht aus dem Wirtschaftsleben kommen, an das R/3 mittels PI anzubinden, findet bei der Bundeswehr keinerlei Betrachtung.
Da kann man nur sagen, „so ist es“. Die Truppe hatte vor der SASPF Einführung Spezialsoftware für jeden Anwendungsfall. Diese Software war extrem ausgereift und hätte bei jedem neuen Waffensystem die Aufgaben übernehmen könnnen. Selbst bei einem so „zivilen“ Anwendungsfall wie Lagerverwaltung, Buchführung und Ersatzteil- und Verbrauchsmaterialbestellung war das Altsystem ZTBÜ AR (Zentrale Truppenbestandsübersicht Abgesetzter Rechner) jeder SASPF Anwendung haushoch überlegen. Mittels dieser Anwendung war es jeden Nachschubmeister der Bw möglich jedes vorhandene Ersatzteil innerhalb der Bw aufzufinden, auch wenn es bei dem Verband xyz lag und nicht zentral im Depot. Der große Vorteil dieser Datenbankanwendung war, das die extrem große Anzahlt von Versorgungsartikeln, mehrere hunderttausend verschiedenener Artikel, in einer Datenbank zentral verwaltet werden konnten. Größe Möbelverkaufsfirmen, die einen ähnlich hohen Artikelbestand haben, arbeiten heute noch mit dieser Anwendung auf einem Zenralrechner.
Die Spezialsoftware „Betriebsführungssystem Werften“ , BFW und „Betriebsführungssystem Technik“, BFT erlaubte von der jährlichen Instandsetzungsplanung, der Aufteilung der Instandsetzung auf Industrie- und Eigenkapazitäten auf Waffenssystemkommandoebene, der Auftragsvorbereitung, Durchführung und Überwachung einer großen Flugzeuginspektion auf Verbandsebene, und der Autragserteilung auf Teileinheitsebene, an einzelne Werkstätten für eine zeitgerechte, in dem gesamten Arbeitsablauf integrierte Ausführung der Arbeiten, eine geschlossene Abbildung und Nachweisführung des gesamten Prozesses der Flugzeuginstandsetzung oder auch der Baugruppeninstandsetzung, z.B. Fahrwerksüberholungen usw.
Warum hat man diese Anwendungen aufgegeben und hat SASPF für die Bw-Anwendungen weiter entwickeln lassen ?
Scharping wollte mit der Privatisierung der IT-Landschaft der Bw eine gigantische Wirtschaftsförderung für SAP Deutschland bewerkstelligen. Der ursprüngliche Vertrag für BWI sah ein Volumen von 7 Mrd Euro aufgeteilt in 10 Jahresscheiben a 700 Mio Euro vor. SAP hat davon gigantisch profitiert und sollte als IT-Anbieter für die amerikanischen Streitkräfte die Entwicklungskosten bezahlt bekommen.
Aber:
Wie schon festgestellt wurde, sollte sich die Bw an die SAP-Strukturen anpassen und nicht umgekehrt. Dies ist weitgehend nicht erfolgt. Aus ursprünglich 3 gedachten Anpassentwicklungen bei SAP-Software wurden über 100 Entwickungen. Wichtig ist dabei, dass diese Maskenanpassung bei jeder Sofware Release neu getätigt werden muss. Das dies bei Tagespreisen von 2000 Euro für einen SAP-Mann ein gigantisches Nachfolgegeschäft für SAP ist, ist offensichtlich !
Übrigens:
– Die Lufthansa Technik wartet ihre Flugzeuge in Hamburg ohne ein SAP-Betriebsführungssystem für die Technik.
– Airbus versorgt die A400M ohne SAP-Anwendungsprogramm. Es soll deshalb z.Zt noch ein Schnittstellenproblem bei der Überführung der Airbus-Stammdaten in das Bw-A400 M System geben
– Die USA haben für die Einsatzsteurung der Flugzeuge auf einen Flugzeugträger als Notsystem ein sogenanntes „Witch-Board“, ein Hexenbrett. Dies ist ungefähr zwei Meter lang und tut die physischen Maße des Flugzeugträgers abbilden mit den möglichen Stellplätzen für die Flugzeuge. Jedes Flugzeug ist ein kleiner Magnet, der je nach Rüstzustand mit einer farbigen Markierung usw. versehen ist.
Man kann also sofort mit einem Blick grafisch den jeweiligen Abstellplatz und den jeweiligen Einsatzustand, Rüstzustand eine Lfz erfassen.
Den Praktikern einer Einsatzsteuerung eines Geschwaders erzähle ich damit nichts Neues. Wir haben dies genauso als stromunabhängiges Backup-System.
Also SAP war Scharpingsche Wirtschaftsförderung für SAP, Walldorf. Das Ergebnis für die Truppe ist aus Sicht der Auftraggeber, der Politiker zweitrangig, wie immer bei deutschen Rüstungsprojekten. Die Truppe muss jetzt leider damit leben.
Ein alter Witz beschreibt den Zustand von SAP für die Truppe noch immer am Besten.
Ein Mann bestellt bei einem Schneider für sich einen neuen Anzug. Bei der Abnahme stellt der Kunde fest, der linke Ärmel ist zu lang, der Rechte zu kurz, ebenso ist das linke Hosenbein zu lang, das rechte Bein zu kurz. Der Schneider versucht sein möglichstes mit Stecknadeln zu korrigieren und gibt den Mann dann noch den Rat, immer nach rechts gebeugt zu gehen, dann wird die linke Seite gestreckt und rechts verkürzt.
So ausgestattet geht er auf die Straße. Zwei Männer beobachten ihn dabei. Der eine sagt: „So ein armer Krüppel“, antwortete der Andere „aber einen guten Schneider hat er gehabt, wie der die Fehlstellung im Anzug eingearbeitet und korrigiert hat ist schon spitze“.
@ as
so gesehen können Sie alles irgendwie mit Logistik in Zusammenhang bringen. Ist mMn zu weit hergeholt. Die TAC´s kann ich nicht auswendig, sind ja auch ein paar. Dafür gibt´s Favoriten-Ordner. Wie Der_sich_immer_wundernde oben schon schrieb: es ist jeder gerne eingeladen sich SASPF in einem fleigeneden Verband aus Sicht eines Betriebsführungsmeisters in der EinsSteuerung oder L-Akte mal anzuschauen.
Tja, für manche Entscheidungsträger fängt die Logistik eben erst dort an wo die Logik aufhört …
@as
Flugplan anlegen: /ISDFPS/LMFP01, Flugplan bearbeiten: /ISDFPS/LMFLP1
und noch 6 andere. Aus der Sicht eines Logistikers stimme ich Ihnen 100 %ig zu, eine feine Sache, aber für Einsetzer/Materialerhalter ist das System eine Katastrophe. Im Übrigen liefert das Programm auch nach Durchführung des Workarounds immer noch keine übersichtliche Darstellung, wie sie vor dem Update immerhin leidlich vorhanden war.
@ Münchhausen
+1
Wir haben unseren Ausbilder für den IH-Fachkraft Lehrgang damals erstmal in die Abläufe einer technischen Gruppe im fliegenden Verband einweisen müssen, sonst hätte die Ausbildung mal gar keinen Sinn gemacht. Als wir ihm dann AMPS vorgeführt hatten war die Reaktion dem entsprechend. (Oh, so einfach geht das!! Und so übersichtlich!!!). Noch Fragen?
@AMSI
… „Als wir ihm dann AMPS vorgeführt hatten war die Reaktion dem entsprechend. (Oh, so einfach geht das!! Und so übersichtlich!!!). Noch Fragen?“
Tja, was soll man sagen. Es gibt halt immer noch Menschen, die glauben, dass eine Ausbildung für ein Materialerhaltungssystem anhand eines Staubsaugers (wurde so in der Ausbildung für BMR gehandhabt) als Objekt für die Materialerhaltung vergleichbar mit einem komplexen Waffensystem ist.
Nach der simulierten Instandsetzung eines Bo 105 Rotors während der Schulung hatte mein Hubi 5 Rotorblätter verbaut, der meines „PC-Nachbarn“ nur 3 :-). Aber wie gesagt: SASPF ist super, alles wird gut.
Wir.Wurschtln.Weiter
@as @Georg
Flugplan anlegen geht mit
/N/ISDFPS/LMFL01 und taktisches Kennzeichen des Fliegezeuges
aber natürlich nur dann wenn Sie die nötige Berechtigung dazu haben.
Flugübersicht gibt es auch, man kann es natürlich auch mit einem Holzmodell nachbilden.
Stichwort „BMR“: nun, um Basics darzustellen mag ein Staubsauger genügen;)
Ich frage mich hier aber, wie es kommt dass jahrelang eine Forderung nach Autarkie im Raum steht, die dann doch nicht mehr ganz so relevant ist wenn da ein IT-System das nicht kann. Anpassen der Anforderung an die Lösungen der Industrie?
Wie macht man das nun auf den Schiffen mit der „Autarkie“?
@Handheld
Dafür sind zwei Projekte in der Pipeline. Einmal für F-125 und einmal für alle anderen schwimmenden Einheiten.
IS-DFPS ist ja seinerzeit von und für die Bw entwickelt worden…
Vermutlich lief es ähnlich wie bei der 1. PzDiv. Da waren u.a. die Prozesse auch erstmal auf einer zu hohen Ebene ohne wirklichen Praxisbezug modelliert.
@AMSI
Das war mit grottig gemeint. Ausbilder, frei von jeder militärischen Kompetenz und Erfahrung (gerade im DFPS-Modul) erzählen einem irgendwas (oft ebenfalls ohne Praxisbezug).
@ Der_sich_immer_wundernde
Zumindest kann man für beides eine IH-Meldung erstellen ;)
@ rr
Ich bezweifle gar nicht, dass dies mit SASPF geht, es macht nur keinen Sinn.
Und für eine Technische Einsatzsteuerung ist ein grafisches Witchboard (übrigens ein Metallboard und kein Holzmodell, wegen den kleinen farbigen Magneten als Flugzeuge) ein wesentlich besseres, übersichtlicheres und absolut ausfallsicheres grafisches Statusübersicht- und Steuerungssystem (wenn man mal von einem möglichen Erdbeben als Ausfallgrund absieht).
@ all
SAP wird auch in der Ausbildungssteuerung, also in der Planung, Entwicklung (Lehrplan) und Steuerung von Lehrgängen (nach Einführung SAP „Trainings“ genannt) in Form des Moduls IAMS (Integriertes Ausbildungs Management System) genutzt. Hier hat man zumindestens für die Erstellung des Lehrplans ein externes Modul dazugekauft und integriert. Zwar nicht besonders gut und komfortabel aber immerhin funktionsfähig.
Die Herausforderung für das IAMS- System ist z.B die Lehrgangsplanung und Steuerung der Durchführung für die OSLw in FFB. Wer das alte Planungstool kennt, eine 6 m lange und 2 m hohe Planungstafel, wo jede Stunde innerhalb eines Lehrganges von 9 Monaten ein zwei Quadratzentimeter großes Kärtchen darstellt, und dies für 25 Klassen parallel, kann sich vorstellen wie extrem diffizil dieser Planungsprozess mit den Abhängigkeiten, vorhandenes Lehrpersonal, vorhandene Hörsäale, externe Ressourcen wie Schießbahnen, Truppenübungsplätze, Überlebensausbildung See und Land usw. ausfällt.
Diesen Prozess in IAMS für bis zu 25 Klassen (Hörsäale, Trainings) parallel bei einer Aufteilung der vorhanden Ressourcen und deren kurzfristige Umplanung ( z.B. wegen Krankheit Ausbilder oder Wassereinbruch Hörsaal (das baufällige „blaue Palais“) durchzuführen ist extem schwierig.
Insider berichteten selbst die Putzfrau durfte nicht allein in diesen Raum mit dem Planungsboard gehen. Sie hätte ja ein paar Kärtchen umhängen können und das Chaos damit ausgelöst. Man kann sich vorstellen, wie so eine Ausbildungssteuerung bei einen Ausfall des SASPF-Systems, z.B. nach einem Systemupdate wie jetzt bei den Hubschraubern, aufgeschmissen wäre.
PS: Ich vermute, sie betreiben ihr altes 12 qm großes Planungsboard als Backup-System ganz ohne Strom, ohne SAP, ohne Citrix-Lizensengpässe, ohne Update-Probleme weiter.
@Handheld
Ich würde gerne nochmal eine Ihrer gestellten Fragen aufgreifen!
„Ich stelle mir die Frage, ob es passieren könnte, dass Lfz eingesetzt werden, die zwar Störungen physikalisch aufweisen oder bei denen Konten überzogen wurden, das in einem unterstützendem IT-System jedoch nicht aufgezeigt wird. Die Software wird man ja übersteuern können…!?“
Meines Wissens nach könnte das nicht nur passieren, sondern es passiert scheinbar regelmäßig!!! Die Aussage eines Technikers eines TaktLwG mir gegenüber war:
„Seit wir Luftfahrzeuge mit SASPF führen ist es uns schon mehrfach passiert, dass wir Luftfahrzeuge für Flüge eingeplant und vorbereitet haben, bei denen mind. eine Inspektion abgelaufen war. Aufgefallen ist es nur durch Zufall!“
Den Wahrheitsgehalt dieser Aussage halte ich übrigens für sehr groß, zumal das nicht die einzige Aussage dieser Art war, die mir gegenüber ausgesprochen wurde.
Wenn ich solche Aussagen höre, dann wächst auch in diesem Bereich bei mir die Sorge, dass Besatzungen und Paxe mit Luftfahrzeugen losgeschickt werden, die nur in der digitalen Welt von SASPF ein „TK“ (technisch klar) haben, in der Realität jedoch ein rotes Kreuz haben, also in keinster Weise einsatzbereit sind. Dabei sei dahingestellt, ob dies passiert, weil ein Techniker in den unübersichtlichen Daten etwas übersieht, ein anderer versehentlich in Unkenntnis eine falsche Inspektion fortschreibt, ein technisches Debriefing, also die Fortschreibung von bei einem Flug verbrauchtem Leben nicht einträgt, oder aber die Software nach einem Patch mal wieder falsche Daten ausspuckt. Wer will das in Zukunft, wenn die Einsatzverbände mit allen Luftfahrzeugen und ausschließlich mit SASPF fliegen müssen, noch überblicken.
Ich habe einfach nur Angst, dass früher oder später jemand aus diesem Grund zu Schaden kommt.
@rr | 05. Februar 2015 – 13:30
„@Handheld
Dafür sind zwei Projekte in der Pipeline. Einmal für F-125 und einmal für alle anderen schwimmenden Einheiten.“
Ich gehe mal schwer davon aus, dass diese Projekte die Sie ansprechen auf einer Satellitenverbindung basieren. Wenn ja, ist Ihnen bewusst, wie lange die Laufzeit des Signals, also der Ping über eine Satellitenverbindung ist und wie träge dieses ohnehin schon träge System dann wird? Ich vermute mal, das Ganze wird ein „Rohrkrepierer“ und wird die Pipeline nie verlassen.
Die Verbindung wird sicherlich über Satellit stattfinden, allerdings nicht 24/7, sondern nur wenn Zeit und Chance ist. Das autarke System soll nötigenfalls über einen längeren Zeitraum ohne Verbindung zum Zentralsystem genutzt werden können.
@rr
Vermutlich ist die Leistungsbeschreibung mit den gleichen Worten wie bei Ihnen formuliert: … soll nötigenfalls …
Solche Formulierungen sind bei der Industrie als Weichmacher in den Verträgen sehr beliebt. Denn, „soll“ heißt nicht „muss“!
Wie lässt sich das Konzept, dass es nötigenfalls auch ohne Zentralsystem laufen soll mit der Datenhoheit bei SASPF vereinbaren? Welche Daten bleiben im Zentralsystem gültig, wenn sowohl im Zentralssystem, als auch im autarken System an einem identischen Artikel (Gerät, Luftfahrzeug, Flug, …) Daten geändert werden und die Daten bei nächster Verbindung ins Zentralsystem übertragen werden?
@ Der_sich_immer_wundernde
Vermutlich werden im autarken, also abgesetzten System die Datensätze durch den Bediener vor Ort geändert und im Zentralsystem z.B. bei den Stammdatensätzen z.B. bei Wartungsplänen usw. werden die Daten durch die Mitarbeiter WaSysKdo Lw oder entsprechender Nachfolgeorganisation gleichzeitig geändert werden.
Interessant wird es wenn das abgesetzte System das nächste Mal Kontakt mit dem Zentralrechner hat und eine Konflikt in der Datenbankstruktur feststellt. Was passiert dann ?
siehe auch „Integritätsbedingung Datenbanken“
http://de.wikipedia.org/wiki/Integrit%C3%A4tsbedingung
Dann wird es eine „in Konflikt stehende Kopie“ eines Datensatzes auf dem abgesetzten Rechner zu dem Hauptdatensatz auf dem Zentralrechner geben. Dieser Konflikt kann aufgrund von Löschrechten und Abhängigkeiten zu anderen Rechten der einzelnen Datenfelder z..T. automatisiert gehandelt werden und der Rest wird wohl eine händische Nacharbeit durch den Bediener werden, also Neueingabe durch die Einsatzsteuerung, L-Akte usw nach Herstellung der Datenverbindung zum Hauptrechner.
siehe auch „Referentielle Integrität einer relationalen Datenbank“
http://de.wikipedia.org/wiki/Referentielle_Integrit%C3%A4t
Es gibt dazu noch keinen Vertrag. Wie der Abgleich zwischen autarkem und Zentralsystem genau abläuft steht noch nicht fest. Wenn das autarke System für diverse „Artikel“ die Datenhoheit hat kann man diese gegen Bearbeitung im Zentralsystem sperren, da muss nichts neues erfunden werden.
@Georg
Das ist genau der Punkt den ich sehr Laienhaft versucht habe darzustellen. Die Idee von @rr, Datensätze gegen die Eingabe im Zentralsystem zu sperren hört sich in der Theorie sehr vernünftig an, ist aber in der Praxis wie bei @Georg beschrieben so nicht durchführbar. Es werden am Ende des Tages immer eine Menge Datensätze offen bleiben, die dann manuell durch wen auch immer korrigiert werden müssen.
Interessant finde ich auch, dass schon seit einiger Zeit davon gesprochen wird, dass für SASPF ein autarkes System kommt, vor allem in Anbetracht der Aussagen von @rr, dass es noch keinen Vertrag gibt und dass noch nicht einmal ein genaues Konzept vorhanden ist für einen aus meiner Sicht essentiellen Punkt eines autarken Systems. Allein der Umstand, dass es Satellitenverbindungen gibt und damit ja ein autarkes System gebaut werden kann erscheint mir ein wenig dürftig! Vermutlich sind noch nicht mal die Gelder dafür eingestellt. Dann bin ich mal gespannt, wann eine autarke SASPF-Lösung eingesetzt wird und wie lange es dann noch dauern wird, bis sie funktionsfähig arbeitet. Es bleibt spannend!
Ironie an:
An die SASPF Jünger: Immer dran bleiben, das wird schon irgendwann!!!
Ironie aus!
Im Bericht der Firma KPMG steht das die F-125 nur mit SASPF betrieben werden kann. Das ist zwar schlicht nicht richtig aber SASPF auf F-125 wird umgesetzt.
Ach ja: koste es was es wolle.
@rr
Ja, der Bericht von KPMG, was soll man davon halten. Mal ganz ehrlich, dieser Bericht ist für mich nur eine Lebens-/Amtsversicherung für UvdL. Die hat das ganz geschickt gemacht. Die kann jetzt immer darauf hinweisen, dass die falsche Betrachtung nicht durch ihr Amt oder durch sie selbst sondern durch die Unternehmensberatung gemacht wurde und sie nur der Empfehlung gefolgt ist. Aber darum sollen sich andere Gedanken machen, das ist sicher nicht meine Baustelle.
Am lustigsten finde ich immer die unwidersprochene Hinnahme dieses SAP-Dogmas, dass die „Organisation der Software“ zu folgen hätte. Das ist so, als ob ich dem Wetter, bzw. dem Klima, befehlen wollte sich gefälligst an die Rechenmodelle der Metereologen zu halten ;-D
@ klabautermann
Das Gegenteil (Software folgt der Organisation), falls Sie das postulieren wollen, ist aber auch falsch. Denn beide sind „nur“ Instrument zum Erreichen zentraler Ziele. Das heißt, auch die Organisation ist nicht sakrosankt, sondern muss entwicklungsfähig sein – und sei es, um das Potenzial neuer Software auch wirklich nutzen zu können. Das Wetterbeispiel hinkt daher gewaltig. Sorry. Ist aber ohnehin eher OT.
@Klabautermann 15:44 Uhr
Naja, die „Dogmas“ sind eigentlich aus unzähligen SAP-Einführungsprojekten (lange vor SASPF der Bw) herauskondensierten Erfahrungen, was man dabei unbedingt bzw. keinesfalls machen muss/darf. Etwas ausführlicher erläutert, sind die auch vernünftig. Oder andersherum: Falls sich die Dogmen bei einem Kunden partout nicht umsetzen lassen oder er das nicht will, ist SAP wahrscheinlich einfach nicht die richtige Lösung für seine Aufgabe.
Um die Jahrtausendwende hatte man sich in der Bw dazu richtig schlau gemacht und gute Vorsätze. Dann sind so über die verstrichene Zeit viele Bw-Beteiligte, die sich sogar zum zertifizierten SAP-Berater haben ausbilden lassen, in den Ruhestand gegangen und man kam immer weiter vom Kurs ab. Ab Mitte des letzten Jahrzehntes hätte ein neutrale Beobachter schließlich den Eindruck gewinnen können, dass die Bw gezielt gegen alle schon relativ teuer bezahlten eigenen Erfahrungen verstößt. Die Einstellung des Teilprojektes, welches sich der Anpassung von SAP an streitkräftespezifische Anforderungen widmete, durch den damaligen AbtLtr M des BMVg (wohl erzwungen, weil man das Budget schon für andere, unsinnige Teilprojekte – z.B. die IT-Unterstützung Fähigkeitsanalyse – verfeuert hatte) hat die SAP-Einführung bei de Bw vollends auf eine schiefe Bahn gebracht.
Übrigens ein Paradebeispiel, wie die Bw über die Zeit längst gemachte Erfahrungen immer wieder verliert. Wenn die w das nicht in den Griff kriegt …
O.k., mein letzter Beitrag war etwas OT, weil es ja um die Hubschrauber geht. Aber SASPF und sonstige IT- bzw. IT-lastige Projekte wären bei Gelegenheit auch mal einen Thread wert. Da fließen ja auch nicht unerheblich viele Euro hinein …
@KeLaBe
na ja, der Kommentar von @Uwe zeigt ja, dass mein Vergleich nicht völlig hinkt.
;-)
Man hat ab einem gewissen Zeitpunkt im BMVg SAP zur „Universallösung“ erhoben und alle bereits gemachten Erfahrungen der TSK in Sachen softwareunterstützter Einsatzlogistik (insbesondere bei M und Lw) einfach in den Mülleimer befördert. Und nun hat man das klitzekleine Problem diese Heilige Kuh SASPF auf dünnem Roll-Out-Eis zum Laufen zu bringen, obwohl die „bordeignen“ Trainer und Coaches dieser Kuh entweder pensioniert und/oder zwecks Förderung der Verschwendungsbreite nach dem Peter-Prinzp an anderer/höherer Stelle ihre Visionen pflegen.
Naja, das „Dogma“ resultiert aus einer Sts-Entscheidung: Org-Änderung vor Softwareänderung. Man muss aber beachten, dass SASPF nix anderes als ein IT-System zur Unterstützung darstellen soll. Somit wäre eine richtige Entscheidung gewesen: Software anpassen, um die Erfüllung des Auftrages optimal unterstützen zu können. Im Rahmen der Feststellung des IST-Zustandes prüfen, ob Prozesse wirksam sind. Wenn nicht: diese anpassen.
So wie es bis dato gelaufen ist wirkt das wie ein „schwarz-weiß-Denken“. Und hier scheint man geglaubt zu haben es heißt „SAP Standardsoftware für alles“.
Fazit: es war alles gut gemeint… Aber das Schiff ist irgendwann mal in die falsche Richtung gefahren (mit oder ohne Autarkie).
Was wäre denn jetzt eine Lösung für welches Problem? Darüber wird hier n.h.E. Noch nichts gesagt, oder?
Die Lösung liegt eigentlich auf der Hand. Vorhandene Spezialsoftware die sich auf viele Jahre bewährt und entwickelt hat über Schnittstelle in SASPF integrieren!
Damit werden die aber Bestandteil von SASPF (Komplememtärprodukte).
Auch ohne ein IT- oder Logistik-Experte zu sein, kommt man auf dem ungewöhnlichen Weg des Nachdenkens zu folgendem Ergebnis: Es ist wie immer eine Frage der Perspektive. Betrachtet man es im Detail, dann wünscht man sich für jede Aufgabe eine maßgeschneiderte Speziallösung. Das ist verständlich. Betrachtet man es aber im Ganzen, dann erkennt man, dass jede zusätzliche Speziallösung erstens alles noch viel teurer macht und zweitens eine sinnvolle Vernetzung aller Teile oft erschwert. Die Wahrheit liegt also irgendwo in der Mitte, und es ist schlichtweg eine Führungsaufgabe, diese Mitte mit Blick weit nach vorn zu erkennen und zu entscheiden. (Ich weiß: Gut gebrüllt.) Partikulardenken im Sinne einer 100%-Forderung hilft jedenfalls nicht weiter. Das ist jetzt kein Plädoyer für oder gegen SAP, aber ein Appell, über den jeweils eigenen Zaun hinauszuschauen. Und das gelingt leider nicht immer.
Und doch noch ein banaler historischer Vergleich zum Zusammenhang zwischen Organisation und SAP: Haben sich mit der Erfindung der Telegrafie die Strategien, Taktiken und Gefechtsgliederungen an die neuen Möglichkeiten angepasst? Sicherlich. Und Ähnliches gilt auch im Falle der modernen IT. Wer die neuen Chancen nicht ausschöpft und zur kritischen Überprüfung liebgewonnener Strukturen nicht bereit ist, ist selbst schuld.
@TS Die Programmierung einer Schnittstelle für einen bidirektionalen Zugang in ein SAP-System dauert wie lange ? Frontend? Datenkohärenz / lesbarkeit / kompatible Datensätze ….
Ich kenne diese BW-Systeme nicht – aber Schnittstellenprogrammierung zwischen zwei verschiedenen Programmen kann echt tricky sein