Unternehmensübergreifend denken und planen

Unternehmensübergreifend denken und planen (Sapport 7- 8/2010) Dänischer Anlagenbauer führt „SAP PS“ ein: Wenn in einem Weltkonzern zur Erfüllung von Compliance- Richtlinien „SAP PS“ als Projektsteuerungssystem eingeführt wird, muss es schon einmal schnell gehen. Doch trotz der sehr komplexen Anforderungen an SAP PS, trotz des ehrgeizigen Zeitplans und trotz der engen Verflechtung mit den Prozessen und Richtlinien der Konzernmutter konnte die Einführung zur Zufriedenheit aller umgesetzt werden. Bei der dänischen Tochter eines internationalen Anlagenbauers wurde kurzfristig der Entschluss gefasst, SAP PS einzuführen. Denn sich wandelnde Compliance-Richtlinien im Konzern machten es nötig, aus den verschiedenen Projekten für interne und externe Anforderer berichtsfähig zu sein. Dabei diente die Lösung der Muttergesellschaft in Deutschland und ein Konzept zur Vereinheitlichung verschiedener SAP-Systeme im Konzern als Vorlage. Die Anforderungen an das Projektsystem lassen sich als sehr komplex zusammenfassen. Interessant wurde die Aufgabe nicht nur durch die Abbildung der Logistikprozesse über Netzpläne, sondern auch durch eine sich vertiefende Integration des Unternehmens in das Konzernumfeld und den Einfluss kultureller Unterschiede. Charakterisieren lässt sich der Auftrag an das Projektteam des Anlagenbauers und den Beratungspartner PIKON als eine Einführung von SAP PS im Release „ERP ECC 5.0“ mit Anpassungen in den Prozessen in Vertrieb, Produktion, Materialwirtschaft und Warehouse-Management. Zusätzlich war die Leistungserfassung mit CATS einzurichten und ein Workflow zur terminlichen Überwachung von Netzplanvorgängen sollte implementiert werden. Schließlich waren im Projekt verschiedene kundeneigene Programme anzupassen oder neu zu erstellen. Durchdachte Rollenverteilung Das Projekt wurde von PIKON gemeinsam mit der IT des Kunden in Dänemark und den Key Usern der Muttergesellschaft in Frankenthal erfolgreich durchgeführt. Die Rollen verteilten sich dabei so, dass das Projektmanagement in der Verant- wortung der IT vor Ort lag. PIKON hat sich in diesem Projekt auf die Konzeption und die Realisierung konzentriert. Auf der Basis der globalen Konzernvorgaben erstellte das Beratungsteam unter Einbezug der lokalen Anforderungen den Business Blueprint. Dabei kam es darauf an, Vorgaben aus einem konzerninternen Projekt zur Vereinheitlichung unterschiedlicher SAP ERP-Systeme zu berücksichtigen. Nicht immer ließen sich die lokalen Besonderheiten an die zentrale Vorgabe anpassen. Dies führte auch zu einer Rückmeldung entsprechender Änderungsbedarfe an das zentrale Team der SAP-ERP- Vereinheitlichung. Die lokale IT hatte als Einstieg in das Projekt einen Prototypen aufgebaut. Dieser bildete eine gute Basis für die Diskussion der Anforderungen mit den Fachabteilungen im Rahmen der Gestaltung des Local Business Blueprint. Wesentlicher Input konnte dabei aus dem bereits von PIKON in der Muttergesellschaft durchgeführten Einführungsprojekt SAP PS gezogen werden. Diese Kenntnis der spezifischen Anforderungen und vor allem die starke Unterstützung durch die Muttergesellschaft in Deutschland brachte einen raschen Vorschritt in dieser für den Erfolg so wichtigen Projektphase. Wieder zeigte sich, dass die Konzepterstellung dann gelingt, wenn alle Beteiligten, also Vertreter der Zentrale und der Tochtergesellschaft aus IT und den verschiedenen Fach- bereichen sowie die Berater, eng zusammenarbeiten. Nicht nur mit einem gemeinsamen Ziel, sondern vor allem in einem Raum und der Verpflichtung, sowohl die jeweiligen eigenen Wünsche als auch das gesteckte Ziel zu berücksichtigen. Nur durch die IT getriebene Projekte sind schwierig und immer mit einem höheren Risiko des Scheiterns behaftet. Dabei sind vor allem die Parteien zu betreuen, die nicht sofort einen Vorteil für sich erkennen, der die in Kauf zu nehmenden Nachteile aufzuwiegen vermag. Hier kommt dann die Erfahrung aus verschiedenen, vergleichbaren Projekten zum Zuge, die ein erfahrener Berater und eine erprobte zentrale IT einbringen können. So profitieren z.B. nach diesem Projekt die Logistiker von der höheren Transparenz, die die Einführung von SAP PS für sie brachte. Erfolg kam einmal mehr durch Kommunikation statt durch reines Vertrauen auf die Logik. Beim Customizing des SAP Projekt- systems waren folgende Teilaspekte zu berücksichtigen: Projektstrukturpläne für Kundenprojekte, Forschungs- und Entwicklungsprojekte, IT-Projekte, interne Projekte, konfigurierbare Netzpläne, Meilensteintechnik mit SD-Integration, Anbindung an ein Dokumentenverwaltungssystem. Das Customizing der Leistungserfassung in CATS beinhaltete die Ablösung Leistungsverrechnung in CO, die Arbeitszeit- erfassung von produktiven und nicht produktiven Stunden auf Kundenauftragspositionen, Netzplanvorgänge sowie PSP- Elemente. Neue Layouts und geänderte Rückmeldemöglich- keiten stellten für die Nutzer eine Herausforderung dar, brachten aber ein besseres Reporting und ermöglichten die Erfassung durch jeden einzelnen Mitarbeiter statt durch eine zentrale Stelle. Solche Veränderungen der Prozesse müssen in ihren positiven und negativen Auswirkungen bedacht werden. So muss der erfassende Mitarbeiter auf viele Aspekte bei der Erfassung achten, die ihn früher nicht interessieren mussten. Dadurch dass die Erfassung jetzt nicht mehr durch eine zentrale Stelle erfolgt, kann die Durchlaufzeit aber erheblich verkürzt werden. Fehlen aber notwendige Angaben, so führt das nötige Nachfassen zu Verzögerungen. Anpassung erforderlich Eine Einführung von SAP PS in dessen voller Nutzungsbreite bringt an verschiedenen Stellen im SAP ERP Anpassungs- bedarf mit sich. Im Vertrieb bedeutete dies eine Integration der bisherigen SD-Funktionalität ins PS, die Einführung von Meilenstein-Fakturaplänen und unbewertete Kundeneinzelbe- stände mit Lieferung aus dem Kundenauftrag. Verbesserungen brachte z.B. die Meilensteinfaktura: bei Rückmeldung des Meilensteins löst das System die Fakturasperre automatisch. Dann kann direkt die Rechnungsstellung erfolgen. In der Produktion wurde die Sammlung der Kosten und die Abrechnung der Fertigungsaufträge von Kundeneinzel- kontierung auf Projektkontierung umgestellt. Ein neuer Workflow bringt jetzt bei Erreichen oder Versäumen eines Termins einen automatisierten Informationsfluss zwischen den Verant- wortlichen eines Vorgangs und ihren Vorgesetzten. In der Produktion waren auch die meisten Anpassungen von Programmen und SAP-Scripten in Formularen nötig. Die weiteren Phasen des Projektes umfassten Schulungen der Key-User und Endanwender, Vorbereitung und Durchführung der Testaktivitäten sowie den Produktivstart. Sehr wichtig war wieder einmal die Nachbetreuung über den Produktivstart hinaus. Denn um einen relativ reibungsarmen Start zu gewährleisten ist immer noch der direkte Support am Schreibtisch der schnellste Weg, Probleme zu lösen und Abläufe einzuüben. Da es sich hier um ein system- und prozessübergreifendes Modul handelt, lag die Kernprojektlaufzeit bei gut sechs Monaten. Es wurde auf Anwenderseite die komplette Mannschaft benötigt, die sich mit zahlreichen Anpassungen in den Modulen konfrontiert sah. Daher bestimmten häufige Abstimmsitzungen das Projekt. Klippen umschiffen Es gibt wohl kein größeres SAP-Projekt, das völlig ohne Schwierigkeiten ablaufen kann. Viele der Schwierigkeiten sind schon vor Beginn des Projektes absehbar, lassen sich aber aus verschiedenen Gründen erst im Laufe des Projektes beseitigen. Andere Hinderungsgründe tauchen unerwartet auf und bedürfen einer hohen Bereitschaft zur Flexibilität auf allen Seiten. Alle diese Reibungsgründe, lassen sich jedoch als Lektionen begreifen, von denen man in weiteren, ähnlichen Projekten profitieren kann. Gerade in Konzernumgebungen mit internationalen Standorten ergeben sich etliche Probleme aus der unklaren Rollenvertei- lung zwischen den Gesellschaften und den Funktionen. Ganz typische Fragen, die hier scheinbar plötzlich auftauchen, sind folgende: Welchen Anteil haben die Mitarbeiter der Key User in der Muttergesellschaft am Projekt? Wie viel Zeit bleibt ihnen über den Verlauf der verschiedenen Projektphasen hinaus für ihre eigentliche Arbeit? Welche Motivation kann sie dazu bringen, sich trotzdem mit dieser Mehrarbeit in optimaler Qualität zu beschäftigen? Hier sind die Erfahrungen des Beratungspartners aus ähnlichen Projekten unbedingt abzu- fragen. Denn im Laufe des Projektes ist es ungleich unange- nehmer und schwieriger, eine Budgeterweiterung und Zielverschiebung zu realisieren, ohne dabei Schmerzen leiden zu müssen. Dann kann es z.B. notwendig werden, kurzfristig zusätzliche Fachkräfte mit ins Projekt holen zu müssen, um den Zeitplan gewährleisten zu können. Stehen die auf Seite des Kunden nicht zur Verfügung, dann müssen sie teuer eingekauft werden – wenn sie denn überhaupt verfügbar sind. Ganz wichtig ist immer wieder der Hinweis auf Integration eines Change Managements in ein solches Projekt. Gerade wenn für bestimmte Projektbeteiligte der Nutzen der neuen Lösung nicht sehr früh transparent wird, führen Ängste und Beharrungskräfte zu mehr oder weniger sichtbaren Widerständen. Dies von Anfang an mit berücksichtigen zu können ist für alle Mitglieder und Nutznießer des Projektes ein echter Mehrwert. Als Riff oft unbekannter Art stellen sich gerne auch die tatsächlich gelebten Prozessvarianten heraus. War bei den ersten Gesprächen noch alles sehr nahe am Standard, so gelingt es später nicht immer, gleich alle Systemeinstellungen sauber erkennen zu können. Teilen sich verschiedene Standorte ein System, so ist natürlich zudem rechtzeitig daran zu denken, wie die Unterstützungsprozesse im Tagesgeschäft geregelt werden sollen. (ap)