(openPR) Mit einer Hand lässt sich kein Knoten knüpfen; man soll sein Zeug nicht an einen Nagel hängen; auf zwei Beinen stehen. Damit ist gemeint, man soll seine Vorhaben auf ein vernünftiges Fundament, eine solide Basis stellen. Die basycs GmbH, bekannt als SAP-on- i-Spezialist, fordert das auch für SAP-Einführungen und hat deshalb ein Technical Blueprint entwickelt.
Entscheidet sich ein Unternehmen dazu, eine SAP-Lösung einzuführen, besteht die Grundlage in der Regel in dem vermeintlich kompletten Einführungsangebot eines Anbieters. Die geforderten betriebswirtschaftlichen Prozesse und ihre Folgen stellt er darin im so genannten Business Blueprint in aller Ausführlichkeit dar. Technische Details wie Sizing oder Performancedefinitionen findet man aber meist nur als kurzen Appendix am Ende des umfangreichen Werks. Und genau hier liegt das Problem: Außer Geschäftsszenarien oder Prozessschritten gilt es bereits im Vorfeld, das Einführungsprojekt auch aus technischer Sicht zu beurteilen und zu definieren, um den optimalen Echtbetrieb zu gewährleisten.
Um diesem Manko vieler SAP-Implementierungen abzuhelfen, hat die basycs GmbH, Kraichtal, die übliche Einführungsmethodik um eine Eigenentwicklung erweitert und dem Business Blueprint ein so genanntes Technical Blueprint gleichwertig zur Seite gestellt. Peter Althapp [Solution Architect SAP/IBM], sagt dazu: „Wir wollen den alten Einführungsautomatismus von seiner Oberflächlichkeit befreien und ein wenig veredeln und die technischen Aspekte vom Stiefkind zum Vollmitglied der Familie machen.“ Ziel ist es, das Risiko, dass eine SAP-Installation scheitert, deutlich zu minimieren, indem man in Einführungsbesprechungen und Project Definition Workshops den Projektplan oder die Einführungsroadmap mit dem Technical Blueprint vervollständigt.
Im Vorfeld Ärger vermeiden
Warum ist das überhaupt nötig? Kommt die Software-Funktion nicht wie der Strom aus der Steckdose? Keineswegs! Ein technisches Vorgespräch dient dazu, die im Business Blueprint geforderten und versprochenen Funktionen auch im Betrieb zu gewährleisten. Dazu müssen eine Vielzahl von Punkten geklärt und definiert werden. Der Kunde soll erfahren, was es bedeutet, ein komplexes SAP-Programm zu konfigurieren und die passende Infrastruktur zu installieren, was zu beachten ist, damit die Systeme später auch performant laufen. Was bedeutet für ihn „performant“, das ist nirgendwo festgelegt und muss definiert werden. Will er ein eigenes Basis-Team, ein eigenes Customer Care Center aufbauen oder nicht und dafür die Administration auslagern? Insgesamt lässt sich diese Flut technischer Daten nur systematisch beherrschen.
Ohne eine methodische Projektplanung aus technischer Sicht sind eine Vielzahl von Unzulänglichkeiten oder gar Fehlfunktionen möglich. So kann die Software in einer IT-Landschaft auf unterschiedlichen Datenbanken laufen, weil niemand analysiert und konsolidiert hat. Führt man SAP nicht in einem Projekt, sondern in mehreren Stufen ein, hat man unter Umständen auch mehrere betriebswirtschaftliche Partner. So kann es in einer SAP-Landschaft zu einem Wildwuchs an Infrastruktur kommen. Als Folge entstehen Ärger, ein höherer Zeitaufwand und ein erheblich größerer Abstimmungs- und Kommunikationsbedarf. „Um alle diese Themen wollen wir eine Klammer machen und die technische Einführung aus einer Hand erledigen. Darin sehen wir die Aufgabe unseres Technical Blueprint“, erläutert Althapp die Zielsetzung des strategischen Neuansatzes von basycs.
Das Sizing stimmt
Ein wichtiger Nutzen des Technical Blueprints liegt auch in einer TCO-Betrachtung. Stellt eine SAP-Einführung etwa die vorhandene IBM AS/400 (iSeries, System i) in Frage, so liefert die TCO-Analyse dem IT-Leiter neutrale Argumente, die vorhandene Plattform unter dem Aspekt der SAP-Anforderungen zu beurteilen. Dazu kommen Excel-Sheets und Fragebögen sowie eigene anonymisierte und fremde Beispiele zum Einsatz. In diesem Zusammenhang spielen auch Lasttests eine wichtige Rolle. Bei vielen SAP-Installationen überhaupt nicht berücksichtigt, lässt sich mit ihnen das Sizing überprüfen. Dazu setzt basycs spezielle, eigene Tools ein, um bereits in der technischen Einführungsphase einen Produktivlast zu emulieren. So weiß der Kunde bereits vor dem Going Live mit großer Sicherheit, dass sein Sizing stimmt. Ein BWL-Einführungspartner kann diesen technischen Ansatz in der Regel gar nicht beurteilen.
Mit Methode zum Erfolg
Und auch die spätere Betreuung, der Support nach dem Going Live, gehört in die technische Vorbesprechung. Welchen Prozentsatz an Administration will der Kunde selber machen? Welche Aufgaben kann oder soll basycs übernehmen, nur als passive Hotline bereit stehen oder bei fortschreitendem Sizing aktiv administrieren? Auch die entsprechenden SLAs müssen definiert werden, so dass eine klare Supportstruktur für den Kunden entsteht.
Der konkrete Nutzen des Technical Blueprints liegt auf der Hand: Eine bis heute in der Regel fehlende Systematik der technischen Seite einer SAP-Einführung wird von basycs dem Business Blueprint zur Seite gestellt. So ist bereits im Vorfeld alles definiert und es gibt später keine Überraschungen. Das Projekt läuft nicht aus dem Ruder, es gibt keine Verzögerungen durch zusätzliche Meetings, die Infrastruktur wird nicht zu klein, sondern zukunftssicher dimensioniert angeschafft. Also entstehen keine Kosten für ungeeignete Hardware und ein Change Request wird nicht so schnell zur Debatte stehen. Damit schafft basycs für die SAP-Einführung zwei gleichberechtigte Ansätze, die erst gemeinsam den Implementierungserfolg gewährleisten.
