„Das ERP ist langsam geworden, wir müssen es wohl austauschen" — einer der teuersten Sätze, die in einer KMU-Vorstandssitzung fallen können. In 8 von 10 Fällen, die wir in den letzten Jahren gesehen haben, ließ sich die eigentliche Ursache in einem Nachmittag finden und in einer Woche beheben. Ohne Ablösung, ohne Migration, ohne zweijähriges Projekt.
Das heißt nicht, dass ein ERP nie wirklich „veraltet". Es heißt, dass sich vor einem Weg für 300 bis 800 Tausend Zloty ein Blick auf die Dinge lohnt, die ein Zehntel davon kosten und an einem Wochenende erledigt sind. Dieser Text handelt davon, wie so eine Diagnose bei Comarch Optima, enova365, Subiekt und ähnlichen Systemen aussieht, die in polnischen KMU meistens auf Microsoft SQL Server laufen.
Erst Fakten, dann Eindrücke
Was Inhaber am meisten überrascht, ist wie subjektiv die Aussage „das ERP läuft langsam" tatsächlich ist. Jemand sagt: „Freitagnachmittag steht alles". Jemand anderes: „seit zwei Monaten ist es schlechter". Ein Dritter: „eine Rechnung zu schreiben dauert ewig". Drei verschiedene Probleme, drei verschiedene Ursachen, ein gemeinsamer Satz in der Mail an den Vorstand.
Bevor jemand in die Datenbank schaut, lohnt es sich, konkret zu werden:
- Welche Operationen sind langsam — die Kundenkarte öffnen, eine Rechnung erzeugen, den Monats-Verkaufsbericht laufen lassen, den Monatsabschluss? Technisch sind das völlig unterschiedliche Dinge.
- Wann wird es langsam — den ganzen Tag, nur morgens beim Hochfahren, nur bei einem großen Monatsende-Bericht, nur bei bestimmten Nutzern?
- Wie lange ist das schon so — seit einem bestimmten Update, seit das Team um 3 Personen gewachsen ist, seit die Datenbank 10 GB überschritten hat, seit der neue Internetanbieter da ist?
- Wie lange genau — mit der Stoppuhr. „Langsam" ist keine Zahl. „18 Sekunden" ist eine Zahl.
Das klingt nach Bürokratie, aber ohne diese vier Antworten ist jede weitere Diagnose Raten, und jeder Softwareanbieter verkauft dir gerne etwas, das du vielleicht gar nicht brauchst.
Ein echtes Beispiel aus der Praxis
Etwas Konkretes, damit das nicht in der Luft schwebt. Bei einem unserer Kunden — einer Steuerkanzlei mit 12 Mitarbeitenden, seit 5 Jahren auf Comarch Optima — dauerte das Öffnen der USt-Karte nach dem Jahreswechsel etwa 40 Sekunden. Dazu regelmäßig ein Einfrieren für ein Dutzend Sekunden mitten am Tag, genau dann, wenn zwei Personen gleichzeitig eine Rechnung speicherten.
Die Diagnose dauerte einen halben Tag und sah so aus: Die SQL-Server-Datenbank war 5 Jahre lang ununterbrochen gewachsen, die Tabellen VatZakup und VatSprzedaz enthielten zusammen über 8 Millionen Zeilen, die Indexe waren zu 92% fragmentiert, und Auto Update Statistics hatte irgendwann jemand ausgeschaltet, „weil es am Monatsende bremste". Dazu hatte der Server 16 GB RAM auf einer Maschine, die gleichzeitig das ERP bediente, die Auslagerungsdatei lag auf derselben HDD wie die Datenbank, und es liefen zehn geplante Jobs, von denen vier dasselbe taten.
Die Reparatur: Rebuild der Indexe in einem Wartungsfenster (2 Stunden), Auto Update Statistics mit sinnvollem Zeitplan wieder anschalten, Auslagerungsdatei auf eine separate Platte verschieben, doppelte Jobs entfernen. Externe Kosten: ein Arbeitstag. Ergebnis: das Öffnen der USt-Karte fiel von 40 Sekunden auf 3, die Einfrierer waren weg. Die ERP-Ablösung, die in den letzten drei Vorstandssitzungen Thema war, wurde auf unbestimmte Zeit vertagt.
Das ist kein Extremfall. Das ist der typische Fall.
Vier Schichten, in denen wir die Ursache suchen
Sobald du weißt, was konkret langsam ist, gehen wir durch vier Schichten — von der billigsten Diagnose zur teuersten. In dieser Reihenfolge, weil sich die Wahrscheinlichkeit statistisch so verteilt.
Schicht 1 — die Datenbank. Hier liegen 60 bis 70% der Probleme, die wir sehen. Fragmentierte Indexe, veraltete Statistiken, fehlende Indexe auf Spalten, die in Berichten verwendet werden, „Müll"-Tabellen aus abgeschalteten Modulen, ein Transaktionslog, das auf 40 GB angeschwollen ist. Alles diagnostizierbar mit ein paar Abfragen gegen sys.dm_db_index_physical_stats und sys.dm_exec_query_stats. Alles reparierbar, ohne das ERP selbst anzufassen.
Schicht 2 — Server und Infrastruktur. RAM, der SQL Server zugewiesen ist (die Voreinstellung 2 GB bei Express ist die klassische Falle), Festplattentyp (HDD gegen SSD ist ein Faktor 20 bis 50), die Auslagerungsdatei, ein Antivirus, der MDF/LDF-Dateien im Betrieb scannt, ein Backup, das stündlich mitten am Arbeitstag läuft. Diagnose: Task-Manager, Performance Monitor, SQL-Server-Konfiguration prüfen. Reparatur: oft reicht schon ein RAM-Upgrade von 16 auf 32 GB, Ausnahmen im Antivirus einzutragen ist eine Sache von 15 Minuten.
Schicht 3 — Netzwerk und Clients. Wenn das ERP auf einem Server im Büro läuft und die Nutzer über ein 6 Jahre altes WLAN kommen, liegt das Problem nicht am ERP. RDP statt Vollclient probieren, die VPN-Konfiguration prüfen, kontrollieren, ob zwischen Server und Arbeitsplätzen ein einzelner überlasteter Switch steht. Extra-Thema: Nutzer, die remote über eine schwache Leitung mit Batch-Dateien arbeiten — ein einziger Import mit 5.000 Positionen hängt den Server, wenn das Netz beim Nutzer der Flaschenhals ist.
Schicht 4 — das ERP selbst und seine Konfiguration. Erst jetzt, wenn die ersten drei Schichten ausgeschlossen sind, schauen wir in die ERP-Konfiguration: aktivierte Module, die niemand benutzt (die aber in jede Abfrage einfließen), eigene Modifikationen in Optima (SDK, Add-ons), schlecht entworfene Druckvorlagen, die hunderttausende Abfragen auslösen, ein Berichts-Cache, der 20 GB frisst. Reparaturen hier sind teurer und brauchen oft den Hersteller, aber immerhin weißt du, dass du über die echte Ursache redest.
Wann ein Austausch wirklich sinnvoll ist
Ein ERP-Austausch ist gerechtfertigt, wenn die Diagnose durch die vier Schichten eines von drei Dingen zeigt: der Hersteller pflegt deine Version nicht mehr und es gibt keine Update-Pfad; das System deckt einen Prozess nicht ab, der heute geschäftskritisch ist (z.B. hast du Online-Verkauf dazugenommen und das ERP hat keine vernünftige E-Commerce-Integration); oder die Daten- und Nutzermenge ist einfach aus der Architektur des Systems herausgewachsen — typisch für Firmen, die von 15 auf 60 Personen gewachsen sind und immer noch die „Kleinbüro"-Edition fahren.
Alle drei Gründe sind real. Sie sind aber auch relativ selten. Viel öfter steckt hinter „das ERP ist langsam" eine der Ursachen von oben. Es lohnt sich, das zu prüfen, bevor der Vorstand einen Vertrag für ein zweijähriges Migrationsprojekt unterschreibt.
Was du diese Woche tun kannst
Du musst nicht sofort ein Audit buchen. Vier Dinge, die du selbst oder mit deinem hausinternen IT-Menschen innerhalb einer Woche tun kannst:
- Konkrete Messungen im Team einsammeln — welche Operationen, wann, wie lange. Ohne das nicht weitergehen.
- Größe der Datenbank, SQL-Server-Edition und zugewiesenen RAM prüfen. Wenn es SQL Server Express mit 2 GB RAM auf einer 30-GB-Datenbank ist — das ist Schicht 2.
- Die geplanten Jobs des SQL Servers anschauen. Wenn seit 5 Jahren niemand Rebuild Indexes und Update Statistics gefahren hat — das ist Schicht 1.
- Den ERP-Hersteller direkt fragen: „was ist aktuell die empfohlene Datenbank- und Serverkonfiguration für eine Firma unserer Größe?" Eine kurze Mail reicht oft, um eine „habt ihr geprüft, ob…"-Liste zurückzubekommen.
Wenn du nach diesen vier Schritten immer noch nicht weißt, wo das Problem liegt — genau dann ist der Moment, jemanden von außen zu rufen, aber mit Fakten in der Hand, nicht mit „wir müssen das System wohl austauschen".
Bevor du 300 Tausend für ein neues ERP ausgibst — es lohnt zu prüfen, ob dem alten nicht einfach ein Arbeitstag mit dem SQL Server fehlt.