Nisi - Fun - SAP-Projekt Gesetze

SAP-Projekt Gesetze

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.