Suche
Close this search box.
Suche
Close this search box.

Ist Access als Grundlage noch zeitgemäß? (Nein, aber…)

Mehrfach von Microsoft abgekündigt, von seriösen Entwicklern schon längst für tot erklärt: Ist Microsoft Access noch ein zeitgemäßes Framework für die Sage Office Line / Sage 100?

So viel vorab: Selbstverständlich ist Access keine Umgebung für eine Multi-User-ERP Software – jedenfalls nicht (mehr) heute.

Aber: Access ist ein flexibles, leicht beherrschbares Framework und daher nicht die schlechteste Lösung gewesen, um vor 10-20 Jahren eine Anwendung zu entwickeln. Zu dem Zeitpunkt gab es kaum handhabbare Umgebungen, die User Interface, Print und Datenzugriff auf einfache Art unterstützt haben.

Nun soll Access „verschwinden“. Zu langsam, nicht mehr zeitgemäß, alte Technologie.

Um den Access-Ausstieg zu prüfen, muss man sich darüber klar werden, wo Access in der Sage Office Line aktuell noch eine Rolle spielt.

Im Grunde besteht die Office Line aus dem Access „Frontend“, also das, was der Benutzer sieht. Dies ist im Wesentlichen je eine ca. 40 MB große Access Datenbank für Warenwirtschaft und Finanzbuchhaltung, sowie weitere Access Datenbanken als Add-Ins, die spezielle Funktionen (z.B. Inventur, Kassenbuch, Zahlungsverkehr, Anlagenbuchhaltung, etc.) abbilden.

Die Daten werden in keiner der Access Datenbanken gespeichert. Lediglich ein paar Parameter (die Menüstruktur, die installierten Addins, Meldungstexte etc.) werden in einer lokalen Access Datenbank abglegt.

Die Konfigurationsdaten werden lokal als XML Dateien gespeichert, und die Nutzdaten in einer Microsoft SQL Server Datenbank. Dadurch ist eine Skalierbarkeit gegeben, die auch bei 400 GB Datenbanken mit 10-20 Millionen Belegpositionen noch nicht am Ende ist.

Die Geschäftsprozesse sind in DLLs (.NET und noch ganz wenige COM) gespeichert.

Warum kann man nun Access nicht einfach ersetzen?

Leider ist der Programmcode der Office Line ziemlich zerstreut:

  • Innerhalb der Formulare in Access werden zahlreiche Plausibilitätsprüfungen durchgeführt, teilweise auch die Speicherung von Daten (etwa bei Unterformularen oder Popup-Formularen) abgebildet
  • Die Plausibilitätsprüfung der Belegerfassung ist ebenfalls im entsprechenden Formular hinterlegt (bis 7.0)
  • Der Workflow wird ebenfalls in Code hinter Formularen, teilweise Funkionsnamen in der lokalen Access Datenbank hinterlegt
  • In Berichten innerhalb von Access ist Code zur Formatierung, teilweise zur Ermittlung der Datenquelle oder zur Gestaltung der Berichte
  • Die Ansteuerung von Formularen, Berichten, Druck und Formular- und Datensatzsperren ist in Code innerhalb der Anwendungsdatenbank hinterlegt
  • Die Geschäftsobjekte (Belegspeicherung, Buchungsspeicherung, Lagerbuchungen etc) sind als .NET DLLs umgesetzt, um die ein COM-Interop-Wrapper gelegt wurde, so dass diese von Access und VBA angesteuert werden können. Die meisten Plausibilitätsprüfungen dafür sind jedoch in Access in den Formularen hinterlegt (z.B. frmMainErfassung = Belegerfassung)
  • Teilweise werden ActiveX Controls verwendet, die ihrerseits wieder Code enthalten
  • Die neueren Views (z.B. Sammelmappe) werden im Applikationsserver abgerufen, d.h. hier ist Code serverseitig gespeichert.
  • Der Webclient ist wiederum eine .NET Kreation, die im Applikationsserver beheimatet ist.
  • Der Belegdruck ist derzeit noch in einem Access Addin und parallel im Appdesigner auf Basis eines Druckframeworks (Stimulsoft Reports) abgelegt.

Diese Liste ließe sich noch recht lange erweitern.

Die scheinbar unkoordinierte Verteilung von Code hat durchaus ihren Grund. Der ist aber nicht in der Technik, sondern mehr in der (fehlenden) Strategie zu suchen: Sage hat sich den Luxus gegönnt, Entwicklerkapazitäten auf zwei Produktlinien zu verteilen (die betagte DOS-Anwendung Classic Line im Windows-Kleid und die „neue“ Office Line). Damit fehlte es immer an Entwicklerkapazitäten.

Dazu kommt, dass Sage auch noch -von britischen Aktionären getrieben- jedem Euro nachrennt und fähige Entwickler zu Endkunden schickt. „Professional Service“ nennt sich das, infolgedessen der Support gegenüber Developer-Partner praktisch nicht vorhanden ist. Teilweise werden Entwicklerdokumentationen erst ein Jahr nach Veröffentlichung einer neuen Version bereitgestellt oder ganze Versionen übersprungen.

Obwohl vom Produktmanagement vor Jahren bereits die Umstellung auf .NET als „Evolution“ angekündigt wurde, ist auch heute, 2016, noch ein Mix aus Access, COM, .NET, Applikationsserver, VBA Code verteilt auf unterschiedlichste Technologien die Regel. Eine saubere Trennung von UI, Geschäftslogik und Datenbank ist nicht existent. Die Evolution hat Millionen von Jahren gedauert – daran orientiert man sich offensichtlich auch bei der Umstellung der Office Line.

Die Folge ist, dass bis heute kein brauchbarer Webclient existiert, die „Cloud-Lösung“ Office Line 24 im Grunde nichts anderes als Access auf einem Terminalserver ist, standardisierte Schnittstellen Fehlanzeige sind. An Webservices wie SOAP ist schon gar nicht zu denken.

Fazit:

Access ist weder zeitgemäß noch auf Dauer tragbar. Moderne Technologien werden nicht unterstützt. Und eine browserbasierte Nutzung ist ebenfalls nicht möglich.

Sage ist gut beraten, eine Strategie zu erarbeiten, mit der man schnellstmöglich auf eine Lösung ohne Access kommt, dafür aber mit ansprechbaren Services, verlässlichen Schnittstellen und Integrationsmöglichkeiten für Partneranpassungen und -erweiterungen.

Statt immer nur dem Geld hinterher zu laufen, sollten man eine nachhaltige Strategie unter Einbeziehung der Lösungspartner erarbeiten, so dass ein für Partner und Anwender tragfähiges Gesamtkonzept entsteht.

Dann klappt am Ende das mit dem Geldverdienen ganz von alleine, und auch die Aktionäre werden vermutlich nicht zu kurz kommen.

Wird Sage das schaffen?

Meine persönliche Einschätzung ist, dass das Unternehmen diesen Wechsel schaffen kann. Sage hat dabei das große Glück, dass es derzeit keine andere, vergleichbar komplexe Lösung in diesem Preissegment auf dem Markt gibt, die zudem von so vielen Vertriebs- und Lösungspartnern unterstützt wird.

Dazu kommt, dass die „Evolution“ auch einen entscheidenden Vorteil hat: Eine Migration auf eine neue technische Basis war bislang nie erforderlich. Jede Version hat die Daten der Vorversion lückenlos übernommen. Aus meiner Office Line Erfahrung seit 1997 (!)  konnten über nahezu 20 Jahre Daten ohne Verlust oder aufwändige Konvertierung lückenlos übernommen werden. D.h. ein Unternehmen, das vor 19 Jahren mit der Office Line begonnen hat, kann jetzt noch seinen allerersten Beleg in der aktuellsten Umgebung auswerten. Diese Kontinuität ist beeindruckend und gibt enorme Sicherheit, sowohl für Partner als auch für Anwender.

Die Tatsache, dass nun auch die Kernprozesse (Belegerfassung und Buchungserfassung) eine MVC ähnliche Struktur haben und im Grunde außerhalb der Access-Umgebung lauffähig sind, lässt einen baldigen Ausstieg aus Access als sehr wahrscheinlich erscheinen. Und dann dürfte der gewichtigste Einwand gegen die Office Line ausgeräumt sein. Und Sage kann das Produkt mit Fug und Recht umbenennen: In „Sage 100“.

Das könnte Sie auch interessieren:

Besuchen Sie uns auf YouTube

Hier erhalten Sie vielen Informationen rund um Sage 100 und unsere Module

Sage 100 Testversion

Hier stellen wir Ihnen eine Demo- / Testversion von Sage 100 zur Verfügung.

Weitere Informationen zur Sage 100

Hier erhalten Sie vielen Informationen rund um Sage 100 und unsere Module

E-Commerce mit Sage 100

Erfahren Sie alles zur intellicon Multi-Shop-Schnittstelle

Versand mit Sage 100

Hier erhalten Sie vielen Informationen rund um Sage 100 und unsere Module

Beratung?

Vereinbaren Sie hier einen kostenlosen Termin für ein Erstgespräch.