Ein Praxisbericht
Aus unserer Beratungserfahrung soll anhand eines praktischen Beispiels erläutert werden, mit welchen Herausforderungen ein Projektteam konfrontiert ist, wenn agile Methodiken auf Wasserfall-Vorgehensweisen treffen.

Ausgangslage
Im Rahmen eines größeren Softwareentwicklungsprojektes wurden fünf Scrum-Teams und zwei Teams mit Wasserfall-Vorgehensweisen eingesetzt. Eine komplette Umstellung auf eine einheitliche agile Methodik hatte sich nicht angeboten, weil die beiden Teams mit Wasserfall-Vorgehensmethodik in ihren Entwicklungen auf externe Lieferanten mit festen Releasezyklen (Basis-Standard-Softwaremodule) dieser Lieferanten basierten.

Das Gesamtprojekt hatte als Zielvorgabe einen gemeinsamen Zieltermin einzuhalten, da das Projekt einen Service für Endkunden im Massenmarkt zur Verfügung stellen sollte.

Herangehensweise
Statt komplett auf Scrum umzustellen, wurden von der Gesamtprojektleitung einzelne Scrum-Element mit bisher üblichen, eher alt bekannten Projektmanagement-Methoden nach PMI kombiniert.
Die Inhalte der Scrum-Teams wurde in einem Arbeitspaket geführt, während die beiden Teams mit Wasserfall-Vorgehensweise als getrennte Arbeitspakete behandelt wurden. Jedem Arbeitspaket wurde ein Arbeitspaket-Verantwortlicher vorangestellt, der auf die erfolgreiche Erbringung der Leistungen und Lieferungen geachtet und dem Gesamtprojektteam wöchentlich berichtet hat.

Darüber hinaus hatte das Gesamtprojektteam ein tägliches Meeting etabliert, welches an ein Daily Scrum erinnert. Hierin wurden die täglichen Aufgaben im Gesamtprojekt abgestimmt und Hindernisse besprochen – auch diejenigen der Teams mit Wasserfall-Vorgehensweise.

Um nun auch planerisch den Überblick zu behalten, wurden sogenannte Iterationen aus Gesamtprojektsicht definiert, welche festgelegte Anteile bezogen auf die Software-Komponenten, Dokumentationen usw. beinhalteten. Mit den Teams mit Wasserfall-Vorgehensweise war die Festlegung, welche Teile in den jeweiligen Iterationen bereitgestellt werden einfach. Mit den Scrum-Teams wurden die User-Stories im Refinement besprochen und nach dem Planning in die Iterationen eingeplant.
Die Scrum-Teams hatten zudem noch eine besondere Herausforderung: es sollten zusätzliche Lieferleistungen für andere Projekte bereitgestellt werden. Das Gesamtprojekt etablierte einen wöchentlichen Austausch im Rahmen des Product-Owner-Boards, welches dann flexibel Entscheidungen treffen konnte.

Nach den Iterationen wurden mit den Stakeholdern Review-Meetings durchgeführt, deren Ergebnisse in die nächste Iteration einfließen konnten. Selbstverständlich wurde auch im Gesamtprojekt vorher definiert, wann eine Iteration als abgeschlossen galt („Definition of Done“).
Sobald sich Veränderungen an den ursprünglichen Planungen ergaben, musste auch das Gesamtprojekt flexibel genug aufgestellt sein, um auf diese Änderungen einzugehen.
Dies wurde dadurch erreicht, dass das Gesamtprojekt ebenfalls tägliche Meetings zur Steuerung durchführte. Darüber hinaus war es unbedingt erforderlich, dass die Stakeholder oder der Lenkungsausschuss kurzfristig über sich ändernde Rahmenbedingungen oder Entscheidungsnotwendigkeiten informiert und einbezogen wurden. Dies verlangte auch von den Stakeholdern eine entsprechende Flexibilität und Verfügbarkeit.

Um am Ende des Projektes auch eine abschließende Sicherheit über die gesamte Funktionsfähigkeit der Software-Komponenten und des Service in Richtung Endkunde zu erhalten, wurde neben der Qualitätssicherung im Rahmen der einzelnen Arbeitspakete bzw. Teams auch ein finaler Produkttest zur Verifikation eingeführt. Dieser hatte zwar keine neuen Erkenntnisse über Fehler aufgezeigt, aber wohl Probleme in den Konfigurationen der komplexen Systeme offengelegt.

Fazit
Die Vermischung von unterschiedlichen Methodiken und Vorgehensweisen – insbesondere Agil und Wasserfall – ist unter Beachtung bestimmter Rahmenbedingungen und einem ebenfalls gemischten Vorgehen im Gesamtprojektmanagement möglich.
Wichtig ist, die Grenzen der Flexibilität bereits im Vorfeld zu kennen. Sie werden in der Regel durch die Teams oder externen Lieferanten bestimmt, die nach dem Wasserfall-Modell vorgegangen sind.

Warum sind KPIs wichtig?

Wozu dienen KPIs und was sind KPIs? Die Key Performance Indicators (KPIs) bieten eine wichtige Grundlage, um den Erfolg im Unternehmen für unterschiedliche Bereiche zu messen. Im E-Commerce helfen die KPIs eine Basis für das Bewerten des Erfolgs von Webshops zu schaffen. Ausgehend von dieser Basis können dann Maßnahmen zur Optimierung von Webshops getroffen und neue Strategien entwickelt werden.

Die richtigen KPIs sind immer abhängig von den Zielen des jeweiligen Unternehmens. Im E-Commerce können unterschiedliche KPIs für die Verbesserung eines Webshops herangezogen werden. Im Folgenden werden einige wichtige KPIs beschrieben.

Besucher
Damit überhaupt Umsatz über einen Webshop generiert werden kann, braucht es zunächst einmal Besucher, die dann im Idealfall einen Kauf tätigen. Die Besucher können Sie zum Beispiel über Social-Media-Aktivitäten oder auch durch Werbung im stationären Handel steigern. Die Zahl der Besucher wird als Traffic bewertet und sollte regelmäßig überprüft werden. Dadurch kann man herausfinden, ob Marketingaktionen dem Webshop mehr Traffic gebracht und damit zielführend waren.

Conversion Rate
Natürlich nutzt der Besuch eines Webshops dem Unternehmen nur, wenn der Besucher auch eine Aktion abgeschlossen hat. Dies wird über die Conversion-Rate gemessen. Hierbei kann es sich natürlich um eine abgeschlossene Transaktion handeln oder aber auch um die Anmeldung zu einem Newsletter oder dem Erfolg von anderen Marketingaktionen, wie z. B. das Bewerben von Artikeln durch Banner. Falls viele Besucher keine erfolgreiche Transaktion durchführen, kann dies unter Anderem darauf hinweisen, dass der Inhalt des Webshops optimiert werden sollte. Laut Statista liegt die Conversion-Rate – je nach Branche – im 1.Quartal zwischen 0,4 % bei Reisen und 10,4 % bei Apotheken (https://de.statista.com/statistik/daten/studie/677869/umfrage/conversion-rate-nach-branchen/).

Abbrüche während des Checkout-Prozesses
Viele Abbrüche während des Kaufprozesses geschehen im Checkout. Natürlich kann sich der Kunde im letzten Moment immer gegen einen Kauf entscheiden, jedoch geschieht dies häufig dadurch, dass Versandkosten im Shop nur unzureichend angegeben waren und erst im Checkout angezeigt werden. Die Abbruchrate im Checkout liegt nach einer Studie von 2017 global betrachtet bei 78,4 % ( https://blog.salecycle.com/featured/infographic-remarketing-report-q3-2017/ ). Es lohnt sich also zu überprüfen, ob die Versandkosten bereits auf der Produktdetailseite ausgewiesen werden sollten, damit die Abbruchrate im Checkoutprozess so gering wie möglich gehalten wird. Auch können fehlende Zahlungsmittel oder der Mangel von anderen Informationen Gründe für einen Abbruch sein. Um den Bestellvorgang zu optimieren, ist es sinnvoll, wenn man sich als Shopbetreiber ein Kundenkonto anlegt und den Bestellvorgang, bzw. den Kaufprozess aus Kundensicht durchläuft.

Durchschnittlicher Warenkorbwert
Wie hoch ist der Durchschnittswert der Kunden pro Einkauf? Diese Information ist neben der Anzahl der Bestellungen interessant, da auch bei einem Rückgang der Anzahl von Bestellungen der Umsatz steigen kann, wenn der Durchschnittswert des Warenkorbs steigt. Der durchschnittliche Warenkorbwert ergibt sich durch die Summe aller Umsätze geteilt durch die Anzahl der Bestellungen.

Rabattaktionen, Bundle-Angebote oder das Entfallen von Versandkosten ab einem bestimmten Bestellwert können den Kunde dazu bringen, mehrere Artikel zu kaufen und dadurch den Warenkorbwert zu vergrößern. Auch kann hierdurch überprüft werden, ob Marketingaktionen erfolgreich sind.

Anzahl der Aufrufe von Seiten und die Besuchsdauer des Webshops
Ein wichtiger Indikator für die Qualität des Inhalts von Webshops ist die Besuchsdauer der Kunden. Wenn ein Shop zwar häufig besucht wird, die Kunden diesen jedoch schnell wieder verlassen, kann das daran liegen, dass die Benutzerfreundlichkeit optimierungsbedürftig ist oder die Inhalte nicht zum Bedürfnis der Kunden passen. Wenn Artikel besonders beworben werden oder im Shop hervorgehoben werden sollen, kann die Klickrate der jeweiligen Produktseiten Aufschluss darüber geben, ob dies erfolgreich ist. Durch Nutzertests kann geprüft werden, ob Artikel gefunden werden oder vielleicht anders platziert werden müssen z. B. durch Banner, damit der Kunde diese findet und es zu einem erfolgreichen Transaktionsabschluss kommt.

Newsletter-Anmeldungen
Mithilfe eines Newsletters können die Kunden über laufende Angebote des Webshops informiert werden. Durch die Individualisierung von Inhalten des Newsletters können gezielt bestimmte Produkte beworben werden. Des Weiteren können die Inhalte auf ausgewählte Zielgruppen abgestimmt sein. Daher ist es wichtig, dass viele Kunden den Newsletter abonnieren. Anreize dazu bietet zum Beispiel ein Rabattcode für den nächsten Einkauf, den der Kunde bei Registrierung für den Newsletter erhält. Die Click-Through-Rate (CTR) gibt Auskunft darüber, ob die Artikel für den Kunden ansprechend waren und er durch den Newsletter im Shop gelandet ist. Auch ist der Newsletter ein wichtiges Werkzeug zur allgemeinen Kundenbindung und sollte deshalb nicht unterschätzt werden.

Neue Besucher vs. wiederkehrende Besucher
Es ist zwar wichtig neue Besucher zu generieren, die dann Bestellungen in dem Webshop tätigen, jedoch sollte eine langfristige Kundenbindung das Ziel eines Unternehmens, bzw. Shopbetreibers sein. Durch den konstanten Einsatz von Newslettern kann man einen wichtigen Beitrag dazu leisten, dass ein Kunde häufiger einen Webshop besucht. Auch durch Werbung im stationären Handel kann ein Kunde auf den Webshop hingewiesen werden. Durch Gewinnspiele, die auf Bestandskunden ausgerichtet sind, kann sich ein Shop von der Konkurrenz abheben und die Kundenbindung intensivieren.

Umsatz
Neben den bereits genannten KPIs wie Conversion-Rate oder wiederkehrende Besucher, ist der Umsatz natürlich ein wichtiges Erfolgskriterium. Wenn man Umsätze über einen längeren Zeitraum vergleicht, wird ersichtlich, welche Monate vielleicht generell stärker und welche schwächer sind. Hier kann zum Beispiel die Vorweihnachtszeit zu einem erheblichen Anstieg des Umsatzes führen. Auch lässt sich über den Umsatz der Erfolg von Marketingaktionen ableiten. Wenn es zum Beispiel zu einer Umgestaltung des Shops kam, kann die zu einem Umsatzverlust oder -gewinn führen. Auf der Grundlage der Umsatzzahlen können dann wieder passende Maßnahmen ergriffen werden, um den Umsatz zu steigern.

Fazit

Die hier beschriebenen KPIs wie Besucheranzahl, Umsatz oder Conversion-Rate sollten jedoch auf jeden Fall von einem Unternehmen berücksichtigt werden, da sie wichtige Indikatoren für den Erfolg von Webshops darstellen. Hierbei ist es wichtig herauszufinden, ob die Kunden zufrieden sind, der Shop eine gewisse Reichweite hat und ob sich die Marketingmaßnahmen rentieren und letztendlich zu dem gewünschten Ergebnis führen. Die Kennzahlen sollten regelmäßig überprüft und optimiert werden. Hierzu helfen Webanalysewerkzeuge und bereits integrierte Tools in Shopsystemen. Auch über KPIs hinaus ist es wichtig, dass man ein gutes Service-Management betreibt oder seinen Shop in den sozialen Medien bewirbt, damit der Webshop zu Erfolg führt.

Haben Sie noch Fragen zu KPIs im E-Commerce? Dann kontaktieren Sie uns : info@solvatis.de

Datenschutz und der Bedarf, an der Nutzung „echter“ Daten für Testzwecke

Testsysteme müssen wie ihre Live-Pendants mit Daten über Kunden und Zahlungsinformationen arbeiten können. Der Datenschutz ist dabei allerdings ein wichtiges Thema, welches auch mit der Datenschutzgrundverordnung im nächsten Jahr neue Fahrt aufnimmt. Doch natürlich ist auch schon das momentan gültige Gesetz einzuhalten – dafür soll dieser Artikel einen Einstieg bieten.

Bei Neu- und Weiterentwicklungen von Software ist es wichtig, realistische Testdaten zu haben, an denen die Use Cases / Anwendungsfälle getestet werden können. Denn wenn die Testdaten die echten Daten nicht ersetzen können, kann es zu kritischen Fehlern kommen, die erst nach der Veröffentlichung auffallen. Daher wird in vielen Fällen auch mit Echtdaten getestet.

Um dem Datenschutz gerecht zu werden, muss aber beachtet werden, dass personenbezogene Daten von echten Kunden meist nicht genutzt werden dürfen. Da die Aufnahme der personenbezogenen Daten immer zweckgebunden im Sinne des Bundesdatenschutzgesetzes (BDSG) sein soll, muss man sich die Verwendung in anderen Bereichen gut überlegen oder absichern. Einfach gesprochen: wenn Kontodaten für den Zweck der Abwicklung von Rechnungen aufgenommen wurden, dürfen sie nicht ohne Weiteres für Testzwecke von Neuentwicklungen genutzt werden.

Hierzu von den Kunden eine eigens dafür formulierte Einwilligung für alle Datensätze einzuholen, ist sehr aufwändig und muss – wie die anderen Einwilligungen zum Datenschutz auch – nachhaltig archiviert werden.

Oftmals sind die Softwareentwicklungen zusätzlich auch outgesourct, so dass hier generell über Verträge von Auftragsdatenverarbeitung (ADV) gesprochen werden müsste, die Kunden informiert werden müssten, und vieles mehr – je nach Anwendungsfall kann dies zu einem deutlichen, teureren Mehraufwand führen.

Es bleibt also, dass Testdaten keine echten Kundendaten enthalten sollten. Hier gibt es nun zwei verschiedene Ansätze, um Testdaten zu erzeugen:

Es wäre zum einen möglich, die Daten komplett künstlich zu erzeugen: aus einer Liste an gültigen Vornamen, Nachnamen und einem Pool an „formal gültigen, aber falschen“ Telefonnummern, Kontonummern etc. werden verschiedene, zufällig oder nach Regeln basierte Daten herausgezogen, und zu einem Testkunden zusammengesetzt.

Andererseits kann eventuelle eine Anonymisierung der echten Daten ein Ansatz sein. Dies bedeutet, dass die Anteile, die eine Person identifizieren können, aus den echten Daten so verändert werden, dass kein Bezug mehr zu einer echten Person mehr hergestellt werden kann.

Das künstliche Neu-erzeugen von Daten ist sicherlich sehr aufwändig, da auch die systemeigenen Regeln dabei beachtet werden müssen. IDs und Querverweise in den Datenbanken sollten gültig sein, zum Teil nur einfach vorkommen, so dass eine komplett zufällige Erzeugung innerhalb der Datenbank sehr unwahrscheinlich funktionieren wird. Es müsste also ein Tool erzeugt werden, welches die gesamte Fachlichkeit kennt und diese bei der Erzeugung der Daten beachten kann. Die Anonymisierung ist hier eine valide Alternative, da technische Bezüge im System in vielen Fällen erhalten bleiben können und man sich auf die „problematischen“ Datenfelder konzentrieren kann.

Was sind denn aber personenbezogene Daten? Gemäß §3 BDSG sind dies „Einzelangaben über persönliche oder sachliche Verhältnisse von bestimmten oder bestimmbaren natürlichen Personen.“[1] Dieses Spektrum reicht von den eindeutigen Fällen (zum Beispiel Namen, Adressen, Telefon- und Kontonummern) auch zu den Fällen, die nicht sofort ins Auge stechen: Die Seriennummer eines angemieteten WLAN-Routers wird bei einem TK-Unternehmen zu den „personenbeziehbaren“ Daten gehören und müsste eventuell ebenso anonymisiert werden. Die Kundennummer, die Vertragsnummer – alles Daten, die auch in den technischen Systemen als eindeutige Identifizierer genutzt werden können und evtl. nicht einfach ausgetauscht werden können. Hier kommt es aber immer auf den Einzelfall an, denn die Verhältnismäßigkeit des Aufwandes einer Anonymisierung ist auch ein beitragender Faktor.

Die wichtigste Eigenschaft der Anonymisierung ist, dass sie nicht rückgängig gemacht werden können soll[2] – selbst, wenn man den verwendeten Algorithmus kennt. Denn wenn jemand weiß, dass aus einem echten „Peter Müller“ immer ein „Christian Schneider“ in den Testdaten wird, hat er oder sie die Anonymisierung schon überwunden. Dem kann durch die Verwendung von zufälligen Elementen Abhilfe geschaffen werden. Sei es, dass für jede Testversion neue Testdaten erzeugt werden, oder dass die Zufallsbasis (der „Seed“) nach Verwendung verworfen wird, so dass keine Rückführbarkeit mehr möglich ist.

Egal, welchen Weg man wählt, der schmale Grat zwischen technisch händelbar und so wenig wie möglich sollte immer rechtskonform sein – hier hilft die ständige Beteiligung des eigenen oder eines externen Datenschutzbeauftragten, die Auffrischung der Datenschutzkenntnisse nach der ab Mai 2018 gültigen Datenschutz-Grundverordnung (DSGVO) sowie eine ständige Sensibilisierung der eigenen Mitarbeiter.

Bei einem unserer Kundenprojekte in einem TK-Unternehmen wurde die Anonymisierung von echten Daten gewählt, da der Datenumfang für eine künstliche Neuerzeugung zu groß war. Einerseits, da die logischen und technischen Möglichkeiten zu komplex waren, um bei einer Neuerzeugung alle Grenzfälle abzudecken – und andererseits, da die Abhängigkeiten zwischen den Daten sehr komplex waren. Beispielsweise sollte nach der Anonymisierung niemand mit einem DSL-Anschluss einen Kabelrouter im Vertrag stehen haben. Die existierenden, tausenden Testfälle sollten weiterhin durchführbar sein.

Dafür wurden bei allen betroffenen Datenfeldern aus mehreren Systemen Abwägungen gemacht, ob eine Anonymisierung rechtlich nötig und technisch umsetzbar war. Das Ziel war, insbesondere auch verzweigte Rückschlüsse zu vermeiden und den Begriff „personenbeziehbar“ sehr sehr streng auszulegen. Besondere Herausforderung hierbei waren Felder, die über die Unternehmensgrenzen hinaus Verwendung fanden, etwa Auftragsnummern bei Drittfirmen, Hardware-Seriennummern in technischen Datenbanken und Telefonnummern aus dem internen Bereich, die in Testfällen über die Systemgrenzen (wie etwa Integrationstests und fachlichen Endnutzertests) auch gültig sein sollten.

Telefon- und Adressdaten mussten „logisch schlüssig sein“ (etwa sollte eine Kölner Telefonnummer auch nach der Anonymisierung mit der Kölner Vorwahl 0221 beginnen), daher war ein einfaches Austauschen aller Zahlen oder ein reines Zufallsverfahren nicht anwendbar.

Da das jahrzehntelang gewachsene System im Hintergrund auch noch viele Redundanzen aufwies, war der Umfang des Projektes dann deutlich größer als Anfangs erwartet. Es wurden sowohl externe Tools als auch interne Lösungen für Grenzfälle verwendet.

Das größte Lob, welches nach solch einem Projekt geäußert werden kann, ist der Satz „Wir haben gar nicht gemerkt, dass sich etwas verändert hat“. Wenn im Hintergrund Adressdaten, Namen und Hardwarelisten, Vertragsnummern und vieles mehr nicht mehr echten Daten entspricht, aber das System dennoch funktioniert – dann wurde dieses Ziel erfolgreich erreicht. Im nächsten Schritt wurden die Möglichkeiten der Automatisierung so weit als möglich ausgeschöpft, da die mehrstufige Anonymisierung mehrmals pro Jahr angewendet werden muss und dabei insbesondere in der Integration in den Betrieb noch kleine Details angepasst werden müssen. Außerdem ist es natürlich notwendig, Neuentwicklungen und Änderungen der Daten mit in die Anonymisierung zu integrieren – so dass das Projekt zwar erfolgreich abgeschlossen wurde, das Thema aber intern weiter begleitet wird.

So wurden und werden nun nach Projektabschluss mehrere Millionen Kundendaten erfolgreich anonymisiert, um den Testern möglichst realistische und dennoch datenschutzrechtlich einwandfreie Testdaten zur Verfügung zu stellen.

[1] https://dejure.org/gesetze/BDSG/3.html

[2] https://www.informatik-aktuell.de/betrieb/sicherheit/testdatenmanagement-datenanonymisierung-muss-unumkehrbar-sein.html