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: 1210301007

1. Begutachter: Dipl.-Ing. Harald Swoboda, MBA

2. Begutachter: Dipl.-Ing. Andreas Hocevar

Wien, Jänner 2014

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 ex-

tremen Umgewissheit kapitulieren müssen, versprechen agile Produktentwick-

lungsmethoden 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 Teilzeitpro-

jekten 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äfts-

modellen 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 Qualifizier-

ung der Produktidee. Den Hauptteil der Arbeit bildet eine Fallstudie, in welcher der Autor

seine Produktidee eines cloudbasierten Foto-Editors auf Basis der agilen Produktentwick-

lungsmethode 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

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 fulltime-

employed 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

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.

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 2013. 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.

7

Inhaltsverzeichnis

1 Einleitung ...........................................................................................................10

2 Die Entwicklung von Running Lean ...................................................................13

2.1 Toyota Production System .................................................................................13

2.1.1 Entstehung ........................................................................................................13

2.1.2 Aufbau ...............................................................................................................14

2.2 Lean Startup ......................................................................................................16

2.2.1 Startups und EntrepreneurInnen ........................................................................17

2.2.2 Prinzipien ...........................................................................................................18

2.2.3 Praktische Umsetzung .......................................................................................19

2.3 Business Model Canvas ....................................................................................20

2.3.1 Definition des Begriffes „Geschäftsmodell“ ........................................................21

2.3.2 Bausteine eines Geschäftsmodells ....................................................................21

2.4 Running Lean ....................................................................................................23

2.4.1 Bestandteile .......................................................................................................24

2.4.2 Durchführung .....................................................................................................24

3 Running-Lean-Fallstudie „Entwicklung eines cloud-basierten Foto-Editors“ .......26

3.1 Einleitung und Rahmenbedingungen .................................................................26

3.2 Ausgangssituation .............................................................................................27

3.2.1 Der Einsatz von DSLRs im Workflow des Autors ...............................................27

3.2.2 Camera RAW-Formate ......................................................................................29

3.2.3 Photosharing-Platformen zum Teilen der Bilder .................................................35

3.3 Problemstellung und Lösungsansatz .................................................................37

3.3.1 Ein erster Lösungsansatz ..................................................................................39

3.4 Überführung der Lösung in ein Produkt .............................................................44

3.4.1 Problem und Kundensegmente ..........................................................................45

3.4.2 Unique Value Proposition ..................................................................................46

3.4.3 Solution .............................................................................................................47

3.4.4 Channels ...........................................................................................................47

3.4.5 Einnahmequellen und Kostenstruktur ................................................................49

3.4.6 Wichtige Kennzahlen (key metrics) ....................................................................49

8

3.4.7 Unfairer Vorteil (unfair advantage) .....................................................................51

3.5 Der „Plan A“ als Lean Canvas............................................................................52

4 Test des „Plan A“ ...............................................................................................53

4.1 Testen der Produktidee durch Problem Interviews .............................................53

4.1.1 Vorüberlegungen ...............................................................................................53

4.1.2 Aufbau und Ablauf der Problem Interviews ........................................................57

4.1.3 Ergebnisse der Problem Interviews ...................................................................58

4.2 Abgleich der Kundenerwartungen mit den technischen Rahmenbedingungen ...60

4.2.1 Upload-Geschwindigkeit als potentieller Flaschenhals .......................................60

4.2.2 Beschleunigter Upload der RAW-Photos durch vorherige Kompression ............61

4.2.3 Echtzeit-Processing der RAW-Bilder am Server ................................................63

4.3 Analyse und Diskussion der Problem Interviews ................................................68

5 Umsetzung des „Plan B“ ....................................................................................69

5.1 Der Pivot als Ideen-Kurskorrektur ......................................................................69

5.2 Durchführung des Pivot .....................................................................................71

5.2.1 Analyse der Produktrisikos ................................................................................72

5.2.2 Analyse des Akquisitionsrisikos .........................................................................73

5.2.3 Analyse des Marktrisikos ...................................................................................73

5.2.4 Aktualisierung der Produktidee ..........................................................................74

5.3 Solution Interviews .............................................................................................75

5.3.1 Einsatz von Prototypen ......................................................................................76

5.3.2 Umsetzung des Trelew-Prototyps ......................................................................78

5.3.3 Definition des Preismodells für Trelew ...............................................................83

5.3.4 Durchführung der Solution Interviews ................................................................90

5.3.5 Ergebnisse der Solution Interviews ....................................................................92

5.3.6 Verifizierung der Exit-Kriterien ...........................................................................94

5.3.7 Überleitung in ein MVP – Minimum Viable Product ............................................95

6 Diskussion .........................................................................................................96

6.1 Persönliche Reflexion ........................................................................................96

6.1.1 Positive Aspekte ................................................................................................97

6.1.2 Herausforderungen ............................................................................................98

6.2 Bewertung der Methode „Running Lean“ ......................................................... 101

6.3 Bewertung der Produktidee ............................................................................. 102

9

6.4 Empfehlungen ................................................................................................. 103

6.4.1 Praktischer Einsatz von Running Lean ............................................................ 103

6.4.2 Einsatzkriterien ................................................................................................ 106

6.5 Externe Evaluierung der Ergebnisse ................................................................ 108

7 Ausblick ........................................................................................................... 110

Anhang ........................................................................................................................ 112

Abschrift der Problem Interviews ................................................................................... 112

Interview mit Bernhard Anders, Konzertfotograf .......................................................... 112

Interview mit Daniel Ortner, Fotografie-Dozent ............................................................ 114

Interview mit Paul Meier, Event-Fotograf ..................................................................... 115

Interview mit David Anger, Fotograf und Dozent .......................................................... 118

Interview mit Tobias Krammer, Mediengestalter und Fotograf ..................................... 120

Interview mit Thorsten Brenner, Panoramafotograf und Dozent für Mediengestaltung . 122

Abschrift der Solution Interviews ................................................................................... 125

Interview mit Paul Meier, Event-Fotograf ..................................................................... 125

Interview mit Tobias Krammer, Mediengestalter und Fotograf ..................................... 127

Interview mit Daniel Ortner, Fotografie-Dozent ............................................................ 129

Interview mit Thorsten Brenner, Panoramafotograf und Dozent für Mediengestaltung . 130

Interview mit Oskar Magenschab, Fotografie-Dozent .................................................. 131

Literaturverzeichnis ......................................................................................................... 133

Abbildungsverzeichnis .................................................................................................... 136

Tabellenverzeichnis ........................................................................................................ 137

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 er-

scheinen – 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 über-

raschende 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 belie-

bige Aktionen starten konnte. Andererseits erlaubte die körpernahe Ballführung eine Kon-

zentration 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. 2001 ü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 ge-

launcht 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öf-

fentlichten 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-

11

lung von Veröffentlichungstermin und Geheimhaltung mit starrem Zeitplan und ohne Kun-

deneinbindung durchgeführt.

Die Folge seien Produkte und Technologien, die an den Bedürfnissen der Kunden vorbei-

gingen, aber dennoch auf den Markt geworfen werden, in der Hoffnung, die hohen Ent-

wicklungskosten 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 er-

wähnten Tempodribblern: während diese alle Kraft aufwenden müssen, um den vorgeleg-

ten 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 eige-

nen Angaben verfügt die von ihm ins Leben gerufene Bewegung „Lean Startup Circle“ über

80000 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ügeln1.

Obwohl Eric Ries‘ Werk sich als bahnbrechend für die internationale Startup-Szene her-

ausstellte, 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 Schilderun-

gen 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 Produkt-

entwicklungsprozess 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 http://www.meetup.com/Lean-Startup-Vienna/, abgerufen am 23.12.2013

12

Fokus auf Effizienz und Zielerreichung er im Laufe der Jahre zu schätzen lernte. Nebenbe-

ruflich 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 verwen-

den. 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 berufsbe-

gleitenden Perfektionierung von Produktideen in Österreich? Der Terminus „berufsbeglei-

tend“ bezieht sich dabei einerseits auf aktuell unselbstständig Beschäftigte, die eine vor-

handene 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 Routine-

aufgaben 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 angespro-

chene 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 Erkennt-

nisse ausführlich analysiert und konkrete Handlungsempfehlungen abgeleitet.

Wien, im Dezember 2013

Franz Buchinger

13

2 Die Entwicklung von Running Lean

2.1 Toyota Production System

2.1.1 Entstehung2

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 Welt-

kriegs, 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 überle-

gen 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 laufen-

den Band aus zahlreichen Einzelteilen zusammengebaut wurde. Durch standardisierte,

möglichst einfache Arbeitsschritte konnten diese Tätigkeiten auch von ungelernten Ar-

beitskräften ausgeführt werden. Es bestand zudem eine klare Trennung zwischen den pla-

nenden 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 wur-

den 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 finan-

ziellen Ressourcen des Unternehmens banden. Außerdem wurde dadurch die bedarfsge-

rechte 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

14

besonders strengen Winters), sondern war gezwungen, die lange vorab geplanten Stan-

dardausfü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 Kom-

ponente 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 verstri-

chenen Zeitraum möglicherweise hunderte fehlerhafte Komponenten produziert worden.

Ono erkannte also in der scheinbar ökonomischen Massenlosfertigung der westlichen Au-

tomobilhersteller eine gigantische Verschwendung von Material, Arbeitszeit und finanziel-

len 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 amerikani-

sche Automobilindustrie in den 80er Jahren in eine schwere Krise stürzte.

2.1.2 Aufbau3

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 Taktsyn-

chronisation aufgrund von Bestellschwankungen oder technischen Produktionsbe-

dingungen 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 Verschwen-

dung in der Produktion: Materialbewegung (Transportation), zu große Lagerbe-

stä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

15

zeiten (waiting), überflüssige Bearbeitung der Werkstücke (over-Processing), Über-

produktion (overproduction) sowie Korrekturen und Fehler (defects). Eine achte

Verschwendungsart, das Nichtnutzen der Kreativität und des Potentials der Mitar-

beiterInnen, 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. Standardi-

sierung bedeutet bei Toyota nicht bloß die Dokumentation von Handlungsempfeh-

lungen 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 de-

fekte Teile durch den knappen Materialfluss eine Produktionslinie schnell lahmle-

gen 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 Ab-

arbeitung langer Qualitäts-Checklisten zu überfordern, unterstützt Toyota sie durch

technische Hilfsmittel: die eingesetzten Maschinen erkennen selbst, ob sie die er-

forderlichen Fertigungstoleranzen erbringen und halten bei Nichterfüllung an

(Jidoka-Prinzip). Poka-Yoke-Einrichtungen verhindern unbeabsichtigte Fehler, in-

dem 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 re-

gulä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 wer-

den 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

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 Prozessver-

besserungen unter direkter Einbindung der Beteiligten gegenüber dem „großen

Wurf“, also radikalen, von externen PlanerInnen über Nacht eingeführten Verfah-

rensinnovationen.

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-Un-

ternehmen 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 For-

men der Verschwendung konfrontiert, die er durch Anwendung des Toyota-Systems elimi-

nieren wollte: als Beispiel nennt Ries die vorzeitige Fokussierung vieler junger Internet-Un-

ternehmen auf Wachstumsfaktoren wie die Lukrierung von Wagniskapital, die Gewinnung

neuer MitarbeiterInnen oder die Entwicklung ausgefeilter Businesspläne, ohne vorher

17

festgestellt zu haben, ob die gewählte Geschäftsidee des Unternehmens am Markt über-

haupt „greift“.

Als Negativbeispiel führt Ries seinen früheren Arbeitgeber There Inc. an4. 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 Ge-

heimhaltung 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.

2.2.1 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ön-

nen. 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 beson-

dere Anforderungen an die MitarbeiterInnen eines Startups. Ries fordert nicht nur geeig-

nete 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.: http://www.youtube.com/watch?feature=player_detailpage&v=EMysvIXmbl0#t=292

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 wollen5. Schumpeter unterscheidet

diese von Kapitalisten, die ihre Profite durch kostenpflichtige Bereitstellung von Kapital

machen (siehe Abbildung 2).

Abbildung 2: Die Rolle von Entrepreneuren im Wirtschaftssystem nach Schumpeter

(Brown & Ulijn, 2004, p. 106)

2.2.2 Prinzipien

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ür-

fen sich nicht auf die Produktentwicklung allein beschränken, sondern müssen Ma-

nagementkompetenzen 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 Expe-

rimente anzueignen. In diesen werden einzelne Annahmen der Produktidee bzw.

unternehmerischen Vision auf ihre Gültigkeit geprüft.

5

vgl. (Schumpeter, 1926)

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 ge-

messen und schließlich die richtigen Lehren daraus gezogen (z.B. Weiterverfol-

gung oder Änderung der Ideenhypothese)

5. Innovationsbilanz: Der Lern- und Innovationsfortschritt eines Startups muss stän-

dig gemessen und hinterfragt werden. Durch Definition von Meilensteinen und Ein-

fü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)

2.2.3 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.

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ög-

lichst 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 Funktio-

nen 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 die-

ses 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, wel-

ches 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-Entrepre-

neuerInnen 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.

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.

2.3.1 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 Defi-

nition „womit das Unternehmen Geld verdient“, für sie umfasst es auch die Entwicklung je-

ner Wertangebote, welche die späteren Einnahmen generieren oder die Akquisition der

Kunden und Kundinnen, die diese Zahlungen leisten.

2.3.2 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 Ge-

schäftsmodells ab, die im Business Model Canvas grafisch dargestellt werden (siehe

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 sei-

nen 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 Organisa-

tion 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 Selbstbedie-

nungs-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üssel-

ressourcen können physische (Rohstoffe, Fabrik, Computernetzwerk,...), immateri-

elle (Patente, Markenrechte), menschliche (Schlüsselarbeitskräfte,...) oder finanzi-

elle (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 (bei-

spielsweise Produktion, Innovation, Vertrieb). Diese bezeichnen Osterwalder und

Pigneur als Schlüsselaktivitäten.

Schlüsselpartnerschaften (key partnerships): nicht alle erforderlichen Ressour-

cen und Aktivitäten können vom Unternehmen selbst bereitgestellt werden, es

muss Partnerschaften mit anderen Organisationen eingehen, um an sie zu kom-

men. Schlüsselpartnerschaften können aber auch zwischen konkurrierenden Un-

ternehmen eingegangen werden, um wichtige Technologien zu standardisieren und

zu vermarkten (z.B. Blu-Ray-DVDs) oder finanzielle Vorteile durch Einkaufsge-

meinschaften zu lukrieren.

Kostenstruktur (cost structure): Die Elemente des Geschäftsmodells verursa-

chen Kosten, welche in einer Kostenstruktur zusammengefasst werden.

23

Osterwalder und Pigneur unterscheiden hierbei zwischen kostenorientierten Unter-

nehmen, 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 Augen-

merk 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 way6.“

(Maurya, 2012, p. 24)

6

Maurya bezieht sich bei dieser Aussage auf in (Mullins & Komisar, 2009, p. vii) veröffentlichte Daten.

24

Er folgert daraus, dass es einen systematischen Prozess benötigt, um die meist wirkungs-

lose Ursprungsgeschäftsidee in Richtung eines funktionierenden Geschäftsmodells zu trei-

ben:

„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)

2.4.1 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 ei-

nes Startups – das Maximieren des Wissens über Kundenbedürfnisse und Markt-

gegebenheiten 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 wag-

niskapitalhungrigen 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 Unternehmens-

grü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.

2.4.2 Durchführung

Maurya gliedert Running Lean in drei Grundschritte, welche im Lauf der Anwendung von

Lean Canvas wiederholt durchlaufen werden. Nachfolgend werden diese Schritte über-

blicksmässig beschrieben, eine detaillierte Beschreibung erfolgt im Rahmen der nachfol-

genden Fallstudie [vgl. (Maurya, 2012, p. 43ff)].

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 zu-

grunde liegendenen Hypothesen. Running Lean gibt auch die Reihenfolge der Be-

füllung vor: erst nach der Dokumentation des Problems aus Zielgruppensicht darf

der (technische) Lösungsansatz ausgeführt werden. Ash Maurya drückt die An-

sprü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 ris-

kantesten Teile des in Schritt 1 erstellten Plan A zu identifizieren. Running Lean

unterstützt den/die EntrepreneurIn dabei mit einem phasenabhängigen Risikobe-

urteiltungsmodell, das auf den aktuellen Produktentwicklungsfortschritt des Star-

tups abstellt:

o Am Beginn seiner Existenz muss das Startup danach streben, den

sogenannten Problem/Solution-Fit zu erreichen – das vom Startup ange-

gangene 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ösens-

wertes 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 ge-

stellt 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.

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 berufsbegleiten-

den7 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ütz-

ten 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 Studien-

gangsleitung definierten Abgabetermin per 30.1. 2014, von dem für diverse Finalisierungs-

arbeiten an der Masterarbeit ein Monat abgezogen wurde.

Weitere wichtige Rahmenbedingungen sind die Beschränkung auf die genannte Produk-

tidee aus dem Bereich digitale Medientechnologien, die gleichzeitige Evaluierung mehrerer

Ideen oder die Ausdehnung der Idee auf andere Fachbereiche stellen aufgrund des knap-

pen 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 be-

absichtigten Gewinnung institutioneller Geldgeber zur Finanzierung der Produktidee wird

aufgrund der Empfehlungen von Running Lean8 ebenfalls nicht nachgegangen. Eine Aus-

nahme 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 Kun-

din?) Hinsicht. Zum anderen sollten die Erfahrungen aus der Fallstudie natürlich der Be-

antwortung der Forschungsfrage dienen: ergibt sich weiters eine gute Eignung von

Running Lean für die betriebliche und „private“ Produktentwicklung, möchte der Autor

7

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. 8

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)].

27

mithilfe von Anwendungsempfehlungen den Einsatz der Methode in diesen Bereichen

erleichtern.

Aufgrund des offenen Ausgangs der Fallstudie stellt die Kommerzialisierung der Produk-

tidee 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 durch-

geführt werden.

3.2 Ausgangssituation

Der Autor dieser Masterarbeit ist ein leidenschaftlicher Hobby-Fotograf, der seine auf Rei-

sen oder Veranstaltungen geschossenen Fotos gerne mit seinem Familien- und Freundes-

kreis 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.

3.2.1 Der Einsatz von DSLRs im Workflow des Autors

Abbildung 5: Modell "EOS 5D Mark II" von Canon9

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: http://commons.wikimedia.org/wiki/File:Canon_EOS_5D.jpg)

28

ser Produktgattung10, die „EOS 5D Mark II“ der Firma Canon. Digitale Spiegelreflexkame-

ras bieten gegenüber Kompakt- oder Smartphone-Kameras folgende Vorteile:

durch einen größeren Bildsensor kommt es zu weniger Rauschen und einer höhe-

ren 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 ge-

trennte 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 Kom-

pakt- und Smartphonekameras verbreitete, verlustbehaftete JPEG-Format (Fraser,

2004).

Abbildung 6: Lichtwege bei DSLRs (Gockel, 2011, p. 28)

10

Quelle: Flickr.com Kamerastatistik, September 2013

29

Abbildung 7: DSLR-Modell Sony A230 mit Wechselobjektiven und weiterem Zubehör11

3.2.2 Camera RAW-Formate

Aufbau und Bedeutung

Der Terminus „Camera RAW-Format“ bezeichnet eine Familie von unterschiedlich aufge-

bauten 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: http://commons.wikimedia.org/wiki/File:Sony_A230_DSLR_kit_(6)_(5789834752).jpg)

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

31

Der Raw Converter durchläuft beim Entwicklungsprozess eines Raw-Bildes folgende Ar-

beitsschritte (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 Filterfo-

lien 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 Demo-

saicing bezeichnet wird (siehe Abbildung 8). Es existieren verschiedene

Demosaicing-Algorithmen, die Vor- und Nachteile haben.

2. Korrektur von Abbildungsfehlern: Die bei der Aufnahme eingesetzten Objek-

tive 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 menschli-

chen 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 die-

nen der Minderung des unvermeidbaren Sensorrauschens bzw. der Vermei-

dung von Moiré-Effekten bei der Abbildung klein strukturierter Muster. Der

Schärfe-Filter wirkt dem durch das Demosaicing bewirkten Schärfeverlust ent-

gegen.

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 veranschlagen12, 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)

32

Unterschiede zum JPEG-Format

Das von digitalen Kompakt- und Smartphone-Kameras produzierte JPEG-Format ent-

spricht 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 Kom-

pressionsraten von 1:10 – 1:15 für „visuell verlustfreie“ Bilder (d.h. auch geübten Betrach-

terInnen 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

Einsatz13. 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-Kompression14

13

Das Vergleichsbild wurde mit dem JPEG-Enkoder des Bildbearbeitungsprogramms Paint.NET Version 3.5.10 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: http://commons.wikimedia.org/wiki/File:Schnepfenfliege_Rhagio_scolopaceus2.jpg)

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 Kameraherstel-

lers angewiesen. Dieser hat aber nur ein beschränktes Budget für Softwareent-

wicklung 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 Bei-

spiel bei Fujifilm-Kameras mit EXR-Sensoren15. Auch hier sind unvollständig doku-

mentierte, 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 ih-

rer 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

Zeit16. Durch die nachträgliche Änderung der Dateistruktur lässt sich zudem der Re-

chenaufwand für die Darstellung der RAW-Datei senken.

Mit dem 2004 veröffentlichten DNG-Format (DNG = digital negative) wollte der Soft-

warehersteller Adobe die Probleme der zueinander inkompatiblen RAW-Formate lösen:

DNG ist ein offen spezifiziertes Dateiformat, das von Adobe für EntwicklerIn-

nen und AnwenderInnen kostenfrei zur Verfügung gestellt wird17. 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.: http://blogs.adobe.com/lightroomjournal/2013/04/lightroom-4-4-now-available.html 16

Einige Hersteller haben Kompressionsalgorithmen von unterschiedlicher Effizienz in ihren RAW-Formaten implementiert:

http://encode.ru/threads/1775-lossless-recompression-of-camera-raw?p=34255&viewfull=1#post34255 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.

34

nach RAW-Format zwischen 20 und 60% der Dateigröße einsparen. Die Beschrän-

kung 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 Arbeits-

last auf mehrere Rechenkerne verteilen können18.

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 platz-

sparenden 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

RAW)

Verlustfrei 5184 x 3456 17,92 22,37

DNG Verlustfrei 5184 x 3456 17,92 18,2

DNG Verlustbehaftet / Bildpixel

beibehalten

5184 x 3456 17,92 6,65

DNG Verlustbehaftet / auf 10

Megapixel verkleinert

3872 x 2581 10 3,18

DNG Verlustbehaftet / auf 6

Megapixel verkleinert

3000 x 2000 6 1,97

Tabelle 1: Vergleich verschiedener DNG-Varianten, die aus einer Canon RAW-Datei erstellt wurden19

.

18

In (Shankland, 2012), Abschnitt „New DNG features“ wird von einer Verdreifachung der Lese/Schreibgeschwindigkeit

berichtet. 19

Erstellt mit Adobe DNG Konverter 7.3

35

Knapp 10 Jahre nach der Einführung hat Adobe sein Ziel, DNG als neues RAW-Stan-

dardformat für Digitalkameras zu etablieren, deutlich verfehlt: nur wenige, nach heutigem

Stand veraltete Modelle unterstützen DNG20.

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 Bildbearbei-

tung, -verwaltung und -konvertierung, die das DNG-Format unterstützten21. Auch der in

Kapitel 3.3.1 beschriebene Lösungsansatz wird sich die Vorzüge des DNG-Formats

zunutze machen.

3.2.3 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 Produkt-

gattung. 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. 2009 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)

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 Charak-

terisierung dieses Produktgenres:

Photosharing-Plattformen bieten Fotografen und Fotografinnen eine leistungsstarke

Online-Software zum Erstellen und Präsentieren ihrer Bilder und Fotoalben im In-

ternet. 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. 119-121)].

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 Personen-

kreis ü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ön-

nen 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 Be-

trachterIn 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 be-

zeichnet ein Geschäftsmodell, bei dem der Kunde/die Kundin anfangs ein kostenlo-

ses Basisprodukt nutzen kann, später aber auf dessen kostenpflichtige Premium-

Variante wechseln wird. Dieser Wechsel wird durch den bewusst reduzierten Funk-

tionsumfang des Basisprodukts provoziert, der ab einer gewissen Nutzungsdauer

hinderlich wird. Flickr.com limitierte über viele Jahre das monatliche Upload-Volu-

men seiner Gratis-Accounts, um die NutzerInnen zum Umstieg auf die kosten-

pflichtige 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 sol-

len, dienen häufig Diskussionsforen und andere Community-Werkzeuge. In den

zahlreichen Flickr-Diskussionsgruppen können sich Fotografinnen und Fotografen

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 im-

mer das Mittel der Wahl zur Publikation größerer Bildkataloge. Ein auf visuelle Inhalte ab-

gestimmtes Layout und die Möglichkeit zur Veröffentlichung größerer Bildauflösungen sind

nur zwei Beispiele für wichtige Differenzierungsfeatures. Allerdings werden weitere Inno-

vationen nötig sein, um die „Kernkompetenz“ Photosharing gegenüber sozialen Netzwer-

ken zu behaupten. Der in Kapitel 3.3.1 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 er-

stellt und über verschiedene Photosharing-Dienste im Freundes- und Bekanntenkreis ge-

teilt. 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 Photosha-

ring-Anbieters) werden nur verkleinerte und qualitätsgeminderte JPEG-Versionen

der Fotos gespeichert. Grund dafür sind die hohen Dateigrößen der RAW-Dateien,

38

die lange Upload-Zeiten und großes Datenvolumen verursachen. Dieses Datenvo-

lumen verursacht Kosten in Form von erhöhtem Internet-Traffic und Server-Spei-

cherplatz. 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 beispiels-

weise 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 An-

bietern 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 (bei-

spielsweise zur Erstellung eines Fotobuchs). Wie hoch ist der Automatisierungs-

grad dieses Prozesses?

39

Anbieter Upload Download Darstellung

im Browser

Bearbeitung Request-

Workflow

Instagram.com nein22 nein nein nein nein

Photobucket.com nein23 nein nein nein nein

Flickr.com nein24 nein nein nein nein

Picasa.com / Google+

Photos

ja ja ja (Zoom

beschränkt)

ja (JPEG-

Version)

nein

Dropbox.com ja ja nein25 nein nein

SmugMug.com ja26 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.

3.3.1 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 werden27. Durch die

Wahl der „richtigen“ Kompressionsmethode lässt sich ein guter Kompromiss zwi-

22

vgl.: http://instagram.com/developer/iphone-hooks/ 23

vgl.: http://support.photobucket.com/entries/21812019-Troubleshooting-Upload-Problems 24

vgl.: https://www.flickr.com/help/photos/#150488231 25

https://www.dropbox.com/help/6/en 26

Unterstützung über kostenpflichtiges Zusatzprodukt SmugMugVault –siehe

http://help.smugmug.com/customer/portal/articles/93324 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)

40

schen Datenmenge/Upload-Dauer und der erforderlichen Bildqualität des Fotos er-

zielen.

2. Upload der konvertierten Fotos über das HTTP-Protokoll auf den Server des

Online-Dienstes, wofür entweder der Web-Browser oder ein kommandozeilenba-

sierter HTTP-Client wie curl28 verwendet werden kann.

3. Der Online-Dienst prozessiert die einlangenden Bilder am Server in eine Bildpyra-

mide 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 Brow-

ser integrierten Skriptsprache Javascript verfügbar sind, müssen zur Betrachtung

der Bilder keine Zusatzprogramme installiert werden. Die meisten tile viewer funkti-

onieren auch auf mobilen Endgeräten wie Smartphones.

5. Durch das Anhängen von URL-Parametern an die Bildkacheln kann eine serversei-

tige Bearbeitung mit Filtern oder Transformationswerkzeugen ausgelöst werden

(siehe Abschnitt „Bearbeitungsfunktionen“).

Abbildung 13: Struktur des RAW2Cloud-Dienstes29

28

curl ist ein Kommandozeilen-Tool zur URL-basierten Datenübertragung in Computernetzwerken und kostenlos unter

http://curl.haxx.se/ 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: http://openclipart.org/share)

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 re-

prä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 quadrati-

sche Einzelbilder mit vorgegebener Größe unterteilt. Verbreitete Kachelauflösungen sind

256 x 256 oder 512 x 512 Pixel.

Abbildung 14: Aufbau einer Bildpyramide30

Nun erfolgt die Konvertierung in das Kachelformat, bei der die generierten Kacheln in ein

internettaugliches Übertragungsformat konvertiert und nach einer bestimmten Dateina-

menskonvention abgespeichert werden. Verbreitete Kachelformate sind das von Microsoft

entwickelte DeepZoom-Format31 und das vom gleichnamigen Unternehmen veröffentlichte

Zoomify-Format32. 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 (http://iipimage.sourceforge.net/documentation/images/) 31

vgl.: http://blogs.msdn.com/b/jaimer/archive/2008/03/31/a-deepzoom-primer-explained-and-coded.aspx 32

vgl.: http://zoomify.com/

42

Beide Formate bestehen aus einem Metadatendokument und einer standardisierten Datei-

pfadstruktur. Das im XML-Format vorliegende Metadatendokument beschreibt die Auflö-

sung des Originalbildes, die Anzahl seiner Bildpyramidenstufen und die verwendete Ti-

legröße. Die standardisierte Dateipfadstruktur erlaubt es dem Anzeigeprogramm, den

Dateinamen einer anzufordernden Kachel aus den bereits vorhandenen Metadaten zu er-

rechnen. 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 Hoch-

wert 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 An-

zeigeprogramm später gezielt jene Kacheln anfordern, die für die aktuelle Ansicht des Bil-

des erforderlich sind, unnötige Datenübertragungen unterbleiben (siehe Abbildung 14,

Schritt 4). Damit eignen sich Kachelformate auch für die Darstellung hochauflösender Bil-

der 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 Be-

arbeitungen am Server nimmt ein kommandozeilenbasierter Bildprozessor vor, wie bei-

spielsweise das weitverbreitete OpenSource-Tool ImageMagick33. 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 http://www.imagemagick.org/ kostenlos beziehbar.

43

Eine Technologierecherche ergab, dass es bereits einige cloud-basierte Bildbearbeitungs-

dienste gibt, wie beispielsweise cloudinary (http://www.cloudinary.com). Dieser Dienst bie-

tet 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 cloudinary34

Abbildung 16: Durch den URL-Parameter e_contrast:80 wurde der Kontrast des Fotos erhöht35

.

34

Quelle: Cloudinary.com, abrufbar unter http://a5.res.cloudinary.com/demo/image/upload/horses.jpg 35

Quelle: Cloudinary.com, abrufbar unter http://a5.res.cloudinary.com/demo/image/upload/e_contrast:80/horses.jpg

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. Die-

ses 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 Produk-

tes, das niemand brauchen kann. Mit der oben geschilderten Prototyp-Entwicklung

„im stillen Kämmerlein“ findet der nötige Abgleich zwischen der Idee des Entrepre-

neurs 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 investie-

ren.

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, Ge-

schä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 2.4.1 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 ge-

gebenenfalls zu korrigieren, wobei mit den riskantesten Angaben begonnen wird. Der in

Abbildung 17 dargestellte Lean Canvas ist entsprechend durchnummeriert.

45

Abbildung 17: Leerer Lean Canvas mit Ausfüllhilfen (Maurya, 2012, p. 66)

3.4.1 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 Pro-

duktes haben und sich in ihre Lage versetzen. Welche ihrer dringenden Probleme kann

das Produkt lösen? Gibt es existierende Konkurrenzprodukte, die das Problem (ansatz-

weise) 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 Heiman-

wender wird sich nicht nur mit existierenden Lösungen aus diesem Marktsegement ver-

gleichen 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 Kun-

den und Kundinnen eines Produkts zu unterscheiden. Bei einem Internet-Preisvergleich-

sportal 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)].

46

Die potentielle Zielgruppe seines Online-Dienstes für RAW-Fotos sieht der Autor in folgen-

den Anwendergruppen:

(Hobby)-Fotografen und Fotografinnen mit DSLR-Kamera und regelmäßiger

Bildausbeute

An hochauflösenden RAW-Fotos interessierte Kunden und Kundinnen von Foto-

schaffenden (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.

3.4.2 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 Allein-

stellung 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.

47

Ihre schönsten Momente in bester Qualität und an den sichersten Orten der Welt

gespeichert

RAW-Bilder online zu Geld machen

3.4.3 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 techni-

schen 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 wer-

den 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 Dateig-

röße)

browerbasierter Viewer auf Tile-Basis (auch für mobile Endgeräte)

API zur Anbindung an Fotodienstleister verhindert unnötige Up- und Downloads

3.4.4 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-Email 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 Entre-

preneurIn den Kontakt her, etwa durch gezielte Schaltung von Werbeanzeigen,

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 fal-

len hingegen sofort Gebühren an. Bei näherer Betrachtung zeigt sich allerdings,

dass kein Kanal wirklich kostenlos sein kann – schließlich muss der/die Entrepre-

neurIn für das Verfassen von Blog-Beiträgen Arbeitszeit investieren. Auch bei kos-

tenpflichtigen 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 „Ka-

nalkosten“ (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 Vertriebs-

partnerschaft mit einem etablierten Unternehmen bedienen (indirekter Kanal).

Manuell/Automatisiert: Bei einem manuellen Kanal findet die Kundenkommunika-

tion immer zwischen zwei Menschen statt, bei der automatisierten Variante hinge-

gegen ersetzt meist ein Computerprogramm den Verkäufer. Ein Beispiel dafür sind

Empfehlungssysteme in Online-Shops, die den Kundinnen und Kunden automa-

tisch 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 finanzi-

elle 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 Nachfrage-

druck, der den/die EntrepreneurIn zwingt, das Vorhaben überhastet umzusetzen.

Inbound-Kanäle wie Blogs sind nach den Erfahrungen von Maurya mit geringeren Ge-

samtkosten behaftet als Outbound-Kanäle und können bereits in der Frühphase der Pro-

duktentwicklung mit Informationen bespielt werden, um die Aufmerksamkeit potentieller

Kunden zu erlangen. Vom exzessiven Einsatz von Outbound-Kanälen rät Maurya hinge-

gen ab. [vgl. (Maurya, 2012, p. 78f)]

49

Der Autor sieht in folgenden Kanälen gute Kontaktmöglichkeiten zu potentieller Kund-

schaft:

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

3.4.5 Einnahmequellen und Kostenstruktur

Die Sicherstellung von Einnahmen ist ein weiteres Problem bei der Umsetzung neuer Pro-

dukte: 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 ver-

fä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-Platt-

form (Heroku/Amazon Cloud) - Grobschätzung 1000 EUR

o Monatliche Brutto-Personalkosten für eine Vollzeitstelle (Autor, 40h*60

EUR*4,5 Wochen) = 10800 EUR

Aus diesen Zahlen folgt, dass der Break-Even bei 1200 Usern und Userinnen liegen

müsste.

3.4.6 Wichtige Kennzahlen (key metrics)

Moderne Kennzahlensysteme wie Balanced Scorecard verlassen sich bei der Beurteilung

des Unternehmenserfolges nicht ausschließlich auf Finanzkennzahlen, da diese den Zu-

stand des Unternehmens verspätet und nur teilweise abbilden. Ein Unternehmen, dass

seine Innovationsaktivitäten eingestellt hat und sich auf den Vertrieb seiner erfolgreichen

50

Bestandsprodukte konzentriert, mag durch die Einsparung der Entwicklung zwar momen-

tan 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 aus-

schließlich auf die erzielten Umsätze verlassen. Setzt das Unternehmen beispielsweise

das in Kapitel 3.2.3 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 Interaktions-

kette 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. Bei-

spiel: 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

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 stattfin-

det. 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 Kenn-

zahlen gute Acquisition-Interaktionen, aber schlechte „Activation“, könnte den Interessier-

ten 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

3.4.7 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 Bei-

spiele 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)]

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)

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-Me-

thode die Befragung potentieller Kunden und Kundinnen im Rahmen von problem inter-

views vor. Diese etwa einstündigen, überwiegend aus offenen Fragen bestehenden Inter-

views 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über-

stehen – den klassischen „early adopter“. Im folgenden Abschnitt werden weitere wichtige

Überlegungen im Hinblick auf die Durchführung von problem interviews vorgestellt.

4.1.1 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-Feed-

backschleife ist nach Maurya ein zentrales Element bei der Konzeption von problem inter-

views. Die ausformulierte oder schon teilweise umgesetzte Produktidee („Bauen“) wird

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 Befrag-

ten zu profitieren. Im Vordergrund des Interviews steht daher nicht die neue Pro-

duktidee, sondern die bisherigen Erfahrungen und Herangehensweisen der be-

fragten 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, grund-

verschiedene Ausführungen. Dies beweisen die in diesem Bereich tätigen Internet-

Unternehmen Netflix, Google, Bittorrent oder Vimeo, die sich in Bezug auf den ver-

triebenen 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 inter-

views.

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än-

gendsten Gefahren in den Interviews gezielt anzusprechen. Das Feedback der Inter-

viewpartner 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 un-

erwünschtem Ausgang verstanden. Die internationale Industrienorm ISO 30000 definiert

Risiko als das Produkt der Eintrittswahrscheinlichkeit eines Ereignisses und dessen negati-

ver 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 Kundenan-

forderungen entspricht?

Akquisitionsrisiko: Wer genau ist die Zielgruppe des Produkts? Kann sie mit den

gegebenen Mitteln in ausreichender Zahl erreicht werden?

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 Unsi-

cherheiten 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 Produktri-

siko 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 verkraft-

bar.

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 (weni-

ger Bearbeitungsfunktionen im Vergleich zu Desktop-Programmen) zugunsten der gewon-

nenen 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)]

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 verbes-

sert werden. Maurya stützt seine Herangehensweise auf eine Feststellung des US-Statis-

tikprofessors 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-Spe-

zialisten 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.

4.1.2 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.

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 Dringlich-

keit 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 Up-

load

Hochauflösende Bilder auf mobilen Endgeräten betrachten

HighRes-Bilder online verkaufen oder für einen guten Zweck / creative commons

bereitstellen

4.1.3 Ergebnisse der Problem Interviews

Die Cloud-Backup-Funktion für RAW-Bilder wurde ausdrücklich von allen Befrag-

ten begrüsst. Allerdings haben die Interviewten angeregt, die Backup-Funktion

nicht nur auf RAW-Bilder zu beschränken: nach seiner „Entwicklung“ und Bearbei-

tung kann ein RAW-Bild nicht mehr als solches gespeichert, sondern muss in ein

RGB-Bild37 überführt werden. Da eine Nachbearbeitung vor der Veröffentlichung ei-

nes 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.

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 zu-

kunftssicheres 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 herunterge-

rechneten 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 ver-

kaufen, 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 ab-

speichert.

Die Online-Bearbeitung von RAW-Fotos wird von den meisten Befragten skep-

tisch gesehen, sie glauben nicht, dass ein Online-Dienst die Funktionen in der

Qualität der führenden Programme Adobe Photoshop und Adobe Lightroom an-

bieten 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öglich-

keit gibt, eine Farbkalibrierung des Displays vorzunehmen. Aus Energiespargrün-

den 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

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 ver-

wenden (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 techni-

schen 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 „nachprogram-

mieren“ 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.

4.2.1 Upload-Geschwindigkeit als potentieller Flaschenhals

Für einen datenbasierten Online-Dienst wie Trelew ist die erzielbare Upload-Geschwindig-

keit 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 Bear-

beitung des Bildes begonnen werden. In den problem interviews deuteten die Befragten

mehrfach an, diese Upload-Dauer mit der Ladedauer des Bildes in einem Desktop-Bildbe-

arbeitungsprogramm 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 speed-

test.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

61

möglich, die Geschwindigkeit der „letzten Meile“ (die vom Provider betriebene Netzwerkinf-

rastruktur 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-Geschwindig-

keit von 3,94 Mbps (Megabit pro Sekunde). Dies entspricht etwa 0,5 Megabyte Daten-

transfer pro Sekunde.

Die durchschnittliche Uploaddauer einer RAW-Datei würde bei einer angenommenen

Dateigröße von 23MB38 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-

Test39 erlaubt einen Vergleich mit den Ladezeiten für ein RAW-Bild im Desktop-

Bildbearbeitungsprogramm Adobe Photoshop Version CS6 in Verbindung mit dem inte-

grierten 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.

4.2.2 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 verlustbehafte-

ten 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 http://forums.adobe.com/message/5447242

62

grade. Zweitere verwerfen gezielt Informationen, die vom menschlichen Auge schlecht

oder gar nicht wahrgenommen werden können und liefern wesentlich bessere Kompressi-

onsverhältnisse, wobei aber ein Datenverlust in Kauf genommen werden muss. In Kapitel

3.2.2 wurden mit DNG und Lossy DNG bereits zwei Vertreter von RAW-

Kompressionsformaten vorgestellt. In diesem Kapitel sollen alternative Verfahren analy-

siert werden.

Verlustfreie Kompression

Im Camera RAW Compression Benchmark (Busch, 2013) untersuchte Stephan Busch 16

verschiedene Softwareprogramme zur verlustfreien Kompression von Camera RAW-Da-

teien. 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, Pa-

nasonic, Pentax, Samsung, Sigma und Sony. Diese wiesen eine durchschnittliche Da-

teigröße von 23 Megabyte auf, insgesamt lagen 577 MB an RAW-Daten vor. Das Kom-

pressionstool „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 Se-

kunden 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 3.2.2 vorgestellten Lossy-DNG-Verfah-

ren 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-

63

Datei fallen 7,59 Megabyte Upload-Volumen an. Dies entspricht 15,18 Sekunden

Upload-Zeit.

4.2.3 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 Abbil-

dungsfehler zu korrigieren und ein RGB-Bild zu erhalten. Die dafür nötigen Bearbeitungs-

schritte wurden bereits in Kapitel 3.2.2 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 grund-

liegende 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 „fernsteu-

erbar“ 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 Beurtei-

lung 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-Ser-

versystemen mit dieser Benchmark-Suite getestet wurden, kann der zeitliche Rechenauf-

wand 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-An-

bieter Amazon, Rackspace und Joyent je nach Hardware-Ausstattung zwischen 25 und 50

Sekunden, was einer Konvertierungsdauer pro Bild von 3 bis 6 Sekunden entspricht.

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 Wis-

sensstand 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 On-

line-Dienstes stark einschränken.

Zur Klärung dieser Frage hat der Autor mit dem Softwareentwickler Klaus Post ein Exper-

ten-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 E-Mail

zwischen 25.8. und 2.9. 2013 durchgeführt.

65

Frage: Welche Besonderheiten müssen bei der Verarbeitung von Camera RAW-Da-

teien im Vergleich zu anderen Bildformaten wie JPEG berücksichtigt werden?

Klaus Post: RAW-Bilder ähneln den analogen Filmnegativen: sie definieren kein eindeuti-

ges 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 dekompri-

miert 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 fehlen-

den 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 analysie-

ren 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-Algorith-

men, 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 (Farb-

säume an kontrastreichen Übergängen) oder Vignettierungen (Abdunkelungen an den

Rändern des Fotos durch verminderten Lichteinfall). Diese Abbildungsfehler werden für

66

jedes Objektivmodell durch verschiedene Testverfahren eruiert und in Objektivprofilen ge-

speichert. Da das verwendete Objektivmodell in den meisten Fällen auch in den Metadaten

der RAW-Datei gespeichert ist, kann die RAW-Entwicklersoftware mithilfe der Objektivpro-

file eine automatische Korrektur durchführen. Kommerzielle RAW-Entwicklungsprogramme

wie Adobe Lightroom bringen ihre eigenen Objektivprogramme mit, im OpenSource-Be-

reich stellt das Projekt LensFun40 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 neut-

ral 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 sor-

gen.

Frage: Welche Herausforderungen gibt es aus Ihrer Sicht, wenn man eine webbrow-

serbasierte Camera RAW-Applikation entwickeln möchte?

Klaus Post: Das hängt von den Anforderungen an diese Applikation ab. Ihr Anwendungs-

fall 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 Bearbei-

tung/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.: http://lensfun.berlios.de/

67

Verfügung steht. Sie kann auch zur Programmierung leistungsfähiger Grafikfilter genutzt

werden.

Frage: Kennen Sie Unternehmen oder OpenSource-Projekte, die derartige Applikati-

onen 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 beurtei-

len. 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 Aus-

kunft geben.

Frage: Welche Marktchancen sehen Sie für webbasierte Camera-RAW-Applikatio-

nen?

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 inte-

ressante 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 down-

loadbar 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.

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-Da-

teien 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 konver-

tierten RGB-Bildes in einer klassischen Bildbearbeitung wie Adobe Photoshop ver-

wendet. 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.

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 die-

ses 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 Funk-

tionsumfang 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 um-

setzbares 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 ange-

nommenen 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 lie-

gen: Einzelne Hypothesen der Produktidee werden solange abgewandelt, bis die

Zielgruppe diese bestätigt. Diese Ideen-Kurswechsel werden auch als Pivots be-

zeichnet (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

70

interviews ergaben, dass sein angedachter RAW-Editor mit Funktionen für Bild-

kompression, Echtzeit-RAW-Darstellung, Farbkorrektur, Retusche, Bildexport und

Schnellansicht ein technologisch sehr weites Feld abdecken müsste, um den Kun-

denansprü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 anderer-

seits 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 rele-

vantes Problem löst.

Product/Market Fit: Wurde das Problem und der Lösungsansatz von der Ziel-

gruppe 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 Erkennt-

nisse, 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 Vor-

dergrund, bei denen Einzelaspekte der Idee bzw. Funktionen des Mininum Viable Products

auf ihre Akzeptanz getestet werden. Dies geschieht durch die im vorigen Absatz erwähn-

ten 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)

71

Für Maurya ist es wichtig, zwischen Pivots und Optimierungen zu unterscheiden. Pivots

sind grobe Kurskorrekturen der Produktidee, Optimierungen stellen geringfügige Verbesse-

rungen 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äu-

men:

„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, emp-

fiehlt 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 4.1.1 vorgestellt und bezeichnen die Wag-

nisse, 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 Produk-

tidee aufgenommen werden müssen.

Am Ende des Pivot steht also ein aktualisierter Lean Canvas, auf dessen Basis die Proto-

typ-Entwicklung und die solution interviews durchgeführt werden können.

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 abgewin-

nen, sehen aber großes Anwendungspotential für einen Teilaspekt der Idee: die zeitspa-

rende Darstellung hochaufgelöster Fotos im Web-Browser auf Basis von Kachelbildern.

Allerdings gelangt dadurch der Kunde oder die Kundin vorab in Besitz des hochaufgelös-

ten 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 Uplo-

adzeit 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 Anfra-

gen sind zwar sehr profitabel, stellen aber meist einen manuellen, fehlerbehafteten Pro-

zess dar. Die Nachbestellungen werden oft über E-Mail abgewickelt, als häufigste Fehler-

quelle entpuppen sich fehlerhaft angegebene Identifikationsnummern für die Bilder bzw. zu

niedrige Empfangslimits für E-Mails auf Kundenseite.

Neue Hypothesen

Kunden und Kundinnen von Fotoschaffenden würden gerne hochaufgelöste Vor-

schaubilder 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 Nachbe-

stellprozesses für Bilder.

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 Gegen-

stä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 Personengrup-

pen fotografieren und deshalb viele Nachbestellungen bearbeiten müssen.

5.2.3 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 Funk-

tionsumfangs 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.

74

5.2.4 Aktualisierung der Produktidee

Aufgrund der vorangegangenen Analyse ergeben sich folgende Änderungen in der Pro-

duktidee:

In Trelew können nunmehr nicht nur RAW- oder DNG-Dateien hochgeladen wer-

den, 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ön-

nen Fotoschaffende besonders speichereffiziente Formate wie JPEG XR verwen-

den, 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 ge-

zielt 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 Bil-

dern 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 Vorschaubil-

dern aufgeben.

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 Be-

antwortung 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)]

76

5.3.1 Einsatz von Prototypen

Bei der Durchführung der problem interviews wurde bewusst auf die Erstellung von Proto-

typen und erklärender Screenshots verzichtet. Dies geschah einerseits, um die Schilde-

rung der Problemstellung aus Sicht des Interviewten in den Vordergrund zu rücken, ande-

rerseits, 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 soll-

ten auch für die Umsetzung des späteren Produkts zur Verfügung stehen. Maurya

wendet sich insbesondere gegen den Einsatz von Animationseffekten, die in eini-

gen Rapid-Prototyping-Tools zur „Verhübschung“ der Ergebnisse eingesetzt wer-

den. 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-

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 Ver-

trauensvorschuss 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 editier-

barer 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 wer-

den kann, desto schneller können Erkenntnisse gesammelt werden. Vorschnell ge-

nommene „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 Interaktions-

funktionen 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 wir-

kenden Daten bestückt werden, die den demonstrierten Anwendungsfall wirksam

illustrieren. Platzhaltertexte wie das bekannte „lorem ipsum“ irritieren den Betrach-

ter und lenken ihn ab.

Abbildung 26: Wireframe-Darstellung einer Dialogbox

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 (Up-

load 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 Vereinfa-

chung der clientseitigen Datenhaltung, hat aber eine nicht unerhebliche Lernkurve.

Um die Eignung von AngularJS für die Umsetzung des späteren Produkts zu tes-

ten, 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 postu-

lierte Forderung nach Authentizität der Daten.

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-Bil-

dern unterstützt. Die den Bildbereich umgebende grafische Benutzeroberfläche erlaubt ein

Umschalten zwischen den einzelnen Bildern, sie entstand unter Verwendung der Frame-

works Bootstrap und AngularJS.

80

Abbildung 28: Der Prototyp der Schnellansicht im Webbrowser

Erläuterung der übrigen Features auf einer Marketingseite

Da die meisten Interviewten über einen E-Mail-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.

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 dokumen-

tieren und von der prototypischen Implementierung dieser Funktionen abzusehen.

Neben dem zeitlichen Argument sprachen auch technische Gründe für diesen An-

satz: für eine tatsächliche Demonstration der Upload-Funktionen müsste der/die

AnwenderIn die vom Autor bereitgestellte Software auf dem eigenen System in-

stallieren, was bei unsachgemäßer Anwendung oder durch unkorrigierte Pro-

grammierfehler 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.

82

Abbildung 29: Vollumfänglicher Screenshot der Trelew-Marketingseite

83

Veröffentlichung des Prototyps auf Dropbox.com

Damit die per E-Mail befragten Anwender auf den Prototyp bzw. die Marketingseite zu-

greifen konnten, mussten diese Komponenten im Internet veröffentlicht werden. Auch

dabei galt es einige Bedingungen zu berücksichtigen:

Beim Testen des Prototyps wird eine nicht unerhebliche Menge an Daten übertra-

gen – ist der Webserver nicht mit ausreichender Bandbreite an das Internet ange-

bunden, könnte bei den Befragten der Eindruck einer schlechten Performance ent-

stehen.

Änderungen an den Quelldaten sollten möglichst schnell und einfach durchführbar

sein

Den Befragten sollte klar sein, dass sie einen frühen Prototyp verwenden und noch

kein fertiges Produkt – die Verwendung einer Top-Level-Domain wie trelew.at

könnte für diesen Eindruck kontraproduktiv sein.

Die Veröffentlichung des Prototyps sollte kostenfrei und ohne verpflichtende

Offenlegung des Quellcodes möglich sein. Der Webspace sollte die Bereitstellung

einer größeren Menge an Bilddaten unterstützen.

Aus den genannten Gründen entschied sich der Autor für eine Veröffentlichung des Proto-

typs über die Dateisynchronisationsplattform dropbox.com. Als eine der führenden Dienste

für Dateisynchronisation im Internet bietet Dropbox ein redundantes Hosting der Daten in

mehreren Rechenzentren mit guter Anbindung, die automatische Synchronisierung von

Änderungen erleichtert Anpassungen des Prototyps.

5.3.3 Definition des Preismodells für Trelew

Mit Interessierten über den Preis für ein noch nicht existierendes Produkt zu sprechen,

stellt besonders Entrepreneure und Entrepreneurinnen mit technischem Background vor

große Herausforderungen. Man kennt die technischen Unzulänglichkeiten und Beschrän-

kungen der eigenen, in Entwicklung befindlichen Lösung zu genau und tendiert dazu, die

bereits am Markt bestehenden Konkurrenzprodukte als übermächtige Konkurrenz wahrzu-

nehmen. Als Konsequenz wird das Thema Preisfindung und Kundenakquise in der An-

fangsphase des Startups gerne ignoriert. Erst wenn ökonomische Zwänge das Thema aufs

Tapet bringen, wird zaghaft die Lukrierung von Einnahmequellen versucht.

Die „Lowering Signup Friction“-Strategie

Eine gängige und bequeme Strategie besteht darin, es Interessierten möglichst angenehm

zu machen, zu zahlenden Kunden und Kundinnen zu werden: zunächst werden sie be-

fragt, wieviel ihnen die Nutzung des Produktes Wert sei. Auf den genannten Betrag wird

84

ein beträchtlicher Anfangsrabatt gewährt, in der Hoffnung, den Widerstand der Interes-

sierten gering zu halten.

Maurya nennt diese Strategie „lowering signup friction“ (Verringerung des Zahlungswider-

standes):

„The mindset most of us have during Solution interviews is one of ‚lowering signup

friction‘. We want to make it as easy as possible for customers to say yes and agree to

take a chance on our product, hoping the value we deliver over time will earn us the

privilege of their business.“

(Maurya, 2012, p. 162)

In weiterer Folge erläutert er, warum er diese Strategie für problematisch hält:

Nicht nur der/die EntrepreneurIn, sondern auch die „early adopter“, die ersten

Kundinnen und Kunden, müssen sich zum Produkt bekennen, es regelmäßig nut-

zen und Feedback liefern. Wenn vorrangig der Preis und nicht die Lösung der in

den problem interviews genannten „brennenden“ Probleme den Ausschlag für die

Nutzung des Produktes geben soll, stellt sich die Frage nach dessen Sinnhaftigkeit.

Anders gesagt: ein Produkt, das nur mit Preisdumping Nutzer gewinnen kann, ist

keine Innovation mehr, sondern nur mehr ein Nachzügler (late follower) in einem

bereits umkämpften Markt.

Überzogen kundenfreundliche Preisgestaltung schadet der Kundschaft selbst:

der/die EntrepreneurIn wird zu niedrig kalkulierte Preise auf Dauer nicht durchhal-

ten können und das Produkt einstellen müssen. Die Kunden sind dadurch gezwun-

gen, sich nach Alternativen umzusehen, ihnen entstehen zusätzliche Migrations-

kosten.

Kundinnen und Kunden bringen nicht nur Umsätze, sie brauchen auch Unterstüt-

zung bei der Anwendung des Produktes. Aufgrund der beschränkten Zeitressour-

cen des Entrepreneurs oder der Entrepreneurin macht es daher keinen Sinn, mög-

lichst viele Kunden um „jeden Preis“ gewinnen zu wollen und diese später durch ei-

nen schlechten Kundenservice zu verärgern.

85

Die „Raising Signup Friction“-Strategie

Maurya empfiehlt daher, den Zahlungswiderstand nicht zu senken, sondern zu erhöhen:

„Don’t Lower Signup Friction, Raise It“

(Maurya, 2012, p. 163)

Um das Produkt trotzdem begehrenswert für die Kundinnen und Kunden erscheinen zu

lassen, rät Maurya bei der Gestaltung des Preismodells zu folgenden psychologischen

Kniffen:

Verknappung: Ein Produkt, das jederzeit und unbeschränkt verfügbar ist, übt auf

VerbraucherInnen nur einen geringen Kaufanreiz aus. Bei zeitlich oder mengen-

mäßig limitierten Produkten ist das Gegenteil der Fall: die Gefahr, schon morgen

nicht mehr zum Zug zu kommen, drängt zum Abschluß des Kaufs. Der/die

EntrepreneurIn erklärt also von sich aus, dass er/sie momentan nur eine be-

schränkte Anzahl von Kunden akzeptiert – zu nicht verhandelbaren Konditionen.

Die Innovations-Trophäe: Der US-Investmentbanker Oren Klaff postuliert in sei-

nem Werk „Pitch Anything“ (Klaff, 2011) die provokante These, dass Geld die ulti-

mative Massenware sei – jeder Mensch der Welt besitzt zumindest ein wenig da-

von und es ist global verfügbar. Klaff sieht daher wenig Sinn darin, eine/n InvestorIn

um Geld anzubetteln und damit aus einer Position der Schwäche auf Wohlwollen

zu hoffen. Er rät Entrepreneuren und Entrepreneurinnen, ihre Person bzw. Erfin-

dung als eine Art Trophäe hochzustilisieren und so einen Jagdinstinkt beim Gegen-

über auszulösen. Neben der bereits oben erwähnten Verknappungsstrategie kann

dies durch investigative Fragen erfolgen („Wir würden gerne wissen, ob Sie als

Kunde zu uns passen. Können Sie uns verraten, wie oft oder in welchem Stil Sie

fotografieren?“).

Positionierung gegenüber der Konkurrenz: der Innovator sollte den Vergleich

mit Konkurrenzprodukten nicht den VerbraucherInnen überlassen, sondern sein

Produkt aktiv gegen schwächelnde Produkte am Markt positionieren, um es attrak-

tiv und überlegen erscheinen zu lassen. Steve Jobs positionierte das erste iPad-

Modell von Apple 2010 gegen die damals sehr populären Netbooks, die allerdings

unter unterdimensionierter Hardware-Ausstattung und schlechter Ergonomie litten.

Die Strategie ging auf: in einer 2010 von Morgan Stanley in den USA durchgeführ-

ten Umfrage gaben 44% der amerikanischen iPad-KäuferInnen an, dieses anstatt

eines ursprünglich vorgesehenen Netbooks gekauft zu haben. Die Wachstumsraten

des Netbook-Marktes brachen in weiterer Folge drastisch ein.41

41

Quelle: http://tech.fortune.cnn.com/2010/05/06/how-the-ipad-gobbles-up-netbook-sales/

86

Vertrauen: der Vertrauensvorschuss der Interessierten („endlich einmal jemand,

der meine Probleme versteht und sie lösen möchte“) sollte im Verkaufsgespräch

bewusst genutzt werden.

Anwendung auf Trelew

Um die von Maurya empfohlene Vorgehensweise auf Trelew anwenden zu können, führte

der Autor zunächst eine Erhebung der Preismodelle bei jenen Photosharing-Anbietern

durch, die von den Befragten der problem interviews verwendet wurden. Aus Tabelle 3 ist

ersichtlich, dass alle Anbieter bis auf Smugmug.com ein Freemium-Modell verwenden, das

im Falle von Google Drive und Flickr.com sehr großzügig ausgelegt ist – in beiden Fällen

erhält der/die UserIn Gigabytes an Online-Speicher, ohne dafür bezahlen zu müssen. Mit

diesen Angeboten kann schon aus wirtschaftlicher Sicht nicht konkurriert werden. Aller-

dings laufen beide Dienste damit auch Gefahr, zur „Foto-Müllhalde“ zu werden, auf der

auch minderwertige Aufnahmen gebunkert werden. Aus Sicht der NutzerInnen erscheint

problematisch, dass beide Dienste nur Abteilungen der beiden Internet-Konzerne Google

und Yahoo bilden und deshalb häufigen unternehmensweiten Strategieänderungen

unterworfen sind (zum Beispiel die „Zwangsintegration“ des früher eigenständigen Photo-

dienstes Picasa Web in das unternehmenseigene soziale Netzwerk Google+).

Anbieter Preismodell

Google Drive 15 GB Speicher gratis42,

100 GB zu 4,99 USD/Monat

200 GB zu 9,99 USD/Monat

Flickr.com 1000 GB werbefinanzierter Speicher gratis43

1000 GB Speicher werbefrei zu 4,16 USD/Monat44

Smugmug.com Preisstaffelung erfolgt nach Produktfunktionen, alle Pro-

duktpakete beinhalten unlimitierten Upload von Fotos45.

Produktpakete:

Basic: 5 USD/Monat

Power: Basic + vollständig anpassbares Seitende-

sign: 8 USD/Monat

Portfolio: Power + Direktanbindung von Druck-

dienstleistern zur Bestellung von Fotonegativen: 20

USD/Monat

Business: Portfolio + erweiterte Bestellfunktionen

(Geschenkpapier, eigenes Antwortschreiben,...),

Mehrbenutzerfähig: 35 USD/Monat

42

Die erworbenen Speicherkontingente lassen sich auch mit anderen Google-Anwendungen wie dem E-Mail-Dienst Gmail

nutzen. Fotos mit einer Auflösung kleiner als vier Megapixel (2048x2048 Pixel) verringern das Speicherkontingent nicht. 43

Auf den Fotoseiten werden Werbebanner eingeblendet 44

Entspricht der Jahresgebühr von 49,90 USD

87

Anbieter Preismodell

500px.com Free: kostenlose Basisversion (maximaler Upload:

20 Bilder/Woche)

Plus: 25 USD/Jahr für unbeschränkte Uploads

Awesome: 75 USD/Jahr für anpassbare Portfolio-

Website

Tabelle 3: Preismodelle der Konkurrenzanbieter, Stand: November 2013

Smugmug.com hingegen verzichtet auf ein Freemium-Modell, hier werden in der kleinsten

Variante 5 USD/Monat fällig. 500px.com hat ein stark eingeschränktes Freemium-Modell

(maximaler Upload: 20 Bilder pro Woche), in der nächsten Stufe („Plus“) hingegen sofort

ein unbeschränktes Upload-Modell.

Bei näherer Betrachtung werden einige weitere Schwächen der Preismodelle offensicht-

lich:

Flickr verlangt zwar nur 49 Dollar für gigantische 1 TB Speicher, gleichzeitig ist dies

aber die „kleinste“ kostenpflichtige Produktversion. Will man sich also von Werbe-

einschaltungen freikaufen, bezahlt man um 100% mehr als noch vor einem Jahr

(Flickr Pro Abo um 24,95 US-Dollar im Jahr). Dieser Trend der erhöhten „Werbe-

frei“-Pönale könnte sich noch fortsetzen.

Starre Funktionalitäten: Produktfeatures wie die Nachbestellfunktion einzelner Bil-

der oder eine E-Shop-Einbindung lassen sich nicht auf Basis einzelner Fotokollek-

tionen aktivieren und bezahlen, sondern müssen pauschal für den gesamten

Account bestellt und bezahlt werden. Dies widerstrebt dem immer populärer wer-

denden „pay per usage“-Modell des Cloud-Computing.

Die Kontingentierung der Dienste erfolgt in Gigabytes, nicht in Fotos, obwohl diese

die „Basiseinheit“ der Fotoschaffenden darstellen. Die Ermittlung der im Kontingent

speicherbaren Bildanzahl ist schwierig, da dafür zahlreiche Variablen wie Bildauflö-

sung, Art der (verlustbehafteten) Kompression und das Bildmotiv selbst berück-

sichtigt werden müssen. Daher erschweren Gigabyte-Angaben die Kapazitätspla-

nung.

Preismodell für Trelew

Die von Maurya befürwortete „Raising Signup Friction“ wird im Preismodell von Trelew wie

folgt umgesetzt:

Verknappungsaspekt:

Nach dem Launch des MVP ist eine private-Beta-Phase geplant, bei der nur eine

geringe Anzahl eingeladener BenutzerInnen den Dienst nutzen kann.

45

Maximale Upload-Größe pro Bild: 50 MB

88

Trelew wird kein Freemium-Modell bieten, der Dienst ist kostenpflichtig. Eine

Kleinstmenge an Fotos kann aber kostenfrei hochgeladen werden, um Produkt-

funktionen zu testen. Das Limit ist so gewählt, dass eine über Demozwecke hin-

ausgehende Gratisnutzung von Trelew nicht möglich ist.

Das Preismodell selbst dient der Verankerung/Etablierung gegenüber der Konkur-

renz:

Trelew verzichtet gänzlich auf Werbeeinschaltungen und Zwangsintegration in sozi-

ale Netzwerke. Der Kunde oder die Kundin muss sich also nicht durch einen Auf-

preis von diesen unerwünschten Funktionen freikaufen.

Abgerechnet wird pro hochgeladenem Bild und Monat (gestaffelt in 1000er Blöcken

ab EUR 3 pro Monat), was den Fotografen die Kapazitätsplanung und Kostener-

mittlung erleichtert. Außerdem wird so der Vergleich mit den Gigabyte-dimensio-

nierten Produkten der Konkurrenz erschwert.

Der Basistarif deckt die gekachelte Vorschau des Bildes im Zoomify-Format und

dessen Download in einer maximalen Auflösung von fünf Megapixel ab. Weitere

Funktionalitäten stehen als aufpreispflichtige, monatlich stornierbare Erweiterungen

zur Verfügung:

o Kachelung im DeepZoom-Format (mehr Zoomstufen als bei Zoomify)

o Download bis zur tatsächlichen Auflösung des Bildes, Kostenpflichtiger

Download (Shop-Funktion)

o Wasserzeichen in Kacheln und/oder downgeloadeten Bildern als „Diebstahl-

schutz“, wahlweise mit Standardtext oder eigenem Logo.

o Retriever-Funktion (der/die UserIn kann mit downgeloadeten Bildern nach

dem Original suchen)

Diese Pay-per-usage-Funktion differenziert das Angebot von Trelew gegenüber

den starren Angeboten der Konkurrenz.

Mithilfe von Photo Cabinets kann der/die FotografIn unterschiedliche Trelew-

Konfigurationen innerhalb eines Accounts verwenden: beispielsweise ein „Privat-

fotos“-Cabinet, das die Funktionen des preisgünstigen Basistarifs nützt und ein

„Business“-Cabinet, das Wasserzeichen, DeepZoom-Format und andere Premium-

Features verwendet.

Shelve-Funktion: mit einem Klick kann ein Bild „offline“ genommen werden, damit

keine Kosten anfallen. Die Bilddaten bleiben aber in der Cloud gespeichert, sodass

es jederzeit online geschalten werden kann.

Ein bereits upgeloadetes Bild kann mit einer höher aufgelösten Version

„nachgebessert“ werden, ohne dass dafür zusätzliche Kosten anfallen.

89

Nachfolgend die Preisstaffeln für die Produktfunktionen:

Speicherkapazität Preis pro Monat

Erste 99 Fotos 0

99 – 1000 Fotos € 3,00

1000 - 2000 Fotos € 2,50

2000 - 3000 Fotos € 2,00

3000 - 4000 Fotos € 1,50

weitere 1000 Fotos je € 1

Tabelle 4: Preisstaffel für das Grundprodukt

Speicherkapazität Tiled Viewing (Aufpreis/Monat)

„Schneider“

Tile-Darstellung im Zoomify-Format

inkl. Farbraum-Konvertierung

„Petzval“

Tile-Darstellung im Deepzoom-

Format (50% mehr Zoomstufen)

inkl. Farbraum-Konvertierung

Erste 99 Fotos inklusive inklusive

99 – 1000 Fotos inklusive € 0,3

1000 - 2000 Fotos Inklusive € 0,25

2000 - 3000 Fotos inklusive € 0,2

3000 - 4000 Fotos inklusive € 0,15

weitere 1000 Fotos je inklusive € 0,1

Tabelle 5: Preisstaffel für Tiled Viewing

Speicherkapazität Download (Aufpreis/Monat)

„Talbot“

Zuschaltbarer Bild-

download bis 5 Megapi-

xel Auflösung

„Niepce“

Bilddownload in voller

Auflösung,

Photorequests ohne

Bezahlfunktion

„Daguerre“

Bilddownload in

voller Auflösung,

Photorequests mit

Bezahlfunktion

Erste 99 Fotos inklusive inklusive -

99 – 1000 Fotos inklusive € 0,15 € 0,3

1000 - 2000 Fotos

Inklusive € 0,13 € 0,25

2000 - 3000 Fotos inklusive € 0,10 € 0,2

3000 - 4000 Fotos inklusive € 0,08 € 0,15

weitere 1000 Fotos je inklusive € 0,05 € 0,1

Tabelle 6: Preisstaffel für Download

90

Speicherkapazität Watermarking (Aufpreis/Monat)

„Marey“

Addon zum Einfügen von Text-

Wasserzeichen in Bilder

„Morgan“

Addon für Wasserzeichen mit

SVG-Grafik (z.B eigenes Logo)

Erste 99 Fotos Inklusive inklusive

99 – 1000 Fotos € 0, 15 € 0,3

1000 - 2000 Fotos

€ 0,13 € 0,25

2000 - 3000 Fotos € 0,10 € 0,2

3000 - 4000 Fotos € 0,08 € 0,15

weitere 1000 Fotos je € 0,05 € 0,1

Tabelle 7: Preisstaffel für Watermarking

Produkt kapazitive Einzelpreise Gesamtsumme

Speicherung für bis zu 3000

Bilder

3 + 2,5 + 2 = 7,50€

Addon „Niepce“ 0,15 + 0,13 + 0,1 = 0,38€

Addon „Petzval“ 0,3 + 0,25 + 0,2 = 0,75€

8,63 €

Tabelle 8: Preisbeispiel für die monatliche Nutzung von Trelew bei 3000 gespeicherten Bildern

5.3.4 Durchführung der Solution Interviews

Maurya definiert ein solution interview als ein circa 30-minütiges, strukturiertes Interview,

das die Resonanz der Zielgruppe auf die wichtigsten Produktfunktionen testen soll. Da

diese nicht vollständig, sondern nur prototypenhaft umgesetzt wurden, kann der/die Entre-

preneurIn schneller und mit weniger Aufwand zu wertvollen Rückmeldungen kommen, als

dies bei herkömmlichen Produktdemonstrationen der Fall ist. Das solution interview ist

aber mehr als eine bloße Produktvorführung: Maurya empfiehlt, auch die Frage der Preis-

gestaltung des späteren in den Interviews zu behandeln und sie zur Verfeinerung der

Zielgruppendefinition zu nutzen (siehe hierzu die am Anfang des Kapitels formulierten

zentralen Fragen des solution interviews).

Maurya empfiehlt, die GesprächspartnerInnen für die solution interviews mehrheitlich aus

den TeilnehmerInnen der problem interviews zu rekrutieren. Da diese im Rahmen der

problem interviews bereits Einfluss auf die Produktidee genommen haben, sollte auch

einige neue Interessenten befragt werden, um die unbefangene Beurteilung des Lösungs-

ansatzes sicher zu stellen. (Maurya, 2012, p. 169)

91

Ablauf

Im Verlauf des solution interviews (siehe Abbildung 30) werden zunächst einige demografi-

sche Daten des Interviewten erhoben, um eine bessere Zielgruppendefinition erstellen zu

können. Im Fallbeispiel des Autors könnte dies beispielsweise die „professionelle Aktivität“

der Fotoschaffenden (Aufträge pro Monat) sein, um stärker zwischen haupt- und nebenbe-

ruflichen Tätigkeiten differenzieren zu können.

Abbildung 30: Aufbau eines Solution Interviews nach Maurya [Quelle: (Maurya, 2012, p. 170)]

Anschließend erläutert der/die EntrepreneurIn kurz die Motivation hinter dem Produkt, um

die/den Interviewte/n auf die nun folgende Demonstration des Prototyps einzustimmen.

Diese nimmt etwa die Hälfte der Interviewzeit ein und besteht aus der schrittweisen

Vorführung der vorab definierten wichtigsten Produktfeatures (siehe Kapitel 5.3.2). Nach

der Demonstration jedes Features wird der/die Interviewte um ein kurzes Feedback

gebeten, am Ende des Demonstrationsblocks priorisiert er/sie die vorgestellten Features

nach den persönlichen Bedürfnissen.

Danach kommt die Preisgestaltung des späteren Produktes zur Sprache: der/die Entrepre-

neurIn muss herausfinden, welchen Preis die Interviewten für das vorgestellte Produkt

bezahlen würden und diese Daten bei der späteren Gestaltung des Geschäftsmodells

92

berücksichtigen. Hierfür sieht Maurya einige besondere Strategien vor, die im vorigen

Abschnitt vorgestellt wurden.

Das Interview endet mit der Frage nach weiteren potentiellen Interessenten und Interes-

sentinnen im Bekanntenkreis des/der Interviewten, die für ein solution interview angefragt

werden können. Nach der Verabschiedung des Interviewgastes erfolgt die sofortige Doku-

mentation des Gesprächsinhalts, um Erinnerungslücken vorzubeugen.

Der Autor folgte bei seinen solution interviews diesem Ablauf, allerdings fand die „Neube-

fragung“ der Interviewpartner aus den problem interviews per E-Mail statt (75% der Inter-

viewpartner), lediglich die Neuinteressenten (25%) wurden persönlich befragt. Diese Ver-

einfachung war dem straffen Zeitplan der Masterarbeit geschuldet – die ausschließlich

persönlich durchgeführten problem interviews erstreckten sich über einen Zeitraum von

zwei Monaten, eine weitere zweimonatige Interviewrunde hätte den Fertigstellungsrahmen

dieser Masterarbeit gesprengt.

Die Zusammenfassungen der solution interviews sind im Anhang dieser Arbeit abgedruckt.

5.3.5 Ergebnisse der Solution Interviews

Akquisitionsrisiko: Wer braucht das Produkt?

Hypothesen

Hauptzielgruppe sind Fotoschaffende, deren Bildmaterial von einer größeren Personen-

gruppe in hoher Qualität und/oder Auflösung nachgefragt wird und die deshalb häufig

Nachbestellungen von Bildern bearbeiten müssen.

Erkenntnisse

Die Hauptzielgruppe wurde durch die Befragungen bestätigt. 50% der befragten Fotogra-

fen gaben aber an, mit der Problematik von Nachbestellungen auch im privaten, nicht-

kommerziellen Umfeld konfrontiert zu sein. Ein gängiges Szenario hierbei sind Fotodoku-

mentationen von Familienfeiern wie Hochzeiten und Geburtstagen, die von den Fotografen

kostenlos oder gegen Unkostenersatz abgewickelt werden, aber angesichts des hohen

Erinnerungswerts und der großen Menge an Teilnehmern viele Nachbestellungen von Bil-

dern generieren. Besonders für diese Ereignisse wünschen sich Fotografen eine professi-

onelle Abwicklung der Nachbestellungen.

Zum essentiellen Kriterium wird damit weniger die Tatsache, ob ein Fotograf seine Tätig-

keit haupt- oder nebenberuflich ausübt, sondern der Prozentsatz seiner Aufträge mit Publi-

kumswirkung.

93

Produktrisiko: Welche konkreten Funktionen sind nötig, um das Problem der

Kunden zu lösen?

Hypothesen

Kunden und Kundinnen von Fotoschaffenden würden gerne hochaufgelöste Vor-

schaubilder betrachten, scheuen aber große Downloads. Fotografen fürchten ille-

gale Verbreitung des Bildmaterials. Eine Schnellansicht hochauflösender Bilder im

Web-Browser auf Basis von Kachelbildern löst das Problem der großen Down-

loads, in die Bildkacheln integrierte Wasserzeichen verhindern eine illegale Nut-

zung des Bildmaterials.

Fotoschaffende möchten ihren Kunden und Kundinnen Bilder möglichst schnell zur

Verfügung stellen, auch von Orten mit langsamer Internet-Verbindung. Speicher-

sparende Upload-Formate wie JPEG XR können dieses Problem lösen.

Fotoschaffende erhalten häufig Nachbestellungen für hochaufgelöste Originalbilder

per E-Mail und müssen den fehlerbehafteten Bestellprozess manuell abwickeln.

Trelew vermeidet diese Fehler, indem es menügestützte Fotobestellungen direkt im

Viewer ermöglicht. Von Trelew downgeloadete Vorschaubilder bleiben mit der

Downloadquelle verknüpft, sodass der Kunde oder die Kundin nur das entspre-

chende Bild in das Browserfenster ziehen muss, um zum in Trelew gehosteten Ori-

ginalbild zu gelangen.

Ergebnisse

Die Demonstration der Foto-Schnellansicht mittels Prototyp wurde sehr positiv aufgenom-

men, die Interviewten lobten die gute Performance der Anwendung und zeigten sich auch

von der Einsatzmöglichkeit auf mobilen Endgeräten sehr angetan. Auf besonderes Inte-

resse stießen aber der beschleunigte Foto-Upload und die menügestützte Nachbestel-

lungsfunktion. Hier hätten sich die meisten Befragten eine umfangreichere Demo ge-

wünscht, standen aber dem damit verbundenen Software-Download eher ablehnend ge-

genüber.

Weitere Anregungen betrafen die Unterstützung verschiedener Farbprofile, um eine opti-

male Farbdarstellung der Bilder sicherzustellen, sowie Verbesserungen bei den Texten der

Marketingseite. Einige der Feature-Überschriften wurden als zu unspezifisch bemängelt.

Beispielsweise drückt die Überschrift „Show full-resolution images on any device“ für die

meisten Befragten keinerlei Differenzierungsmerkmal zu den etablierten Photosharing-

Plattformen aus. Auch diese bieten eine Downloadfunktion für hochauflösende Bilder an.

Erst die Tatsache, dass durch die Kacheltechnologie eine um bis zu 90% schnellere An-

zeige als beim herkömmlichen Download des Bildes erfolgen kann, stellte für die Befragten

ein „killer feature“ dar.

94

Als „Learning“ wird der Autor die Marketingtexte konkretisieren, um den Wettbewerbsvor-

teil der einzelnen Features besser zur Geltung zu bringen. Ergänzend werden einfache,

auf HTML-Animationen beruhende Demofunktionen in die Marketingseite eingebaut. Die

Zeitersparnis durch den JPEG-XR-Upload im Vergleich zum JPEG-Upload lässt sich bei-

spielsweise über zwei animierte Ladebalken veranschaulichen. Durch den Download der

verwendeten Demofotos kann sich der/die BenutzerIn von der gleichwertigen Qualität der

JPEG-XR-Daten überzeugen.

Marktrisiko: Wie sieht das Preismodell aus?

Hypothese

Die Zielgruppe bevorzugt ein Preismodell mit flexibler, bildbasierter Abrechnung, um ihre

Kosten präziser planen zu können.

Ergebnisse

Die Befragten stehen einem nutzungsbasierten Preismodell positiv gegenüber, erwarten

sich aber eine verständliche und genaue Abrechnung.

5.3.6 Verifizierung der Exit-Kriterien

Maurya (Maurya, 2012, p. 178) definiert folgende Exit-Kriterien für die solution interviews:

1. Demographische Eigenschaften der Zielgruppe sind bekannt

2. „must-have problem“: Die Dringlichkeit und Lösungswürdigkeit des Problems wurde

von der Zielgruppe akzeptiert

3. Benötigte Mindestfunktionalität zur Lösung des Problems ist bekannt und wurde in

den solution interviews anhand von Prototypen demonstriert.

4. Preis(modell) wird vom Kunden/von der Kundin akzeptiert

5. Aus der Preisgestaltung lässt sich ein tragfähiges Geschäftsmodell ableiten.

Wie dieses Kapitel zeigte, konnten die vom Autor durchgeführten solution interviews die

genannten Exit-Kriterien erfüllen: als Kernzielgruppe haben sich Fotoschaffende mit häufi-

gen privaten und geschäftlichen Auftragen herauskristallisiert, die ihre Bilder einer größe-

ren Menge an Personen präsentieren müssen. Die vom Autor angenommenen Haupt-

probleme dieses Unterfangens – die Präsentation des hochauflösenden Bildmaterials im

Internet sowie die mühsame Abwicklung von Nachbestellungen – wurden von der Ziel-

gruppe bestätigt und der in Form eines Prototypen präsentierte Lösungsansatz begrüßt.

Das nutzungsbasierte, nicht-pauschalierte Abrechnungsmodell stieß ebenso auf positive

Resonanz, aus ihm lässt sich ein tragfähiges Geschäftsmodell ableiten.

95

5.3.7 Überleitung in ein MVP – Minimum Viable Product

An dieser Stelle war die schrittweise Überführung der Funktionalitäten des Prototypen in

ein minimum viable product geplant. Den Anfang sollte die browserbasierte Schnellansicht

für hochauflösende Bilder machen, für ihre Umsetzung hat der Autor einen Aufwand von

circa 50 Stunden geschätzt. Da sich diese Arbeiten nicht mehr vor dem Redaktionsschluss

der Masterarbeit per 29.12. 2013 realisieren ließen, kann hier kein Bezug mehr auf sie

genommen werden. Der Autor beabsichtigt aber, auf seinem Blog unter

http://leancanvasthesis.wordpress.com/ über den weiteren Fortschritt von Trelew zu

informieren.

96

6 Diskussion

Nachdem in den vorangegangenen vier Kapiteln die Durchführung eines Lean-Canvas-

Projektes ausführlich geschildert wurde, sollte dieser Abschnitt der Analyse und Bewertung

des durchgeführten Projektes dienen. Er wird mit einer persönlichen Reflexion des Autors

eingeleitet, welche die positiven und negativen Erfahrungen des Autors mit Running Lean

zum Inhalt hat. Anschließend erfolgt eine Analyse und Bewertung der durch Running Lean

verfeinerten Produktidee sowie der Methode Running Lean selbst. Daraus ergeben sich

die abschließenden Empfehlungen zum Einsatz von Running Lean für persönliche und

betriebliche Innovationsprojekte.

6.1 Persönliche Reflexion

Der Autor setzte Running Lean über einen Zeitraum von sechs Monaten (Juli – Dezember

2013) ein. Sein Ausgangsziel bestand darin, die ursprüngliche Produktidee „Online-Editor

für Camera RAW-Dateien“ möglichst rasch und unverändert umzusetzen. Durch den Ein-

satz von Running Lean sollte lediglich die bereits sehr detailliert konzipierte Idee mit Hilfe

der Interviews bestätigt und an ihr eventuell Detailverbesserungen vorgenommen werden.

Das Hauptmotiv für den Einsatz von Running Lean sah der Autor aber in der Akquise von

Kundinnen und Kunden. Diese war für die Umsetzung der Produktidee notwendig, aber

aufgrund mangelnder Verkaufserfahrung schwierig. Der Autor nahm Running Lean also

anfänglich als Verkaufs- und Vermarktungstechnik für seine bereits bestehende Produk-

tidee wahr.

Die von Running Lean propagierte frühe und umfassende Einbindung von Kunden in den

Ideenentwicklungsprozess bewirkte beim Autor aber ein Umdenken und ganzheitliches

„Einlassen“ auf den Lean-Canvas-Prozess, da im Zuge der Projektumsetzung zahlreiche

positive Effekte auftraten:

Beim erstmaligen Befüllen des Lean-Canvas-Rasters mit der Grundidee zeigten

sich einige konzeptionelle Lücken in der Produktidee, die aufgrund der Anweisun-

gen ad hoc geschlossen werden konnten. Beispielsweise war im Ursprungskonzept

eine Zielgruppendefinition vorhanden, an die Kommunikationskanäle zum Errei-

chen dieser Zielgruppe wurde aber nicht gedacht.

Die Aufteilung der Urspungsidee in mehrere, durch Experimente verifizierbare

Einzelhypothesen („Fotoschaffende wollen ihre digitalen Negative auf Tablets be-

arbeiten“) erleichterte nicht nur ihre Validierung, sondern auch die Kommunikation

der Idee Dritten gegenüber.

Im Zuge der problem interviews kam es sehr schnell zur gewünschten

Konkretisierung der Produktidee in Bezug auf Funktionsumfang, Zielgruppe und

97

Geschäftsmodell. Durch Zustimmung oder Ablehnung der vom Autor präsentierten

Hypothesen wurde die ursprüngliche, sehr umfangreiche Produktidee auf wenige,

erfolgversprechende Aspekte zurechtgestutzt. Dies erhöhte wiederrum die Umset-

zungswahrscheinlichkeit des Endproduktes. Die Ablehnung der vom Autor favori-

sierten RAW-Bearbeitungsfunktion durch die Kunden mag zwar im ersten Moment

schmerzhaft gewirkt haben, auf lange Sicht konnte sich der Autor dadurch aber

hohe und unnötige Aufwendungen ersparen.

Der in Running Lean sehr gut spezifizierte Pivot-Prozess erlaubte ein strukturiertes

und rasches Umdenken der Produktidee nach den problem interviews.

Während die Durchführung der problem interviews circa zwei Monate in Anspruch

nahm, konnte die Dauer der nachfolgenden solution-interview-Phase durch mehr-

heitliche Durchführung von E-Mail-Interviews auf nur ein Monat verkürzt werden –

und das trotz des Mehraufwands durch die Prototypen-Entwicklung.

Am Ende der solution-interview-Phase stand die Spezifikation eines minimal

nutzbaren Produktes (MVP), das mit einem geschätzten Arbeitsaufwand von circa

50 Stunden umsetzbar ist und danach bereits von Kunden getestet werden kann. In

ursprünglichen Schätzungen war der Autor von einem vielfach höheren Aufwand

ausgegangen.

Die Mehrheit der Interviewten hat Interesse an einem Beta-Test des Produktes in

der MVP-Phase bekundet, weshalb 7 der 10 vorgesehenen Beta-User-Plätze be-

reits vergeben sind.

6.1.1 Positive Aspekte

In der Gesamtbetrachtung des Projektablaufs haben sich folgende Versprechungen von

Running Lean erfüllt:

Für die Evaluierung der Produktidee waren kaum finanzielle Investitionen not-

wendig, die budgetierten 1000 EUR pro Monat wurden nicht einmal ansatzweise

verbraucht. Das Versprechen der risikolosen Evaluierung von Produktideen hat

sich also erfüllt (sofern keine Opportunitätskosten für die investierte eigene Arbeits-

zeit angesetzt werden).

Die in das Lean-Canvas-Projekt investierte Arbeitszeit betrug im Durchschnitt

acht Wochenstunden und wurde vom Autor zusätzlich zu den 38,5h gesetzli-

cher Wochenarbeitszeit als Vollzeit-Angestellter geleistet. In Anlehnung an den

vom Technologiekonzern Google geprägten Begriff des „20%-Projektes“ (der/die

ArbeitnehmerIn kann 20% der Arbeitszeit für eigene Innovationsprojekte verwen-

den) könnte man von einem „120%-Projekt“ sprechen, da die 8h oder 20% der Ar-

beitszeit zusätzlich zu den 100% Kernarbeitszeit geleistet wurden. Diese investierte

Arbeitsleistung reichte für die Fortführung des Projektes aus, wobei der Arbeitsauf-

wand für das Verfassen der projektbegleitenden Diplomarbeit nicht enthalten ist.

98

Der Autor sieht seine zentrale Hypothese einer berufsbegleitenden Durchführbar-

keit von Running Lean-Projekten dadurch bestätigt.

Als wichtig stellte sich aber eine möglichst kontinuierliche Arbeit an dem Pro-

jekt heraus. Längere, mehrwöchige Projektpausen wären im Hinblick auf die inten-

siv eingebundenen Interessenten kontraproduktiv gewesen, zumal dadurch ein

Eindruck entstehen könnte, das Projekt wäre eingeschlafen.

80% der in den problem interviews befragten Personen konnten auf Nach-

frage weitere potentielle Interessenten aus dem eigenen Bekanntenkreis für

das Projekt des Autors nennen. Obwohl es aus Zeitgründen nicht möglich war,

all diese Interessenten in das Projekt einzubinden, zeigt dieses Verhältnis die

„Mächtigkeit“ persönlicher Interviews in Bezug auf die Gewinnung neuer potentieller

Kundinnen und Kunden.

Im Laufe der Fallstudie hat sich gezeigt, dass Running Lean-Projekte nicht

unbedingt von mehreren Personen durchgeführt werden müssen. Obwohl

Trelew aus Zeitgründen als Einpersonenprojekt gestartet wurde – bei einer durch

die Terminierung der Masterarbeit vorgegebenen Projektlaufzeit von sechs Mona-

ten fehlte schlicht die Zeit für die Rekrutierung zusätzlicher Projektmitglieder – lag

die Arbeitslast nie allein auf den Schultern des Autors. Im Zuge der Projektinter-

views lernte er MitstreiterInnen kennen, die Einzelaufgaben wie Logodesign oder

Implementierung einzelner Prototypen übernahmen. Diesen UnterstützerInnen wa-

ren aber keine vollwertigen Projektmitglieder, sodass zeitaufwändige Abstim-

mungssitzungen entfallen konnten.

6.1.2 Herausforderungen

Im Laufe der sechsmonatigen Anwendung von Running Lean haben sich aber nicht nur

positive Aspekte der Methode gezeigt, es gab auch Verfahren und Situationen, die der

Autor als herausfordernd empfungen hat:

Das zentrale Mantra von Running Lean und anderer von Lean Management

inspirierter Methoden lautet „Vermeide Verschwendung und arbeite dadurch

effektiver!“. Bei der praktischen Berücksichtigung dieser Maxime stieß der Autor

auf einige Schwierigkeiten

– Verschwendung ist oft nicht vorweg erkennbar: erst nachdem ein

Prozess (z.B. Planung und Durchführung eines customer interviews)

mehrfach durchlaufen wurde, sind genug Erfahrungswerte vorhanden,

um zeitraubende Einzelaktivitäten dieses Prozesses zu identifizieren

und zu verbessern.

– Nicht nur ein „zuviel“, sondern auch ein „zuwenig“ ist Verschwen-

dung: Die Forderungen nach möglichst schlanken Prozessen ließ den

Autor einige voreilige Abkürzungen nehmen, die sich später rächten.

Beispielsweise wurden Screendesigns für die Prototypen ursprünglich in

99

Photoshop umgesetzt und nicht in HTML und CSS implementiert. Dies

sparte zwar anfänglich etwa die Hälfte der Arbeitszeit, die Inter-

viewpartner monierten aber die mangelnde Interaktivität der Screende-

signs. Dadurch wurde erst recht die Komplettumsetzung in HTML und

CSS erforderlich.

– Verschwendung ist oft eine Frage der Perspektive: Im Zuge des

Canvas-Projektes nahm der Autor zwei Perspektiven ein – jene des

Produktentwicklers/Innovators und jene des Software-Entwicklers. Wäh-

rend es aus Sicht des Produktentwicklers wichtig war, Prototypen mög-

lichst schnell zu entwickeln und die Code-Qualität im Hinblick auf die

ungewisse Lebensdauer des Prototypen eher vernachlässigbar er-

schien, strebte der Software-Entwickler nach der zumindest anfangs

zeitaufwändigeren Einhaltung der best practices des Software-Enginee-

ring. Beide Sichtweisen haben ihre Berechtigung – schnell implemen-

tierte Prototypen ermöglichen rascheres Feedback der Kunden, können

aber bei Weiterverfolgung der Idee durch mangelnde Code-Qualität zum

Problem werden. Nach allen Regeln der Programmierkunst fertigge-

stellte Prototypen hingegen überzeugen mit besserer Wart- und Erwei-

terbarkeit, brauchen aber anfangs mehr Zeitaufwand – der im Falle einer

Ablehnung durch den Kunden oder die Kundin umsonst gewesen sein

könnte. Die Vermeidung von Verschwendung erwies sich unter diesen

Gesichtspunkten als ein objektiv unlösbares Problem

Management von technical debt. Der amerikanische Programmierer Ward

Cunningham beschrieb das im vorigen Punkt geschilderte Spannungsverhältnis

als technical debt46 (technische Schuld), die durch Vernachlässigung der Code-

Qualität zugunsten von Fertigstellungstermin und Funktionsumfang auf das

Projekt geladen wird. Ist zuviel technical debt angehäuft, droht der technische

Bankrott des Projektes. Der Autor von Lean Startup, Eric Ries, ist hingegen der

Ansicht, dass sich Startups aufgrund hoher Entwicklungsgeschwindigkeit und

Ungewissheit auf technical debt einlassen müssen. Dem kontinuierlichen

Management von technical debt komme allerdings eine große Bedeutung zu.47

Dieser Umgang mit technischer Schuld erfordert allerdings viel Erfahrung, die

man von einem Lean-Canvas-Neuling nicht erwarten kann.

Die von Running Lean geforderte kontinuierliche Umsetzung einer neuarti-

gen Idee im Kontext hoher Ungewissheit stellt auch hohe Anforderungen

an den verwendeten Technologie-Stack: einerseits soll die Umsetzung neu-

artiger, innovativer Produkte ermöglicht werden – eine Forderung, die tendenzi-

ell eher von neuen, noch nicht ausgereiften Technologien erfüllt wird. Anderer-

46

vgl.: http://martinfowler.com/bliki/TechnicalDebt.html 47

vgl.: http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html

100

seits soll die Produktumsetzung mit planbaren, minimalem Aufwand vonstatten

gehen – was wiederrum für etablierte Technologien spricht, die ihre „Kinder-

krankheiten“ überwunden haben. Leider lässt Running Lean den/die Entrepre-

neurIn in der heiklen Frage der Technologieauswahl alleine, und das, obwohl es

im von Running Lean vielfach referenzierten Toyota Production System sogar

ein Selektionsprinzip für Technologien gibt („Principle 8: Use only reliable,

thoroughly tested technology that serves your people and processes“ (Liker,

2003, p. 39))

Da der Autor in seiner bisherigen Karriere nicht im Verkauf tätig war, fiel es ihm

trotz wohlwollendem Interesse seiner Interviewpartner schwer, ihnen ein finan-

zielles „Commitment“ (z.B. kostenpflichtige Monatsmitgliedschaft) zum Produkt

abzuringen. Als verkaufshemmend wirkte zudem die Tatsache, dass noch kein

fertiges, nutzbares Produkt zur Verfügung stand. Der Autor plant daher, nach

Umsetzung des MVP ein stärkeres Augenmerk auf Verkaufsaktivitäten zu rich-

ten.

Die als persönliche, mitunter mehrstündige Gespräche durchgeführten prob-

lem/solution interviews erwiesen sich als ein sehr wichtiges Element von

Running Lean, stellten aber gleichzeitig einen großen „Blocker“ im Projektfort-

schritt dar. Durchschnittlich vergingen drei Wochen zwischen Erstkontakt zum

Interviewpartner und der tatsächlichen Durchführung des Interviews. Durch die

mindestens 30-minütige Dauer können problem/solution interviews aber nur

schwer spontan durchgeführt werden (z.B. im Rahmen von Fotomessen). Für

einen effizienteren Befragungsprozess müsste also bei weiteren Interviews die

„Anbahnungsphase“ zwischen Erstkontakt und Interviewtermin drastisch ver-

kürzt werden.

Der Lean Canvas-Raster eignete sich hervorragend zur Darstellung des Ist-

Status der Idee, aber nicht, um bereits verworfene und geprüfte Hypothe-

sen zu archivieren. Dieser „Erfahrungsschatz der Vergangenheit“ kann aber

bei der zukünftigen Produktplanung eine wichtige Rolle spielen. Der Autor ver-

suchte, ein „Hypothesen-Archiv“ aufzubauen, indem er mehrere Versionen sei-

nes Lean Canvas-Dokuments abspeicherte. Allerdings war auch dieses Vorge-

hen unzureichend, da im Canvas aus Platzgründen nur eine Kurzfassung der

Hypothesen dargestellt werden konnte. Eine Verlinkung dieser Kurzeinträge mit

einer ausführlichen Beschreibung abseits des Lean-Canvas-Rasters erscheint

notwendig.

101

6.2 Bewertung der Methode „Running Lean“

Running Lean ist eine nötige und sehr hilfreiche Konkretisierung der Lean Startup-

Methode, die besonders auf angehende Entrepreneure und Intrapreneurinnen abzielt. Ihr

„Erfinder“, Ash Maurya, hat sie entwickelt, als er bei der Umsetzung der Rezepte aus

anderen Startup-Büchern für seine ersten Produkte auf Schwierigkeiten stieß. Der Autor

kann dieser Motivation beipflichten: die im Standardwerk „The Lean Startup“ präsentierten

Werkzeuge werden aus der Perspektive eines bereits etablierten Software-Unternehmens

vorgestellt, das sich an die Entwicklung neuartiger Produkte macht. Der Detaillierungsgrad

der vorgestellten Werkzeuge leidet mitunter an den zahlreichen eingeflochtenen Anekdo-

ten, in ihrer thematisch gruppierten Darstellungform fehlt ein Anwendungsrahmen, der

Schritt für Schritt die konkrete Umsetzung demonstriert.

Running Lean beseitigt diese Defizite. Ash Maurya hat aus den vielen Lean-Startup-Werk-

zeugen jene ausgewählt, die besonders in der Frühphase eines Startups relevant sind –

darunter fallen in erster Linie die Durchführung von problem/solution-Interviews, die

„schlanke“ Entwicklung von Prototypen sowie Kniffe zur raschen Umsetzung von minimum

viable products. Die umsetzungsfreundliche, mit einer Fallstudie konkretisierte Präsenta-

tion dieser Werkzeuge erleichtert auch Startup-Neulingen ihre Anwendung (vgl. beispiels-

weise die detaillierten Anweisungen zur Durchführung von customer interviews).

Der namensgebende Lean-Canvas-Raster eignet sich sehr gut für die ganzheitliche Dar-

stellung und Ausarbeitung von Produktideen.

In puncto Technologieauswahl lässt Running Lean den/die AnwenderIn leider etwas im

Stich: im Dickicht der immer zahlreicher werdenden Web-Technologien jene auszuwählen,

die für das erdachte Produkt geeignet scheinen, stellte den Autor vor unerwartete Schwie-

rigkeiten, Running Lean bot hier wenig methodische Unterstützung.

Die Empfehlung von Running Lean, am Produkt Interessierte schon im Rahmen der

solution interviews zu eine finanzielle Zusage abzuringen, wird nicht für alle Produkttypen

und Märkte funktionieren: in bereits umkämpften Märkten wie jener der Photosharing-

Plattformen wird der Kunde oder die Kundin zuerst das fertiggestellte Produkt testen wol-

len, bevor eine kostenpflichtige Mitgliedschaft abgeschlossen wird. Der Erfolg des Cloud-

Speicherdienstes Dropbox zeigt aber, dass man auch in scheinbar gesättigten Märkten

Erfolg haben kann, wenn man Kundenbedürfnisse mit Unterstützung neuer Technologien

konsequent umsetzt.

Insgesamt eignet sich Running Lean aber sehr gut für den Einstieg in die Welt der agilen

Produktentwicklung. Die in Ash Mauryas Buch „Running Lean“ angeführten Kochrezepte

102

lassen sich auch von Neulingen gut umsetzen, nach mehrmaliger Anwendung kann man

die Methode dann an eigene Bedürfnisse und best practices anpassen.

Bei der Umsetzung der Fallstudie stellte der Autor keinerlei Konflikte mit den rechtlichen

und gesellschaftlichen Rahmenbedingungen in Österreich fest, die sich ja stark von jenen

der USA, dem Entstehungsland von Running Lean, unterscheiden.

Running Lean kann sowohl in einem privaten als auch beruflichen Szenario eingesetzt

werden. Auf die nötigen Rahmenbedingungungen wird im nächsten Abschnitt eingegangen

werden.

6.3 Bewertung der Produktidee

Die ursprüngliche Produktidee eines Online-Editors für Camera RAW-Dateien wurde vom

Autor schon vor der Anwendung von Running Lean bearbeitet: etwa 50 Arbeitsstunden

flossen in Technologierecherche, Marktanalyse, Konzeption und Verschriftlichung der Idee.

Feedback von potenziellen Anwendern und Anwenderinnen wurde in dieser Vorideen-

phase allerdings nicht eingeholt, was sich als entscheidender Fehler herausstellte: bereits

in der problem interview-Phase wandten sich die befragten Anwender gegen die zentralste

Funktion der Idee, die cloudgestützte Bearbeitung und Speicherung von Camera-RAW-

Bildern.

In der vom Autor eher als nebenläufiges Feature beurteilten Kacheldarstellung hochauflö-

sender Bilder im Web-Browser erkannten sie hohes Potential, sodass sich der Fokus der

weiteren Produktentwicklung auf diese Funktion verschob.

Derartige Perspektivenwechsel, bei denen eine Nebenfunktion plötzlich zum zentralen

Aspekt der Produktidee wird, sind bei Startup-Ideen nicht ungewöhnlich: Eric Ries be-

zeichnet sie als Zoom-In-Korrektur, da der zu breit angelegte Funktionsumfang des Pro-

duktes durch intelligentes Einzoomen beschnitten wird (Ries, 2012, p. 158).

Im weiteren Anwendungsverlauf von Running Lean entwickelte sich die Idee aber

„wunschgemäß“ in Richtung eines Fotoportals für hochauflösende und hochqualitative

Aufnahmen weiter: durch diese Zoom-In-Korrektur, welche im Pivot-Prozess initiiert und

und in den folgenden Solution Interviews weiter präzisiert wurde, ergab sich ein in nur etwa

50 Arbeitsstunden umsetzbares minimum viable product.

Die ultimative Bestätigung der Produktidee durch zahlende Kunden und Kundinnen konnte

zwar noch nicht erreicht werden, dieser Umsetzungsaspekt musste aus Zeitgründen zu-

rück gestellt werden.

103

Der Autor als Ideengeber und Anwender von Running Lean ist aber mehr als zufrieden mit

den erreichten Ergebnissen und beabsichtigt die Weiterverfolgung der Produktidee über

den Abschluss dieser Masterarbeit hinaus.

6.4 Empfehlungen

Nach der Bewertung von Running Lean und der damit verfolgten Produktidee möchte der

Autor seine Erfahrungen in Form von Handlungsempfehlungen für den betrieblichen und

privaten Einsatz von Running Lean weitergeben. Dieses Kapitel versucht zunächst, geeig-

nete Einsatzzwecke für Running Lean in beiden Bereichen darzulegen und geht anschlie-

ßend auf die erforderlichen Rahmenbedingungen ein.

6.4.1 Praktischer Einsatz von Running Lean

Obwohl in der Fallstudie dieser Arbeit nur ein privates Lean-Canvas-Projekt verfolgt wurde,

das nicht in Verbindung zu einem existierenden Unternehmen steht, sieht sich der Autor

durchaus in der Lage, auch Empfehlungen für den betrieblichen Einsatz von Running Lean

auszusprechen: er führte sein Lean-Canvas-Projekt neben einer Vollzeit-Beschäftigung als

Angestellter durch und musste die in das Projekt investierte Arbeitszeit mit dieser Tätigkeit

abstimmen.

Betrieblicher Einsatz

In betrieblichen Innovationsprojekten findet sich häufig ein ähnliches Szenario: die Pro-

jektmitglieder können aus Kosten- und Qualifikationsgründen nicht einfach vom Tagesge-

schäft freigestellt werden und müssen daher sowohl die täglichen Routineangelegenheiten

als auch die angestrebten Projektziele erfüllen. Denkbar ist aber die Entlastung von einzel-

nen Aufgaben des Tagesgeschäfts, um mehr Handlungsspielraum im Innovationsprojekt

zu erhalten. Die Höhe dieses Handlungsspielraums (in Stunden) kann durchaus aus der

Fallstudie des Autors abgeleitet werden: es zeigte sich, dass ab einem wöchentlichen

„Investment“ von ca. 8 Stunden pro Projektmitglied sinnvoll an einem Running Lean-

Projekt gearbeitet werden kann.

Doch für welche betrieblichen Einsatzzwecke eignet sich Running Lean? Steve Blank defi-

niert ein Startup als „...organization formed to search for a repeatable and scalable

business model“48. Die von Blank erwähnten skalierbaren Geschäftsmodelle

(Einnahmequellen) sucht ein Unternehmen am ehesten bei der Entwicklung neuartiger

Produkte, mit denen es bisher noch wenig Erfahrung gesammelt hat. Daher kann die Qua-

lifizierung neuartiger Produktideen ein Einsatzgebiet von Running Lean darstellen.

48

vgl. http://steveblank.com/2010/01/25/whats-a-startup-first-principles/

104

Diese enge, ausschließlich auf monetäre Vorteile begründete Daseinsberechtigung für

Startups gilt aber heute als überholt: bei der Lean Startup Konferenz 2013 präsentierten

viele Behörden und nicht-profitorientierte Vereine ihre Einsatzzwecke für Lean-Startup-

Methoden: die US-Organisation Blackgirlscode49 entwickelte damit ein Trainingsprogramm

für farbige Mädchen, um diesen die am US-Arbeitsmarkt immer wichtiger werdenden Pro-

grammierkenntnisse altersgerecht zu vermitteln. Es handelt sich dabei um eine sehr wich-

tige Initiative, da diese Kenntnisse häufig nur in kostenpflichtigen, universitären Bildungs-

angeboten vermittelt werden, die für ärmere Familien nicht leistbar sind.

Im betrieblichen Umfeld kann also Running Lean nicht nur für die Entwicklung neuer Pro-

dukte zum Einsatz kommen, sondern auch für die Weiterentwicklung umfangreicherer

Verbesserungsideen zur Erreichung verschiedenster Unternehmensziele genutzt werden:

Erhöhung der Kundenzufriedenheit, Senkung der Beschäftigtenfluktuation, Qualifizie-

rungsoffensiven etc. Die Abgrenzung zum „einfachen“ Verbesserungsvorschlag, wie er im

Rahmen von Qualitätszirkeln geäußert wird, kann aufgrund budgetärer Grenzen gezogen

werden: Wenn der Vorschlag nur mit größerem finanziellem oder organisatorischen Auf-

wand umsetzbar ist, dann sollte er erst in einem „Running Lean“-Experiment geprüft wer-

den, bevor er tatsächlich umgesetzt wird.

Wichtig für den erfolgreichen Einsatz von Running Lean sind kleine, interdisziplinäre

Teams, die möglichst autonom arbeiten können. Sie sollten Konzeptions- und Umset-

zungskompetenz vereinen und nicht mehr als acht Personen umfassen. Nicht jede/r Be-

troffen/e der (Produkt-)Idee muss gleich Mitglied des Projektteams werden, auch die be-

fragten Personen können in den Interviews ihre Vorstellungen einbringen.

Den Abschluss eines betrieblichen Lean-Canvas-Projektes bildet wie in der Fallstudie die-

ser Arbeit ein minimum viable product: das neue, prototypisch in wenigen Einzellektionen

umgesetzte betriebliche Bildungsprogramm, das nach der Genehmigung durch die Ge-

schäftsführung in einer neuen Firmenakademie vermittelt wird, die in Zusammenarbeit mit

einer externen Maklerfirma gegründete Umzugsberatung, welche mehr Bewerber für den

Unternehmensstandort begeistern soll etc.

Der Vorteil für das Unternehmen: erst nach Evaluierung des de-facto investitionsfreien

Startup-Experiments muss eine endgültige Entscheidung über die Umsetzung der Idee

getroffen werden, auf diese Weise können teure Flops vermieden werden.

49

vgl. http://www.blackgirlscode.com/

105

Privater Einsatz

Viele der bereits im vorigen Abschnitt genannten Zwecke treffen auch für den privaten Ein-

satz von Running Lean zu: die Methode eignet sich vor allem für die Perfektionierung eige-

ner Geschäftsideen im Hinblick auf die zukünftige Selbstständigkeit.

Unterschiede gibt es in der Durchführung: einem/r privaten „EinzelkämpferIn“ fehlt die

Unterstützung der betrieblichen Infrastruktur – sowohl in personeller wie manchmal auch in

finanzieller Hinsicht.

Wie die Erfahrungen des Autors zeigen, sollte man sich dadurch aber nicht entmutigen

lassen, ein Startup mit Running Lean zu beginnen: ist die Idee einmal verständlich und

schlüßig zu Papier gebracht oder gar bereits in Prototypen umgesetzt, fällt es wesentlich

leichter, MitstreiterInnen für die eigene Sache zu gewinnen als mit bloßen Worten.

Die große Herausforderung für Einzel-Startups ist die Vereinigung vieler, teils einander

widersprechender Rollen in einer Person: ProduktentwicklerIn, VerkäuferIn und Program-

miererIn lassen sich nur schwer in einer Person vereinen. Umgekehrt droht bei Mehrper-

sonen-Startups ein höheres Konfliktpotential, da die in der Frühphase des Startups oft sehr

breit angelegte Produktidee sich in Richtung einer möglichen Umsetzung verengen muss –

in der sich mitunter nicht alle Teammitglieder wiederfinden.

Am Ende eines privaten Running-Lean-Projekts sollte neben einem minium viable product

auch die Entscheidung darüber stehen, ob man dieses nun hauptberuflich weiterverfolgen

möchte oder nicht. Diese Entscheidung fällt nicht immer leicht, zumal nur wenige Startup-

Projekte abheben und es auch bei erfolgreichen Startup-Projekten zu Seitwärtsbewegun-

gen ohne momentane Wachstumstendenz kommen kann.

Tabelle 9 stellt die beiden Einsatzbereiche einander gegenüber:

Betrieblicher Einsatz Persönlicher Einsatz

Einsatzzwecke Qualifizierung umfangreicherer

(Produkt-) Ideen, Ergänzung

zum betrieblichen Vorschlags-

wesen

Perfektionierung eigener

Geschäftsideen, Vorberei-

tung der eigenen Selbststän-

digkeit

Teamgröße 1 -8 Personen, ab 4 Personen

Trennung in Problem und

Solution-Teams

1-4 Personen50

50

diese Empfehlung geht davon aus, dass die Abstimmung zwischen den TeilnehmerInnen eines privaten Running-Lean-

Projektes schwieriger zu bewerkstelligen ist als bei einer innerbetrieblichen Anwendung (beispielsweise aufgrund

verschiedener ArbeitgeberInnen). Daher empfiehlt der Autor für diesen Fall kleinere Gruppengrößen.

106

Betrieblicher Einsatz Persönlicher Einsatz

Teamkomposition Interdisziplinär, mit Konzepti-

ons- und Umsetzungskompe-

tenz

Möglichst interdisziplinär,

Grundkompetenzen für Pla-

nung und Umsetzung sollten

gegeben sein, Outsourcing

erweiterter Kompetenzen

möglich.

Durchführungszeitraum 6 – 12 Monate

Zeitaufwand pro Woche

und Teammitglied

ab 8 Wochenstunden

Positionierung im Inno-

vationsprozess

Begleitung einer Idee bis hin

zur Frontend-Phase

Von der Idee zum finalen

Businessplan

Art der Einführung Schrittweise Einführung über

Mentoren-Modell, anfangs

nicht für zeitkritische Projekte

verwenden.

Kontinuierliche Anwendung

über einen längeren Zeit-

raum (ggf. mit verschiedenen

Projekten), um die nötige

Methodenkompetenz zu er-

werben.

Tabelle 9: Einsatzempfehlungen für Running Lean

6.4.2 Einsatzkriterien

Im Zuge der Fallstudie konnte der Autor folgende Erfolgsfaktoren für Lean-Canvas-Pro-

jekte ermitteln, die sich einerseits aus der verwendeten Literatur, andererseits aus den

gewonnenen praktischen Erfahrungen ergaben. Diese Erfolgsfaktoren definieren die Ein-

satzkriterien näher und können in Form einer Checkliste vor der Durchführung eines Lean-

Canvas-Projekts geprüft werden:

Das Projektteam bringt Grundkenntnisse im Projekt- und Prozessmanagement

sowie zumindest grundlegendes Fachwissen und Umsetzungskompetenz im

Themenbereich der Idee mit.

Ein Grundstock von mindestens fünf potentiellen Interessenten oder Interessen-

tinnen, welche auch für Interviews zur Verfügung stehen, sollte vorhanden

sein. Dies erleichtert das schnelle Einläuten der problem-interview-Phase.

Repräsentative Prototypen, die als Platzhalter für das spätere Produkt fungie-

ren, sind kostengünstig und zeitnah umsetzbar. Im Idealfall geschieht die Um-

setzung durch das Projektteam selbst, die für die Umsetzung nötigen externen Ab-

hängigkeiten sollten jedenfalls minimiert werden.

Die Teammitglieder können regelmäßig (wöchentlich) am Projekt arbeiten, pro

Person sind mind. 8h/Woche empfehlenswert. Kleinere Projektteams mit mehr

107

Arbeitszeit pro Mitglied sind größeren Teams vorzuziehen, um langwierige Abstim-

mungsphasen zu vermeiden.

Der Einsatz von Running Lean wird von den Entscheidungsträgern befürwortet

und von den Stakeholdern im Unternehmen zumindest toleriert. Die „heimli-

che“ Einführung von Running Lean sollte die ultima ratio darstellen.

Es gibt eine klare Abgrenzung zwischen dem Running Lean-„Labor“ und der

übrigen Unternehmensumwelt: für die an den Produktideen Interessierten muss

klar sein, dass es sich um „Produkt-Experimente“ handelt, die jederzeit wieder ein-

gestellt werden können, und nicht um seriennahe Produkte. Quellcode aus Lean-

Canvas-Prototypen darf nicht ungeprüft in „produktiven“ Code umgewandelt wer-

den, da er wesentlich geringeren Qualitätskriterien genügen muss.

Wie bei jeder Methode bestehen auch bei Lean-Canvas gewisse Anwendungsrisiken, die

in der folgenden Aufzählung konkretisiert werden:

Der mögliche Patentanspruch technischer Ideen und Erfindungen könnte durch die

vorzeitige Kommunikation nach außen verwirkt werden

Running Lean könnte im Widerspruch zu bestehenden betrieblichen Geheimhal-

tungsabkommen stehen

Hardware-Projekte stellen noch eine Herausforderung für agile

Produktentwicklungstechniken dar. Anders als bei Softwareprojekten kann der

Projektfortschritt nicht inkrementell an die Kundinnen und Kunden ausgeliefert

werden (der neue Greifarm eines in Entwicklung befindlichen Roboters kann nicht

über das Internet installiert werden, die neue Bilderkennungsfunktion eines Foto-

portals schon), die Erstellung von Prototypen verursacht hohen finanziellen und

personellen Aufwand (obwohl es durch den 3D-Druck Verbesserungsmöglichkei-

ten gibt)

Zuletzt ist auch der mit Running Lean verbundene Eingriff ins betriebliche

Kompetenzgefüge ein gewisses Risiko: wenn Produktentscheidungen nun durch

Experimente im Lean-Canvas-„Labor“ getroffen werden, wird das den bisher zu-

ständigen Verantwortlichen nicht unbedingt schmecken (selbst wenn sie im Lean-

Canvas-Projektteam sind, müssen sie damit Macht abgeben). Es empfiehlt sich

also eine behutsame Einführung unter Einbindung aller Betroffenen, das Lean-

Canvas-Labor sollte zudem eindeutig von der restlichen Unternehmensumwelt ab-

gegrenzt sein.

108

6.5 Externe Evaluierung der Ergebnisse

Um die Objektivität der gewonnenen Erkenntnisse sicherzustellen, wurde die vom Autor

durchgeführte Fallstudie sowie die sich daraus ergebenen Erkenntnisse einem externen

Evaluator zur Begutachtung vorgelegt. Als Evaluator konnte Herr Lukas Fittl gewonnen

werden, der als persönlicher Mitarbeiter von Running-Lean-Erfinder Ash Maurya an der

Entwicklung dieser Methode beteiligt war51. In seiner Funktion als Startup-Berater und

Koordinator der Anwendergruppe „Lean Startup Circle Vienna“ hat er einen umfassenden

Einblick in die Anwendung von Lean-Startup-Methoden im beruflichen und privaten Um-

feld.

Im Rahmen eines persönlichen Evaluierungsgesprächs stellte der Autor zunächst die Fall-

studie „Trelew“ in ihrer Gesamtheit vor und präsentierte danach die von ihm daraus gezo-

genen Schlüsse bezüglich der Stärken und Schwächen von „Running Lean“ sowie ihrer

Anwendbarkeit für betriebliche und private Innovationsprojekte.

Herr Fittl beurteilte sowohl den Umfang als auch die Durchführung der Fallstudie als sehr

gelungen und erbat sich folgende Anmerkungen zu den Schlussfolgerungen:

Zur Durchführung von Running-Lean-Projekten alleine oder im Team: Für

Herrn Fittl hat die Durchführung im Team den Vorteil, dass dadurch die Selbstdis-

ziplin und Fokussierung der TeilnehmerInnen steigt – schließlich gehen sie den an-

deren Projektmitgliedern gegenüber Verpflichtungen bezüglich der Erledigung ein-

zelner Aufgaben ein. Bei Einzelprojekten fehlt dieser positive Gruppendruck. Im

konkreten Fall wurde der Autor durch einen festen Zeitrahmen (vorgegebener Ab-

gabetermin der Masterarbeit) angehalten, kontinuierlich an seinem Running-Lean-

Projekt zu arbeiten. Herr Fittl empfiehlt diese als „Timeboxing“ benannte Technik

zur Aufrechterhaltung der Motivation bei Einzelprojekten.

Zu fehlenden Technologieauswahlprozessen in Running Lean: Herr Fittl sieht

rasche Feedback-Zyklen als das entscheidende Erfolgsmerkmal von Running-

Lean. Daher sollten Prototypen und Produkte mit jenen Technologien entwickelt

werden, die das Projektteam beherrscht und mit denen es möglichst produktiv ar-

beiten kann. Erst wenn die verwendeten Technologien in Einzelbereichen Defizite

aufweisen, sollten sie mit neuen Technologien ergänzt werden. Für Herrn Fittl be-

steht der Innovationsgehalt vieler Produkte zudem nicht in Technologie-, sondern in

Marktinnovationen: bekannte Produkte oder Teile ihrer Funktionen werden zum

ersten Mal auf einem neuen Markt verfügbar gemacht. Beispielsweise ähneln die

charakteristischen Fotoeffekte der höchst erfolgreichen Smartphone-Applikation

„Instagram“ jenen der wesentlich älteren PC-Bildbearbeitungsprogramme Google

Picasa oder Adobe Photoshop Elements. Das technologische Wagnis für solche

51

vgl http://fittl.com/about/

109

„Produkt-Portierungen“ sei wesentlich geringer als für echte Technologieinnovatio-

nen, da viele der technologischen Bestandteile im Zuge der Portierung unverändert

übernommen werden können. Insofern sei die vom Autor aufgestellte These, inno-

vative Produkte würden ein hohes technologisches Risiko verursachen, nicht immer

zutreffend. Er teilt aber die Kritik des Autors, dass Running Lean dem Aspekt der

Technologieauswahl zuwenig Bedeutung beimisst.

Zur von Autor kritisierten Running-Lean-Empfehlung, den Interessierten

schon während der solution interviews finanzielle Zusagen abzunötigen:

Herrn Fittl zufolge kann der „Bestätigungsaspekt“ einer finanzielle Zusage (z.B. ab-

geschlossenes Monatsabo) für eine Produktidee nicht hoch genug eingeschätzt

werden, da der Kunde oder die Kundin damit erstmals signalisiert, dass ihm/ihr eine

Idee tatsächlich etwas Wert ist. Gleichzeitig sei Verkauf eine Tätigkeit, die insbe-

sondere Innovatoren mit technischem Background schwerfällt. Verkaufen sei aber

erlernbar, für Herrn Fittl haben sich in Zusammenhang mit Running Lean folgende

Techniken bewährt:

o Bereits in den problem interviews fragen, wieviel der/die Interviewte an Zeit

und Geld zur Lösung des Produktproblems ausgibt. In den solution

interviews darauf zurückkommen („Sie verwenden 20 Stunden und 80 Euro

im Monat, um Ihre Fotos im Internet zu präsentieren. Mit Trelew werden es

nur 40 Euro und 10 Stunden sein“)

o Geld-zurück-Garantie anbieten

o Es erscheint logisch, problem/solution interviews mit Experten des Prob-

lembereichs durchzuführen, um ausführliche Informationen über die Prob-

lemstellung und existierende Lösungen zu erhalten. Aus Verkäufersicht

sind diese Profis aber ein schwieriges Klientel, da sie von vielen Anbietern

umworben werden oder das in der Produktidee aufgegriffene Problem durch

ihr Experten-Know-How lösen können. Für die solution interviews sollte da-

her auch auf EinsteigerInnen des jeweiligen Fachbereichs zurückgegriffen

werden (z.B. Fotografie-SchülerInnen statt Fotografie-Lehrenden). Diese

sind oft sehr an professionellen Werkzeugen interessiert.

o solution interviews können und sollen auch noch während der „MVP“-Phase

durchgeführt werden, einerseits um den Kontakt zu den Interessenten nicht

zu verlieren und neue Produkthypothesen abtesten zu können, andererseits

um zahlende Kunden und Kundinnen zu akquirieren.

o Anfangs simple Preismodelle (Monatspauschale) anbieten, diese können

einfach in das applikationsinterne Abrechnungssystem implementiert wer-

den. Nutzungsabhängige Preismodelle (wie die für Trelew angedachten

Fotopakete) sollten erst nach ausführlichen Akzeptanztests umgesetzt wer-

den, da sie sowohl für den/die AnbieterIn (hoher Implementierungsaufwand)

als auch für die Kundschaft (Gebühren bei unbeabsichtiger Nutzung) Risi-

ken bergen.

110

Bezüglich der in der Fallstudie verfolgten Produktidee des Autors regte Herr Fittl an, bei

der Formulierung der Marketingbotschaften genauer zwischen der nutzenden und der

zahlenden Kundschaft zu unterscheiden. Fotoschaffende bilden zwar die mögliche zah-

lende Kundschaft von Trelew, benutzt würde der Dienst aber in erster Linie von deren

Kundinnen und Kunden, die in Auftrag gegebene Fotos betrachten und nachbestellen

möchten. Das Produktversprechen „View your images up to 96% faster“ müsste daher

umformuliert werden zu „Let your customers browse your photos 96% faster“. Er empfahl

weiters, die Upload-Funktion mit JPEG XR weniger technisch zu vermarkten, sondern

mehr unter dem Gesichtspunkt des Termindrucks von Fotoschaffenden zu betrachten

(Beispiel-Slogan: „Deliver your work 50% faster“)

Zu den Einsatzempfehlungen für Running Lean merkt Herr Fittl an, dass beim betrieblichen

Einsatz der Methode das „Branding“ eines Running-Lean-Projektes eine große Herausfor-

derung darstellt: darf den Befragten in den problem/solution interviews der Firmenname

genannt werden? Wie wird das Projekt firmenintern „verkauft“, ohne dass Missverständ-

nisse und Kompetenzstreitigkeiten entstehen?

Für Fittl besteht ein Ausweg in der Vermarktung als „Hackathon für Produktideen“. Der

Begriff „Hackathon“ bezeichnet eine auf wenige Tage begrenzte Veranstaltung, in deren

Rahmen SoftwareentwicklerInnen intensiv an neuen Programmfunktionen arbeiten und

diese abschließend präsentieren – im Vordergrund steht dabei die prototypische Umset-

zung experimenteller Funktionen. Damit könne man sowohl in der Unternehmensumwelt

als auch bei den Befragten Missverständnisse und falsche Erwartungen verhindern.

7 Ausblick

Diese Masterarbeit illustrierte anhand einer ausführlichen Fallstudie den Ablauf eines agi-

len Produktentwicklungsprozesses unter Verwendung der Running-Lean-Methode. Die

dabei gewonnenen praktischen Erfahrungen erlaubten die kritische Beurteilung der Me-

thode selbst, die Darstellung ihres Potentials für die moderne Produktentwicklung sowie

die Formulierung konkreter Anwendungsempfehlungen für den betrieblichen und privaten

Einsatz.

Im Zuge der Auseinandersetzung mit Running Lean stieß der Autor auf neue Forschungs-

fragen, die den Rahmen dieser Arbeit sprengen würden, aber Inhalte für zukünftige Mas-

terarbeiten im Bereich „agile Produktentwicklung“ darstellen:

Die vorliegende Masterarbeit konnte zwar Anwendungsempfehlungen für

„Running Lean“ aussprechen, aber nicht feststellen, wie weit verbreitet diese und

verwandte Methoden in der betrieblichen Praxis sind. Eine branchenübergreifende

111

Befragung von Innovations- und Produktentwicklungsbeauftragten könnte diese

Frage beantworten und zu einer Verfeinerung der best practices beitragen.

Wie die Lean Startup Conference 2013 zeigte, werden agile

Produktentwicklungsmethoden nicht mehr nur von „Garagenfirmen“ eingesetzt:

Großunternehmen wie der IT-Konzern Microsoft zählen ebenso zu den Anwendern

wie diverse Non-Profit-Organisationen oder die New Yorker Schulbehörde. Sie alle

möchten in Lean-Startup-Labors Produkte, Prozesse oder Dienstleistungen entwi-

ckeln, die noch besser auf die Bedürfnisse ihrer Kunden eingehen. Interessant

wäre in diesem Zusammenhang die Erforschung des beruflichen Hintergrunds der

österreichischen Lean-Startup-AnwenderInnen: in welchen Branchen und Organi-

sationen sind sie tätig? Für welche Zwecke setzen sie Startup-Methoden ein? Als

„Untersuchungsobjekt“ für eine Umfrage bietet sich die Anwendergruppe

„Lean Startup Circle Vienna“ an, die aktuell 413 registrierte Mitglieder umfasst52.

In der Fallstudie zeigte sich an einigen Stellen fachlicher Vertiefungsbedarf bei der

Anwendung von Running Lean, etwa im Customer Development, bei dem potenti-

elle AnwenderInnen einer Produktidee zu tatsächlichen, zahlenden Kunden entwi-

ckelt werden. Auch Umsetzungsstrategien für Prototypen im Sinne von

Running Lean könnten wissenschaftlich untersucht werden: vom optimalen Um-

gang mit technischer Schuld bis hin zur Anwendbarkeit des hochiterativen Prototy-

penkonzeptes außerhalb der Softwareentwicklung.

Mit diesem Ausblick auf anknüpfende Forschungsfragen beschließt der Autor seine Aus-

führungen. Er hofft, mit seiner Arbeit zu einem besseren wissenschaftlichen Verständnis

von Running Lean und verwandter Methoden beigetragen zu haben. Sein ultimativer

Wunsch wäre es jedoch, wenn sich der/die LeserIn nicht nur theoretisch mit dem Thema

beschäftigen würde. Unserem Land würden mehr kreative und innovative Köpfe guttun, die

ihre Ideen als Entrepreneure oder Intrapreneurinnen umsetzen, anstatt „unselbstständig“

die ewiggleichen Rituale, Prozeduren und Prozesse abzuarbeiten. Um den vielleicht schon

länger mit eigenen Produktideen kokettierenden und dann doch immer wieder zögernden

Lesern und Leserinnen Mut zur Umsetzung zu machen, endet diese Arbeit mit dem Run-

ning-Lean-Leitspruch:

„practice trumps theory!“

52

http://www.meetup.com/Lean-Startup-Vienna/ (abgerufen am 19.12. 2013)

112

Anhang

Abschrift der Problem Interviews

Die nachfolgenden Seiten enthalten eine Abschrift der in Kapitel 4.1 diskutierten problem

interviews zum Online-Fotodienst Trelew. Auf den Aufbau der Interviews wird ebendort

eingegangen. Die Interviews wurden von Juli bis September 2013 durchgeführt, die getä-

tigten Stellungnahmen zu Arbeitsweisen, Produkten und Technologien sind also im Kon-

text dieses Zeitraums zu sehen. Die Interviews fanden ausschließlich in Form persönlicher,

ein- bis zweistündiger Einzelgespräche statt. Diese Abschrift muss sich daher aus Platz-

gründen auf die zusammengefassten Aussagen der Interviewten beschränken. Die Na-

men der befragten Personen wurden geändert, alle weiteren Angaben entsprechen den

tatsächlichen Aussagen der Interviewten. Damit diese Aussagen möglichst unverfälscht

wiedergegeben werden, wurde – wie in den Vorbemerkungen zu dieser Arbeit bereits

erwähnt – von einer nachträglichen Ergänzung geschlechtsneutraler Bezeichnungen ab-

gesehen.

Interview mit Bernhard Anders, Konzertfotograf

Demografische Fragen

Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich erstelle in meiner

Freizeit künstlerisch hochwertige Bilder von Kleinkunst-Events und Konzerten, da-

neben widme ich mich der Porträtfotografie.

Welches DSLR-Modell besitzen Sie? Eine Nikon D90

Wieviele Fotos schießen Sie durchschnittlich pro Monat? 300 Fotos

Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW

Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,

Adobe Lightroom

Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Facebook,

500px.com

Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?

Ja, diese Funktion ist mir wichtig. Ich schieße 300 - 500 Photos pro Konzert und veröffent-

liche nur ein "Best Of" davon im Internet. Alle Bilder in RAW-Qualität im Netz zu veröffent-

lichen erscheint mir aber aufgrund des hohen Datenvolumens unrealistisch. Die von

Trelew angedachte verlustbehaftete RAW-Komprimierung mit dem Adobe DNG Format ist

umstritten, da dadurch der nachträgliche Weißabgleich beeinträchtigt wird. Eine verlust-

freie Kompression der RAW-Bilder bringt meiner Erfahrung nach max. 50% Speicherplatz-

ersparnis.

113

Zusammengefasst bin ich mir deshalb nicht sicher, ob Trelew mit einer Backup-Funktion

für alle geschossenen Fotos werben soll. Sehe es eher als Backup-Dienst der besten

Bilder.

Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um

beispielsweise ad hoc Abzüge zu bestellen?

Ja, diese Funktion ist mir wichtig. Der mobile Zugriff auf hoch aufgelöste Bilder gefällt mir

gut, mich sprechen oft Bandmitglieder an, ob sie ein im Internet veröffentlichtes Konzert-

foto nicht in nativer Auflösung bekommen können. Es ist oft gar nicht so leicht, die zugehö-

rige RAW-Datei zu finden. Es wäre toll, wenn der Dienst für alle User die niedrig aufgelöste

Version des Bildes bereitstellt und man dann für ausgewählte User die RAW-Version frei-

schalten kann. Aber: der mobile Zugriff auf Originaldateien ist ein heikles Thema für kom-

merzielle Fotografen, es muss klar und einfach feststellbar sein, wer auf welche Versionen

Zugriff hat und was die Nutzungsbedingungen sind.

Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-

mit Geld zu verdienen oder einen guten Zweck zu unterstützen?

Ich betreibe Fotografie als Hobby und möchte dies frei von ökonomischen Zwängen tun,

daher hat diese Funktion keine Relevanz für mich.

Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,

um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?

Diese Funktion sehe ich eher problematisch. Wo beginnt "grundlegendes Bearbeiten" und

wo hört es auf? Ich mache mit meinen RAW-Bildern oft Belichtungskorrekturen in

Lightroom und dann Retuschearbeiten in Photoshop. Ich halte es für unrealistisch, dass

mir ein Online-Dienst die Funktionen in derselben Qualität bieten kann. Könnte mir aber

ein Vorschautool für professionelle Fotografen vorstellen: der jeweilige Endkunde (z.B.

Hochzeitspaar) legt ein paar Filter über das Bild (z.B. Sepia) übers Bild und teilt so dem

Fotografen seine Wünsche mit. Dieser vollzieht die Bearbeitung dann in Photoshop nach.

Haben Sie noch weitere Ideen für den Online-Dienst?

Wenn es ums Drucken geht, müsste Trelew Proofing/Colormanagement-Funktionen mit-

bringen. Einen Plugin für Adobe Lightroom oder Photoshop sollte man auf jeden Fall an-

denken, um den direkten Upload aus diesen Programmen zu ermöglichen.

114

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Cloud-Backup von RAW-Bildern 1

Grundlegende Bearbeitungsfunktionen 5

Verkauf von Bildern 4

Anbindung von Fotodienstleistern 3

Online-Zugriff auf hochaufgelöste Bilder

(auch von mobilen Endgeräten)

2

Interview mit Daniel Ortner, Fotografie-Dozent

Demografische Fragen

Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich unterrichte das

Freifach „Digitale Fotografie“ an einer technischen Fachhochschule und bin freibe-

ruflicher Porträtfotograf.

Welches DSLR-Modell besitzen Sie? Mehrere Modelle der Firma Nikon

Wieviele Fotos schießen Sie durchschnittlich pro Monat? 100 Fotos

Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW

Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,

Adobe Lightroom

Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Keine

Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?

Die Funktion klingt interessant, aber ich fürchte, die Upload-Zeit für die Bilder ist zu hoch.

Auf Reisen wäre ein solches Cloud-Backup nützlich, um die erstellten Bilder redundant

speichern zu können. Erfahrungsgemäß ist die Upload-Geschwindigkeit dann aber noch

geringer, da die mobilen Datenleitungen nicht so gut ausgebaut sind.

Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um

beispielsweise ad hoc Abzüge zu bestellen?

Üblicherweise führe ich meinen Kunden erstellte Portraits auf meinem iPad vor, dafür

reichen auch niedrig aufgelöste Versionen der Fotos, die ich mit Adobe Lightroom erstelle.

Für Landschaftsfotografie oder detailreiche Motive können hochaufgelöste Bildversionen

aber nützlich sein.

115

Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-

mit Geld zu verdienen oder einen guten Zweck zu unterstützen?

Ich wäre schon an alternativen Vermarktungsmöglichkeiten für meine Bilder interessiert,

allerdings müssten die investierte Arbeit und der mögliche Ertrag in einem sinnvollen Ver-

hältnis stehen.

Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,

um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?

Ich bin vor allem daran interessiert, meinen Bildbearbeitungsworkflow zu beschleunigen,

um die Bilder noch schneller zum Kunden zu bekommen. Aktuell habe ich in SSD-Lauf-

werke investiert, um die Datenübertragung zwischen Kamera und Bearbeitungsrechner zu

beschleunigen. Ich finde zwar den Gedanken interessant, die mitunter rechenintensive

Bildbearbeitung an leistungsstarke Cloud-Server auszulagern, aber die kreative Freiheit

der Fotografen darf nicht darunter leiden. Ich bin eher skeptisch, ob mir ein Online-Dienst

dieselben Bearbeitungsmöglichkeiten wie Adobe Photoshop und Adobe Lightroom zur

Verfügung stellen kann.

Haben Sie noch weitere Ideen für den Online-Dienst?

-

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Cloud-Backup von RAW-Bildern 2

Grundlegende Bearbeitungsfunktionen 4

Verkauf von Bildern 1

Anbindung von Fotodienstleistern 3

Online-Zugriff auf hochaufgelöste Bilder

(auch von mobilen Endgeräten)

3

Interview mit Paul Meier, Event-Fotograf

Demografische Fragen

Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich betreibe Fotogra-

fie als mein Hobby und fotografiere vor allem auf Feiern und Veranstaltungen im

Familien- und Freundeskreis. Ich sehe mich als ambitionierten Freizeit-Fotografen

und versuche, mein diesbezügliches Wissen laufend über Workshops zu erweitern.

Welches DSLR-Modell besitzen Sie? Canon 1000D

Wieviele Fotos schießen Sie durchschnittlich pro Monat? 100-200 Fotos

Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW

116

Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,

Adobe Lightroom

Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Flickr.com (kos-

tenpflichtiger Pro-Account), Dropbox.com (kostenloser Basis-Account)

Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?

Derzeit verwende ich eine externe Festplatte zur redundanten Speicherung meiner Bilder.

Ich würde allerdings ein Backup in der Cloud begrüßen, auch um via Internet auf die Bilder

zugreifen zu können. Dem DNG-Format, das in Trelew für den beschleunigten Upload der

RAW-Dateien eingesetzt werden sollte, stehe ich grundsätzlich positiv gegenüber. Dieses

Format stellt schließlich eine zukunftssichere Form der Datenspeicherung dar, außerdem

vermeidet es die den RAW-Formaten anhaftenden Kompatibilitätsprobleme. Mein Bildbe-

arbeitungsprogramm konnte einmal das RAW-Format einer Leihkamera nicht lesen, eine

Konvertierung nach DNG schaffte Abhilfe. Die verlustbehaftete DNG-Variante sehe ich

allerdings skeptisch, da ich nicht weiß, inwiefern ich dadurch Bearbeitungsmöglichkeiten

opfere.

Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um

beispielsweise ad hoc Abzüge zu bestellen?

Ein Online-Zugriff auf meine RAW-Bilder via Tablet oder Smartphone wäre ein tolles Fea-

ture, um beispielsweise meiner Familie die Bilder zu zeigen und sofort Abzüge zu bestel-

len.

Bisher wollten sich Familienmitglieder meine Bilder direkt nach dem Fotografieren von der

Speicherkarte "ziehen", was ich aber im Hinblick auf meine künstlerische Freiheit abge-

lehnt habe. Durch die angedachte Bildkachelung in Trelew könnte ich anderen "read-only"

Zugriff auf die hochauflösenden Bilder geben, ohne ihnen die Originaldatei selbst auszu-

händigen. Optionen wie Download oder Nachbestellung würde ich dann selektiv freischal-

ten wollen.

Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-

mit Geld zu verdienen oder einen guten Zweck zu unterstützen?

Ich fände es gut, wenn ich mit Trelew RAW-Bilder ins Internet stellen kann und sowohl für

freie als auch kommerzielle Nutzung freigeben kann (verschiedene Creative-Commons-

Lizenzen). Die Integration von existierenden Fotohandelsplattformen wie istockphoto.com

wäre sehr nützlich. Würde aber nie die originale RAW-Datei selbst freigeben, sondern im-

mer die entwickelte/bearbeitete Version davon, um die künstlerische Freiheit zu behalten.

117

Für den Erfahrungsaustausch mit anderen Fotografen könnte ich mir die Freigabe einzel-

ner RAW-Bilder aber vorstellen, damit andere Benutzer durch Online-Bearbeitung das

Optimum aus meiner RAW-Datei herausholen.

Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,

um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?

Ich finde es sehr schwer, "grundlegendes Bearbeiten" für RAW-Bilder zu definieren. Bei

einigen meiner Fotos reichen minimale Belichtungskorrekturen, bei Porträtfotos greife ich

gerne zu Photoshop-Retusche-Techniken (Kopierstempel,...).

Wäre eher enttäuscht wenn mich Trelew nach dem langen Upload nur mit minimalen Be-

arbeitungswerkzeugen (z.B. Helligkeit/Kontrast/Gradationskurven) erwarten würde. Durch

die RAW-Fotografie erwartet man sich ja ein "Mehr" an Bearbeitungsmöglichkeiten. Viel-

leicht könnte man das durch intelligente Voreinstellungen kompensieren, mit denen gleich

nach dem Upload ein paar gute Bearbeitungsvorschläge umgesetzt werden. Denkbar wäre

der Upload und Einsatz von Photoshop-Voreinstellungen (.acv-Kurven, Aktionen).

Haben Sie noch weitere Ideen für den Online-Dienst?

Auf Flickr.com habe ich die Gästepass-Funktion schätzen gelernt: damit kann ich auch

nicht bei Flickr registrierten Anwendern einen zeitlich beschränkten Zugriff auf bestimmte

Alben geben. Diese Funktion setze ich vor allem für Familienmitglieder gerne ein.

Nützlich fände ich auch einen Plugin für Adobe Lightroom, der den Bildupload für Trelew

direkt aus Adobe Lightroom ermöglicht.

Bezüglich der Bearbeitungsfunktionen sehe ich maximale ein Einsatzgebiet in der Kunden-

kommunikation: der Kunde sieht Foto in Trelew, wendet einfache Presets wie Sepia an

und gibt so dem Fotografen zu verstehen, wie er das Bild gerne hätte. Dies könnte aber

der Fotograf als Beschneidung seiner künstlerischen Freiheit auffassen.

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Cloud-Backup von RAW-Bildern 4

Grundlegende Bearbeitungsfunktionen 5

Verkauf von Bildern 3

Anbindung von Fotodienstleistern 2

Online-Zugriff auf hochaufgelöste Bilder

(auch von mobilen Endgeräten)

1

118

Interview mit David Anger, Fotograf und Dozent

Demografische Fragen

Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich bin ausgebildeter

Berufsfotograf und fotografiere freiberuflich Events und Fotogeschichten. Daneben

gebe ich Workshops zu verschiedensten Themen der Fotografie in staatlichen und

privaten Bildungseinrichtungen.

Welches DSLR-Modell besitzen Sie? Nikon D700, Nikon D35

Wieviele Fotos schießen Sie durchschnittlich pro Monat? Über 200 Fotos

Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW

Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,

Adobe Lightroom

Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Facebook,

selbstentwickelte Fotogaleriesoftware für meine Kunden zum Bestellen von Abzü-

gen/Fotobüchern.

Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?

Aktuell verwende ich einen lokalen Dateiserver mit RAID-System zum Speichern und zur

Datensicherung meiner Bilder. Nach dem Abschluss eines Auftrags landen die Bilder auf

dem Server, auf der lokalen Platte verbleiben nur niedrig aufgelöste Bilder in einem Light-

room-Katalog. Zur späteren Bearbeitung wird das Katalogbild mit dem hochauflösenden

Bild vom Server verknüpft. Die performante Anbindung des Dateiservers erleichert das

Arbeiten ungemein, allerdings bleibt die Angst vor einem Diebstahl oder Systemausfall.

Ein Cloud-Backup der RAW-Daten finde ich sehr sinnvoll, aber nur unter folgenden Vo-

raussetzungen:

vertrauenswürdiger Anbieter (kein Amazon), am besten regional etabliert, persönli-

cher Support

performante Anbindung, schneller Datenzugriff, postalische Übermittlung größerer

Datenmengen auf Wechseldatenträgern

höchste Ansprüche an Datensicherheit (meine Rohdaten sind wie mein Haustor-

schlüssel)

darf ruhig etwas kosten, aber Preis/Leistungsverhältnis muss stimmen.

Mit dem zur Speicherung herangezogenen DNG-Format habe ich noch wenig Erfahrung

gesammelt, verwende das proprietäre Nikon-RAW-Format, sehe aber die DNG Archivie-

rungssicherheit positiv. Wer weiß, ob die Bildbearbeitungsprogramme in 10 Jahren noch

mit meinen Nikon-RAWs umgehen können.

119

Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um

beispielsweise ad hoc Abzüge zu bestellen?

Aktuell verwende ich den Online-Dienst Dropbox.com zum "mobilen" Präsentieren meiner

Bilder auf meinem iPad. Die Bilder werden vorher in Adobe Lightroom bzw. Adobe

Photoshop bearbeitet und über die Lightroom-Exportfunktion unter einem Dateinamen im

Format <Datum>-<Kürzel Auftraggeber>-<laufende Fotonummer> abgespeichert. Über

diesen eindeutigen Dateinamen kann ich die Vorschaubilder aus Dropbox.com jederzeit

meinen Originalbildern zuordnen. Die exportierten Vorschaubilder werden durch synchro-

nisierte Ordner automatisch in Dropbox eingebunden. Sollte Trelew die Erstellung der Vor-

schaubilder beschleunigen oder ihre Qualität verbessern, wäre dieser Dienst interessant

für mich.

Ich bin allerdings skeptisch, ob zum Erstellen der Vorschaubilder tatsächlich die originalen

RAW-Dateien in den Online-Dienst hochgeladen werden sollten. Ich fotografiere mit Voll-

format-Sensor und 12-16 Megapixel-Auflösung, die daraus resultierenden RAW-Dateien

sind zwischen 21 und 25 MB groß. Diese Datenmenge erscheint mir zu gewaltig, um für

jedes Bild eine RAW-Datei hochladen zu können. Vielleicht sollte sich Trelew auf den Up-

load hochauflösender JPEG-Dateien beschränken.

Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-

mit Geld zu verdienen oder einen guten Zweck zu unterstützen?

Meine Aufträge bestehen ausschließlich aus privaten Fotodokumentationen bzw. Fotoge-

schichten, meine Auftraggeber und ich haben daher kein Interesse an einer Veröffentli-

chung der Bilder.

Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,

um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?

Wenn es um die Bearbeitung von Bildern geht, sind mir professionelle Einstellungsmög-

lichkeiten wichtig, die deutlich über das Niveau von Einsteigerprogrammen wie Google

Picasa oder Photoshop Elements hinausgehen sollten. Ich bezweifle, dass mir ein Online-

Dienst einen derartigen Funktionsumfang bieten kann, zumal mich die Bearbeitungsfunkti-

onen der existierenden Photosharing-Dienste überhaupt nicht überzeugen.

Was ich mir noch am ehesten vorstellen könnte, wäre ein Online-Viewer für in Photoshop

oder Lightroom bearbeitete Bilder, der sowohl das Originalbild als auch die einzelnen Be-

arbeitungsschritte in „Schnappschuß“-Form anzeigt (Vorher/Nachher-Ansicht jedes Bear-

beitungsschrittes). Einen solchen Viewer könnte ich einsetzen, um die Kursarbeiten meiner

Schüler zu kommentieren oder zu korrigieren. Keinesfalls würde ich aber damit Kunden die

120

von mir aufgenommenen Bilder bearbeiten lassen – das würde meine kreative Freiheit

inakzeptabel beschränken.

Haben Sie noch weitere Ideen für den Online-Dienst?

Der Dienst müsste auf jeden Fall einen professionellen Eindruck vermitteln, über eine gute

Performance verfügen und einen echten Mehrwert zu oder für Adobe Lightroom bieten,

damit ich ihn einsetzen würde.

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Cloud-Backup von RAW-Bildern 1

Grundlegende Bearbeitungsfunktionen 2 (sofern damit der vorgeschlagene Online-

Viewer gemeint ist)

Verkauf von Bildern 5

Anbindung von Fotodienstleistern 4

Online-Zugriff auf hochaufgelöste Bilder

(auch von mobilen Endgeräten)

3

Interview mit Tobias Krammer, Mediengestalter und Fotograf

Demografische Fragen

Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich bin freiberuflicher

Mediengestalter und fotografiere in erster Linie, um visuelles „Rohmaterial“ für

meine Print- und Webdesignprojekte zu erhalten. Mein Wissen als Mediengestalter

und Fotograf vermittle ich auch in Fachbüchern und Videotrainings, wobei ich im-

mer wieder mit professionellen Fotografen verschiedenster Disziplinen zusammen

arbeite.

Welches DSLR-Modell besitzen Sie? Canon EOS 60D

Wieviele Fotos schießen Sie durchschnittlich pro Monat? Circa 100 Fotos

Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW

Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,

Adobe Lightroom

Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Flickr.com (kos-

tenloser Basis-Account), Facebook

Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?

Ein Cloud-Backup für RAW-Bilder erscheint mir sehr wichtig, aber durch die Größe der

RAW-Bilder schwierig (22-30 MB/Bild). Ich lösche oft "schlechte" RAW-Bilder und behalte

nur die JPEG-Versionen von ihnen, um den Speicherbedarf zu minimieren. Der RAW-

Speicherhunger ist auch schon während des Fotografierens ein Problem: ich und einige

121

mir bekannte Fotografen verwenden lieber mehrere "kleine" Speicherkarten (z.B. 8 GB)

statt einer großen (z.B. 64 GB), um das Ausfallrisiko durch Schäden an der Speicherkarte

zu minimieren. Hier wird RAW schnell zum Kapazitätsproblem. In der Studiofotografie wird

zudem häufig "Tethered Shooting"53 eingesetzt, die Kamera ist hier direkt mit dem Lap-

top/Rechner verbunden, der auch als Vorschaugerät fungiert. Die Cloud-Backup-Lösung

müsste diese Szenarien berücksichtigen.

Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um

beispielsweise ad hoc Abzüge zu bestellen?

Diese Funktion erscheint mir sinnvoll. Ein mobiler Zugriff ist zur Qualitätsbeurteilung der

Bilder wichtig, aber nur für ausgewählte Fotos denkbar. Alle Bilder als RAW hochzuladen,

wäre aufgrund des Upload-Volumens wohl illusorisch. Ein Online-Viewer liefert aber sehr

gute Möglichkeiten zur Qualitätsbeurteilung (vgl. vergrößerte Ausschnitt-Funktion auf

Photocase.de). Die direkte Anbindung an Druckdienstleister finde ich gut, man sollte aber

einen offenen Authentifizierungsstandard finden (OpenAuth?) statt mit Doppel-Accounts zu

arbeiten (d.h. einen erneuten Login beim Online-Dienstleister vermeiden).

Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-

mit Geld zu verdienen oder einen guten Zweck zu unterstützen?

Diese Funktion erscheint mir sinnvoll. Ich kenne einige Fotografen, die sehr erfolgreich

Stock-Photos54 im Internet verkaufen55, meine jährlichen Stock-Foto Einnahmen bewegen

sich im einstelligen Euro-Bereich. Ich vermute, man muss sich auf Stock-Photografie spe-

zialisieren und für guten und regelmäßigen Output sorgen, um in diesem Bereich Erfolg zu

haben.

Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,

um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?

Ich halte Online-Bildbearbeitung für eine spannende Technologie, sehe aber momentan

noch zuviele technische Hürden für ihren professionellen Einsatz. Das Bearbeiten von

Fotos auf Tablets ist problematisch, da die Tablet-Displays meist zu kontrastreich einge-

stellt sind. Wechselnde Lichtverhältnisse machten die nötige Farbkalibrierung des Displays

nahezu unmöglich.

Für den amateurhaften Einsatz könnten einzelne Cloud-Bearbeitungsfunktionen durchaus

spannend sein, man könnte sich z.B. an der populären Smartphone-App Instagram orien-

53

vgl.: http://de.wikipedia.org/wiki/Tethered_Shooting 54

Dieser Terminus bezeichnet Bilder von häufig nachgefragten Motiven (beispielsweise Sehenswürdigkeiten), die auf Vorrat

(engl. stock) produziert und über Bildagenturen verkauft werden. 55

Einer dieser Fotografen ist der vom Autor ebenfalls interviewte Thorsten Brenner. Dieser verneint aber nennenswerte

Einkünfte aus dem Verkauf von Stock Photos und rät Fotografen ab, sich in diesem Marktsegement zu engagieren.

122

tieren und auf dessen Funktionsumfang aufbauen. Allerdings stellt sich dann die Frage,

warum man angesichts der rudimentären Bearbeitungsmöglichkeiten auf RAW-Dateien

setzt.

Viele Fotografen in Ausbildung erhalten gerne Feedback auf ihre Arbeit, ein Foto-Review-

Tool, das die RAW-Datei und alle darauf angewandten Bearbeitungsschritte darstellt,

würde sicher den Geschmack vieler Nutzer treffen.

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Cloud-Backup von RAW-Bildern 1

Grundlegende Bearbeitungsfunktionen 5

Verkauf von Bildern 4

Anbindung von Fotodienstleistern 3

Online-Zugriff auf hochaufgelöste Bilder

(auch von mobilen Endgeräten)

2

Haben Sie noch weitere Ideen für den Online-Dienst?

Das vorhin genannte Photoreview-Tool könnte man um ein Modul für Fotografiewettwerbe

ergänzen, bei denen es div. technischen Beschränkungen gibt (z.B. nur Photos mit

8er/9er-Blende oder Festbrennweiten-Objektiven geschossen, wie beispielsweise die von

Ansel Adams geprägte f64-Fotografie56)

Interview mit Thorsten Brenner, Panoramafotograf und Dozent für

Mediengestaltung

Demografische Fragen

Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich habe mich auf

den Bereich Panoramafotografie spezialisiert. In dieser fotografischen Gattung

werden Landschaften oder Sehenswürdigkeiten mit sehr großem Blickwinkel bis hin

zur Rundumsicht (360°-Panorama) fotografiert. Mein diesbezügliches Wissen setze

ich einerseits in Kundenaufträgen um, andererseits gebe ich es in zahlreichen

Schulungen an öffentlichen und privaten Bildungseinrichtungen weiter. Daneben

bin ich auch als Fachbuchautor für Panoramafotografie und das Bildbearbeitungs-

programm Adobe Photoshop tätig.

Welches DSLR-Modell besitzen Sie? Canon 7D, Canon 600D, Canon EOS 5D

Mark III (leihweise)

Wieviele Fotos schießen Sie durchschnittlich pro Monat? Mindestens 200

56

vgl.: https://de.wikipedia.org/wiki/F/64

123

Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW

Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,

Adobe Lightroom, Adobe Bridge sowie die Spezialprogramme PTGUI und Enfuse

zum Erstellen von Panoramabildern.

Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Zum Präsentie-

ren meiner Panoramabilder verwende ich mein privates Blog, das mit einem spezi-

ellen Viewer ausgestattet ist. Außerdem bin ich im Panorama-Portal

http://www.360cities.net/ vertreten.

Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?

Cloud-Backup sehe ich als sehr wichtig, Knackpunkt ist aber die Upload-Geschwindigkeit

(ca. 25 MB pro Bild sind eine Menge Daten). Die Wahl von DNG als Archivierungsformat

(im Online-Dienst Trelew, Anmerkung des Verfassers) sehe ich positiv, da damit

Zukunftssicherheit geschaffen wird. Wenn sich kleinere DSLR-Kamerahersteller aus die-

sem Marktsegment zurückziehen, werden auch ihre RAW-Formate nicht mehr unterstützt.

Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um

beispielsweise ad hoc Abzüge zu bestellen?

Für mich wäre mobiler, internetbasierter Zugriff auf RAW-Bilder oder hochaufgelöste

JPEGs vor allem wertvoll in der Kundenkommunikation, nur in voller Auflösung lassen sich

Schärfe und Bilddetails gut beurteilen. Wichtig ist aber, dass Dritte niemals auf die Origi-

naldaten zugreifen dürfen, sondern auf entsprechend runtergerechnete oder mit Wasser-

zeichen geschützte Ansichten, um die unberechtigte Weiterverwendung des Bildmaterials

zu verhindern. Sollte der Online-Dienst auf ein professionelles Publikum zielen, darf das

Thema „Farbmanagement“57 natürlich nicht ignoriert werden, ich empfehle diesbezüglich

einen sRGB-basierten Workflow.

Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-

mit Geld zu verdienen oder einen guten Zweck zu unterstützen?

Am klassischen Anwendungsfall für diese Funktion, der Stockfotografie, bin ich nicht inte-

ressiert, da in diesem Segment nur sehr wenige, hochspezialisierte Fotografen Geld ver-

dienen. Meine eigenen Jahresumsätze mit Stockfotografie bewegen sich im Bereich von

200-300 US-Dollar. Von der Anbieterseite her ist dieses Marktsegment gesättigt für mich.

57

Farbmanagement bezeichnet die möglichst originalgetreue Wiedergabe der von der Kamera festgehaltenen Farbwerte auf

verschiedenen Ausgabemedien durch den Einsatz von Farbprofilen. [vgl. (Gockel, 2011, p. 93)]

124

Viel wichtiger finde ich das Thema "Kundenkommunikation und Bildbestellung" in der Auf-

tragsfotografie58: Kunde betrachtet Bilder seines Fotoauftrags im Webbrowser, wählt die

gewünschten Aufnahmen aus, bezahlt im Online-Shop und lädt sich die Bilder runter. Der-

zeit ist mir noch kein Anbieter bekannt, der diesen Prozess vollständig abbildet und in das

Bildverwaltungsprogramm Adobe Lightroom integriert. Es gibt zwar einige „halbautomati-

sche“ Lösungen, diese erfordern jedoch die manuelle Intervention des Fotografen beim

Bestellvorgang (beispielsweise müssen bei der Lightroom-Galerielösung „The Turning

Gate“59 die per E-Mail angeforderten Bilder manuell herausgesucht werden). Mit einer voll-

automatischen Lösung könnte Trelew sicher einen Treffer landen.

Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,

um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?

Aus technischer Sicht ist eine cloud-basierte RAW-Bearbeitung eine spannende Sache,

aber es ist schwierig eine genaue Zielgruppe für diese Funktion auszumachen. Die Quali-

tät und der Umfang der Bearbeitungsfunktionen müssten an jene von Adobe Lightroom

herankommen, was ich bei einem Startup für unrealistisch halte. Zudem müsste auch der

Bildschirm des Bearbeitungsgeräts einer Farbkalibrierung unterzogen werden, was bei

Tablets noch nicht möglich ist. Zumindest mittelfristig werden Online-Dienste die etablier-

ten Programme Adobe Photoshop und Lightroom nicht ersetzen können. Eventuell könnte

man eine HTML5-Oberfläche für das OpenSource-Bildbearbeitungsprogramm darktable60

stricken und damit experimentieren. Ich bezweifle aber, dass es kommerzielles Potential

für diesen Ansatz gibt.

Haben Sie noch weitere Ideen für den Online-Dienst?

Grundsätzlich sehe ich zwei wesentliche Anwendungsfälle für Trelew: einerseits eine per-

formante Online-Vorschau auf hochaufgelöste Bilder mit integrierten Werkzeugen für die

Kommunikation zwischen Fotografen und Kunden. Andererseits ein Cloud-Backupdienst

für RAW-Fotos, der die Bilder in unterschiedlichen Auflösungen und Formaten verfügbar

macht.

58

Anlassbezogene und exklusive Produktion von Fotos für einen Kunden, der Fotograf erhält entweder eine vorher

vereinbarte Pauschale oder ein Basishonorar sowie eine Vergütung pro tatsächlich bestelltem Bild. 59

siehe: http://ce3.theturninggate.net/galleries/02-ttg-ce3-client-response-gallery/ 60

siehe: http://www.darktable.org/

125

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Cloud-Backup von RAW-Bildern 1

Grundlegende Bearbeitungsfunktionen 5

Verkauf von Bildern 3

Anbindung von Fotodienstleistern 4

Online-Zugriff auf hochaufgelöste Bilder

(auch von mobilen Endgeräten)

2

Abschrift der Solution Interviews

Für die Durchführung der in Kapitel 5.3 vorgestellten solution interviews griff der Autor

überwiegend auf die Teilnehmer der problem interviews zurück. Die Befragung erfolgte in

den meisten Fällen per E-Mail, nur die Fotografen Paul Meier und Oskar Magenschab

wurden persönlich befragt. Im Rahmen der Interviews wurde den Teilnehmern der in den

Kapiteln 5.3.1 und 5.3.2 vorgestellte Prototyp vorgelegt, anschließend fragte der Autor die

Teilnehmer nach ihrer Bewertung der vier „Schlüsselfunktionen“ von Trelew (kachelba-

sierte Schnellanzeige, neue Bildformate, automatisierte Fotobestellung und dateibasierte

Bildsuche), die auf der den Prototyp begleitenden Marketingseite vorgestellt sind (siehe

Abbildung 29 auf Seite 82).

Interview mit Paul Meier, Event-Fotograf

Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende

Bilder?

Sehr tolles Feature, besonders wenn man unterwegs mit schlechter Internet-Verbindung

seine Bilder in voller Qualität herzeigen will.

Sehe es als wichtiges Differenzierungsfeature zu anderen Diensten, leider wird es auf der

Startseite des Trelew-Prototyps nicht optimal präsentiert. Der für diese Funktion gewählte

Slogan lautet "Show full resolution pictures on any device" - das können Flickr, Picasa und

andere Photosharing-Dienste auch. Würde den Slogan umformulieren in “View high-

resolution images up to 90% faster than conventional photosharing services“, so kommt

der Zeitvorteil durch den kachelbasierten Bildaufbau besser zur Geltung. Man sollte die

Ladevorgänge von konventionellen und kachelbasierten Bildern in einem Balkendiagramm

gegenüberstellen – auf diese Weise wird für den Benutzer der Zeitvorteil anschaulich.

126

Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere

Uploads oder hochwertigere Bildvorschauen?

Kannte die angesprochenen neuen Bildformate JPEG XR bzw. lossy DNG noch nicht.

Finde es sehr gut, dass Trelew diese Bilder für Uploads unterstützt und man dadurch Up-

load-Zeit sparen kann oder bessere Qualität als im JPEG-Format liefert. Bin oft auf Reisen

und würde Bilder gerne auch über schlechtere Internet-Verbindungen möglichst rasch

hochladen.

Von der Präsentation dieses Features bin ich nicht so angetan - "Efficient Photo I/O" klingt

zu abstrakt-technisch für einen Fotografen. Es wäre besser, die Formate konkret zu er-

wähnen und die durch sie mögliche Verkürzung der Upload-Zeit mittels einer Animation zu

zeigen.

Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von

Fotobestellungen?

Dieses Feature ist mir mit Abstand das wichtigste und sollte unbedingt prominenter plat-

ziert werden. Fotografiere viel auf Events und erhalte oft E-Mail-Anfragen nach einzelnen

Bildern. Das Problem dabei: die Anfrager schicken falsche oder unvollständige Dateina-

men, was die Suche mühsam macht. Ein Tool, das den ganzen Bestellungsprozess auto-

matisiert (Nachbestellung durch Kunden - Verständigung Fotograf - Automatisches Hoch-

laden) wäre Gold für mich wert.

Allerdings ist auch hier die Präsentation zu verwirrend - man müsste mit einer Animation

arbeiten, um den Ablauf besser darzustellen. Die Darstellung des Prozesses als Komman-

dozeilen-Skript schreckt viele grafisch orientierte User ab.

Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-

teien?

Sehe den Nutzen: Man hat ein Bild downgeloadet, nach zwei Wochen die Quelle verges-

sen, benötigt aber nun die Copyright-Informationen für eine Veröffentlichung. In diesem

Fall wäre es schon praktisch, die downgeloadete Datei einfach in das Trelew-Fenster zu

ziehen und man wird zur Informationsseite des Bildes weitergeleitet. Für mich als „Bildpro-

duzent“ hat das Feature aber nur untergeordnete Bedeutung.

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Schnellanzeige hochauflösender Bilder 2

Automatisches Handling von Fotobestel-

lungen

1

127

Funktion Priorität nach dem Schulnotenprinzip

Dateibasierte Bildsuche 4

Unterstützung innovativer Bildformate 3

Interview mit Tobias Krammer, Mediengestalter und Fotograf

Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende

Bilder?

Das finde ich eines der spannendsten Features. Bis jetzt musste man ein Bild vollständig

herunterladen und in einem Bildbearbeitungsprogramm öffnen, um es in allen Zoomstufen

zu betrachten. Wenn sich dies nun wesentlich schneller direkt im Webbrowser bewerkstel-

ligen lässt, ist das wirklich ein Feature mit Mehrwert, zumal Schärfe und Farbgebung sich

am besten in voller Auflösung beurteilen lassen.

Ich habe allerdings noch nicht verstanden, ob die Bearbeitung der Bilder nun auf den Ser-

vern von Trelew oder auf dem Rechner des Fotografen erfolgt. Auf der Präsentationsseite

des Prototyps sollte man daher den Workflow besser erläutern (beispielsweise Bearbei-

tung in Adobe Photoshop/Lightroom → Upload des hochaufgelösten Bildes nach Trelew

→ Kachelung → Schnellansicht). Für den professionellen Einsatz wäre ein Schutz der im

Viewer angezeigten Bilder mit Wasserzeichen wichtig, um unerlaubter Verwendung vorzu-

beugen. Außerdem wäre ein Bild-Navigator nützlich, der den gerade angezeigten Aus-

schnitt des Gesamtbildes kenntlich macht und seine Änderung erlaubt.

Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere

Uploads oder hochwertigere Bildvorschauen?

Finde es sehr gut, dass Trelew auch neue Bildformate unterstützt und den Benutzer von

Ihren Vorteilen profitieren lässt. Bei der Euphorie gegenüber neuen Dateiformaten sollte

man aber beachten, dass damit oft Konvertierungsprozesse verbunden sind, die Bildbear-

beitungsworkflows verlangsamen und komplizieren können. Wenn beispielsweise die

Konvertierung nach JPEG XR sehr zeitaufwendig ist, relativiert sich der Geschwindigkeits-

vorteil dieses Formats beim Upload wieder. Ich bin aber zuversichtlich, dass sich die Up-

load- und Konvertierungsfunktionalität von Trelew mit der sehr leistungsfähigen Export-API

von Adobe Lightroom umsetzen lässt.

Wenn mit dem Upload von RAW-Dateien geworben wird, sollte man betonen, dass RAW-

Dateien nicht 1:1 durch Dritte downgeloadet werden können. Dieser Punkt ist professio-

nellen Fotografen sehr wichtig.

128

Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von

Fotobestellungen?

Mir gefällt die Idee eines privaten „Photo-Shops“ für Auftrags- und Stockfotografie sehr gut,

besonders wenn eine Bezahlfunktion integriert ist. Man sollte aber den Workflow des „se-

lektiven Hochladens“ besser erklären. Ich verstehe diese Funktion so, dass man als Foto-

graf zuerst eine größere Anzahl von Auswahlbildern in hoher Auflösung, aber mittlerer

Qualität hochlädt. Erst wenn der Kunde ein Bild bestellt, wird das Bild in bestmöglicher

Qualität und Auflösung hochgeladen. Muss der Fotograf diesen Upload anstossen oder

wird er automatisch von Trelew durchgeführt (vergleiche dazu die Idee der synchronisier-

ten Ordner von Dropbox)? Wenn das Feature noch nicht programmatisch umgesetzt ist,

könnte vielleicht eine kurze Workflow-Animation helfen.

Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-

teien?

Ebenso sehr praktsich, besonders in Hinblick auf einen Publishing-Hintergrund. In einer

Redaktion mit Previews arbeiten, nach Entscheidung für dieses Bild soll es schnell und

einfach (automatisiert) gehen mit dem Download. Im Optimalfall wäre das sogar ein kleines

Applet oder ähnliches, das mir automatisch meine Preview-Dateien mit dem Original er-

setzt (overwrite policies?). Möglicherweise wäre hier ein Zusatzfeature ganz toll, das mir

schnell und einfach zeigt, welche Metadaten in meiner Bilddatei schon enthalten sind im

Moment. Oder gar ein Zusatzrequest. Also z.B. eine Art Drag&Drop Zone, auf die ich ein

Bild ziehe. Dann wird mir rechts davon (iconographisch) gezeigt, welche Metadaten vor-

handen sind (ausgefüllte Icons) und welche fehlen (ausgegraute Icons). Wenn ich auf ein

ausgegrautes Icon klicke, kann Trelew dieses fehlende Metadatum on demand herunter-

laden und überschreibt im Hintergrund automatisch die Datei. Das wäre ein etwas anderer

Ansatz als bei anderen Bildbetrachtern (Adobe Bridge oder Lightroom z.B.), aber durchaus

sinnvoll.

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Schnellanzeige hochauflösender Bilder 1

Automatisches Handling von Fotobestel-

lungen

2

Dateibasierte Bildsuche 3

Unterstützung innovativer Bildformate 4

129

Interview mit Daniel Ortner, Fotografie-Dozent

Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende

Bilder?

Die Möglichkeit der kachelbasierten Schnellanzeige finde ich sehr gut. Durch immer bes-

sere Sensoren und Optiken sind die Megapixel-Werte heutzutage wieder im Steigen be-

griffen, ohne dass man zwangsläufig Probleme mit dem Bildrauschen bekommt. Auch bei

den Handy-Kameras ist Qualität und Bildauflösung starkt gestiegen. Es fehlt aber eine

Technologie, um diese hochaufgelösten Bilder übers Internet präsentieren zu können –

Trelew könnte eine interessante Lösung darstellen. Bei der Wiedergabe auf mobilen End-

geräten oder Büromonitoren sollte man aber mögliche Probleme mit der Farbwiedergabe

beachten. Zur ungefähren Farb- und Belichtungskontrolle könnte die Darstellung eines

Histogramms helfen.

Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere

Uploads oder hochwertigere Bildvorschauen?

Ich finde es sehr gut, wenn Trelew den Fotografen durch Unterstützung neuer Dateifor-

mate Produktivitätsvorteile und Archivierungssicherheit bietet. DNG ist wegen seiner Stan-

dardisierung und Unterstützung durch Adobe eine gute Wahl für die Langzeitarchivierung

von RAW-Dateien. Mit JPEG XR habe ich mich noch nicht befasst, möchte dies aber in

naher Zukunft tun.

Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von

Fotobestellungen?

Ich finde das Fotobestelltool mit Bezahlschnittstelle sehr gut. Sollte Trelew für die Bezahl-

abwicklung auf externe Anbieter zurückgreifen, möchte ich mir die für meinen Trelew-

„Photo-Shop“ zugelassenen Anbieter aussuchen können. Ich habe in der Vergangenheit

als Käufer und Verkäufer sowohl gute als auch schlechte Erfahrungen mit Internet-Bezahl-

anbietern gemacht. Daher ist es mir wichtig, unkooperative Anbieter aus meinem Shop

verbannen zu können.

Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-

teien?

Die Suche über downgeloadete Vorschau-Dateien finde ich sehr gut, auch die Möglichkeit,

diese Vorschaudateien später über ein Skript automatisch durch die hochauflösenden Ori-

ginaldateien zu ersetzen. Für mich stellt sich nur die Frage, ob diese Übersetzung aus je-

der Layout-Applikation heraus funktioniert.

130

Priorisierung der Funktionen

Funktion Priorität nach dem Schulnotenprinzip

Schnellanzeige hochauflösender Bilder 1

Automatisches Handling von Fotobestel-

lungen

3

Dateibasierte Bildsuche 2

Unterstützung innovativer Bildformate 4

Interview mit Thorsten Brenner, Panoramafotograf und Dozent für

Mediengestaltung

Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende

Bilder?

Die kachelbasierte Schnellansicht ist mit Abstand mein Lieblingsfeature. Hochauflösende

Bilder im Browser zu betrachten und quasi in Echtzeit ihre Schärfe beurteilen zu können,

ist schon ein potentielles Killerfeature. Kachelansichten kenne ich zwar vereinzelt von

Stockphoto-Anbietern, aber die Version von Trelew glänzt durch gute Performance und

intuitive Navigation.

Ich würde dieses Feature als erstes umsetzen und es entsprechend vertiefen, damit es

auch für Profis gut einsetzbar ist. Darunter verstehe ich den ohnehin schon angedachten

Lightroom-Plugin, der einen Direktupload aus diesem Programm erlauben soll. Wichtig

sind auch gute Navigationsmöglichkeiten innerhalb des Bildes sowie in größeren Bildkol-

lektionen (hier sollte man keinesfalls auf Tastenkürzel vergessen, Profis lieben so etwas).

Auch eine mobile Version des Trelew-Kachelviewers (entweder als Mobile-Website oder

App) wäre wichtig. Nicht vergessen sollte man auch auf „ästhetische“ Wasserzeichen, um

unberechtigte Weiterverwendung der Bilder zu verhindern.

Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere

Uploads oder hochwertigere Bildvorschauen?

Der beschleunigte Upload durch das JPEG-XR-Format ist natürlich ein Nice-To-Have und

gutes Differenzierungsmerkmal, ich würde mich aber zuerst auf die kachelbasierte

Schnellanzeige konzentrieren.

131

Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von

Fotobestellungen?

Die dateibasierte Bildsuche oder das Handling von Fotobestellungen klingen für mich sehr

brauchbar, ich würde aber zuerst die Bildanzeige gut umsetzen und dann mit diesen Fea-

tures starten. So überfordert man weder die Anwender noch die Entwicklermannschaft ;).

Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-

teien?

Siehe vorige Antwort.

Funktion Priorität nach dem Schulnotenprinzip

Schnellanzeige hochauflösender Bilder 1

Automatisches Handling von Fotobestel-

lungen

3

Dateibasierte Bildsuche 3

Unterstützung innovativer Bildformate 3

Interview mit Oskar Magenschab, Fotografie-Dozent

Demografische Fragen

Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich betreibe seit

Jahrzehnten Fotografie als ambitionierter Hobbyist und habe bereits einige meiner

Werke ausgestellt. Daneben unterrichte ich das Freifach „digitale Fotografie“ an ei-

ner technischen Fachhochschule.

Welches DSLR-Modell besitzen Sie? Nikon D700

Wieviele Fotos schießen Sie durchschnittlich pro Monat? Circa 100

Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW

Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,

Adobe Lightroom

Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? SmugMug.com

Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende

Bilder?

Finde das Feature sehr wichtig. Würde hochauflösende Bilder gerne im Netz präsentieren,

das scheiterte aber an den langen Ladezeiten bzw. der schwierigen Navigation auf mobi-

len Endgeräten. Für mich stellt sich aber die Frage nach der Farbverbindlichkeit der Bilder

im Browser. Es müsste möglich sein, den Bildern eigene Farbprofile mitzugeben und diese

so umzurechnen, dass der Browser zumindest eine annähernd korrekte Farbdarstellung

132

liefert. Bei Browsern, bei denen das nicht möglich ist, sollte ein Warnhinweis angezeigt

werden.

Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere

Uploads oder hochwertigere Bildvorschauen?

Finde es sehr positiv, wenn der Fotograf durch die Wahl des richtigen Bildformats die Up-

loadgeschwindigkeit und/oder Bildqualität steuern kann - viele Photosharingdienste sind

hier sehr intransparent. Wichtig ist mir die Unterstützung von RAW-Formaten neuerer Ka-

meras - bei solchen Bildern kam es bei mir in Lightroom schon öfter zu Anzeigefehlern

(falsche Farben, Verpixelung).

Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von

Fotobestellungen?

Ist für mich wichtig, allerdings nicht so dringend wie die Schnellanzeige der Bilder im Web.

Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-

teien?

nettes Zusatzfeature, sehe ich aber nicht als „kaufentscheidend“.

Haben Sie Ideen für zusätzliche Funktionen?

Die Unterstützung von Kamerafarbprofilen wäre sicher wünschenswert, mir sind außerdem

ansprechende Diashows wichtig, die im Webbrowser laufen sollen. Die Anordnung der

Thumbnails muss nicht immer in einem strengen Zeilenraster erfolgen, mir wäre die fle-

xible Anordnung per Drag-and-Drop auf einem virtuellen Leuchttisch fast lieber. Die Größe

der Thumbnails sollte sich flexibel einstellen lassen. Zudem sollten Trelew-Alben unter

Kundendomains laufen können bzw. in Blogs integrierbar sein.

Funktion Priorität nach dem Schulnotenprinzip

Schnellanzeige hochauflösender Bilder 1

Automatisches Handling von Fotobestel-

lungen

3

Dateibasierte Bildsuche 4

Unterstützung innovativer Bildformate 2

133

Literaturverzeichnis

Adobe Systems Incorporated, 2008. Digital Negative (DNG) Specification 1.2.0.0, San

Jose: Adobe Systems Incorporated.

Adobe Systems Incorporated, 2012. Adobe Digital Negative (DNG) Specification Version

1.4.0.0, San Jose: Adobe Systems Incorporated.

Bayer, B. E., 1975. Color Imaging Array. USA, Patentnr. 3,971,065.

Birklbauer, V. & Karner, T., 2007. Erfolgsfaktoren österreichischer Jungunternehmen.

Statistische Nachrichten, Ausgabe 12.

Blank, S., 2013. The Four Steps to the Epiphany - Successful strategies for products that

win. California: K & S Ranch.

Bockaert, V., 2009. DPReview Glossary: Dynamic Range. [Online]

Available at: http://www.dpreview.com/glossary/digital-imaging/dynamic-range

[Zugriff am 08 09 2013].

Bockaert, V., 2009. DPReview Glossary: Sensor Sizes. [Online]

Available at: http://www.dpreview.com/glossary/camera-system/sensor-sizes

[Zugriff am 08 09 2013].

Brown, T. E. & Ulijn, J. M., 2004. Innovation, Entrepreneurship and Culture: The Interaction

Between Technology, Progress and Economic Growth. Cheltenham: Edward Elgar

Publishing.

Busch, S., 2013. Squeeze Chart 2013 - Camera RAW Compression Benchmark. [Online]

Available at: http://www.squeezechart.com/craw5.html

[Zugriff am 01 09 2013].

Fraser, B., 2004. Understanding Digital Raw Capture. [Online]

Available at: http://www.adobe.com/digitalimag/pdfs/understanding_digitalrawcapture.pdf

[Zugriff am 06 09 2013].

Gianforte, G. & Gibson, M., 2007. Bootstrapping Your Business: Start and Grow a

Successful Company with Almost No Money. Seattle: BookSurge Publishing.

Gockel, T., 2011. Kompendium digitale Fotografie - Von der Theorie zur erfolgreichen

Fotopraxis. Berlin Heidelberg: Springer.

Hubbard, D. W., 2010. How to Measure Anything: Finding the Value of Intangibles in

Business. 2. Hrsg. Hoboken: Wiley.

134

ITU Consultative Comitee, 1993. JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81,

Genf: ITU.

Klaff, O., 2011. Pitch Anything - An innovative method for presenting, persuading and

winning the deal. New York: McGraw-Hill Professional.

Liker, J., 2003. The Toyota Way - 14 management principles from the world's greatest

manufacturer. New York: McGraw-Hill.

Maurya, A., 2012. Running Lean - Iterate from a Plan A to a Plan That Works. Sebastopol:

O'Reilly61.

Mullins, J. & Komisar, R., 2009. Getting to Plan B: Breaking Through to a Better Business

Model. Boston: Harvard Business Review Press .

Nielsen, J., 2000. Why You Only Need to Test with 5 Users. [Online]

Available at: http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

[Zugriff am 20 10 2013].

Ookla, 2013. Ookla Netindex: Upload Speed Index Austria August 2013. [Online]

Available at: http://www.netindex.com/upload/2,20/Austria/

[Zugriff am 01 09 2013].

Osterwalder, A. & Pigneur, Y., 2011. Business Model Generation - ein Handbuch für

Visionäre, Spielveränderer, Herausforderer. Frankfurt am Main: Campus Verlag.

Pearson, B., 2011. Cameras that write DNG. [Online]

Available at: http://www.barrypearson.co.uk/articles/dng/products_cameras.htm

[Zugriff am 14 09 2013].

Pearson, B., 2011. DNG support, to end-December 2010. [Online]

Available at: http://www.barrypearson.co.uk/articles/dng/products_y7.htm

[Zugriff am 14 09 2013].

Ries, E., 2012. Lean Startup - Schnell, risikolos und erfolgreich Unternehmen gründen.

München: Redline Verlag.

Schumpeter, J. A., 1926. Theorie der wirtschaftlichen Entwicklung: eine Untersuchung

über Unternehmergewinn, Kapital, Kredit, Zins und den Konjunkturzyklus. 2. Hrsg. Berlin:

Duncker & Humblot.

61

Die in den Zitaten dieser Arbeit genannten Seitenzahlen beziehen sich auf die eBook-Ausgabe von „Running Lean“ und

wurden mit dem kostenlosen eBook-Reader calibre Version 0.9.12 ermittelt (http://calibre-ebook.com/). Sie können von

den Seitenzahlen der gedruckten Ausgabe abweichen.

135

Shankland, S., 2012. news.cnet.com - Adobe offering new reasons to get DNG religion.

[Online] Available at: http://news.cnet.com/8301-30685_3-57371809-264/adobe-offering-

new-reasons-to-get-dng-religion/

[Zugriff am 14 09 2013].

Srinivasan, B. S. & Pande, V. S., 2013. Stanford Startup Engineering Course. [Online]

Available at: https://class.coursera.org/startup-001

[Zugriff am 11 11 2013].

Tan, L., 2006. Biomed Imaging and Intervention Journal. [Online]

Available at: http://www.biij.org/2006/1/e6/

[Zugriff am 06 09 2013].

Vogel, R., Koçoglu, T. & Berger, T., 2010. Desktopvirtualisierung: Definitionen –

Architekturen – Business-Nutzen. Wiesbaden: Vieweg+Teubner Verlag.

136

Abbildungsverzeichnis

Abbildung 1: Schematische Darstellung des Toyota-Produktionssystems .........................16

Abbildung 2: Die Rolle von Entrepreneuren im Wirtschaftssystem ....................................18

Abbildung 3: Die Bauen-Messen-Lernen Feedbackschleife ..............................................19

Abbildung 4: Der Business Model Canvas nach Pigneur und Osterwalder ........................21

Abbildung 5: Modell "EOS 5D Mark II" von Canon ............................................................27

Abbildung 6: Lichtwege bei DSLRs ...................................................................................28

Abbildung 7: DSLR-Modell Sony A230 mit Wechselobjektiven und weiterem Zubehör .....29

Abbildung 8: Interpolation von Farbwerten im Raw-Konverter ...........................................30

Abbildung 9: Adobe Lightroom mit integrierte mCamera RAW Konverter ..........................30

Abbildung 10: Visuelle Artefakte bei der verlustbehafteten JPEG-Kompression ................32

Abbildung 11: Eine auf flickr.com veröffentliche Fotogalerie ..............................................35

Abbildung 12: Tag Clouds visualisieren die Popularität von Schlagworten. .......................37

Abbildung 13: Struktur des RAW2Cloud-Dienstes .............................................................40

Abbildung 14: Aufbau einer Bildpyramide ..........................................................................41

Abbildung 15: Ausgangsbild für den Test des Bildbearbeitungsdiensters cloudinary .........43

Abbildung 16: Der URL-Parameter e_contrast:80 erhöht den Kontrast des Fotos. ............43

Abbildung 17: Leerer Lean Canvas mit Ausfüllhilfen .........................................................45

Abbildung 18: Das Pirate-Metrics-Modell von Dave McClure ............................................50

Abbildung 19: Der Plan "A" als Lean Canvas ....................................................................52

Abbildung 20: Erfolgskriterien der Bauen-Messen-Lernen Feedbackschleife ....................53

Abbildung 21: Ideenlabyrinth - auf eine "Grobidee" passen viele Ausführungen ................55

Abbildung 22: Die Risikoarten und ihre Entsprechung im Lean Canvas ............................56

Abbildung 23: Dauer des dcraw-Konvertierungsvorgangs auf verschiedenen Servern ......64

Abbildung 24: Zielsetzungen eines Startups vor und nach dem Product/Market-Fit ..........70

Abbildung 25: Aktualisierter Canvas nach durchgeführtem Pivot .......................................75

Abbildung 26: Wireframe-Darstellung einer Dialogbox ......................................................77

Abbildung 27: Demoseite des CSS-Frameworks Twitter Bootstrap ...................................79

Abbildung 28: Der Prototyp der Schnellansicht im Webbrowser ........................................80

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

Abbildung 30: Aufbau eines Solution Interviews nach Maurya ..........................................91

137

Tabellenverzeichnis

Tabelle 1: Vergleich verschiedener DNG-Varianten. .........................................................34

Tabelle 2: Camera-RAW-Unterstützung der wichtigsten Photosharing-Sites .....................39

Tabelle 3: Preismodelle der Konkurrenzanbieter ...............................................................87

Tabelle 4: Preisstaffel für das Grundprodukt .....................................................................89

Tabelle 5: Preisstaffel für Tiled Viewing .............................................................................89

Tabelle 6: Preisstaffel für Download ..................................................................................89

Tabelle 7: Preisstaffel für Watermarking ............................................................................90

Tabelle 8: Preisbeispiel für die monatliche Nutzung von Trelew ........................................90

Tabelle 9: Einsatzempfehlungen für Running Lean ......................................................... 106