SAP-Projektgesetze
Die vollständigen SAP-Projektgesetze in freier Anlehnung an Murphys Gesetze von Joachim Graf, von M. Treder. Viel Spaß!
In freier Anlehnung an Murphys Gesetze von Joachim Graf, von M. Treder.
Generelles
Projektplanung
Durch Planung wird der Zufall zum Irrtum gemacht, d.h. glaube nicht an Wunder, verlaß dich auf sie.
Schlecht geplante Projekte brauchen dreimal so lange wie geplant.
Gut geplante Projekte benötigt nur viermal so lange.
SPJ-Wahn
Mit genau geplanten Aktivitäten und Aufwänden, gepflegten Ressourcen- und Projektkalendern errechnet SPJ über Ausgleichsfunktionen den Projektendtermin.
Gesetz der Wichtigkeit: Ein Gramm schönere Planung ist wichtiger als ein Kilo Arbeitsergebnisse.
Projektverlauf
Wenn sich irgend etwas bewegt, dann in die falsche Richtung.
Alles was sich nicht bewegt steht am falschen Platz.
Seelenlose Dinge entziehen sich grundsätzlich jedem Zugriff.
Wenn irgend etwas beschleunigt werden soll, beschleunigt sich nur das Auftreten von Problemen und Systemabstürzen.
Gestaltung systemgestützter betriebswirtschaftlicher Funktionen und
Ablauforganisation
Betriebswirtschaft ist die Lehre vom Geld und wie es die Gesetze der Informatik und gesundem Menschenverstand mißachtet.
Informatik ist die Lehre vom Computer und wie es die Gesetze der Betriebswirtschaft und gesundem Menschenverstand mißachtet.
Logik ist das Bindeglied, um mit richtigen betriebswirtschaftlichen Überlegungen zu falschen Schlußfolgerungen in der Informatik zu gelangen.
Die 80% Regeln für Geschäftsvorfälle
80% der Anwender werden nur 20% der Funktionen aus den Geschäftsvorfällen anwenden.
20% der Anwender benötigen die 80% der Funktionen, die die Geschäftsvorfälle nicht abdecken.
Alle Teilnehmer deiner Schulung gehören mit hundertprozentiger Sicherheit zu den 20%.
Die ersten 80% der Geschäftsvorfälle benötigen 80 % der eingeplanten Zeit.
Die anderen 20% brauchen die restlichen 80%.
Mit SAP dauert beides doppelt so lang und kostet viermal so viel.
Oktal-Erkenntnis
Von je 10 Geschäftsvorfällen werden nur 8 fertiggestellt werden.
Achills-Erkenntnis
Egal wie langsam sich der Endpunkt der Fertigstellung deiner Geschäftsvorfälle bewegt, du kannst den Vorsprung nicht einholen.
Axiom der Problemvermehrung
In jedem Geschäftsvorfall steckt ein kleines Problem, das gerne raus will.
In jedem kleinen Problem steckt ein großes, das gerne raus will.
Wo überhaupt kein Problem ist, steckt ein großes, das gerne raus will.
Alle Probleme bestehen aus n Gleichungen und haben n+1 Unbekannte.
Folgerung: Wenn irgend jemand sagt: “Kein Problem”, dann hast du eines.
Erkenntnis: Mißtraue jedem, der erzählt, etwas wäre leicht zu realisieren. Es ist entweder ein Irrer, Ignorant oder Verkäufer der Software.
Dokumentation
Mündliche Erklärungen von Funktionen und Abläufen sind das Papier nicht wert, auf dem sie nicht geschrieben sind.
Tautologie der Dokumentationsstandards
Wenn du nicht weißt, wie dokumentiert werden soll, lies die Dokumentationsstandards
Widerlegung der Tautologie
Die Dokumentationsstandards werden nicht gelesen.
ABC-FlowChart
Der Unterschied zwischen Lineal mit Bleistift und ABC-FlowChart ist, daß du beide nicht vernünftig einsetzen kannst.
Klickst du auf einen Kasten, um ihn zu verschieben, so wird sich seine Größe ändern.
Kannst du den Kasten verschieben, dann bewegen sich auch alle anderen Symbole mit.
Keiner der Vorgänge ist zu widerrufen.
Kann der Vorgang widerrufen werden, so hast du zwischenzeitlich eine unsinnige Funktion ausgeführt, die widerrufen werden kann.
Mit der Kurztaste ALT-D-S, an die du aus dem Winword gewöhnt bist, wolltest du Schließen, um noch einmal mit dem alten Dokument zu beginnen.
Wenn du das ABC-FlowChartdiagramm ausgedruckt hast, wirst du feststellen, daß es noch nicht alles korrigiert ist.
Projektorganisation
Die Summe der Intelligenz im Projekt ist konstant, die Beteiligung steigt.
Die Summe des eingesetzten Organisations-Knowhows ist umgekehrt proportional zu der Zahl der den Anwendern verständlichen Abläufen und Funktionen.
Die Wahrscheinlichkeit etwas zu vergessen ist direkt proportional zu …, äh,….zu….
Erkenntnis
Inkompetenz kennt keine Grenzen von Raum und Zeit.
Postulat der Zusammenarbeit
Anwender und Systementwickler werden erst vernünftig miteinander umgehen, wenn alle anderen Methoden versagt haben.
Steigerung
Anwender und Systementwickler werden auch dann nicht vernünftig miteinander umgehen, wenn alle anderen Methoden versagt haben.
1. Folgerung
Systementwickler sind sich darüber einig, daß ihr Leben ohne Anwender und deren unverständliche Wünsche sehr viel leichter wäre, d.h. gesegnet sei der Anwender, der nichts erwartet. Er soll nicht enttäuscht werden.
2. Folgerung
Anwender sind sich darüber einig, daß ihr Leben ohne Systementwickler und deren Einwände über die Umsetzbarkeit von Systemanforderungen sehr viel leichter wäre.
Finale Ableitung
Da sich also alle einig darüber sind, daß sie überflüssig sind, ist die konsequente Einführung eines computergestützten IMW der einzige Weg das System so einzustellen, daß es in der richtigen Art mißverstanden werden kann.
Definition der Arbeitsteilung
Die, die können, tun
Die, die nicht können, schulen
Die, die nicht schulen können, planen
Die, die nicht schulen oder planen können, entwickeln
Die, die nicht entwickeln können, erarbeiten Richtlinien für die Entwickler
Erkenntnis aus der Arbeitsteilung
Tu etwas zur Lösung der Probleme und man wird sich an dich erinnern, wenn es wieder Probleme gibt. Vorher wirst du nicht gefragt werden.
SAP-Standardsoftware
SAP setzt sich aus 5% Fehlfunktionen und 95% in ABAP/4 und Assembler codierter Heimtücke zusammen.
Die Möglichkeit SAP über Tabellen falsch einzustellen optimiert dieses Verhältnis zu 95% Fehlfunktionen und 95% Heimtücke.
Die verbleibenden 10%, die zu einer zweihundertprozentigen Fehlersicherheit fehlen, werden durch unvollständige oder falsche Dokumentation wettgemacht.
Gesetz der komplexen Systeme
SAP ist ein komplexes System.
Komplexe Systeme neigen zu komplexen Fehlern.
Einfache Systeme hingegen neigen zu komplexen Fehlern.
In komplexen Systemen gibt es keine Relation zwischen Daten und anwendbaren Funktionen.
Analyse
Was wäre, wenn Gott wirklich gewollt hätte, das SAP einfach einzuführen ist.
Das Tabellen-Axiom
Jede Tabelle, die richtig eingestellt ist, wird früher oder später verstellt.
Verschärfung des Tabellen-Axioms
Alles wird früher verstellt.
Die Tabelle ist nicht über die 990t geschützt und wird zum ungünstigsten Zeitpunkt verstellt.
Die alte Tabelleneinstellung ist entweder gelöscht oder überschrieben und nicht im F-Dokument oder FB90 dokumentiert.
Jede unsinnige Einstellung wurde sofort dokumentiert.
Die Entwickler, die die Tabelle eingestellt oder verstellt haben, erinnern sich nicht mehr an die richtigen Einstellungen.
Wenn sie sich doch erinnern, ist die Erinnerung falsch und es kostet einen Manntag dies festzustellen. Damit hat man aber immer noch nicht die richtige Einstellung.
Übergang zum großen Funktionsschwindel
Der Fehler wird sofort als neue Funktion verkauft.
Realisierung
Das Programmier-Paradigma
Durch den Einsatz von Standardsoftware erübrigen sich Eigenentwicklungen.
Ableitung
Systementwickler sind für die Einführung von Standardsoftware überflüssig.
1. Folgerung
SAP liefert den Quellcode und eine Entwicklungsumgebung aus.
2. Folgerung
SAP bietet Kurse zur Ausbildung von Systementwicklern an.
Erkenntnis
Jede Firma ist gleich oder die reale Welt ist nur ein Spezialfall des SAP-Modells.
Systementwickler wären die letzten, die ihre Systeme einsetzen.
Wenn ein Fehler entdeckt und beseitigt wurde, wird festgestellt, daß es kein Fehler war.
Anwenderfreundlichkeit ist das entgegenkommende, höfliche und duldsame Verhalten des Anwenders gegenüber dem unflexiblen und rätselhaften Verhalten von IV-Systemen.
- IMG-Struktur anzeigen - 11. März 2024
- ALV-Grid und Dropdown - 8. März 2024
- Finden ─ nicht suchen - 28. Februar 2024
