In vielen mittelständischen Unternehmen findet Planung heute in Tabellenkalkulationen statt. Der Vertrieb pflegt eine Absatzschätzung, der Einkauf eine Bedarfsliste, die Produktion einen Kapazitätsabgleich, das Controlling eine Umsatzvorschau. Jede dieser Dateien hat eine eigene Wahrheit, einen eigenen Stand und einen eigenen Eigentümer. Solange das Geschäft ruhig läuft, funktioniert das erstaunlich gut. Sobald eine Störung eintritt – ein Lieferant fällt aus, eine Kampagne läuft anders als erwartet, ein Rohstoffpreis springt –, zeigt sich der Preis dieser Zersplitterung: Niemand kann in vertretbarer Zeit sagen, was die Störung für Umsatz, Servicegrad und Kapitalbindung bedeutet.
Genau an dieser Stelle setzt integrierte Planung an. Der Grundgedanke ist, alle Planungssichten auf ein gemeinsames Datenmodell zu stellen: dieselben Artikel, dieselben Standorte, dieselben Zeitraster, dieselben Mengengerüste. Wenn Absatz-, Bestands-, Versorgungs- und Finanzsicht auf denselben Zahlen aufsetzen, wird eine Änderung an einer Stelle sofort in allen anderen sichtbar. Aus getrennten Meinungen wird ein abgestimmter Plan – und aus einer Diskussion über Zahlen eine Diskussion über Entscheidungen. Das ist der eigentliche Nutzen, und er ist organisatorischer Natur, nicht technischer.
Eine saubere Abgrenzung erspart im Projekt viel Ärger. Das ERP-System führt Stammdaten, Bestände, Aufträge, Bestellungen, Fertigungsaufträge und Belege. Es weiß, was tatsächlich passiert ist und was gerade passiert. Ein Planungssystem wie SAP IBP arbeitet auf einer aggregierten, in die Zukunft gerichteten Ebene: Es rechnet mit Wochen oder Monaten statt mit Sekunden, mit Produktfamilien statt mit Einzelchargen, mit Wahrscheinlichkeiten statt mit Belegen. Es erzeugt Planvorgaben, die anschließend an das ausführende System zurückgespielt werden.
Ebenso wenig ist SAP IBP ein Business-Intelligence-Werkzeug. Es zeigt nicht nur, was war, sondern erzeugt Pläne, die verbindlich werden sollen. Der Unterschied klingt akademisch, ist aber praktisch entscheidend: Ein Bericht wird gelesen, ein Plan wird beschlossen. Ein Planungssystem entfaltet erst dann Wirkung, wenn es einen definierten Entscheidungsprozess bedient, in dem Menschen mit Verantwortung an festen Terminen Zahlen freigeben. Ohne diesen Prozess entsteht eine teure Auswertungsumgebung.
SAP IBP wird ausschließlich als Cloud-Dienst angeboten. Eine Installation im eigenen Rechenzentrum oder bei einem selbst gewählten Hoster ist nicht vorgesehen. Dieser Zuschnitt ist bewusst gewählt: Planungsrechnungen sind rechenintensiv und laufen in Wellen – über weite Strecken passiert wenig, dann wird für einen Planungslauf sehr viel Rechenleistung gebraucht. Eine solche Lastkurve ist im Eigenbetrieb unwirtschaftlich, weil die Spitzenlast dauerhaft vorgehalten werden müsste.
Für Unternehmen bedeutet das zweierlei. Erstens entfällt der klassische Aufwand für Server, Datenbanken, Sicherungen und technische Aktualisierungen. Zweitens gibt man Kontrolle ab: Versionsstände, Wartungsfenster und der Rhythmus der Funktionsauslieferung werden vom Anbieter bestimmt. Wer eine IT-Richtlinie hat, die den Eigenbetrieb planungsrelevanter Systeme vorschreibt, muss diese Frage vor allen fachlichen Themen klären – sie lässt sich nicht durch Konfiguration lösen.
Der dritte Punkt betrifft die Datenhaltung. Ein Planungssystem in der Cloud braucht regelmäßig aktuelle Daten aus den Ausführungssystemen: Stammdaten, Bestände, offene Aufträge, historische Absätze, Lieferantendaten. Diese Datenversorgung ist der technische Kern jedes IBP-Projekts – und in der Praxis der Punkt, an dem Zeitpläne reißen. Ein Planungssystem ist genau so gut wie die Daten, die es bekommt, und die Bereinigung dieser Daten ist Arbeit, die im eigenen Haus anfällt.
Der übliche Denkfehler bei Modulübersichten besteht darin, sie als Einkaufsliste zu lesen. Fachlich sinnvoll ist eine andere Lesart: Die Bausteine bilden eine Kette, in der die Ergebnisse des einen zur Eingabe des nächsten werden. Die Absatzplanung erzeugt eine Bedarfssicht. Diese Bedarfssicht mit ihren Schwankungen ist die Grundlage, auf der die Bestandsplanung Sicherheitsbestände dimensioniert. Bedarf und Zielbestände zusammen ergeben die Anforderung an die Versorgung, die gegen Kapazitäten und Lieferantenmengen gerechnet wird. Der Abstimmungsprozess führt alles zusammen und entscheidet, was gilt. Der Control Tower schließlich beobachtet, ob der beschlossene Plan hält.
Aus dieser Kette folgt eine praktische Empfehlung für den Einstieg: Man beginnt dort, wo der größte Schmerz liegt, und baut die Kette schrittweise aus. In vielen mittelständischen Projekten ist das die Absatzplanung, weil sie den größten Hebel auf alle nachgelagerten Größen hat und weil die notwendigen Daten – Verkaufshistorie und Artikelstamm – regelmäßig verfügbar sind. In anderen Fällen ist der Einstieg über die Bestandsdimensionierung sinnvoller, etwa wenn Kapitalbindung und Lieferfähigkeit gleichzeitig in der Kritik stehen. Der Versuch, alle Bausteine gleichzeitig einzuführen, ist der klassische Weg in ein überlanges Projekt.
Zu beachten ist außerdem, dass die Bausteine unterschiedlich anspruchsvoll in der Datenversorgung sind. Absatzplanung braucht vor allem saubere Historie und eine belastbare Produkthierarchie. Bestandsoptimierung braucht zusätzlich verlässliche Angaben zu Wiederbeschaffungszeiten und deren Schwankung – Werte, die in vielen Stammdatensätzen seit Jahren unverändert stehen und mit der Realität wenig zu tun haben. Versorgungsplanung braucht Kapazitäts- und Netzwerkdaten, die häufig überhaupt nicht systematisch gepflegt sind. Der Aufwand steigt entlang der Kette deutlich an, und diese Steigerung gehört in jede Projektplanung.
SAP hat über viele Jahre mit dem Advanced Planner and Optimizer, kurz APO, als Teil der SCM-Suite eine eigene Planungslösung angeboten. APO war ein installiertes System mit eigenen Modulen für Bedarfsplanung, Versorgungsplanung, Produktionsfeinplanung und globale Verfügbarkeitsprüfung. Es ist in vielen deutschen Industrieunternehmen tief verankert und trägt teilweise seit zwei Jahrzehnten Planungsprozesse. SAP IBP ist der strategische Nachfolger für den planerischen Teil dieses Portfolios; ergänzend übernimmt die eingebettete Planung in S/4HANA Aufgaben, die früher in APO angesiedelt waren.
Für Bestandskunden ergibt sich daraus eine Migrationsfrage, die nicht rein technisch ist. Ein Wechsel von APO nach IBP ist keine Aktualisierung, sondern ein Neuaufbau der Planungslogik auf einem anderen Datenmodell und mit anderen Werkzeugen. Gewachsene Eigenentwicklungen, Makros und individuelle Planungssichten lassen sich nicht eins zu eins übertragen. Das ist einerseits Aufwand, andererseits eine Gelegenheit: Viele APO-Installationen enthalten Logik, die niemand mehr erklären kann und die längst nicht mehr zum Geschäft passt. Eine Migration ist der natürliche Moment, um Planungsprozesse fachlich neu zu begründen statt technisch zu kopieren.
Zu Wartungs- und Unterstützungszeiträumen machen wir bewusst keine Angaben. Solche Termine werden vom Hersteller festgelegt, gelegentlich angepasst und sind je nach Vertrag und Produktvariante unterschiedlich. Wer eine APO-Installation betreibt, sollte den für die eigene Landschaft geltenden Zeitraum verbindlich beim Anbieter erfragen und daraus einen Zeitplan ableiten – und zwar früh genug, dass die Entscheidung fachlich getroffen werden kann und nicht unter Termindruck. Ein Planungssystem abzulösen ist ein Vorhaben über mehrere Quartale, nicht über wenige Wochen.
Im Markt für Supply-Chain-Planung lassen sich grob drei Ausgangspunkte unterscheiden. Erstens Anbieter, die aus der ERP-Welt kommen und Planung als Erweiterung ihrer Prozesslandschaft anbieten. Zweitens spezialisierte Planungsanbieter, die ohne eigenes ERP antreten und ihre Stärke in Rechenmodellen, Geschwindigkeit und Benutzerführung suchen. Drittens Werkzeuge, die aus einer bestimmten Branche stammen – etwa aus dem Handel mit seiner Filial- und Aktionslogik – und dort besonders tief sind.
SAP IBP gehört klar zur ersten Gruppe. Das ist der Kern seiner Positionierung: Die Nähe zur eigenen ERP-Welt, zu deren Stammdatenmodell und zu deren Ausführungssystemen ist das zentrale Argument. Für Unternehmen, deren Prozesse ohnehin auf SAP-Systemen laufen, verkürzt das den Weg von der Planung in die Ausführung erheblich. Für Unternehmen mit heterogener Systemlandschaft ohne SAP-Bezug fällt dieses Argument weg, und die Auswahl wird zu einem offenen Vergleich, in dem spezialisierte Anbieter mindestens gleichrangig zu prüfen sind. Eine Rangfolge geben wir bewusst nicht an – sie hängt vom Einzelfall ab und wäre ohne Kenntnis der konkreten Anforderungen unseriös.
Jede Planungskette beginnt mit einer Aussage über die künftige Nachfrage. SAP IBP stellt dafür eine Umgebung bereit, in der historische Absatzdaten aufbereitet, mit unterschiedlichen Verfahren fortgeschrieben und anschließend fachlich überarbeitet werden. Die technische Seite umfasst die Bereinigung von Ausreißern, den Umgang mit Fehlmengen in der Vergangenheit, die Behandlung von Aktionen und Sondereffekten sowie die Auswahl geeigneter Prognoseverfahren je Artikelgruppe. Die fachliche Seite umfasst all das, was Zahlen nicht wissen können: geplante Kampagnen, Kundenprojekte, Auslauf- und Anlaufartikel, Marktentwicklungen.
Praktisch bedeutsam ist die Fähigkeit, auf unterschiedlichen Ebenen zu planen und die Ebenen konsistent zu halten. Der Vertrieb denkt in Kunden und Produktgruppen, die Produktion in Artikeln und Werken, das Controlling in Umsatz und Deckungsbeitrag. Ein Planungssystem muss erlauben, auf einer groben Ebene einzugreifen und die Änderung sauber auf die feine Ebene herunterzubrechen – und umgekehrt Änderungen auf feiner Ebene nach oben zu verdichten. Diese Auf- und Abwärtsrechnung klingt banal, ist aber der Punkt, an dem selbst gebaute Tabellenlösungen regelmäßig scheitern.
Ein dritter Aspekt ist die Messung. Ein Prognoseprozess ohne systematische Auswertung der eigenen Treffgenauigkeit ist Beschäftigung ohne Lerneffekt. SAP IBP kann Abweichungen zwischen Prognose und tatsächlichem Absatz laufend auswerten und nach Artikelgruppen, Regionen oder Verantwortlichen aufschlüsseln. Wichtig ist dabei die ehrliche Erwartung: Prognosen bleiben Prognosen. Eine seriöse Einordnung verspricht keine bestimmte Genauigkeit, sondern eine bessere Grundlage für Entscheidungen und einen Prozess, in dem Fehler sichtbar werden und zu Korrekturen führen.
Die verbreitete Praxis, Sicherheitsbestände je Standort und Artikel isoliert festzulegen, hat einen systematischen Nachteil: Sie führt dazu, dass an jeder Netzwerkstufe gepuffert wird, ohne dass jemand die Gesamtwirkung kennt. Eine mehrstufige Betrachtung – häufig als „Multi-Echelon“ bezeichnet – rechnet das Netzwerk stattdessen als Ganzes und verteilt Puffer dorthin, wo sie den größten Beitrag zur Lieferfähigkeit leisten. Das Ergebnis ist oft überraschend: An manchen Stellen steigt der empfohlene Bestand, an anderen sinkt er deutlich, und in Summe verschiebt sich das Verhältnis zwischen Kapitalbindung und Servicegrad.
Voraussetzung dafür sind Daten, die viele Unternehmen nicht in der nötigen Qualität haben. Gebraucht werden nicht nur Mittelwerte, sondern Schwankungen: Wie stark streut die Nachfrage je Artikel? Wie zuverlässig halten Lieferanten ihre Zusagen ein, und wie groß ist die Streuung der Wiederbeschaffungszeit? Wie oft weichen Produktionsmengen von der Planung ab? Diese Größen lassen sich aus vorhandenen Bewegungsdaten ableiten, aber es ist Arbeit, und sie muss vor dem ersten sinnvollen Rechenlauf geleistet werden.
Die Fähigkeit, Alternativen parallel durchzurechnen, ist der Punkt, an dem ein Planungssystem seinen Wert am deutlichsten zeigt. Ein Szenario ist eine vollständige Kopie des Plans mit veränderten Annahmen: höhere Nachfrage in einer Region, Ausfall eines Lieferanten, eine zusätzliche Schicht, ein verschobener Produktstart. Das System rechnet die Wirkungen durch die gesamte Kette und zeigt, was mit Beständen, Lieferfähigkeit, Kapazitätsauslastung und Kosten passiert. Die Diskussion im Führungskreis verlagert sich damit von Meinungen auf Wirkungen – und genau darin liegt der organisatorische Nutzen.
Alerts ergänzen das um die laufende Überwachung. Statt Berichte durchzusehen, definiert man Regeln: Unterschreitet ein Bestand die Reichweitengrenze, weicht ein Zulauf um mehr als eine festgelegte Toleranz ab, überschreitet eine Kapazitätsauslastung einen Schwellwert, dann entsteht eine Meldung mit Zuständigkeit. Der Erfolgsfaktor ist Zurückhaltung. Ein System, das täglich hunderte Warnungen erzeugt, wird nach wenigen Wochen ignoriert. Sinnvoll sind wenige, scharf definierte Regeln mit klarer Zuständigkeit und einem festgelegten Umgang – und eine regelmäßige Überprüfung, ob eine Regel noch trägt.
Der dritte Baustein ist der Prozessrhythmus. Ein Sales-and-Operations-Planning-Zyklus ist ein fester Ablauf über den Monat: Datenaufbereitung und statistische Prognose, Abstimmung mit dem Vertrieb, Versorgungssicht mit Engpassprüfung, Vorabstimmung der Bereiche, Entscheidungstermin der Geschäftsführung. SAP IBP unterstützt diesen Ablauf mit Prozessschritten, Aufgaben, Zuständigkeiten und Fristen. Der Nutzen entsteht allerdings nicht aus der Software, sondern aus der Disziplin, den Rhythmus einzuhalten. Systeme können einen Prozess abbilden – etablieren müssen ihn Menschen.
Eine Besonderheit von SAP IBP ist die Oberflächenstrategie. Für die eigentliche Planungsarbeit steht ein Add-in für die Tabellenkalkulation zur Verfügung: Planerinnen und Planer arbeiten in einer vertrauten Umgebung, laden Planungssichten aus dem System, ändern Werte, rechnen Simulationen und speichern zurück. Das ist ein pragmatischer Ansatz, weil Planung seit jeher in Tabellen stattfindet und die Einarbeitungshürde dadurch sinkt. Wichtig ist der Unterschied zur bisherigen Praxis: Die Daten liegen nicht in der Datei, sondern im System – die Tabelle ist Sicht, nicht Speicher.
Ergänzend gibt es webbasierte Anwendungen für alles, was nicht Zellenarbeit ist: Kennzahlensichten, Alert-Bearbeitung, Prozesssteuerung, Freigaben, Stammdatenpflege, Auswertungen für Führungskräfte. Diese Trennung funktioniert im Alltag gut, verlangt aber eine bewusste Entscheidung darüber, welche Rolle womit arbeitet. Ein häufiger Fehler in Projekten besteht darin, allen Beteiligten beide Welten zu geben und die Zuständigkeit offen zu lassen. Besser ist ein klarer Zuschnitt: Wer plant, arbeitet in der Tabelle; wer steuert und entscheidet, arbeitet in den Apps.
Der überwiegende Teil der Prognosearbeit in einem Planungssystem beruht auf klassischen statistischen Verfahren, und das ist kein Mangel, sondern eine Stärke. Verfahren aus der Familie der exponentiellen Glättung, Modelle mit Trend- und Saisonkomponenten sowie Ansätze für Artikel mit sporadischem Bedarf decken einen großen Teil realer Absatzmuster ab. Sie haben zwei Eigenschaften, die im Alltag mehr wert sind, als oft angenommen wird: Sie sind nachvollziehbar, und sie brauchen vergleichsweise wenig Historie.
SAP IBP erlaubt es, mehrere Verfahren gegeneinander laufen zu lassen und automatisch dasjenige auszuwählen, das für die jeweilige Zeitreihe die geringste Abweichung erzeugt. Dieser Auswahlmechanismus ist im Alltag wertvoll, weil er die manuelle Modellpflege für tausende Artikel überflüssig macht. Er ersetzt aber nicht das fachliche Urteil: Ein Modell, das Vergangenheit gut nachbildet, kann in die Irre führen, wenn sich die Rahmenbedingungen geändert haben – etwa nach einem Sortimentswechsel, einem Kundenverlust oder einer Preisanpassung.
Zur Erwartungshaltung gehört ein zweiter Punkt. Die Qualität einer Prognose hängt weit stärker von der Beschaffenheit der Nachfrage ab als vom eingesetzten Verfahren. Artikel mit gleichmäßigem, hohem Absatz lassen sich gut vorhersagen; Artikel mit seltenen, großen Einzelbedarfen grundsätzlich schlecht – unabhängig von der Methode. Statt Genauigkeit pauschal zu versprechen, ist es sinnvoller, das Sortiment nach Prognostizierbarkeit zu klassifizieren und je Klasse ein passendes Vorgehen zu wählen: statistische Prognose für das eine, Verbrauchssteuerung oder Kundenabsprache für das andere.
Über die klassischen Verfahren hinaus stellt SAP IBP Ansätze bereit, die dem Bereich des maschinellen Lernens zuzurechnen sind. Der wesentliche Unterschied liegt darin, dass nicht nur die eigene Absatzhistorie betrachtet wird, sondern zusätzliche erklärende Größen einbezogen werden können – etwa Preisstellungen, Aktionen, Feiertage, Wetterlagen, Kundenanfragen oder Kennzahlen aus dem Marktumfeld. Solche Modelle können Zusammenhänge abbilden, die einer reinen Zeitreihenbetrachtung verborgen bleiben.
Die Bedingungen dafür sind allerdings anspruchsvoll. Erstens braucht ein lernendes Verfahren ausreichend Historie, und zwar nicht nur für den Absatz, sondern auch für die erklärenden Größen. Zweitens müssen diese Größen verlässlich und dauerhaft verfügbar sein – eine Aktionshistorie, die nur unvollständig dokumentiert ist, erzeugt Scheinzusammenhänge. Drittens sinkt die Nachvollziehbarkeit: Wenn Planer nicht mehr erklären können, warum ein Modell eine bestimmte Menge vorschlägt, sinkt das Vertrauen und damit die Nutzung. Wir empfehlen deshalb, lernende Verfahren gezielt für abgegrenzte Sortimentsteile einzusetzen und dort gegen ein statistisches Modell zu messen, statt sie flächendeckend einzuführen.
Ein eigener Fall ist die kurzfristige Nachfrageerkennung, häufig als „Demand Sensing“ bezeichnet. Der Gedanke: Für den unmittelbar bevorstehenden Zeitraum liefern aktuelle Signale – Auftragseingänge, Abrufe, Abverkaufsdaten, offene Anfragen – bessere Hinweise als eine Monatsprognose aus dem Vormonat. Ein solches Verfahren aktualisiert die kurzfristige Sicht in engem Takt und wirkt vor allem dort, wo kurze Wiederbeschaffungszeiten schnelle Reaktionen zulassen. Der Nutzen ist eng an zwei Voraussetzungen gebunden: aktuelle Daten in hoher Frequenz und die Fähigkeit der Organisation, kurzfristig überhaupt zu reagieren. Wo die Beschaffung Monate braucht, verpufft ein tagesaktuelles Signal.
Weniger spektakulär, im Alltag aber häufig wirkungsvoller sind Funktionen zur Segmentierung. Ein Sortiment mit vielen tausend Artikeln lässt sich nicht mit gleicher Aufmerksamkeit behandeln. Klassifikationen nach Wertanteil, Absatzhäufigkeit, Schwankungsintensität oder strategischer Bedeutung erlauben es, Planungsregeln differenziert zu vergeben: enge Überwachung und manuelle Pflege für wenige wichtige Artikel, regelbasierte Automatik für den großen Rest. Diese Differenzierung ist der wirksamste Hebel gegen Überlastung von Planungsteams – und sie funktioniert unabhängig von jeder KI-Diskussion.
Anomalieerkennung schließt daran an. Statt Kennzahlen manuell durchzusehen, prüfen Regeln oder Modelle laufend auf auffällige Muster: ein Absatz, der stark vom erwarteten Verlauf abweicht, ein Zulauf, der ausbleibt, eine Reichweite, die unerwartet kippt, eine Prognose, die sich ohne erkennbaren Grund sprunghaft ändert. Solche Hinweise landen als Meldung im Arbeitsvorrat. Auch hier gilt die Regel der Zurückhaltung: Ein System, das zu viel meldet, wird ignoriert; ein System, das gut kalibrierte Ausnahmen meldet, spart täglich Zeit.
Automatisierung im engeren Sinn betrifft die Routinearbeit rund um die Planung: geplante Läufe für Datenübernahme, statistische Prognose, Bestandsrechnung und Versorgungsabgleich, automatische Freigabe von Plänen an nachgelagerte Systeme, terminierte Verteilung von Auswertungen, automatische Erzeugung von Aufgaben im Prozessablauf. Das ist wenig aufregend, entlastet aber spürbar. Wir empfehlen, diese Automatisierung sauber zu dokumentieren – welcher Lauf startet wann, mit welchen Daten, mit welchem Ergebnis und wer prüft ihn. Undokumentierte Automatik ist die häufigste Ursache für Vertrauensverlust in ein Planungssystem.
Der naheliegende und am besten unterstützte Fall ist die Anbindung an eine bestehende SAP-Landschaft. Sowohl aktuelle S/4HANA-Systeme als auch ältere ECC-Installationen lassen sich als Datenquelle nutzen. Übertragen werden im Wesentlichen zwei Kategorien: Stammdaten – Artikel, Werke, Kunden, Lieferanten, Stücklisten, Beschaffungsbeziehungen, Kalender – und Bewegungsdaten – Absatzhistorie, Bestände, offene Bestellungen, Fertigungsaufträge, Kundenaufträge. In die Gegenrichtung fließen die Planungsergebnisse: Bedarfe, Zielbestände, Beschaffungsvorschläge, Freigaben.
Für die technische Umsetzung stellt SAP eine eigene Integrationsschicht bereit. Für die dateibasierte und tabellenorientierte Übernahme größerer Datenmengen wird üblicherweise der Dienst für Datenintegration genutzt, der in der SAP-Welt als „Cloud Integration for Data Services“ bekannt ist; für ereignisnahe Verbindungen und Schnittstellen zu weiteren Anwendungen kommt die allgemeine Cloud-Integrationsplattform in Frage. Welche Variante im Einzelfall passt, hängt von Datenvolumen, Aktualisierungsfrequenz und vorhandener Infrastruktur ab und gehört früh mit dem Anbieter oder dem Umsetzungspartner geklärt.
Wichtiger als die Auswahl des Werkzeugs ist die Frage der Datenhoheit: Welches System hält die Wahrheit über welchen Datensatz? Ein Planungssystem, das Stammdaten selbst pflegt, erzeugt binnen weniger Monate eine zweite, abweichende Realität. Bewährt hat sich eine klare Regel: Stammdaten kommen aus dem führenden System und werden dort gepflegt; planungsspezifische Ergänzungen – etwa Prognosemodelle, Servicegradziele oder Segmentzuordnungen – werden im Planungssystem geführt und sind dort auch dokumentiert. Diese Grenze muss schriftlich festgelegt werden, sonst verwischt sie.
Für Auswertungen jenseits der eingebauten Sichten wird häufig eine Analyseplattform ergänzt. In der SAP-Welt ist das üblicherweise die SAP Analytics Cloud, die sich für Managementberichte, Abweichungsanalysen und die Verbindung von Mengen- und Wertsicht anbietet. Ob dieser Zusatz nötig ist, hängt vom Anspruch ab: Für die reine Planungsarbeit reichen die enthaltenen Sichten in vielen Fällen aus, für unternehmensweites Berichtswesen selten. Diese Frage sollte bewusst entschieden und nicht stillschweigend mitgekauft werden.
Für Erweiterungen und eigene Anwendungen steht die Entwicklungs- und Integrationsplattform des Herstellers zur Verfügung, die als „SAP Business Technology Platform“ firmiert. Sie ist der vorgesehene Ort für alles, was über die Standardfunktionen hinausgeht: eigene Oberflächen, zusätzliche Rechenlogik, Verbindungen zu Fremdsystemen, Automatisierungen. Für mittelständische Projekte ist wichtig zu wissen, dass damit eine weitere Plattform mit eigenen Kosten, eigenen Fähigkeiten und eigenem Betriebsaufwand ins Spiel kommt. Wer diesen Weg geht, sollte vorher klären, wer die entstehenden Erweiterungen dauerhaft pflegt.
Wenn IBP-Projekte scheitern oder sich stark verzögern, liegt es selten an der Software. Der mit Abstand häufigste Grund sind Stammdaten, die für operative Zwecke ausreichen, für Planungszwecke aber nicht. Ein Artikelstamm mit gepflegter Nummer, Bezeichnung und Preis genügt, um eine Rechnung zu schreiben. Für eine Planung braucht es mehr: eine belastbare Produkthierarchie, korrekte Wiederbeschaffungszeiten, gepflegte Mindestmengen und Losgrößen, aktuelle Beschaffungsbeziehungen, sinnvolle Klassifikationen, eine saubere Zuordnung von Nachfolgeartikeln bei Auslauf.
Dazu kommt die Historie. Absatzdaten aus der Vergangenheit enthalten Effekte, die eine Prognose verzerren: Umstellungen der Artikelnummern, Fusionen von Kundengruppen, einmalige Großaufträge, Zeiträume mit Lieferunfähigkeit, in denen der gemessene Absatz nicht den tatsächlichen Bedarf abbildet. Diese Bereinigung ist fachliche Arbeit, die nur Menschen mit Geschäftskenntnis leisten können. Sie lässt sich nicht an einen Dienstleister auslagern und nicht durch ein Werkzeug ersetzen.
Unsere Empfehlung aus Projekten: Beginnen Sie mit der Datenprüfung, bevor Sie über Lizenzen sprechen. Ein Auszug der wichtigsten Stammdatenfelder und zwei bis drei Jahre Absatzhistorie, systematisch auf Vollständigkeit und Plausibilität geprüft, sagt mehr über die Machbarkeit eines Planungsprojekts aus als jede Systemdemonstration. Wenn dabei erhebliche Lücken sichtbar werden, ist das keine schlechte Nachricht – es ist die Nachricht, die man vor der Entscheidung braucht und nicht danach.
Vergleichsstudien und Quadranten suggerieren, es gebe eine objektiv beste Planungslösung. Für die praktische Auswahl ist diese Vorstellung irreführend. Die Anbieter unterscheiden sich weniger in der Frage, ob sie eine bestimmte Funktion beherrschen, als in der Frage, welche Annahmen ihr Datenmodell macht und welche Art von Planungsprozess sie voraussetzen. Ein System, das auf sehr häufige Neuberechnung der gesamten Kette ausgelegt ist, spielt seine Stärke in einem Umfeld mit vielen Störungen aus; in einem stabilen Umfeld mit langen Vorlaufzeiten bleibt dieser Vorteil ungenutzt und bezahlt.
Hinzu kommt die Systemlandschaft. Für ein Unternehmen, dessen Ausführungsprozesse auf SAP laufen und das die Planung dorthin zurückspielen muss, ist die Integrationsnähe ein gewichtiges Argument – nicht weil andere Anbieter keine Schnittstellen hätten, sondern weil jede zusätzliche Übersetzungsschicht Aufwand, Latenz und Fehlerquellen erzeugt. Umgekehrt gilt: Wo kein SAP-Bezug besteht, verliert dieses Argument seine Kraft, und spezialisierte Anbieter treten gleichrangig an.
Ein dritter Faktor wird in Vergleichen regelmäßig unterschätzt: die Verfügbarkeit von Umsetzungskompetenz in erreichbarer Nähe. Ein Planungssystem braucht Beratung, die sowohl das Werkzeug als auch die Fachdomäne beherrscht, und es braucht sie nicht nur im Projekt, sondern über Jahre. Wer ein System auswählt, für das es im eigenen Sprachraum nur wenige erfahrene Partner gibt, kauft ein Abhängigkeitsrisiko mit. Diese Frage lässt sich in wenigen Gesprächen klären und sagt mehr über die Erfolgswahrscheinlichkeit aus als jede Funktionsmatrix.
Ebenso abzugrenzen sind Werkzeuge für Transportmanagement und Frachtvergabe sowie Plattformen für Lieferantenanbindung und Beschaffung. Sie decken Teilaufgaben ab, die in einem Planungsprojekt zwar berührt werden, aber eigene Systeme rechtfertigen. Die entscheidende Frage bei jeder dieser Kategorien lautet: Geht es um die Entscheidung, was in Zukunft geschehen soll, oder um die Abwicklung dessen, was bereits entschieden ist? Planungssysteme beantworten die erste Frage, Ausführungssysteme die zweite. Wer diese Trennlinie sauber zieht, vermeidet die teuersten Fehlentscheidungen in Systemprojekten.
Als Cloud-Anwendung wird SAP IBP in festen Abständen aktualisiert. Neue Funktionen, Änderungen an bestehenden Verhalten und technische Anpassungen kommen zu vom Anbieter bestimmten Terminen. Das ist bequem, weil kein eigenes Aktualisierungsprojekt anfällt, und unbequem, weil man nicht entscheiden kann, ob und wann eine Änderung kommt. Praktisch bedeutet das: Es braucht eine Routine, in der die Ankündigungen des Anbieters gelesen, auf Relevanz für die eigene Konfiguration geprüft und in einer Testumgebung nachgestellt werden.
Diese Routine ist der Punkt, an dem viele Cloud-Projekte im Mittelstand unterschätzt werden. Der Wegfall des klassischen Aktualisierungsprojekts wird als Ersparnis verbucht, der laufende Prüfaufwand aber niemandem zugeordnet. Die Folge sind Überraschungen im Produktivbetrieb: Eine geänderte Berechnungslogik, eine angepasste Oberfläche, ein verändertes Verhalten in einer Schnittstelle. Wir empfehlen, für die Releasebegleitung feste Zeiten einzuplanen und die Testfälle für die eigenen kritischen Abläufe einmal sauber zu dokumentieren – dann ist jeder Test danach eine Frage von Stunden.
Der schwierigste Teil eines Planungsprojekts ist nicht die Technik, sondern die Verhaltensänderung. Planung berührt Machtfragen: Wessen Zahl gilt, wenn Vertrieb und Produktion unterschiedliche Erwartungen haben? Wer trägt die Verantwortung, wenn ein abgestimmter Plan nicht gehalten wird? Was passiert mit dem Bauchgefühl erfahrener Mitarbeitender, wenn ein Modell eine andere Menge vorschlägt? Diese Fragen sind unangenehm, aber sie entscheiden über den Erfolg – und sie werden in Projektplänen fast nie abgebildet.
Bewährt haben sich drei Prinzipien. Erstens Transparenz statt Automatik im ersten Jahr: Modelle schlagen vor, Menschen entscheiden, und jede Abweichung wird kurz begründet. So entsteht Vertrauen, und gleichzeitig sammelt sich Wissen darüber, wo das Modell systematisch danebenliegt. Zweitens Messung ohne Schuldzuweisung: Prognosefehler werden ausgewertet, um Verfahren zu verbessern, nicht um Personen vorzuführen. Drittens sichtbare Rückendeckung der Geschäftsführung: Ein Abstimmungstermin, an dem die Führung nicht regelmäßig teilnimmt, verliert innerhalb weniger Monate seine Verbindlichkeit.
Ein häufig unterschätzter Punkt ist die Frage, was mit den alten Tabellen geschieht. Solange die gewohnte Datei weiter gepflegt wird, existieren zwei Wahrheiten, und im Zweifel gewinnt die vertraute. Der Umstieg muss deshalb einen definierten Endpunkt haben: ein Datum, ab dem die alte Datei nicht mehr gepflegt und nicht mehr als Entscheidungsgrundlage akzeptiert wird. Dieses Datum sollte erst gesetzt werden, wenn der neue Prozess mehrere Zyklen getragen hat – dann aber konsequent.
Ein Planungssystem braucht Menschen mit einer besonderen Mischung aus Fähigkeiten. Gesucht ist nicht die reine IT-Rolle und nicht die reine Fachrolle, sondern jemand, der beides verbindet: Verständnis für die Lieferkette, Sicherheit im Umgang mit Zahlen und Modellen, und genug technisches Verständnis, um Datenflüsse und Konfiguration zu durchschauen. In größeren Organisationen ist das eine eigene Stelle, im Mittelstand häufig eine Person mit Teilzeitanteil an dieser Aufgabe.
Diese Rolle sollte im Projekt besetzt und nicht danach gesucht werden. Wenn das Wissen über Datenmodell, Prognoseeinstellungen und Regelwerk ausschließlich beim externen Partner liegt, ist jede spätere Anpassung ein Beratungsauftrag. Bewährt hat sich, eine interne Person von Beginn an in alle Entwurfsentscheidungen einzubinden, sie eigene Konfigurationsschritte durchführen zu lassen und die Dokumentation als ihre Aufgabe zu definieren. Der Aufwand dafür fällt im Projekt an; die Ersparnis zeigt sich über Jahre.
Für die Planungsteams selbst gilt Ähnliches. Die Arbeit verändert sich: weniger Datensammeln, mehr Beurteilen; weniger Tabellenpflege, mehr Umgang mit Ausnahmen und Szenarien. Diese Verschiebung ist für viele attraktiv, für manche auch bedrohlich. Eine ehrliche Kommunikation darüber, welche Tätigkeiten wegfallen und welche neu entstehen, gehört an den Anfang des Projekts – nicht in die Schulungswoche vor dem Produktivstart.
Aus unserer Projekterfahrung lassen sich mehrere Merkmale benennen, die zusammen den Bedarf an einem eigenen Planungssystem begründen. Erstens eine mehrstufige Lieferkette: mehrere Werke oder Lager, Zwischenstufen, Umlagerungen, gegebenenfalls Lohnfertigung. Zweitens eine Artikelzahl, die manuelle Betreuung ausschließt – wenn ein Disponent tausende Positionen verantwortet, ist Segmentierung keine Kür mehr. Drittens lange oder schwankende Wiederbeschaffungszeiten, die eine vorausschauende Betrachtung erzwingen. Viertens ein Geschäft mit ausgeprägter Saison, Aktionen oder Projektspitzen, in dem der Blick auf die Vergangenheit nicht ausreicht.
Fünftens – und das wird oft übersehen – ein organisatorischer Bedarf. Wenn Vertrieb, Produktion, Einkauf und Finanzen regelmäßig mit unterschiedlichen Zahlen in dieselbe Sitzung gehen, ist das Problem nicht Rechenleistung, sondern Abstimmung. Genau dafür ist integrierte Planung gebaut. Umgekehrt gilt: Wo diese Abstimmung informell gut funktioniert, weil das Unternehmen überschaubar ist und die Beteiligten täglich miteinander sprechen, bringt ein System zunächst wenig zusätzlichen Nutzen.
Eine sechste Bedingung betrifft die Systemlandschaft. SAP IBP entfaltet seinen Vorteil vor allem dort, wo die Ausführungsprozesse ohnehin auf SAP-Systemen laufen und die Planergebnisse ohne Umwege zurückfließen. In einem Unternehmen mit einem anderen ERP-System ist die Anbindung machbar, aber der zentrale Integrationsvorteil fällt weg – und damit ein wesentliches Argument für genau dieses Werkzeug.
Es gehört zur ehrlichen Beratung, den Fall zu benennen, in dem ein System dieser Größenordnung nicht die richtige Antwort ist. Ein Unternehmen mit einem überschaubaren Sortiment, einem Lager, kurzen Wiederbeschaffungszeiten und stabiler Nachfrage braucht keine mehrstufige Optimierung. Hier lassen sich mit den Dispositionsfunktionen des vorhandenen ERP-Systems, sauber gepflegten Parametern und einer disziplinierten monatlichen Abstimmungsrunde Ergebnisse erzielen, die einem großen Planungsprojekt in nichts nachstehen – bei einem Bruchteil des Aufwands.
Zwischen ERP-Bordmitteln und einer vollen Planungsplattform liegt eine mittlere Kategorie: spezialisierte Werkzeuge für Absatzprognose und Bestandsdisposition, die sich an ein bestehendes ERP-System anhängen und deutlich schneller produktiv sind. Sie decken die Kernaufgaben – Prognose, Sicherheitsbestand, Bestellvorschlag – gut ab, ohne den Anspruch, den gesamten Abstimmungsprozess eines Konzerns abzubilden. Für viele mittelständische Betriebe ist das der wirtschaftlich richtige Zuschnitt, und es ist keine Zwischenlösung, sondern häufig das passende Zielbild.
Die Entscheidungslogik, die wir empfehlen, ist einfach. Erstens: Welche Planungsfragen bleiben heute unbeantwortet, und was kosten sie? Zweitens: Lassen sie sich mit vorhandenen Mitteln beantworten, wenn Stammdaten und Prozess in Ordnung gebracht werden? Drittens: Falls nicht – welches ist das kleinste Werkzeug, das die Lücke schließt? Erst wenn die Antwort auf die dritte Frage eine vollständige Planungsplattform ist, lohnt der Schritt. Diese Reihenfolge verhindert die häufigste Fehlinvestition in diesem Feld: ein leistungsfähiges System, das mangels Prozess und Datenqualität nie über den Prototypstatus hinauskommt.
In der Fertigung ist der klassische Auslöser eine Kombination aus langen Beschaffungszeiten für Komponenten, schwankendem Abruf der Kunden und knappen Kapazitäten in der Produktion. Die entscheidende Fähigkeit ist hier die Versorgungssicht: Wie wirkt eine Absatzverschiebung auf Materialbedarfe mit unterschiedlicher Vorlaufzeit, und wo entsteht ein Engpass, den man drei Monate im Voraus noch lösen kann? Häufig kommt eine Mehrwerksstruktur hinzu, in der Verlagerungen zwischen Standorten möglich, aber nicht kostenneutral sind.
Im Konsumgüterbereich steht die Absatzseite im Vordergrund: Aktionen, Listungen bei Handelspartnern, Saisonverläufe, kurze Produktlebenszyklen und ein hoher Anteil kurzfristiger Abrufe. Gefragt sind hier eine belastbare Aktionsplanung, die Trennung von Grundbedarf und Sondereffekt sowie eine kurzfristige Nachfrageerkennung, die Abverkaufsdaten des Handels verarbeitet. Die Herausforderung liegt weniger in der Rechnung als in der Datenbeschaffung – Handelsdaten kommen in unterschiedlichen Formaten und Frequenzen.
Im Handel selbst verschiebt sich der Schwerpunkt auf Standort- und Sortimentsebene: Bestände über Filialen oder Lager verteilen, Nachschub steuern, Sortimentsentscheidungen mit Absatzdaten unterlegen. Für filialgeprägte Modelle mit Frischesortiment und hohem Aktionsanteil sind spezialisierte Handelslösungen häufig näher am Problem als eine allgemeine Planungsplattform. Für Handelsunternehmen mit Zentrallagerstruktur, Importbeschaffung und langen Vorlaufzeiten gilt das Gegenteil – dort dominieren dieselben Fragen wie in der Fertigung.
Quer über alle Branchen gilt eine Beobachtung: Der Nutzen eines Planungssystems korreliert nicht mit der Unternehmensgröße, sondern mit der Anzahl der Entscheidungen, die unter Unsicherheit und mit Vorlauf getroffen werden müssen. Ein mittelständischer Zulieferer mit sechs Monaten Beschaffungszeit hat einen höheren Planungsbedarf als ein deutlich größerer Betrieb, der aus dem Lager verkauft und in Tagen nachbestellt. Diese Frage – „Wie viel Vorlauf verlangt unser Geschäft?“ – ist der bessere Ausgangspunkt als jede Umsatzschwelle.
Die Gesamtkosten einer Planungsplattform entstehen aus vier Blöcken, die nur gemeinsam ein Bild ergeben. Der erste ist die Subskription: das laufende Entgelt für die Nutzung, gestaffelt nach Modulen, Nutzerzahl und einem Mengengerüst. Der zweite ist die Integration: Aufbau und Betrieb der Datenversorgung, gegebenenfalls einschließlich einer Integrationsplattform mit eigenen Kosten. Der dritte ist die Einführung: Beratung, Datenmodellentwurf, Konfiguration, Migration bestehender Planungslogik, Test und Schulung. Der vierte ist die interne Arbeitszeit der Fachbereiche, im Projekt wie im späteren Betrieb.
Als Kostentreiber wirken vor allem drei Größen. Erstens der Umfang der Planungskette: Nur Absatzplanung ist ein deutlich kleineres Vorhaben als Absatz, Bestand, Versorgung und Abstimmungsprozess gemeinsam. Zweitens die Zahl der Planungsobjekte und Ebenen im Datenmodell – jede zusätzliche Dimension erhöht Rechenaufwand, Pflegeaufwand und Komplexität in der Bedienung. Drittens der Zustand der Stammdaten, der den Einführungsaufwand stärker beeinflusst als jede Funktionsentscheidung.
Zur Gegenrechnung gehört ebenso viel Disziplin. Der Nutzen integrierter Planung ist grundsätzlich bezifferbar: geringere Kapitalbindung bei gleichem oder besserem Lieferservice, weniger Eilfracht und Sonderschichten durch früher erkannte Engpässe, weniger Abschriften auf Ware, die am falschen Ort liegt, kürzere Zeit bis zu einer belastbaren Entscheidung nach einer Störung. Diese Effekte lassen sich mit eigenen Zahlen und vorsichtigen Annahmen abschätzen. Wir raten ausdrücklich davon ab, dafür Referenzwerte aus Anbieterunterlagen zu übernehmen – sie stammen aus fremden Ausgangslagen und sind für die eigene Rechnung ohne Aussagekraft.
Ein Hinweis zum Angebotsvergleich: Preismodelle unterschiedlicher Planungsanbieter setzen an unterschiedlichen Größen an – Nutzer, Planungsobjekte, Datenvolumen, Module, Umsatz. Ein direkter Vergleich der Listenlogik führt in die Irre. Sinnvoll ist, das eigene Mengengerüst und den geplanten Ausbau über mehrere Jahre aufzuschreiben und jeden Anbieter zu bitten, genau dieses Gerüst zu bepreisen, einschließlich der Frage, was bei Überschreitung einer Grenze passiert und wie sich die Konditionen bei Vertragsverlängerung entwickeln.
Dass Hauptsitz und Entwicklung des Anbieters in Deutschland liegen, ist ein realer Ausgangsvorteil, ersetzt aber keine Prüfung des konkreten Betriebsmodells. Cloud-Dienste großer Anbieter werden häufig auf der Infrastruktur von Hyperscalern betrieben, teils in eigenen Rechenzentren, teils in einer Mischform. Für eine belastbare Datenschutzdokumentation ist deshalb zu klären, in welcher Region die eigene Instanz betrieben wird, welcher Infrastrukturanbieter darunter liegt und ob eine Verarbeitung ausschließlich innerhalb der Europäischen Union zugesichert werden kann. Diese Angaben sollten schriftlich vorliegen und nicht im Gespräch bleiben.
Ein zweiter Punkt, der in Verhandlungen häufig zu spät auftaucht, sind Support- und Wartungszugriffe. Wenn ein Störungsfall analysiert wird, greifen Mitarbeitende des Anbieters oder seiner Dienstleister möglicherweise auf Produktivdaten zu – und zwar nicht zwingend aus Europa. Zu regeln sind: unter welchen Bedingungen ein solcher Zugriff erfolgt, ob eine Freigabe des Kunden erforderlich ist, wie er protokolliert wird und wie lange Protokolle verfügbar sind. Für Unternehmen mit sensiblen Sortiments- oder Kundendaten ist dieser Punkt wichtiger als die Frage nach dem Serverstandort.
Der dritte Aspekt betrifft die Datenhoheit im engeren Sinn. Ein Planungsmodell enthält nach einigen Jahren erhebliches Unternehmenswissen: Segmentierungen, Prognoseeinstellungen, Servicegradziele, Netzwerkstrukturen, Kennzahldefinitionen. Wer sicherstellen will, dass dieses Wissen bei einem Anbieterwechsel nicht verloren geht, sollte zwei Dinge vertraglich sichern: den strukturierten Export der Planungsdaten und eine verwertbare Dokumentation der Modellkonfiguration. Und unabhängig vom Vertrag gilt: Eine gepflegte eigene Dokumentation des Datenmodells ist die wirksamste Vorsorge gegen Abhängigkeit.
Ein Softwareanbieter, der Daten seiner Kunden in einem Cloud-Dienst verarbeitet, handelt typischerweise nach deren Weisung – es liegt also eine Auftragsverarbeitung vor, für die ein entsprechender Vertrag erforderlich ist. Verantwortlich im Sinne der Datenschutz-Grundverordnung bleibt das einsetzende Unternehmen. In diesem Vertrag gehören die üblichen Punkte geregelt: Gegenstand und Dauer der Verarbeitung, Art der Daten und Kategorien betroffener Personen, technische und organisatorische Maßnahmen, Umgang mit Unterauftragnehmern, Unterstützung bei Betroffenenanfragen sowie Löschung und Rückgabe bei Vertragsende.
Praktisch folgen daraus vier Aufgaben im eigenen Haus. Erstens die Aufnahme der Verarbeitung in das Verarbeitungsverzeichnis, einschließlich der angebundenen Quell- und Zielsysteme. Zweitens eine Prüfung, welche personenbezogenen Felder überhaupt in das Planungssystem übertragen werden müssen – häufig genügen aggregierte Kundengruppen statt Einzelkunden, und diese Reduktion löst mehrere Fragen auf einmal. Drittens ein Berechtigungskonzept nach dem Prinzip der geringsten Rechte, das insbesondere Wertsichten und Deckungsbeitragsinformationen gezielt vergibt. Viertens ein Löschkonzept, das mit den Aufbewahrungspflichten für Belege abgestimmt ist, wobei Planungsdaten in aller Regel keine Belegqualität haben und deshalb kürzer aufbewahrt werden können.
Zu den Betroffenenrechten schließlich: Wenn eine Auskunft verlangt wird, muss klar sein, welche personenbezogenen Daten im Planungssystem liegen und wie eine Auskunft erzeugt wird. In der Praxis ist das in einem Planungssystem meist überschaubar – gerade deshalb lohnt es sich, den Umfang bewusst klein zu halten. Wer bei der Integration konsequent aggregiert, reduziert die Datenschutzlast erheblich und verliert dabei fachlich nichts, weil Planung ohnehin auf verdichteten Ebenen stattfindet.
