So mancher Navision-Anwender möchte statt der nativen Datenbank des ERP-Pakets Microsofts SQL Server nutzen, da dieser besser skaliert, größere Datenmengen verarbeiten kann und mehr Funktionen in puncto Geschäftsdatenanalyse bietet. Doch nicht alle Anwender sind nach der Datenbankmigration zufrieden. Zu den Kritikern zählt die in Schwabach beheimatete Firma Apollo Optik. Sie unterhält 370 Filialen und Franchiser in Deutschland und verwendet seit 1998 Navision. Derzeit nutzen 60 Anwender die Business-Software in der Version 3.70.
Im Zuge des Updates von Version 2.60 stieg Apollo von der nativen Datenbank auf den SQL Server um, und zwar mit dem Ziel, die akuten Probleme bezüglich Backup und Restore zu beseitigen, die ERP-Lösung leistungsfähiger zu machen sowie die Integration in andere Systeme zu vereinfachen. IT-Leiter Erich Ehbauer versprach sich vom SQL Server zudem einen Ausweg aus dem Ärgernis, dass durch die zahlreichen Batch-Läufe das Antwortzeitverhalten nicht mehr akzeptabel war. So werden mitunter ganze Tabellen während eines Stapeljobs für einen längeren Zeitraum gesperrt ("Table Locking") und sind somit für Benutzertransaktionen oder andere Batches nicht zugänglich.
Solche Lock-Mechanismen sind nützlich und notwendig. Sie sollen verhindern, dass mehrere Prozesse um den Zugriff auf Datenfelder einer Datenbank konkurrieren. Ohne diese Vorkehrungen käme es zu Inkonsistenzen in der Datenhaltung.
Doch nicht nur das Sperrverhalten, sondern auch die Gesamt-Performance des Systems bereitete Ehbauer massive Schwierigkeiten. Schuld daran seien die schlecht implementierten Schlüssel, Indizes und Filter der Datenbank. Dies änderte sich auch nicht, nachdem Apollo Optik die Hardwareressourcen vergrößert hatte.
Datenbankumstieg konnte die Probleme nicht beseitigen
Die Performanzprobleme mit Navision im Zusammenspiel mit der nativen Datenbank sollten, so versprach es das beauftragte Systemhaus Amball Business-Software aus Nürnberg, mit dem Umstieg auf den SQL Server beseitigt sein. Doch leider entsprach dies aus Sicht Ehbauers nicht die Realität: Auch mit der Microsoft-Datenbank komme es zu inakzeptabel langen Sperrungen von Tabellen, die den IT-Betrieb bei Apollo Optik nach wie vor beeinträchtigten. "Wir versuchen täglich, diese Schwierigkeiten mit allen möglichen Ideen und Verbesserungen abzumildern."
Hilfe erst nach Beschwerden
Unzufrieden ist Ehbauer mit der Unterstützung des Navision-Partners Amball, der bis Redaktionsschluß zu keiner Stellungnahme bereit war. Das Systemhaus verfüge einfach nicht über genügend Know-how in Sachen Navision und SQL Server. Das sei allerdings auch bei anderen Navision-Partnern der Fall. "Wir mussten uns das Wissen selbst aneignen und betreiben Troubleshooting in Eigenregie. Erst nach massiven Beschwerden bekamen wir tatkräftige Unterstützung von Microsoft." Der Softwarekonzern hatte Navision im Jahr 2002 gekauft. Nach eigener Aussage sei Microsoft mit dem Wissensstand einiger Partner in Sachen SQL Server ebenfalls unzufrieden. "Selbst Amballs SQL-Spezialisten haben versagt." Eine Schwestergesellschaft von Apollo Optik in den Niederlanden habe mit denselben Problemen hinsichtlich SQL-Performance und Inkompetenz der Partner zu kämpfen.
Auf Anfrage der computerwoche äußerte sich Microsoft zu den Schwierigkeiten: "Navision selbst initiiert kein Table Locking, vielmehr setzt die ERP-Software einen Lock-Befehl an den SQL Server ab, ohne ihm dabei den Lock-Mechanismus vorzuschreiben", erläutert Frank Hassler, Produkt-Manager für Navision bei Microsoft Business Solutions. Der Datenbank-Server selbst entscheide, ob ein Datenfeld, ein Record oder ein Bereich gesperrt werde. "Genau dies hätte Amball wissen sollen und bei der Implementierung der Stapelverarbeitungen berücksichtigen müssen", wettert Ehbauer. Die Erfahrung habe gezeigt, dass gerade Batchjobs lange, wenig performante Transaktionen erzeugten, die in der Regel zur Sperrung ganzer Tabellen führten. "Unser Troubleshooting besteht darin, die Prozesse zu modifizieren, um die Transaktionen zu verkürzen und so unter Umständen die Sperrdauer auf ein Minimum zu beschränken."
Apollo Optik ist kein Einzelfall
"Die Probleme mancher Kunden und auch Partner rühren daher, dass sie meinen, die Migration der Datenbank sei durch das Einspielen einer CD bereits vollbracht", bemerkt Microsoft-Manager Hassler. Dem sei jedoch nicht so. Oft würden kundenspezifische Einstellungen im ERP-System vorgenommen, weshalb die Migration des Datenbankunterbaus auf SQL Server nicht im Handumdrehen zu realisieren sei. "Der SQL Server verhält sich anders als die native Datenbank, dies muss in Projekten berücksichtigt werden." Da reiche es nicht aus, eine Datensicherung aus der alten Datenbank in den SQL Server zu überführen. So unterscheiden sich die Konzepte, wie Schlüssel gesetzt werden. Hier kämen Anwender nicht umhin, die selbst entwickelten ERP-Funktionen zu begutachten.
Dem widerspricht Ehbauer auch nicht. Ihm zufolge handelte es sich bei der Migration des ERP-Systems seines Unternehmens von Version 2.60 auf 3.70 jedoch um kein Upgrade im herkömmlichen Sinne. Vielmehr sei das System von Grund auf neu aufgesetzt worden. Es habe also von vornherein die Möglichkeit bestanden, alle Modifikationen "SQL-Server-tauglich" zu integrieren; dies sei kaum geschehen, da die herangezogenen Spezialisten von Amball nicht über die richtigen Informationen verfügt hätten.
Schwierigkeiten bei Navision-Anwendern, die einen Wechsel von der nativen Datenbank auf den SQL Server vornehmen, können wohl nicht ausgeschlossen werden. Grundsätzlich, so der Hersteller, sind das ERP-System und Microsofts Datenbank-Server gut aufeinander abgestimmt. "Das Standardsystem arbeitet tadellos mit SQL Server zusammen", versichert Hassler.
Einige Anwender beurteilen das allerdings anders. "Navision ist ein sehr gutes ERP-System, aber die SQL-Server-Portierung ist nicht das Gelbe vom Ei", bemerkt ein langjähriger Kunde, der anonym bleiben möchte. "Ein Umstieg auf SQL Server ist für die Benutzer mit Kunstgriffen verbunden." Grund sei, dass die Anpassung an die Datenbank erst nachträglich vorgenommen wurde. Doch nicht alle Nutzer müssten mit Problemen rechnen. Es komme sehr darauf an, wie viele Batch-Läufe die Firmen fahren und wie groß deren ERP-Datenbanken sind.
Die Schwierigkeiten von Firmen wie Apollo Optik schrecken andere Navision-Anwender ab, auf SQL Server zu migrieren. Zu ihnen zählt Marcus Weichelt, IT-Leiter der auf Gebäudereinigung und -Management sowie Catering spezialisierten Dorfner Gruppe aus Nürnberg, der von Ehbauers Sorgen gehört hat.
Zu den leidgeprüften Nutzern zählt auch Michael Georgie, IT-Leiter beim PC-Anbieter Vobis AG aus Potsdam. Die größten Schwierigkeiten sind bei ihm zwar gelöst, doch immer wieder treten neue Probleme auf. "Wir müssen sehr genau darauf achten, dass unsere Programmanpassungen in Navision korrekt vom SQL Server umgesetzt werden." So sei es erforderlich, nachzuschauen, ob die Datenbank die richtigen Schlüssel verwendet. Größte Sorgfalt sei auch beim Einspielen von ERP-Updates angebracht. Vobis nutzt die Programmversion 3.70 sowie die Datenbankversion 2.6 von Navision.
Bessere Zusammenarbeit
Obwohl noch nicht alle Schwachstellen beseitigt sind, hat sich aus Sicht von Georgie zumindest die Zusammenarbeit mit dem Hersteller verbessert. Schon bei der Euro-Umstellung vor einigen Jahren hatte Vobis mit Performance-Engpässen zu kämpfen. Erst durch massiven Druck ließ sich die damals noch eigenständige Firma Navision dazu bewegen, für Abhilfe zu sorgen. Dies klappt nun wesentlich reibungsloser, was der IT-Leiter allerdings nicht auf die Übernahme des Herstellers durch Microsoft zurückführt.
Auch SQL-Server-Spezialisten kritisieren die Kopplung zwischen Datenbank und ERP-Lösung. "Navision ist für die native Datenbank entwickelt worden und nutzt daher die Leistungsfähigkeit des SQL Server nicht aus", bemerkt Bodo Danitz, SQL-Server-Experte aus Bochum. Aus seiner Sicht stünde ein kom-plettes Redesign der Abfragestrategie, an und dabei könnte Microsoft auch gleich von den Olap-Analysefunktionen des SQL Server Gebrauch machen. Danitz erscheint es widersinnig, dass Microsoft Business Solutions weiterhin die native Navision-Datenbank unterstützt. Abgesehen von den Portierungs- und Performance-Problemen breche der Hersteller so mit der eigenen Strategie, SQL Server als universellen Datenhalter zu positionieren. Zudem trage er damit dem Integrationskonzept der hauseigenen Office- und Backoffice-Produkte keinerlei Rechnung.