Viable System Model. System Fünf (S5) Normative Funktionen Normatives Corporate Management. System Drei* (S3*) Auditierende Funktionen

Transkript

1 Legon-Prinzipien 1. Wir beeinflussen und formen die Umwelt aktiv; 2. Wir leisten einen positiven Netto-Beitrag zur Lebensfähigkeit und Entwicklung des grösseren Ganzen in das wir eingebettet sind; 3. Wir passen uns an verändernde Umweltsituationen an, z.b. Veränderungen als Impulse von aussen; 4. Wir finden, falls nötig, ein neues Milieu ( Spielfeld ) oder definieren uns in unserer Umwelt neu Markus Schwaninger: Intelligent Organizations; Powerful Models for Systematic Management, Berlin Heidelberg 2009 auf Google-Books:

2 Viable System Model System Fünf (S5) Normative Funktionen Normatives Corporate Management Letzte Entscheidungsinstanz des Systems. Stiftet Identität, definiert Werthaltungen, Grundregeln, Basisannahmen. System 5 sorgt dafür, dass System 3 und 4 wirksam im Hinblick auf den Zweck des Systems funktionieren. Bekannte & unbekannte Umwelt des Gesamtsystems System Vier (S4) Outside & Then Funktionen Strategic Corporate Management Nimmt Informationen aus der Umwelt des Gesamtsystems auf und verarbeitet diese: Adaption, Forschung, Entwicklung, Strategie, Corporate Development. Kommuniziert nach aussen: Marketing, PR, Kooperationen, etc. Aufbau zukünftiger Erfolgspotentiale. System Drei (S3) Inside & Now Funktionen Operatives Corporate Management Sorgt für die Optimierung des Zusammenspiels der operativen Einheiten und für die Realisierung der im System bestehenden Synergien. Nutzung bestehender Erfolgspotentiale.? 3* System Drei* (S3*) Auditierende Funktionen Über die Funktionen von S3* erhält S3 ungefilterte real-life-informationen aus S1 (Auditierungen, Inspektionen, Spaziergang durch die Fabrik ). System Zwei (S2) Koordinierende & Anti-Oszilierende Funktionen Umfasst jene Funktionen, die auf die Koordination der weitgehend autonom agierenden S1 gerichtet sind. Setzt Rahmenbediungen für eine konflikt- und missverständnisfreie Atmosphäre und ermöglicht die Selbstregu lation der S1 untereinander System Eins (S1) Operative Einheiten Jedes S1 besteht aus einem Management, einer Operation und einer für diese relevanten Umwelt (die sich stets verändert). Die S1 erfüllen den Zweck des Systems, indem sie das produzieren, wofür der Kunde bezahlt. Jedes S1 ist so gestaltet, dass es grösstmögliche Autonomie, eigene Budgets und Ressourcen und eine verantwortliche Führung besitzt. Jedes S1 ist demnach selbst lebensfähig und besteht wiederum aus den fünf Subsystemen (S5, S4, S3 (inkl. S3*), S2 und S1) Viable System Model Malik Management Zentrum St. Gallen

3 Das Viable System Model im Überblick Unsere Mission ist es, für alle Arten von Organisationen ein Gehirn und Nervensystem zu etablieren, das sie anpassungsfähig, lernfähig und selbstorganisierend macht, so dass sie die zukünftigen Herausforderungen ihrer Umwelt bewältigen können. Ursprung Das Viable System Model (Modell lebensfähiger Systeme) wurde vom britischen Kybernetiker Stafford Beer ( ) entwickelt. Es basiert auf Systemtheorie und Kybernetik und ist vom menschlichen Nervensystem und Gehirn abgeleitet, dem höchstentwickelten Regulierungsmechanismus für den Umgang mit Komplexität und Selbstorganisation. Anwendung Das VSM bietet die notwendigen und hinreichenden Voraussetzungen für die Lebensfähigkeit von zweckorientierten, produktiven sozialen Systemen in ihrer komplexen und dynamischen Umwelt. Es ist die regulatorische Struktur eines jeden Systems, das in seiner komplexen Umwelt anpassungsfähig, lernfähig und selbstorganisierend - und daher lebensfähig ist; es ist die Tiefenstruktur jedes lebensfähigen Systems. Die fünf Subsysteme Jedes lebensfähige System besteht erstens aus den Operativen Einheiten, den Systemen 1 (S1), die den Zweck einer Organisation erfüllen. Da Organisationen aus mehreren Operativen Einheiten bestehen, braucht es eine Koordierende und Anti-Oszillatorische Funktion, das System 2 (S2), das einen stabilisierenden Effekt hat und die Notwendigkeit der Intervention durch ein übergeordnetes Operatives Management, das System 3 (S3), minimiert. S3 optimiert das Zusammenspiel der S1 und führt die relativ autonomen S1 zu einem Ganzen zusammen. Um das Zusammenspiel der S1 unter Kontrolle zu halten, liefert eine Auditierende Funktion, das System 3* (S3*), ungefilterte Information direkt von den S1 zu S3. Strategische Fragen sind Sache des Strategischen Managements, dem System 4 (S4). S3 und S4 sind in stetem Kontakt, um die Balance zwischen heutigem und zukünftigem (Erkennen von Chancen & Risiken) Geschäft sicherzustellen. Bei Unstimmigkeiten zwischen S3 und S4 greift das Normative Management, das System 5 (S5), ein und schließt den Kreis. S5 hat die normative Entscheidungsgewalt und setzt die Regeln, Richtlinien und Werte der Organisation. malik-mzsg Legon Informatik GmbH, 2008

4 Die invariante Grundstruktur von Geschäftssystemen suchen Kundenwünsche haben Lösungstechnologien erzeugen erreichen Produkte, Leistungen Kundengruppen Absatzwege fliessen durch Die invariante Grundstruktur von Geschäftssystemen Malik Management Zentrum St. Gallen

5 4 Actions Framework nach Blue Ocean Strategy Reduce Which factors should be reduced well below the industry s standard? Eliminate Which of the factors that the industry takes for granted should be eliminated? A New Value Curve Create Which factors should be created that the industry has never offered? Raise W. C. Kim, R. Mauborgne: Blue Ocean Strategy. Boston, MA: Harvard Business School Press, 2005 Which factors should be raised well above the industry s standard? To reconstruct buyer value elements in crafting a new value curve, we use the Four Actions Framework. As shown in the diagram above, to break the trade-off between differentiation and low cost and to create a new value curve, there are four key questions to challenge an industry s strategic logic and business model

6 Fair Process Blue Ocean Strategy 1. Engagement. Engagement means involving individuals in the strategic decisions that affect them, asking for their input, and allowing them to refute the merit of one another s ideas and assumptions. Engagement communicates respect for individuals and their ideas. 2. Explanation. Explanation means that everyone involved and affected should understand why final strategic decisions are made as they are. An explanation of the thinking behind decisions makes people confident their opinions have been considered. An explanation serves as a powerful feedback loop that enhances learning. 3. Expectation clarity. Expectation clarity requires that after a strategy is set, parties state clearly the new rules of the game and what is expected of the other party. Although the expectations may be demanding, people should know up front what standards they will be judged by and the penalties for failure. When people clearly understand what is expected of them, political jockeying and favoritism are minimized, and people can focus on executing the strategy rapidly.

7 IMS Malik Management Zentrum St. Gallen

8 Business Model Canvas Key Partners Who are our Key Partners? Who are our key suppliers? Which Key Resources are we acquiring from partners? Which Key Activities do partners perform? MOTIVATIONS FOR PARTNERSHIPS: Optimization and economy Reduction of risk and uncertainty Acquisition of particular resources and activities Key Activities What Key Activities do our Value Propositions require? Our Distribution Channels? Customer Relationships? Revenue streams? CATEGORIES Production Problem Solving Platform/Network Key Resources What Key Resources do our Value Propositions require? Our Distribution Channels? Customer Relationships? Revenue Streams? TYPES OF RESOURCES Physical Intellectual (brand patents, copyrights, data) Human Financial Value Propositions What value do we deliver to the customer? Which one of our customer s problems are we helping to solve? What bundles of products and services are we offering to each Customer Segment? Which customer needs are we satisfying? CHARACTERISTICS Newness Performance Customization Getting the Job Done Design Brand/Status Price Cost Reduction Risk Reduction Accessibility Convenience/Usability Customer Relationships What type of relationship does each of our Customer Segments expect us to establish and maintain with them? Which ones have we established? How are they integrated with the rest of our business model? How costly are they? EXAMPLES Personal assistance Dedicated Personal Assistance Self-Service Automated Services Communities Co-creation Channels Through which Channels do our Customer Segments want to be reached? How are we reaching them now? How are our Channels integrated? Which ones work best? Which ones are most cost-efficient? How are we integrating them with customer routines? CHANNEL PHASES: 1. Awareness How do we raise awareness about our company s products and services? 2. Evaluation How do we help customers evaluate our organization s Value Proposition? 3. Purchase How do we allow customers to purchase specific products and services? 4. Delivery How do we deliver a Value Proposition to customers? 5. After sales How do we provide post-purchase customer support? Customer Segments For whom are we creating value? Who are our most important customers? MASS MARKET Niche Market Segmented Diversified Multi-sided Platform Cost Structure What are the most important costs inherent in our business model? Which Key Resources are most expensive? Which Key Activities are most expensive? IS YOUR BUSINESS MORE: Cost Driven (leanest cost structure, low price value proposition, maximum automation, extensive outsourcing) Value Driven ( focused on value creation, premium value proposition) SAMPLE CHARACTERISTICS: Fixed Costs (salaries, rents, utilities) Variable costs Economies of scale Economies of scope Revenue Streams For what value are our customers really willing to pay? For what do they currently pay? How are they currently paying? How would they prefer to pay? How much does each Revenue Stream contribute to overall revenues? TYPES: Asset sale Usage fee Subscription Fees Lending/Renting/Leasing Licensing Brokerage fees Advertising FIXED PRICING List Price Product feature dependent Customer segment dependent Volume dependent DYNAMIC PRICING Negotiation ( bargaining) Yield Management Real-time-Market Diese Arbeit ist unter Creative Commons oder CC linzenziert.

9 Software Craftmanship Manifesto for Agile Software Development 2001 Manifesto for Software Craftsmanship 2009 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only but also Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan working software, responding to change, individuals and interactions, customer collaboration, well-crafted software steadily adding value a community of professionals productive partnerships That is, while there is value in the items on the right, we value the items on the left more. That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

10 Erfolgsfaktoren Lean-Agile Software Development Business entscheidet, wo Software-Entwicklung am meisten Wert kreiert Teams welche die Systeme erstellen sind Owner der Systeme Management bildet die Teams aus und unterstützt diese Leadership drückt über Appreciation aus, dass die notwendige Qualtität und die strategische Ausrichtung des Resultats stimmen A. Shalloway, G. Beaver, J.R. Trott: Lean-Agile Software Development; Achieving Enterprise Agility, Massachusets 2009 Übersetzung ins Deutsche: Legon

11 Project Variables Most projects have four parameters time, cost, features and quality. Trying to fix all these parameters at the outset is impractical and is the cause of many common problems. Traditional Approach DSDM Atern Approach Features fixed Time Cost Quality Quality Time Cost variable Features

12 Iterative Zusammenarbeit Variante Wochen 3-4 Wochen 3-4 Wochen 3-4 Wochen 3-4 Wochen 3-4 Wochen 8 Tage Initialphase 6 Tage 1 6 Tage 2 6 Tage 3 6 Tage 4 6 Tage 5 Variante Wochen 2-3 Wochen 2-3 Wochen 2-3 Wochen 2-3 Wochen 2-3 Wochen 2-3 Wochen 2-3 Wochen 6 Tage Initialphase 4 Tage 1 4 Tage 2 4 Tage 3 4 Tage 4 4 Tage 5 4 Tage 6 4 Tage 7 Quelle: DSDM Atern: Iterative Development

13 Process nach dem Prinzip von: DSDM Lifecycle Feasibility Business Study Agree Plan Identify Functional Prototype Review Business Implement Create Functional Prototype Iteration Functional Model Review Prototype User approval & user guidelines Iteration Implementation Train users Create Design Prototype Agree Plan Iteration Identify Design Prototype Design & Review Build Design Prototype Pre Project Post Project DSDM User Executive Sponsor Visionary Ambassador User Advisor User Project Manager Technical Co-ordinator Facilitator Team Leader Developer Tester Scribe Prioritization MoSCoW Rules» Must have for requirements that are fundamental to the system. Without them the system will be unworkable and useless. The Must Haves define the minimum usable subset. A DSDM project guarantees to satisfy all the minimum usable subset.» Should have for important requirements for which there is a workaround in the short term and which would normally be classed as mandatory in less time-constrained development, but the system will be useful and usable without them.» Could have for requirements that can more easily be left out of the increment under development.» Waiting List DSDM is a registered trademark of Dynamic Systems Development Method Limited. Dynamic Systems Development Method Limited 2003

14 Principles When to Use DSDM 1. Active user involvement is imperative. 2. The team must be empowered to get the job done. 3. The focus is on frequent delivery of products. 4. Fitness for business purpose is the essential criterion for acceptance of deliverables. 5. Iterative and incremental delivery is necessary to converge on accurate business solutions. 6. All changes during development are reversible. 7. Requirements are baselined at a high level. 8. Testing is integrated throughout the lifecycle 9. Collaboration & cooperation between all stakeholders is essential» Interactive System where functionality is clearly demonstrable at the user interface» A clearly defined user group» If computationally complex, the complexity can be decomposed or isolated» If large, capable of being split into smaller functional components» Time-constrained» Requirements can be prioritised.» Requirements are unclear or subject to frequent changes Pre Project Feasibility Study Business Study Functional Model Iteration Design and Build Iteration Implementation Post Project Description Projects do not exist in a vacuum: they need to be set up correctly from the outset to ensure success. To establish whether the proposed development can meet the business requirements of the organisation and to assess whether DSDM is the right approach for this project. Provides the basis for all subsequent work. Like the Feasibility Study, it is as short as possible (the duration measured in weeks rather than months), while achieving sufficient understanding of the business requirements and technical constraints to move forward with safety. Refining the business-based aspects of the system, i.e. building on the high-level processing and information requirements identified during the Business Study. Where the system is engineered to a sufficiently high standard to be safely placed in the hands of the users. The major product here is obviously the tested system. Covers the cutover from the development environment to the operational environment. This includes training the users who have not been part of the project team. Contains the activities that occur once the project team have disbanded. These include support and maintenance activities. Products Initial definition of the business problem and plans for the Feasibility Study Confirmation of alignment of the project with the appropriate strategy Ensure budget and resources are allocated and the initial project governance is in place Feasibility Study Feasibility Prototype (optional) Outline Plan Risk Log Business Area Definition Prioritised Requirement list System architecture Definition Development Plan Updated Risk Log Functional Model Functional Prototypes Non Functional Requirements List Functional Model Review Records Implementation Plan Timebox Plan Updated Risk Log Timebox Plans Design Prototypes Define Prototyping Review Records Tested System Test Records User Documentation Trained User Population Delivered System Increment Review Document Post Implementation Review Report Change Requests DSDM is a registered trademark of Dynamic Systems Development Method Limited. Dynamic Systems Development Method Limited 2003

15 Critical Success Factors Acceptance of the DSDM philosophy Decision making powers of the business people and developers in the team Commitment of senior business management to provide significant end-user involvement Incremental delivery Easy access to end-users Stability of the team Development team skills Size of the development team Supportive commercial relationship Development technology Description It is important that the sponsor/senior management understands and accepts the DSDM philosophy particularly the underlying principles. The senior business management must either agree to delegate decision-making to the business representatives in the development team or to participate in the team themselves. The business commitment and agreed participation is absolutely key. If this commitment is not achieved by the end of the DSDM Feasibility Study, DSDM should be abandoned in favour of a more traditional approach. The organisation should be amenable to the delivery of systems in an incremental fashion. This applies to both the business and the development side of the project. Contact between the developers and end-users should be continual and frequent throughout the project. The project will be put at risk if staff are swapped in and out. Specialists may be called in as required to support a team, but core teams should be constant throughout. The team must contain highly skilled people in terms of both the business area as well as the technical environment. Each DSDM team within the project should be small in order to minimise the overheads of management and communication, while optimising ownership The relationship must accommodate the evolution of the system`s requirements without imposing onerous change management overheads. The development technology should be suitable for the DSDM approach. DSDM is a registered trademark of Dynamic Systems Development Method Limited. Dynamic Systems Development Method Limited 2003

16