197

Status Quo Seit Fertigstellung der diesem Buch zugrundeliegenden Dissertation wurden unter der Marke "Business Model Creativity" zahlreiche Business Modeling-Workshops mit Gründern, Unternehmen und Studierenden durchgeführt und dabei im Laufe der Zeit sowohl das in Kapitel 5 vorgestellte Business Model-Framework, als auch der in Kapitel 6 vorgestellte Softwareprototyp (ePoint.SL) weiterentwickelt.

model smart,

play tough!

Business ModelFramework

Key Resources

Team/ Service/ Product:

Endogenous Endogenous

Date:

Critical Success Factors

Exogenous

Which factors influence our company’s success? Which strengths should we enhance and which weaknesses should we eliminate? Which chances should we use and which risks should we avoid? Which trends can be observed on the market and what is their influence on the market/ our company?

What are the sources for market differentiation and how do our activities support them? Which resources do we need to perform our key activities? Which resources do we need to deliver our value proposition? Which resources do our channels, customer relationships and revenues need?

14

Customer Relatio nships Which kind of relationship do our customer segments allow and how much will it cost? Do we have any existing relationships to our customers and how much do they cost? How are these relationships integrated into our routines and touchpoints?

11

Key Activities What are the sources for market differentiation and how do our activities support them? What is our job in the value chain? What are the most important activities? Which benefit/ value will they provide? Which activities should be automated? How can activities be linked in a novel way? Which activities are customers not willing to pay for? Which activities do our channels, customer relationships and revenues need?

7

Value Proposition

COMPETITION Which alternatives exist today? Who and where are our most important (possible) competitors? Which alternatives can come tomorrow? What or where are the (possible) risks? What will happen if we do nothing? What are our most important chances or competencies on market? Do we have market entry barriers? Can we create market entry barriers?

12

Customers

NEED

Which customer segments do we address? What are the central customers’ needs? What do we, our friends, our family or colleagues lack? What are the challenges our customers struggle with? What can we improve? What are the typical use cases? Where is our chance? How important is the solution for our customers? What is important for our customers (price, quality, time, speed, status quo, know-how …)?

4

Who are our customers? Who are our most important customers? Which customer segments do we address? Whose problems do we solve? Which role do our customers have in their organization?

6

1

Vision

Mission

USP Our value proposition/ USP in one short sentence Alternatively: Our value proposition/ USP in a maximum of seven words

Where do we want to be in 2, 5, 10 years?

9

How do we want to be perceived by our stakeholders?

10

5

BENEFIT

Key Partners Which activities should we perform by ourselves and which should we buy from market? Who are our most important partners? Which partners do we need to perform our key activities and to deliver our value proposition? Which key activities are performed by our partners? Which key resources are delivered by our partners? Which dependencies can arise or already exists?

What is the benefit for our customers? Which advantages does our approach create for our customers? Which results do we want to provide to our customers? Which functional, monetary and emotional benefits will our customers have? What is the benefit for our company?

13

Channels

APPROACH What is the design of our solution/ approach? How is our product* designed? What are our core processes? What is our USP? How is the product developed and offered to our customers? In which situations does the customer use our product? What are the most important touchpoints and shared experiences between us and our users? Which role do we play?

3

Which channels are qualified to reach our customers? How do we reach them today? How are these channels integrated into our processes or routines? How can we integrate these channels into the processes or routines of our customers? Which channel performs best? Which channel is most cost-effective?

2

8

(c) 2011 - Andreas Rusnjak (www.businessmodelcreativity.net)

Cost Structure

Resource-based Ressource-based-view

What are the most important costs? Which key activities are the most expensive? Which key resources are the most expensive? Which channels are the most expensive? Which customer relationships are the most expensive? Which key partners are the most expensive?

Market-based

Who are our competitors and in which fields, segments, … are their value propositions superior to our value proposition? In which fields, segments, … is our value proposition superior or on the verge of becoming superior? Do we want to play in a niche? Do we want to be cost leader or differentiator? Which resources, activities and partnerships can lead to strategic competitive advantages?

Revenue Model How do we earn money? Which benefit/ value are customers willing to pay for? Which benefit/ value do customers pay for currently? How (much?) do the customers pay currently? Which contribution provides every revenue stream compared to the total revenue?

15

16 Viewports:

Strategies

Internal View - How do we create value? - Doing the things right! "What are the most important Key Acvites, Resources?" "Who are the most important Key Partners?" "What are the most important Key Costs?" "How can we configure our resources to gain compeve advantage?" "What are Crical Success Factors and how can we influence them by improving our strengths or eliminiaon of our weaknesses?"

External View - For whom and how do we deliver value? - Doing the right things! "Who are our customers?" "What are the customer needs and how can we safsfy them (Approach)?" "How do we reach our customers and which relaonship do they prefer?" "How can we earn money?" "Which external Crical Success Factors are important to us and how can we use them to reduce risks or idenfy chances"

17 more ports... Compeve View

Customer/ Network View

Value Proposion View

Abb. 87: Neues Business Model-Framework mit Schlüsselfragen (seit Ende 2011)

Das aktuelle Business Model-Framework (vgl. Abb. 87) wurde übersichtlicher gestaltet und um bestimmte Viewports, Schlüsselfragen sowie eine Nummerierung ergänzt. Die Nummerierung orientiert sich an einem "idealtypischen Prozess" zur Entwicklung eines neuen Produkts. Die Schlüsselfragen unterstützen den Anwender bei der Gestaltung der einzelnen Business Model-Komponenten, und die Viewports stellen eine Art "Leserichtungen" des Posters dar, um gezielt Strategien oder Herausforderungen des Marktes zu begegnen. Auf das neue Poster1, den Prozess wie auch auf die Viewports wird in der nächsten Publikation genauer eingegangen. Ein ganz besonderer Dank gilt hierbei Herrn Matthias Pohle2, der die Weiterentwicklung tatkräftig unterstützt und jederzeit als kompetenter Ansprechpartner aus der Industrie zur Seite steht.

1 2

Steht unter www.businessmodelcreativity.net zum Download bereit Swisscom (Schweiz) AG - Head of Process & Production Engineering New Business

A. Rusnjak, Entrepreneurial Business Modeling, DOI 10.1007/978-3-658-03767-3, © Springer Fachmedien Wiesbaden 2014

198

Der Software-Prototyp wurde in ein marktfähiges Produkt überführt und dabei von ePoint.SL in runpat3 umbenannt. Im August 2013 ist die Beta-Version am Markt erschienen und kann unter www.runpat.com getestet bzw. lizenziert werden. runpat ermöglicht eine softwaregestützte, strukturierte Gestaltung, Dokumentation und (kollaborative) Weiterentwicklung von Geschäftsmodellen. Es richtet sich an Entrepreneure, Intrapreneure, Produktentwickler, Projektmanager sowie weitere interessierte Anwender und unterstützt sie mittels Schlüsselfragen und Plausibilitäts-Checks bei der Entwicklung von Geschäftsmodellen respektive Produkten. runpat erlaubt einen Export in die unterschiedlichen MS-Office-Formate (docx, xlsx, pptx), u.a. um das Geschäftsmodell im Rahmen eines Businessplans weiter auszuführen. Es können auch Kennzahlen hinterlegt werden, um ein oder mehrere Geschäftsmodelle auf der Meta-Ebene rechnen und steuern bzw. überwachen zu können. Abb. 88 repräsentiert ein Geschäftsmodell von Nespresso, über runpat modelliert.

Abb. 88: Teil des Nespresso-Geschäftsmodells über runpat visualisiert

Da es lange Zeit an einer einheitlichen Bildsprache für Geschäftsmodelle bzw. deren Komponenten mangelte, wurde im Zuge der Entwicklung von runpat auch die Business Modeling Notation (BMN)4 entwickelt und eingeführt. Sie soll sich zum Standard für die Visualisierung von Geschäftsmodellen entwickeln und wird im folgenden Kapitel kurz noch einmal ergänzend dargestellt.

3 4

abgeleitet aus "run" und "pattern" www.businessmodelingnotation.com

199

Business Modeling Notation Mit dem Vorgehensmodell aus Kapitel 4 wurde dargelegt, dass in kreativen, frühen Entwicklungsstadien von Business Models oder Produktentwicklungen ein formales Vorgehensmodell durchaus zu Effizienz- oder Performancezugewinnen führen kann. Neben dem formalen Vorgehensmodell im Entrepreneurial Business Modeling sollte aber auch eine formale Sprache zur Beschreibung von Business Models Eingang finden, die als Standard team-, unternehmens- oder sogar branchenübergreifend genutzt werden kann um Business Models oder Produkte zu entwickeln bzw. weiterzuentwickeln. Aktuell existieren drei [ScMo09] anerkannte Modellierungs-Ontologien für Business Models: (a) die Business Model Ontology (BMO), (b) Resources, Events, Agents (REA) und (c) e3-Value (e3V). Die BMO wird dabei durch das in diesem Buch vorgeschlagene Business Model-Framework, um aktuelle Definitionen erweitert und um ein tiefergehendes Vorgehensmodell ergänzt. Die Business Modeling Notation (BMN) soll mit ihrem Ansatz die genannten drei etablierten Ontologien sowie die in diesem Buch behandelten Business Model-Komponenten zu einer gemeinsamen Ontologie zusammenzuführen. Grundlage für eine grafische Syntax liefert das i* Framework [Yu97]. In diesem Kapitel werden die drei anerkannten Modellierungs-Ontologien und i* vorgestellt sowie Gemeinsamkeiten und Unterschiede beschrieben um damit eine Zusammenführung in die Business Modeling Notation aufzuzeigen.

Business Model Ontology Die Business Model Ontology (BMO) wurde in 2004 von Osterwalder als eine Ontologie für die genaue Beschreibung der Business Models von Unternehmen vorgeschlagen [Ande+06]. Das Business Model wird hierbei aus der Perspektive des agierenden Unternehmens beschrieben. Betrachtet werden die Befriedigung eines bestimmten Kundenbedürfnisses und die damit verbundenen Konzepte. Die Ontologie beschreibt hierfür neun Elemente. Zentrales Element ist die Value Proposition, die eine Übersicht über die Produkte und Dienstleistungen des Unternehmens darstellt, die für den Kunden besonders wertvoll sind. Abb. 89 zeigt eine Übersicht über die neun Komponenten und deren gemeinsame Beziehung zueinander innerhalb von vier grundlegenden Bereichen. Target Customer ist ein definiertes Kundensegment, dem das Unternehmen einen Wert anbietet. Distribution Channel bezeichnet die, für die Interaktion mit dem Kunden, notwendigen Mittel. Relationship ist die Verbindung, die das Unternehmen zwischen sich und dem Kunden aufbaut. Value Configuration bezeichnet die Kombination aus Ressourcen und Aktivitäten, die notwendig sind, um Wert für den Kunden zu schaffen. Capability ist die Fähigkeit, ein Muster von Aktionen wiederholt auszuführen um Wert für den Kunden zu schaffen. Partnership ist eine freiwillige, kooperative Vereinbarung zwischen zwei oder mehr Firmen, um Wert für den Kunden zu schaffen. Cost Structure repräsentiert alle im Business Model verwendeten finanziellen Mittel. Das Revenue Model beschreibt, wie ein Unternehmen Geld verdient durch eine Kombination verschiedener Einkommensströme.

A. Rusnjak, Entrepreneurial Business Modeling, DOI 10.1007/978-3-658-03767-3, © Springer Fachmedien Wiesbaden 2014

200

Abb. 89: Vereinfachtes Business Model Ontology Metamodell in Anlehnung an [Oste04]

In [OsPi11] wird ergänzend eine vereinfachte grafische Neun-Felder-Matrix — der Business Model Canvas (BMC) — für die schnelle Anwendung des Frameworks präsentiert. Abb. 90 zeigt die Anwendung des Frameworks in Form des Business Model Canvas am Beispiel des Unternehmens Skype1. Kunden gegenüber — positioniert auf der rechten Seite des Canvas — bietet Skype als Basisleistung kostenlose Internet- und Videotelefonie und kostenpflichtige Leistungen wie günstige Anrufe in das Festnetz an. Unterschiedliche Farben markieren jeweils zusammengehörige Komponenten2 in ihrer Betrachtung. Während die Zielgruppe zu Beginn Reisende und kleinere Geschäftsleute waren, hat sich das Kundensegment wegen des Erfolgs des Unternehmens auf alle Internetnutzer sowie Telefonnutzer ausgeweitet. Vertrieben wird Skype einerseits über Skype.com aber auch durch Partnerschaften, wie bspw. mit dem Headset-Herstellern Plantronics3. Skype erzielt seine Einnahmen über ein Freemium-Erlösmodell4, d.h. nur ca. 10 % der Kunden von Skype zahlen für Leistungen. In der internen Sichtweise, dargestellt auf der linken Seite des Canvas, konzentriert sich Skype auf seine Kernkompetenz, die Entwicklung der Skype-Software. Skype selbst betreibt bzw. wartet keinerlei Netzinfrastruktur. Diese wird von den Telekommunikationspartnern angemietet.

1 2 3 4

www.skype.com z.B. die Zuordnung Value Proposition - Customer Segment ist in der Ontologie definiert, in der Struktur des Canvas jedoch nicht explizit dargestellt www.plantronics.com Die Hauptleistung wird kostnelos erbracht, über die Nebenleistung, bspw. über Premium-Dienstleistungen, werden Erlöse erzielt

201

Abb. 90: Business Model Canvas Beispiel Skype in Anlehnung an [OsPi11]

REA Die REA Ontologie wurde von McCarthy [McC82] entwickelt und in Zusammenarbeit mit Geerts in [GM99] zu einer vollständigen Ontologie ausgearbeitet. REA betrachtet den Austausch von Ressourcen im Unternehmen aus der Perspektive der doppelten Buchführung. REA ersetzt das Konzept der zwei Buchungssätze durch ein semantisches Model des ökonomischen Austausches sowie der Umwandelung. Die Abkürzung REA benennt die zentralen Konzepte der Ontologie: Resources, Events und Agents. Das Framework basiert auf dem Grundgedanken, dass eine Geschäftstransaktion als ein Austausch von Ressourcen zwischen zwei Akteuren gesehen werden kann. Abb. 91 zeigt das Metamodell eines Austausches in REA. Austausche werden nach dem ExchangePattern abgebildet. Für verschiedene andere Zwecke existieren weitere Pattern, welche sich jedoch alle auf dasselbe Metamodell, also dieselben Grundkonstrukte beziehen (Vergleich [Hrub+06] für weitere Pattern). Aus Platzgründen wird das gesamte Metamodell nicht dargestellt. Zusammengefasst beschreibt REA die Reduzierung einer Ressource zur Erhöhung einer anderen Ressource, d.h. eine Umwandlung. Die Events erfüllen die Commitments, die eingegangenen Verpflichtungen, der beteiligten Agenten. Ein Commitment entsteht durch einen Contract zwischen zwei Agenten und ist definiert als eine Vereinbarung über eine Umwandlung in einer festgelegten Zukunft. Commitments sind demnach der Auslöser für Events. Welche Commitments zusammenhängen, bestimmt sich durch Agreements. Eine Geschäftstransaktion in REA besteht aus zwei verknüpften Umwandlungen, die jeweils einen Austausch beschreiben.

202

Abb. 92 zeigt einen einfachen Fall, in dem Geld gegen Ware ausgetauscht wird. Der Akteur "Buyer" muss die Ressource "Money" ausgeben, um die Ressource "Goods" zu erhalten. Das Event "Payment" löst hierbei das Event "Shipment" aus. Das erläuterte Beispiel deckt die vier fundamentalen Fragen einer Geschäftskollaboration ab: • Wer ist der Verkäufer, • was wird wann ausgetauscht, • und warum? Das "Wer" und das "Was werden durch die EconAgents und EconResources beantwortet. "Wann" und "Warum" wird durch EconEvents sowie die Dualitätsbeziehung ziehen ihnen beantwortet. Während das Framework für die Beschreibung der Buchführung gedacht war, hat es als ontologische Beschreibung von Unternehmen seinen Weg in einige Standards, wie z.B. [ISO01](ISO Open-EDI Specification), gefunden.

Abb. 91: REA Exchange Pattern in Anlehnung an [ScMo09]

Abb. 92: Austausch von Ressourcen im REA, Exchange Pattern (Vergleich [ScMo09])

203

e3value Die e3Value-Methodologie [GoAk03] wurde von Gordijn und Akkermans entwickelt, um den Austausch sowie die Erstellung und den Konsum von Gütern durch Akteure in einem Wertnetz5 darzustellen, in dem Akteure Objekte wie z.B. Güter, Geld oder Dienstleistungen austauschen. e3Value (e3V) ist hierbei als leichtgewichtiges Framework gedacht, um innovative eCommerce Ideen zu konzeptionieren und auf klar definierte Mehrwerte, sowie finanziell, zu prüfen. In [GoAk03] beschreiben Gordijn und Akkermans drei Perspektiven, sogenannte "Viewpoints" bei der Entwicklung von eCommerce-Systemen: Die Wert-Perspektive adressiert unter anderem CxO's6. Sie betrachten den, durch die eCommerce-Idee, geschaffen Wert in finanziellen Größen. Die Informationen dieser Modelle werden meist durch Business Developer (z.B. Marketing- oder Strategieverantwortliche) gesammelt und aufbereitet. Betrachtet werden insbesondere Werterstellung, -verteilung und -konsum. Hinzukommen die Prozess-Perspektive sowie die Informationssystem-Perspektive. Für die Darstellung der Wert-Perspektive mangelt es, nach Gordijn und Akkermans, an Modellierungswerkzeugen und sie schlagen deshalb e3Value für diesen Zweck vor. Ebenfalls wird die fehlende Bekanntheit von Modellierungstechniken mit Blick auf Business Stakeholder angemerkt. e3V basiert auf dem Prinzip der ökonomischen Reziprozität, also dem Austausch von wertvollen Objekten, z.B. Ware gegen Geld. Abb. 93 zeigt einen solchen Austausch. Die sogenannten Market Segments sind als Rechtecke dargestellt (A). Market Segments sind eine Menge von Akteuren, welche zusammen im Markt zur Wertschöpfung agieren. Die ausgetauschten Value Objects, siehe Beschriftung (B), werden immer in Verbindung mit einem Value Transfer (C) dargestellt. Value Transfers finden zwischen zwei Value Ports (D) statt, welche durch Value Interfaces (E) gruppiert werden. Value Interfaces repräsentieren die Teilnahme an einer Value Activity, einer wertschöpfenden Aktivität. Diese wird innerhalb von Market Segments verwendet, ist jedoch in diesem einfachen Beispiel nicht enthalten. Value Ports definieren ein Angebot oder ein Bedürfnis im Rahmen des Value Interfaces. Startstimulus (G) und Stopstimulus (H) defnieren einen sogenannten Scenario Path (F). Ein Scenario Path beschreibt die notwendigen Austausche zwischen mehreren Segmenten zur Wertschöpfung. Im Beispiel der Abb. 93 genügt der ein Austausch von Geld gegen Ware, um die Wertschöpfung zu erreichen. In komplexeren Modellen werden jedoch häufig mehrere Austausche zwischen mehreren Akteuren benötigt. Diese können dann durch einen Scenario Path als zusammengehörend markiert werden. Abb. 94 zeigt die vorgestellten sowie einige weitere Konstrukte der e3V-Notation in der Übersicht. Alle dargestellten Konstrukte sind in [GoAk03] genauer beschrieben.

Abb. 93: Einfacher Austausch von e3-Value Werten (Vergleich [ScMo09]) 5 6

value web C-Level Management, z.B. Chief Financial Officer, Chief Marketing Officer etc.

204

e3V beinhaltet ebenfalls ein Vorgehensmodell, welches die Schritte von einer eCommerce Idee bis zur Umsetzungsentscheidung beschreibt. Das Vorgehensmodell geht von einer vorhandenen, innovativen eCommerce Idee aus, für die ein grundlegendes Value Model (e3V Modell) erstellt wird. Entstehen während der Erstellung des Value Models und der anschließenden Betrachtung der Informationsystem- sowie der Prozessperspektive neue Ideen7, so wird der Vorgang wiederholt bis ein grundlegendes Value Model alle Ideen enthält. Anschließend wird das Modell durch feste, im Framework verankerte Regeln, auf Profitabilität geprüft und die finale Umsetzungsentscheidung getroffen. Dies geschieht meist durch Führungskräfte. Ist die Entscheidung positiv, so folgt die Umsetzung. Neben diesem allgemeinen Vorgehen werden verschiedene Ansätze, z.B. Actor-Orientied oder Market Oriented, für die Entwicklung des Modells vorgestellt. Diese sollen hier nicht näher erläutert werden und können in [GoAk03] nachgelesen werden.

Abb. 94: Konstrukte der e3-Value-Notation (Vergleich [ScMo09])

i* "The i* framework was developed for modeling and reasoning about organizational environments and their information systems." [Yu97]

i* ist ein von Yu und Mylopoulos ([YuMy93], [Yu93]) entwickeltes Framework zur Modellierung der Systemumgebung und der beteiligten Stakeholder im Rahmen des Systems Requirements Engineering. Ebenfalls können Anforderungen der Prozessneugestaltung und der sozialen Umgebungen von (agentenorientierten) Softwaresystemen abgebildet werden. 7

Wie es beim Auseinandersetzen mit der Idee aus der Perspektive eines festen Frameworks wie e3-Value häufig geschieht [GoAk03]

205

Der Name i* verweist auf das Prinzip der verteilten Intentionen, also der Absichten der Akteure innerhalb eines Modells. i* integriert das Non-functional Requirements(NFR)-Framework [Chun+00] über ein Softgoal-Element.

Abb. 95: i* Modelltypen aus [Yu97]

i* Modelle beantworten die Frage nach der Systemumgebung, nach Abhängigkeiten und nach dem "Warum?". Damit kann eine Notwendigkeitsbegründung des Systems im Allgemeinen abgeleitet werden. Die erstellten Modelle sollen die Kausalitäten hinter den Abläufen (Rationale) darstellen. Statt dem "Wie genau?" steht die Frage "Warum?" im Vordergrund. Die Stakeholder und Systeme werden als aktive "Actors" mit Absichten und Zielen modelliert. Die weiteren Modellelemente bilden die von den "Actors" angestrebten Zustände, sogenannte Intentional Elements. Dabei kommt es zu Abhängigkeiten zwischen den Stakeholdern und ihren Absichten. Da nicht jeder "Actor" seine Absichten allein, zumindest nicht effizient, umsetzen kann, muss er sich auf andere "Actors" verlassen. Durch diese Kooperationen machen die "Actors" sich verwundbar und es kann zu Konflikten in den Zielsetzungen kommen.

"The i* modelling framework for earlyphase requirements engineering" [Yu97]

206

Durch die Betonung des Einflusses der Stakeholder auf die Anforderungen ist i* besonders für die Modellierung der Early Requirements geeignet. Die treiben Kräfte der Anforderungen werden abgebildet und gleichzeitig in ihren organisationalen Kontext eingeordnet. Nach Abbildung der Early Requirements kann das Modell zur Ableitung der Late Requirements genutzt werden.

Abb. 96: * Diagrammtypen aus [Yu97]

207

i* unterscheidet dabei zwei Modellierungsarten: das Strategic Dependency (SD) und das Strategic Rationale (SR) Diagramm (vgl. Abb. 96). SD-Diagramme beinhalten nur SD-Verknüpfungen, also strategische Abhängigkeiten. SD-Verknüpfungen beschreiben, von welchen Akteuren andere Akteure abhängig sind, da sie Leistungen oder ein sonstiges Mitwirken von diesen benötigen. SR-Diagramme bilden die Abhängigkeiten zwischen bestimmten Akteure sowie die bezogenen Leistungen ab. SR Diagramme vertiefen die Modelle weiter, indem die Akteure durch die sogenannte Actor-Boundary geöffnet und ihr "Innenleben" beschrieben wird. Hierzu zählen unter anderem deren Ziele sowie Mittel um diese zu realisieren. Neben sechs verschiedenen Akteur-Beziehungen, z.B. "Teil von", sowie neun Einflusspfeilen für Softgoals, z.B. "schadet", enthalten SR-Diagramme zusätzlich die Task-Decomposition-Verknüpfung. Diese definiert, welche andere Elemente zur Erfüllung dieser Aufgabe beitragen. Die Task-Decomposition ist also eine Zweck-Mittel-Beziehung.

Verhältnis der Business Model Ontologien Trotz der unterschiedlichen Ausrichtungen der Ontologien lässt sich ein gemeinsamer Kern feststellen, der Austausch von Objekten. Hierbei beschreibt die BMO — im Vergleich zu den anderen Ontologien — relativ ausführlich die Teilaspekte eines Business Models aus der Perspektive eines einzelnen Unternehmens. Dabei werden bspw. Fragen im Sinne von "Wer sind unsere Kunden?" und "Welche Ressourcen brauchen wir?" beantwortet. Die Aufzählung aller wichtigen Komponenten (z.B. Kunden, Vertriebskanäle, etc.) kann dabei als "Checkliste" für die Prüfung von Modellen verwendet werden. Die grafische Repräsentation in Form des BMC macht sie zu einem guten Kommunikations- und Strukturierungstool für Einsteiger im Bereich Business Modeling. Durch die Berechnung eines groben Saldos, der als Teil der Ontologie definierten Einnahmen und Ausgaben, lässt sich die Profitabilität auf Basis des Modells leicht einschätzen. Die Anwendbarkeit der Ontologie ist durch die vereinfachte Darstellung des BMC jedoch eingeschränkt. Viele der in der BMO definierten Abhängigkeiten finden ihren Weg nicht in die grafische Repräsentation. Aus Sicht des Requirements Engineerings fehlt beispielsweise eine detaillierte Darstellung der Abhängigkeiten, wie sie z.B. i* bietet. So wird bspw. die Ausführung von Aktivitäten oder Bereitstellung von Ressourcen durch Partner nicht explizit abgebildet. Die Einschätzung der Profitabilität ist auch eines der Kernziele von e3V. Statt die Perspektive eines bestimmten Akteurs einzunehmen, wird das Zusammenspiel aller Akteure objektiv (grafisch) — aus der Vogelperspektive — abgebildet. Welche Austausche zusammen an welchen wertschöpfenden Aktivitäten teilnehmen ist hierbei durch das Value Interface/ Port/ Activity Konzept klar strukturiert. Durch die strukturierte Abbildung eines "Big Pictures" lässt sich ein guter Überblick über das Gesamtkonzept erzielen, was auch das Ansinnen von e3V ist. Nicht vorhanden in e3V sind, neben den Zielen, weitere Kompontenten wie Ressourcen und Beziehungen der Akteure, insbesondere die Kanäle, über welche bestimmte Akteure erreicht werden. Während das Fehlen dieser Komponenten die Abbildung der konkreten Flüsse zwischen den Akteuren in e3V nicht beeinträchtigt, sind sie doch für eine vollständige Spezifikation eines Business Models (siehe Distribution Channel in [Oste04]) notwendig.

208

Durch seine Entstehungsgeschichte aus der doppelten Buchführung konzentriert sich REA auf die einen Austausch auslösenden Ereignisse des Business Models und hebt sich so durch eine abstraktere Struktur von den anderen, dargestellten Ontologien ab. Durch die Abbildung der Modelle in einer Entity-Relationship [Chen76] ähnlichen Darstellung, d.h. durch Entitäten und Assoziationen sowie durch die stark formale Struktur, ist REA mehr auf die Anforderungsermittlung, z.B. für die Entwicklung von Buchhaltungssystemen, ausgerichtet. Hierbei sollen insbesondere Verpflichtungen abgebildet werden, damit deren Einhaltung zu Laufzeit des Systems überprüft werden kann. Zwar soll die starke Abstraktion das Modell von der operationalen Umsetzung separieren, jedoch bleibt die Ontologie durch Ihre speziellen Elemente, wie z.B. Ereignisse und Verträge, gefühlt in ihrer speziellen Domäne. Die Einordnung als Business Modeling Ontologie verdankt REA der Tatsache, dass, ähnlich wie bei den anderen Ontologien, alle notwendigen Konstrukte für Austauschbeziehungen und weitere typische Business Model Aspekte (z.B. Verträge) vorhanden sind. Die in REA definierten Business Pattern erlauben eine reglementierte Betrachtung von Modellen im Bereich Business Models. Die teils ausgeprägte Detailtiefe verhindert jedoch die Betrachtung des "Big Pictures", sodass zunächst die Entwicklung anderer Modelle vorgezogen werden sollte. Dies eröffnet die Möglichkeit, die Austauschbeziehungen, welche den Kern der Modelle ausmachen, in einer einfacheren Form abzubilden, bevor das formale REA-Modell erstellt bzw. generiert wird. i* ist, im Gegensatz zu den anderen vorgestellten Ontologien, ein Requirements Engineering Framework und nicht für die Abbildung von Business Models, sondern für die Abbildung von organisatorischen Umgebungen von Informationssystemen und Prozessen entwickelt worden. Durch den Fokus auf die Akteure, ihre Absichten und Abhängigkeiten, beschreibt i* jedoch einen für das Business Model und seine Umgebung essentiellen Aspekt. Wie e3V ist die grafische Darstellung der Modelle ein wesentlicher Vorteil für den Einsatz im Business Modeling. Wesentliches Einsatzhindernis für den Einsatz in der Praxis ist die grafische Syntax. Detaillierte Kritikpunkte sowie Verbesserungsvorschläge hierzu werden in [Mood09] sowie in [Mood+10] gegeben. Die drei vorstellten Business Model Ontologien sowie i* bilden — in ihren jeweiligen Ausprägungen — die Domäne der Business Models umfassend ab, von den Early Requirements (z.B. Business Model Canvas) bis zu den Late Requirements (z.B. REA). Eine kontinuierliche Nutzung der Ontologien, bspw. über den Lebenszyklus eines Business hinweg, ist aus mehreren Gründen schwer möglich. Tab. 28 zeigt mögliche Hemmnisse, aber auch mögliche Vorteile eines dauerhaften Einsatzes der einzelnen Ontologien. Insbesondere die mangelnde Ausrichtung an einem nicht technischen bzw. nicht fachspezifischen Publikum wird hierbei als starkes Anwendungshemmnis wahrgenommen. Sowohl i* als auch e³ Value haben jedoch das Potential, Business Models mit variablem Detailgrad grafisch abzubilden. Hinderlich ist in beiden Ontologien jedoch der schwierige grafische Syntax der Modelle. Im Folgenden soll daher eine (vereinfachte) Vereinigung der Ontologien BMO, e³ Value, i* sowie REA in Kombination mit gezielter Optimierung des grafischen Syntaxes [Mood+09], [Mood+10] als BMN vorgestellt werden.

209

Vorbild ist hierbei die für interdisziplinäre Zusammenarbeit konzipierte BPMN-Sprache, welche trotz hoher Mächtigkeit in der Abbildung von Prozessen auf (soweit möglich) intuitives Verständnis in der Darstellung setzt. Moody et al. haben in [Mood+09] eine umfangreiche Analyse der visuellen Syntax von i* durchgeführt und in [Mood+10] weiter detailliert. Die Analyse basiert auf einem Framework [Mood09] für die Bewertung grafischer Notationen. Zentrale Kritikpunkte der Arbeit sind: Zu hohe "Graphic Complexity" (grafische Komplexität), Mangelhafte "Visual Expressiveness" (Visuelle Ausdrucksstärke) sowie fehlende "Semiotic Clarity" (eine Bedeutung für ein Symbol). Diese und weitere beschriebene Kriterien wurden bei der Entwicklung der grafischen Syntax der BMN berücksichtigt. Ontologie

Hemnisse

Vorteile

Mangelnde Unterstützung der gesamten Ontologie in der BMC Methodik

Detaillierte Definition für Vollständigkeit und Abhängigkeiten

REA

Umständlicher Einsatz durch fehlende visuelle Notation, zu starker Fokus auf detaillierte Austauschabbildung

Aufbereitung der Early Requirements zu Late Requirements

e3value

Fehlende Business Model Komponenten nach modernem Begriffsverständnis (vgl. z.B. Business Model Definition in [Rusn13])

Grafische Darstellung wichtiger Flüsse zwischen den Akteuren

Umständlicher grafischer Syntax[Mood+09], [Mood+10]

Grafische Darstellung wichtiger Abhängigkeit und zusammenhänge

BMO

i*

Tab. 28: Hemmnisse und Vorzüge der Ontologien im Hinblick auf das Business Modeling

Die in Tabelle 1 dargestellten Hindernisse sollen im Folgenden durch die Vereinigung der Ontologien zu einer Business Modeling Notation (BMN) weitestgehend eliminiert werden. Um die Anwendbarkeit einfach sowie Einsteigerfreundlichkeit dieses neuen Frameworks hoch zu halten, sind bewusst nicht alle semantischen Konstrukte der einzelnen Ontologien auf die BMN angewendet worden. Die Business Modeling Notation ist damit eine reduzierte Vereinigung der vorgestellten Ontologien und wurde für die Abbildung von Business Models in allen Stadien der Unternehmens- oder Produktentwicklung konzipiert. Insbesondere die Early Requirements können strukturiert für die weitere Bearbeitung erfasst werden. Da BMN-Modelle in allen Phasen der Unternehmensentwicklung eingesetzt werden können, ist bei der Modellierung auf die Empfängerangemessenheit sowie die Botschaft des Modells zu achten. Die BMN basiert auf den bisher vorgestellten Ontologien und führt diese mithilfe einiger Vereinfachung zu einem einheitlichen Framework zusammen.

MODELLIERUNGSRICHTLINIE Da BMN-Modelle in sehr unterschiedlichen Umgebungen eingesetzt werden, sollte bei der Modellierung ein Empfänger sowie ein Kommunikationsziel definiert werden.

210

Abb. 97: Business Modeling Notation8 - Elemente

8

www.businessmodelingnotation.com

211

Abb. 98: Business Modeling Notation - Flüsse, Konstrukte & Farbkonzept

212

Metamodell der BMN Die BMN vereint in Ihrem Metamodell die syntaktischen Konstrukte der beschreibenen Ontologien und ermöglicht die Abbildung der Modelle dieser Ontologien in einfacher, grafischer Form. Abb. 99 zeigt das komplette Metamodell der BMN. Das Metamodell bietet durch die Möglichkeit der Definition von weiteren Leistungs- und Anforderungselementen das Potenzial, an spezielle Anwendungsfälle, wie den Einsatz in speziellen Domänen, angepasst werden zu können. Das Metamodell unterscheidet drei zentrale Metatypen: • Akteure: Kunde, Partner, Wettbewerber & "Ich selbst". • Leistungselemente: Elemente die über Leistungsflüsse zu Wertschöpfungsketten verknüpft werden und von Akteur zu Akteur fließen, z.B. Ziel, weiches Ziel, Kundenbedürfnis, Angebot, Vertriebskanal, Kundenbindung, Ressource und Aktivität. • (Spezielle) Anforderungselemente: Elemente die nur bestimmten Elementen zugeordnet werden können, z.B. Kundenbindung.

Abb. 99: BMN Metamodell

Akteure

DEFINITION "AKTEUR" Ein Akteur ist eine natürliche bzw. juristische Person oder eine Gruppe von Personen, die an einem Business Model beteiligt ist/ sind. Beispiele: "Behörde" oder "Gründer". (vgl. "Actor" in [Yu93], "Agent" in [McCa82])

213

Akteure bilden die Eckpfeiler der BMN Modelle, analog zu i*, e³V und REA. Zwischen den Akteuren werden je nach Rolle des Akteurs verschiedene Leistungen ausgetauscht. Während i*, e³V und REA nicht zwischen verschiedenen Akteuren unterscheiden, bietet die BMN mehrere konkrete Akteure für häufig auftretende Fälle an. Die Verwendung des generischen Akteurs ermöglicht die Abbildung von spezifischen Fällen. Mittelpunkt der BMN Modelle ist der Ich-Akteur, welcher die Perspektive der modellierten Unternehmung, Abteilung, Person etc. einbringt. Der Ich-Akteur definiert somit die Perspektive, aus der das Business Model erstellt wird. Die Modellierungsperspektive der BMN ist hierbei eine Kombination der subjektiven BMO und objektiven e³-Value Perspektive. Die Leistungen, welche zwischen den Akteuren ausgetauscht werden, werden durch die Leistungselemente beschrieben. Die zentrale Interaktion von Akteuren im Modell ist diejenige zwischen dem Ich-Akteur sowie den Kunden. Das Business Model sollte hierbei so aufgebaut sein, dass es die Bereitstellung der richtigen Produkte und Dienstleistungen für die Erfüllung der Kundenbedürfnisse ermöglicht. Hierbei kann es mitunter wichtig sein, zwischen reinen Usern, also Kunden, welche nur kostenlose Angebote nutzen, und den zahlenden Kunden zu unterscheiden.

DEFINITION "KUNDE" Ein Kunde ist ein Akteur, dem etwas angeboten wird. Der Kunde hat konkrete Bedürfnisse, welche durch das Angebot erfüllt werden sollen. Beispiele: "Schüler", "Technologieunternehmen" (vgl. "Market Segment" in [GoAk03], "Target Customer" in [Oste04])

Während der Kunde im Modell Leistungen meistens direkt, manchmal indirekt, vom Ich-Akteur erhält, kann der Ich-Akteur wiederrum Leistungen von bestimmten Partnern beziehen, i.d.R. handelt es sich um Aktivitäten und/ oder Ressourcen, welche nicht im Unternehmen vorhanden oder schwer umzusetzen sind. Durch den Bezug von notwendigen Leistungen steht das Unternehmen in einen Abhängigkeitsverhältnis zu seinen Partnern. Wie stark diese Abhängigkeit ist, hängt von der Notwendigkeit der erhaltenen Leistungen sowie der Substituierbarkeit über andere Partner ab.

DEFINITION "PARTNER" Ein Partner ist ein Akteur, der Ressourcen oder Aktivitäten liefert, die für die Erstellung und Bereitstellung des Angebotes notwendig sind. Beispiele: "Lieferant für Verpackungsmaterial", "Werbeagentur" (vgl. "Partnership" in [Oste04])

Das Abhängigkeitsverhältnis ist abgeleitet vom Dependency-Prinzip der i*-Notation. Eine Unterscheidung zwischen besonders kritischen und wenig kritischen Abhängigkeiten wird zur Komplexitätsreduktion nicht vorgenommen. Die folgende Modellierungsrichtlinie zeigt hierbei den Leitgedanken auf.

214

Wettbewerber bedrohen ein Business Model durch die Bereitstellung von gleichen bzw. ähnlichen Produkten oder Ersatzprodukten. Die BMN bildet hierbei ab, ob der Wettbewerber ein konkretes Angebot bedroht oder ein Kundenbedürfnis auf andere Weise erfüllt. Weitere, an dieser Stelle nicht näher beschriebene, Akteure können z.B. Gesetzgeber oder externe Interessensgruppen sein.

DEFINITION "WETTBEWERBER" Ein Wettbewerber ist ein Akteur, der ein bestimmtes Angebot des Business Models bedroht. Die Bedrohung kann durch Bereitstellung desselben Angebots oder einer Ersatzleistung bestehen. Beispiel für einen Online-Buchversand: "Buchfachhandel" (vgl. "Competition" in [CaWi06])

MODELLIERUNGSRICHTLINIE Das Modell sollte bei der ersten Erstellung für das Business Model essentielle Elemente enthalten, um nicht zu detailliert zu beginnen. Wichtige Details, können später wesentlich zielgerichteter ergänzt werden. Eine Abbildung der Profitabsicht des Ich-Akteurs ist nicht notwendig, da Business Models eine kommerzielle Absicht implizieren. Wird zwischen profit- und nicht profitorientierten Akteuren im Modell unterschieden (z.B. im Fall von Non-Profit Organisationen) kann eine Darstellung der Absicht des Akteurs zur besseren Verständlichkeit beitragen.

Grafische Gestaltung

Abb. 100: BMN-Akteure

215

Die visuelle Distanz, die Differenz im Aussehen, verschiedener Notationselemente sollte ihrer semantischen Distanz, also der Differenz ihrer Bedeutung, entsprechen. Ebenfalls sollte eine möglichst intuitive Symbolik verwendet werden, da dies das Verständnis bei Modellierungseinsteigern signifikant steigern kann [Mood+10]. Diesen Grundsätzen folgend sind die BMN-Akteure stilisierten Figuren nachempfunden. Speziellere Akteure wie Kunden und Partner werden hierbei durch kleine Ergänzungen gekennzeichnet. Der Stern Symbolisiert die "favorisierte"9 Behandlung der Kunden, da ihm die Angebote des Unternehmens gefallen sollen bzw. dieser über das Business Model adressiert wird. Die Krawatte des Partners symbolisiert Seriosität in der Bereitstellung von Produkten. Der Wettbewerber fällt aus diesem Raster heraus, da er in der Literatur nicht dem Business Model direkt, sondern der Business Model Umgebung, zugeordnet wird. Abb. 100 zeigt die grafische Darstellung der Akteure. Die Zugehörigkeit zur Gruppe der Akteure wird in BMN-Modellen durch die Verwendung eines Farbkonzeptes ermöglicht. Dieses wird in Abb. 101 dargestellt.

Abb. 101: BMN Farbkonzept

Leistungselemente

DEFINITION "ZIEL" Ein Ziel ist eine klar definierte Absicht eines Akteurs, welche nach SMART-Kriterien (spezifisch, messbar, erreichbar, relevant und terminiert) eindeutig definiert sein sollte. Beispiele: "Versand ab Juni 2013 kostenlos anbieten" oder "bis 2014 1.000 Neukunden gewinnen" (vgl. "Goal" in [YuMy93])

9

Der Stern symbolisiert die Markierung eines Elementes als Favorit in der modernen Web- und Softwaregestaltung

216

Das Verhältnis der im Modell vorhandenen Akteure kann durch die Beschreibung ihrer Ziele abgebildet werden. Analog zu i* unterscheidet die BMN hierfür zwischen Zielen und weichen Zielen. Die Ziele sind die treibenden Kräfte der Akteure. In i* nutzen die Akteure ihre Ressourcen und Fähigkeiten die Erreichung ihrer Ziele zu gestalten. Ziele bilden eine Dimension ab, welche weder in e³V noch in REA vertreten ist. Die BMN-Modelle tragen durch die Verwendung von Zielen zur Requirements Traceability und der Nachvollziehbarkeit der Entscheidung für oder gegen bestimmte Anforderungen bei. Hier wird die Verankerung der BMN in das Requirements Engineering, als Oberdisziplin des Business Modelings, deutlich. Die abgebildeten Ziele der Akteure sollen hierbei die Motivation des Akteurs begründen, am Business Model zu partizipieren. i* integriert das NFR [Chun+00] Framework für die Abbildung von weichen Faktoren und Anforderungen. Um diese auch in der Domäne der Business Models auf strategischer Ebene abzubilden, wird in der BMN das weiche Ziel verwendet. Weiche Ziele in der BMN sind nicht eindeutiger definiert.

DEFINITION "WEICHES ZIEL" Ein weiches Ziel ist eine Absicht eines Akteurs, welche schwer mess- und terminierbar ist. Beispiele: "Eine trendige Marke aufbauen", "Freude verbreiten" (vgl. "Softgoal" in [YuMy93])

Weiche Ziele erfüllen ebenfalls die Kriterien der Spezifität, Relevanz sowie Erreichbarkeit. Nicht eindeutig bestimmbar ist hierbei jedoch die Mess- und Terminierbarkeit, wobei in diesem Fall der Versuch unternommen werden kann, weiche Ziele über möglichst viele harte Unterziele smart zu gestalten. Die Einschränkung bezieht dieser beiden Kriterien bezieht sich insbesondere auf die Bestimmung, ab welchen Zeitpunkt das weiche Ziel als erreicht gilt. Da Faktoren dieser Art einen entscheidenden Einfluss auf das Business Model haben können sollten sie von eindeutig mess- und terminierbaren Zielen getrennt werden, um diese Unschärfe bewusst zu kommunizieren. Abbildung 15 zeigt die verschiedenen Beziehungen, die ein Akteur zu einem Ziel, bzw. einem allgemeinen Leistungselement, haben kann. In (1) wird ein Ziel durch den Kunden begehrt, jedoch ist kein Anbieter für die Erfüllung vorhanden. Im Fall (2) wird das Ziel des Kunden durch einen Anbieter, auf unbestimmte Weise, erfüllt. (3) zeigt ein Ziel, welches der Akteur selbst erreicht bzw. erreichen kann.

217

Abb. 102: Zielbeziehung der Akteure

DEFINITION "KUNDENBEDÜRFNIS" Ein Kundenbedürfnis ist ein Ziel, welches einem oder mehreren Kunden zugeordnet ist. Beispiele: "Gute Bücher finden", "Mit freunden kommunizieren (vgl. "Need" in [CaWi06], vgl. [Scha12])

Ein wichtiger Spezialfall bei der Betrachtung der Ziele der verschiedenen Akteure im Business Model sind die Ziele der Kunden. Der Anspruch eines erfolgreichen Business Models ist es, diese Ziele der Kunden durch passende Produkte zu erfüllen. Hat ein Kunde ein bestimmtes Bedürfnis, so ist dieses zunächst unerfüllt. Er kann das Bedürfnis nicht selbst erfüllen und benötigt daher einen Akteur, welcher die Erfüllung anbietet. Diese Beziehung wird durch den Leistungsfluss dargestellt.

Wie ein Unternehmen die Bedürfnisse der Kunden erfüllt, wird durch die Definition von Angeboten beschrieben. Angebote definieren konkrete Dienstleistungen und Produkte welche der Kunden nutzen, bzw. konsumieren kann. Angebote können hierbei kostenpflichtig unter Anwendung verschiedenster Preismodelle oder kostenfrei zu Verfügung gestellt werden.

DEFINITION "ANGEBOT" Ein Angebot ist ein konkretes Produkt oder eine konkrete Dienstleistung, welches bzw. welche einem Kunden oder einer Kundengruppe angeboten wird. Beispiele: "Günstige Bücher", "Unternehmensberatung" (vgl. Value Proposition in [Oste04])

218

Die Angebote werden über verschiedene Vertriebs- und Kommunikationskanäle an den Kunden vertrieben. Ein Kanal kann hierbei eine oder mehrere der in Definition "Vertriebskanal" beschriebenen Aufgaben einnehmen.

DEFINITION "VERTRIEBSKANAL" Ein Vertriebskanal ist ein Weg zur Aufmerksamkeitsgenerierung, Verkaufstransaktionsabwickelung, Belieferung und Betreuung eines Kunden. Beispiele: "Ladengeschäft", "Onlineshop" (vgl. "Distribution Channel" in [Oste04], "Channels" in diesem Buch)

Abb. 103: BMN Wertschöpfungskette

Da nicht alle der in der Definition beschriebenen Aufgaben des Vertriebskanals gleichzeitig dargestellt werden können, ohne die Darstellung zu komplex werden zu lassen, wurde die intuitivste Aufgabe, das "Shipping", d.h. der Versand gewählt. Diese Verwendung des Schifffahrt-Motives deutet ebenfalls die Verwandtschaft zum Wettbewerb, "Konkurrenz umschiffen" (Hai) sowie zur Kundenbindung an. Die zentrale Aufgabe des Vertriebskanals ist die Akquisition von neuen Kunden und die Aufrechterhaltung der bestehenden Kundenbeziehungen. Um die Nachhaltigkeit dieser — zumeist teuren — Akquisition zu erhöhen, sollte das Business Model Kundenbindungsmechanismen integrieren. Diese können einem Vertriebskanal, aber auch einem oder mehreren Kunden zugeordnet sein. Abb. 103 zeigt eine einfache Wertschöpfungskette — über die logische Verknüpfung von Leistungselemente — vom Ich-Akteur bis zum Kunden. Das Angebot wird hierbei über einen Vertriebskanal angeboten und erfüllt das Ziel (Bedürfnis) eines Kunden.

DEFINITION "KUNDENBINDUNG" Kundenbindung: Die Kundenbindung beschreibt das Verhältnis zum Kunden und damit, warum ein Kunde ein Angebot kontinuierlich nutzt. Beispiele: "persönliche Beratung", "Lock-in-Effekt"

Kundenbindung sind Mechanismen oder Effekte, die sich auf Kunde, Vertriebskanal oder Angebot ableiten. Die Kundenbeziehung wird wegrationalisiert, da sich Ihre Effekte auf Art der Interaktion (Kanal) und Bindung (Kundenbindung) aufteilen lassen. Kundenbeziehung hat u.A. bei Osterwalder den Unterton: „Durch welche Beziehung können wir den Kunden halten?“. Die Kundenbindung "verankert" die Nutzung des Angebotes beim Kunden.

219

Das "Anker"-Symbol wurde deshalb wegen seines inhaltlichen Verhältnisses zum Wettbewerb sowie zum Vertriebskanal gewählt, vgl. hierzu Abb. 97. Die Kundenbindung ersetzt in der BMN die Stellung der in [Oste04] beschriebenen Kundenbeziehung. Grund hierfür ist, dass sich bei der Entwicklung von Modellen in sehr frühen Phasen, die Konzentration auf den Bindungsteil der Beziehung als zielführender erwiesen hat. Eine nachträgliche Ergänzung wäre durch Definition eines weiteren Anforderungselementes des Kunden einfach umsetzbar. Um das Framework einfach zu gestalten, wurde bisher darauf verzichtet. Um das Nutzen-/ Wertversprechen eines Business Models erfüllen zu können, müssen bestimmte Aktivitäten bzw. Prozesse ausgeführt werden und Ressourcen vorhanden sein. Aktivitäten und Ressourcen werden insbesondere von Akteuren benötigt, um Ziele zu erreichen und die Wertschöpfungskette im wirtschaftlichen Sinne zu realisieren bzw. rentabel zu halten. Das Verhältnis zwischen Ressourcen und Aktivitäten wird in der BMO [Oste04] und [YuMy93] als eine Zweck-Mittel Beziehung definiert. Die Ressource wird also für die Ausführung der Aktivität benötigt. Sowohl in i*, in der BMO und in e3V werden die Aktivitäten weiterhin den ausführenden Akteuren bzw. bestimmten Angeboten zugeordnet.

DEFINITION "RESSOURCE" Eine Ressource ist ein Sachmittel, Finanzmittel, Schutzrecht, eine Arbeitskraft oder Information, welche zur Angebotserstellung benötigt wird. Beispiele: "Buchpapier", "Know-How" (vgl. Capability in [Oste04], vgl. EconRessource in [McCa82])

DEFINITION "AKTIVITÄT" Eine Aktivität ist eine Aufgabe oder auch ein ganzer (Erstellungs-) Prozess, welche bzw. welcher zur Angebotserstellung im Business Model erfolgen muss. Beispiele: "Programmierung", "Produktion" (vgl. Activity in [Oste04], Value Activity in [GoAk03])

MODELLIERUNGSREGEL Aktivitäten und Ressourcen können entweder von einem Akteur besessen bzw. selbst ausgeführt werden oder durch einen anderen Akteur durchgeführt bzw. zur Verfügung gestellt werden.

220

Detailflüsse Die eben angedeutete Zweck-Mittel-Beziehung wird in i* über Decompositionsverknüpfungen abgebildet. Das BMN-Äquivalent ist der Detailfluss. Er beschreibt die Notwendigkeit der Erreichung bzw. das Vorhandensein bestimmter Anforderungen, z.B. das Erreichen eines bestimmten Ziels oder die Ausführung einer Aktivität. Abbildung 25 zeigt mögliche Operationalisierungen eines Ziels ausgehend von einem Akteur. Durch den Detailfluss ist eine Zuordnung von Zielen, weichen Zielen, Aktivitäten und Ressourcen zu bestimmten Akteuren des Business Models möglich. Wird ein Detail einem Leistungselement zugeordnet, so wird es dem anbietenden Akteur zugeordnet. Gleiches gilt für den gesamten Detailbaum, d.h. die Menge der Detailelemente, die von einem Leistungselement abgehen (vgl. Abb. 104).

DEFINITION "DETAILFLUSS" Der Detailfluss beschreibt Elemente, durch die Zuordnung weiterer Elemente, näher. Die Menge aller Nachfahren eines Elementes über den Detail Link werden als Detailbaum bezeichnet.

Abb. 104: BMN Detailbaum

221

Elemente, welche als Detail einem Leistungselement untergeordnet sind, werden als Anforderungselemente bezeichnet. Sie definieren spezielle Anforderungen oder die Beschaffenheit der Modellelemente. Auf diese Weise erlaubt die BMN — neben der Top-Level-Definition des Business Models — die Spezifikation von ersten Anforderungen in direkter Verknüpfung mit dem Modell. Spezielle Anforderungselemente (zurzeit nur Kundenbindung) sind ebenfalls Details, jedoch in der Verwendung nur für bestimmte Typen einsatzbar. Im Fall der Kundenbindung z.B. nur als Detail des Kunden. Dies bietet die Möglichkeit die BMN auf speziellere Anforderungsdomänen anzupassen, wenn deren ontologische Beschreibung bekannt ist. Analog zu den Value Interfaces in e³V können Leistungsflüsse in der BMN auch von Detailelementen, anstatt des zugehörigen Akteurs ausgehen. Dies erlaubt den Ursprung der Leistung genauer zu definieren. Zusammenfassend hat der Detailfluss die drei folgenden Aufgaben: • Zuordnung von Elementen zu Akteuren, • Operationalisierung von Elementen, • sowie detaillierte Unterteilung von Elemente in weitere, gleiche Komponenten. Die mehrfache Bedeutung dieses Flusses wiederspricht dem Prinzip der semiotischen Klarheit, also der Zuordnungen genau einer Bedeutung zu jeweils einem Symbol. Dieses Symboldefizit (Mehrere Bedeutungen eines Symbols) soll zur Vereinfachten Anwendung der BMN beitragen. Detailflüsse sollen im Modell tendenziell vertikal modelliert werden, um die Unterscheidung zum Leistungsfluss weiter zu verbessern (vgl. Abb. 105). Vertikale Modellierung führt hierbei nachweislich zu einer intuitiven Erkennung von Hierarchien [Mood+10].

MODELLIERUNGSRICHTLINIE Leistungselemente können mithilfe des Detailflusses weiter aufgeteilt sowie mit Anforderungen versehen werden. Aktivitäten und Ressourcen können entweder von einem Akteur besessen werden, oder durch einen anderen Akteur durchgeführt bzw. zur Verfügung gestellt werden.

Leistungsflüsse

DEFINITION "LEISTUNGSFLUSS" Ein Leistungsfluss beschreibt die Erbringung einer Leistung durch einen Leistungserbringer gegenüber einem Leistungsempfänger. Ist kein Leistungserbringer vorhanden, so hat der Leistungsempfänger ein offenes Bedürfnis. Der Leistungsempfänger ist aufgrund des Bezugs von Leistung abhängig vom Leistungserbringer. Die Leistung kann hierbei durch ein oder mehrere Leistungselemente beschrieben sein. Die Menge dieser Elemente, unter Berücksichtigung der Reihenfolge, wird als eine Wertschöpfungskette bezeichnet. (vgl. Dependency Link in [YuMy93], vgl. "Value Transfer" in [GoAk03])

222

Um die BMN-Flüsse einfach, jedoch nach dem Prinzip der Wahrnehmbaren Unterscheidbarkeit zu gestalten unterscheiden sich diese in zwei visuellen Variablen. Um den Flusscharakter zu unterstreichen werden beide Konstrukte als Pfeile dargestellt. Die Unterscheidung zwischen den zwei wird zum einen durch die Farbgebung, zum anderen durch die Ausrichtung gemacht. Abb. 105 zeigt beide Flüsse und ihre Ausrichtungen.

Abb. 105: BMN Flüsse

Fallbeispiele Abb. 106 zeigt das Geschäftsmodell des Voice-Over-IP-Dienstes Skype. Skype bietet eine kostenlose Kommunikation zwischen zwei oder mehreren Skype-Clients sowie das kostenpflichtige "Skypeout", d.h. eine Skype-zu-Telefon-Verbindung", an. Hierbei nutzt ein Großteil der Kunden die kostenlose Variante und nur ein kleiner Teil die kostenpflichtige. Dieses Modell wird auch als Freemium bezeichnet. Vertrieben wird Skype hauptsächlich über skype. com. Wichtiger Teil des Business Models ist der Bezug von Infrastruktur über Partner. Auf diese Weise kann sich Skype auf sein Kerngebiet, die Entwicklung und Vermarktung der Skype Software, konzentrieren. Dieses Business Model stellt den Stand vor der Übernahme durch Microsoft dar.

Abb. 106: skype Business Model modelliert mit runpat

223

Abb. 107 zeigt das Business Model der Geschäftseinheit Nespresso der Nestlé Gruppe. Unter anderem werden Nespresso Kaffeemaschinen (für den Gebrauch von Kapseln) über den Einzelhandel an Haushalte und Gewerbekunden verkauft. Die dazugehörigen Nespresso-Kapseln werden jedoch nur über eigene Kanäle verkauft. Die Kunden werden durch die Inkompatibilität anderer Kapseln oder Maschinen langfristig an Nespresso gebunden und so werden langfristige Umsätze erzeugt. Ein solches Modell wird auch als Bait-And-Hook bezeichnet.

Abb. 107: Nespresso Business Model mit runpat modelliert

Abb. 108: my Boo - Business Model modelliert mit runpat

224

Abb. 108 zeigt das Business Model des Bambus-Fahrradherstellers my Boo10. my Boo setzt bei der Produktion seiner Fahrräder auf nationale sowie internationale Partner (insbesondere afrikanische) und einen sozialen Hintergrund. Das Unternehmen aggregiert und koordiniert hierbei die Leistungen der Partner, um seine Fahrräder national und international anzubieten. Kernzielgruppe sind junge und alte Fahrradfahrer mit sozialem und ökologischem Bewusstsein. Wettbewerb existiert durch die klassische Fahrradbranche aber auch durch die ersten Player im neuen Markt der Bambusfahrräder.

Zum Abschluss wird das Business Model von Expand Stretch Covers (ESC)11 vorgestellt. Das Produktportpolio umfasst hierbei verschiedene Lösungen für die Verkleidung und Dekoration von Lautsprechern und Lichtanlagen auf Veranstaltungen sowie rein dekorative Stoffobjekte. Vertrieben werden die ESCs sowohl an die direkten Anwender, sowie an Zwischenhändler. Die Produktion ist zweigeteilt. Während ein Teil der Ware intern mit eigenen Maschinen produziert wird, übernimmt ein Dienstleister auf Auftragsbasis den größeren Anteil.

Abb. 109: Business Model von Expand Stretch Covers modelliert mit runpat

10 http://www.my-boo.de 11 http://expand-cover.de

225

Fazit zur BMN Die BMN wurde bereits vielfach im Rahmen von Workshops und Lehrveranstaltungen zur Abbildung von Business Model angewendet. Die folgenden Punkte wurden von Teilnehmern hierbei als positiv wahrgenommen: • • • •

Intuitive Verständlichkeit Symbole (nach erster Erklärung) Detailliertere Gestaltungsmöglichkeiten als der Business Model Canvas Einfache Erstellung der Modelle durch interaktiven Editor12 Konkretes Ergebnis am Ende des Workshop (in Form eines strukturierten Modells)

Verbesserung wurde bei den folgenden Punkten gefordert: • Möglichkeit zur Vorbereitung durch Online Materialien und Nachschlagewerke • Umfassende Auswahl an Beispiele und Referenzmodellen für verschiedene Arten von Business Models • Ein Best-Practice-Guide für die Erstellung von Modellen

Zusammenfassung und Ausblick Mit der BMO, e³Value und REA wurden drei umfassende Business Model Ontologien sowie die Abbildung von Early Requirements durch i* vorgestellt. Die jede der Ontologien zeigte hierbei verschiedene Vor- und Nachteile bei der Abbildung von Business Models. Eine Vereinigung zu einer ganzheitlichen Ontologie wurde durch die BMN aufgezeigt, jedoch war dies im hier dargestellten Rahmen nur durch Vereinfachung möglich, ohne die einfache Anwendbarkeit zu reduzieren. Die Erfassung von Requirements, beginnend im Early Stage, bietet das Potential die Later Requirements strukturierter vorzubereiten sowie die Anforderungshintergründe, das Requirements Rationale, zu erfassen. Gerade in der durch den informalen Business Plan dominierten Wirtschaft bietet die BMN die Chance, bei der Entwicklung und Validierung von Geschäftskonzepten formaler vorzugehen, ohne größere Einarbeitungsaufwände für die beteiligten Modellierer zu verursachen. Eine Abbildung aller e³Value sowie REA Modelle in die BMN ist in der aktuellen Fassung aufgrund von Vereinfachungen nicht gegeben. Ob eine solche Abbildbarkeit einen Mehrwert für Forschung und Wirtschaft darstellt muss zunächst genauer untersucht werden, wäre durch einige Erweiterung jedoch in die BMN integrierbar. Aufgrund der agilen Natur der Anforderungen im Entrepreneurial Business Modeling, scheint die vollständige Abbildung der beiden Ontologien jedoch zu detailliert. Die Abbildbarkeit von BMO in Form des BMC ist möglich. Die Unterstützung einer grafischen Darstellung der gesamten BMO ist ebenfalls ein interessanter Aspekt für zukünftige Arbeiten. Die Aufnahme einer breiten Menge von Geschäftsmodellen in BMN würde weiterhin die Untersuchung stereotypischer Business Model Muster ermöglichen.

12

htttp://www.runpat.com

227

Literaturverzeichnis [AfTu03] [AkGo03] [Alby07] [Alen+00]

[AlZi01] [AmZo01] [Ande+06] [Ande+09]

[Ande10]

[Andr04]

[Antó+09]

[Appl+03] [Bain56] [Baum+05] [Baum08]

[Beck+03]

[Beck+95]

Afuah, A.; Tucci, C. L.: Internet business models and strategies. Text and cases. McGraw-Hill Higher Education, Boston, 2003 Akkermans, J.; Gordijn, J.: Value-based requirements engineering: exploring innovative e-commerce ideas. In Requirements Engineering, 2003, 8; S. 114–134 Alby, T.: Web 2.0. Konzepte, Anwendungen, Technologien. Hanser, München, 2007 Alencar, F. et al.: From Early Requirements Modeled by the i* Technique to Later Requirements Modeled in Precise UML. In Anais do WER00 - Workshop em Engenharia de Requisitos, Rio de Janeiro-RJ, Brasil, Julho 13-14, 2000, 2000; S. 92–108 Alt, R.; Zimmermann, H.-D.: Preface: Introduction to Special Section - Business Models. In Electronic Markets, 2001, 11; S. 3–9 Amit, R.; Zott, C.: Value creation in E-business. In Strategic Management Journal, 2001, 22; S. 493–520 Andersson, B. et al.: Towards a reference ontology for business models. In Conceptual Modeling-ER 2006, 2006 Andersson, B.; Johannesson, P.; Zdravkovic, J.: Aligning goals and services through goal and business modelling. In Information Systems and E-Business Management, 2009; S. 143–169 Anders, E.: Modellierung und Validierung von Prozessmodellen auf Basis variabler Modellierungsnotationen und Validierungsmethoden als Erweiterung für Eclipse. Diplomarbeit, Kiel, 2010 Andreopoulos, W.: Achieving Software Quality Using the NFR Framework: Maintainability and Performance. In Proceedings of the 3rd International Conference on Computer Science, Software Engineering, Information Technology, e-Business, and Applications (CSITeA'04), 2004 António, S.; Araújo, J.; Silva, C.: Adapting the i* Framework for Software Product Lines. In Proceedings of the ER 2009 Workshops (CoMoL, ETheCoM, FP-UML, MOST-ONISW, QoIS, RIGiM, SeCoGIS) on Advances in Conceptual Modeling Challenging Perspectives, 2009; S. 286–295 Applegate, L. M.; Austin, R. D.; McFarlan, F. W.: Corporate information strategy and management. Text and cases. McGraw-Hill, Boston, Mass, 2003 Bain, J. S.: Barriers to new competition. Their character and consequences in manufacturing industries. Harvard Univ. Press, Cambridge Mass, 1956 Baumöl, U.; Österle, H.; Winter, R.: Business Engineering in der Praxis. http://www. springerlink.com/index/pt68583858693w16.pdf, 17.01.2011 Baumöl, U.: Change Management in Organisationen. Situative Methodenkonstruktion für flexible Veränderungsprozesse. Univ., Habil.--Zugl.: St. Gallen, 2005. Gabler Verlag / GWV Fachverlage GmbH Wiesbaden, Wiesbaden, 2008 Becker, J. et al.: Forschungsmethodische Positionierung in der Wirtschaftsinformatik-epistemologische, ontologische und linguistische Leitfragen, Münster, 2003 Becker, J.; Rosemann, M.; Schütte, R.: Grundsätze ordnungsgemäßer Modellierung. In Wirtschaftsinformatik, 1995, 5; S. 435–445

A. Rusnjak, Entrepreneurial Business Modeling, DOI 10.1007/978-3-658-03767-3, © Springer Fachmedien Wiesbaden 2014

228

[Bisc07] [Bitk09a] [Bitk09b] [Bitk09c] [Bitk09d] [Bitk10] [Bitk11] [Blei+03] [Blei04] [BoBa01] [Böin01] [Brau07] [BrSt07] [Bryl+07]

[BrZa09]

[Bund09] [Buch09] [BuTi08] [Buxt+78]

[CaDe07] [CaRi11] [Cast+01]

Bischoff, W.: Zielorientierte Ansätze des Requirements Engineering, Stuttgart, 2007 Bitkom: Mehr als 100 Millionen Mobilfunkanschlüsse in Deutschland. http://www. bitkom.org/de/presse/56204_51915.aspx, 10.11.2009 Bitkom: Online-Shopping in Deutschland weit verbreitet. http://www.bitkom.org/ de/presse/30739_59337.aspx, 10.11.2009 Bitkom: Jedes zweite Kind hat ein Handy. http://www.bitkom.org/de/markt_statistik/64046_61083.aspx, 04.02.2011 Bitkom: More than four billion mobile phone users worldwide. http://www.eito. com/pressinformation_20090807.htm, 22.09.2009 Bitkom: Bald mehr als fünf Milliarden Mobilfunkanschlüsse. http://www.bitkom. org/de/markt_statistik/64046_64681.aspx, 04.02.2011 Bitkom: E-Commerce – Konsumenten. http://www.bitkom.org/de/markt_statistik/64038_38540.aspx, 04.02.2011 Bleistein, S. J. et al.: Linking Requirements Goal Modeling Techniques to Strategic e-Business Patterns and Best Practice. In AWRE, 2003, 3 Bleicher, K.: Das Konzept integriertes Management. Visionen - Missionen Programme. Campus-Verl, Frankfurt/Main, 2004 Boehm, B.; Basili, V. R.: Software Defect Reduction List. In Computer, 2001, 34; S. 135–137 Böing, C.: Erfolgsfaktoren im Business-to-Consumer-E-Commerce. Gabler, Wiesbaden, 2001 Braun, C.: Modellierung der Unternehmensarchitektur. Dissertation, St. Gallen, 2007 Bruhn, M.; Stauss, B.: Wertschöpfungsprozesse bei Dienstleistungen. http://dx.doi. org/10.1007/978-3-8349-9285-7 Bryl, V. et al.: B-Tropos. Agent-oriented requirements engineering meets computational logic for declarative business process modeling and verification. In 8th Workshop on Computational Logic in Multi-Agent Systems, 2007 Bridgeland, D. M.; Zahavi, R.: Business modeling. A practical guide to realizing business value. Morgan Kaufmann; Morgan Kaufmann/Elsevier, Amsterdam, 2009 Bundesverband des Deutschen Versandhandels e.V.: Versandhandel gewinnt: Umsatz steigt auf 29,1 Mrd. Euro. http://www.versandhandel.org/, 16.11.2009 Buchholz, O.: Strategieentwicklung und Business Modeling bei der Siemens AG. Persönliches Interview, Duisburg, 2009 Buse, S.; Tiwari, R.: Perspektiven des Mobile Commerce in Deutschland. Grundlagen, Strategien, Kundenakzeptanz, Erfolgsfaktoren. Shaker, Aachen, 2008 Buxton, M.; Naur, P.; Randel, P.: Software Engineering Concepts and Techniques. In Proceedings of the 1968 North Atlantic Treaty Organisation (NATO) Conference on Software Engineering, 1978; S. 88.98 Cawsey, T. F.; Deszca, G.: Toolkit for organizational change. Sage Publ, Los Angeles, 2007 Casadesus-Masanell, R.; Ricart, J. E.: How to Design A Winning Business Model. In Harvard Business Review, 2011; S. 101–107 Castro, J.; Kolp, M.; Mylopoulos, J.: A Requirements-Driven Development Methodology. In Proceedings of the 13th International Conference on Advanced Information Systems Engineering, 2001; S. 108–123

229

[Cast+10]

Castro, J.; Franch, X.; Mylopoulos, J.; Yu, E. Hrsg.: Proceedings of the 4th International i* Workshop, 2010 [Cast96] Castrogiovanni, G. J.: Pre-Startup Planning and the Survival of New Small Businesses: Theoretical Linkages. In Journal of Management, 1996, 22; S. 801-822 [CaWi06] Carlson, C. R.; Wilmot, W. W.: Innovation: The five disciplines for creating what customers want. Crown Business, New York, 2006 [Chan+09] Chang, S.-I. et al.: Critical Success Factors of Mobile Commerce Adoption: A Study Based on the System Life Cycle and Diamond Model. IEEE Computer Society, Dalian, 2009 [Chan62] Chandler, A. D.: Strategy and structure. Chapters in the history of the industrial enterprise. MIT Pr, Cambridge, Mass, 1962 [Chen76] Chen, P. P.-S.: The entity-relationship model—toward a unified view of data. In ACM Transactions on Database Systems (TODS), 1976, 1 [Ches08] Chesbrough, H.: Open business models. How to thrive in the new innovation landscape. Harvard Business School Press, Boston, Mass, 2008 [Ches10] Chesbrough, H.: Business Model Innovation: Opportunities and Barriers. In Long Range Planning, 2010, 43; S. 354-363 [Ches11] Chesbrough, H. W.: Open Services Innovation. Rethinking Your Business to Grow and Compete in a New Era. Jossey-Bass, San Francisco, CA, 2011 [ChLe83] Churchill, N. C.; Lewis, V. L.: The Five Stages of Small Business Growth. In Harvard Business Review, 1983, 61; S. 30–50 [Chun00] Chung, L.: Non-functional requirements in software engineering. Kluwer Acad. Publ, Boston, Mass, 2000 [Colo08] Colom, G. G.: An i*-based reengineering framework for requirements engineering. Dissertation, Barcelona, 2008 [Coop+08] Cooper, S. W.; Grutzner, F. P.; Cooper, B. P.: Tips and traps for marketing your business. McGraw-Hill, New York, 2008 [Curr04] Currie, W. L.: Value creation from e-business models. Elsevier Butterworth-Heinemann, Amsterdam, 2004 [DePo08] Decreus, K.; Poels, G.: Putting Business into Business Process Models. Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International. In Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International DOI - 10.1109/COMPSAC.2008.110, 2008; S. 1005–1010 [DoRo92] Dodge, R. H.; Robins, J. E.: An empirical Investigation of Organizational Life Cycle Model for Small Business Development and Survival. In Journal of Small Business Management, 1992; S. 27–37 [Dubo+02] Dubosson-Torbay, M.; Osterwalder, A.; Pigneur, Y.: eBusiness Model Design, Classification and Measurements. In Thunderbird International Business Review, 2002, 44 [Dunk08] Dunkel, J.: Systemarchitekturen für verteilte Anwendungen. http://books.hanser. de:8080/vkb/default.jsf?doi=9783446413214_ISBN [EgWi02] Egger, A.; Winterheller, M.: Kurzfristige Unternehmensplanung. Budgetierung. Linde, Wien, 2002 [Erca10] Ercan, T.: Ziel- und intentionsorientierte Modellierung von Geschäftsmodellen zur Identifikation von kritischen Erfolgsfaktoren auf Basis des i* Frameworks. Bachelorarbeit, Kiel, 2010

230

[Estr+06]

[Eyri+11] [Falt10] [FeCo03] [Feja+10]

[FeLo05] [Feng+06] [FeSi01] [Fran02] [Fran94]

[Frit92]

[FrSc03] [Fugl10] [Fuxm+04] [Fuxm01] [Gade99]

[Gail+08]

[Gamm09] [GeMc99] [GhVe05]

Estrada, H. et al.: An Empirical Evaluation of the i* Framework in a Model-Based Software Generation Environment. In Advanced Information Systems Engineering, 2006; S. 513–527 Eyring, M. J.; Johnson, M. W.; Nair, H.: New Business Models In Emerging Markets. In Harvard Business Review, 2011; S. 89–95 Faltin, G.: Kopf schlägt Kapital. Die ganz andere Art, ein Unternehmen zu gründen ; von der Lust, ein Entrepreneur zu sein. Hanser, München, 2010 Feather, M. S.; Cornford, S. L.: Quantitative risk-based requirements reasoning. In Requirements Engineering, 2003, 8; S. 248–265 Feja, S. et al.: Checkable Graphical Busines Process Representation. In Proceedings of the 14th East European Conference Advances in Databases and Information Systems (ADBIS), 2010; S. 176–189 Fettke, P.; Loos, P.: Der Beitrag der Referenzmodellierung zum Business Engineering. Universität Mainz, Mainz, 2005 Feng, H.; Hoegler, T.; Stucky, W.: Exploring the Critical Success Factors for Mobile Commerce. IEEE Computer Society, 2006 Ferstl, O. K.; Sinz, E. J.: Grundlagen der Wirtschaftsinformatik. Oldenbourg, München, 2001 Franke, T. S.: Strategische Analyse der E-Commerce-Situation von Unternehmen. Systematik und Verfahren. Univ., Diss.--Mainz, 2002. Kovac, Hamburg, 2002 Frank, U.: Multiperspektivische Unternehmensmodellierung. Theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung. Univ., Habil.-Schr.--Marburg, 1993. Oldenbourg, München, Wien, 1994 Fritz, W.: Marktorientierte Unternehmensführung und Unternehmenserfolg. Grundlagen und Ergebnisse einer empirischen Untersuchung. Schäffer-Poeschel, Stuttgart, 1992 Friedag, H. R.; Schmidt, W.: Balanced scorecard at work. Strategisch - taktisch operativ. Haufe, Freiburg, 2003 Fugléwicz-Bren, M.: ZukunftsWebBuch 2010. Chancen und Risiken des Web 3.0. ed. mono/monochrom, Wien, 2010 Fuxman, A. et al.: Specifying and analyzing early requirements in Tropos. In Requirements Engineering, 2004, 9; S. 132–150 Fuxman, A. D.: Formal Analysis of Early Requirements Specifications, 2001 Gadenne, V.: Der kritische Rationalismus und die Rolle von Theorien in der Wirtschaftsinformatik;In (Institut für Produktion und industrielles Management Hrsg.), Essen; S. 5–21 Gailly, F. et al.: Integrating Business Domain Ontologies with Early Requirements Modelling. In Advances in Conceptual Modeling – Challenges and Opportunities, 2008; S. 282–291 Gamma, E.: Design patterns. Elements of reusable object-oriented software. Addison-Wesley, Boston, 2009 Geerts, G. L.; McCarthy, W. E.: An Accounting Object Infrastructure for Knowledge-Based Enterprise Models. In IEEE Intelligent Systems, 1999, 14 Ghaziani, A.; Ventresca, M. J.: Keywords and Cultural Change: Frame Analysis of Business Model Public Talk, 1975–2000. In Sociological Forum, 2005, 20; S. 523–559

231

[GoAk03]

[Gord+00]

[Gree+94]

[Grei72] [GrGr03] [Haak+04]

[Hame02] [Hame10] [Hans96] [HaPr00] [HaPr97]

[Harv10] [HaSi99] [HeCh10] [Helm06] [Heng10]

[Henz88] [Hirs98] [HöGr02] [Holz01] [Hood+08]

Gordijn, J.; Akkermans, H.: Does e-Business Modeling Really Help? In Proceedings of the 36th Hawaii International Conference on System Sciences, 2003; S. 1–10 Gordijn, J.; Akkermans, H.; van Vliet, H.: Business Modelling Is Not Process Modelling. In Proceedings of the Workshops on Conceptual Modeling Approaches for E-Business and The World Wide Web and Conceptual Modeling: Conceptual Modeling for E-Business and the Web, 2000; S. 40-51 Greenspan, S.; Mylopoulos, J.; Borgida, A.: On formal requirements modeling languages: RML revisited. In In Proc. 16th International Conference on Software Engineering, 1994; S. 135-148 Greiner, L. E.: Evolution and revolution as organizations grow. In Harvard Business Review, 1972, 50; S. 37–46 Graf, N.; Gründer, T.: eBusiness. Grundlagen für den globalen Wettbewerb. Dt. Taschenbuch-Verl., München, 2003 Haaker, T.; Faber, E.; Bouwman, H.: Balancing strategic interests and technological requirements for mobile services. In Proceedings of the 6th international conference on Electronic commerce, 2004; S. 235–248 Hamel, G.: Leading the revolution. How to thrive in turbulent times by making innovation a way of life. Plume, New York NY u.a, 2002 Hamel, G.: Who's Really Innovative. http://blogs.wsj.com/management/2010/11/22/whos-really-innovative/, 19.12.2010 Hansen, H. R.: Klare Sicht am Info-Highway. Geschäfte via Internet & Co. Orac, Wien, 1996 Hamel, G.; Prahalad, C. K.: Competing for the future. Harvard Business School Press, Boston, Mass, 2000 Hamel, G.; Prahalad, C. K.: Wettlauf um die Zukunft. Wie Sie mit bahnbrechenden Strategien die Kontrolle über Ihre Branche gewinnen und die Märkte von morgen schaffen. Ueberreuter, Wien, 1997 Harvard Business School Publishing Corporation: Harvard business review on business model innovation. Harvard Business Press, Boston, Mass, 2010 Hagel, J.; Singer, M.: Unbundling the Corporation. In Harvard Business Review, 1999 Hevner, A.; Chatterjee, S.: Design Research in Information Systems. Theory and Practice. Springer Science+Business Media LLC, Boston, MA, 2010 Helms, M. M.: Encyclopedia of management. Thomson Gale, Detroit, 2006 Hengartner, U.: Web 3.0 & Semantic Web. Semantische Suche, Social Tagging, Text-Mining-Methoden, Social-Bookmarking-System, semantische Mashups, WikiTagging, Informationssuche in Weblogs. dpunkt-Verl, Heidelberg, 2010 Henzler, H. A.: Handbuch strategische Führung. Gabler, Wiesbaden, 1988 Hirschmann, P.: Kooperative Gestaltung unternehmensübergreifender Geschäftsprozesse. Dissertation. Gabler, Wiesbaden, Saarbrücken, 1998 Hölzle, P.; Grünig, C.: Projektmanagement. Professionell führen - Erfolge präsentieren ; [mit Kienbaum-Tools auf CD]. Haufe, Freiburg (Breisgau), 2002 Holzbaur, U. D.: Management. Kiehl, Ludwigshafen (Rhein), 2001 Hood, C. et al.: Requirements Management. The Interface Between Requirements Development and All Other Systems Engineering Processes. Springer-Verlag Berlin Heidelberg, Berlin, Heidelberg, 2008

232

[HoTu10]

Hornby, A. S.; Turnbull, J.: Oxford Advanced Learner's Dictionary - 8th Edition // Oxford advanced learner's dictionary of current English ; [improve your writing with Oxford writing tutor]. Kartoniert. Cornelsen Verlag; Oxford Univ. Press [u.a.], Oxford, 2010 [Hrub+06] Pavel. Hruby; Kiehn, J.; Scheller, C. V.: Model-driven design using business patterns. Springer, 2006 [HuCh96] Hughes, G. D.; Chafin, D. C.: Turning New Product Development into a Continuous Learning Process. In Journal of Product Innovation Management, 1996, 13; S. 89-104 [IBM 06] IBM Corporation: Expanding the Innovation Horizon: The Global CEO Study 2006. http://www-07.ibm.com/smb/includes/content/industries/electronics/pdf/ Global_CEO_Study_-_Electronics.pdf, 13.12.2010 [ISO07] International Organization for Standardization: Information technology - Business Operational View - Part 4: Business transaction scenarios - Accounting and economic ontology. ISO, Geneva, Switzerland, 2007 [ITU 08] ITU: User requirements notation (URN) – Language definition. ITU, Genf, 2008. http://www.itu.int/rec/T-REC-Z.151-200811-I/en [John+08] Johnson, M. W.; Christensen, C. M.; Kagermann, H.: Reinventing Your Business Model. In Harvard Business Review, 2008; S. 50–59 [John10] Johnson, M. W.: Seizing the white space. Business model innovation for growth and renewal. Harvard Business Press, Boston, Mass, 2010 [Kage+11] Kagermann, H.; Osterle, H.; Jordan, J. M.: IT-driven business models. Global case studies in transformation. Wiley, Hoboken, NJ, 2011 [KaNo04] Kaplan, R. S.; Norton, D. P.: Strategy maps. Converting intangible assets into tangible outcomes. Harvard Business School Press, Boston, Mass, 2004 [KaÖs07] Kagermann, H.; Österle, H.: Geschäftsmodelle 2010. Wie CEOs Unternehmen transformieren. FAZ-Inst. für Management- Markt- und Medieninformationen, Frankfurt am Main, 2007 [Karl96] Karlsson, J.: Software requirements prioritizing. In Proceedings of the Second International Conference on Requirements Engineering, 1996; S. 110–116 [KeMa03] Kerzner, H.; Majetschak, B.: Projekt-Management. Ein systemorientierter Ansatz zur Planung und Steuerung. mitp-Verl, Bonn, 2003 [Kert+07] Kerth, K.; Asum, H.; Nührich, K.: Die besten Strategietools in der Praxis. Welche Werkzeuge brauche ich wann? - Wie wende ich sie an? - Wo liegen die Grenzen? Hanser, München, 2007 [Khur+09] Khurum, M. et al.: A Controlled Experiment of a Method for Early Requirements Triage Utilizing Product Strategies. In Proceedings of the 15th International 2009, 2009; S. 22–36 [Kill08] Killam, D.: Vision, Mission, Goals and Objectives . . . Oh My! http://www.umext. maine.edu/onlinepubs/htmpubs/6107.htm, 24.04.2010 [Kles10] Klesse, H.-J.: Roland Berger vor Neupositionierung. http://www.wiwo.de/unternehmen-maerkte/roland-berger-vor-neupositionierung-435809/, 21.02.2011 [Koll08] Kollmann, T.: E-Entrepreneurship. Grundlagen der Unternehmensgründung in der Net Economy. Betriebswirtschaftlicher Verlag Gabler, 2008 [Koll09] Kollmann, T.: E-Business. Grundlagen elektronischer Geschäftsprozesse in der Net Economy. Gabler, Wiesbaden, 2009

233

[Köni+96]

[Köpp03] [Kowa04] [Kran07]

[Krei87]

[KrLu08] [Kroi03]

[Kurp09]

[Kust+08] [LaCa07]

[Lam+07]

[Lams00] [Lank05] [Lapo04]

[Lapo05] [LaSi87] [Laud+10] [LeDa01] [Lenn01]

König, W. et al.: Zur Entwicklung der Forschungsmethoden und Theoriekerne der Wirtschaftsinformatik in den nächsten zehn Jahren – Eine kombinierte Delphiund AHP-Untersuchung;In (Heilmann, H. Hrsg.). Oldenbourg, München, 1996; S. 36–65 Köppen, A.: Metamodell zur Analyse und Gestaltung von Geschäftsmodellen im Electronic Business Kontext. Dissertation, Saarland, 2003 Kowallik, T.: Erfolgschancen der Geschäftsmodelle von Start-ups im E-Commerce. Analyse von Erfolgsfaktoren. Lang, Frankfurt am Main, 2004 Kranz, M.: Management von Strategieprozessen. Von der Strategischen Planung zur integrierten Strategieentwicklung. Univ., Diss.--Zugl.: Potsdam, 2006. Dt. Univ.Verl., Wiesbaden, 2007 Kreilkamp, E.: Strategisches Management und Marketing. Markt- u. Wettbewerbsanalyse strateg. Frühaufklärung Portfolio-Management. de Gruyter, Berlin [u.a.], 1987 Krishna, A.; Lu, H.: Requirements Elicitation Using Goal-Based Organizational Model. In Australian Software Engineering Conference, 2008, 0; S. 543–551 Kroiß, A.: Erfolgsfaktoren von Internet-Start-Ups. Eine empirische Untersuchung originärer deutscher Unternehmensgründungen nach Wachstumsphasen und Internet-Anbietersegmenten. Kovac, Hamburg, 2003 Kurpjuweit, S.: Stakeholder-orientierte Modellierung und Analyse der Unternehmensarchitektur unter besonderer Berücksichtigung der Geschäfts- und IT-Architektur. Dissertation, St. Gallen, 2009 Kuster, J. et al.: Handbuch Projektmanagement. http://dx.doi. org/10.1007/978-3-540-76432-8 Ladeira, S. A. Z.; Cagnin, M. I.: Guidelines for Business Modeling Elaboration based on Views from Domain Information. In Proceedings of Anais do WER07 Workshop em Engenharia de Requisitos, 2007, 7; S. 47–55 Lam, E. W.; Chan, A. P.; Chan, D. W.: Benchmarking the performance of design-build projects: Development of project success index. In Benchmarking: An International Journal, 2007, 14; S. 624-638 Lamsweerde, A.v. Hrsg.: Requirements engineering in the year 00: a research perspective, 2000 Lankhorst, M.: Enterprise Architecture at Work. Modelling, Communication, and Analysis. Springer-Verlag Berlin Heidelberg, Berlin, Heidelberg, 2005 Lapouchnian, A.: Modeling Mental States in Requirements Engineering – An Agent-Oriented Framework Based on i* and CASL. Master-Thesis, Toronto, 2004 Lapouchnian, A.: Goal-Oriented Requirements Engineering: An Overview of the Current Research. Depth Report. University Of Toronto, 2005 Larkin, J. H.; Simon, H. A.: Why a Diagram is (Sometimes) Worth Ten Thousand Words. In Cognitive Science, 1987, 11; S. 65-100 Laudon, K. C.; Laudon, J. P.; Schoder, D.: Wirtschaftsinformatik. Eine Einführung. Pearson Studium, München, 2010 Leibbrand, F.; Danz, B.: Entrepreneurship und Unternehmertum. Denkstrukturen für eine neue Zeit. Gabler, Wiesbaden, 2001 Lennerz, C.: E-Business Modeling: Analyse von Methoden zur Beschreibung unternehmensübergreifender Geschäftsprozesse. Diplomarbeit, Saarbrücken, 2001

234

[Lest+03]

Lester, D. L.; Parnell, J. A.; Carraher, S.: Organizational Life Cycle: A five-stage empirical scale. In International Journal of Organizational Analysis, 2003, 11; S. 339-354 [LeWi02] Leist, S.; Winter, R.: Retail Banking im Informationszeitalter. Integrierte Gestaltung der Geschäfts-, Prozess- und Applikationsebene ; mit 15 Tabellen. Springer, Berlin, 2002 [Link03] Link, J.: Mobile Commerce. Gewinnpotenziale einer stillen Revolution ; mit 13 Tabellen. Springer, Berlin, 2003 [LiPr96] Liles, D. H.; Presley, A. R.: Enterprise modeling within an enterprise engineering framework. In Proceedings of the 28th conference on Winter simulation, 1996; S. 993–999 [Loga07] Logara, T.: Mobile Business im B2C. Komplexität als Ursache von Produktivitätsengpässen in den Distributionskanälen des deutschen B2C-Marktes. Books on Demand, Norderstedt, 2007 [Lohm+04] Lohman, C.; Fortuin, L.; Wouters, M.: Designing a performance measurement system: A case study. In European Journal of Operational Research, 2004, 156; S. 267-286 [LuLi10] Ludewig, J.; Lichter, H.: Software Engineering. Grundlagen, Menschen, Prozesse, Techniken. dpunkt-Verl, Heidelberg, 2010 [Mann90] Mann, R.: Das visionäre Unternehmen. Der Weg zur Vision in zwölf Stufen. Gabler, Wiesbaden, 1990 [Mart+08] Martinez, A. et al.: From Early to Late Requirements: A Goal-Based Approach. In Agent-Oriented Information Systems IV, 2008; S. 123–142 [Mart09] Martin, R. L.: The design of business. Why design thinking is the next competitive advantage. Harvard Business Press, Boston, Mass, 2009 [Maye09] Mayer, R. E.: Multimedia learning. Cambridge University Press, Cambridge, 2009 [McCa82] McCarthy, W. E.: The REA accounting model: A generalized framework for accounting systems in a shared data environment. In Accounting Review, 1982 [MeSc07] Meyer, C.; Schwager, A.: Understand Customer Experience. In Harvard Business Review, 2007; S. 117–126 [MeSt08] Meier, A.; Stormer, H.: eBusiness & eCommerce. Management der digitalen Wertschöpfungskette. Springer-Verlag, Berlin, Heidelberg, 2008 [Mini11] Miniwatts Marketing Group: Internet Usage Statistics. http://www.internetworldstats.com/stats.htm, 22.09.2009 [Mint+98] Mintzberg, H.; Ahlstrand, B. W.; Lampel, J.: Strategy safari. A guided tour through the wilds of strategic management. Free Press, New York, 1998 [Mint03] Mintzberg, H.: The strategy process. Concepts, contexts, cases. Pearson Education, Harlow, 2003 [Misr+08] Misra, S. C.; Kumar, U.; Kumar, V.: Modelling strategic actor relationships for risk management in organizations undergoing business process reengineering due to information systems adoption. In Business Process Management Journal, 2008, 14; S. 65-84 [MoBa04] Montilva, J. C.; Barrios, J. A.: BMM: A Business Modeling Method for Information Systems Development. In CLEI ELECTRONIC JOURNAL, 2004, 7 [Mood09] Moody, D. L.: The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. In Software Engineering, IEEE Transactions on, 2009, 35; S. 756-779

235

[Mood+09] Moody, D. L.; Heymans, P.; Matulevicius, R.: Improving the effectiveness of visual representations in requirements engineering: An evaluation of i* visual syntax. In Requirements Engineering Conference, 2009. RE’09. 17th IEEE International [Mood+10] Moody, D. L.; Heymans, P.; Matulevičius, R.: Visual syntax does matter: improving the cognitive effectiveness of the i* visual notation. In Requirements Engineering, 2010, 15 [Morr+05] Morris, M.; Schindehutte, M.; Allen, J.: The entrepreneur‘s business model: toward a unified perspective. In Journal of Business Research, 2005, 58; S. 726-735 [MuKo10] Mullins, J. W.; Komisar, R.: Getting to plan B. Breaking through to a better business model. Harvard Business Press, Boston, Mass, 2010 [Müll99] Müller, R.: Erfolgsfaktoren schnell wachsender Software-Startups. Eine lebenszyklusorientierte Untersuchung von Softwareunternehmen des Produktgeschäfts. Lang, Frankfurt am Main, Berlin, Bern, Wien, 1999 [Muni+04] Munive-Hernandez, E. J. et al.: Modelling the strategy management process: An initial BPM approach. In Business Process Management Journal, 2004, 10; S. 691–711 [Mylo+00] Mylopoulos, J.; Castro, J.; Kolp, M.: Tropos: A Framework for Requirements-Driven Software Development. In INFORMATION SYSTEMS ENGINEERING: STATE OF THE ART AND RESEARCH THEMES, 2000; S. 261–273 [Mylo+92] Mylopoulos, J.; Chung, L.; Nixon, B.: Representing and using nonfunctional requirements: a process-oriented approach. In Software Engineering, IEEE Transactions on, 1992, 18; S. 483-497 [Mylo+99] Mylopoulos, J.; Chung, L.; Yu, E.: From object-oriented to goal-oriented requirements analysis. In Communications of the ACM, 1999, 42; S. 31–37 [Mylo97] Mylopoulos, J.: Information modeling in the time of the revolution. In Information Systems, 1997, 23; S. 127-155 [Nage93] Nagel, K.: Die 6 Erfolgsfaktoren des Unternehmens. Strategie, Organisation, Mitarbeiter, Führungssystem, Informationssystem, Kundennähe. Verl. Moderne Industrie, Landsberg/Lech, 1993 [Nagl06] Nagl, A.: Der Businessplan. Geschäftspläne professionell erstellen Mit Checklisten und Fallbeispielen. Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH Wiesbaden, Wiesbaden, 2006 [Nico01] Nicolai, A.T. Hrsg.: Strategien im M-Commerce. Grundlagen, Management, Geschäftsmodelle. Schäffer-Poeschel, Stuttgart, 2001 [ÖsBl05] Österle, H.; Blessing, D.: Ansätze des Business Engineering. In HMD - Praxis der Wirtschaftsinformatik, 2005, 42; S. 7–17 [OsPi02] Osterwalder, A.; Pigneur, Y.: An e-Business Model Ontology for Modeling e-Business. In Proceediings of the 15th Bled Electronic Commerce Conference, 2002 [OsPi09] Osterwalder, A.; Pigneur, Y.: Business model generation. A handbook for visionaries, game changers, and challengers. Modderman Drukwerk, Amsterdam, 2009 [OsPi11] Osterwalder, A.; Pigneur, Y.: Business Model Generation: ein Handbuch für Visionäre, Spielveränderer und Herausforderer. Campus, 2011 [Oste+05] Osterwalder, A.; Pigneur, Y.; Tucci, C. L.: Clarifying Business Models: Origins, Present and Future of the Concept. In Communications of the Association for Information Systems, 2005, 16 [Oste02] Osterwalder, A.: An e-Business Model Ontology for the Creation of New Management Software Tools and IS Requirement Engineering. In Proc. of the CAiSE'2002 Doctoral Consortium, 2002

236

[Oste04] [Oste13] [Öste10a]

[Öste10b]

[Öste95] [ÖsWi03] [Paul+93] [PeWa91]

[Pill08] [Pohl08] [Pohl09] [Pohl11] [Port01] [Port02] [Port96] [Pott99]

[QuCa83]

[Rach01] [Raps04] [Ring04]

Osterwalder, A.: The Business Model Ontology. A Proposition In A Design Science Approach. Dissertation. Universite de Lausanne, Lausanne, 2004 Osterwalder, A.: Sketch Out Your Hypothesis. http://hbr.org/web/2013/05/whythe-lean-start-up-changes-everything/sketch-out-your-hypothesis, 15.11.13 Österle, H.: St. Galler Ansatz des Business Engineering. http://www.oldenbourg. de:8080/wi-enzyklopaedie/lexikon/daten-wissen/Informationsmanagement/ Business-Engineering/-Business-Engineering--Ansatze-des/St--Galler-Ansatz-des-Business-Engineering, 13.12.2010 Österle, H.: Business Engineering. http://www.oldenbourg.de:8080/wi-enzyklopaedie/lexikon/daten-wissen/Informationsmanagement/Business-Engineering, 12.12.2010 Österle, H.: Entwurfstechniken. Springer, Berlin, 1995 Österle, H.; Winter, R.: Business Engineering. Auf dem Weg zum Unternehmen des Informationszeitalters. Springer, Berlin, 2003 Paulk, M. et al.: Capability maturity model, version 1.1. In Software, IEEE, 1993, 10; S. 18–27 Peters, T. J.; Waterman, R. H.: Auf der Suche nach Spitzenleistungen: Was man von den bestgeführten US-Unternehmen lernen kann. Moderne Industrie AG, Landsberg/Lech, 1991 Pillkahn, U.: Using trends and scenarios as tools for strategy development. Shaping the future of your enterprise. Publicis Corp. Publ, Erlangen, 2008 Pohl, K.: Requirements engineering. Grundlagen, Prinzipien, Techniken. dpunktVerl, Heidelberg, 2008 Pohle, M.: Problemstellungen der Produktentwicklung im Konzernumfeld der Swisscom. Persönliches Interview, Zürich, 2009 Pohle, M.: Die Rolle der Speed Creation und ihr Ablauf im PEP der Swisscom (CBU). Persönliches Interview, Zürich, 2011 Porter, M. E.: Strategy and the Internet. In Harvard Business Review, 2001; S. 63–78 Porter, M.: Strategy and the Internet. Harvard business review on advances in strategy. Harvard Business School Press, Boston, Mass, 2002 Porter, M. E.: What Is Strategy? In Harvard Business Review, 1996, 74; S. 61-78 Potts, C.: ScenIC: a strategy for inquiry-driven requirements determination. In Proceedings of the IEEE International Symposium on Requirements Engineering, 1999 Quinn, R. E.; Cameron, K.: Organisational Life Cycles and Shifting Criteria of Effectiveness: Some Preliminary Evidence. In Management Science, 1983, 29; S. 33–51 Rachlin, R.: Praxishandbuch Budgetplanung. Grundlagen und Instrumente für erfolgreiches Finanzmanagement. Campus-Verl, Frankfurt/Main, 2001 Raps, Andreas: Erfolgsfaktoren der Strategieimplementierung; Wiesbaden: Gabler, 2004 Ringle, C. M.: Kooperation in Virtuellen Unternehmungen. Auswirkungen auf die strategischen Erfolgsfaktoren der Partnerunternehmen. Univ., Diss. u.d.T.: Ringle, Christian Marc: Virtuelle Unternehmung und erfolgsfaktorenzentriertes strategisches Management der Partnerunternehmen--Hamburg, 2004. Dt. Univ.-Verl., Wiesbaden, 2004

237

[Robb08]

Robbins, S. P.: Organisation der Unternehmung. Pearson Studium, München, 2008 [Rock10] Rock, D.: Your brain at work. Strategies for overcoming distraction, regaining focus, and working smarter all day long. Harper Business, New York NY, 2010 [RoSc77] Ross, D. T.; Schoman, K. E., JR.: Structured Analysis for Requirements Definition. Software Engineering, IEEE Transactions on. In Software Engineering, IEEE Transactions on DOI -, 1977, SE-3; S. 6–15 [RuEl09] Rusnjak, A.; El Kharbili, M.: On Leveraging Business Processes to deal with Critical Success Factors. GI, Bonn, 2009 [Rusn13] Rusnjak, A.: Entrepreneurial Business Modeling im Kontext einer erfolgsfaktorenorientierten Strategie-Entwicklung. http://nbn-resolving.de/urn:nbn:de:bsz:15-qucosa-118684, 07.11.2013 [Rume03] Rumelt, R. P.: What in the World is Competitive Advantage? http://www.anderson. ucla.edu/x8016.xml, 17.01.2011 [Rupp09] Rupp, C.: Requirements-Engineering und -Management. Professionelle, iterative Anforderungsanalyse für die Praxis. Hanser, München, 2009 [SaAr96] Sambamurthy, V.; Armstron, C.: Creating Business Value Through Information Technology: The Effects of Chief Information Officer and Top Management Team Characteristics. In ICIS 1996 Proceedings, 1996; S. 195–208 [Sahl97] Sahlman, W. A.: How to Write a Great Business Plan. In Harvard Business Review, 1997; S. 114–121 [Sama+08] Samavi, R.; Yu, E.; Topaloglou, T.: Strategic reasoning about business models. A conceptual modeling approach. Springer-Verlag, 2008 [Scha12] Schallmo, D.: Geschäftsmodellinnovation. Grundlagen, bestehende Ansätze, methodisches Vorgehen und B2B-Geschäftsmodelle. Springer Gabler, Wiesbaden, 2012 [ScHa99] Scheer, A.-W.; Habermann, F.: Electronic Business: vom Why now? zum Let's go! In IM Informationsmanagement & Consulting, 1999, 14; S. 7–14 [Sche+03] Scheer, C.; Deelmann, T.; Loos, P.: Geschäftsmodelle und internetbasierte Geschäftsmodelle. Begriffsbestimmung und Teilnehmermodell. Johannes Gutenberg-University Mainz, Mainz, 2003 [Sche02] Scheer, A.-W.: ARIS - vom Geschäftsprozess zum Anwendungssystem. Springer, Berlin, 2002 [Sche03] Scheer, A.-W.: Business process change management. ARIS in practice ; with 11 tables. Springer, Berlin, 2003 [Sche96] Scheer, A. W.: ARIS-House of Business Engineering: Von der Geschäftsprozeßmodellierung zur Workflow-gesteuerten Anwendung; vom Business Process Reengineering zum Continuous Process Improvement. In Institut für Wirtschaftsinformatik (IWi), Universität des Saarlandes, 1996 [Sche97] Scheer, A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. Springer, Berlin, 1997 [Sche99] Scheer, A.-W.: Electronic Business Engineering. Physica-Verl., Heidelberg, 1999 [Scho00] Scholze-Stubenrecht, W.: Duden Die deutsche Rechtschreibung. Dudenverlag, Mannheim, 2000 [Schö09] Schönbeck, R.: Geschäftsklima im E-Commerce 2009/2010. http://www. ecc-handel.de/download/83045001/Expertenstudie-Gesch%C3%A4ftsklima+im+E-Commerce.pdf, 04.02.2011

238

[ScKn04]

Schwiderski-Grosche, S.; Knospe, H.: Secure M-Commerce. IEEE Press, London, 2004 [ScLo02] Scheer, C.; Loos, P.: Concepts of customer orientation - Internet business model for customer-driven output. In Proceedings of the 10th European Conference on Information Systems (ECIS), 2002, 10; S. 573–581 [ScMo09] Schuster, R.; Motal, T.: From e3-value to REA: Modeling Multi-party E-business Collaborations. In Proceedings of the 11th IEEE Conference on Commerce and Enterprise, 2009 [ScSe05] Schumpeter, J. A.; Seifert, E. K.: Kapitalismus, Sozialismus und Demokratie. Francke, Tübingen, 2005 [SeLe03] Seddon, P.; Lewis, G.: Strategy and Business Models: What's the Difference? In PACIS 2003 Proceedings, 2003; S. 235–248 [Semm+09] Semmak, F.; Gnaho, C.; Laleau, R.: Extended Kaos to Support Variability for Goal Oriented Requirements Reuse. In Proceedings of the International Workshop on Model Driven Information Systems Engineering: Enterprise, User and System Models (MoDISE-EUS'08), 2009 [SiGa02] Simon, H.; Gathen, A. von der: Das große Handbuch der Strategieinstrumente. Werkzeuge für eine erfolgreiche Unternehmensführung ; [Benchmarking, Kompetenz-Mapping, Portfolio-Analyse, Marktsegmentierung, Szenario-Analyse, Balanced Scorecard und andere]. Campus-Verl, Frankfurt/Main, 2002 [SiLo98] Simon, H.; Lorenz, J. U.: Die heimlichen Gewinner. Die Erfolgsstrategien unbekannter Weltmarktführer = (Hidden champions). Campus-Verl., Frankfurt/Main, 1998 [Simo01] Simon, J. S.: The five life stages of nonprofit organizations. Where you are, where you're going, and what to expect when you get there. Amherst H. Wilder Foundation, Saint Paul MN, 2001 [Simo07] Simon, H.: Hidden Champions des 21. Jahrhunderts. Die Erfolgsstrategien unbekannter Weltmarktführer. Campus-Verl, Frankfurt/Main, 2007 [SiNo06] Sitzberger, S.; Nowey, T.: Lernen vom Business Engineering: Ansätze für ein systematisches, modellgestütztes Vorgehensmodell zum Sicherheitsmanagement. Multikonferenz Wirtschaftsinformatik 2006, Passau, 2006 [Sobc09] Sobczyk, M.: Keep All Objectives Satisfied (KAOS) with Intentional Anti-Models. http://www.fb9dv.uni-duisburg.de/se/de/education/ss2009/seceng/download/ KaosAusarbeitung.pdf, 15.01.2011 [Somm07] Sommerville, I.: Software engineering. Pearson Studium, München, 2007 [Spri11] Springer Gabler Verlag: Kosten. http://wirtschaftslexikon.gabler.de/Archiv/54284/ kosten-v7.html [Stac73] Stachowiak, H.: Allgemeine Modelltheorie. Springer, Wien, 1973 [Stäh01] Stähler, P.: Geschäftsmodelle in der digitalen Ökonomie. Eul, Lohmar, St.Gallen, 2001 [Stäh09] Stähler, P.: Wie man Marktführer vom Thron stösst. http://blog.business-model-innovation.com/2009/04/business-model-innovation-on-the-web/, 17.12.2010 [Stat09] Statistisches Bundesamt: Bevölkerungsstand. http://www.destatis.de/jetspeed/ portal/cms/Sites/destatis/Internet/DE/Navigation/Statistiken/Bevoelkerung/ Bevoelkerungsstand/Bevoelkerungsstand.psml, 10.11.2009 [StFj98] Stabell, C. B.; Fjeldstad, Ø. D.: Configuring value for competitive advantage: on chains, shops, and networks. In Strategic Management Journal, 1998, 19; S. 413–437

239

[StHa05]

Stahlknecht, P.; Hasenkamp, U.: Einführung in die Wirtschaftsinformatik. http:// dx.doi.org/10.1007/b137873 [Stro+08] Strohmaier, M. et al.: Can Patterns Improve i* Modeling? Two Exploratory Studies. In Proceedings of the 14th international conference on Requirements Engineering: Foundation for Software Quality, 2008; S. 153–167 [StSc02] Strauß, R.; Schoder, D.: eReality. Das e-business-Bausteinkonzept ; Strategien und Erfolgsfaktoren für das e-business-Management. FAZ-Inst. für ManagementMarkt- und Medieninformationen, Frankfurt am Main, 2002 [SuGi98] Sung, T. K.; Gibson, D. V.: Critical Success Factors for Business Reengineering and Corporate Performance: The Case of Korean Corporations. http://dx.doi. org/10.1016/S0040-1625(98)00027-4, 18.10.2009 [Sutc98] Sutcliffe, A.: Scenario-based requirements analysis. In Requirements Engineering, 1998, 3; S. 48–65 [Teec09] Teece, D. J.: Business Models, Business Strategy and Innovation. In Long Range Planning, 2009, 43; S. 172-194 [Timm98] Timmers, P.: Business Models for Electronic Markets. In Electronic Markets, 1998, 8; S. 3-8 [TöWi08] Töpfer, J.; Winter, R.: Active Enterprise Intelligence. http://dx.doi. org/10.1007/978-3-540-78498-2 [Trac07] Trachsel, M.: Nischenstrategien und ihre Bedeutung für den Unternehmenserfolg. Deutscher Universitäts-Verlag / GWV Fachverlage GmbH Wiesbaden, Wiesbaden, 2007 [TsDa08] Tsun, C.; Dac-Buu, C.: A survey study of critical success factors in agile software projects. In The Journal of Systems and Software, 2008; S. 961–971 [VoTh06] Vom Brocke, J.; Thomas, O.: Reference Modeling for Organizational Change: Applying Collaborative Techniques for Business Engineering. In Proceedings of the Twelfth Americas Conference on Information Systems, 2006; S. 680–688 [Wamp09] Wampfler, R.: Herausforderungen im Produktentwicklungsprozess in der Swisscom (CBU). Persönliches Interview, Bern, 2009 [Wamp11] Wampfler, R.: Produktentwicklungsprozess in der Swisscom (CBU). Persönliches Interview, Bern, 2011 [Wang08] Wang, Y.-S.: Assessing e-commerce systems success: a respecification and validation of the DeLone and McLean model of IS success. In Information Systems Journal, 2008; S. 529–557 [WeVi01] Weill, P.; Vitale, M. R.: Place to space. Migrating to ebusiness models. Harvard Business School Press, Boston, Mass., 2001 [Will07] Willer, P.: Businessplan und Markterfolg eines Geschäftskonzepts. Deutscher UniversitSts-Verlag | GWV Fachverlage GmbH Wiesbaden, Wiesbaden, 2007 [Wint03] Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering. In Business Engineering - Auf dem Weg zum Unternehmen des Informationszeitalters 2. Aufl., 2003; S. 87–118 [Wirt00] Wirtz, B. W.: Electronic Business. Gabler, Wiesbaden, 2000 [Wirt10] Wirtz, B. W.: Business Model Management. Design - Instrumente - Erfolgsfaktoren von Geschäftsmodellen. Gabler, Wiesbaden, 2010 [WöDö00] Wöhe, G.; Döring, U.: Einführung in die allgemeine Betriebswirtschaftslehre. Vahlen, München, 2000 [Wood97] Woodruff, R.: Customer value: The next source for competitive advantage. In Journal of the Academy of Marketing Science, 1997, 25; S. 139-153

240

[Wüth+97] Wüthrich, H. A.; Philipp, A. F.; Frentz, M. H.: Vorsprung durch Virtualisierung. Lernen von virtuellen Pionierunternehmen. Gabler, Wiesbaden, 1997 [Wyss04] Wyssusek, B.: Methodologische Aspekte der Organisationsmodellierung in der Wirtschaftsinformatik. Ein soziopragmatisch-konstruktivistischer Ansatz. Dissertation, Berlin, 2004 [Youn04] Young, R. R.: The requirements engineering handbook. Artech House, Boston, Mass, 2004 [Yu95] Yu, E. S.-K.: Modelling strategic relationships for process reengineering. Univ., Ph. D. Thesis--Toronto, 1995, 1995 [Yu97] Yu, E. S. K.: Towards modelling and reasoning support for early-phase requirements engineering. In Requirements Engineering, 1997., Proceedings of the Third IEEE International Symposium on, 1997 [Yu+01] Yu, E.; Liu, L.; Li, Y.: Modelling Strategic Actor Relationships to Support Intellectual Property Management;In (Kunii, H. S.; Jajodia, S.; Sølvberg, A. Hrsg.). Springer Berlin / Heidelberg, 2001; S. 164-178 [Yu01] Yu, C.-C.: An Integrated Framework of Business Models for Guiding Electronic Commerce Applications and Case Studies. Second international conference, EC-Web 2001, Munich, Germany, September 4 - 6, 2001 ; proceedings. Springer, Berlin, 2001 [Yu09] Yu, E. S.: Social Modeling and i*. In Conceptual Modeling: Foundations and Applications: Essays in Honor of John Mylopoulos, 2009; S. 99–121 [Yu11] Yu, E. S. K.: Social modeling for requirements engineering. The MIT Press, Cambridge, Mass, 2011 [YuMy93] Yu, E. S. K.; Mylopoulos, J.: An actor dependency model of organizational work: with application to business process reengineering. In Proceedings of the conference on Organizational computing system [Zhao+08] Zhao, J.; Huang, W. V.; Zhu, Z.: An Empirical Study of E-Business Implementation Process in China. Engineering Management, IEEE Transactions on. In Engineering Management, IEEE Transactions on DOI - 10.1109/TEM.2007.912930, 2008, 55; S. 134–147 [Zoll06] Zollenkop, M.: Geschäftsmodellinnovation. Gabler Verlag / GWV Fachverlage GmbH Wiesbaden, Wiesbaden, Bamberg, 2006

241

Über den Autor Dr. Andreas Rusnjak, MBA (geb. 1974) besitzt seit mehr als zwölf Jahren fundierte Berufs-, Beratungs- und Gründungserfahrung, vorrangig in den neuen Medien bzw. im eCommerce. Er promovierte mit dem Forschungsschwerpunkt "Transformation von Geschäftsmodellen" von 2008 bis 2013 — in enger Kooperation mit der Christian-Albrechts-Universität Kiel — an der Universität Leipzig. Während seiner Zeit in Kiel initiierte und leitete er ein staatlich gefördertes Projekt zum Aufbau bzw. Ausbau von Gründeraktivitäten an Hochschulen und erreichte eine bis heute andauernde nachhaltige Kooperation von Professoren und Studierenden über alle Kieler Hochschulen hinweg1. Darüber hinaus ist er Gründungsmitglied der Campus Business Box2 und des ersten deutschen Rotary E-Clubs3.

Seit 2009 wirkt Andreas Rusnjak als Dozent/ Referent an diversen Hochschulen für die Lehrinhalte Strategieentwicklung, Geschäftsmodellentwicklung, eCommerce, data-driven eCommerce, Entrepreneurship, Innovationsmanagement sowie Marketing und bietet darüber hinaus Business-Modeling Workshops für Studierende, Gründer und Unternehmen bzw. Unternehmer an. Seit Juli 2011 verantwortet Andreas Rusnjak die Themengebiete Personalisierung, data-driven/ metric-driven eCommerce und Business Intelligence bzw. Business Analytics bei einem der größten deutschen Online-Shops. Parallel hierzu plant er als "Business Model Engineering"-Evangelist unter der Marke "Business Model Creativity" weitere Buch-, Beratungs- und Konferenzprojekte. Kontakt: www.businessmodelcreativity.net | eMail: [email protected] Zusatzbeitrag zur Business Model Notation M.Sc. Wirtschaftsinformatik Timur Ercan ist seit 2010 in Kooperation mit Dr. Andreas Rusnjak sowie der Arbeitsgruppe Wirtschaftsinformatik der Christian-Albrechts-Universität (CAU) zu Kiel im Forschungsfeld Business Modeling aktiv und Mitbegründer der Business Modeling Notation (BMN). Zudem ist er geschäftsführender Gesellschafter der runpat GmbH, eine Ausgründung der Universität Kiel, welche Business Modeling Workshops, Beratung sowie die eigens entwickelte Business Modeling Software runpat — auf Basis der BMN — entwickelt und vertreibt. Während der Gründungsvorbereitung wurde das runpat-Konzept bereits durch die Innovationsstiftung Schleswig-Holstein (ISH) ausgezeichnet und das EXIST Gründerstipendien gefördert.

1 2

3

CAU Kiel, FH Kiel, Wirtschaftsakademie Kiel und Muthesius Kunsthochschule Die Campus Business Box ist ein von Studierenden, Unternehmern und Hochschulprofessoren initiierter gemeinnütziger Verein. Die Grundidee der Box basiert darauf, praktische Erfahrung mit dem akademischen Hochschulumfeld zu vereinen, interdisziplinäre Teamarbeit zu unterstützen, soziale Verantwortung zu stärken und eine Innovationskultur zu festigen.; www.campusbuxinessbox.de http://www.rotary1810.org/eclub/

A. Rusnjak, Entrepreneurial Business Modeling, DOI 10.1007/978-3-658-03767-3, © Springer Fachmedien Wiesbaden 2014