Beiträge

Wie werden Shop und ERP-System eine Einheit?

Serie Teil I: Onlineshop und ERP-System – Stolpersteine auf dem Weg des Erfolgsduos

Vollständige Integration oder Schnittstellenanbindung

Soll ein Onlineshop in das bestehende ERP-System integriert werden, muss die Frage nach dem Integrationsmaß zwingend beantwortet werden. Dabei reichen die Möglichkeiten von einer einfachen Anbindung bis zur vollständigen Integration mit Echtzeitsynchronisierung. Welche Lösung die bessere ist, hängt vom jeweiligen Fall ab.

Verwirrung um die Begriffe Integration und Anbindung

Die Begriffe Integration und Anbindung – bezogen auf Software – werden im Praxisalltag oft Synonym verwendet. Das sorgt oft für Verwirrung. Dabei gibt es zwischen ihnen erhebliche Unterschiede.

Integration bezeichnet in der Regel eine engere Verzahnung, die einerseits für eine hoch abgestimmte Zusammenarbeit der Anwendungen sorgt; andererseits aber auch zu Abhängigkeiten und Funktionsstörungen zwischen den Programmen führen kann.

Bei einer Anbindung mittels einer Schnittstelle handelt es sich hingegen um eine lockerere Form der Zusammenarbeit. Die Gefahr für Abhängigkeiten und Konflikte ist hier nicht so groß, dafür lässt sich aber auch die Funktionalität zwischen den Anwendungen nicht so fein abstimmten.

Was haben menschliches Zusammenleben und technische Integration gemeinsam?

Um die Unterschiede zwischen technischer Integration und Anbindung besser zu veranschaulichen, könnten Formen des zwischenmenschlichen Umgangs und Zusammenlebens als Vergleich herangezogen werden. Leben mehrere Personen in einem Haushalt etwa als Familie zusammen, ist ihre Lebensweise stark verzahnt und damit integriert. Funktioniert das Familienleben gut, unterstützen sich alle gegenseitig im Alltag und nutzen dabei z. B. auch viele Haushaltsgeräte und -einrichtungen gemeinsam. So profitieren die Haushaltsmitglieder von Synergien, dazu gehören Aufwands- und Kosteneinsparungen. Auf der anderen Seite erfordert diese Lebensform auch mehr gegenseitige Rücksicht, die die individuellen Spielräume einschränken kann. Das Konfliktpotenzial ist dadurch tendenziell höher als etwa zwischen Menschen, die allein leben.

Ganz anders sieht es aus, wenn eine Familie Unterstützung von außen anfordert, um ein spezifisches Problem zu lösen. Es kann sich dabei um einen Babysitter, eine Putzhilfe oder einen Handwerker handeln. Diese Personen führen eine Dienstleistung schnell und unkompliziert – und im Idealfall zur vollsten Zufriedenheit der Auftraggeber aus – und verlassen anschließend wieder das Haus. Dadurch sind sie in ihrer Zeit- und Lebensgestaltung nur minimal von der Familie in Frage betroffen. Sie müssen nicht so anpassungsfähig sein, wie die Familienmitglieder untereinander, genießen aber auch nicht die Vorteile des Familienlebens.

Integration von Shop- und ERP-Lösungen: Vor- und Nachteile

Wenn ein ERP-System und ein Onlineshop miteinander enger integriert werden sollen, werden zwei Software-Komponenten zu einer Einheit verschmolzen. Sie greifen dann auf gemeinsame Daten zu – die etwa in einer Datenbank abgelegt sind. Das hat mehrere Vorteile: Zum einen sind die Daten zwischen ERP-System und Onlineshop immer auf dem aktuellen Stand. Gibt jemand einen neuen Datensatz in die ERP-Software ein – z. B. eine Preisänderung eines Artikels – werden die Daten (fast) sofort in die Onlineshop-Software übertragen. Umgekehrt wird auch der Verkauf eines Artikels im Onlineshop echtzeitnah an das ERP-System gemeldet.

Eine Shopping Experience deluxe entsteht, wenn Shop und ERP-System zusammenarbeiten.
Die ideale Integrationstiefe zwischen Shop und ERP-System hat maßgeblichen Einfluss auf die Customer Experience

Darüber hinaus entfallen beim integrierten System viele Kosten. Der Pflege- und Wartungsaufwand ist oft geringer, weil beide Bestandteile viele gemeinsame Komponenten und Standards nutzen.

Eine stärkere Integration bedeutet allerdings häufig ein wesentlich komplexeres Projekt, da viele Prozesse und mehrere IT-Systeme ideal aufeinander abgestimmt werden müssen. Das Projektmanagement kann unter Umständen – z.B., wenn nicht sauber durchgeführt – zu einem erheblichen Zeitverlust und hohen Kosten führen. Außerdem kann die Tiefe der Integration auch dazu führen, dass bei einer der Lösungen oder auch bei beiden Lösungen ein Teil der Funktionalität ausfällt bzw. eingeschränkt wird. Beispielsweise könnte eine Software immer wieder abstürzen, weil sie sich mit der anderen Software bei einem bestimmten Vorgang nicht abstimmen kann.

Anbindung mithilfe einer Schnittstelle: Vor- und Nachteile

Ganz anders sieht es aus, wenn eine Lösung durch eine Schnittstelle angebunden wird. Hier findet keine enge Integration statt. Die beiden Lösungen bleiben selbstständig und tauschen spezifische, im Voraus festgelegten Daten aus. Ein Onlineshop und ein ERP-System könnten so weitgehend ihre Selbstständigkeit behalten. Das kann sinnvoll sein, wenn der technische oder ökonomische Aufwand der Integration zu hoch oder der geschäftliche Nutzen gering ist. Denn Schnittstellen sind oft auf die geforderten Fähigkeiten ideal programmiert, kommen schlüsselfertig daher, fügen sich nahtlos ein und wurden in der Regel in zahlreichen Projekten erfolgreich umgesetzt, ohne dass das Rad jedes Mal neu erfunden werden musste. Hier können z.B. alle am Tage im Onlineshop verkauften Artikel – etwa durch Anklicken einer Taste – ins ERP-System übertragen werden. Anbindungstiefe und -umfang lassen sich natürlich auch abstufen. So kann es durchaus angebracht sein, dass die Daten nicht einmal am Tag, sondern mehrmals täglich oder sogar in kürzeren Zeitabständen aktualisiert werden.

Schlüsselfertige Schnittstellen sind für ihren Einsatzbereich maßgeschneidert.
Schlüsselfertige Schnittstellen sind für ihren Einsatzzweck maßgeschneidert

Ein wesentlicher Nachteil einer solchen Vorgehensweise ist die Zeitverzögerung. Diese kann dazu führen, dass falsche Entscheidungen aufgrund nicht aktueller Daten getroffen werden. Das kann zur Verärgerung seitens der Kunden und zu Umsatzverlusten führen. Beispielsweise könnte auf der Webseite des Onlineshops ein Artikel noch als ausverkauft angezeigt sein, wenn die neue Lieferung bereits eingetroffen ist. Andersherum könnte auf der Webshop-Seite angegeben sein, dass bestimmte Artikel vorrätig sind, während sie in Wirklichkeit nicht mehr auf Lager sind. Wenn dann z. B. der Kunde ein zum Kindergeburtstag bestelltes Fahrrad nicht pünktlich bekommt, werden dadurch die Kundenloyalität und die Shop-Bewertungen in Mitleidenschaft gezogen.

Anbindung vs. Integration: weitere Punkte, die es zu beachten gibt

Weil ERP-Software heute noch oft lokal betrieben wird, der Onlineshop dagegen öffentlich, agieren beide Systeme in unterschiedlichen Netzwerken. Sie unterliegen deswegen auch unterschiedlichen Sicherheitsstandards. Ein Onlineshop muss – weil wegen öffentlichem Betrieb mehr gefährdet – höhere Sicherheitsstandards erfüllen, als ein lokales ERP-System. Dazu kommen möglicherweise unterschiedliche Betriebssysteme, auf denen die ERP- und die Webshop-Software laufen. Darüber hinaus muss ein Webshop häufig an zusätzliche Services, wie z. B. einen Payment-Service Provider angebunden werden. Diese Unterschiede und Anforderungen können unter Umständen den Aufwand einer Integration deutlich erhöhen.

Bei einer Anbindung mittels einer Schnittstelle sollte man andererseits beachten, dass der Datenaustausch vom Shop und der ERP-Lösung zumeist einen Datenverkehr zwischen zwei eigenständigen Datenbanken voraussetzt. Die Datenübertragung sollte deswegen verschlüsselt werden.

Fazit

Grundsätzlich sollte man sich auch bewusst sein, dass es neben einer vollen Integration und einer losen Anbindung mehrere Zwischenstufen gibt. Die Wahl der Integrations- bzw. Anbindungstiefe sollte das optimale Verhältnis zwischen den erwarteten geschäftlichen Vorteilen und dem Aufwand bzw. dem Risiko im Zusammenhang mit der Umsetzung und dem Betrieb einer gegebenen Software-Lösung bestimmen. Unternehmen sollten also vor Projektstart sorgfältig evaluieren, welches Szenario entsprechend der etablierten Prozesse und der vorhandenen IT-Umgebung das passende ist. Gute Praxisbeispiele, technische Szenarien bis hin zu schlüsselfertigen Lösungen gibt es reichlich. Allein das einzig wahre und für alle Bedürfnisse perfekte Set-up ist nicht am Markt verfügbar. Das muss jedes Unternehmen für sich selbst erarbeiten.

Autor

Nicole Lipphardt OXID eSales AG

Nicole Lipphardt studierte Germanistik und Politikwissenschaft an der Albert-Ludwigs-Universität Freiburg. Über Umwege kam sie nach dem Studium zur Marketing Kommunikation bei GE Healthcare IT und später bei der Testo AG. Dort tauchte sie tief in die Facetten des Marketing ein. Ihre Leidenschaft für den redaktionellen Bereich lebt Nicole heute als Content Marketing Managerin bei der OXID eSales AG aus.

OXID implements GraphQL

(By Pierluigi Meloni, Product Manager OXID eSales AG)

APIs, Schnittstellen zwischen Systemen, Trennung von Front Ends und Back Ends, Data Consumer jeglicher Art… sind im E-Commerce wirklich nichts neues. Es gibt im E-Commerce seit Jahren kreative Lösungen für bunt zusammengestellte Systemlandschaften. Trotzdem schafft es 2019 ein Buzzword wie „headless“ wieder auf‘s Podium. Wo bis vor kurzem „headless“ noch in einem Atemzug mit REST genannt wurde, betritt nun ein weiterer Player die Bühne der weiten Öffentlichkeit. Und das völlig zu Recht. Sein Name: GraphQL.

Was ist GraphQL?

Einfach gesagt ist GraphQL nichts anderes als eine query language (Anfragesprache), welche von Facebook 2015 veröffentlicht wurde und heute auch von anderen namhaften Playern wie GitHub, Pinterest oder Twitter eingesetzt wird. GraphQL wird verwendet, um auf Schnittstellen zuzugreifen und um Datentypen für Abnehmersysteme zu spezifizieren.

Ist GraphQL besser als REST?

Im Netz trifft man auf viele Vergleiche zwischen GraphQL und REST. Man kann in Foren-Glaubensgemeinschaften unendlich lange Diskussionen darüber lesen, welches Konzept die bessere Wahl ist. Generell ist ein objektiver Vergleich schwer, da GraphQL (wie bereits erwähnt) eine query language ist und REST lediglich ein Architekturkonzept für netzwerkbasierte Software, welches als Ergebnis einer Dissertation aus dem Jahre 2000 veröffentlicht wurde. Mein Anliegen ist es nicht, hier mit noch einem GraphQL/REST Vergleich SEO Traffic zu generieren, sondern zu erläutern, warum gerade GraphQL für OXID eine interessante Wahl ist.

Warum GraphQL bei OXID?

Im OXID Ökosystem gibt es verschiedene Implementierungen von REST-Schnittstellen. Das reicht von open source bis hin zu maßgeschneiderten Entwicklungen exklusiv in Projekten. OXID selbst hat bis Dato keine offizielle REST-Schnittstelle, was vor allem daran liegt, dass die Anforderungen der unterschiedlichen Projekte an die Spezifikation von Schnittstellen oft sehr weit auseinander liegen. So sieht die Realität im Projektalltag eben aus, weswegen Versprechen von „performanten Standardschnittstellen“ im E-Commerce-Zirkus oft einen bitteren Beigeschmack haben. Probleme, die man beim Anbieten von „standardisierten“ REST-Schnittstellen antrifft, sind vor allem:

  • Performance- und Flexibilitätsprobleme durch:
    overfetching: Man erhält (möglicherweise viele) Daten, die man gar nicht unbedingt braucht. Nehmen wir als Beispiel eine Schnittstelle für user, welche als Antwort sämtliche Informationen eines user liefern würde wie Name, Geburtsdatum, Adresse, Telefonnummer, E-Mail-Adresse, usw. Das ist ein Überangebot an Informationen, wenn man beispielsweise für seine APP nur die Spitznamen der user anzeigen will. So etwas erschwert die Handhabung mit dem Antwortobjekt und kann bei komplizierteren und größeren Antwortobjekten auch unnötigerweise auf die Performance gehen.
    underfetching: Oft enthalten Antworten von Schnittstellen nicht alle Informationen, die man für einen besonderen use case gerade braucht. Nehmen wir als Beispiel einen Aufruf für ein Forum, bei dem zu einem bestimmten user eine Auflistung seiner posts und seiner follower angezeigt werden sollen. Hier müssen mit großer Wahrscheinlichkeit – anstatt einer – drei verschiedene Schnittstellen angefragt werden, nämlich die für user, follower und posts. Mehr Anfragen = schlecht für die Performance. Erschwerend könnte noch hinzukommen, dass die 3 unabhängigen Antwortobjekte noch zu einem gemeinsamen Objekt fusioniert werden müssen, was anstrengend und fehleranfällig in der Handhabung ist.
  • Versionierung der Schnittstelle: API first ist ein Ansatz, welcher diesem Problem entgegenwirken soll. Die perfekte Definition der Schnittstelle, die dann möglichst lange konstant bleibt. Die Theorie ist spitze, die Realität sieht oft anders aus. So kommen neben ungeahnten Neuerungen und Features in einem lebendigen Business auch ganz banale Dinge hinzu wie Refactorings der Datenschicht beispielsweise und zack – die Schnittstelle muss versioniert werden. Ein großes Problem bei häufiger Versionierung ist die Fehlerfindung zwischen den unabhängigen Systemen, was mitunter zum echten PITA werden kann. REST gibt leider kein einheitliches Versionierungskonzept vor, weshalb Versionierung meist im Header oder im URI selbst passiert.

GraphQL wurde unter anderem – wie auch auf der offiziellen Webseite https://graphql.org angepriesen – mit gerade jenen Intentionen entwickelt, welche genau die oben genannten Probleme adressieren:

  • Performance- und Flexibilitätsoptimierungen durch:
    Minimierung von Requests: GraphQL „bündelt“ durch das Auflösen von Abhängigkeiten der Daten untereinander verschiedene Requests in nur einem einzigen Request.
    Nur das ausliefern, was auch benötigt wird: Bei GraphQL fragt man nicht einen fixen Schnittstellen-Endpunkt nach einem starren Ergebnisobjekt an, sondern man definiert schon in der Anfrage, wie das gewünschte Ergebnis aussehen soll.
  • „Evolving APIs without version“: Aufgrund der im vorigen Punkt beschriebenen Flexibilität der Anfragemöglichkeiten, kann man einer GraphQL Schnittstelle beispielsweise problemlos neue Features hinzufügen, ohne dass diese ein angebundenes Front End sprengen würden.

Man kann zwar nicht pauschal sagen, dass „GraphQL besser als REST“ ist, denn das hängt eindeutig von den Einsatzszenarien und Anforderungen ab. Aber man kann mit Sicherheit sagen, dass GraphQL für Problemstellungen im täglichen und schnelllebigen E-Commerce Business ein absoluter Mehrwert ist!

Wir konnten in Projekten bereits erste sehr gute Erfahrungen mit dem Einsatz der GraphQL machen, weswegen wir uns entschieden haben, GraphQL in den Core des OXID eShop zu integrieren. Für die Realisierung dieses Vorhabens haben wir einen Open Innovation Ansatz gewählt.

GraphQL und Taskforce Open Innovation bei OXID

Open Innovation bei OXID!

Da GraphQL für viele Entwickler – und auch für uns – noch größtenteils Neuland ist, haben wir uns dazu entschieden, die Entwicklung gemeinsam mit verschiedensten Gruppen unseres Ökosystems anzugehen, um auf Erfahrungen zurückgreifen, und um gemeinsam Innovation vorantreiben zu können. Wir haben eine Taskforce mit Vertretern von Community, Enterprise- und Solutionpartnern, Kunden, OXID Professional Services sowie dem OXID Core Development gebildet. Diese Taskforce hat Erfahrungen und Learnings eingesetzter REST-Schnittstellen diskutiert, sowie Prioritäten und Milestones in der Anbindung von GraphQL an OXID erarbeitet.

Als Hersteller einer Standardsoftware haben wir die Philosophie, dass Innovation zum größten Teil nicht an der Basis (also in der Breite) entsteht, sondern in der Spitze. Innovative Features entstehen bei den Domänenexperten in den Projekten, in agilen Use-Cases, in A/B Tests in kleinen Szenarien im Livebetrieb, wo man mehr Spielraum für Risiken hat. Hohes Innovationsrisiko in Standardsoftware bedeutet dagegen, alle Kunden zum Testballon für Technologieexperimente zu machen, und das Risiko auf Kundenseite zu verlagern. Daher liegt unsere Verantwortung weniger darin, fertige „innovative“ Features zu produzieren, sondern darin, Freiheitsgrade und eine Basis zu schaffen, auf der Innovation entstehen kann. Erreicht diese Innovation eine gewisse Reife (Funktionalität, Stabilität, Akzeptanz), dann kann sie den Weg in die Standardsoftware finden. Genau so sind wir hier auch vorgegangen.

OXID selbst hat die Anbindung von GraphQL bereits realisiert, dokumentiert und im Rahmen der Taskforce released. Dazu gibt es best practice Beispiele, wie spezielle Routen (vgl. Schnittstellen: schemas, types, mutations) umgesetzt werden sollten. Die restlichen Mitglieder der Taskforce können auf dieser Basis die für sie relevanten Routen implementieren, welche innerhalb der Taskforce geteilt und optimiert werden. Das Ziel ist hierbei, die relevantesten Routen zu identifizieren, sie product-ready zu machen, um sie dann Stück für Stück in den Core zu überführen, bis am Ende „vollumfängliche“ Routen für den OXID eShop zur Verfügung stehen.

Pierluigi Meloni

Pierluigi Meloni war schon in der Schule dagegen. Schon damals waren Fragen wie „Warum sollte jemand so etwas überhaupt machen wollen?“ ständige Begleiter des Alltags. Das ist bis heute auch so geblieben, weswegen er als Software Architect und Requirements Engineer auf Herangehensweisen wie Domain-Driven Design schwört und seinen Fokus auf die sorgfältige Klärung des WAS richtet. Tätig in verschiedensten Branchen ist er vor knapp 3 Jahren im E-Commerce gelandet, wo das „Was“ eine besondere Herausforderung darstellt, da es meist einem anarchistischen Pool entspringt, dessen Grenzen Technikgenies und Marktschreier bilden. Humor mag er auch.

Gastblog: Mit Microsoft AX 2012 neue Wege im E-Commerce beschreiten

Stetige Informationen sind Anspruch und Bedürfnis moderner Kunden: 24 Stunden, 7 Tage die Woche. Eine zentrale Rolle spielt dabei ein gut integriertes E-Commerce-Portal. Es ist Chance und Herausforderung zugleich für Handelsunternehmen aller Art. Bieten Websites und Webshops doch Kunden eine optimale Plattform für eine selbständige Informationsversorgung. Dies bedeutet nicht nur Service am Kunden. Es entlastet auch bestehende Kundenkanäle wie den telefonischen Support oder den Verkaufsinnendienst.

Voraussetzung für den erfolgreichen Schritt in den E-Commerce

Ein wesentlicher Faktor für den Erfolg eines Online-Vertriebskanals ist die reibungslose Anbindung des Shops an das Warenwirtschaftssystem eines Unternehmens. Durch eine automatische Übertragung aller relevanten Daten werden diese zentral verwaltet. So lassen sich Prozesse effizienter gestalten. Das spart Zeit und Geld. Und nur so ist es möglich, erfolgreich und kundenfreundlich zu wirtschaften.

Mit OXID4AX wird Microsoft Dynamics AX Anwendern eine umfassende Lösung für den Einstieg in den E-Commerce geboten. Die Optimierung und Verschlankung der Arbeitsprozesse des Webshop-Betreibers gewährleisten eine schnelle Amortisation von Investitionen in den Webshop.

Zusammenspiel Microsoft Dynamics AX und OXID eShop

Unternehmen, die bereits Microsoft Dynamics AX im Einsatz haben, lassen häufig viel Zeit und Ressourcen in die unternehmensspezifische Anpassung des Systems fließen. Daher steht bei OXID4AX eine Trennung der Systeme im Vordergrund. Dennoch erfolgt eine saubere Integration. Microsoft Dynamics AX und der OXID eShop bleiben eigenständig in ihrer Logik.

OXID eShop Schnittstelle in Microsoft Dynamics AXOXID4AX ist ein Add-On für Microsoft Dynamics AX. Darin inbegriffen sind der OXID eShop sowie die Schnittstelle OXAX für eine 100 %-ige Integration des Vertriebskanals in die Microsoft ERP-Lösung. Umfangreiche Stammdaten zu Produkten und Kunden werden zentral im ERP gepflegt und stehen dem Webshop sofort zur Verfügung. In Echtzeit erhalten Shopbesucher Informationen zu verfügbaren Artikeln und aktuellen Lagerbeständen.

Ein komplexes Thema beim Betreiben eines Shops ist die Preisgestaltung. Im Rahmen von OXID4AX sind sämtliche in Microsoft Dynamics AX verfügbaren Preisstrukturen an den Shop übertragbar. Damit sind sowohl B2C- als auch B2B-Kunden individuell ansprechbar. Ausgehandelte Konditionen werden automatisch berücksichtigt.

Zudem erfolgt eine Anpassung der vorhandenen Informationen im OXID eShop Kundenportal. Neben der Bestellhistorie sind sämtliche in Microsoft Dynamics AX generierten Rechnungen im PDF-Format verfügbar. Beides wird in Echtzeit aus dem ERP-System abgerufen. Das beinhaltet auch Bestellungen, die direkt in Microsoft Dynamics AX erfasst wurden. So bleibt der Kunde vollumfänglich über seine getätigten Bestellungen auf dem Laufenden.

Was ist mit OXID4AX noch möglich?

Die Standardlösung bietet bereits eine umfangreiche Integration von Shop und ERP. Doch durch die flexible Architektur beider Systeme sind Weiterentwicklungen möglich. Dank zahlreicher, frei verfügbarer Module kann man mit der rasanten technologischen Entwicklung problemlos Schritt halten.

Vorteile und Nutzen auf einen Blick

OX4AX_tabelleFazit

OXID4AX macht die Integration eines Shops ins Microsoft Dynamics AX zum Kinderspiel. Langwierige Implementierungsphasen gehören der Vergangenheit an. Der Mehrwert einer voll integrierten E-Commerce-Lösung liegt in der Kundenzufriedenheit, Kundenbindung und langfristig im gesteigerten Umsatz. So wird der E-Commerce zum Erfolgsfaktor einer jeden Unternehmung.

Autor:

Anne-Rosenthal_blog_swAnne Rosenthal ist bei der ESYON GmbH die Spezialistin für Marketing und PMO. Bei der Entwicklung von OXID4AX war sie als PMO maßgeblich beteiligt und leistete mit der Evaluierung der Marktsituation die wesentliche Grundlage des Projektes. Als E-Commerce-Spezialistin betreut sie verschiedene Webanwendungen der ESYON GmbH aus Leipzig. Privat lebt sie ihren Beruf weiter und betreibt einen Blog rund um bunte Tassen, Familie und Leipzig.