Agile Produktentwicklung mit Running Lean am Beispiel eines cloud-basierten Foto-Editors

Transkript

1 MASTER THESIS zur Erlangung des akademischen Grades Master of Science in Engineering im Studiengang Innovations- und Technologiemanagement Agile Produktentwicklung mit Running Lean am Beispiel eines cloud-basierten Foto-Editors Ausgeführt von: DI (FH) Franz Buchinger Personenkennzeichen: Begutachter: Dipl.-Ing. Harald Swoboda, MBA 2. Begutachter: Dipl.-Ing. Andreas Hocevar Wien, Jänner 2014

2 Eidesstattliche Erklärung Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher weder in gleicher noch in ähnlicher Form einer anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Ich versichere, dass die abgegebene Version jener im Uploadtool entspricht. Ort, Datum Unterschrift

3 Kurzfassung Die Entwicklung innovativer Produkte bedeutet häufig die Umsetzung vage formulierter Bedürfnisse der Kundinnen und Kunden mit noch nicht ausgereiften Technologien. Während traditionelle, seriell ablaufende Produktentwicklungsprozesse vor dieser extremen Umgewissheit kapitulieren müssen, versprechen agile Produktentwicklungsmethoden wie Lean Startup oder Running Lean Abhilfe: durch iterative Entwicklung des Produkts und kontinuierliche Einbindung potentieller Kundinnen und Kunden in diesen Prozess wird das Innovationsrisiko minimiert. Obwohl zahlreiche Referenzen aus Startups und Innovationsabteilungen das Erfolgspotential agiler Produktentwicklungsmethoden bezeugen, ist noch wenig über ihre Anwendbarkeit neben dem Tagesgeschäft bekannt. In Bezug auf den in der Softwareindustrie verbreiteten Innovationsprozess stellt dies eine echte Wissenslücke dar, zumal hier die Entwicklung eines neuen Produktes häufig in Form von kurzzeitig anberaumten oder neben den Tagesaufgaben durchgeführten Teilzeitprojekten durchgeführt wird. Diese oft als Hackathon, Codefest, 20% Projekt oder pet project bezeichneten Explorationsprojekte konzentrieren sich auf die Umsetzung als innovativ empfundener Funktionalitäten beziehungsweise die Erstellung neuer Prototypen. Die mit echter Produktentwicklung verbundene Marktforschung und Entwicklung von Geschäftsmodellen fehlt diesen Innovationsbestrebungen, was sich negativ auf die Umsetzbarkeit ihrer Ergebnisse auswirken kann. Diese Masterarbeit untersucht die Einsetzbarkeit einer agilen Produktentwicklungsmethode in einem nebenberuflichen Innovationsprojekt mit dem Ziel der markttauglichen Qualifizierung der Produktidee. Den Hauptteil der Arbeit bildet eine Fallstudie, in welcher der Autor seine Produktidee eines cloudbasierten Foto-Editors auf Basis der agilen Produktentwicklungsmethode Running Lean über einen Zeitraum von sechs Monaten perfektionieren möchte. Die Fallstudie zeigt, dass Running Lean eine sehr effektive Methode zur Validierung und Perfektionierung von Produktideen darstellt und sich besonders für eine nebenberufliche Anwendung eignet. Klare, gut spezifizierte Prozesse erleichtern auch Produktentwicklungs- Neulingen die Anwendung und führen rasch zu Ergebnissen. Für die erfolgreiche Anwendung von Running Lean sind jedoch einige Rahmenbedingungen wie rasch verfügbare, kostengünstige Prototypen zu berücksichtigen, was die Anwendbarkeit der Methode beispielsweise bei Hardware-Projekten erschweren kann. Schlagwörter: Agile Produktentwicklung, Software, Lean Startup, Running Lean, 20% project, Customer Development, Entrepreneurship 3

4 Abstract Developing innovative products often means implementing yet-unknown customer requirements with still-evolving technologies. While traditional, sequential product development processes struggle with this high degree of uncertainty, agile product development methods such as Lean Startup or Running Lean can mitigate the risks of innovations by iterative product development and continuous customer involvement. Although a lot of success stories by full-time entrepreneurs and product development managers indicate the effectiveness of agile methods, little information on the part-time application of these methods is available. This imposes a veritable information gap, because many innovation efforts especially in the IT industry start as part-time or short-term exploration projects. These activities are often called Hackathon, Codefest, 20% project or pet project and focus on the technical implementation of new features or prototypes. Thus they lack the customer and market research activities required for true product development. This thesis examines whether holistic product development can occur in extra-occupational innovation projects in order to improve their outcome. In a case study, the agile product development method Running Lean is applied to such a scenario: While being fulltimeemployed as a software developer in a non-related field, the author tries to bring his business idea of a cloud-based online photo editor to perfection by following the Running Lean product development process for about six months. The case study shows that Running Lean is a very effective method for the perfection of business and product ideas, especially in an extra-occupational or part-time scenario. Running Lean is well-suited even for novice entrepreneurs or product development managers. Its processes are easy to follow, lightweight and quickly yield results. However, the successful application of Running Lean imposes a few conditions (e.g. continuous application period, fast prototype iteration times, low-cost production of prototypes) that might prevent its employment for the development of certain products. Keywords: Lean Startup, Running Lean, 20% project, Customer Development, Lean Canvas, Case Study 4

5 Danksagung Diese Masterarbeit hätte ohne die großartige Unterstützung zahlreicher Personen und Organisationen nicht entstehen können. Der Autor möchte sich namentlich bedanken bei der Internet Privatstiftung Austria (IPA), welche diese Arbeit im Rahmen des Internet-Innovationswettbewerbs netidee 2013 mit einem Stipendium förderte. Dipl.-Ing. Harald Swoboda, MBA für die kompetente und unkomplizierte Betreuung dieser Masterarbeit Dipl.-Ing. Andreas Hocevar vom OpenLayers-Projekt für wertvolle technische Hilfestellungen und die Zweitbegutachtung der Arbeit Lukas Fittl für die Organisation des Lean Startup Circle Vienna, aus dessen Veranstaltungen sich wichtige Anregungen für diese Masterarbeit ergaben. Mag. Bettina Riedlecker für die Durchsicht und Korrektur des Manuskriptes den interviewten Fotoschaffenden, die mir in längeren Gesprächen Rede und Antwort gestanden sind und so einen entscheidenden Beitrag zur Perfektionierung meiner Produktidee geliefert haben. Besonderer Dank gilt meiner Familie und meiner Lebensgefährtin Gabriela Lucano, die nun eineinhalb Jahre auf meine zeitintensive berufsbegleitende Weiterbildung Rücksicht nehmen mussten und dies mit sehr viel Verständnis taten. 5

6 Vorbemerkungen Diese Masterarbeit berücksichtigt die Richtlinien für gendergerechtes Wording des Corporate Wording Manuals der FH Technikum Wien in der aktuell geltenden Version 3 vom Februar Da diese Richtlinien nicht alle Formulierungsaspekte dieser Arbeit abdecken, hat der Autor folgende Ergänzungen vorgenommen: Bei den in der Arbeit enthaltenen Interview-Protokollen und Zitaten wurde von einer nachträglichen Ergänzung beider Geschlechtsformen abgesehen, um die Authenzität der getroffenen Aussagen zu bewahren. Nicht gegendert wurden weiters in der Literatur etablierte Fachbegriffe ( Kundentakt ), um einschlägig vorgebildeten LeserInnen das Verständnis zu erleichtern. Ebenso nicht gegendert wurden Bezeichnungen, die sich eindeutig auf nicht-natürliche Personen beziehen (beispielsweise Erzeuger von Digitalkameras ). Lean Canvas ist eine eingetragene Handelsmarke von Spark59 Inc. Running Lean ist eine eingetragene Handelsmarke von O Reilly Media Inc. Die in dieser Masterarbeit wiedergegebenen Gebrauchsnamen, Handelsnamen und Warenzeichen können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen. 6

7 Inhaltsverzeichnis 1 Einleitung Die Entwicklung von Running Lean Toyota Production System Entstehung Aufbau Lean Startup Startups und EntrepreneurInnen Prinzipien Praktische Umsetzung Business Model Canvas Definition des Begriffes Geschäftsmodell Bausteine eines Geschäftsmodells Running Lean Bestandteile Durchführung Running-Lean-Fallstudie Entwicklung eines cloud-basierten Foto-Editors Einleitung und Rahmenbedingungen Ausgangssituation Der Einsatz von DSLRs im Workflow des Autors Camera RAW-Formate Photosharing-Platformen zum Teilen der Bilder Problemstellung und Lösungsansatz Ein erster Lösungsansatz Überführung der Lösung in ein Produkt Problem und Kundensegmente Unique Value Proposition Solution Channels Einnahmequellen und Kostenstruktur Wichtige Kennzahlen (key metrics)

8 3.4.7 Unfairer Vorteil (unfair advantage) Der Plan A als Lean Canvas Test des Plan A Testen der Produktidee durch Problem Interviews Vorüberlegungen Aufbau und Ablauf der Problem Interviews Ergebnisse der Problem Interviews Abgleich der Kundenerwartungen mit den technischen Rahmenbedingungen Upload-Geschwindigkeit als potentieller Flaschenhals Beschleunigter Upload der RAW-Photos durch vorherige Kompression Echtzeit-Processing der RAW-Bilder am Server Analyse und Diskussion der Problem Interviews Umsetzung des Plan B Der Pivot als Ideen-Kurskorrektur Durchführung des Pivot Analyse der Produktrisikos Analyse des Akquisitionsrisikos Analyse des Marktrisikos Aktualisierung der Produktidee Solution Interviews Einsatz von Prototypen Umsetzung des Trelew-Prototyps Definition des Preismodells für Trelew Durchführung der Solution Interviews Ergebnisse der Solution Interviews Verifizierung der Exit-Kriterien Überleitung in ein MVP Minimum Viable Product Diskussion Persönliche Reflexion Positive Aspekte Herausforderungen Bewertung der Methode Running Lean Bewertung der Produktidee

9 6.4 Empfehlungen Praktischer Einsatz von Running Lean Einsatzkriterien Externe Evaluierung der Ergebnisse Ausblick Anhang Abschrift der Problem Interviews Interview mit Bernhard Anders, Konzertfotograf Interview mit Daniel Ortner, Fotografie-Dozent Interview mit Paul Meier, Event-Fotograf Interview mit David Anger, Fotograf und Dozent Interview mit Tobias Krammer, Mediengestalter und Fotograf Interview mit Thorsten Brenner, Panoramafotograf und Dozent für Mediengestaltung. 122 Abschrift der Solution Interviews Interview mit Paul Meier, Event-Fotograf Interview mit Tobias Krammer, Mediengestalter und Fotograf Interview mit Daniel Ortner, Fotografie-Dozent Interview mit Thorsten Brenner, Panoramafotograf und Dozent für Mediengestaltung. 130 Interview mit Oskar Magenschab, Fotografie-Dozent Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis

10 1 Einleitung Agil laut Duden bedeutet dieses in letzter Zeit gehäuft auftretende Modewort soviel wie von großer Beweglichkeit zeugend, regsam, wendig. Um uns der praktischen Bedeutung des Begriffs zu nähern, brauchen wir uns nicht lange mit agiler Softwareentwicklung oder agilen Innovationsprozessen beschäftigen es reicht eine kurze Rückbesinnung auf die Fußballspiele unserer Kindheit. Sich beim Dribbeln den Ball möglichst weit vorzulegen, mag anfangs als gute Idee erscheinen schließlich kann man ohne Ball schneller laufen und macht so wertvolle Meter in Richtung Tor. Für die gegnerischen Verteidiger waren solche Tempo-Dribblings aber ein gefundenes Fressen: der zu weit vorgelegte Ball konnte vom angreifenden Team nicht mehr kontrolliert und damit leicht abgefangen werden. Ballführende, die das Spielgerät stets körpernahe bewegten, waren hingegen wesentlich schwerer auszurechnen: sie konnten Haken schlagen, ihre Laufrichtung ändern oder überraschende Pässe spielen. Der Vorteil dieser wendigen, agilen Spielweise lag einerseits darin, dass der/die SpielerIn den Ball ständig unter Kontrolle hatte und so jederzeit beliebige Aktionen starten konnte. Andererseits erlaubte die körpernahe Ballführung eine Konzentration auf die Geschehnisse am Spielfield, wodurch Gelegenheiten wie Stellungsfehler der gegnerischen Mannschaft besser genutzt werden konnten. Der/die Tempo-DribblerIn hingegen musste die ganze Aufmerksamkeit auf das Erreichen des vorgelegten Balls legen - in der Umgebung lauernde Chancen und Gefahren konnte er oder sie gar nicht wahrnehmen. Oft machte daher nicht die gegnerische Verteidigung, sondern die Outlinie das mühevolle Tempo-Dribbling zunichte. Agilität spielt aber nicht nur im Sport, sondern auch bei der Entwicklung neuer Produkte eine große Rolle übersiedelt der junge Softwareentwickler Eric Ries ins kalifornische Silicon Valley, um für das Internet-Unternehmen There Inc. eine browserbasierte 3D-Welt zu entwickeln. Er und bis zu 200 weitere Entwickler arbeiten an dem Projekt, das aus Angst vor Nachahmern unter strengster Geheimhaltung und ohne Kundeneinbindung durchgeführt wird. Als das Produkt schließlich 2003 unter dem Namen there.com gelauncht wird, hat There Inc. bereits über 40 Millionen Dollar in seine Entwicklung investiert. Ein Jahr später muss das Unternehmen dichtmachen und die meisten seiner Mitarbeiter entlassen, weil sich there.com als kapitaler Flop erweist. Ries verarbeitet diese und weitere Erfahrungen als Internet-Unternehmer im 2011 veröffentlichten Buch The Lean Startup (Ries, 2012), das zum Bestseller wird. Er sieht groß aufgezogene Produkt- und Technologieentwicklungsprojekte als eine der Hauptursachen für teure Innovationsflops: sie würden häufig unter hohem Aufwand, aber zur Sicherstel- 10

11 lung von Veröffentlichungstermin und Geheimhaltung mit starrem Zeitplan und ohne Kundeneinbindung durchgeführt. Die Folge seien Produkte und Technologien, die an den Bedürfnissen der Kunden vorbeigingen, aber dennoch auf den Markt geworfen werden, in der Hoffnung, die hohen Entwicklungskosten werden doch noch eingespielt. Oft seien sich die Beteiligten schon vorab des Flops bewusst, machen aber gute Miene zum bösen Spiel, da das Innovationsprojekt vom Management als too big too fail eingestuft worden war. Die von Ries kritisierten Monster-Innovationsprojekte ähneln damit den eingangs erwähnten Tempodribblern: während diese alle Kraft aufwenden müssen, um den vorgelegten Ball noch vor den Gegenspielern zu erreichen, wird in den Projekten einem starren, oft zu ambitionierten Zeitplan hinterhergehechelt. Entwicklungen am Spielfeld, die sie in ihren Bestrebungen unterstützen oder behindern könnten, bekommen beide nicht mit. Ries Thesen fanden nicht nur in den USA, sondern weltweit regen Widerhall: nach eigenen Angaben verfügt die von ihm ins Leben gerufene Bewegung Lean Startup Circle über Mitglieder, die via Internet oder über die 130 lokalen Anwendergruppen miteinander in Kontakt stehen. Die Lean Startup Circle -Anwendergruppe in Wien konnte in den zwei Jahren ihres Bestehens 400 Mitglieder gewinnen und damit die meisten wesentlich länger etablierten Anwendergruppen aus der IT-Szene überflügeln 1. Obwohl Eric Ries Werk sich als bahnbrechend für die internationale Startup-Szene herausstellte, hatten vor allem Startup-Neulinge Schwierigkeiten, seine in der Lean Startup - Methodik zusammengefassten Empfehlungen für schlanke Innovationsprojekte praktisch umzusetzen. Ries erläutert in seinem Buch vor allem die Vision hinter Lean Startup und stellt dann die Werkzeuge der Methode in loser, anekdotenreicher Aufzählung vor. Startup- Neulingen fällt es mitunter schwer, aus diesen manchmal etwas detailarmen Schilderungen eine konkrete Schritt-für-Schritt-Anleitung für ihr eigenes Vorhaben abzuleiten. Der texanische Entrepreneur Ash Maurya erkannte dieses Problem und entwickelte mit Running Lean (Maurya, 2012) eine vielverlangte Konkretisierung von Eric Ries Methode. Wie in einem Tutorial wird der/die Neo-EntrepreneurIn durch den mehrphasigen Produktentwicklungsprozess von Running Lean geführt, der Ries Methoden zudem um den Lean Canvas erweitert. Dieser grafische Raster unterstützt den/die EntrepreneurIn bei der ganzheitlichen Erfassung und Weiterentwicklung seiner/ihrer Produktidee. Der Autor dieser Masterarbeit ist als Software-Entwickler tätig und kam vor vier Jahren zum ersten Mal mit der agilen Softwareentwicklungsmethode Scrum in Berührung, deren 1 Anzahl der Entrepreneurs auf abgerufen am

12 Fokus auf Effizienz und Zielerreichung er im Laufe der Jahre zu schätzen lernte. Nebenberuflich versuchte er sich immer wieder in der Umsetzung innovativer Software-Ideen, konnte aber aufgrund beschränkter Ressourcen und mangelnder Kundeneinbindung nur bescheidene Erfolge verbuchen. Nach intensiver Auseinandersetzung mit den Methoden Lean Startup und Running Lean reifte in ihm der Entschluss, eine der beiden Methoden im Rahmen der Masterarbeit zur Perfektionierung einer eigenen Produktidee zu verwenden. Das Rennen machte Running Lean, da es als besonders auf die Bedürfnisse von Neo-EntrepreneurInnen zugeschnittene Herangehensweise für sein Vorhaben besser geeignet erschien als der allgemeinere Ansatz von Lean Startup. Die Forschungsfrage dieser Arbeit lautet daher: Eignet sich Running Lean zur berufsbegleitenden Perfektionierung von Produktideen in Österreich? Der Terminus berufsbegleitend bezieht sich dabei einerseits auf aktuell unselbstständig Beschäftigte, die eine vorhandene Produktidee nebenberuflich perfektionieren und so ihre spätere Selbstständigkeit vorbereiten möchten. Andererseits wird auf den innerbetrieblichen Einsatz von Running Lean abgezielt: wenn beispielsweise Mitarbeiter abseits ihrer täglichen Routineaufgaben neue Produkte oder Dienstleistungen für ihr Unternehmen entwickeln möchten. Nach diesen einleitenden Worten folgt nun ein kurzes Theoriekapitel, das den Leser mit der geschichtlichen Entwicklung und den wichtigsten Begriffen rund um die behandelten Methoden Running Lean und Lean Startup vertraut macht. Danach folgt die angesprochene Fallstudie, welche sich über mehrere Kapitel erstreckt und die Entwicklung der Idee vom ersten Innovationsimpuls bis hin zur Umsetzung des ersten minimal-funktionalen Produktes beschreibt. In der abschließenden Diskussion werden die gewonnenen Erkenntnisse ausführlich analysiert und konkrete Handlungsempfehlungen abgeleitet. Wien, im Dezember 2013 Franz Buchinger 12

13 2 Die Entwicklung von Running Lean 2.1 Toyota Production System Entstehung 2 Japan, 1950: die noch junge Automobilfirma Toyota hatte gerade eine ihrer schwersten Prüfungen überstanden. Ihr Heimatland zählte zu den Verlierermächten des zweiten Weltkriegs, der mühsame Wiederaufbau und die grassierende Inflation hatten die Nachfrage nach Produkten von Toyota beinahe zum Erliegen gebracht. Das Unternehmen konnte sich zwar mühsam mit Gehaltsverzichten und Zwangspensionierungen aus der Krise retten, doch am Horizont drohnte schon das nächste Ungemach: die US-amerikanische Autoindustrie war der japanischen in Sachen Produktivität und Produktvielfalt weit überlegen und würde diese wohl früher oder später vernichten. Just in diesem Jahr beauftragte der CEO von Toyota, Eiji Toyoda, seinen Produktionsleiter Taiichi Ono mit einem ehrgeizigen Ziel: er möge die Produktivität von Toyota an jene des damals führenden Automobilkonzerns Ford angleichen, um Toyota konkurrenzfähig zu machen. Dies sollte freilich ohne Erhöhung der Produktionsmenge vonstatten gehen. Ono besuchte in der Folge mehrfach die Ford-Automobilwerke in den USA und traf dort auf die von Firmengründer Henry Ford geprägte Fließbandproduktion, bei der ein Auto am laufenden Band aus zahlreichen Einzelteilen zusammengebaut wurde. Durch standardisierte, möglichst einfache Arbeitsschritte konnten diese Tätigkeiten auch von ungelernten Arbeitskräften ausgeführt werden. Es bestand zudem eine klare Trennung zwischen den planenden IngenieurInnen und den ausführenden ArbeiterInnen. Doch Ono nahm auch bedenkliche Fehlentwicklungen in Fords Produktionssystem der 50er wahr: während Henry Ford noch den kontinuierlichen Materialfluss als überlegenes Fertigungskonzept propagierte, hatten seine Nachfolger weite Teile der Produktion auf die scheinbar ökonomischere Losfertigung umgestellt: Einzelkomponenten wie Autotüren wurden an spezialisierten Produktionsstätten in möglichst großen Stückzahlen produziert und dann lange Zeit auf Lager gelegt, bis sie schließlich beim Zusammenbau des Autos zum Einsatz kamen. Ono erkannte die Schwäche dieses Ansatzes: die Massenlosfertigung mochte zwar die Kosten pro Komponente drücken, bewirkte aber große Lagerbestände, die auch die finanziellen Ressourcen des Unternehmens banden. Außerdem wurde dadurch die bedarfsgerechte Produktion erschwert: das Unternehmen konnte nicht auf kurzfristige Markttrends reagieren (beispielsweise die vermehrte Nachfrage nach Allrad-Modellen infolge eines 2 Der Inhalt dieses Kapitels folgt der in (Liker, 2003), Teil 1, Kapitel 2 dargelegten Geschichte des Toyota Produktionssystems 13

14 besonders strengen Winters), sondern war gezwungen, die lange vorab geplanten Standardausführungen der Fahrzeuge auf den Markt bringen. Etwas weniger offensichtlich, aber umso drastischer waren die negativen Auswirkungen der Ford schen Losfertigung auf die Produktqualität: Komponenten, die nach ihrer Produktion auf Halde gelegt werden, tragen ein latent höheres Defektrisiko, als solche, die unmittelbar danach weiterverarbeitet werden. In letzterem Fall kann der/die WeiterverarbeiterIn den/die ProduzentIn der Komponente unmittelbar auf den Qualitätsmangel ansprechen (z.b. unsauber geschliffene Kanten der Autotür), während diese/r nach mehrwöchiger Lagerung auf Halde vielleicht gar nicht mehr eruierbar ist. Und selbst wenn die Eruierung erfolgreich war, so sind im verstrichenen Zeitraum möglicherweise hunderte fehlerhafte Komponenten produziert worden. Ono erkannte also in der scheinbar ökonomischen Massenlosfertigung der westlichen Automobilhersteller eine gigantische Verschwendung von Material, Arbeitszeit und finanziellen Ressourcen. Im Laufe der folgenden Jahre entwickelte er das Toyota- Produktionssystem, das eben diese erkannte Verschwendung vermeiden sollte. Durch konsequente Anwendung dieses Produktionssystems schaffte Toyota nicht nur binnen weniger Jahre den Sprung auf ein westliches Produktivitätsniveau, sondern übertraf die westlichen Hersteller derartig in puncto Preis/Leistungsverhältnis, sodass die amerikanische Automobilindustrie in den 80er Jahren in eine schwere Krise stürzte Aufbau 3 Das von Ono erdachte Produktionssystem umfasste folgende Prinzipien, die schematisch in Abbildung 1 dargestellt sind: Produktion im Kundentakt: der/die HerstellerIn sollte danach trachten, die Produktion mit dem Kundenbedarf zu synchronisieren, also nur das zu produzieren, was interne oder externe AbnehmerInnen momentan benötigten (just-in-time Produktion). Diese sollten ihm/ihr idealerweise das gerade fertiggestellte Produkt direkt vom Fließband abnehmen (pull system). Erst wenn diese absolute Taktsynchronisation aufgrund von Bestellschwankungen oder technischen Produktionsbedingungen nicht möglich ist, tritt das Kanban-System in Kraft: der/die ProduzentIn befüllt ein kleines Pufferlager mit den Produkten, aus dem der/die KonsumentIn den vorhandenen Bedarf stillt. Unterschreitet der Füllstand des Pufferlagers einen Mindeststand, wird die Produktion verständigt und beginnt mit der Nachfüllung. Ono ließ bei der Entwicklung von Kanban durch US-amerikanische Supermarktregale inspirieren, die vom Personal bei Bedarf mit neuen Produkten nachgefüllt wurden. Vermeidung von Verschwendung: Ono erkannte sieben Arten von Verschwendung in der Produktion: Materialbewegung (Transportation), zu große Lagerbestände (inventory), unnötige Bewegungen/Handgriffe der Arbeiter (motion), Warte- 3 Zusammenfassung der in (Liker, 2003), Teil 1, Kapitel 3 und 4 erläuterten Merkmale des Toyota Produktionssystems 14

15 zeiten (waiting), überflüssige Bearbeitung der Werkstücke (over-processing), Überproduktion (overproduction) sowie Korrekturen und Fehler (defects). Eine achte Verschwendungsart, das Nichtnutzen der Kreativität und des Potentials der MitarbeiterInnen, wurde später in der Literatur hinzugefügt. Methoden zur Vermeidung von Verschwendung: Durch Synchronisierung der Produktionsprozesse (wofür die bereits erwähnten Prinzipien Just-In-Time- Produktion und Kanban zum Einsatz kommen) und deren Standardisierung sollen vor allem unnötige Lagerbestände und Transporte vermieden werden. Standardisierung bedeutet bei Toyota nicht bloß die Dokumentation von Handlungsempfehlungen in Papierform: Ono legte großen Wert darauf, dass ihre Einhaltung auch beim Besuch einer Produktionsstätte sofort ersichtlich ist. Beispielsweise zeigen Umrisse an den Arbeitsplätzen, wo Werkzeuge und Material abgelegt werden sollen, um eine möglichst ergonomische Arbeitsweise zu gewährleisten. In der Just-In-Time-Produktion ist ein hohes Qualitätsbewusstsein wichtig, da defekte Teile durch den knappen Materialfluss eine Produktionslinie schnell lahmlegen können. Toyota entwickelte daher das Total-Quality-Management, das eine ständige Qualitätsprüfung und verbesserung durch alle ProduktionsmitarbeiterInnen zum Ziel hat. Um die MitarbeiterInnen nicht durch Abarbeitung langer Qualitäts-Checklisten zu überfordern, unterstützt Toyota sie durch technische Hilfsmittel: die eingesetzten Maschinen erkennen selbst, ob sie die erforderlichen Fertigungstoleranzen erbringen und halten bei Nichterfüllung an (Jidoka-Prinzip). Poka-Yoke-Einrichtungen verhindern unbeabsichtigte Fehler, indem sie diese verunmöglichen (Beispiel: durch ein asymmetrisches Profil kann ein Stecker nur auf die richtige Art eingesteckt werden). Verbesserung der Produktionsanlagen: Bei der Verbesserung der Produktionsanlagen zielt Toyota vor allem auf eine einfache und rasche Wartung ab Störungen sollten möglichst während des laufenden Betriebes durch die regulären MitarbeiterInnen selbst und nicht durch herbeigeholtes Wartungspersonal behoben werden. Ein weiteres wichtiges Ziel ist die Minimierung der Rüstzeiten: auf ein und derselben Maschine sollten viele Varianten eines Produktes erzeugt werden können, ohne dass diese dafür lange stillgelegt und umgerüstet werden muss. Kurze Rüstzeiten erlauben eine große Produktvielfalt trotz Just-In-Time-Produktion. Toyota entwickelte hierfür das SMED-Konzept: diese Abkürzung steht für Single Minute Exchange of Die und bezeichnet einen Werkzeugwechsel im Minutentakt. Qualifizierung der MitarbeiterInnen: Während der Fordismus den Einsatz unqualifizierter MitarbeiterInnen propagiert und sich dadurch eine kostengünstigere Produktion erhofft, sieht Toyota in der Qualifikation seiner MitarbeiterInnen ein wichtiges Kriterium zur Steigerung der Prozessqualität. Toyota-MitarbeiterInnen werden in eigenen Trainingszentren geschult, bevor sie im Betrieb eingesetzt werden. Sie sind auch für viele Prozessverbesserungen verantwortlich, die sie in 15

16 ihrem Arbeitsbereich erkennen und in Kaizen-Zirkeln einmelden. In diesen regelmäßigen Treffen reflektieren die WerkerInnen die Produktionsprozesse mit ihren Vorgesetzten und erarbeiten Verbesserungsvorschläge. Verbesserung in kleinen Schritten: Toyota bevorzugt kontinuierliche Prozessverbesserungen unter direkter Einbindung der Beteiligten gegenüber dem großen Wurf, also radikalen, von externen PlanerInnen über Nacht eingeführten Verfahrensinnovationen. Abbildung 1: Schematische Darstellung des Toyota-Produktionssystems nach (Liker, 2003) 2.2 Lean Startup Als sich der US-amerikanische Software-Entwickler und Internet-Unternehmer Eric Ries 2011 entschloss, seine Erfahrungen als Berater, Gründer und Mitarbeiter von Internet-Unternehmen in Form einer neuen Existenzgründungsmethode zu veröffentlichen, nannte er diese nicht von ungefähr Lean Startup. Der englische Begriff Lean (schlank) bezog sich auf das schlanke Produktionssystem von Toyota, das Ries mit einigen Modifikationen für die Entwicklung neuer Produkte beziehungsweise die Neugründung innovationslastiger Unternehmen nutzen wollte. In seiner bisherigen Tätigkeit als Internet-Unternehmer war Ries mit verschiedenen Formen der Verschwendung konfrontiert, die er durch Anwendung des Toyota-Systems eliminieren wollte: als Beispiel nennt Ries die vorzeitige Fokussierung vieler junger Internet-Unternehmen auf Wachstumsfaktoren wie die Lukrierung von Wagniskapital, die Gewinnung neuer MitarbeiterInnen oder die Entwicklung ausgefeilter Businesspläne, ohne vorher 16

17 festgestellt zu haben, ob die gewählte Geschäftsidee des Unternehmens am Markt überhaupt greift. Als Negativbeispiel führt Ries seinen früheren Arbeitgeber There Inc. an 4. Dieses Softwareunternehmen entwickelte zur Zeit des Dot-Com-Booms über vier Jahre ein 3D- Programm für virtuelle Welten im Internet. Die Entwicklung erfolgte unter strenger Geheimhaltung und ohne Einbindung von Kundinnen und Kunden, um die Imitationsgefahr durch Mitbewerber zu minimieren. Über 200 EntwicklerInnen arbeiteten an dem Projekt, 40 Millionen US-Dollar wurden investiert. Das Produkt konnte nicht am Markt Fuß fassen und There Inc musste beinahe das gesamte Personal entlassen. Schlussendlich stand das Unternehmen kurz vor der Liquidation Startups und EntrepreneurInnen Ries Lehren aus diesem Debakel: radikale Innovationen dürfen nicht in die Hände von aufgeblähten Entwicklungsabteilungen gelegt werden, sondern bedürfen der Umsetzung durch kleine, interdisziplinäre Teams, die Ries als Startups bezeichnet. Ein Startup ist eine menschliche Institution, die ein neues Produkt oder eine neue Dienstleistung in einem Umfeld extremer Ungewissheit entwickelt. [...] Unsere Definition sagt nichts über das Unternehmen, die Branche oder den Wirtschaftssektor aus. (Ries, 2012, p. 32) Demnach kann ein frisch gegründetes Zwei-Personen-Unternehmen genauso ein Startup darstellen wie ein zur Entwicklung einer Produktidee zusammengestelltes Acht-Personen- Team innerhalb eines Großkonzerns. Startups können in Unternehmen beliebiger Größe und Branche gegründet werden. Neuere Entwicklungen zeigen, dass Startups auch in nicht gewinnorientierten, gemeinnützigen Organisationen oder Behörden existieren können. Auch solche Organisationen müssen ständig neue Dienstleistungen anbieten, um ihrem Daseinszweck gerecht zu werden. Die Entwicklung neuer Produkte in einem sich rasch ändernden Marktumfeld stellt besondere Anforderungen an die MitarbeiterInnen eines Startups. Ries fordert nicht nur geeignete fachliche Qualifikation, sondern auch unternehmerisches Denken von ihnen. Der Begriff des Entrepreneurs trifft auf jeden zu, der in einem Startup arbeitet. (Ries, 2012, p. 15) 4 vgl.: 17

18 Er verwendet dafür den Begriff Entrepreneur, der vom österreichischen Ökonomen Joseph Schumpeter für UnternehmerInnen geprägt wurde, die ihre wirtschaftliche Position durch Hervorbringen von Innovationen verbessern wollen 5. Schumpeter unterscheidet diese von Kapitalisten, die ihre Profite durch kostenpflichtige Bereitstellung von Kapital machen (siehe Abbildung 2) Prinzipien Abbildung 2: Die Rolle von Entrepreneuren im Wirtschaftssystem nach Schumpeter (Brown & Ulijn, 2004, p. 106) Ries definiert folgende fünf Grundprinzipien für die Lean-Startup-Methode: 1. EntrepreneurInnen sind überall: Wie im vorangegangenen Abschnitt erläutert, beschränken sich Startups nicht auf bestimmte Wirtschaftszweige (z.b. Internet- Unternehmen) oder Unternehmensarten. Jede Organisation oder jedes Individuum kann zur Entwicklung neuer Produkte oder Dienstleistungen ein Startup ins Leben rufen. 2. Entrepreneurship ist Management: Die Fähigkeiten der EntrepreneurInnen dürfen sich nicht auf die Produktentwicklung allein beschränken, sondern müssen Managementkompetenzen wie die Führung der MitarbeiterInnen umfassen. Dabei ist das äußerst dynamische und fragile Umfeld des Startups zu berücksichtigen. 3. Validierte Lernprozesse sind der Daseinszweck des Startups: Startups werden gegründet, um tragfähige Geschäftsmodelle für neue Produkte, Dienstleistungen oder Märkte zu entwickeln, über die noch kein oder wenig Wissen vorhanden ist. Daher ist der primäre Zweck eines Startups, sich dieses Wissen über eigene Experimente anzueignen. In diesen werden einzelne Annahmen der Produktidee bzw. unternehmerischen Vision auf ihre Gültigkeit geprüft. 5 vgl. (Schumpeter, 1926) 18

19 4. Bauen-Messen-Lernen: Jedes Startup-Experiment läuft nach der Bauen-Messen- Lernen-Feedbackschleife (siehe Abbildung 3) ab, d.h. zuerst wird mit möglichst minimalem Aufwand ein Versuchsobjekt gebaut (z.b. Prototyp zur Demonstration einer Produktfunktion), dann die Reaktion der Kundinnen und Kunden darauf gemessen und schließlich die richtigen Lehren daraus gezogen (z.b. Weiterverfolgung oder Änderung der Ideenhypothese) 5. Innovationsbilanz: Der Lern- und Innovationsfortschritt eines Startups muss ständig gemessen und hinterfragt werden. Durch Definition von Meilensteinen und Einführung von Kennzahlen soll für jede/n Startup-MitarbeiterIn und auch die externen InteressensvertreterInnen ersichtlich sein, wie es um die Zielerfüllung des Startups steht. Das Erstellen der Innovationsbilanz ist aber nicht alleinige Aufgabe des Managements, jede/r MitarbeiterIn soll durch Dokumentation von Experimenten etc. seinen Beitrag dazu leisten. (Ries, 2012, p. 15f) Abbildung 3: Die Bauen-Messen-Lernen Feedbackschleife nach Ries (Ries, 2012, p. 73) Praktische Umsetzung Wesentliches Element der Lean Startup -Methodik ist die schlanke Durchführung des Innovationsprojektes, wofür Ries Anleihen beim vom japanischen Automobilhersteller Toyota geprägten Lean Management nimmt. 19

20 Lean Startup minimiert Verschwendung und damit verbundenen finanziellen Aufwand durch eine Fülle von Aktivitäten: Potentielle Kunden und Kundinnen werden bereits am Beginn des Innovationsprozesses identifiziert und in diesen eingebunden. Dadurch erübrigen sich teure Marktforschungsaktivitäten, die Gefahr unvorhersehbarer Flops sinkt. Die Geschäftsidee des Startups wird als Bündel von Hypothesen betrachtet, die in Experimenten bestätigt werden müssen, bevor tatsächlich Geld in großem Stil in sie investiert wird. Da gröbere Änderungen an der Geschäftsidee in dieser Phase durchaus wahrscheinlich sind, definiert Lean Startup mit dem sogenannten Pivot einen eigenen strukturierten Umdenkprozess für derartige Fälle. Neben qualitativen, offenen Kundeninterviews stellt das minimal-funktionale Produkt (minimum viable product) das wichtigste Experimentierobjekt dar: mit möglichst geringem Aufwand wird frühzeitig ein minimales Produkt umgesetzt, das den/die zentralen Aspekte der Produktidee demonstriert und von Interessierten ausprobiert werden kann. Das minimum viable product wird kontinuierlich, aber defensiv mit weiteren Funktionen ergänzt. Entscheidend ist nicht die Anzahl oder Originalität der Funktionen, sondern einzig und allein ihre Akzeptanz durch den Kunden/die Kundin. Erst wenn sich eine klare Übereinstimmung des entstehenden Produktes mit den Bedürfnissen der Kunden abzeichnet (product/market-fit), kann das Startup die Wachstumsphase einläuten und sich mit Kapital und Personal ausstatten, um dieses Wachstum zu bewältigen. 2.3 Business Model Canvas Während die Lean-Startup-Methode den Weg einer Produktidee über ihre Umsetzung bis hin zur Marktakzeptanz begleitet, bleibt für viele EntrepreneurInnen die Frage offen, welches Geschäftsmodell sie für ihr Produkt wählen sollen, sobald dieses am Markt greift. Heutzutage werden Produkte mit einer Vielzahl von Geschäftsmodellen angeboten, die von werbefinanzierten Gratis-Angeboten (U-Bahn-Zeitung) über kostenlose Basisversionen mit kostenpflichtigen Premium-Funktionen (dieses Freemium-Modell wird gerne von Online-Diensten wie Google und Flickr verwendet) bis hin zu echten Bezahlangeboten reicht. Die Motivation hinter der Wahl eines Geschäftsmodells ist dabei für Neo-EntrepreneuerInnen nicht immer ersichtlich. Der Internet-Unternehmer Alex Osterwalder hat mit dem Wirtschaftsprofessor Yves Pigneur daher den Business Model Canvas entwickelt. Mit diesem einseitigen Darstellungraster lassen sich Geschäftsmodelle anschaulich in ihre Komponenten aufspalten und so analysieren, verbessern oder neu entwickeln. 20

21 Da der Business Model Canvas in abgewandelter Form auch in der Running-Lean- Methode zum Einsatz kommt, soll nachfolgend kurz auf ihn eingegangen werden Definition des Begriffes Geschäftsmodell Zunächst gilt es, die Bedeutung des Begriffes Geschäftsmodell näher zu erklären. Er wird von Osterwalder und Pigneur wie folgt definiert: Ein Geschäftsmodell beschreibt das Grundprinzip, nach dem eine Organisation Werte schafft, vermittelt und erfasst. (Osterwalder & Pigneur, 2011, p. 18) Die Autoren reduzieren also das Geschäftsmodell nicht auf die landläufig verbreitete Definition womit das Unternehmen Geld verdient, für sie umfasst es auch die Entwicklung jener Wertangebote, welche die späteren Einnahmen generieren oder die Akquisition der Kunden und Kundinnen, die diese Zahlungen leisten Bausteine eines Geschäftsmodells Abbildung 4: Der Business Model Canvas nach Pigneur und Osterwalder (Osterwalder & Pigneur, 2011, p. 48) Aus der obigen Definition leiten Pigneur und Osterwalder neun Bausteine eines Geschäftsmodells ab, die im Business Model Canvas grafisch dargestellt werden (siehe 21

22 Abbildung 4). Pigneur und Osterwalder präzisieren die Bausteine wie folgt (Osterwalder & Pigneur, 2011, p. 25 ff): Kundensegmente (customer segments): Eine Organisation bedient ein oder mehrere Kundensegmente (der IT-Konzern Hewlett-Packard wendet sich mit seinen Produkten beispielsweise an private Endkundinnen und -kunden, klein- und mittelständische Unternehmen sowie große Konzerne, die Art und Aufmachung der Produkte unterscheidet sich je Kundensegment). Wertangebote (value proposition): mit ihren Wertangeboten versucht die Organisation, Kundenprobleme zu lösen und Kundenbedürfnisse zu befriedigen. Ein Wertangebot kann aus Produkten, Dienstleistungen oder einer Kombination dieser beiden Faktoren bestehen. Kanäle (channels): Wertangebote werden den Kundinnen und Kunden durch Kommunikations-, Distributions-, und Verkaufskanäle unterbreitet. Eine Organisation kann direkte (eigene Website, Filialen) oder indirekte Kanäle (Vertriebspartner, Händlernetz) zur Vermittlung der Wertangebote nutzen. Kundenbeziehungen (customer relationships): zu jedem Kundensegment muss die Organisation Beziehungen herstellen und pflegen. Je nach Geschäftsmodell geschieht dies über die Verkaufsberater (z.b. Autohandel) oder über Selbstbedienungs-Terminals (z.b. Fahrkartenautomaten) Einnahmequellen (revenue streams): sind das Ergebnis der Konsumation von Wertangeboten. Je nach Geschäftsmodell kann es sich bei den Einnahmequellen um einmalige oder fortlaufende Zahlungen handeln. Schlüsselressourcen (key ressources): sind Güter, die zum Anbieten der Wertangebote oder für die Nutzung der Kundenkanäle erforderlich sind. Schlüsselressourcen können physische (Rohstoffe, Fabrik, Computernetzwerk,...), immaterielle (Patente, Markenrechte), menschliche (Schlüsselarbeitskräfte,...) oder finanzielle (Kredite, Bürgschaften,... ) Ausformungen haben. Schlüsselaktivitäten (key activities): damit die Schlüsselressourcen ihren Nutzen entfalten können, müssen sie in Aktivitäten zum Einsatz gebracht werden (beispielsweise Produktion, Innovation, Vertrieb). Diese bezeichnen Osterwalder und Pigneur als Schlüsselaktivitäten. Schlüsselpartnerschaften (key partnerships): nicht alle erforderlichen Ressourcen und Aktivitäten können vom Unternehmen selbst bereitgestellt werden, es muss Partnerschaften mit anderen Organisationen eingehen, um an sie zu kommen. Schlüsselpartnerschaften können aber auch zwischen konkurrierenden Unternehmen eingegangen werden, um wichtige Technologien zu standardisieren und zu vermarkten (z.b. Blu-Ray-DVDs) oder finanzielle Vorteile durch Einkaufsgemeinschaften zu lukrieren. Kostenstruktur (cost structure): Die Elemente des Geschäftsmodells verursachen Kosten, welche in einer Kostenstruktur zusammengefasst werden. 22

23 Osterwalder und Pigneur unterscheiden hierbei zwischen kostenorientierten Unternehmen, welche die Preisführerschaft in ihrem Marktsegment anstreben wollen und wertorientierten Firmen, die aufwendige, qualitativ hochwertige Produkte ohne übertriebenen Kostendruck anbieten möchten. 2.4 Running Lean Der texanische Entrepreneur Ash Maurya hatte bereits eine zehnjährige Historie als Internet-Unternehmer hinter sich, als er 2012 seine Startup-Methode Running Lean veröffentlichte. Wie der Titel bereits vermuten lässt, baut Maurya auf dem Werk von Eric Ries auf. In der Tat entstand Running Lean, als Maurya versuchte, die von Ries in Lean Startup vorgeschlagenen Techniken zur Entwicklung seines neuen Produkts Cloud Fire anzuwenden: I was determined to test these techniques on my next product (CloudFire) but ran into many early challenges when trying to take these concepts to practice. [...] while Eric Ries was sharing his retrospective lessons learned from working at IMVU, IMVU was no longer a startup. With a technical staff of 40 people and more than $40 million in revenue, what you saw was a fully realized Lean Startup machine, which was at times daunting. (Maurya, 2012, p. 33) Maurya hatte also Probleme, die von Ries innerhalb des mittelständischen, etablierten Softwareunternehmens IMVU entwickelten Startup-Techniken auf sein Ein-Mann-Startup zu übertragen und folgerte daraus, dass die von Ries für einen sehr weiten Anwenderkreis gedachten Methoden für die Bedürfnisse von Klein- und Kleinstunternehmen konkretisiert werden müssen. Mit Running Lean schuf Maurya ein Startup-Tutorial, das den/die Neo-EntrepreneurIn Schritt für Schritt durch die Verfolgung seiner Geschäftsidee begleitet und ihn dabei mit klar vorgegebenen und ins Detail definierten Prozessen unterstützt. Besonderes Augenmerk richtet Maurya auf die zahlreichen Richtungswechsel der Geschäftsidee, die ein Startup im Laufe der Zeit vollführen muss, um am Leben zu bleiben: Most startups still fail. But the more interesting fact is that, of those startups that succeed, two-thirds report having drastically changed their plans along the way 6. (Maurya, 2012, p. 24) 6 Maurya bezieht sich bei dieser Aussage auf in (Mullins & Komisar, 2009, p. vii) veröffentlichte Daten. 23

24 Er folgert daraus, dass es einen systematischen Prozess benötigt, um die meist wirkungslose Ursprungsgeschäftsidee in Richtung eines funktionierenden Geschäftsmodells zu treiben: Running Lean is a systematic process for iterating from Plan A to a plan that works, before running out of ressources. (Maurya, 2012, p. 25) Bestandteile Für Running Lean griff Ash Maurya nicht nur auf die Erkenntnisse von Eric Ries The Lean Startup zurück, er verwendete ergänzende Techniken, um die Methode abzurunden: Die vom US-Wirtschaftsprofessor und Internet-Unternehmer Steve Blank geprägte Methode Customer Development bezeichnet ein frühzeitiges Indentifizieren potentieller Kundinnen und Kunden am Beginn des Produktentwicklungsprozesses und deren kontinuierliche Involvierung in diesem Prozess über Feedback-Schleifen [vgl. (Blank, 2013)] Lean Startup: Aus der Lean-Startup-Methode übernahm Maurya die Prämisse eines Startups das Maximieren des Wissens über Kundenbedürfnisse und Marktgegebenheiten in möglichst kurzer Zeit durch validiertes Lernen sowie Elemente wie die Bauen-Messen-Lernen-Feedbackschleife und den Pivot-Prozess. Bootstrapping ist eine Technik zur Minimierung des externen Kapitalbedarfs für Produktentwicklung und/oder Existenzgründung und stellt die Antithese zur wagniskapitalhungrigen Finanzierung US-amerikanischer Internet-Unternehmen dar. Der Begriff leitet sich aus der englischen Redewendung "to pull oneself up by one's bootstraps" ab (ungefähre deutsche Übersetzung: sich am eigenen Schopf aus dem Sumpf ziehen ). Ziel der Methode ist eine einfache, rasche Unternehmensgründung sowie die weitgehende Bewahrung der unternehmerischen Souveränität durch Verzicht auf Fremdkapital. [vgl. (Gianforte & Gibson, 2007)] Business Model Canvas: Zur permanenten Visualisierung der Geschäftsidee kommt in Running Lean der Lean Canvas, eine abgewandelte Version des von Osterwalder/Pigneur erdachten Business Model Canvas zum Einsatz Durchführung Maurya gliedert Running Lean in drei Grundschritte, welche im Lauf der Anwendung von Lean Canvas wiederholt durchlaufen werden. Nachfolgend werden diese Schritte überblicksmässig beschrieben, eine detaillierte Beschreibung erfolgt im Rahmen der nachfolgenden Fallstudie [vgl. (Maurya, 2012, p. 43ff)]. 24

25 1. Dokumentation des Plan A auf dem Lean Canvas: Der/die EntrepreneurIn dokumentiert die Ausgangsidee auf dem einseitigen Lean-Canvas-Raster, der von Running Lean bereitgestellt wird. Neun vorgegebene Aspekte zwingen zu einer ganzheitlichen, auf ein vollwertiges Geschäftsmodell abzielenden Dokumentation der Geschäftsidee, der limitierte Platz sorgt für eine schlanke Erfassung der zugrunde liegendenen Hypothesen. Running Lean gibt auch die Reihenfolge der Befüllung vor: erst nach der Dokumentation des Problems aus Zielgruppensicht darf der (technische) Lösungsansatz ausgeführt werden. Ash Maurya drückt die Ansprüche von Running Lean wie folgt aus: Your job isn t just building the best solution, but owning the entire business model and making all the pieces fit. [..] Lean Canvas helps deconstruct your business model into nine distinct subparts that are then systematically tested, in order of highest to lowest risk. (Maurya, 2012, p. 43) 2. Identifikation der riskantesten Teile des Plans: Im zweiten Schritt gilt es die riskantesten Teile des in Schritt 1 erstellten Plan A zu identifizieren. Running Lean unterstützt den/die EntrepreneurIn dabei mit einem phasenabhängigen Risikobeurteiltungsmodell, das auf den aktuellen Produktentwicklungsfortschritt des Startups abstellt: o Am Beginn seiner Existenz muss das Startup danach streben, den sogenannten Problem/Solution-Fit zu erreichen das vom Startup angegangene Problem muss von den potentiellen Kunden und Kundinnen als so dringlich eingestuft werden, dass sie bereit wären, das Produkt oder die Dienstleistung des Startups zu nutzen. Die Frage Verfolge ich ein lösenswertes Problem? stellt also das Hauptrisiko in der Frühphase des Startups dar. Running Lean verwendet qualitative Befragungstechniken wie problem/solution interviews, um dieses Risiko aufzuklären. o Als nächstes Ziel sollte der Product/Market-Fit angestrebt werden dabei stellt sich die Frage, ob die in ein meist kostenpflichtiges Produkt paketierte Problemlösung auch vom Markt akzeptiert wird. Zur Aufklärung dieses Produktrisikos verwendet Maurya das aus Lean Startup bekannte minimum viable product, welches in Beta-Tests frühen Anwendern zur Verfügung gestellt wird. o Wenn die Markttauglichkeit des Produktes durch die Frühanwendergruppe bestätigt wurde und diese möglicherweise schon kleine Umsätze generiert, stellt sich die Frage nach dem Wachstum des Startups: Mit welchen Mitteln kann das Startup mehr Kundinnen und Kunden generieren? Hierfür werden neue Marketingkanäle getestet (z.b. Online-Anzeigen) und in ihrer Wirkung optimiert (beispielsweise durch verbesserte Textierung) 3. Durch Experimente werden die riskantesten Planelemente systematisch getestet und verbessert. 25

26 3 Running-Lean-Fallstudie Entwicklung eines cloud-basierten Foto-Editors 3.1 Einleitung und Rahmenbedingungen Die Forschungsfrage dieser Arbeit lautet: Eignet sich Running Lean zur berufsbegleitenden 7 Perfektionierung von Produktideen in Österreich? Zur Beantwortung dieser Frage testet der Autor im Rahmen einer Einzelfallstudie die berufsbegleitende Anwendung von Running Lean: neben seiner Vollzeitbeschäftigung als Software-Entwickler wendet er die Methode über einen Zeitraum von sechs Monaten an, um seine Idee eines cloud-gestützten Speicherdienstes für digitale Negative weiter zu perfektionieren auf die technischen Einzelheiten der Produktidee wird im Verlauf der Fallstudie noch detailliert eingegangen. Der Anwendungszeitraum von sechs Monaten ergab sich aus dem studienbedingten frühestmöglichen Starttermin der Arbeit (Juli 2013) und dem ebenfalls von der Studiengangsleitung definierten Abgabetermin per , von dem für diverse Finalisierungsarbeiten an der Masterarbeit ein Monat abgezogen wurde. Weitere wichtige Rahmenbedingungen sind die Beschränkung auf die genannte Produktidee aus dem Bereich digitale Medientechnologien, die gleichzeitige Evaluierung mehrerer Ideen oder die Ausdehnung der Idee auf andere Fachbereiche stellen aufgrund des knappen Zeitbudgets klare Nicht-Ziele dar. Aus finanzieller Sicht erfolgt eine Beschränkung der möglichen Ausgaben auf maximal 1000 EUR pro Monat, die aus dem Privatvermögen des Autors bestritten würden. Der beabsichtigten Gewinnung institutioneller Geldgeber zur Finanzierung der Produktidee wird aufgrund der Empfehlungen von Running Lean 8 ebenfalls nicht nachgegangen. Eine Ausnahme bildet das von der Internet-Förderaktion netidee dankenswerterweise gewährte Förderstipendium zur Fertigstellung dieser Masterarbeit. Erhofftes Ergebnis der Anwendung von Running Lean ist zum einen die Konkretisierung der Produktidee des Autors in technischer (welche Technologien sind zur Umsetzung des Produktes nötig?) und funktioneller (welche Funktionen erwartet der Kunde oder die Kundin?) Hinsicht. Zum anderen sollten die Erfahrungen aus der Fallstudie natürlich der Beantwortung der Forschungsfrage dienen: ergibt sich weiters eine gute Eignung von Running Lean für die betriebliche und private Produktentwicklung, möchte der Autor 7 8 Wie in der Einleitung bereits erläutert, bezieht sich berufsbegleitend entweder auf die innerbetriebliche Anwendung von Running Lean (zusätzlich zu den eigentlichen Kernaufgaben der betroffenen Beschäftigten) oder auf den nebenberuflichen Einsatz. Externes Investitionskapital zählt nach Running-Lean-Ansicht zu den Wachstumsfaktoren eines Startups. Es sollte daher erst nach Erzielung des product/market fit akquiriert werden [vgl (Maurya, 2012, p. 46)]. 26

27 mithilfe von Anwendungsempfehlungen den Einsatz der Methode in diesen Bereichen erleichtern. Aufgrund des offenen Ausgangs der Fallstudie stellt die Kommerzialisierung der Produktidee durch ein vom Autor gegründetes Unternehmen kein definitives Ziel der Arbeit dar. Diese Aktivitäten würden zudem auch den zeitlichen Rahmen der Masterarbeit sprengen, sollen aber bei erfolgreicher Umsetzung der Idee nach Erstellung der Masterarbeit durchgeführt werden. 3.2 Ausgangssituation Der Autor dieser Masterarbeit ist ein leidenschaftlicher Hobby-Fotograf, der seine auf Reisen oder Veranstaltungen geschossenen Fotos gerne mit seinem Familien- und Freundeskreis teilt. Dafür verwendet er das kostenlose Desktop-Programm Google Picasa, mit dem die Fotos gesichtet und bearbeitet werden. Die integrierte Upload-Funktion von Google Picasa publiziert anschließend eine Auswahl gelungener Bilder auf dem sozialen Netzwerk Google+. Die jeweilige Zielgruppe der Fotos erfährt durch die Benachrichtigungsfunktion von Google+ vom neuen Bilderangebot und kann dieses unter einem veröffentlichten Hyperlink abrufen Der Einsatz von DSLRs im Workflow des Autors Abbildung 5: Modell "EOS 5D Mark II" von Canon 9 Die Fotos selbst werden mit einer digitalen Spiegelreflex-Kamera (digital single lens reflex camera, DSLR) geschossen. Abbildung 5 zeigt eines der aktuell populärsten Modelle die- 9 Quelle: unmodifiziertes Originalbild von Charles Lanteigne, das unter der creative-commons-lizenz CC BY-SA 3.0 veröffentlicht wurde (Bild und Lizenzbestimmungen: 27

28 ser Produktgattung 10, die EOS 5D Mark II der Firma Canon. Digitale Spiegelreflexkameras bieten gegenüber Kompakt- oder Smartphone-Kameras folgende Vorteile: durch einen größeren Bildsensor kommt es zu weniger Rauschen und einer höheren Bilddynamik (Bockaert, 2009). Ein klappbarer Spiegel leitet das im Objektiv eintreffende Licht durch den Sucher oder während des Auslösevorgangs auf den Bildsensor (Abbildung 6). Kompaktkameras hingegen verfügen über keinen Klappspiegel, sondern zwei getrennte Linsensysteme für Sucher und Aufnahme. Bei ihnen ist der Tausch des Objektives nicht möglich, während bei Spiegelreflexkameras wechselbare Objektive eine flexible Bildgestaltung ermöglichen (Abbildung 7) ein herstellerspezifisches Rohdatenformat (RAW-Format) bietet durch verlustfreie Speicherung der Bildsensordaten eine deutlich höhere Bildqualität als das in Kompakt- und Smartphonekameras verbreitete, verlustbehaftete JPEG-Format (Fraser, 2004). Abbildung 6: Lichtwege bei DSLRs (Gockel, 2011, p. 28) 10 Quelle: Flickr.com Kamerastatistik, September

29 Abbildung 7: DSLR-Modell Sony A230 mit Wechselobjektiven und weiterem Zubehör Camera RAW-Formate Aufbau und Bedeutung Der Terminus Camera RAW-Format bezeichnet eine Familie von unterschiedlich aufgebauten Dateiformaten, die von den Herstellern digitaler Spiegelreflexkameras entwickelt wurden. Es gibt dutzende verschiedene RAW-Formate, die aber einen gemeinsamen Zweck verfolgen: die beim Fotografiervorgang vom Bildsensor ermittelten Helligkeitswerte möglichst unverfälscht zu speichern. [vgl. (Fraser, 2004)] Damit liefert die RAW-Datei ähnlich einem analogen Negativ die Ausgangsdaten eines Fotos, aus denen aber erst durch mehrere Entwicklungsschritte ein fertiger Fotoabzug wird. 11 Quelle: unmodifiziertes Originalbild von Brian Eager, das unter der creative-commons-lizenz CC BY 2.0 veröffentlicht wurde (Bild und Lizenztext: 29

30 Abbildung 8: Interpolation von Farbwerten im Raw-Konverter (Fraser, 2004) Diese Entwicklungsschritte übernimmt der Raw Converter, eine Softwarekomponente, die in viele moderne Bildbearbeitungsprogramme integriert ist. Der Entwicklungsprozess ist allerdings interaktiv, der Benutzer kann durch Einstellungsänderungen eingreifen. Abbildung 9: Der in die Bildverwaltungssoftware Adobe Lightroom integrierte Camera RAW Konverter 30

31 Der Raw Converter durchläuft beim Entwicklungsprozess eines Raw-Bildes folgende Arbeitsschritte (Fraser, 2004): 1. Demosaicing: Die meisten Digitalkameras verfügen über einen Color Filter Array (CFA)-Bildsensor, der 1975 vom Kodak-Ingenieur Bryce Bayer patentiert wurde (Bayer, 1975). Bei diesem Sensortyp wird der farbenblinde, d.h. nur auf Helligkeitsunterschiede reagierende Bildsensor durch Aufbringen von Filterfolien für die RGB-Grundfarben Rot, Grün und Blau empfindlich gemacht. Jeder Sensorpixel liefert dabei entweder einen Rot-, Grün- oder Blauwert. Da für die Farbdarstellung eines Bildes alle drei Farbwerte je Pixel vorliegen müssen, ist ein Interpolationsvorgang zwischen den Farbwerten erforderlich, der als Demosaicing bezeichnet wird (siehe Abbildung 8). Es existieren verschiedene Demosaicing-Algorithmen, die Vor- und Nachteile haben. 2. Korrektur von Abbildungsfehlern: Die bei der Aufnahme eingesetzten Objektive sind nicht frei von Abbildungsfehlern, wie beispielsweise Abschattungen an den Objektivrändern (Vignettierung). Durch Einsatz entsprechender Filter kann der RAW-Konverter diese Fehler beseitigen oder abmildern. 3. Weißabgleich: Beim Weißabgleich werden die neutralen Bildpixel bestimmt, die keine Farbinformation enthalten, also weiß, grau oder schwarz sind. Durch dieses Neutralsetzen einzelner Pixel ändert sich die Farbcharakteristik des Bildes. 4. Gammakorrektur: bei der Gammakorrektur wird eine physikalisch proportional wachsende Größe mit einer Potenzfunktion korrigiert, weil sie dem menschlichen Empfinden nach nicht proportional wächst. Bei der digitalen Fotografie betrifft dies die vom Sensor gemessenen Tonwerte die Kontrastunterschiede der Werte wären bei linearer Umrechnung für das menschliche Auge zu niedrig. Die Gammakorrektur sorgt für die nötige Anpassung der Werte. 5. Rauschunterdrückung, Antialiasing und Schärfen: Diese Korrekturfilter dienen der Minderung des unvermeidbaren Sensorrauschens bzw. der Vermeidung von Moiré-Effekten bei der Abbildung klein strukturierter Muster. Der Schärfe-Filter wirkt dem durch das Demosaicing bewirkten Schärfeverlust entgegen. Durch Beeinflussung dieser RAW-Entwicklungsparameter kann der/die FotografIn Bilder unterschiedlichster Charakteristik entwickeln. Diese Flexibilität hat jedoch ihren Preis: für ein RAW-Foto sind je nach Kamera-Modell, Bildauflösung und Dateiformat zwischen 10 und 45 Megabyte Speicherplatz zu veranschlagen 12, die Umrechnung des Graustufen- Negativs in ein Farbbild ist zudem ein sehr leistungsintensiver Rechenvorgang (vgl. die Performance-Tests für Camera-RAW-Decoding in Kapitel 4.2.3). 12 Bandbreite des Speicherbedarfs der RAW-Testbilder in (Busch, 2013) 31

32 Unterschiede zum JPEG-Format Das von digitalen Kompakt- und Smartphone-Kameras produzierte JPEG-Format entspricht einem analogen Farbabzug: binnen Sekundenbruchteilen wird die vom Bildsensor wahrgenommene Helligkeitsinformation an einen Bildprozessor umgeleitet, der daraus unter Anwendung der im vorigen Abschnitt genannten Entwicklungsschritte ein Farbbild erstellt. Da dieser Prozess in Sekundenbruchteilen in der Kamera stattfinden muss, hat der/die FotografIn nur wenige Eingriffsmöglichkeiten. Um Speicherplatz zu sparen, wird dieses sogleich in ein JPEG-Bild konvertiert. Bei diesem verlustbehafteten, in (ITU Consultative Comitee, 1993) standardisierten Kompressionsverfahren wird das Foto in 8x8 Pixel große Quadrate unterteilt, innerhalb dieser werden durch Irrelevanzreduktion für den Menschen schlecht wahrnehmbare Kontrastunterschiede entfernt. JPEG ermöglicht Kompressionsraten von 1:10 1:15 für visuell verlustfreie Bilder (d.h. auch geübten BetrachterInnen wird kein Qualitätsunterschied auffallen). Abbildung 10 zeigt die Auswirkungen der JPEG-Kompression das linke Beispielbild wurde mit JPEG-Qualitätseinstellung 90 gespeichert rechts kam die Einstellung 12 zum Einsatz 13. Dabei werden die durch die Kompression verursachten Blockartefakte und der Verlust an Schärfe sichtbar. Bei der nachträglichen Bearbeitung treten diese Artefakte auch bei guten Qualitätsstufen schnell zutage ( Treppchen -Effekt). Abbildung 10: Visuelle Artefakte bei der verlustbehafteten JPEG-Kompression Das Vergleichsbild wurde mit dem JPEG-Enkoder des Bildbearbeitungsprogramms Paint.NET Version erstellt, die möglichen Qualitätswerte reichen von 1 (schlechteste Qualität, geringste Dateigröße) bis 100 (maximale Qualität und Dateigröße). 14 Quelle: modifiziertes Foto von Richard Bartz, das unter der creative-commons-lizenz CC BY-SA 2.5 veröffentlicht wurde (Originalbild und Lizenztext: 32

33 Probleme und neue Entwicklungen Die Verwendung von Camera-RAW-Formaten bringt allerdings auch Probleme mit sich: wie bereits im vorigen Abschnitt angesprochen wurde, handelt es sich bei den RAW-Formaten um proprietäre Bildformate, die von Kameraherstellern für eine bestimmte Modellpalette entwickelt wurden. Zur Darstellung und Bearbeitung einer RAW-Datei ist der/die AnwenderIn primär auf Originalsoftware des Kameraherstellers angewiesen. Dieser hat aber nur ein beschränktes Budget für Softwareentwicklung zur Verfügung und wird vermutlich die Unterstützung seiner Altformate einstellen, wenn er genügend neue Modellgenerationen auf den Markt gebracht hat. Aus dem Blickpunkt der Archivierungssicherheit ist dieser Umstand natürlich höchst bedenklich. Kommerzielle Bildbearbeitungsprogramme wie Adobe Photoshop oder Adobe Lightroom können zwar eine Vielzahl von RAW-Formaten lesen, bei jenen neuer Kameramodelle kommt es aber immer wieder zu Fehlanzeigen, wie zum Beispiel bei Fujifilm-Kameras mit EXR-Sensoren 15. Auch hier sind unvollständig dokumentierte, proprietäre RAW-Dateiformate als Fehlerursache anzunehmen. Wie in Kapitel 4.2 erläutert wird, benötigen RAW-Bilder viel Speicherplatz, ihre Bearbeitung ist zudem sehr rechenintensiv. Obwohl RAW-Dateien aufgrund ihrer Informationsmenge niemals an die Dateigrößen des verlustbehafteten JPEG- Formats herankommen werden, besteht bei Speicher- und CPU-Bedarf durchaus Optimierungsbedarf. Schließlich muss die DSLR nach Betätigung des Auslösers die RAW-Datei so schnell als möglich in ihren Speicher schreiben, um bereit für das nächste Foto zu sein. Für aufwendige Kompressionsvorgänge fehlt schlicht die Zeit 16. Durch die nachträgliche Änderung der Dateistruktur lässt sich zudem der Rechenaufwand für die Darstellung der RAW-Datei senken. Mit dem 2004 veröffentlichten DNG-Format (DNG = digital negative) wollte der Softwarehersteller Adobe die Probleme der zueinander inkompatiblen RAW-Formate lösen: DNG ist ein offen spezifiziertes Dateiformat, das von Adobe für EntwicklerInnen und AnwenderInnen kostenfrei zur Verfügung gestellt wird 17. Es stellt eine einheitliche, standardisierte Datenstruktur für RAW-Daten bereit. Somit können Bildbearbeitungsprogramme die RAW-Daten beliebiger Kameramodelle lesen, ohne dafür adaptiert werden zu müssen. DNG erlaubt den Einsatz des verlustfreien Kompressionsalgorithmus JPEG Lossless Compression zur Reduktion der Dateigröße. Damit lassen sich je 15 vgl.: 16 Einige Hersteller haben Kompressionsalgorithmen von unterschiedlicher Effizienz in ihren RAW-Formaten implementiert: 17 Gegenüber Software-Entwicklern verzichtet Adobe auf jegliche Einnahmen aus Patenten, die dem Unternehmen durch die Implementierung des DNG-Formats zustehen würden. AnwenderInnen wird ein kostenfreies Konverter-Programm ins DNG-Format zur Verfügung gestellt. 33

34 nach RAW-Format zwischen 20 und 60% der Dateigröße einsparen. Die Beschränkung auf einen Kompressionsstandard erleichtert Software-EntwicklerInnen die Einbindung des Dateiformats. Mit der 2008 veröffentlichten Version DNG 1.2 (Adobe Systems Incorporated, 2008) verbesserte Adobe das rechenaufwendige Lesen und Schreiben von DNG-Dateien. Das mehrere Megapixel große RAW-Bild wird vor der Speicherung in 512x512 Pixel große Kacheln (SubTiles) unterteilt, die unabhängig voneinander komprimiert werden. Dies bringt sowohl beim Öffnen als auch beim Speichern der RAW-Datei große Geschwindigkeitsvorteile, da moderne Prozessoren die Arbeitslast auf mehrere Rechenkerne verteilen können 18. Die 2012 veröffentlichte DNG-Version 1.4 (Adobe Systems Incorporated, 2012) brachte mit Lossy DNG ein verlustbehaftetes Kompressionsverfahren für RAW-Dateien. Adobe sieht den Haupteinsatzbereich von Lossy DNG in der platzsparenden Archivierung von Zweite-Wahl-Fotos. Lossy DNG und JPEG-Dateien nutzen denselben Kompressionsalgorithmus, daher sind auch ihre Dateigrößen vergleichbar. Lossy DNG bietet allerdings wesentlich mehr Bearbeitungsspielraum als JPEG, da vor der verlustbehafteten Komprimierung nur das Demosaicing durchgeführt wird, während JPEG auch Weißabgleich, Gamma-Korrektur und Schärfefilter auf das Bild anwendet. (vgl. obigen Abschnitt Aufgaben eines RAW Konverters ). Durch das bereits durchgeführte Demosaicing kann bei Lossy DNG zudem die Auflösung des RAW-Bilds beliebig angepasst werden, was sich sehr vorteilhaft auf die Dateigröße auswirkt (siehe Tabelle 1). Dateiformat Komprimierung Auflösung Megapixel Dateigröße [MB].CR2 (Canon Verlustfrei 5184 x ,92 22,37 RAW) DNG Verlustfrei 5184 x ,92 18,2 DNG Verlustbehaftet / Bildpixel 5184 x ,92 6,65 beibehalten DNG Verlustbehaftet / auf x ,18 Megapixel verkleinert DNG Verlustbehaftet / auf 6 Megapixel verkleinert 3000 x ,97 Tabelle 1: Vergleich verschiedener DNG-Varianten, die aus einer Canon RAW-Datei erstellt wurden In (Shankland, 2012), Abschnitt New DNG features wird von einer Verdreifachung der Lese/Schreibgeschwindigkeit berichtet. 19 Erstellt mit Adobe DNG Konverter

35 Knapp 10 Jahre nach der Einführung hat Adobe sein Ziel, DNG als neues RAW-Standardformat für Digitalkameras zu etablieren, deutlich verfehlt: nur wenige, nach heutigem Stand veraltete Modelle unterstützen DNG 20. Durch seine Innovationen in Bezug auf Speicherbedarf und Rendering-Performance hat DNG aber eine hohe Bedeutung als Austausch- und Archivierungsformat für RAW-Daten. Bereits 2010 gab es über 290 Software-Applikationen aus den Bereichen Bildbearbeitung, -verwaltung und -konvertierung, die das DNG-Format unterstützten 21. Auch der in Kapitel beschriebene Lösungsansatz wird sich die Vorzüge des DNG-Formats zunutze machen Photosharing-Platformen zum Teilen der Bilder Photosharing-Plattformen dienen Fotoschaffenden zur Veröffentlichung ihres Bildmaterials im Internet und dem Austausch mit Gleichgesinnten. Der seit 2004 betriebene Online- Dienst flickr.com ist Urahn und zugleich einer der populärsten Vertreter dieser Produktgattung. Der Name flickr leitet sich vom englischen to flick through ab, was soviel wie durchblättern bedeutet. Flickr wurde ursprünglich als Zusatzmodul eines Onlinespiels entwickelt, zählt aber mittlerweile zu den 50 populärsten Websites weltweit wurde das viermilliardste Foto hochgeladen. [vgl. (Gockel, 2011, p. 183 ff)] Abbildung 11: Eine auf flickr.com veröffentliche Fotogalerie 20 (Pearson, 2011) listet etwa 30 Modelle 21 These pages identify over 290 non-adobe products that support DNG in some way, from well over 250 sources. (Pearson, 2011) 35

36 Das Geschäftsmodell von flickr wurde mittlerweile von vielen anderen Photosharing-Sites wie Google Picasa oder Photobucket.com kopiert und eignet sich deshalb gut zur Charakterisierung dieses Produktgenres: Photosharing-Plattformen bieten Fotografen und Fotografinnen eine leistungsstarke Online-Software zum Erstellen und Präsentieren ihrer Bilder und Fotoalben im Internet. Der Online-Dienstanbieter kümmert sich um den laufenden Betrieb, die Wartung und etwaige Updates der involvierten Hard- und Software. Damit stellt eine Photosharing-Platform ein SaaS (Software-as-a-Service)-Angebot im Sinne des Cloud-Computings dar [vgl. (Vogel, et al., 2010, pp )]. Die Kernfunktionen von Photosharing-Diensten sind die Bereitstellung von Online-Fotogalerien, die sich sowohl von mobilen Endgeräten als auch von Desktop-Browsern nutzen lassen (siehe Abbildung 11). Der/die ErstellerIn kann detailliert festlegen, wer seine/ihre Galerien betrachten darf und diesen Personenkreis über eine Nachrichtenfunktion verständigen. Durch Beschlagwortung kann er/sie die Auffindbarkeit seiner Bilder erhöhen, die dabei vergebenen Schlagworte (Tags) werden häufig aggregiert in einer Tag Cloud dargestellt (siehe Abbildung 12). Der Upload der Bilder wird meist durch eine eigens programmierte Desktop- Software erleichtert, welche die Fotos in ein geeignetes Übertragungsformat (meist JPEG) konvertiert und so die Upload-Zeit verkürzt. Auch die BetrachterInnen können sich die hochgeladenen Bilder in verschiedenen Auflösungen anzeigen lassen. Aufgrund des verbrauchten Online-Speicherplatzes und der langen Upload-Dauer werden die Fotos vor dem Upload allerdings oft verkleinert, wodurch dem/der BetrachterIn nur ein Bruchteil der möglichen Bildauflösung zur Verfügung steht ein fauler Kompromiss, wie die Erläuterung der Problemstellung in Kapitel 3.3 zeigen wird. Einnahmen generieren die meisten Photosharing-Dienste über ein Freemium - Modell. Freemium ist eine Wortkombination aus free und premium und bezeichnet ein Geschäftsmodell, bei dem der Kunde/die Kundin anfangs ein kostenloses Basisprodukt nutzen kann, später aber auf dessen kostenpflichtige Premium- Variante wechseln wird. Dieser Wechsel wird durch den bewusst reduzierten Funktionsumfang des Basisprodukts provoziert, der ab einer gewissen Nutzungsdauer hinderlich wird. Flickr.com limitierte über viele Jahre das monatliche Upload-Volumen seiner Gratis-Accounts, um die NutzerInnen zum Umstieg auf die kostenpflichtige Pro-Variante zu bewegen. Andere Anbieter wie Picasa beschränken den zur Verfügung stehenden Online-Speicherplatz. [vgl. (Osterwalder & Pigneur, 2011, p. 100)] Als retention tools, die User am Abwandern zu alternativen Diensten hindern sollen, dienen häufig Diskussionsforen und andere Community-Werkzeuge. In den zahlreichen Flickr-Diskussionsgruppen können sich Fotografinnen und Fotografen 36

37 zu unterschiedlichen Fachbereichen wie Tier- oder Naturfotografie austauschen und auch Feedback zu eigenen Werken erhalten. Abbildung 12: Tag Clouds visualisieren die Popularität von Schlagworten über deren Schriftgröße. Obwohl soziale Netzwerke wie Facebook den klassischen Photosharing-Diensten beim Veröffentlichen von Bildmaterial immer mehr Konkurrenz machen, sind letztere noch immer das Mittel der Wahl zur Publikation größerer Bildkataloge. Ein auf visuelle Inhalte abgestimmtes Layout und die Möglichkeit zur Veröffentlichung größerer Bildauflösungen sind nur zwei Beispiele für wichtige Differenzierungsfeatures. Allerdings werden weitere Innovationen nötig sein, um die Kernkompetenz Photosharing gegenüber sozialen Netzwerken zu behaupten. Der in Kapitel vorgeschlagene RAW-Entwicklungsmodus könnte eine solche Innovation darstellen. 3.3 Problemstellung und Lösungsansatz In den vergangenen sieben Jahren hat der Autor über 120 Fotoalben mit seiner DSLR erstellt und über verschiedene Photosharing-Dienste im Freundes- und Bekanntenkreis geteilt. Dabei ist er auf folgende drei Hauptprobleme gestoßen, deren Ursachen bereits im vorangegangenen Kapitel angeschnitten wurden: 1. Kein Cloud-Backup von RAW-Bildern: In der Cloud (d.h. auf den umfassend durch Backups, Zutrittsbeschränkungen, etc. gesicherten Servern des Photosharing-Anbieters) werden nur verkleinerte und qualitätsgeminderte JPEG-Versionen der Fotos gespeichert. Grund dafür sind die hohen Dateigrößen der RAW-Dateien, 37

38 die lange Upload-Zeiten und großes Datenvolumen verursachen. Dieses Datenvolumen verursacht Kosten in Form von erhöhtem Internet-Traffic und Server-Speicherplatz. Die wertvollen digitalen Negative liegen relativ ungeschützt auf lokalen Festplatten in den Wohnräumen des Autors. 2. Kein mobiler Zugriff auf hochauflösende Bildversionen: es ist nicht möglich, von unterwegs auf die hochaufgelösten Originalbilder zuzugreifen, um beispielsweise Bekannten spontan druckfähige Versionen der im Internet geteilten Fotos zukommen zu lassen. Die Kundschaft professioneller Fotografinnen und Fotografen muss anhand niedrig aufgelöster Vorschaubilder in Web-Galerien entscheiden, welche Fotos sie gerne (kostenpflichtig) bestellen würde. 3. Für Ausarbeitungen/Bearbeitungen müssen Bilder mehrfach hochgeladen werden: erfolgt die Bestellung von Fotoprodukten wie Postern, Fotobüchern oder Plakaten bei verschiedenen Dienstleistern, müssen die Bilder vom lokalen PC mehrfach hochgeladen werden. Da es mittlerweile eine Vielzahl von Fotoprodukten und Anbietern gibt, die sich jeweils auf verschiedene Teilsegmente spezialisiert haben, ist es durchaus wahrscheinlich, dass ein/e AnwenderIn bei mehreren Anbietern Aufträge platziert. Für RAW-Bilder können selbst einfache Bearbeitungen nicht online ausgeführt werden. Selbst wenn das unter Punkt 1 geschilderte Cloud- Backup angeboten wird, wären also mehrere Up- und Downloads erforderlich, um das RAW-Foto für verschiedene Anwendungszwecke anzupassen. Um die angenommene Problemstellung einem Realitätstest zu unterziehen, wurde der Leistungsumfang der wichtigsten Photosharing-Anbieter in Bezug auf die genannten Probleme untersucht. Die Untersuchung erfolgte anhand folgender Kriterien: Erlaubt der Anbieter einen Upload von RAW-Bildern oder müssen diese vorher in andere Bildformate (z.b. JPEG oder TIFF) konvertiert werden? Ist ein Download der vom Anbieter gehosteten RAW-Bilder möglich? Bietet die Photosharing-Site eine Browser-Darstellung der RAW-Bilder, bei der diese in voller Auflösung betrachtet werden können? Gibt es Online-Bearbeitungsfunktionen für RAW-Bilder (Helligkeits- und Farbkorrekturen etc)? Request-Workflow: Können Kundinnen und Kunden von Fotoschaffenden gezielt hochauflösende Versionen von einem niedrig aufgelösten Bild anfordern (beispielsweise zur Erstellung eines Fotobuchs). Wie hoch ist der Automatisierungsgrad dieses Prozesses? 38

39 Anbieter Upload Download Darstellung im Browser Bearbeitung Request- Workflow Instagram.com nein 22 nein nein nein nein Photobucket.com nein 23 nein nein nein nein Flickr.com nein 24 nein nein nein nein Picasa.com / Google+ ja ja ja (Zoom ja (JPEG- nein Photos beschränkt) Version) Dropbox.com ja ja nein 25 nein nein SmugMug.com ja 26 ja nein nein nein Tabelle 2: Camera-RAW-Unterstützung der wichtigsten Photosharing-Sites (Stand: August 2013) Die Ergebnisse in Tabelle 2 zeigen, dass kein Anbieter alle genannten Kriterien unterstützt. Die Hälfte der Anbieter erlaubt überhaupt keinen RAW-Upload, der Request-Workflow wird von keinem der Anbieter unterstützt. Picasa/Google+ zeigt zwar gute Ansätze, die Browserdarstellung ist bei diesem Dienst aber nur auf wenige Zoomstufen beschränkt. Bei den Bearbeitungsfunktionen wird nur eine JPEG-Version des RAW-Bildes verwendet. Daher sollte im Rahmen dieser Masterarbeit an einer besseren Lösung des Problems gearbeitet werden Ein erster Lösungsansatz Ein erster, vom Autor spontan entworfener Lösungsansatz sieht einen cloud-basierten Online-Dienst für RAW-Fotos vor, der Fotoschaffenden das interaktive Bearbeiten und Teilen ihrer Fotos im Browser erlaubt. Abbildung 13 zeigt den grundlegenden Aufbau des Dienstes in 5 Schritten: 1. Der Fotograf konvertiert die RAW-Fotos in das komprimierte DNG-Format, wodurch zwischen 10 und mehr als 75% des Speicherplatzes gespart werden 27. Durch die Wahl der richtigen Kompressionsmethode lässt sich ein guter Kompromiss zwi- 22 vgl.: 23 vgl.: 24 vgl.: Unterstützung über kostenpflichtiges Zusatzprodukt SmugMugVault siehe 27 Der Einsparungsgrad hängt vom Ausgangsformat des RAW-Fotos und von der Wahl der DNG-Komprimierung (verlustfrei/verlustbehaftet) ab. Die Dateigrösse neuerer RAW-Formate verringert sich bei verlustfreier DNG- Komprimierung nur mehr um 10-20%, da das Ausgangsformat bereits ähnliche Kompressionstechniken einsetzt. Mit Lossy DNG, der verlustbehafteten Version, ist eine Einsparung um mindestens 75% möglich, die allerdings zulasten der späteren Bearbeitungsmöglichkeiten geht. Durch die Anpassbarkeit der Bildauflösung lässt sich bei Lossy DNG die Dateigröße dramatisch reduzieren (siehe Tabelle 1) 39

40 schen Datenmenge/Upload-Dauer und der erforderlichen Bildqualität des Fotos erzielen. 2. Upload der konvertierten Fotos über das HTTP-Protokoll auf den Server des Online-Dienstes, wofür entweder der Web-Browser oder ein kommandozeilenbasierter HTTP-Client wie curl 28 verwendet werden kann. 3. Der Online-Dienst prozessiert die einlangenden Bilder am Server in eine Bildpyramide und speichert sie in einem kachelbasierten Bildformat, das eine effiziente Übertragung einzelner Bildansichten ermöglicht (siehe Abschnitt Bildkachelung zur schnelleren Anzeige ) 4. AnwenderInnen können das gekachelte Bild nun über ein Anzeigeprogramm (tile viewer) im Webbrowser betrachten. Da viele tile viewer mittlerweile in der im Browser integrierten Skriptsprache Javascript verfügbar sind, müssen zur Betrachtung der Bilder keine Zusatzprogramme installiert werden. Die meisten tile viewer funktionieren auch auf mobilen Endgeräten wie Smartphones. 5. Durch das Anhängen von URL-Parametern an die Bildkacheln kann eine serverseitige Bearbeitung mit Filtern oder Transformationswerkzeugen ausgelöst werden (siehe Abschnitt Bearbeitungsfunktionen ). Abbildung 13: Struktur des RAW2Cloud-Dienstes curl ist ein Kommandozeilen-Tool zur URL-basierten Datenübertragung in Computernetzwerken und kostenlos unter verfügbar 29 Quelle: vom Autor erstellte Übersichtsgrafik unter Verwendung von Einzelgrafiken, die auf OpenClipart.org unter der Public-Domain-Lizenz veröffentlicht wurden (siehe: 40

41 Bildkachelung zur schnelleren Anzeige Am Server wird das hochgeladene RAW-Bild in eine gekachelte Bildpyramide prozessiert (siehe Abbildung 14, Schritt 3) und in ein Kachelformat konvertiert. Eine Bildpyramide ist eine hierarchische Struktur, die ein pixelbasiertes Bild in verschiedenen Auflösungen repräsentiert. Die unterste Stufe entspricht dem Bild in Originalauflösung. Für alle weiteren Stufen wird das Bild der vorherigen Stufe auf 25% seiner Größe verkleinert (d.h. seine Länge und Breite halbieren sich), bis ein vordefinierter Grenzwert erreicht wird. Meist wird die Verkleinerung abgebrochen, wenn das Bild in einer Kachel (siehe folgender Absatz) Platz findet. Anschließend werden die errechneten Zwischenauflösungen gekachelt, also in quadratische Einzelbilder mit vorgegebener Größe unterteilt. Verbreitete Kachelauflösungen sind 256 x 256 oder 512 x 512 Pixel. Abbildung 14: Aufbau einer Bildpyramide 30 Nun erfolgt die Konvertierung in das Kachelformat, bei der die generierten Kacheln in ein internettaugliches Übertragungsformat konvertiert und nach einer bestimmten Dateinamenskonvention abgespeichert werden. Verbreitete Kachelformate sind das von Microsoft entwickelte DeepZoom-Format 31 und das vom gleichnamigen Unternehmen veröffentlichte Zoomify-Format 32. Während das einfachere Zoomify-Format die Bildpyramide eines hochauflösenden Fotos abspeichern kann, unterstützt das komplexere DeepZoom-Format ineinander übergehende Bildpyramiden (sparse images) und Kollektionen mehrerer Bilder. 30 vgl.: IIPImage Project Documentation ( 31 vgl.: 32 vgl.: 41

42 Beide Formate bestehen aus einem Metadatendokument und einer standardisierten Dateipfadstruktur. Das im XML-Format vorliegende Metadatendokument beschreibt die Auflösung des Originalbildes, die Anzahl seiner Bildpyramidenstufen und die verwendete Tilegröße. Die standardisierte Dateipfadstruktur erlaubt es dem Anzeigeprogramm, den Dateinamen einer anzufordernden Kachel aus den bereits vorhandenen Metadaten zu errechnen. Beim Zoomify-Format lautet die Struktur TileGroup{TileGroupIndex}/{z}- {x}-{y}.jpg, wobei sich die Platzhalter wie folgt errechnen: TileGroup: ergibt sich aus der aktuellen Zoomstufe sowie dem Rechts- und Hochwert der Kachel. z: entspricht der Zoomstufe, also der aktuellen Ebene der Bildpyramide (0=Spitze der Pyramide, entspricht kleinster Zoomstufe) x: entspricht dem Rechtswert der Kachel auf der aktuellen Ebene der Bildpyramide y: entspricht dem Hochwert der Kachel auf der akutellen Ebene der Bildpyramide. Mithilfe des Metadatendokuments und der standardisierten Ordnerstruktur kann das Anzeigeprogramm später gezielt jene Kacheln anfordern, die für die aktuelle Ansicht des Bildes erforderlich sind, unnötige Datenübertragungen unterbleiben (siehe Abbildung 14, Schritt 4). Damit eignen sich Kachelformate auch für die Darstellung hochauflösender Bilder auf mobilen Endgeräten. Ein Beispiel verdeutlicht dies: betrachtet man ein gekacheltes RAW-Bild in einem 1024 x 1792 Pixel großen Viewer-Fenster, sind dafür 7 x 4 = 28 Kacheln à 256 x 256 Pixel Auflösung erforderlich. Bei etwa 5 Kilobyte Dateigröße je Kachel sind dies 140 KB Daten. Das in diesem Beispiel verwendete RAW-Bild hat eine Dateigröße von 22,5 Megabytes, was in etwa der 160-fachen Datenmenge entspricht. Selbst bei einer vorherigen Konvertierung in das verlustbehaftete JPEG-Format hat das Bild noch 1,48 MB, was der etwa zehnfachen Datenmenge entspricht. Bearbeitungsfunktionen Will der/die UserIn nun das RAW-Bild im Browser bearbeiten, sollen die verwendeten Filtereinstellungen (z.b. Tonwertkorrektur, Weißabgleich) über URL-Parameter an den Server übertragen werden. Dieser öffnet die RAW-Datei, wendet die Einstellungen an und generiert eine gekachelte Version des Bildes, die auf den Client übertragen wird. Die Bearbeitungen am Server nimmt ein kommandozeilenbasierter Bildprozessor vor, wie beispielsweise das weitverbreitete OpenSource-Tool ImageMagick 33. Der Bearbeitung nachgelagert ist der oben bereits erwähnte Kachelungsprozess. Anschließend werden die Bildkacheln an den Browser zurückgeschickt. 33 ImageMagick ist ein für Windows, Linux und MacOS verfügbares Kommandozeilentool, das Bilder in verschiedensten Formaten bearbeiten kann. Das Programm ist unter kostenlos beziehbar. 42

43 Eine Technologierecherche ergab, dass es bereits einige cloud-basierte Bildbearbeitungsdienste gibt, wie beispielsweise cloudinary ( Dieser Dienst bietet unter anderem Bearbeitungsfunktionen für bereits in der Cloud befindliche Bilder an, wobei die anzuwendenden Bearbeitungsschritte über URL-Parameter übergeben werden. Kachelungen größerer Bilder unterstützte aber keiner dieser Dienste. Abbildung 15: Ausgangsbild für den Test des Cloud-Bildbearbeitungsdiensters cloudinary 34 Abbildung 16: Durch den URL-Parameter e_contrast:80 wurde der Kontrast des Fotos erhöht Quelle: Cloudinary.com, abrufbar unter 35 Quelle: Cloudinary.com, abrufbar unter 43

44 3.4 Überführung der Lösung in ein Produkt Die bisherigen Abschnitte dieses Kapitels widmeten sich einer ausführlichen Erläuterung des Problems und der Formulierung eines Lösungsansatzes. Der logische nächste Schritt wäre die Umsetzung des Lösungsansatzes in einen realitätsnahen Prototypen. Dieses Vorhaben würde sich über mehrere Monate hinziehen und neben einem beträchtlichen Einsatz an Arbeitszeit auch zahlreiche weitere Investitionen in Server-Hardware, Software- Lizenzen, Fachliteratur etc. erfordern. Potentielle Kunden bekämen den Prototypen also erst zu Gesicht, nachdem der/die EntrepreneurIn eine beträchtliche Menge der zur Verfügung stehenden Ressourcen investiert hat. In dieser Herangehensweise ortet Lean-Canvas-Autor Ash Maury zwei Hauptprobleme: 1. The bigger risk for most startups is building something nobody wants (Maurya, 2012, p. 43) - das größte Risiko eines Startups ist die Entwicklung eines Produktes, das niemand brauchen kann. Mit der oben geschilderten Prototyp-Entwicklung im stillen Kämmerlein findet der nötige Abgleich zwischen der Idee des Entrepreneurs oder der Entrepreneurin und der Realität viel zu spät statt. Innovierende sollten daher die Praxistauglichkeit ihrer Ideen durch Befragung der angedachten Zielgruppe prüfen, bevor sie nennenswerte Ressourcen in die Umsetzung investieren. 2. Die gesamte Aufmerksamkeit wird auf den (technischen) Lösungsaspekt der Idee gelenkt. Dieser macht aber nur einen verschwindend kleinen Anteil des späteren Produktes aus. Wichtige Produktaspekte wie Zielgruppe, Absatzkanäle, Geschäftsmodell bleiben unberücksichtigt. Your job isn t just building the best solution, but owning the entire business model and making all the pieces fit. (Maurya, 2012, p. 42) Mit bereits in Kapitel vorgestellten Lean Canvas versucht Maurya, die meist auf technische Aspekte beschränkte Perspektive von Innovierenden zu erweitern und ihre Aufmerksamkeit auf eine ganzheitliche Produktentwicklung zu lenken. Der Lean Canvas dekonstruiert das Produkt dabei in neun verschiedene Bereiche, die im Rahmen einer kurzen Kreativitätssitzung befüllt werden. Alle nun folgenden Aktivitäten haben das Ziel, die gemachten Angaben zu prüfen und gegebenenfalls zu korrigieren, wobei mit den riskantesten Angaben begonnen wird. Der in Abbildung 17 dargestellte Lean Canvas ist entsprechend durchnummeriert. 44

45 Abbildung 17: Leerer Lean Canvas mit Ausfüllhilfen (Maurya, 2012, p. 66) Problem und Kundensegmente Maurya empfiehlt, mit dem Befüllen der Segmente Problem und Kunden zu beginnen. Der/die EntrepreneurIn sollte bereits ein klares Bild von der Zielgruppe des späteren Produktes haben und sich in ihre Lage versetzen. Welche ihrer dringenden Probleme kann das Produkt lösen? Gibt es existierende Konkurrenzprodukte, die das Problem (ansatzweise) lösen? Die Konkurrenzanalyse sollte nicht aus der Perspektive der Innovierenden, sondern aus dem Blickwinkel der potentiellen Kunden erfolgen. Dies kann mitunter zu überraschenden Konkurrenten führen: eine neuartige Buchhaltungssoftware für Heimanwender wird sich nicht nur mit existierenden Lösungen aus diesem Marktsegement vergleichen müssen, sondern auch mit einer Tabellenkalkulation, da viele EinsteigerInnen Tabellenkalkulationen für Buchhaltungszwecke verwenden. Für die spätere Entwicklung des Geschäftsmodells ist es außerdem wichtig, zwischen nutzenden und zahlenden Kunden und Kundinnen eines Produkts zu unterscheiden. Bei einem Internet-Preisvergleichsportal wird die überwiegende Anzahl der NutzerInnen aus Kaufinteressierten bestehen, die kostenlose Preisvergleiche durchführen wollen. Die eigentlichen Kunden des Portals sind aber die dort gelisteten Unternehmen, denn sie bezahlen für diese Leistung [vgl. (Maurya, 2012, p. 66f)]. 45

46 Die potentielle Zielgruppe seines Online-Dienstes für RAW-Fotos sieht der Autor in folgenden Anwendergruppen: (Hobby)-Fotografen und Fotografinnen mit DSLR-Kamera und regelmäßiger Bildausbeute An hochauflösenden RAW-Fotos interessierte Kunden und Kundinnen von Fotoschaffenden (bessere Beurteilung von Schärfe,..) Fotografinnen und Fotografen, die ihre RAW-Bilder online zum Kauf anbieten möchten. Die wichtigsten, noch ungelösten Probleme dieser Zielgruppe sind nach Sichtweise des Autors folgende: Photosharing-Dienste unterstützen keine hochauflösenden (RAW)-Bilder mit mehr als 5 Megapixel Auflösung Photosharing-Dienste ermögliche kein Backup der originalen RAW-Bilder in der Cloud. Es gibt keine Möglichkeit, unterwegs oder von Drittrechnern aus auf hochauflösende Bilder zuzugreifen. Dies ist aber zur Beurteilung von Schärfe und Bilddetails erforderlich. Für Ausarbeitungen müssen hochauflösende Bilder mehrfach hochgeladen werden, wenn der Kunde oder die Kundin verschiedene Fotodienstleister nutzen will Unique Value Proposition Unter Unique Value Proposition versteht Maurya Alleinstellungsmerkmale des Produkts, welche seinen Kauf oder zumindest das Interesse der Kunden und Kundinnen am Produkt rechtfertigen. Der Begriff lässt sich in etwa mit einzigartiges Wertangebot 36 ins Deutsche übersetzen. Maurya sieht in der Definition dieses Wertangebots einen der schwierigsten Lean Canvas-Bereiche, da sowohl die rationale als auch emotionale Seite der Kundschaft angesprochen werden muss. Häufige Fehler bei der Wahl des Wertangebots sind Alleinstellung um jeden Preis (auch wenn das Merkmal für die Zielgruppe gar nicht relevant ist) oder die bloße Aufzählung von Produktfunktionen ohne den Endnutzen für die Kundschaft hervorzuheben (z.b. professionelle Gestaltung von Bewerbungsunterlagen vs. Ihre Eintrittskarte für den nächsten Traumjob ). [vgl. (Maurya, 2012, p. 70f)] Mögliche Wertangebote für den Online-RAW-Dienst sind: Online immer auf die native/beste Bildauflösung zugreifen RAW-Bilder im Browser und auch auf mobilen Endgeräten bearbeiten 36 In der deutschen Ausgabe von (Osterwalder & Pigneur, 2011) wurde der englische Begriff value proposition mit dem deutschen Wertangebot übersetzt. Da die von Maurya gewählte Bezeichnung auf diesem Begriff aufbaut, hat der Autor die Übersetzung übernommen. 46

47 Ihre schönsten Momente in bester Qualität und an den sichersten Orten der Welt gespeichert RAW-Bilder online zu Geld machen Solution Im Bereich Solution sieht Maurya den vielleicht gefährlichsten Lean-Canvas-Bereich. Hier beschreiben die Innovierenden jene oft technischen Produkteigenschaften, mit denen die in Punkt 1 genannten Probleme gelöst werden sollen. Da viele Innovierende einen technischen Background besitzen, besteht die Gefahr, diesem Punkt zuviel Aufmerksamkeit und Detailierung zu widmen oder aber an liebgewonnenen Lösungsansätzen festzuhalten, auch wenn diese den Bedürfnissen der Zielgruppe widersprechen. Aus diesem Grund hat Maurya das Solution-Feld besonders klein ausgeführt und hält ausdrücklich fest, dass der technische Lösungsansatz im Verlauf der Lean-Canvas-Iterationen häufig geändert werden muss. [vgl. (Maurya, 2012, p. 75f)] Für den Online-Dienst des Autors bieten sich folgende Lösungselemente an: RAW-Upload in die Cloud im komprimierten DNG-Format (75% geringere Dateigröße) browerbasierter Viewer auf Tile-Basis (auch für mobile Endgeräte) API zur Anbindung an Fotodienstleister verhindert unnötige Up- und Downloads Channels Channels sind Kanäle zu potentiellen Kundinnen und Kunden. In der Frühphase von Running Lean wird der/die EntrepreneurIn diese Interessenten aus dem Freundes- und Bekanntenkreis bzw. dem professionellen Umfeld rekrutieren. Mit ihnen überprüft und verfeinert er/sie die Geschäftsidee in den problem und solution interviews (siehe Kapitel 4.1 und 5.3), Für die später angestrebte Wachstumsphase des Startups ist es aber unerlässlich, sich frühzeitig über Kanäle zu neuen Kundinnen und Kunden Gedanken zu machen. Es gilt, aus der Fülle der möglichen Kanäle von Blogs über Online-Anzeigen bis hin zur Präsenz auf Fachmessen die für das Produkt passenden auszuwählen. Maurya charakterisiert dazu die Kanäle nach folgenden Gesichtspunkten [vgl. (Maurya, 2012, p. 76)]: Inbound/Outbound: Bei Inbound-Kanälen initialisiert der/die InteressentIn den Kontakt, indem er/sie beispielsweise einen Blog-Beitrag zur Produktidee mit einer Nachfrage- beantwortet und mehr über das vorgestellte Produkt wissen will. Auch im Internet veröffentlichte Tutorials, Online-Seminare oder E-Books können Inbound-Kontakte generieren. Bei Outbound-Kanälen hingegen stellt der/die EntrepreneurIn den Kontakt her, etwa durch gezielte Schaltung von Werbeanzeigen, 47

48 Verfassen von Newslettern oder das in Europa meist verbotene cold calling dem ungefragten Anrufen potentieller Interessenten. Kostenlos/Kostenpflichtig: Ein Kanal kann kostenlos oder kostenpflichtig sein. Ein Blog kann zumindest in einer einfachen Basisversion bei diversen Online- Anbietern kostenlos betrieben werden. Für die Schaltung von Online-Anzeigen fallen hingegen sofort Gebühren an. Bei näherer Betrachtung zeigt sich allerdings, dass kein Kanal wirklich kostenlos sein kann schließlich muss der/die EntrepreneurIn für das Verfassen von Blog-Beiträgen Arbeitszeit investieren. Auch bei kostenpflichtigen Kanälen kann der nötige Aufwand an Humankapital den offiziellen Preis schnell übersteigen. Möchte der/die EntrepreneurIn beispielsweise 300 EUR in die Schaltung von Online-Anzeigen investieren, ist es durchaus wahrscheinlich, dass die Produktionskosten der erforderlichen Texte und Grafiken die reinen Kanalkosten (d.h. den Preis der Schaltungen) bei weitem übersteigen. Direkt/Indirekt: Der/die EntrepreneurIn kann das Produkt entweder selbst bzw. durch eigene Mitarbeiter verkaufen (direkter Kanal) oder sich dafür einer Vertriebspartnerschaft mit einem etablierten Unternehmen bedienen (indirekter Kanal). Manuell/Automatisiert: Bei einem manuellen Kanal findet die Kundenkommunikation immer zwischen zwei Menschen statt, bei der automatisierten Variante hingegegen ersetzt meist ein Computerprogramm den Verkäufer. Ein Beispiel dafür sind Empfehlungssysteme in Online-Shops, die den Kundinnen und Kunden automatisch Alternativen zum aktuell betrachteten Produkt empfehlen und diese bei Bedarf auch rabattieren. Kundenkanäle werden vor allem in der Wachstumsphase des Startups relevant, die auf die Entwicklungsphase des Produktes folgt. Maurya empfiehlt daher, den Kundenkanälen in der Frühphase von Lean Canvas nicht zuviel Aufmerksamkeit zu schenken. Dies betrifft etwa die Schaltung von Werbeanzeigen im Internet oder die Rekrutierung von freiberuflichen Vertriebs- und Marketingmitarbeitern. Beide Aktivitäten helfen zwar den Bekanntheitsgrad des Produktes bei der Zielgruppe zu steigern, kosten aber auch finanzielle und zeitliche Mittel, die für die nötige Perfektionierung der Produktidee fehlen. Im schlimmsten Fall erzeugt die frühzeitige Vermarktung der Idee einen erhöhten Nachfragedruck, der den/die EntrepreneurIn zwingt, das Vorhaben überhastet umzusetzen. Inbound-Kanäle wie Blogs sind nach den Erfahrungen von Maurya mit geringeren Gesamtkosten behaftet als Outbound-Kanäle und können bereits in der Frühphase der Produktentwicklung mit Informationen bespielt werden, um die Aufmerksamkeit potentieller Kunden zu erlangen. Vom exzessiven Einsatz von Outbound-Kanälen rät Maurya hingegen ab. [vgl. (Maurya, 2012, p. 78f)] 48

49 Der Autor sieht in folgenden Kanälen gute Kontaktmöglichkeiten zu potentieller Kundschaft: Fotogruppen an der FH Technikum Wien und FH St. Pölten (der Autor studierte an beiden Hochschulen und hat Kontakt zu Lehrkräften) Usergroups/Fotokurse im Raum Wien Online-Werbung (Google Adwords) Mundpropaganda Facebook Einnahmequellen und Kostenstruktur Die Sicherstellung von Einnahmen ist ein weiteres Problem bei der Umsetzung neuer Produkte: Welcher Kunde oder welche Kundin möchte schon für ein noch in Entwicklung befindliches Produkt bezahlen? Nach Mauryas Ansicht wird er oder sie das gerne tun, wenn das Produkt tatsächlich ein dringendes Problem löst. Zögert der/die EntrepreneurIn hingegen die Preisfrage hinaus, wird die endgültige Bestätigung der Produktidee verfälscht, was die langfristige Existenz des Produktes gefährdet. Möglichen Zweifeln kann mit einer großzügigen Geld-Zurück-Regelung und einer Abbuchung des Betrages am Ende der Rechnungsperiode begegnet werden. Auf der Aufgabenseite sollte der/die EntrepreneurIn unnötige Ausgaben vermeiden und die nötige Infrastruktur für die Erzeugung und Bereitstellung des Produktes mieten [vgl. (Maurya, 2012, p. 81f)]. Die Einnahmen- und Ausgabenstruktur für den Online-Dienst des Autors sieht in einer ersten Grobschätzung wie folgt aus: Einnahmen werden über die monatlichen Nutzungsgebühren des Online-Dienstes erwirtschaftet, die bei 10 EUR im Monat liegen sollen. Die beiden Ausgabenblöcke bestehen aus Hosting- und Personalkosten: o Hosting-Kosten für den Betrieb des Online-Dienstes auf einer Cloud-Plattform (Heroku/Amazon Cloud) - Grobschätzung 1000 EUR o Monatliche Brutto-Personalkosten für eine Vollzeitstelle (Autor, 40h*60 EUR*4,5 Wochen) = EUR Aus diesen Zahlen folgt, dass der Break-Even bei 1200 Usern und Userinnen liegen müsste Wichtige Kennzahlen (key metrics) Moderne Kennzahlensysteme wie Balanced Scorecard verlassen sich bei der Beurteilung des Unternehmenserfolges nicht ausschließlich auf Finanzkennzahlen, da diese den Zustand des Unternehmens verspätet und nur teilweise abbilden. Ein Unternehmen, dass seine Innovationsaktivitäten eingestellt hat und sich auf den Vertrieb seiner erfolgreichen 49

50 Bestandsprodukte konzentriert, mag durch die Einsparung der Entwicklung zwar momentan gute Gewinne erwirtschaften, in einigen Jahren wird es aufgrund veralteter Produkte aber in Konkurs gehen. Auch bei der Beurteilung neu eingeführter, innovativer Produkte darf man sich nicht ausschließlich auf die erzielten Umsätze verlassen. Setzt das Unternehmen beispielsweise das in Kapitel vorgestellte Freemium-Geschäftsmodell ein, werden die meisten AnwenderInnen anfangs die kostenlose Basisversion des Produkts nutzen und erst später Umsätze über die kostenpflichtige Premium-Version generieren. Lean Canvas nutzt ein ganzheitliches Kennzahlensystem, um den Umsetzungserfolg einer Idee zu beurteilen. Maurya empfiehlt das Pirate Metrics System von Dave McClure, um das gesamte Interaktionsverhalten von Kunden und Kundinnen mit dem neuen Produkt in Form von Kennzahlen abzubilden und so die Stärken und Schwächen in der Interaktionskette zu analysieren. Dieses System sieht folgende Interaktionsphasen vor: Abbildung 18: Das Pirate-Metrics-Modell von Dave McClure [Quelle: (Maurya, 2012, p. 85)] Acquisition: die Kundschaft wird auf das Produkt aufmerksam. Beispiele: eine Kundin betritt ein Geschäft oder interagiert mit der Produktwebsite. Activation: die Kundschaft hat die erste positive Erfahrung mit dem Produkt. Beispiel: eine gelungene Warenpräsentation im Geschäft oder eine vielversprechende Demonstration auf der Produktwebsite. Retention: die Kundschaft nutzt oder probiert das Produkt wiederholt dies kann sowohl ein mehrfaches Ausprobieren vor dem Kauf im Geschäft bedeuten oder die Nutzung einer Demoversion 50

51 Revenue: die Kundschaft bezahlt für das Produkt der Kunde erwirbt das physikalische Produkt im Geschäft oder nutzt die kostenpflichtige Premium-Version eines Online-Dienstes Referral: die Kundschaft empfiehlt das Produkt weiter und wirbt aktiv um andere Anwender. Die trichterförmige Darstellung der Phasen in Abbildung 18 kommt nicht von ungefähr: sie symbolisiert den Selektionsprozess von einer größeren Anzahl von Interessierten in eine kleinere Anzahl von Kunden und Kundinnen, wobei in jeder Phase eine Reduktion stattfindet. Nicht jede Person, der auf ein Produkt aufmerksam wird (Activation) möchte dieses auch ausprobieren (Retention), von den Testern und Testerinnen eines Produkts wird sich nur ein bestimmter Prozentsatz zum Kauf (Revenue) entschließen. Durch die Abbildung des gesamten Kundeninteraktionsprozesses in Form von Pirate-Metrics-Kennzahlen kann der/die EntrepreneurIn Schwächen im Angebot präzise aufspüren: signalisieren die Kennzahlen gute Acquisition-Interaktionen, aber schlechte Activation, könnte den Interessierten das Testen des Produkts zu kompliziert erscheinen (beispielsweise aufgrund einer langwierigen Registrierung oder verpflichtender Software-Downloads). Bei Freemium- Geschäftsmodellen gibt es häufig gute Retention-Werte, aber zu wenig Revenue (Umsatz) ein Hinweis darauf, dass die kostenlose Basisversion zu großzügig gestaltet wurde und die AnwenderInnen keinen Grund sehen, auf die kostenpflichtige Premiumversion upzudaten. [vgl. (Maurya, 2012, p. 89f)] Für den Dienst des Autors könnte man folgende Pirate Metrics Kennzahlen definieren: Acquisition: Anzahl Besuche Website Activation: Anzahl der Anmeldungen für die kostenlose Basisversion Retention: Anzahl der hochgeladenen Bilder Revenue: Anzahl der NutzerInnen für die kostenpflichtige Premium-Version Referral: Anzahl der Einladungen an Dritte zur Nutzung des Online-Dienstes Unfairer Vorteil (unfair advantage) Maurya definiert einen unfairen Vorteil als eine Eigenschaft, die nicht einfach kopiert oder gekauft werden kann. Sollte sich die Produktidee des/der EntrepreneurIn als erfolgreich erweisen, muss diese/r den unfairen Vorteil ausspielen, um sich gegen finanziell besser gestellte Konkurrenzunternehmen zu wehren, welche die Idee kopieren wollen. Als Beispiele für unfaire Vorteile führt er Insider-Informationen, persönliches Charisma, eine etablierte Kundencommunity oder gute Suchmaschinen-Platzierungen an. [vgl. (Maurya, 2012, p. 90)] 51

52 Der Autor könnte folgende unfaire Vorteile mitbringen: gute Kontakte in die lokale Fotografie-Community für die Umsetzung nützliches KnowHow aus GIS-Branche (Web-Kartendienste) 3.5 Der Plan A als Lean Canvas Zusammengefasst sieht der Lean Canvas für den Online-Dienst des Autors wie folgt aus: Abbildung 19: Der Plan "A" als Lean Canvas (Maurya, 2012, p. 66) 52

53 4 Test des Plan A Der Plan A des Autors wurde zwar nun umfassend in einem Lean Canvas dokumentiert, dieser Plan enthält aber zahlreiche ungeprüfte Annahmen: sieht die Zielgruppe tatsächlich einen zwingenden Nutzen in der Produktidee? Verspürt sie die Probleme tatsächlich in der angenommenen Dringlichkeit? 4.1 Testen der Produktidee durch Problem Interviews Zum Testen des Plan A, des Erstenwurfs der Produktidee, sieht die Lean-Canvas-Methode die Befragung potentieller Kunden und Kundinnen im Rahmen von problem interviews vor. Diese etwa einstündigen, überwiegend aus offenen Fragen bestehenden Interviews dienen der qualitativen Validierung der Produktidee. Der/die EntrepreneurIn versucht also nicht, eine möglichst große Anzahl an geeigneten Personen zu interviewen, sondern konzentriert sich auf etwa sechs bis acht Kandidaten, die möglichst repräsentativ für die angedachte Zielgruppe sind und Produktinnovationen zumindest wohlwollend gegenüberstehen den klassischen early adopter. Im folgenden Abschnitt werden weitere wichtige Überlegungen im Hinblick auf die Durchführung von problem interviews vorgestellt Vorüberlegungen Die Bauen-Messen-Lernen-Feedbackschleife Abbildung 20: Erfolgskriterien der Bauen-Messen-Lernen Feedbackschleife nach Ries (Maurya, 2012, p. 109) Die von Eric Ries entwickelte und in Kapitel 2.2 vorgestellte Bauen-Messen-Lernen-Feedbackschleife ist nach Maurya ein zentrales Element bei der Konzeption von problem interviews. Die ausformulierte oder schon teilweise umgesetzte Produktidee ( Bauen ) wird 53

54 mittels der im Lean Canvas aufgestellten Hypothesen bewertet ( Messen ) und aufgrund des Feedbacks angepasst ( Lernen ). Problem interviews sind also keine Verkaufsgespräche, sondern dienen folgenden Zielen [vgl (Maurya, 2012, p. 107)]: Effektives Lernen: Der/die EntrepreneurIn sollte die nötigen Lektionen in Bezug auf die Konzeption des Produktes und seine Vermarktung möglichst rasch und mit wenig Aufwand lernen. Dabei getroffene Fehlannahmen (z.b. im Hinblick auf die Zielgruppe oder die Funktionalität des Produkts) sollten möglichst schnell zutage treten. Für effektives Lernen ist es unerläßlich, vom Erfahrungsschatz der Befragten zu profitieren. Im Vordergrund des Interviews steht daher nicht die neue Produktidee, sondern die bisherigen Erfahrungen und Herangehensweisen der befragten Personen im Anwendungsbereich des künftigen Produkts. Fokussierierung der Produktidee: Wie Abbildung 21 zeigt, sind Ideen in der Frühphase der Produktentwicklung tendenziell zu weit gefasst: auf die einfache Grundidee, Filme im Internet gegen Entgelt zu vertreiben, passen dutzende, grundverschiedene Ausführungen. Dies beweisen die in diesem Bereich tätigen Internet- Unternehmen Netflix, Google, Bittorrent oder Vimeo, die sich in Bezug auf den vertriebenen Content (Hollywood-Produktionen versus von Nutzern produzierte Filme) oder den Vertriebskanal (zentrale Cloud-Server versus dezentrale Peer-To-Peer Netzwerke) unterscheiden. Der/die EntrepreneurIn sollte die problem interviews daher nutzen, um sich auf mehrheitlich positiv beurteilte Aspekte der Produktidee zu fokussieren und die weitere Entwicklung so zu konkretisieren. Geschwindigkeit: Der/die EntrepreneurIn verfügt nur eine beschränkte Menge an zeitlichen und finanziellen Mitteln zur Umsetzung der Idee. Lean Canvas verfolgt das Ziel, die Bauen-Messen-Lernen Schleife innerhalb dieses Zeitraums möglichst oft zu durchlaufen, um die Erfolgswahrscheinlichkeit der Ideenumsetzung zu erhöhen. Die problem interviews sollten daher möglichst rasch und über einen kurzen Zeitraum hinweg durchgeführt werden. Daher sind eine gute Terminplanung und die zeitnahe Verfügbarkeit der Befragten wichtige Erfolgskriterien für problem interviews. 54

55 Abbildung 21: Ideenlabyrinth - auf eine "Grobidee" passen dutzende, grundverschiedene Ausführungen (Srinivasan & Pande, 2013) Risikopriorisierung Als Entwickler eines neuartigen Produkts ist der/die EntrepreneurIn mit vielen Risiken konfrontiert. Die Produktidee kann an konzeptionellen Mängeln, fehlender Nachfrage oder zu schwieriger Kundenakquise scheitern. Maurya empfiehlt daher, bereits in der Phase vor den problem interviews mit einer einfachen Risikopriorisierung zu beginnen und die drängendsten Gefahren in den Interviews gezielt anzusprechen. Das Feedback der Interviewpartner erleichtert dann die Einschätzung der Risken oder kann sie bestenfalls aus dem Weg räumen. Unter dem Begriff Risiko wird gemeinhin ein möglicherweise eintretendes Ereignis mit unerwünschtem Ausgang verstanden. Die internationale Industrienorm ISO definiert Risiko als das Produkt der Eintrittswahrscheinlichkeit eines Ereignisses und dessen negativer Konsequenzen, die in verschiedenen Zielgrößen quantifiziert werden können. Da in der Frühphase der Produktentwicklung oft die nötigen Erfahrungswerte für die Quantifizierung der Risiken fehlen, verwendet Lean Canvas eine vereinfachte Risikopriorisierung anhand dreier Risikoarten: Produktrisiko: Löst das Produkt tatsächlich ein drängendes Problem potentieller Kunden? Wenn ja, kann es unter den gegebenen finanziellen, personellen und technischen Rahmenbedingungen so umgesetzt werden, dass es den Kundenanforderungen entspricht? Akquisitionsrisiko: Wer genau ist die Zielgruppe des Produkts? Kann sie mit den gegebenen Mitteln in ausreichender Zahl erreicht werden? 55

56 Marktrisiko: Lässt sich mit dem Produkt ein rentables Geschäftsmodell aufbauen? Wie sieht die Konkurrenzsituation am Markt aus? Bei der Identifizierung von Risiken ist es wichtig, zwischen diesen und gewöhnlichen Unsicherheiten zu unterscheiden. Abbildung 22 ordnet diese Risiken den Lean Canvas-Feldern zu. Nach Analyse seines Lean Canvas kommt der Autor zum Schluss, dass bei seinem Online-Dienst das Produktrisiko am größten ist. Angebot und Marktanteil der im weitesten Sinne konkurrierenden Photosharing-Dienste ist bekannt, das Alleinstellungsmerkmal RAW-Entwicklung wurde bei der Konkurrenzrecherche in Kapitel 3.3 bestätigt. Durch gute Kontakte zu Fotoschaffenden im deutschen Sprachraum erscheint auch das Akquisitionsrisiko verkraftbar. Beim Produktrisiko bleiben allerdings sowohl bei der technischen Umsetzbarkeit als auch beim Nutzen für die Kundinnen und Kunden einige Fragezeichen: kann die Lösung wie im Erstentwurf der Idee (Kapitel 3.3.1) umgesetzt werden? Wenn nein, welche Adaptionen sind mit welchem Aufwand erforderlich? Werden die Kunden funktionelle Einbußen (weniger Bearbeitungsfunktionen im Vergleich zu Desktop-Programmen) zugunsten der gewonnenen Flexibilität und Datensicherheit (Bedienung im Webbrowser, Datenspeicherung in der Cloud) in Kauf nehmen? Daher wird dem Produktrisiko im Aufbau der folgenden problem interviews besondere Beachtung geschenkt. Abbildung 22: Die Risikoarten und ihre Entsprechung im Lean Canvas [Quelle: (Maurya, 2012, p. 121)] 56

57 Qualitative versus Quantitative Validierung Wie bereits in der Einleitung zu diesem Kapitel erwähnt, empfiehlt Maurya eine qualitative Validierung der Produktidee in der Frühphase der Entwicklung. Erst nachdem sich ein product/market-fit abzeichnet, also eine klare Übereinstimmung des Produktes mit den Bedürfnissen des Marktes, kann die Idee mit einer quantitativen Validierung weiter verbessert werden. Maurya stützt seine Herangehensweise auf eine Feststellung des US-Statistikprofessors Douglas W. Hubbard: If you have a lot of uncertainty now, you don t need much data to reduce uncertainty significantly. When you have a lot of certainty already, then you need a lot of data to reduce uncertainty significantly. (Hubbard, 2010, p. 110) Demnach reichen in einem Szenario mit vielen Unsicherheiten wenige Messwerte aus, um diese Unsicherheiten signifikant zu reduzieren, was für eine qualitative Validierung spricht. Erst wenn in einem Szenario relativer Sicherheit diese signifikant gesteigert werden soll, ist eine Vielzahl von Messwerten erforderlich. Maurya nennt eine Mindestzahl von fünf problem interviews, um eine Produktidee sinnvoll bewerten zu können. Er bezieht diese Anzahl aus einer Studie des User-Experience-Spezialisten Jacob Nielsen, wonach fünf Testpersonen bis zu 85% der Konzeptionsfehler einer grafischen Benutzeroberfläche erkennen können. Mehr Testpersonen können diesen Wert nur mehr unwesentlich steigern, weshalb angesichts knapper Projektbudgets von größeren Testteams abgesehen werden soll. (Nielsen, 2000). Als Konsequenz dieser Aussagen wählte der Autor sechs professionelle Fotografen aus seinem Bekanntenkreis als Interviewpartner aus. Diese haben einen Output von mehr als 500 Bildern im Monat, der Großteil von ihnen leitet Fotokurse im universitären Umfeld Aufbau und Ablauf der Problem Interviews Die problem interviews folgten dem von Maurya in (Maurya, 2012, p. 138ff) empfohlenen Aufbau und gliedern sich in einen kurzen, demografischen Teil und den Hauptteil, der die angenommenen Probleme der Zielgruppe mit der Entwicklung von RAW-Fotos untersucht. Die Interviews wurden von Juli bis September 2013 in Form von persönlichen Gesprächen durchgeführt, Abschriften der Gespräche finden sich im Anhang dieser Arbeit. 57

58 Demografische Fragen dienen der Erfassung einiger nützlicher statistischer Parameter (z.b. der Aktivitätsgrad des Fotografen in Form der pro Monat erstellten Bilder) und geben überblicksmässig darüber Auskunft, welche Produkte/Technologien von den Fotografen eingesetzt werden. Besitzen Sie eine digitale Spiegelreflex-Kamera? Wenn ja, um welches Modell handelt es sich? Wieviele Fotos schießen Sie damit im Monat? Fotografieren Sie im RAW oder JPEG-Format? Welche der folgenden Tools verwenden Sie zum Bearbeiten Ihrer Fotos (Google Picasa, Adobe Lightroom, div. andere Tools) Welche der folgenden Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? (Flickr, Picasa, 500px,...) Feedback-Fragen zu den angenommenen Problemen. Die Interview-Partner wurden gebeten, die Dringlichkeit jedes Problems einzustufen ( Wie wichtig ist eine Lösung des Problems für Sie? ) und in freier Form zu dem Problem Stellung zu nehmen: Cloud-Backup der Fotos (die sonst nur auf einem Heimrechner gesichert sind) Bilder direkt aus der Cloud an Druckdienstleister weiterleiten, kein separater Upload Hochauflösende Bilder auf mobilen Endgeräten betrachten HighRes-Bilder online verkaufen oder für einen guten Zweck / creative commons bereitstellen Ergebnisse der Problem Interviews Die Cloud-Backup-Funktion für RAW-Bilder wurde ausdrücklich von allen Befragten begrüsst. Allerdings haben die Interviewten angeregt, die Backup-Funktion nicht nur auf RAW-Bilder zu beschränken: nach seiner Entwicklung und Bearbeitung kann ein RAW-Bild nicht mehr als solches gespeichert, sondern muss in ein RGB-Bild 37 überführt werden. Da eine Nachbearbeitung vor der Veröffentlichung eines Bildes häufig erforderlich ist (insbesondere Retusche), wäre der Nutzwert des Dienstes stark eingeschränkt, wenn er nur reine RAW-Bilder akzeptieren würde. Folgende Rahmenbedingungen wurden für den Backup-Dienst genannt: o Vertrauenswürdiger Anbieter (NSA-Problematik) 37 In einem RGB-Bild werden für jeden Pixel die Farbwerte Rot, Grün und Blau gespeichert, in einem RAW-Bild enthält ein Pixel nur jeweils einen dieser Farbwerte. Die fehlenden Werte werden beim Entwicklungsvorgang durch Interpolation berechnet. 58

59 o Performante Anbindung (keine signifikante Verzögerung im Vergleich zur Bearbeitung in einem Desktop-Programm) o Postalische Übermittlung größerer Datenmengen o Hohe Ansprüche an Datensicherheit o Zukunftssicherheit (RAW-Formate sind proprietär und werden vom Anbieter manchmal eingestellt, ein Online-Dienst sollte sie automatisch in ein zukunftssicheres Rohdatenformat wie DNG konvertieren) Den mobilen Zugriff auf hochauflösende Bilder bzw. die Freigabe dieser Bilder an ausgewählte User sehen die Befragten als zweitwichtigstes Feature. Für die mobile Präsentation der Bilder verwenden einige der Befragten derzeit Dropbox und andere Dateisynchronisationsdienste, die von Lightroom aus mit heruntergerechneten JPEG-Versionen der RAW-Dateien bestückt werden. Wichtig ist allen Befragten, dass nie originale RAW-Dateien zum Download durch Dritte freigegeben werden dürfen, sondern nur fertig bearbeitete Bildversionen. Andernfalls wäre dies ein Eingriff in die künstlerische Freiheit. Der Idee, RAW-Bilder im Internet zu verkaufen, stehen die Befragten eher zurückhaltend gegenüber. Erstens kommen dafür nur sogenannte Stock-Photos infrage neutrale, auf Vorrat (stock) produzierte Fotos, die häufig nachgefragte Motive zum Inhalt haben. Bei Auftragsfotos (z.b. Fotodokumentation eines Events) entfällt diese Möglichkeit. Zweitens gibt es schon zahlreiche etablierte Plattformen für Stock Photos. Drittens würde keiner der Befragten die originale RAW-Datei verkaufen, sondern stets die bearbeitete RGB-Version des Bildes. Denkbar wäre aber für viele Befragte ein Bestellportal für Auftragsfotos, das nach einem Login die bestellten Fotos des Auftraggebers oder der Auftraggeberin in voller Auflösung anzeigt und ihm die Möglichkeit der Nachbestellung gegen Entgelt gibt. Die Darstellung in voller Auflösung erhöht das Vertrauen, durch die Kachelung des Bildes wird verhindert, dass der/die BestellerIn das Bild ohne Bezahlung abspeichert. Die Online-Bearbeitung von RAW-Fotos wird von den meisten Befragten skeptisch gesehen, sie glauben nicht, dass ein Online-Dienst die Funktionen in der Qualität der führenden Programme Adobe Photoshop und Adobe Lightroom anbieten kann, da es viele technische Fragezeichen gibt (z.b. Farbmanagement im Browser, identische Algorithmen,...). Bei mobilen Bearbeitungsgeräten wie Tablets und Smartphones wird dieses Problem sogar noch verstärkt, da es keine Möglichkeit gibt, eine Farbkalibrierung des Displays vorzunehmen. Aus Energiespargründen wird die Helligkeit des Displays meist nach kurzer Inaktivität herunter geregelt, was die Bildbeurteilung zusätzlich erschwert. Für etwa 25% der Befragten wäre aber eine Art kollaborative Bildbearbeitung für Digitalfotos interessant, bei der UserInnen bestimmte RAW-Bilder zur Bearbeitung freigeben ( zeige mir, was du 59

60 aus meinem Foto machen kannst ) die Bearbeitung selbst würde dann aber in Desktop-Bildbearbeitungsprogrammen wie Adobe Lightroom stattfinden. Das interessanteste Ergebnis des demografischen Frageteils: Alle Befragten verwenden (nahezu) ausschließlich Adobe Lightroom zum Verwalten ihrer Fotos und wünschen die Einbindung des Online-Dienstes über ein Plugin. 4.2 Abgleich der Kundenerwartungen mit den technischen Rahmenbedingungen Die im vorigen Abschnitt durchgeführten problem interviews haben gezeigt, dass Kunden und Kundinnen zwar die Flexibilität einer browserbasierten RAW-Bildbearbeitung und die sichere Archivierung ihrer Bilder in der Cloud schätzen, dafür aber keine Performance- Nachteile in Bezug auf Desktop-Bildbearbeitungsprogramme in Kauf nehmen wollen. Dies betrifft insbesondere das potentielle Nadelöhr des Datei-Uploads, mit dem die RAW-Bilder vom Rechner des Users oder der Userin auf die Cloud-Server übertragen werden müssen. Der enorme Funktionsumfang von Desktop-Produkten wie Adobe Photoshop oder Adobe- Lightroom stellt ein zusätzliches Problem dar die Befragten schätzen diesen sehr, aber es ist fraglich, ob er sich mit für den Autor verfügbaren Grafikbibliotheken nachprogrammieren lässt. In diesem Kapitel sollten daher die technischen Rahmenbedingungen, die dem Autor zur Verfügung stehen, mit den geäußerten Kundenanforderungen abgeglichen werden. Am Ende des Abgleichs steht die Entscheidung, ob die ursprüngliche Produktidee in dieser Form weiterverfolgt werden kann oder abgeändert werden muss Upload-Geschwindigkeit als potentieller Flaschenhals Für einen datenbasierten Online-Dienst wie Trelew ist die erzielbare Upload-Geschwindigkeit vom Rechner des Anwenders oder der Anwenderin zu den Servern des Dienstes von hoher Relevanz. Erst wenn die hochgeladene RAW-Datei dort einlangt, kann mit der Bearbeitung des Bildes begonnen werden. In den problem interviews deuteten die Befragten mehrfach an, diese Upload-Dauer mit der Ladedauer des Bildes in einem Desktop-Bildbearbeitungsprogramm zu vergleichen. Ergeben sich hier signifikante Unterschiede, wird die Attraktivität des Online-Dienstes leiden. Erzielbare Upload-Geschwindigkeit in Österreich Zur Messung der in Österreich erzielbaren Upload-Geschwindigkeit wurde der Ookla Netindex (Ookla, 2013) herangezogen. Dieser browserbasierte Test bewertet weltweit die Qualität der Internet-Anschlüsse diverser Internet Service Provider (ISPs). Er wird von den Kundinnen und Kunden der ISPs durchgeführt, indem sie sich auf die Testportale speedtest.net und pingtest.net begeben. Beim Test verbindet sich der Browser mit einem Server, der geographisch möglichst nahe am Standort des Providers liegt. Auf diese Weise ist es 60

61 möglich, die Geschwindigkeit der letzten Meile (die vom Provider betriebene Netzwerkinfrastruktur vom lokalen Rechner zum Internet) möglichst exakt zu messen. Der Test misst dabei 3 Größen: Verbindungsgeschwindigkeit zum Testserver (Ping-Wert) Download-Geschwindigkeit (Daten werden vom Testserver heruntergeladen) Upload-Geschwindigkeit (Daten werden auf den Testserver hochgeladen) Im ebenfalls von Ookla betriebenen netindex werden die Werte eines Landes zusammen geführt. Für Österreich ermittelt der netindex eine durchschnittliche Upload-Geschwindigkeit von 3,94 Mbps (Megabit pro Sekunde). Dies entspricht etwa 0,5 Megabyte Datentransfer pro Sekunde. Die durchschnittliche Uploaddauer einer RAW-Datei würde bei einer angenommenen Dateigröße von 23MB 38 also etwa 43 Sekunden betragen. Vergleich mit der Ladeperformance von Desktop-Bildbearbeitungen Ein von Usern und Userinnen im Adobe Camera RAW Forum durchgeführter Performance- Test 39 erlaubt einen Vergleich mit den Ladezeiten für ein RAW-Bild im Desktop- Bildbearbeitungsprogramm Adobe Photoshop Version CS6 in Verbindung mit dem integrierten RAW-Konverter Adobe Camera RAW 7. Je nach Hardware-Ausstattung benötigte die Software 3,6 8 Sekunden, um ein lokal vorhandenes RAW-Foto zu öffnen und in voller Auflösung darzustellen. In den problem interviews haben die Interviewten angemerkt, dass der Online-Dienst RAW-Bilder in ähnlicher Geschwindigkeit öffnen sollte wie ein Desktop-Programm. Ein erster Vergleich zeigt, dass aber mit der mindestens zehnfachen Ladezeit zu rechnen ist, zumal die Zeit für die Prozessierung der RAW-Bilder am Server noch nicht einkalkuliert wurde. Im folgenden Kapitel soll daher untersucht werden, ob die Upload-Dauer von RAW- Bildern durch vorherige Kompression signifikant verringert werden kann Beschleunigter Upload der RAW-Photos durch vorherige Kompression Eine Möglichkeit, um die lange Uploaddauer für RAW-Dateien zu verkürzen, besteht in der vorherigen Kompression der Daten. Hierbei ist zwischen verlustfreien und verlustbehafteten Kompressionsverfahren zu unterscheiden. Erstere können die Ausgangsdaten bei der Dekompression bytegenau wieder herstellen, erzielen aber schlechtere Kompressions- 38 entspricht der gemittelten Dateigröße der RAW-Dateien in (Busch, 2013) 39 siehe 61

62 grade. Zweitere verwerfen gezielt Informationen, die vom menschlichen Auge schlecht oder gar nicht wahrgenommen werden können und liefern wesentlich bessere Kompressionsverhältnisse, wobei aber ein Datenverlust in Kauf genommen werden muss. In Kapitel wurden mit DNG und Lossy DNG bereits zwei Vertreter von RAW- Kompressionsformaten vorgestellt. In diesem Kapitel sollen alternative Verfahren analysiert werden. Verlustfreie Kompression Im Camera RAW Compression Benchmark (Busch, 2013) untersuchte Stephan Busch 16 verschiedene Softwareprogramme zur verlustfreien Kompression von Camera RAW-Dateien. Einige der Kompressionsprogramme waren speziell auf RAW-Dateien ausgerichtet, andere dienten der allgemeinen Datenkompression. Als Testdaten dienten 25 Camera RAW-Bilder der Kamerahersteller Canon, Fujifilm, Leica, Nikon, Olympus, Panasonic, Pentax, Samsung, Sigma und Sony. Diese wiesen eine durchschnittliche Dateigröße von 23 Megabyte auf, insgesamt lagen 577 MB an RAW-Daten vor. Das Kompressionstool RawSpeedCmp3 konnte im Verbund mit den Tools precomp und qpaq den höchsten Kompressionsgrad erzielen und die Dateigröße um durchschnittlich 30% reduzieren. Allerdings sind für den Kompressions- und Dekompressionsvorgang jeweils ca. 52 Sekunden pro Datei zu veranschlagen. Etwas besser schneidet die Variante RawSpeedComp3/Precomp/DCGA ab, die zwar nur 26,4% Kompression bietet, dafür aber nur 8,2 Sekunden pro Datei benötigt. Der erzielbare verlustfreie Kompressionsgrad bei einer RAW-Datei beträgt also durchschnittlich 30%, bei einer gemittelten Dateigröße von 23 Megabyte pro RAW- Datei würden also 17,6 Megabyte Uploadvolumen anfallen. Dies entspräche 36 Sekunden durchschnittlicher Upload-Zeit. Verlustbehaftete Kompression Um einen Vergleichswert für verlustbehaftete RAW-Kompression zu erhalten, wurden die RAW-Daten aus dem Benchmark mit den in Kapitel vorgestellten Lossy-DNG-Verfahren komprimiert. Hierfür wurde der frei erhältliche Adobe DNG Konverter 7.3 verwendet, wobei folgende Einstellungen zur Anwendung kamen: Kompatibilität: Camera RAW 6.6 und neuer Keine JPEG-Vorschau Verlustreiche Komprimierung anwenden, Anzahl der Bildpixel beibehalten. Die Eingangsdatenmenge von ca. 532 Megabyte konnte so auf 180 Megbyte komprimiert werden, was einer Speicherersparnis von 67 % entspricht. Der erzielbare verlustbehaftete Kompressionsgrad bei einer RAW-Datei beträgt durchschnittlich 67%, bei einer gemittelten Dateigröße von 23 Megabyte pro RAW- 62

63 Datei fallen 7,59 Megabyte Upload-Volumen an. Dies entspricht 15,18 Sekunden Upload-Zeit Echtzeit-Processing der RAW-Bilder am Server Nach dem Hochladen der RAW-Dateien auf die Server des Online-Dienstes müssen diese auch noch von einem RAW-Konverter prozessiert werden, um kameraspezifische Abbildungsfehler zu korrigieren und ein RGB-Bild zu erhalten. Die dafür nötigen Bearbeitungsschritte wurden bereits in Kapitel erläutert. Nun stellt sich die Frage nach dem dafür nötigen Rechenaufwand. Die RAW-Konvertierung muss pro Bild zumindest einmal nach dessen Upload durchlaufen werden. Ändert der Benutzer oder die Benutzerin aber grundliegende RAW-Parameter wie beispielsweise den Interpolationsalgorithmus oder das Linsenprofil, könnte eine wiederholte Prozessierung erforderlich werden. Der Zeitaufwand für diese Verarbeitung soll wiederum anhand vorhandener Benchmark-Daten abgeschätzt werden. Benchmark-Tests zum Processing von RAW-Bildern dcraw ist ein kommandozeilenbasierter RAW-Konverter, der unter einer OpenSource- Lizenz steht. Er bietet sich für die Verarbeitung der RAW-Bilder am Server an, da er keine grafische Benutzeroberfläche erfordert und über Kommandozeilenparameter gut fernsteuerbar ist. Ähnlich wie der Adobe RAW-Konverter wird das Programm laufend um neue RAW-Formate erweitert. Die Phoronix Open Benchmark Suite, eine Sammlung von Performancetests zur Beurteilung der Leistungsfähigkeit verschiedener Linux-Systeme, enthält auch einen Test, der die Dauer von RAW-Konvertierungen mit dcraw misst. Da bereits eine Vielzahl von Linux-Serversystemen mit dieser Benchmark-Suite getestet wurden, kann der zeitliche Rechenaufwand für die serverseitige Raw-Konvertierung relativ genau abgeschätzt werden. Für die acht zu konvertierenden RAW-Bilder benötigten die ausgewählten Server der Cloud-Anbieter Amazon, Rackspace und Joyent je nach Hardware-Ausstattung zwischen 25 und 50 Sekunden, was einer Konvertierungsdauer pro Bild von 3 bis 6 Sekunden entspricht. 63

64 Abbildung 23: Dauer des dcraw-konvertierungsvorgangs auf verschiedenen Cloud-Servern Experten-Interview zur Problematik des Echtzeit-Processing Die im vorigen Abschnitt ermittelte Konvertierungsdauer für RAW-Dateien nimmt sich neben den relativ langen Upload-Zeiten zwar bescheiden aus, doch nach derzeitigem Wissensstand des Autors ist unklar, wie oft diese Konvertierung beim Bearbeiten der RAW- Bilder durchlaufen werden muss. Wenn jede unwesentliche Einstellungsänderung eine neue, mehrsekündige RAW-Konvertierung erfordert, würde dies die Nutzbarkeit des Online-Dienstes stark einschränken. Zur Klärung dieser Frage hat der Autor mit dem Softwareentwickler Klaus Post ein Experten-Interview geführt. Klaus Post ist Entwickler der OpenSource-Programme RawStudio (Bearbeitungsprogramm für Camera RAW-Dateien) und RawSpeed (Programmbibliothek zum beschleunigten Einlesen von Camera RAW-Dateien), das Interview wurde per zwischen und durchgeführt. 64

65 Frage: Welche Besonderheiten müssen bei der Verarbeitung von Camera RAW-Dateien im Vergleich zu anderen Bildformaten wie JPEG berücksichtigt werden? Klaus Post: RAW-Bilder ähneln den analogen Filmnegativen: sie definieren kein eindeutiges visuelles Abbild der in ihnen enthaltenen Information. Der Bildbearbeiter muss sie erst entwickeln und mehrere, teilweise interaktive Bearbeitungsschritte durchführen, um eine RAW-Datei am Computerbildschirm darstellen zu können. Im Unterschied dazu kann eine JPEG-Datei ohne Zutun des Anwenders sofort am Computerbildschirm dargestellt werden. Frage: Welche Bearbeitungsschritte sind das? Klaus Post: Zuerst erfolgt die Dekodierung der RAW-Datei, d.h. in ihrer Datenstruktur der muss das Graustufenbild der Sensordaten lokalisiert und extrahiert werden. Oftmals liegen die Sensordaten auch komprimiert vor, sodass sie vor ihrer Weiterverarbeitung dekomprimiert werden müssen. Der nächste Schritt ist das sogenannte Demosaicing. Die meisten Kameras können pro Sensorpixel nur einen Farbwert aufzeichnen, entweder Rot, Grün oder Blau. Um für jeden Pixel die nötige RGB-Information zu erhalten, werden die fehlenden Farbwerte durch Interpolation berechnet, wofür es mehrere Algorithmen gibt. Das Demosaicing ist häufig der Flaschenhals bei der RAW-Darstellung. Frage: Warum ist das Demosaicing so performance-intensiv? Klaus Post: Das liegt einerseits an der Vielzahl der Rechenoperationen, die für jeden Sensorpixel ausgeführt werden müssen. Die meisten Demosaicing-Algorithmen analysieren die Umgebung des Pixels, um möglichst gute Farbwerte zu interpolieren. Nur so ist gewährleistet, dass kontrastreiche Übergänge an den Kanten von abgebildeten Objekten erhalten bleiben. Ein Beispiel: Mein Testsystem kann 35 Megapixel des RAW-Formats Olympus ORF pro Sekunde dekodieren und das ist das mit Abstand langsamste Format. Beim Demosaicing kam keines der RAW-Formate auf über 20 Megapixel pro Sekunde. Frage: Gibt es Möglichkeiten, das Demosaicing zu beschleunigen? Klaus Post: Eine Möglichkeit ist die Verwendung genügsamerer Demosaicing-Algorithmen, die weniger Rechenoperationen benötigen, was aber zulasten der Bildqualität geht. Frage: Was sind nach Decoding und Demosaicing die nächsten Schritte im RAW- Decoding-Workflow? Klaus Post: Als nächstes folgt die Objektivkorrektur, also Abbildungsfehler, die durch nicht vermeidbare optische Unzulänglichkeiten der verwendeten Objektive verursacht wurden. Dazu zählen beispielsweise Verzerrungen (distortion), chromatische Aberationen (Farbsäume an kontrastreichen Übergängen) oder Vignettierungen (Abdunkelungen an den Rändern des Fotos durch verminderten Lichteinfall). Diese Abbildungsfehler werden für 65

66 jedes Objektivmodell durch verschiedene Testverfahren eruiert und in Objektivprofilen gespeichert. Da das verwendete Objektivmodell in den meisten Fällen auch in den Metadaten der RAW-Datei gespeichert ist, kann die RAW-Entwicklersoftware mithilfe der Objektivprofile eine automatische Korrektur durchführen. Kommerzielle RAW-Entwicklungsprogramme wie Adobe Lightroom bringen ihre eigenen Objektivprogramme mit, im OpenSource-Bereich stellt das Projekt LensFun 40 sowohl Objektivprofile als auch eine Korrektursoftware für gängige Abbildungsfehler bereit. Bei extremen Lichtsituationen oder der Verwendung nicht-unterstützter Objektivmodelle ist allerdings eine manuelle Korrektur erforderlich. Frage: Nach diesen überwiegend automatisch durchgeführten Operationen wird der RAW-Workflow mit einer Reihe manueller Schritte abgeschlossen, in denen der User die Bildcharakteristik aktiv beeinflussen kann. Welche sind das? Klaus Post: Als nächstes folgt der Weißabgleich (white balance), bei dem die im Bild neutral erscheinenden Farbtöne (weiß, grau oder schwarz) bestimmt werden. Damit lässt sich die Farbtemperatur beeinflussen, ein wichtiges gestalterisches Mittel für jeden Fotografen. Daher wird der Weißabgleich vorzugsweise manuell durchgeführt, auch wenn die Kamera bzw. das RAW-Bearbeitungsprogramm ihn automatisch durchführen kann. Danach folgen Farb- und Tonwertkorrekturfilter, mit denen die Präsenz einzelner Farben oder Kontraste im Bild verstärkt oder abgeschwächt werden kann. Zum Abschluss können je nach Bedarf noch Spezialfilter zum Einsatz kommen, die beispielsweise für Rauschunterdrückung sorgen. Frage: Welche Herausforderungen gibt es aus Ihrer Sicht, wenn man eine webbrowserbasierte Camera RAW-Applikation entwickeln möchte? Klaus Post: Das hängt von den Anforderungen an diese Applikation ab. Ihr Anwendungsfall zielt auf die zentrale Speicherung der RAW-Datei auf einem Webserver und auf die Bearbeitung derselben im Webbrowser ab, wobei nur die für die aktuelle Bearbeitung/Ansicht unbedingt nötigen Daten übertragen werden sollen. In diesem Fall wäre die größte Herausforderung die Aufteilung der bereits beschriebenen Arbeitsschritte zwischen Client (Browser) und Web/Applikationsserver. Man müsste die ersten, eher statischen Workflowschritte Dekodierung, Demosaicing und Objektivkorrektur am Server ausführen und die prozessierten RAW-Daten in einem möglichst schlanken Zwischenformat an den Browser senden. Die dynamischen, vom User stark beeinflussten Schritte Weißabgleich, Farbkorrektur und (optional) Postprocessing-Filter müssten im Webbrowser stattfinden, um eine echtzeitnahe Darstellung der Filtereinstellungen zu gewährleisten. Für die dafür nötige Performance könnte die 3D-Programmierschnittstelle WebGL sorgen, welche in modernen Browsern zur 40 vgl.: 66

67 Verfügung steht. Sie kann auch zur Programmierung leistungsfähiger Grafikfilter genutzt werden. Frage: Kennen Sie Unternehmen oder OpenSource-Projekte, die derartige Applikationen bereits anbieten? Klaus Post: Mir ist das Startup pics.io bekannt, das eine derartige Applikation anbieten möchte. Derzeit durchläuft das Startup die private-beta-phase, nur ein Werbevideo ist öffentlich zugänglich. Daher kann ich den technischen Fortschritt von pics.io nicht beurteilen. Ich selbst arbeite an einem web-basierten RAW-Editor, den ich in absehbarer Zeit auf den Markt bringen möchte. Momentan kann ich über technische Details noch keine Auskunft geben. Frage: Welche Marktchancen sehen Sie für webbasierte Camera-RAW-Applikationen? Klaus Post: Für sich alleine ist ein web-basierter Camera-RAW-Konverter keine Killer Applikation, dafür sind die Upload-Zeiten zu hoch und die Bearbeitungsmöglichkeiten noch zu gering. Betrachtet man ein solches Tool jedoch in einem ganzheitlichen Kontext, beispielsweise als Teil eines digital asset management systems, ergeben sich jedoch interessante Möglichkeiten. Beispielsweise könnte das Fotomaterial einer Organisation über einen zentralen Server zur Verfügung gestellt werden, wo es je nach Berechtigungsstufe (z.b. anonymer Web-User, registrierter Journalist) in verschiedenen Auflösungen downloadbar ist. Der RAW-Konverter könnte die nötigen Umrechnungen in andere Formate on the fly durchführen. Wichtig ist jedoch eine gute Interoperabilität mit existierenden Tools, Bildbearbeitung wird wohl noch eine geraume Zeit in Desktop-Programmen wie Adobe Photoshop durchgeführt werden. Die derzeit verbreiteten lokalen Bildkataloge von Fotomanagement-Applikationen wie Adobe Lightroom führen zu redundanter Speicherung von Bildmaterial und für eine große Organisation wird es schwierig, ihren Fotobestand im Überblick zu behalten. Ein Online-Dienst, der Unternehmen genügend Speicherplatz und Rechenkapazität für das Handling großer RAW-Archive zur Verfügung stellt, hätte meiner Meinung nach gute Marktchancen. 67

68 4.3 Analyse und Diskussion der Problem Interviews Nach ausführlicher Analyse der durchgeführten problem interviews sowie der technischen Rahmenbedingungen hält der Autor ein Umdenken der ursprünglichen Produktidee für erforderlich. Die dafür maßgeblichen Gründe ergaben sich aufgrund der in diesem Kapitel erhobenen Fakten: Die problem interviews ergaben, dass die Befragten die erhöhte Flexibilität eines Online-Dienstes für RAW-Bilder zwar schätzen, aber gleichzeitig die Performance und den Funktionsumfang ihrer bekannten Desktop-Bildbearbeitungsprogramme erwarten. Abschnitt 4.2 zeigt, dass insbesondere das Importieren von RAW-Dateien in einen Online-Dienst viel länger dauern würde als in ein Desktop-Programm. Im Experten-Interview zum Echtzeit-Processing von RAW-Bildern wurde klar, dass die dafür nötige Basistechnologie noch nicht existiert. Der Experte Klaus Post räumt zudem einer Standalone-Lösung zur Online-Bearbeitung von RAW-Bildern nur wenig Marktchancen ein. Dies deckt sich mit den Angaben der Befragten aus den problem interviews, die den Anteil an reiner RAW-Bearbeitung in ihrem Bildbearbeitungsworkflow auf etwa 10% schätzen. Die meiste Zeit wird für die Bearbeitung des bereits konvertierten RGB-Bildes in einer klassischen Bildbearbeitung wie Adobe Photoshop verwendet. Diese Funktionalität müsste ein Online-Dienst demnach auch anbieten, was den Projektumfang um viele Mannjahre vergrößern würde. Im folgendenen Kapitel sollten daher die als positiv beurteilten Aspekte der Produktidee zu einem Plan B verarbeitet werden. 68

69 5 Umsetzung des Plan B Im vorigen Kapitel versuchte der Autor, seine Idee eines Online-Editors für Camera RAW- Dateien zu spezifizieren und im Rahmen von problem interviews sechs ausgewählten Fotografen schmackhaft zu machen. Die zurückhaltende Resonanz der Zielgruppe und einige technische Fragezeichen zwangen den Autor schließlich zum Umdenken seiner Idee. Dieser Umdenkprozess beziehungsweise die Ergebnisse bilden den ersten Teil dieses Kapitels. Der zweite Teil des Kapitels beschäftigt sich mit der Vorbereitung und Durchführung der problem interviews: dabei wird die abgeänderte Produktidee mithilfe eines Prototypen weiter konkretisiert. Nach einer Demonstration des Prototypen urteilen ausgewählte Testuser erneut über die Idee, aus ihrem Feedback werden Rückschlüsse über den Funktionsumfang und die Preisgestaltung des späteren minimum viable products (siehe Kapitel 5.3.7) gezogen. 5.1 Der Pivot als Ideen-Kurskorrektur Zunächst stellt sich natürlich die berechtigte Frage, ob der Autor sein Projekt überhaupt weiterverfolgen sollte. Einzelne Aspekte der Idee wurden von den befragten Fotografen zwar sehr positiv beurteilt und scheinen auch technisch problemlos umsetzbar, aber in seiner Gesamtheit ist der RAW-Online-Editor weder ein nachgefragtes noch ein gut umsetzbares Produkt. Dennoch sprechen einige Fakten für eine Weiterführung des Projektes mit einer geänderten Produktidee: Eric Ries definiert ein Startup als menschliche Institution, die ein neues Produkt oder eine neue Dienstleistung in einem Umfeld extremer Ungewissheit entwickelt (Ries, 2012, p. 32). Diese Ungewissheit betrifft vor allem die Gültigkeit der angenommenen Problemstellung ( Für Fotografen dauert die RAW-Entwicklung in Desktop-Programmen zu lange ) und des Lösungsansatzes ( Online-Editor für RAW-Dateien mit Rechenleistung aus der Cloud ). Solange diese Gültigkeit noch nicht von der Zielgruppe bestätigt wurde und der sogenannte Problem/Solution-Fit noch nicht eingetreten ist, muss der Fokus des Startups auf validiertem Lernen liegen: Einzelne Hypothesen der Produktidee werden solange abgewandelt, bis die Zielgruppe diese bestätigt. Diese Ideen-Kurswechsel werden auch als Pivots bezeichnet (siehe Abbildung 24). Sie sind fester Bestandteil von Lean Canvas. Der/die EntrepreneurIn ist sogar aufgerufen, in der Frühphase des Startups Pivots einzubauen, um einen guten Problem/Solution-Fit zu gewährleisten. Das im vorigen Kapitel vorgestellte Ideenlabyrinth (siehe Abbildung 21) zeigt, dass Ideen in ihrer Frühphase tendenziell zu weit gefasst sind und ein und dieselbe Grundidee durch erforderliche Konkretisierungen in der Konzeptionsphase zu völlig verschiedenen Umsetzungen führen kann. Die vom Autor durchgeführten problem 69

70 interviews ergaben, dass sein angedachter RAW-Editor mit Funktionen für Bildkompression, Echtzeit-RAW-Darstellung, Farbkorrektur, Retusche, Bildexport und Schnellansicht ein technologisch sehr weites Feld abdecken müsste, um den Kundenansprüchen gerecht zu werden. Im Rahmen der Interviews wurde aber auch deutlich, hinter welchen Teilaspekten der Idee die Befragten den meisten Nutzen sahen. Mit einer Konzentration auf den vielversprechendsten Teilaspekt seiner Idee würde der Autor daher einerseits die Umsetzungswahrscheinlichkeit und andererseits die Marktakzeptanz des späteren Produktes erhöhen. Ash Maurya unterteilt die Entwicklung eines Startups in drei Phasen (Maurya, 2012, p. 43): Problem/Solution Fit: in der Frühphase des Startups muss der/die EntrepreneurIn herausfinden, ob die Produktidee tatsächlich ein für die jeweilige Zielgruppe relevantes Problem löst. Product/Market Fit: Wurde das Problem und der Lösungsansatz von der Zielgruppe bestätigt, kann mit der Entwicklung eines Minimum Viable Products (MVP) begonnen werden. Während der Umsetzung des MVP sorgen kontinuierliche Tests mit Beta-Usern dafür, dass es in Bezug auf Funktionsumfang und Preisgestaltung den Bedürfnissen der Zielgruppe entspricht. Scale: Qualitative Interviews und Beta-Tests liefern zwar wertvolle, neue Erkenntnisse, tragen aber wenig zum wirtschaftlichen Erfolg des Startups bei. Nach der Bestätigung des MVP gilt es daher, so rasch wie möglich zu wachsen, um die für die Profitabilität erforderlichen Umsätze zu generieren. Für Maurya steht dabei während der ersten beiden Phasen das validierte Lernen im Vordergrund, bei denen Einzelaspekte der Idee bzw. Funktionen des Mininum Viable Products auf ihre Akzeptanz getestet werden. Dies geschieht durch die im vorigen Absatz erwähnten Pivots. Erst in der letzten Startup-Phase steht das Wachstum im Vordergrund und damit auch die Optimierung der damit verbundenen Prozesse. Abbildung 24: Zielsetzungen eines Startups vor und nach dem Product/Market-Fit (Maurya, 2012, p. 45) 70

71 Für Maurya ist es wichtig, zwischen Pivots und Optimierungen zu unterscheiden. Pivots sind grobe Kurskorrekturen der Produktidee, Optimierungen stellen geringfügige Verbesserungen bereits bestätigter Ideenhypothesen dar: The best way to differentiate pivots from optimizations is that pivots are about finding a plan that works, while optimizations are about accelerating that plan. (Maurya, 2012, p. 45) Häufig gestellte Optimierungsfragen lauten: Wie können wir den Registrierungsprozess verkürzen, sodass sich mehr Kundinnen und Kunden für die Demoversion anmelden? Welche Zahlungsmöglichkeiten sollten wir anbieten, damit ihnen die Bezahlung leichter fällt? Wendet sich der/die EntrepreneurIn vorschnell Optimierungsfragen zu, besteht die Gefahr, große und wichtige Lernschritte zugunsten nebensächlicher Verbesserungen zu versäumen: In order to maximize learning, you have to pick bold outcomes instead of chasing incremental improvements. So, rather than changing the color of your call-to-action button, change your entire landing page. Rather than tweaking your unique value proposition (UVP) for a single customer segment, experiment with different UVPs for different customer segments. (Maurya, 2012, p. 46) 5.2 Durchführung des Pivot Um die Produktidee strukturiert und ohne Schnellschüsse umdenken zu können, empfiehlt Maurya, die Ergebnisse der problem interviews hinsichtlich ihrer Implikationen auf das Produkt-, Akquisitions- und Marktrisiko zu strukturieren. Diese drei Risikoarten wurden im Abschnitt Risikopriorisierung des Kapitels vorgestellt und bezeichnen die Wagnisse, ein tatsächlich nachgefragtes Produkt zu entwickeln, dafür ausreichend Kundschaft akquirieren zu können und in einem profitablen Markt ohne übermächtige Konkurrenz tätig zu werden. Für jede Risikoart wird eine zentrale Eingangshypothese definiert, die durch die problem interviews entweder bestätigt oder verworfen wurde. Die Anregungen der Interviewten wiederrum werden in neuen Hypothesen münden, die im Rahmen des Pivot in die Produktidee aufgenommen werden müssen. Am Ende des Pivot steht also ein aktualisierter Lean Canvas, auf dessen Basis die Prototyp-Entwicklung und die solution interviews durchgeführt werden können. 71

72 5.2.1 Analyse der Produktrisikos Hypothese Die problem interviews werden zeigen, dass die Speicherung und Bearbeitung von Camera RAW-Bildern in der Cloud sowie der browserbasierte Zugriff darauf ein wichtiges Feature für professionelle Fotoschaffende ist. Erkenntnisse aus den problem interviews Die interviewten Fotografen können dem Online-RAW-Editor nur wenig Nutzen abgewinnen, sehen aber großes Anwendungspotential für einen Teilaspekt der Idee: die zeitsparende Darstellung hochaufgelöster Fotos im Web-Browser auf Basis von Kachelbildern. Allerdings gelangt dadurch der Kunde oder die Kundin vorab in Besitz des hochaufgelösten Fotomaterials, ohne entsprechende Zahlungen geleistet zu haben. Der Einbau von Sicherheitsmechanismen wie Wasserzeichen wäre daher erforderlich. Alle Interviewten haben Interesse an Produktfunktionen, welche die Veröffentlichung ihres Bildmaterials beschleunigen könnten. Viele Aufnahmen entstehen auf Veranstaltungen oder Reisen, daher wurde insbesonders Interesse an Features angemeldet, die die Uploadzeit von Bildern auch über schlechte Internetverbindungen verkürzen. Alle Befragten sehen sich häufig mit Anfragen von Kundinnen und Kunden konfrontiert, bei denen einzelne Aufnahmen aus vergangenen Aufträgen nachbestellt werden. Diese Anfragen sind zwar sehr profitabel, stellen aber meist einen manuellen, fehlerbehafteten Prozess dar. Die Nachbestellungen werden oft über abgewickelt, als häufigste Fehlerquelle entpuppen sich fehlerhaft angegebene Identifikationsnummern für die Bilder bzw. zu niedrige Empfangslimits für s auf Kundenseite. Neue Hypothesen Kunden und Kundinnen von Fotoschaffenden würden gerne hochaufgelöste Vorschaubilder betrachten, scheuen aber große Downloads. Die Fotoschaffenden fürchten die illegale Verbreitung des Bildmaterials. Fotoschaffende möchten ihren Kunden und Kundinnen Bilder möglichst schnell zur Verfügung stellen, auch von Orten mit langsamer Internet-Verbindung. Fotoschaffende wünschen sich eine Automatisierung des fehlerbehafteten Nachbestellprozesses für Bilder. 72

73 5.2.2 Analyse des Akquisitionsrisikos Hypothese Die Zielgruppe des Online-Dienstes sind Fotografen, die regelmäßig Auftragsfotos einer beschränkten Personengruppe online zugänglich machen wollen (Auftragsfotografie) oder neutral produzierte Aufnahmen von Sehenswürdigkeiten, Alltagssituationen oder Gegenständen an die Allgemeinheit verkaufen wollen ( stock photography ). Erkenntnisse aus den problem interviews Nach einhelligem Feedback der Interviewten werden Fotoschaffende im stock photo - Bereich nicht mehr als Zielgruppe betrachtet, da es für diese Fotografiegattung bereits zahlreiche Plattformen gibt. Außerdem würden Fotoschaffende niemals ihre digitalen Negative verkaufen, sondern nur von ihnen bearbeitete Versionen. Eine potentielle neue Zielgruppe sind Fotoschaffende, die häufig größere Personengruppen fotografieren und deshalb viele Nachbestellungen bearbeiten müssen Analyse des Marktrisikos Hypothese Die problem interviews werden zeigen, dass Fotoschaffende zwar andere Online-Dienste zur Veröffentlichung ihres Bildmaterials nutzen, diese aber aufgrund des geänderten Funktionsumfangs keine Konkurrenz für Trelew darstellen. Erkenntnisse aus den problem interviews Fotoschaffende nutzen Online-Dienste nur zum Veröffentlichen ihrer Bilder und verwenden die dort integrierten Bearbeitungsmöglichkeiten kaum. Die Bearbeitung der Bilder wird in den etablierten Bildbearbeitungsprogrammen Adobe Lightroom und Adobe Photoshop erledigt. Daher stehen sie auch einem Online-Bearbeitungstool für RAW-Dateien sehr skeptisch gegenüber. Die Befragten räumen einem Online-Dienst, der ihren Kunden das einfache und schnelle Betrachten von hochauflösenden Bildern ermöglicht und gleichzeitig das Bestellwesen drastisch vereinfacht, sehr gute Marktchancen ein. 73

74 5.2.4 Aktualisierung der Produktidee Aufgrund der vorangegangenen Analyse ergeben sich folgende Änderungen in der Produktidee: In Trelew können nunmehr nicht nur RAW- oder DNG-Dateien hochgeladen werden, der Dienst steht für hochaufgelöste Bilder aller Formate offen. Als Untergrenze wird eine Bildauflösung von 5 Megapixel festgelegt. Um den Bildupload über langsamere Internet-Verbindungen zu beschleunigen, können Fotoschaffende besonders speichereffiziente Formate wie JPEG XR verwenden, das im Vergleich zu JPEG um bis zu 50% weniger Speicherplatz bei gleicher Bildqualität benötigt. Kunden und Kundinnen von Fotoschaffenden können über eine Menüfunktion gezielt das Original des gezeigten Vorschaubildes anfordern. Diese Menüfunktion kommuniziert mit einem bei dem/der Fotoschaffenden installierten Softwaretool, das automatisch den Upload des richtigen Bildes auf Trelew übernimmt und damit die manuellen Abwicklung der Bestellung obsolet macht. Optional lässt sich eine Bezahlschnittstelle in diesen Prozess integrieren, die den Bilddownload erst freigibt, wenn die dafür vereinbarte Zahlung geleistet wurde. von Trelew heruntergeladene Vorschaubilder bleiben mit den online gehosteten Bildern verknüpft: wird ein heruntergeladenes Bild in den Browser gezogen, erkennt es Trelew und öffnet automatisch die gehostete Version. Damit kann ein Kunde oder eine Kundin jederzeit Bestellungen zu bereits downgeloadeten Vorschaubildern aufgeben. 74

75 Abbildung 25: Aktualisierter Canvas nach durchgeführtem Pivot 5.3 Solution Interviews Während die in Kapitel 4.1 durchgeführten problem interviews einen ersten Abgleich der Produktidee des Innovators mit den Problemen der Zielgruppe zum Inhalt hatten, geht es in den solution interviews um die Konkretisierung einer bereits bestätigten Produktidee. Zudem rückt erstmals das Thema Preisfindung in den Vordergrund. Für Maurya besteht die Ideenkonkretisierung der solution interviews vor allem in der Beantwortung folgender Fragen in Bezug auf die drei Startup-Risiken: Akquistionsrisko: Wer genau sind die potentiellen early adopter des Produkts? (Weitere Präzisierung der Zielgruppe aus den problem interviews, beispielsweise eine Verfeinerung der Zielgruppe Fotoschaffende mit DSLR auf Fotoschaffende mit mindestens 10 Aufträgen pro Quartal ) Produktrisiko: Was ist der minimale Funktionsumfang, den ein sinnvoll nutzbares Produkt aus Sicht der Kundinnen und Kunden haben sollte? Marktrisiko: Wird die Zielgruppe für das Produkt bezahlen? Wenn ja, welcher Preis ist erzielbar? [vgl.: (Maurya, 2012, p. 157)] 75

76 5.3.1 Einsatz von Prototypen Bei der Durchführung der problem interviews wurde bewusst auf die Erstellung von Prototypen und erklärender Screenshots verzichtet. Dies geschah einerseits, um die Schilderung der Problemstellung aus Sicht des Interviewten in den Vordergrund zu rücken, andererseits, um eine unvoreingenommene Beurteilung der Idee zu ermöglichen. Vor der Durchführung der problem interviews empfiehlt Maurya hingegen die Umsetzung eines ersten Prototyps, um den Interviewten die gefundenen Lösungsansätze besser vor Augen führen zu können. Most customers are great at articulating problems but not at visualizing solutions. (Maurya, 2012, p. 159) Auf den ersten Blick sollte der Prototyp die Befragten also dabei unterstützen, den vom Entrepreneur oder der Entrepreneurin vorgeschlagenen Lösungsansatz zu verstehen und auf dessen Basis nötige Änderungen zu diskutieren. Für ein umfassendes Verständnis wäre aber die Implementierung eines Großteils der vorgesehenen Produktfunktionen erforderlich, was wiederrum den Zeitaufwand für die Erstellung des Prototyps massiv erhöhen würde. Angesichts der Tatsache, dass die Interviewten zum ersten Mal mit dem konkreten Lösungsansatz konfrontiert werden und daher wahrscheinlich umfangreichere Änderungswünsche haben werden, rät Maurya explizit zu schlanken Prototypen: I use the term demo (hier ist der Prototyp gemeint, Anm. d. Verf.) loosely to mean anything that can reasonably stand in for the actual solution. The assumption here is that building the full solution is time-consuming and could lead to waste if you build the wrong solution or add unneeded features. (Maurya, 2012, p. 159) Maurya konkretisiert seine Anforderungen an Prototypen wie folgt: Technologiekongruenz: die für den Prototypen eingesetzten Technologien sollten auch für die Umsetzung des späteren Produkts zur Verfügung stehen. Maurya wendet sich insbesondere gegen den Einsatz von Animationseffekten, die in einigen Rapid-Prototyping-Tools zur Verhübschung der Ergebnisse eingesetzt werden. Bei der tatsächlichen Implementierung des Programms stehen diese nicht mehr zur Verfügung, was zu einem Vertrauensverlust der Befragten führen kann ( in der Demo sah das anders aus ). Realistisches Aussehen: Der Prototyp sollte dem Aussehen des Endprodukts möglichst nahe kommen. Eine bloße Aneinanderreihung skizzenhafter Screenshots (wireframes, siehe Abbildung 26) würde nach Maurya zwar die Umsetzungsdauer des Prototyps massiv senken, den Befragten (und möglicherweise späteren Kun- 76

77 dinnen und Kunden) eine Menge Vertrauen abnötigen ( Ist der Innovator überhaupt in der Lage, dieses Produkt umzusetzen? ). In Bezug auf die Preisfindung, die ebenfalls im Rahmen des Interviews stattfinden soll, ist dieser erzwungene Vertrauensvorschuss sicher nachteilig. Rasch anpassbar: berechtigte Änderungsvorschläge der Interviewten sollten sich noch vor dem nächsten Interviewtermin in den Prototyp einarbeiten lassen. Auf diese Weise kann der Prototyp schnell schrittweise verfeinert werden. Maurya warnt in diesem Zusammenhang vor einem Outsourcing der Prototyp-Umsetzung. Zudem ist bei der Erstellung des Prototyps zu beachten, dass alle Daten in editierbarer Form vorliegen (Bei in Bitmap-Formaten gespeicherten Screenshots lassen sich Format und Position von Texten nur mehr sehr schwer ändern). Minimaler Aufwand: Die größte Herausforderung ist die Erstellung des Prototyps mit minimalem Aufwand. Je schneller der Prototyp umgesetzt und angepasst werden kann, desto schneller können Erkenntnisse gesammelt werden. Vorschnell genommene Abkürzungen können sich dabei später als Bremsklotz entpuppen: es mag anfangs reichen, ein Screendesign im Bildbearbeitungsprogramm Adobe Photoshop anstatt in HTML und CSS umzusetzen, will man später Interaktionsfunktionen demonstrieren, wird aber erst recht eine zeitaufwändige Neuumsetzung in HTML/CSS erforderlich. Der/die EntrepreneurIn ist also aufgerufen, unter Einsatz der vorhandenen Kenntnisse eine optimale Marschroute zu finden. Verwendung authentischer Daten: Prototypen sollten mit authentischen, echt wirkenden Daten bestückt werden, die den demonstrierten Anwendungsfall wirksam illustrieren. Platzhaltertexte wie das bekannte lorem ipsum irritieren den Betrachter und lenken ihn ab. Abbildung 26: Wireframe-Darstellung einer Dialogbox 77

78 5.3.2 Umsetzung des Trelew-Prototyps Bei der Umsetzung des Prototyps für Trelew versuchte der Autor die von Maurya gestellten Anforderungen so gut als möglich umzusetzen. Als erstes wurden aufgrund der Ergebnisse des Pivot (siehe Kapitel 5.2) vier Funktionen ausgewählt, die im Rahmen des Prototyps demonstriert werden sollten: 1. Schnellansicht hochauflösender Bilder im Web-Browser mittels Tiling-Technologie 2. Verkürzung der Upload-Dauer durch Unterstützung speichersparender Bildformate 3. Automatische Abwicklung von Fotobestellung durch Kundinnen und Kunden (Upload der entsprechenden Bilder bei Bedarf) 4. Dauerhafte Verknüpfung downgeloadeter Bilder mit dem Originalbild Sie sollten entsprechend der von Maurya geforderten Prinzipien umgesetzt werden: Um die Technologiekongruenz und ein realistisches Aussehen des Prototyps zu gewährleisten, plant der Autor die direkte Umsetzung aller Features in den Browsertechnologien HTML, CSS und Javascript, die auch im finalen Produkt zum Einsatz kommen werden. Zur Minimierung des Aufwandes für die Prototyp-Erstellung nutzt der Autor die Javascript-Bibliothek jquery sowie das Web-Frontent-Framework Bootstrap. Mit diesen beiden Komponenten lassen sich Web-Oberflächen rasch umsetzen. Eine Sonderstellung nimmt das OpenSource-Framework OpenLayers ein, das an sich zur Darstellung von Kartenwerken im Webbrowser konzipiert wurde. Im Prototyp des Autors ist es für die Tiling-Ansicht der hochauflösenden Bilder verantwortlich. Während dem Autor alle genannten Frameworks aus seiner Tätigkeit als Frontend- Entwickler bekannt sind, betritt er mit der Nutzung des Javascript-Frameworks AngularJS Neuland. Dieses Framework verspricht zwar eine radikale Vereinfachung der clientseitigen Datenhaltung, hat aber eine nicht unerhebliche Lernkurve. Um die Eignung von AngularJS für die Umsetzung des späteren Produkts zu testen, soll es bereits bei der Implementierung des Prototyps zum Einsatz kommen. Um den Umsetzungszeitraum des Prototyps nicht unnötig zu verlängern, wurde auf die Implementierung eines serverseitigen Backends verzichtet. Die Generierung der für Trelew nötigen Kachelbilder und downloadbaren Bildversionen übernahm ein Python-Skript, das die Daten in einer standardisierten Ordnerstruktur ablegte. Die so gewonnenen statischen Demodaten erfüllten aber die von Maurya postulierte Forderung nach Authentizität der Daten. 78

79 Abbildung 27: Demoseite des CSS-Frameworks Twitter Bootstrap Schnellansicht hochauflösender Bilder im Web-Browser Als Ausgangsdaten für die Demonstration der Schnellansicht im Webbrowser nutzte der Autor einige Camera RAW-Bilder in verschiedenen Formaten. Sie wurden durch ein in der Skriptsprache Python implementiertes Konvertierungsskript in das Zoomify-Kachelformat umgewandelt. Hierfür griff das Skript auf die OpenSource-Bibliotheken dcraw (RAW- Konvertierung) und libvips (Umwandlung in das Zoomify-Format) zurück. Die konvertierten Dateien wurden unterhalb eines gemeinsamen Verzeichnisses abgelegt, das über einen Webserver freigegeben wurde. Auf diese Weise konnte der in Javascript implementierte Client auf die Bilddaten zugreifen. Die Darstellung des Bildes erfolgte über das OpenSource-Kartenframework OpenLayers, das auch die Anzeige von Zoomify-Bildern unterstützt. Die den Bildbereich umgebende grafische Benutzeroberfläche erlaubt ein Umschalten zwischen den einzelnen Bildern, sie entstand unter Verwendung der Frameworks Bootstrap und AngularJS. 79

80 Abbildung 28: Der Prototyp der Schnellansicht im Webbrowser Erläuterung der übrigen Features auf einer Marketingseite Da die meisten Interviewten über einen -Link auf den Prototyp zugreifen würden, entschloß sich der Autor, ihm eine Marketingseite voranzustellen, welche die Idee hinter dem Dienst grundsätzlich erklärt und die vier prominentesten Features hervorstreicht. Der Aufbau dieser Seite folgt den in (Srinivasan & Pande, 2013) vermittelten Prinzipien zur Gestaltung von Startup-Marketingseiten. Die Seite wurde in englischer Sprache verfasst und enthält folgende Elemente (siehe Abbildung 29) : 1. Name des Dienstes ( Trelew ) und Slogan ( Download a few Kilobytes. Enjoy a lot of megapixels ), gefolgt von einer kurzen Erklärung des Dienstes selbst 2. Klickbare Fotogalerie (grau hervorgehoben), welche dem User oder der Userin die wesentlichen Features näher bringt. 3. Auflistung der vier prominentesten Features mit kurzen Erklärungstexten: a. Show full Resolution photos on any device : Dieses Feature nimmt Bezug auf die im vorigen Abschnitt vorgestellte Schnellansicht und verlinkt den dort vorgestellten Foto-Viewer. b. Efficient Photo I/O : Verkürzung der Upload-Dauer durch Unterstützung speichereffizienter Bildformate c. Photo Requests : Automatisierte Abwicklung von Fotobestellungen durch Kunden und Kundinnen d. Find By File : Von der Trelew-Seite downgeloadete Bilder öffnen das Originalbild, wenn sie in den Browser gezogen werden, dieses Prinzip wird durch eine Screenshot-Animation verdeutlicht. 80

81 Da die Fertigstellung des Foto-Viewer-Prototyps länger als geplant gedauert hat, entschloß sich der Autor, die übrigen Features nur mit Screenshots zu dokumentieren und von der prototypischen Implementierung dieser Funktionen abzusehen. Neben dem zeitlichen Argument sprachen auch technische Gründe für diesen Ansatz: für eine tatsächliche Demonstration der Upload-Funktionen müsste der/die AnwenderIn die vom Autor bereitgestellte Software auf dem eigenen System installieren, was bei unsachgemäßer Anwendung oder durch unkorrigierte Programmierfehler zu Datenverlust führen könnte. In jedem Fall würde der durch die Bereitstellung der Softwarekomponenten gestiegene Test- und Supportaufwand den Autor in der Weiterentwicklung der Lösung bremsen. 81

82 Abbildung 29: Vollumfänglicher Screenshot der Trelew-Marketingseite 82