Monthly Archives: Februar 2014

Was der Kölner Dom mit einem Onlineshop zu tun hat

Kölner DomDas allererste Mal hörte ich es von einem Kollegen: Wenn der Kölner Dom je fertig ist, geht die Welt unter. Und weil das so ist (und wer könnte das Gegenteil beweisen?) wird am Kölner Dom beständig weiter gebaut – und zwar seit 1248. Und so wird seit 366 Jahren beständig erweitert, ausgebessert und verbessert.

Was das mit einem Onlineshop zu tun hat? Eine ganze Menge!

Es gibt zwei grundlegende Möglichkeiten ein Gebäude zu sanieren:

  1. – Stete Veränderungen und Verbesserungen wie neuer Anstrich, neue Elektrik oder der Anbau einer Garage
  2. – Kompletter Abriss und Neubau

In der Welt der Webentwicklung spricht man im zweiten Fall von „Re-Launch„.

Eine Gemeinsamkeit von Onlineshop und Kölner Dom ist, dass beide nie fertig sind. Kunden vermuten oft, dass eine Webseite irgendwann ja fertig ist. Und behandeln das fertige Produkt nach Auslieferung auch genau so. Ich vermute, dass dies noch ein Relikt aus einer Zeit ist, in der es vornehmlich Printmedien gab. Wenn ein Flyer oder Prospekt gedruckt ist, dann ist er halt „fertig“ und wird die nächsten Jahre so verwendet.

Onlineshops bedürfen der permanenten Verbesserung und Optimierung (und natürlich der Kontrollierung, ob die Verbesserung einen Effekt hatte). Das können auch kleinste Details sein. Gutes wird beibehalten, nicht Funktionierendes wird aussortiert. So entsteht im Laufe der Zeit ein Onlineshop, der funktioniert, ordentliche Konversionsraten hat und an den Bedürfnissen der Kunden ausgerichtet ist.

Die Natur hat es vorgemacht: Evolution nennen Biologen diese Verfahrensweise.

Dem Gegenüber steht der sog. „Re-Launch“. Da wird alles neu gemacht. Neues System oder neues Design oder, oder, oder … oder alles zusammen.

Das Relaunchen kompletter Onlineshops birgt einige Risiken. Es gibt reichlich Fälle in denen nach einem Relaunch die Umsätze in den Keller gingen. Ein Re-Launch kommt einem kompletten Gebäudeabriss und einem Neubau gleich. Und dafür muss man schon sehr, sehr gute Gründe haben.

Der E-Commerce-Primus Amazon geht da anders vor und verbessert sein System im Frontend und im Backoffice permanent. Wer will kann sich auf archive.org ja mal die schleichende Entwicklung von Amazon anschauen (ganz früher gab es da mal auch eine Telefonnummer, die man bei Bedarf anrufen konnte. Das ist – der stetigen Verbesserung sei Dank – heute nicht mehr nötig).

Die Moral: Wer einen Onlineshop von der Langlebigkeit des Kölner Doms aufbauen möchte, geht nach dem Prinzip der stetigen Verbesserung vor.

P.S. Zu diesem Thema gibt es hier auch einen lesenswerten Artikel: „From launch tunnel vision to constant change„.

Bildnachweis:
flickr.com, gudrunfromberlin, Creative Commons: BY-NC – no changes made.

Ein Beispiel, wann Content Strategy nützlich ist

sparenKürzlich war ich zur Zertifizierungsschulung bei Shopware. Dort traf ich einige Leute aus dem Agenturumfeld. In den Kaffeepausen kamen wir natürlich auch ins Gespräch. Und da erzählte ein Kollege eine schöne Geschichte von einem Projekt, das er seit 3 Jahren betreut, mit dem der Kunde aber bis zum heutigen Tag nicht online gegangen ist.

Ich stehe ja in Kontakt mit einigen Hundert Internetagenturen in Deutschland. Und natürlich unterhält man sich auch das eine oder andere Mal. Und die Geschichte, die mir der Kollege hier erzählte, gehört für mich zu den absoluten Klassikern: Alles ist fertig, der Kunde hat auch bezahlt, aber nichts geht online, weil die Inhalte noch nicht geliefert oder qualitativ einfach zu mau sind.

In diesem speziellen Fall ist es so, dass der Kunde seine Produkte nicht nur in einer Warenwirtschaft, sondern intern  in 3 verschiedenen Warenwirtschaftssystemen verwaltet. Das ist – wie dann immer so schön gesagt wird – historisch gewachsen. „Gewuchert“ ist der passendere Ausdruck. Hier ist es so, dass die gleichen Produkte in den unterschiedlichen Wawis auch noch unterschiedlich bezeichnet sind.

Für den Kollegen war es unmöglich in irgendeiner Form Daten zu importieren. Denn woher soll er importieren? Welche Bezeichnung und welche Beschreibung ist denn führend?

Wäre es eine Lösung eine übergreifende Wawi einzuführen? Bestimmt. Nur wäre dann immer noch nicht geklärt, wie die Texte aussehen sollen. Und es würde einen Haufen Geld kosten.

Dieser Zustand scheint bei Firmen ab einer gewissen Größe (und – wie ich vermute – ab einem gewissen „Alter“) häufiger vorzukommen. Ein Kollege erzählt mir mal vom Content-Chaos bei einem bekannten Deutschen Retailer. Da hatten im Laufe der Zeit unterschiedlichste Abteilungen Texte für Produkte eingegeben. Und so las sich das auch.

In diesem Fall hilft es, wenn man an diesen Content strategisch herangeht. Es gilt zu ermitteln, an wen man welche Botschaften kommunizieren will und übergreifend Vorlagen – oder Richtlinien – zu erstellen, die auch bei zukünftig einzustellenden Produkten über die Wawis hinweg gleichklingende Produktbezeichnungen erzeugen.

Bleibt dann „nur“ noch das Problem, die Daten über die Wawis hinweg synchron zu halten. Das geht zu Not aber auch manuell.

Besser ist natürlich, den Content schon von Beginn an strategisch zu planen.

Bildnachweis:
flickr.com, by SP W, Creative Commons: BY-NC-SA – no changes made

Der Bastler, oder: Informatik als Ingenieurswissenschaft

Heute ein etwas launiger Beitrag, der gar nichts mit Content zu tun hat, sondern sich mit einer in der Webentwicklung scheinbar öfter anzutreffenden Geisteshaltung befasst.

Wenn man sich schon so lange im Agenturumfeld rumtreibt wie etwa ich (was immerhin – oha – beinahe 20 Jahre sind), dann weiß man, dass es immer wieder Probleme bzw. Anforderungen von Kunden gibt, für die es schlicht keine brauchbare Standardlösungen gibt. Und jedes mal hat man dann den Stress, dem Kunden seinen Wunsch entweder auszureden oder aber mit viel Aufwand und der heißen Nadel irgendwas für den Kunden zusammenzuschustern. Und hofft dann, dass nie jemand in die Sourcen guckt.

So kamen wir eines Tages auf die Idee Reaktionssysteme mit Shopsystemen zu verbinden und dafür eine standardisierte Plug&Play-Lösung zu schaffen (ShopFusion). Wir wollten damit allen Entwicklern die Möglichkeit geben sich endlich den Schweiß von der Stirn zu  wischen und zukünftig zum Kunden sagen zu können: „Verbinden? Kein Problem, geht ganz easy! Updatesicherheit? Lieber Kunde: Na klar!“. Und fertig ist die Laube.

Nun scheint das manchen Zeitgenossen gar nicht zu gefallen. So schrieb mir einmal jemand, der ein Mailing von uns erhalten hatte:

„schon zum zweiten Mal haben Sie mir Werbung zu Ihrem Produkt „ShopFusion“ zugeschickt. Ich habe keinerlei Interesse an Ihrem Produkt. Als TYPO3- und Magento-Entwickler habe ich die Integration dieser beiden Systeme außerdem lieber selbst unter Kontrolle gehe damit individuell auf die Anforderungen unserer Kunden ein.“.

Dass jemand keinerlei Interesse an ShopFusion hat ist vollkommen in Ordnung. Und das offen kommuniziert zu bekommen finde ich sogar äußerst sympathisch.
Einen gewissen –  und mit Sicherheit berechtigten – Stolz auf die eigenen Fähigkeiten als Entwickler kann man deutlich herauslesen. Fühlte sich der oder die Angesprochene  möglicherweise gekränkt, weil wir ihm oder ihr mitteilten, dass jetzt alles ganz einfach geht? Bevor ich jetzt die Psychoanalyse gehe, widme ich mich lieber dem Grund für das Desinteresse, nämlich: Lieber selbst unter Kontrolle haben wollen.

Das fand ich dann doch erstaunlich. Und zwar aus folgendem Grund: Informatik ist – nach meinem und dem Verständnis vieler anderer auch – mittlerweile eine Ingenieursdisziplin. Und ein Ingenieur nimmt sich bestehende und funktionierende Teile und verbindet diese zu einem sinnvollen – manchmal auch vollkommen neuen – Ganzen. So kann man schnell und effizient Neues schaffen, was zudem auch noch sehr robust ist. Kürzlich sprach ich mit einem Ingenieur, der zufällig im Webumfeld gelandet war. Dieser wunderte sich nachhaltig über die „ich mache alles selbst“-Mentalität im Webentwickler-Umfeld. Als ordentlichem Ingenieur war ihm diese Denk- und Handlungsweise vollkommen fremd. Denkt man diesen Ansatz nämlich konsequent  zu Ende, kommt dabei folgendes heraus:

„Apache? Ich entwickle selber einen Server, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„Mysql? Ich entwickle selber eine Datenbank, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„PHP? Ich entwickle selber eine Skriptsprache, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„TYPO3? Ich entwickle selber ein CMS, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„Magento? Ich entwickle selber einen Shop, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„SAP R3? Ich entwickle selber ein Wawi-System, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„Schnittstellen  zur Wawi? Ich entwickle das selber, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„Bezahlsysteme? Ich entwickle selber eins, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„FLOW3? Ich entwickle selber ein Framework, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.
„JQuery? Ich entwickle selber ein JS-Framework, denn dann habe ich alles unter Kontrolle und gehe damit individuell auf die Anforderungen unserer Kunden ein“.

Na denn: Viel Spaß. Wenn man dann nach 30 Jahren alles auf dem Entwicklungs- und Leistungsstand der obigen Systeme bekommen hat, kann man ja endlich loslegen…

Wie kommt eine solche Mentalität zustande?
Zu einem Teil ist es vermutlich der Tatsache geschuldet, dass sich im Web-, besonders aber im PHP-Umfeld, immer noch viele „Script-Kiddies“ herumtreiben (was auf obige Person nicht zutrifft). Also junge, talentierte Menschen mit einem Faible für „das Programmieren“, die aber keine reguläre ingenieurswissenschaftliche Ausbildung genossen haben. Die haben einfach Bock darauf, alles selber zu machen. Häufig fehlen denen dann gerne das solide technische Handwerkszeug. Und dann kommt einer beispielsweise auf die Idee eine n:m-Relation in einer Datenbank durch kommaseparierte Listen abzubilden und diese in ein Textfeld der Datenbank zu schreiben, weil er (oder sie) sonst nicht weiß, wie die Problematik zu lösen wäre. Und Tausende von Entwicklern können zukünftig nie wieder eine ordentliche Datenbankabfrage fahren, sondern müssen die ganze Logik in ihre Applikationsschicht schieben…

Alles selber zu machen ist aber möglicherweise schlicht sehr Deutsch.

Wie sagte Jochen Malmsheimer: „Der Deutsche ist ein Bastler. Und der Schwede hat’s gemerkt!“.

Content und Commerce Digest Januar 2014

 Scroll to top