Lehren aus gescheitertem Projekt

Denn daran scheiterte vor einigen Jahren beispielsweise ein ERP-Projekt. Damals sollte die NA mit dem Wechsel von SAPSAP R2 auf R3 das ERP-System mit dem System der Hüttenwerke Kayser zusammenlegen. Weil sich beide Seiten nicht zusammenraufen konnten, wurde der Plan wegen hohen Zeitdrucks, schlechter Projektvorbereitungen und davonrennender Kosten wieder ad acta gelegt. Durch die Globalisierung geriet die Affinerie inzwischen immer stärker unter Handlungszwang: Wettbewerber können überall in der Welt Kupfer produzieren und verarbeiten - und das zu deutlich geringeren Kosten. Conrath erklärt den Unterschied zu heute: "Beim ersten Anlauf war nur der Wunsch da. Erst als der Marktdruck schließlich zu hoch war, entschied der Vorstand das Zusammengehen von SAP-Systemen und Werken." Alles zu SAP auf CIO.de

Bei den Hüttenwerken Kayser diskutierten die Hamburger IT-Leiter immer wieder über die Prozesse. "Den Fachbereichen fehlt häufig die Abstraktion, wie sich auf Papier Gemaltes in der Realität darstellt", berichtet Conrath aus ihren Erfahrungen. Auch waren immer alle Teamplayer im Projekt vertreten, sodass nur das besprochen wurde, was auch realistisch umsetzbar war. Darüber hinaus mussten sie Sprachprobleme überwinden: "Beide Seiten meinten das Gleiche, gebrauchten aber ein anderes Vokabular. Jetzt verstehen wir uns alle als ein Team, das war lange Zeit nicht so."

Widerstand gab es auf vielen Ebenen. Deswegen nahmen sich Conrath und Meyer beim Kupfer-Recycling-Unternehmen Cablo (Fehrbellin in Brandenburg) mehrere Wochen Zeit für Gespräche, um die SAP-Prozesse zu erklären. Bis dahin arbeitete Cablo noch ohne SAP. Anschließend führte es eine klassische Projektorganisation mit Projektteams, Lenkungsausschuss und Key-Usern ein - begleitet von weiteren ständigen Besuchen. Heute äußern Cablo-Mitarbeiter nur noch gelegentlich marginale Kritik wie etwa am Aussehen von Formularen, die Prozessoptimierung an sich steht nicht mehr in der Diskussion.

Schwere Gewöhnung an Einzelverrechnung

Nie versiegender Gesprächsstoff bietet dagegen die Verrechnung von IT-Services. So gewöhnen sich die Hüttenwerke Kayser immer noch schwer daran, dass die Kostenstellen ihre IT-Leistungen bezahlen müssen. Früher wurden alle IT-Kosten auf alle Kostenstellen gleichmäßig verteilt. Weil IT-Kosten als Eh’-da-Kosten mitliefen, fühlte sich auch niemand für die IT-Ausgaben verantwortlich. Heute müssen alle Abteilungen beispielsweise den Nutzen eines Change-Requests schriftlich begründen. "Wenn darin keine wirtschaftliche Erklärung steht, geht der Antrag zurück", erläutert Conrath. Nebeneffekt: "Durch dieses Vorgehen wird die IT transparent, weil wir belegen können, was wir den ganzen Tag machen."

Die Verrechnung auf Produktpreise schaffte noch mehr Offenheit: Zum einen zahlen die Kostenstellen nun realistische und faire Preise statt Konzern-Solidaritätspreise. Zum anderen muss die IT an jede Leistung ein Preisschild hängen und begründen, wie sie auf den Preis kommt und was sie dafür bietet. Einzelverrechnungen dienen zudem als gutes Steuerungsmittel, um alle bei der StandardisierungStandardisierung mit ins Boot zu holen: Je stärker standardisiert ein Produkt ist, desto weniger müssen die Kostenstellen dafür bezahlen. Alles zu Standardisierung auf CIO.de