7 Konzepte zur Beschleunigung Ihres digitalen Handels
Die neuesten Speed Hacks für Technologie, Team- und ProjektmanagementWarum Geschwindigkeit ein entscheidender Erfolgsfaktor im E-Commerce ist
Geschwindigkeit ist zu einem elementar wichtigen Erfolgsfaktor im digitalen Handel geworden, da sich die Märkte schneller denn je verändern. Mit der Entwicklung der Technologie steigt der Druck zur Digitalisierung und gleichzeitig auch die Kundenerwartungen. Um sich von der Konkurrenz abzuheben und immer auf der Höhe der neuesten Marktentwicklungen zu sein, müssen Unternehmen schnell handeln und sich anpassen können. Sie müssen kontinuierlich neue Ideen, Funktionen, Touchpoints oder ganze Geschäftsmodelle testen, um ihr digitales Angebot ohne lange Umwege zu verbessern. Letztendlich führt eine kürzere Time-to-Market, sei es für einen großen Launch einer Commerce-Software oder kleinere Projekte für spezifische Features, zu einem schnelleren Return on Investment (ROI) und geringeren Total Cost of Ownership (TCO).
Aber die Fähigkeit, schnell auf jeden Umstand zu reagieren, ist für viele Unternehmen nicht einfach zu erreichen. Wie kann man eine effiziente Zusammenarbeit von IT- und Business-Abteilungen fördern? Wie etabliert man am besten eine Test-und Lernkultur? Wie kann man das Potenzial und die Relevanz neuer technologischer Entwicklungen bewerten? Die bestehende Technologie-Landschaft steht einem höheren Tempo oft im Weg, denn monolithische Legacy-Systeme sind meist nicht für schnelle Anpassungen ausgelegt, da sie vor Jahren für andere Marktbedürfnisse entwickelt wurden. Gleiches gilt für Teamstrukturen, interne Prozesse und Mindsets vieler Unternehmen, die ebenfalls für das Ziel von schnellen, agilen Lösungen im Digital Commerce optimiert werden müssen.
Dieser Guide soll Unternehmen einen Überblick über die neuesten Konzepte geben, mit denen sie eine höhere Geschwindigkeit im E-Commerce erreichen können. Die neuesten technischen Entwicklungen werden aufgezeigt und es wird erklärt, wie man ihren Nutzen aus geschäftlicher Sicht bewerten kann. Außerdem wird erörtert, welche Managementansätze Sie nutzen können, um Ihre IT-Teams und Commerce-Projekte zu beschleunigen
Konzept #1: Fusion Teams
Definition
Im Jahr 2020 führte Gartner den Begriff Fusion Teams als neues Modell für die digitale Wertschöpfung ein. Fusion Teams sind multidisziplinäre Teams, die Technologie- und andere Arten von Domänenexpertise mischen und oft darauf ausgelegt sind, Produkte und nicht Projekte zu liefern.
Die Zukunft der abteilungsübergreifenden Zusammenarbeit
Laut Gartner überdenken Unternehmen, die im digitalen Commerce erfolgreich sind, die Art und Weise, wie sie arbeiten. Fusion Teams ersetzen mehr und mehr homogene Abteilungen und gehen Hand in Hand mit einer immer schnelleren Aufweichung der Grenzen zwischen IT und dem Rest des Unternehmens. Wie die Daten von Gartner zeigen, haben bereits mindestens 84 % der Unternehmen und 59 % der staatlichen Einrichtungen Fusion Teams eingerichtet.
Letztlich sind Fusion Teams ein Mittel, um den maximalen Wert aus digitalen Erstellungsprozessen zu ziehen. Fusion Teams tun dies, indem sie die Befugnisse und Verantwortlichkeiten innerhalb des Teams erhöhen und digitale Fähigkeiten auf das gesamte Unternehmen übertragen. Das hilft, digitale Talent-Silos zu vermeiden und bringt die Unternehmens-IT näher an den Kern der Wertschöpfung.
Um das zu erreichen, schlägt die Gartner-Studie vor, dass fortschrittliche CIOs und Führungsteams sich mehr auf die menschliche Seite des Managements digitaler Geschäftsrisiken konzentrieren sollten, wie z. B. kulturelle, organisatorische und verhaltensbezogene Aspekte. Zudem sollten digitale Geschäftsinitiativen gefördert werden, die dezentral und simultan statt zentral und sequenziell sind.
Beispiel: State Machines zur Vereinfachung der Zusammenarbeit
Wir bei Spryker verstehen unsere Technologie als einen Wegbereiter für Kollaboration, der Innovationen und eine Test- und Lernkultur fördern kann. Unsere State Machine zum Beispiel löst die Herausforderung, alle geschäftlichen Anforderungen in eine kohärente IT-Struktur zu übersetzen und sorgt so für eine reibungslose Zusammenarbeit über Abteilungsgrenzen hinweg.
State Machines haben ihren Ursprung in der Mathematik. Für Unternehmen können sie ein Werkzeug sein, um komplexe Prozesse einfach zu implementieren und verschiedene Geschäftsabläufe abzubilden und zu automatisieren, wodurch die Effizienz schnell gesteigert werden kann. Einfach ausgedrückt liest eine State Machine eine Folge von Ereignissen und wechselt oder verbleibt in einem ihrer individuell vordefinierten Zustände. Diese Methodik erlaubt es Unternehmen, komplexe Journeys abzubilden und Prozesse zu automatisieren, z.B. im Auftragsmanagement.
Im Auftragsmanagement könnten die verschiedenen Zustände „Auftrag ist neu“, „autorisiert“, „Zahlungseingang“, „versandt“ sein. Der Übergang von einem Zustand zum anderen geschieht durch Ereignisse, die automatisch verarbeitet werden können, z.B. Bestellung wird nach Zahlungseingang autorisiert, oder manuell durch einen Klick im Backoffice. Das Abbilden solcher Prozesse mit einer State Machine ist vollständig anpassbar und verringert den Zeitaufwand für die Verwaltung von kompliziertem Code durch Ihr Entwicklerteam. Und aufgrund der leicht verständlichen Übersicht können auch beteiligte Nicht-IT-Stakeholder den Prozess überprüfen und verbessern, was die State Machine so effizient für den Einsatz in Fusion Teams macht. Sie verbessert die Zusammenarbeit Ihres Teams und die Geschwindigkeit der Ausführung.
Konzept #2: Brooks’s Law
Definition
Brooks’s Law ist eine Beobachtung über Software-Projektmanagement, die von Fred Brooks (1975) geprägt wurde. Die Kernaussage von Brooks’s Law ist: “adding manpower to a late software project makes it later”, d. h., es gibt eine negative Korrelation zwischen Teamgröße und Projektgeschwindigkeit aufgrund der zusätzlichen Komplexität..
Zusätzliche Komplexität überwiegt die erhöhte Arbeitskraft
Warum würde eine zusätzliche Person, die zu einem Projekt hinzugefügt wird, zu mehr und nicht zu weniger benötigter Zeit führen? Erstens wird es immer eine gewisse Anlaufzeit geben, d. h. es dauert eine Weile, bis die zu einem Projekt hinzugefügten Personen produktiv werden. Zweitens steigt der Kommunikationsaufwand mit zunehmender Anzahl von Personen. Und drittens könnte die begrenzte Aufteilbarkeit der Aufgabe zu mehr Chaos führen.2
Natürlich müssen die Erfahrung und der Kenntnisstand der beteiligten Entwickler sowie die Qualität der verfügbaren Dokumentation berücksichtigt werden, und das Brooks‘sche Gesetz gilt speziell für Projekte, die bereits in Verzug sind. Nichtsdestotrotz wird der zusätzliche Zeitaufwand für die Besprechung der Aufgabenstellung, der Verpflichtungen und der technischen Details sowie für die Bewertung der Ergebnisse unabhängig von ihrem Erfahrungsstand exponentiell steigen, wenn mehr Personen zu einem Projekt hinzukommen.
Beispiel: 7 Jahre vs. 14 Tage Projektdauer
Auch wenn Brooks’s Law natürlich eine starke Vereinfachung ist, gibt es viele Beispiele aus der Praxis, die seine praktische Relevanz belegen.
Ein berühmtes Worst-Case-Beispiel ist das 500 Millionen Euro teure SAP-Desaster von Lidl. Lidl beauftragte im Jahr 2011 den Softwareanbieter SAP mit der Entwicklung eines neuen ERPSystems. Mehr als 7 Jahre, 3 verschiedene CEOs und 500+ Millionen Euro versunkene Kosten später wurde das Projekt unvollendet abgebrochen. Dies zeigt deutlich, dass die wachsende Projekt- und Teamgröße eine enorme Verlangsamung bedeutete. Es arbeiteten mehrere hundert Entwickler an dem Projekt, es wurden immer mehr externe Berater hinzugezogen und es war trotzdem (oder gerade deshalb) nicht möglich, das Projekt innerhalb von 7 Jahren zum Abschluss zu bringen.
Ein aktuelles positives Beispiel dafür, wie man die Gefahren von Brooks‘s Law vermeiden kann, ist ein anderer deutscher Lebensmittelhändler, der Spryker-Kunde Globus. Sie hielten ihr Click & Collect-Projekt von Anfang an so klein wie möglich, mit wenigen Stakeholdern und klaren Verantwortlichkeiten. Dadurch konnte Globus eine sofortige Umsetzung in allen Phasen des Projekts erreichen und das Projekt schließlich nach nur 2 Wochen mit dem erfolgreichen Launch der Click & Collect-Lösung abschließen.
Konzept #3: Conway’s Law
Definition
Conway’s Law besagt, dass jede Organisation, die ein System (im weitesten Sinne) entwirft, ein Design produziert, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist5 . Das bedeutet, dass Systeme (Software, Geschäftsmodelle, ...) die Kommunikationsstrukturen des ursprünglichen Unternehmens widerspiegeln..
Würde Tesla anders aussehen, wenn es die Historie von General Motors hätte?
Das Gesetz von Conway hilft dabei, die Kräfte zu verstehen, die bei der Organisation von Teams im Spiel sind und lang anhaltende, oft unbeachtete Auswirkungen haben können. Kurz gesagt: Nach Conway’s Law werden Organisation, deren Strukturen aus der Vergangenheit stammen, wahrscheinlich nie das Softwaresystem oder Geschäftsmodell der Zukunft hervorbringen. Große Unternehmen, deren Abteilungen ständig miteinander im Streit liegen, können kaum effizient funktionierende Geschäftsmodelle aufbauen. Die Idee, dass in großen Unternehmen die besten Köpfe aus abgeschotteten Abteilungen an neuen Geschäftsmodellen arbeiten, würde zunichte gemacht.
Das Gesetz von Conway stammt ursprünglich aus der Informatik, ist aber zumindest teilweise auf digitale Geschäftsmodelle anwendbar, da für sie die gleichen Regeln gelten. Die Art und Weise, wie Teams zusammengesetzt sind und interagieren, basiert oft auf vergangenen Projekten und/oder LegacyTechnologien und spiegelt ein Organigramm wider, das vor vielen Jahren erstellt wurde. Sie müssen verstehen, welches Ergebnis benötigt wird, bevor Sie die Teams organisieren, um Kommunikationswege und Strukturen im Unternehmen zu vermeiden, die am Ende die Ergebnisse diktieren. Große Unternehmen haben das Problem erkannt und versuchen nun, ihre IT-Abteilungen zu reorganisieren. Immerhin ist das ein Anfang, auch wenn die Reorganisation beim Vorstand beginnen muss.
Beispiel: METRO wendet Conway’s Law zur Digitalisierung an
Der Spryker Kunde METRO ist ein international führender Spezialist im Groß- und Lebensmittelhandel; ein Geschäftsfeld, in dem die IT bisher eine Unterstützungsfunktion für das klassische B2B-Großhandelsgeschäft hatte. Doch bei METRO hatte man ehrgeizige Ziele und das Credo, eigene Systemkomponenten zu entwickeln, die einen Wettbewerbsvorteil versprechen. Gemäß Conway‘s Law erkannte METRO, dass diese angestrebte Gestaltung der Zukunft aus den alten Strukturen heraus nahezu unmöglich sein würde. Deshalb wurde die Tech-Unit METRONOM aus der METRO AG ausgegliedert.
Als eigenständige Einheit gewann METRONOM deutlich an Flexibilität und Geschwindigkeit und konnte den digitalen Handel der METRO unvoreingenommen und innovativ gestalten. Sie verfolgten den Omnichannel-Ansatz, um den Kunden den Einkauf so schnell und effizient wie möglich zu machen, z. B. durch die Pilotierung einer App, die Kunden bei der Navigation durch die riesigen Märkte hilft. Das neueste digitale Projekt sind flexible Online-Shops für Einzelhändler, die eine spezielle Zielgruppe mit individuellen Anforderungen sind. METRO hat dies als Pilot in Rumänien schnell gelauncht und wird es nach dem ersten Test weiter ausrollen.
Timo Salzsieder, CIO/CSO der METRO AG und CEO von METRONOM, sagt: „Die Motivation für die Zusammenarbeit mit Spryker war, unsere Technologie zu erweitern, schneller zu skalieren und unseren Kunden einen breit gefächerten Funktionsumfang zu bieten.
Konzept #4: CVP
Definition
CVP steht für „Corona Viable Product“ und ist eine Abwandlung des Begriffs MVP (Minimum Viable Product). CVP beschreibt die Philosophie, sich auf unmittelbare Anforderungen und schnellstmögliche Anpassungen zu konzentrieren. Die Idee wurde als Reaktion auf plötzliche Marktveränderungen durch die COVID-19-Pandemie eingeführt.
When MVP is not Fast Enough Anymore
Die Idee des Minimum Viable Product (MVP)-Ansatzes für die Softwareentwicklung tauchte erstmals vor 20 Jahren auf und wurde mit der Veröffentlichung von The Lean Startup von Eric Ries 2011 zum Mainstream. Eine Anwendung zunächst als MVP zu starten ist mittlerweile gängige Praxis für viele Unternehmen. Dabei werden Produkte erstellt, die gerade genug Funktionen haben, um Early Adopters anzulocken und das nötige Feedback zu erhalten, um ein Produkt früh im Entwicklungszyklus zu validieren oder zu verwerfen, bevor zu viel Geld ausgegeben wurde.
Diese agile Methodik soll es Unternehmen ermöglichen, Produkte schneller auf den Markt zu bringen. Doch in der Realität wurde oft mehr über MVPs geredet als sie tatsächlich eingesetzt wurden. Als COVID aufkam, standen viele Unternehmen plötzlich unter enormem Druck, überhaupt zu überleben. Der Fokus verlagerte sich von der Frage, was das beste Produkt oder die beste Plattform ist, auf die Frage, wie man die Kunden jetzt bedienen und das Unternehmen retten kann. Infolgedessen wurde die „Corona Viable Product (CVP)“-Philosophie geboren, die sich darauf konzentriert, unmittelbare Anforderungen zu erfüllen, anstatt ein MVP zu entwickeln, das sich mehr auf wünschenswerte Funktionen konzentriert.
Beim CVP-Ansatz dreht sich alles um die Beschleunigung Ihres Geschäfts. Unternehmen, die dieses Prinzip umsetzen können, sind in der Lage, schnell auf sich ändernde Marktbedingungen aller Art zu reagieren; und deshalb sind CVPs für die krisengeplagte Realität der Software-Entwicklung im Jahr 2021 noch relevanter als MVPs. Und jetzt, da Unternehmen einen Vorgeschmack darauf bekommen haben, wie schnell Projekte wirklich ablaufen können, werden CVPs auch nach der Pandemie bestehen bleiben und wahrscheinlich die Softwareentwicklung für immer verändern.
Beispiel: Toyota launcht ein CVP zur Unterstützung seiner Autohändler in nur 3 Wochen
Toyotas Autohändler waren vom Lockdown stark betroffen. Um sie zu unterstützen, wollte Toyota einen B2B2C-Online-Katalog erstellen, mit dem die Händler ihre Produkte online präsentieren konnten, während ihre Autohäuser geschlossen waren. Dieses Szenario, in dem die Händler mit den Endkunden in Kontakt treten und interagieren konnten, musste in einer rekordverdächtig kurzen Time-to-Market von 3 Wochen realisiert werden.
Jens Brech, Director Customer Experience and Network Quality bei Toyota, sagt: „Wir brauchten sofort eine Lösung, aber die Erwartung war, dass eine Lösung zwei oder drei Monate dauern würde. In normalen Zeiten wäre das für uns sehr schnell gewesen, aber in der Krise war es nicht akzeptabel. Und letztlich konnten wir den neuen Vehicle Stock Locator auf unserer Website in nur drei Wochen live bringen, was unglaublich war.“
Wenn es darum geht, eine schnelle Einführung im CVP-Stil zu ermöglichen, ist die Änderung der Denkweise oft eine größere Herausforderung als die Änderung der zugrunde liegenden Technologie. Toyota wusste, dass das Produkt nach der Schließung der Filialen schnell zu den Kunden gelangen musste; man verstand diese Anforderung sofort, weil man die richtige CVPMentalität hatte.
Konzept #5: Composable Commerce & PBC
Definition
Composable Commerce ist die von Gartner definierte Idee, dass Unternehmen in der Lage sein sollten, „Best-of-Breed“-Komponenten anstelle von festgelegten Standardlösungen im E-Commerce auszuwählen und diese zu einer maßgeschneiderten Anwendung zu kombinieren oder zu „komponieren“, die auf ihre Geschäftsanforderungen zugeschnitten ist. Das bedeutet, dass Softwarelösungen aus Paketen von Komponenten bestehen sollten, die einzeln genutzt und je nach Bedarf mit anderen Anbietern verbunden werden können.
“Bis 2023 werden Unternehmen, die einen Composable-Ansatz verfolgen, die Konkurrenz bei der Geschwindigkeit der Implementierung neuer Funktionen um 80 % übertreffen.“
Der Kern von schnellem digitalen Commerce ist Anpassungsfähigkeit
Moderne, ansprechende Kundenerlebnisse zu schaffen, ist schwieriger denn je, da die Kundenerwartungen in den letzten Jahren in die Höhe geschnellt sind. Deshalb reicht es nicht mehr aus, nur Standardfunktionen als Pauschalangebot zu nutzen. Das Composable Commerce-Prinzip nutzt die Vielfalt des Angebots an Commerce-Services, um Unternehmen die Möglichkeit zu geben, genau das auszuwählen, was zu ihren Geschäftsanforderungen passt. Kein Unternehmen sollte gezwungen sein, überflüssige Technologie zu verwenden.
Composable Commerce erreicht dies durch die Kombination von Packaged Business Capabilities (PBCs). PBCs wurden auch von Gartner8 eingeführt und beschreiben eine Zusammenstellung von Funktionalitäten, die in größeren Clustern gruppiert sind. Diese Cluster oder Bündel bilden logische Geschäftseinheiten wie Order Management, CRM oder Preise & Promotionen. Ein Composable-Ansatz nutzt mehrere Anbieter und deren bewährte, umfassende Funktionen für ihr jeweiliges Angebot, um die bestmögliche Lösung für jedes dieser Cluster zu finden.
Der digitale Handel unterliegt einer fortschreitenden Modularisierung und Composable Commerce ist der nächste Schritt zur Schaffung zukunftssicherer digitaler Handelserlebnisse.
Die positiven Auswirkungen auf die Geschwindigkeit liegen vor allem in der gewonnenen Flexibilität bei Anpassungen und dem Tempo, mit dem neue Lösungen zur Marktreife gebracht werden können, indem auf spezialisierte Lösungen verschiedener Anbieter zurückgegriffen wird.
Beispiel: Der Unterschied zwischen Microservices und PBCs
Die Begriffe Microservices und PBCs sind sich sehr ähnlich und können zu Verwirrung führen. Tatsächlich sind die beiden Konzepte aber komplementär. Microservices sind eine Art und Weise, in der eine Anwendung in kleine Funktionen oder Features zerlegt wird oder werden kann. Packaged Business Capabilities sind funktional sinnvoll gebündelte Sätze von Microservices.
Composable Commerce setzt auf PBCs statt auf Microservices, weil es den Best-of-Breed-Ansatz betont. Microservices sind dafür zu kleine, granulare Einheiten innerhalb einer einzigen Lösung. Martin Fowler, Autor zu Softwareentwicklung und Chief Scientist bei ThoughtWorks, sagt: „Ziehen Sie Microservices nur dann in Betracht, wenn Sie ein System haben, das zu komplex ist, um es als Monolith zu verwalten“.
Composable Commerce ist also der Sweet Spot zwischen der Modularität von Microservices und der Einfachheit eines Monolithen. Deshalb können Unternehmen im Spryker Cloud Commerce OS ihre benötigten Funktionen auswählen und sie einfach zusammenfügen. Spryker wird Sie niemals dazu zwingen, Kompromisse bei den Lösungen einzugehen, die für Ihr Unternehmen am besten geeignet sind. Mit einem Best-of-Breed-Ansatz und -Mentalität sowie einer riesigen Partnerlandschaft ermöglicht Spryker seinen Kunden grenzenlose Flexibilität und eine beispiellose Geschwindigkeit.
Konzept #6: Headless
Definition
Headless Commerce ist eine E-Commerce-Architektur, die eine Trennung zwischen dem Frontend (kundenorientierter Teil) und der Backend-Infrastruktur (wo sich normalerweise der Warenkorb, der Produktkatalog, das Zahlungs-Gateway und andere Funktionen befinden) ermöglicht. Vereinfacht ausgedrückt, ist bei Headless Commerce das Frontend vom Backend entkoppelt.
Kundenorientierung durch Flexibilität in der Entwicklung erreichen
Das Frontend ist der Ausgangspunkt für die Optimierung von Conversion Rates oder das Ausprobieren neuer Touchpoints. Daher erfordert es eine Menge Experimente und Änderungen. Das Backend muss sicher sein und wird folglich in einem ganz anderen Tempo entwickelt. Headless-Architektur bedeutet, dass beide Schichten unabhängig voneinander entwickelt werden, sodass sie sich nicht gegenseitig negativ beeinflussen.
Traditionelle E-Commerce-Systeme sind meist monolithisch und bieten nur wenig Raum für Flexibilität. Bei solchen Systemen sind das Frontend und das Backend untrennbar miteinander verbunden, was es für Entwickler schwierig macht, Änderungen am Frontend vorzunehmen, ohne das Backend zu beeinträchtigen. Dies stellt in der Regel eine Herausforderung für Unternehmen dar, die sich eine viel individuellere und flexiblere Benutzererfahrung wünschen.
In einer Zeit, in der der Kampf um die Aufmerksamkeit der Verbraucher auf einem Allzeithoch ist, kann eine kundenzentrierte Strategie bei Ihren E-Commerce-Bemühungen helfen, den langfristigen Erfolg Ihres Unternehmens zu sichern. Um dies jedoch erfolgreich zu erreichen und gleichzeitig agil und schnell zu bleiben, benötigen Sie eine Headless Commerce-Lösung.
Beispiel: Integration von IoT mit Spryker Cloud Commerce OS
Ein gutes Beispiel für die Anwendung der Headless-Technologie ist IoT. Heutzutage nutzen Verbraucher z. B. Sprachassistenten, die sie bei der Erledigung alltäglicher Aufgaben unterstützen. Jedes Voice Device kann über die GLUE API mit dem Spryker Cloud Commerce OS Backend verbunden werden.
Die innovativen Lösungen von Spryker verfügen über verschiedene Fähigkeiten und Funktionen, die das Kundenerlebnis verbessern. Die GLUE API-Funktionen von Spryker ermöglichen es B2B- und B2CUnternehmen, sich mit ihren Kunden über verschiedene Touchpoints wie Wearables, Sprachgeräte und sogar Smart-Shelves im Laden oder im Lager zu verbinden. Einige dieser Funktionen umfassen das Anzeigen von Produktoptionen, die Erstellung von Wunsch- oder Einkaufslisten, die Verwaltung von Bestellungen, die Handhabung von Zahlungsmethoden und Mehrfachlieferungen.
Mit den zahlreichen Headless-Angeboten von Spryker können Unternehmen eine erhöhte Skalierbarkeit und Agilität erreichen. Heute besteht mehr denn je die Notwendigkeit, relevante Funktionalitäten schnell bereitzustellen, die Kunden zufriedenstellen und den Geschäftsbetrieb reibungsloser ablaufen lassen. Headless Commerce garantiert, dass die Benutzererfahrung durchgängig konsistent bleibt und seine umfangreichen Anpassungsmöglichkeiten schaffen ein viel stärkeres Markenimage für die Kunden von Spryker.
Konzept #7: PaaS vs SaaS
Definiton
Software as a Service (SaaS) und Platform as a Service (PaaS) sind beides Modelle von Cloud-Diensten für Unternehmen. SaaS nutzt das Internet, um Anwendungen, die von einem Drittanbieter verwaltet werden, für seine Benutzer bereitzustellen. PaaS stellt Entwicklern ein Framework zur Verfügung, auf das sie aufbauen können, um individuelle Anwendungen zu erstellen..
Braucht Ihr digitales Business eine Standard- oder maßgeschneiderte Lösung?
Jedes Modell des Cloud Computing hat seine Vor- und Nachteile. Daher ist es wichtig zu erkennen, welches Modell für ein Unternehmen das richtige ist. SaaS ist eine standardisierte Lösung mit sehr begrenzten Möglichkeiten zur Anpassung und Differenzierung. Sie hilft Unternehmen, Zeit und Geld für mühsame Aufgaben wie die Installation, Verwaltung und Aktualisierung von Software zu sparen. Auf der anderen Seite geht dies auf Kosten der Anpassungsfähigkeit, einer Anbieterbindung und einer begrenzten Kontrolle über Funktionen und Leistung. Im digitalen Handel eignet sich SaaS vor allem für einfache B2CUmgebungen, insbesondere für Anwendungsfälle im Einzelhandel, bei denen es um den Aufbau einfacher Webshops geht.
PaaS-Anwender können traditionell über einen Webbrowser auf eine Softwareentwicklungsplattform zugreifen. Der einfache Zugang zu einer Suite von Entwicklungstools bedeutet, dass Entwickler programmieren können und Unternehmen schnell neue Anwendungen bereitstellen können. Während SaaS für Standardlösungen steht, ist PaaS der beste Weg, über den Standard im E-Commerce hinauszugehen. Es gibt keine Grenzen in Bezug auf Anpassung und Integration und es bietet maximale Skalierbarkeit und Verfügbarkeit. PaaS eignet sich am besten für Unternehmen, die sehr individuelle oder komplexe Geschäftsanforderungen und anspruchsvolle transaktionale Anwendungsfälle wie Unified Commerce oder Enterprise-Marktplätze lösen wollen.
Letztlich muss jedes Unternehmen seine Geschäftsziele abwägen und sich darüber im Klaren sein, was es braucht, um eine fundierte Entscheidung zu treffen. In Bezug auf die Geschwindigkeit sind sowohl SaaS als auch PaaS einer On-Premise-Lösung weit überlegen. PaaS weitet diese Schnelligkeit lediglich auf komplexe Anwendungsfälle und Anpassungen aus.
Beispiel: Pizza as a Service
Um die Unterschiede zwischen PaaS, SaaS und On Premise zu verdeutlichen, verwenden wir die Analogie des Pizzaessens.
- Homemade (Traditionalle On Premise-Lösung)
Eine On-Premise-Lösung ist das Äquivalent zum Selbermachen einer Pizza zu Hause. Sie müssen sich um alles selbst kümmern. Vom Besorgen der Zutaten über die Zubereitung der Pizza bis hin zum Decken des Tisches und Aufräumen. - Pizzalieferdienst (Platform as a Service – PaaS)
Die PaaS-Version des Pizzaessens ist die Pizzalieferung. Sie wählen Ihre Lieblingspizza aus und bekommen sie verzehrfertig geliefert. Sie müssen nur noch entscheiden, ob Sie am Tisch oder auf der Couch essen möchten und sich um die Getränke kümmern. Zudem können Sie frei über Beilagen entscheiden und zusätzliche Beläge auf die Pizza tun, die Sie in Ihrem Kühlschrank finden. - Essen gehen (Software as a Service – SaaS)
Wenn Sie auswärts essen gehen, haben Sie eine festgelegte Auswahl an Möglichkeiten, was somit SaaS entspricht. Es ist bequem und einfach, aber Ihre Optionen sind an die Möglichkeiten des Restaurants gebunden; und wenn Sie doch Appetit auf etwas anderes bekommen, müssen Sie erst das Restaurant wechseln.
About Spryker
Spryker is the leading global composable commerce platform for enterprises with sophisticated business models to enable growth, innovation, and differentiation. Designed specifically for sophisticated transactional businesses, Spryker’s easy-to-use, headless, API-first model offers a best-of-breed approach that provides businesses the flexibility to adapt, scale, and quickly go to market while facilitating faster time-to-value throughout their digital transformation journey. As a global platform leader for B2B and B2C Enterprise Marketplaces, IoT Commerce, and Unified Commerce, Spryker has empowered 150+ global enterprise customers worldwide and is trusted by brands such as ALDI, Siemens, ZF Friedrichshafen, and Ricoh. Spryker is a privately held technology company headquartered in Berlin and New York backed by world class investors such as TCV, One Peak, Project A, Cherry Ventures, and Maverick Capital. Learn more at spryker.com.