Die klassische Planungswelt ist sequenziell aufgebaut. Aus dem Vertrieb kommt eine Absatzplanung, daraus wird ein Bedarfsplan, daraus ein Beschaffungs- und Produktionsvorschlag, daraus eine Kapazitätsprüfung. Jede dieser Stufen läuft als eigener Rechenlauf, häufig über Nacht, jede greift auf einen eigenen Datenstand zu, und jede erzeugt eine Ergebnismenge, die die nächste Stufe als gegeben hinnimmt. Diese Architektur ist historisch begründet: Rechenzeit war teuer, Arbeitsspeicher knapp, und die Aufteilung in Batchläufe war die einzige Möglichkeit, große Mengengerüste überhaupt zu verarbeiten. Sie hat aber eine unangenehme Eigenschaft. Wenn sich unterwegs etwas ändert – ein Lieferant meldet Verzug, ein Kunde storniert, eine Maschine fällt aus –, dann ist die Antwort auf die Frage „Was bedeutet das für uns?“ nicht sofort verfügbar, sondern erst nach dem nächsten vollständigen Durchlauf. Bis dahin arbeiten Disposition, Fertigungssteuerung und Vertrieb mit Zahlen, die bereits überholt sind.
Kinaxis setzt genau hier an. Statt getrennter Rechenwelten gibt es ein einziges, im Arbeitsspeicher gehaltenes Datenmodell, in dem Aufträge, Bestände, Stücklisten, Arbeitspläne, Kapazitäten, Wiederbeschaffungszeiten und Prognosen gemeinsam abgebildet sind. Eine Änderung an einer beliebigen Stelle wirkt sich unmittelbar auf alle abhängigen Größen aus, weil die Abhängigkeiten im Modell hinterlegt sind und nicht in getrennten Programmläufen nachvollzogen werden müssen. Der Anbieter nennt dieses Prinzip Concurrent Planning, also gleichzeitige Planung. Der Begriff ist Marketing, das Prinzip dahinter ist es nicht: Es ist eine bewusste architektonische Entscheidung mit weitreichenden Folgen.
Die Ursprünge des Unternehmens liegen in einer Zeit, in der Materialbedarfsplanung fast ausschließlich im ERP-System stattfand und Planer sich mit Tabellenkalkulationen behalfen, sobald eine Frage über die Standardauswertung hinausging. Aus einer Spezialsoftware für die Simulation von Lieferkettenstörungen wurde über die Jahre eine breit ausgebaute Plattform, die heute die gesamte taktische und operative Planungskette abdeckt – von der Absatzprognose über Bestandszielsetzung und Versorgungsplanung bis zur Auftragszusage und zur Zusammenarbeit mit Lieferanten. Ergänzt wurde diese Entwicklung durch Zukäufe, unter anderem im Bereich KI-gestützter Handels- und Bedarfsprognosen sowie in der übergreifenden Auftrags- und Netzwerkorchestrierung. Diese Zukäufe sind funktional inzwischen weitgehend in das Plattformangebot integriert; welche Bestandteile in welcher Ausbaustufe enthalten sind, gehört in jedem Fall zu den Punkten, die im konkreten Angebot geprüft werden sollten.
Parallel dazu hat sich die Positionierung verschoben. Kinaxis wird von Analysten regelmäßig in der Spitzengruppe der Anbieter für Supply-Chain-Planung geführt und tritt vor allem gegen SAP, Blue Yonder, o9 Solutions und Oracle an. Der typische Referenzkunde ist ein produzierendes Unternehmen mit mehreren Werken, internationalen Beschaffungsketten, langen Wiederbeschaffungszeiten und einem Sortiment, dessen Stücklisten mehrere Ebenen tief reichen. In Branchen wie Elektronik, Halbleiter, Medizintechnik, Pharma, Automobilzulieferung und Industriegüter ist die Plattform besonders sichtbar – also überall dort, wo Störungen in der Versorgung unmittelbar teuer werden und wo Planer permanent zwischen Lieferfähigkeit und Kapitalbindung abwägen müssen.
Der Unterschied zwischen sequenzieller und gleichzeitiger Planung klingt abstrakt, wird aber im Arbeitsalltag sehr konkret. In einer sequenziellen Landschaft lautet die typische Antwort auf eine Störungsmeldung: „Das sehen wir morgen früh.“ In einer gleichzeitig rechnenden Umgebung lautet sie: „Das sehen wir jetzt – und wir sehen auch, welche Kundenaufträge betroffen sind, welche Alternativen es gibt und was jede Alternative kostet.“ Der Gewinn liegt nicht in der Rechengeschwindigkeit als Selbstzweck, sondern in der Verkürzung der Zeitspanne zwischen einem Ereignis und einer belastbaren Entscheidung.
Ein zweiter, oft unterschätzter Effekt betrifft die Zusammenarbeit. Wenn Vertrieb, Produktion, Beschaffung und Finanzbereich auf denselben Datenstand schauen und jede Partei ihre eigenen Annahmen in einem Szenario prüfen kann, verändert sich der Charakter von Abstimmungsrunden. Die Diskussion dreht sich weniger darum, wessen Zahlen stimmen, und mehr darum, welche Entscheidung getroffen werden soll. Genau das ist der Anspruch, den moderne S&OP-Konzepte an ein Planungssystem stellen – und es ist gleichzeitig der Anspruch, an dem die meisten Einführungsprojekte scheitern, wenn die organisatorische Seite vernachlässigt wird.
Damit ist auch die Abgrenzung zum ERP-System gesetzt. Kinaxis ersetzt keine Warenwirtschaft, keine Finanzbuchhaltung und keine Auftragsabwicklung. Es liest Stamm- und Bewegungsdaten aus den führenden Systemen, rechnet darauf seine Planungsergebnisse und gibt Entscheidungen – Bestellvorschläge, Fertigungsaufträge, angepasste Termine – wieder an diese Systeme zurück. Wer glaubt, mit einer Planungsplattform ein schwaches ERP-Fundament ausgleichen zu können, wird enttäuscht: Die Qualität der Planung ist durch die Qualität der zugelieferten Daten begrenzt, und daran ändert auch die beste Rechenarchitektur nichts.
Historisch ist der Produktname RapidResponse eng mit dem Unternehmen verbunden. Er steht bis heute für die zugrunde liegende Rechen- und Datenplattform. Unter der Dachmarke Maestro hat der Anbieter das Angebot in den vergangenen Jahren neu geordnet und dabei insbesondere die KI-Funktionen und die Orchestrierungsfähigkeiten stärker herausgestellt. Für die Bewertung eines Angebots ist die Markenfrage zweitrangig; entscheidend ist, welche Funktionsbereiche vertraglich enthalten sind, in welcher Ausbaustufe und mit welchen Mengengrenzen.
Diese Bausteine sind keine getrennten Programme. Sie greifen auf dasselbe Datenmodell zu, was den entscheidenden Unterschied zu Landschaften ausmacht, in denen Bedarfsplanung, Bestandsoptimierung und Kapazitätsprüfung in verschiedenen Werkzeugen mit eigenen Datenkopien laufen. In der Praxis bedeutet das: Ein zusätzlicher Funktionsbereich erweitert das Modell, er dupliziert es nicht. Genau das ist der Grund, warum sich der Ausbau in Stufen anbietet – man kann mit einem Bereich beginnen und weitere ergänzen, ohne die Datenbasis neu aufzusetzen.
Kinaxis positioniert sich klar im oberen Segment. Das zeigt sich weniger an Marketingaussagen als an der Bauart des Produkts: Die Plattform entfaltet ihren Wert vor allem bei mehrstufigen Stücklisten, mehreren Werken, internationalen Beschaffungsketten und einer relevanten Zahl von Planungsobjekten. Ein Einproduktbetrieb mit einem Lager und drei Lieferanten braucht diese Maschinerie nicht – hier lassen sich vergleichbare Ergebnisse mit deutlich einfacheren Mitteln erzielen. Umgekehrt gilt: Je verzweigter das Netzwerk und je häufiger Störungen auftreten, desto größer wird der Abstand zu einfacheren Werkzeugen.
Für den DACH-Raum ist eine weitere Beobachtung relevant. Die Plattform ist im Ursprung nicht auf die Besonderheiten deutschsprachiger Fertigungsbetriebe zugeschnitten – etwa auf variantenreiche Auftragsfertigung mit kundenspezifischen Stücklisten oder auf die enge Verzahnung mit gewachsenen ERP-Installationen. Das schließt solche Konstellationen keineswegs aus, verlagert aber Aufwand in die Modellierung. Umgekehrt ist die Plattform sprachlich und organisatorisch international aufgestellt, was für Unternehmen mit Standorten in mehreren Ländern ein echter Vorteil ist.
Im Zentrum steht ein Datenmodell, das die relevanten Objekte der Lieferkette und ihre Beziehungen abbildet: Artikel, Standorte, Stücklisten, Arbeitspläne, Ressourcen, Lieferantenbeziehungen, Bestände, offene Bestellungen, Fertigungsaufträge, Kundenaufträge, Prognosen, Kalender und Restriktionen. Dieses Modell wird aus den führenden Systemen befüllt und im Arbeitsspeicher gehalten. Alle Auswertungen und Berechnungen greifen auf denselben Bestand zu – es gibt keine nachgelagerte Kopie, die erst über Nacht aktualisiert wird.
Aus dieser Bauweise folgt eine Eigenschaft, die im Alltag den größten Unterschied macht: Änderungen propagieren automatisch. Wird der Liefertermin einer Zukaufkomponente um zwei Wochen verschoben, dann verschiebt sich nicht nur der Bestandsverlauf dieser Komponente. Es verschieben sich die Verfügbarkeitstermine aller Baugruppen, die diese Komponente enthalten, die Termine der Endprodukte, die diese Baugruppen enthalten, und schließlich die Zusagen gegenüber den Kunden, die auf diese Endprodukte warten. Der Planer sieht diese Kette, ohne sie selbst nachvollziehen zu müssen – und er sieht sie sofort, nicht nach dem nächsten Rechenlauf.
Die zweite Konsequenz ist die durchgängige Rückverfolgbarkeit. Zu jeder Fehlmenge, zu jedem verspäteten Auftrag und zu jedem Kapazitätsengpass lässt sich die Ursachenkette bis zum auslösenden Ereignis verfolgen. Diese Fähigkeit, im Fachjargon häufig als Pegging bezeichnet, ist in sequenziellen Landschaften mühsam nachzubilden, weil die Verbindung zwischen den Rechenstufen verloren geht. Hier ist sie ein Nebenprodukt der Architektur.
Was-wäre-wenn-Analysen bieten alle Planungssysteme an. Der Unterschied liegt darin, wie teuer ein Szenario ist. In vielen Systemen bedeutet ein Szenario, eine Kopie des Planungsdatenbestands anzulegen, darauf einen Rechenlauf zu starten und das Ergebnis anschließend mit dem Basisplan zu vergleichen. Das ist aufwendig, dauert lange und wird deshalb selten gemacht – meist nur für große, angekündigte Fragestellungen wie eine Werksverlagerung oder eine Jahresplanung.
Bei Kinaxis ist ein Szenario ein leichtgewichtiges Objekt. Es speichert nicht den gesamten Datenbestand, sondern nur die Abweichungen gegenüber dem Ausgangszustand, und es rechnet auf demselben Modell weiter. Praktisch heißt das: Ein Planer kann während eines Telefonats mit einem Lieferanten ein Szenario anlegen, die veränderte Liefermenge eintragen und innerhalb kurzer Zeit sehen, welche Kundenaufträge dadurch gefährdet sind. Er kann parallel ein zweites Szenario mit einer Alternativquelle rechnen und beide vergleichen. Und er kann das tun, ohne den freigegebenen Plan zu berühren, den seine Kollegen gerade nutzen.
Daraus entsteht ein anderer Umgang mit Unsicherheit. Wenn Szenarien billig sind, werden sie zum Normalfall statt zur Ausnahme. Statt einer Planung, die eine einzige Zukunft unterstellt, entsteht ein Arbeitsmodus, in dem mehrere Zukünfte nebeneinander bestehen und regelmäßig gegeneinander bewertet werden. Genau das ist der Anspruch, der hinter dem Begriff der resilienten Lieferkette steht – und es ist ein Anspruch, der weniger von der Software als von der Bereitschaft der Organisation abhängt, ihn auch zu nutzen.
Die Bestandsplanung beantwortet die Frage, wie viel Bestand an welcher Stelle der Kette vorgehalten werden soll. Der methodische Sprung gegenüber einfachen Reichweitenregeln liegt in der mehrstufigen Betrachtung: Bestand an der richtigen Stelle im Netzwerk ist wirksamer als Bestand überall. Ein Halbfabrikat, aus dem mehrere Varianten entstehen, puffert Unsicherheit besser als Sicherheitsbestände auf jeder einzelnen Variante. Diese Logik lässt sich nur rechnen, wenn Nachfrage- und Versorgungsschwankung über die gesamte Kette hinweg bekannt sind – wieder ein Argument für ein gemeinsames Modell.
Die Versorgungsplanung löst die Bedarfe über Stücklisten und Beschaffungsbeziehungen auf und erzeugt Vorschläge für Bestellungen, Fertigungsaufträge und Umlagerungen. Der Anspruch geht über die klassische Materialbedarfsplanung hinaus, weil Restriktionen berücksichtigt werden: begrenzte Kapazitäten, Lieferantenkontingente, Mindest- und Rundungsmengen, Kalender, Transportzeiten. Eine unrestringierte Rechnung zeigt, was gebraucht würde; eine restringierte zeigt, was tatsächlich machbar ist. Beide Sichten sind nützlich, und der Vergleich zwischen ihnen ist häufig die aussagekräftigste Auswertung überhaupt, weil er die Lücke zwischen Wunsch und Wirklichkeit beziffert.
Die Kapazitätsplanung schließlich prüft die Ressourcenseite. Sie arbeitet in der Regel auf der Ebene der Grob- und Mittelfristplanung, nicht auf der Ebene der Feinsteuerung in der Werkstatt – dort bleiben MES und Feinplanungssysteme zuständig. Der Nutzen liegt darin, Überlast frühzeitig sichtbar zu machen, solange noch Handlungsspielraum besteht: Schichtmodelle anpassen, Aufträge zwischen Werken verschieben, Fremdvergabe prüfen, Termine mit Kunden neu verhandeln.
Über all dem liegt der S&OP-Prozess, der diese Disziplinen in einen festen Kalender einbindet: Datenaufbereitung, Bedarfsabstimmung, Versorgungsabstimmung, Vorabstimmung, Managementrunde. Die Software liefert dafür die Datenbasis, die Szenarienvergleiche und die Entscheidungsdokumentation. Was sie nicht liefert, ist die Bereitschaft der Beteiligten, sich an den Kalender zu halten und getroffene Entscheidungen auch umzusetzen. Diese Unterscheidung ernst zu nehmen, ersparte schon manchem Projekt eine teure Enttäuschung.
Auf der Prognoseseite geht es zunächst um die automatische Auswahl und Parametrierung von Verfahren. Statt dass ein Planer für jede Artikelgruppe manuell entscheidet, ob ein Verfahren mit Trend, mit Saison oder mit Ereignisberücksichtigung passt, wird diese Auswahl anhand der Datenlage automatisiert und laufend überprüft. Das ist keine spektakuläre KI, spart aber erhebliche Zeit und verbessert die Ergebnisqualität dort, wo bislang aus Aufwandsgründen ein einheitliches Verfahren über alles gelegt wurde.
Eine Stufe darüber liegen Verfahren des maschinellen Lernens, die zusätzliche Einflussgrößen einbeziehen: Preisänderungen, Aktionen, Wettbewerbsaktivität, Wetter, Kalendereffekte, Vorlaufindikatoren aus dem Vertriebsprozess. Der Vorteil liegt darin, dass Zusammenhänge erkannt werden können, die in einer reinen Zeitreihenbetrachtung nicht sichtbar sind. Der Preis ist ein höherer Datenbedarf und ein Ergebnis, das schwerer zu erklären ist. In der Praxis bewährt sich ein gemischter Ansatz: bewährte Verfahren als Grundlage, lernende Verfahren dort, wo sie nachweisbar besser sind, und eine laufende Messung, die diesen Nachweis erbringt.
Ein zweiter Anwendungsbereich ist die Bedarfserkennung im kurzen Horizont, häufig als Demand Sensing bezeichnet. Dabei werden aktuelle Signale – Auftragseingänge, Abrufe, Abverkaufsdaten, Lagerbewegungen der Kunden – genutzt, um die Prognose für die nächsten Wochen zu korrigieren. Für Branchen mit kurzen Reaktionszeiten ist das relevant, für Betriebe mit langen Wiederbeschaffungszeiten deutlich weniger, weil die Beschaffungsentscheidung längst gefallen ist, bevor das Signal eintrifft. Diese Unterscheidung wird in Präsentationen selten gemacht, entscheidet aber über den Nutzen.
Der zweite große Hebel liegt nicht in der Prognose, sondern in der Ausnahmebehandlung. Ein Planungssystem erzeugt in jedem Lauf eine große Zahl von Hinweisen: verspätete Zugänge, Unterdeckungen, Terminverschiebungen, Kapazitätsüberlast. Die meisten davon sind unkritisch, einige wenige sind es nicht. Die klassische Antwort darauf ist ein Regelwerk mit Schwellenwerten, das schnell unübersichtlich wird und laufende Pflege verlangt.
Lernende Verfahren können hier auf zweierlei Weise helfen. Erstens durch Priorisierung: Aus dem historischen Verhalten – welche Hinweise wurden bearbeitet, welche ignoriert, welche führten zu einem Problem – lässt sich ableiten, welche Meldungen tatsächlich Aufmerksamkeit verdienen. Zweitens durch Vorschläge: Für wiederkehrende Situationen lassen sich Handlungsvorschläge erzeugen, die der Planer annimmt oder verwirft. Aus diesen Entscheidungen lernt das System weiter. Der Endzustand ist keine planerlose Lieferkette, sondern eine, in der der Planer sich auf die Fälle konzentriert, die tatsächlich Urteilsvermögen erfordern.
Ein dritter Bereich betrifft die automatisierte Ausführung im engen Rahmen. Für klar abgegrenzte Entscheidungsklassen – etwa die Bestätigung unkritischer Terminverschiebungen innerhalb definierter Toleranzen oder die Auslösung von Nachschubaufträgen unterhalb einer Wertgrenze – lässt sich die Bearbeitung vollständig automatisieren. Wichtig ist hier die Disziplin, den Rahmen eng zu ziehen und ihn erst auszuweiten, wenn die Ergebnisse über einen längeren Zeitraum überzeugt haben. Eine Automatisierung, die falsche Entscheidungen schnell trifft, ist schlechter als keine.
Die jüngste Entwicklungsstufe betrifft die Bedienung. Sprachbasierte Assistenten sollen es ermöglichen, Fragen in natürlicher Sprache zu stellen – etwa nach den Ursachen einer Terminverschiebung oder nach den Auswirkungen einer Mengenänderung – und darauf eine verständliche Antwort samt passender Auswertung zu erhalten. Für Gelegenheitsnutzer aus dem Management oder dem Vertrieb kann das die Hürde deutlich senken, weil sie nicht lernen müssen, wo eine bestimmte Auswertung im System liegt.
Bei aller Faszination sind drei Einschränkungen zu beachten. Erstens hängt die Qualität solcher Antworten unmittelbar an der Qualität der zugrunde liegenden Daten und Modelle – ein Assistent, der auf einem lückenhaften Modell aufsetzt, formuliert lückenhafte Aussagen nur eleganter. Zweitens stellen sich Fragen zur Datenverarbeitung: Wo werden Anfragen verarbeitet, welche Daten verlassen dabei welchen Bereich, und werden Eingaben zur Weiterentwicklung von Modellen genutzt? Das gehört vertraglich geklärt, und zwar vor der Aktivierung, nicht danach. Drittens ersetzt eine gute Antwort keine Entscheidung: Verantwortlich bleibt der Mensch, der handelt.
In den meisten Konstellationen ist ein ERP-System die wichtigste Datenquelle. Aus ihm kommen Artikelstämme, Stücklisten, Arbeitspläne, Lieferantenbeziehungen, Bestände, offene Bestellungen, Fertigungsaufträge und Kundenaufträge. Für SAP-Landschaften – im DACH-Mittelstand der häufigste Fall bei Unternehmen dieser Größenordnung – existieren etablierte Wege, sowohl für die klassischen Systeme als auch für S/4HANA. Die Auswahl reicht von direkten Datenbankextrakten über Standardschnittstellen bis hin zu Integrationsplattformen, die die Transformation übernehmen. Wichtig ist die frühzeitige Klärung, welcher Weg im konkreten Fall gewählt wird, denn davon hängen Aufwand, Latenz und Betriebskosten ab.
Für Oracle-Landschaften, Microsoft Dynamics und andere ERP-Systeme gilt dasselbe Prinzip mit anderen technischen Mitteln. Entscheidend ist weniger die Existenz eines Konnektors als die Frage, wie gut die fachlichen Konzepte zusammenpassen. Ein Konnektor überträgt Felder; er löst nicht das Problem, dass die Stücklistenlogik im ERP anders aufgebaut ist als im Planungsmodell oder dass Wiederbeschaffungszeiten im Quellsystem als grobe Pauschalen gepflegt sind. Diese fachliche Abbildung ist der eigentliche Integrationsaufwand, und sie wird in Aufwandsschätzungen regelmäßig unterschätzt.
Die Anbindung an MES-Systeme und die Fertigungssteuerung ist ein Thema, bei dem häufig zu viel gewollt wird. Ein Planungssystem braucht keine Maschinendaten im Sekundentakt. Es braucht verlässliche Aussagen darüber, welche Kapazität tatsächlich verfügbar ist, wie hoch die realen Durchlaufzeiten sind und welche Aufträge sich in welchem Fertigungsstand befinden. Diese Informationen sind aggregiert nützlicher als in voller Auflösung, weil sie sonst das Modell aufblähen, ohne die Planungsqualität zu verbessern.
Umgekehrt ist die Rückgaberichtung wichtiger, als sie oft behandelt wird. Ein Planungsergebnis, das nicht in die ausführenden Systeme gelangt, bleibt eine Empfehlung. Der Wert entsteht erst, wenn aus einem Vorschlag eine Bestellung, ein Fertigungsauftrag oder eine geänderte Zusage wird. Drei Festlegungen gehören deshalb in jedes Lastenheft: eine eindeutige Kennzeichnung jedes übergebenen Vorgangs, damit eine wiederholte Übertragung keine Dopplung erzeugt; eine klare Regel, welches System bei widersprüchlichen Ständen führt; und eine dokumentierte Fehlerbehandlung für den Fall, dass eine Übernahme scheitert.
Über die Standardanbindungen hinaus verfügen Plattformen dieser Kategorie über Schnittstellen für den programmatischen Zugriff, über Möglichkeiten zur Erweiterung des Datenmodells um eigene Felder und Objekte sowie über Werkzeuge zur Erstellung eigener Auswertungen und Arbeitsoberflächen. Diese Erweiterbarkeit ist ein zweischneidiges Schwert. Sie erlaubt es, betriebsspezifische Anforderungen abzubilden, die kein Standardprodukt kennt. Sie erzeugt aber auch Pflegeaufwand bei jedem Versionswechsel und bindet Wissen an einzelne Personen.
Ein weiterer Aspekt ist das Beratungsökosystem. Einführungsprojekte dieser Größenordnung werden selten allein vom Softwareanbieter umgesetzt, sondern zusammen mit Implementierungspartnern. Die Qualität dieser Partner ist für den Projekterfolg mindestens so wichtig wie die Qualität der Software. Für den DACH-Raum lohnt die Prüfung, ob Partner mit Erfahrung in der eigenen Branche und mit deutschsprachigen Ansprechpartnern verfügbar sind – nicht aus Bequemlichkeit, sondern weil Planungsprojekte intensive Fachdiskussionen erfordern, die in einer Fremdsprache mühsamer und fehleranfälliger werden.
Der Vorteil der Plattform tritt dort deutlich hervor, wo Veränderung der Normalzustand ist. Betriebe mit langen und unsicheren Beschaffungsketten, mit häufigen Terminverschiebungen auf der Zuliefererseite, mit knappen Schlüsselkomponenten oder mit einer Kundschaft, die kurzfristige Änderungen erwartet, profitieren am stärksten. In solchen Umgebungen ist die Fähigkeit, innerhalb von Minuten eine belastbare Antwort auf eine Störungsmeldung zu geben, kein Komfortmerkmal, sondern ein betriebswirtschaftlicher Faktor.
Ein zweites Unterscheidungsmerkmal ist die Unabhängigkeit von der ERP-Herkunft. Unternehmen mit heterogener Systemlandschaft – etwa nach Zukäufen, mit mehreren ERP-Installationen in verschiedenen Ländern – finden in einer eigenständigen Planungsschicht einen praktikablen Weg, eine gemeinsame Sicht herzustellen, ohne zuvor die gesamte Systemlandschaft zu harmonisieren. Das ist ein starkes Argument, das in reinen Funktionsvergleichen selten auftaucht.
Der erste ist die Stammdatenqualität. Wiederbeschaffungszeiten, die seit Jahren nicht überprüft wurden. Stücklisten, die vom tatsächlichen Fertigungsablauf abweichen. Mindestbestellmengen, die aus einem alten Rahmenvertrag stammen. Sicherheitsbestände, die einmal jemand gesetzt hat und die niemand mehr begründen kann. Jeder dieser Punkte verfälscht die Planungsergebnisse, und zwar auf eine Weise, die Planer sofort bemerken und die das Vertrauen in das neue System untergräbt. Die Bereinigung ist unspektakuläre Arbeit, sie lässt sich nicht delegieren und sie muss beginnen, bevor das erste Testsystem steht.
Der zweite ist der Zuschnitt. Planungsplattformen laden dazu ein, alles gleichzeitig anzugehen, weil das Datenmodell ohnehin zusammenhängt. Diese Verlockung gilt es zu widerstehen. Ein erster Abschnitt, der in einem überschaubaren Zeitraum ein sichtbares Ergebnis liefert, ist mehr wert als ein perfektes Gesamtkonzept ohne Umsetzung. Sichtbare Ergebnisse erzeugen Rückenwind, und Rückenwind ist in Projekten dieser Länge eine knappe Ressource.
Der dritte ist die Rollenklärung. Eine Planungsplattform verschiebt Verantwortung. Wer entscheidet über Sicherheitsbestände, wenn das System sie rechnet? Wer darf Planungsparameter ändern? Wer pflegt das Modell, wenn ein neues Werk hinzukommt? Wer beantwortet die Frage, welche Zahl gilt, wenn ERP und Planungssystem unterschiedliche Bestände zeigen? Diese Fragen sind organisatorisch, nicht technisch – und sie gehören vor der Einführung beantwortet, nicht danach im Konflikt.
Der laufende Betrieb einer Planungsplattform ist kein Selbstläufer. Er umfasst die Überwachung der Datenversorgung, die Behandlung von Übertragungsfehlern, die regelmäßige Überprüfung von Planungsparametern, die Pflege des Modells bei organisatorischen Veränderungen, das Testen neuer Softwareversionen und die Weiterentwicklung von Auswertungen. Bei Cloud-Lösungen kommen Releasezyklen hinzu, die vom Anbieter vorgegeben werden und in der eigenen Planung berücksichtigt werden müssen.
Praktisch bedeutet das: Es braucht mindestens eine Person im Unternehmen, die das Planungsmodell fachlich versteht und weiterentwickeln kann. Diese Rolle vollständig an einen externen Dienstleister zu geben, ist möglich, erzeugt aber eine Abhängigkeit, die bei jeder Änderung spürbar wird. Wir empfehlen, den Aufbau dieser internen Kompetenz von Anfang an als Projektziel zu führen und nicht als Nebeneffekt zu erhoffen.
In unserer Projekterfahrung ist die Mitarbeiterzahl ein schlechter Indikator dafür, ob eine Planungsplattform passt. Wesentlich aussagekräftiger ist die Planungsreife. Ein Unternehmen, das bereits einen strukturierten monatlichen Abstimmungsprozess fährt, das seine Prognosegüte misst, das Sicherheitsbestände begründen kann und das Verantwortlichkeiten für Planungsparameter definiert hat, wird auch mit einer anspruchsvollen Plattform zurechtkommen. Ein deutlich größeres Unternehmen ohne diese Grundlagen wird daran scheitern – unabhängig davon, wie viel Geld es investiert.
Daraus folgt eine unbequeme, aber nützliche Empfehlung: Wenn die Planungsreife fehlt, ist Software nicht der erste Schritt. Der erste Schritt ist die Einführung eines belastbaren Prozesses mit den vorhandenen Mitteln, die Definition von Kenngrößen und die Klärung von Verantwortlichkeiten. Das kostet Monate, keine Jahre, und es kostet vergleichsweise wenig Geld. Danach ist die Auswahlentscheidung sowohl leichter zu treffen als auch billiger umzusetzen, weil die Anforderungen bekannt sind und nicht im Projekt erst entdeckt werden.
Für Unternehmen, die diesen Reifegrad haben, deren Komplexität aber unterhalb der typischen Kinaxis-Zielgruppe liegt, lohnt der Blick auf schlankere Alternativen. Der Verzicht auf ein Spitzenprodukt ist keine Niederlage, sondern eine wirtschaftliche Entscheidung. Umgekehrt gilt: Wer die Komplexität hat und sie mit Tabellenkalkulationen bewältigt, zahlt diesen Verzicht in einer Währung, die in keiner Software-Rechnung auftaucht – in Überstunden, in Fehlentscheidungen und in Bestand, der an der falschen Stelle liegt.
Drei Größen bestimmen die Gesamtkosten stärker als alle anderen. Erstens der Umfang der Planungskette: Eine reine Bedarfsplanung ist ein deutlich kleineres Vorhaben als die durchgängige Abbildung von Absatz, Versorgung, Bestand, Kapazität und Abstimmungsprozess. Zweitens die Zahl der Planungsobjekte und Dimensionen im Modell – jede zusätzliche Ebene erhöht Rechenaufwand, Pflegeaufwand und Bedienkomplexität gleichzeitig. Drittens der Zustand der Stammdaten, der den Einführungsaufwand stärker beeinflusst als jede Funktionsentscheidung und der sich vor Projektbeginn ehrlich einschätzen lässt.
Die Gegenrechnung verdient dieselbe Sorgfalt. 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 am falschen Ort, kürzere Zeit bis zu einer belastbaren Entscheidung nach einer Störung, weniger Arbeitszeit für die manuelle Zusammenstellung von Zahlen. Diese Effekte lassen sich mit eigenen Ausgangswerten und vorsichtigen Annahmen abschätzen. Von der Übernahme von Referenzwerten aus Anbieterunterlagen raten wir ausdrücklich ab – sie stammen aus fremden Ausgangslagen und sind für die eigene Rechnung ohne Aussagekraft.
Ein Hinweis zur Vertragsgestaltung: Achten Sie auf die Behandlung von Wachstum. Wenn die Nutzung an Mengengrößen gekoppelt ist, sollte vertraglich klar sein, was bei Überschreitung passiert, wie gemessen wird und ob eine Rückstufung möglich ist. Ebenso gehören Ausstiegs- und Übergangsregelungen in den Vertrag: Wie lange bleibt der Zugriff nach Kündigung bestehen, in welchem Format werden die Daten übergeben, und wer trägt den Aufwand dafür?
Die Diskussion um Datenhoheit wird häufig auf den Datenschutz verengt. Für ein Planungssystem ist das zu kurz gegriffen. Die Daten, die in einem solchen Modell liegen, sind das Abbild der eigenen Wertschöpfung: Stücklisten, Lieferantenbeziehungen, Kostensätze, Absatzverläufe, Kundenstruktur. Wer diese Daten in eine externe Plattform gibt, sollte drei Fragen unabhängig vom Datenschutzrecht beantworten können.
Erstens: Wie kommt das Unternehmen im Bedarfsfall an seine eigenen Daten zurück – vollständig, strukturiert, in einem weiterverwendbaren Format und in einer Frist, die einen Wechsel praktisch möglich macht? Zweitens: Welche Abhängigkeit entsteht durch die im System hinterlegte Planungslogik? Ein Modell, das über Jahre gewachsen ist, lässt sich nicht in wenigen Wochen anderswo nachbauen; dieser Umstand ist Teil der Kostenrechnung und gehört bewusst akzeptiert. Drittens: Welche Auswirkungen hätte ein Ausfall der Plattform auf den laufenden Betrieb, und existiert ein Rückfallverfahren, das ohne sie auskommt?
Diese Fragen sprechen nicht gegen eine Cloud-Plattform. Sie sprechen dafür, die Antworten vor Vertragsschluss zu kennen, statt sie im Krisenfall zu suchen. Eine ausgewogene Position lautet: europäische Verarbeitung als Kriterium bewusst führen, vertragliche Exportrechte hart verhandeln, das Modellwissen im eigenen Haus halten und die Abhängigkeit als Preis für den Nutzen benennen, statt sie zu ignorieren. Auch diese Ausführungen sind eine fachliche Einordnung und keine Rechtsberatung.
