Vorlesung 03: (IT-)Organisation & Prozesse (3) Flashcards
Organisationsdesign: Entrepeneur
• Struktur
- Organisation ist eine große Einheit - Ein oder wenige Manager
• Koordinationsmechanismen
- Direkte Supervision, einige Manager im mittl. Management - Keine Standardisierung → wenig Technostruktur
• Intention/Charakter
- Dynamisch, um mit Bürokratien zu konkurrieren
→ Pull to Lead
Organisationsdesign: Bürokratie
• Struktur
- Große Technostruktur für Standardisierung - Große Anzahl von Mittelmanagement (vertikale Dezentralisierung)
• Koordinationsmechanismen
- Arbeit hoch spezialisiert und standardisiert (Output und Arbeit)
• Intention/Charakter
- Folge von industrieller Revolution (Massenproduktion) - Bsp.: VW
→ Pull to Rationalize
Organisationsdesign: Expertenorganisation
• Struktur
- Hoch spezialisiertes Fachpersonal mit hoher Kontrolle über eigene Arbeit, horizontale Dezentralisierung - Wenig Technostruktur
• Koordinationsmechanismen
- Standardisierung durch Ausbildung außerhalb der Organisation
• Intention/Charakter
- Umwelt stabil (Arbeit nach Standardisierung über Ausbildung und Autonomie) - Bsp.: Uni HH
→ Pull to Professionalize
Organisationsdesign: Adhokratie
• Struktur
- Dezentralisiert, vertikal und horizontal - Macht verteilt je nach Notwendigkeit - Planen, Designen, Ausführen nicht zu trennen - Unterschiede verschwimmen zwischen Mittelmanagement und Experten
• Koordinationsmechanismen
- Gegenseitige Abstimmung
• Intention/Charakter
- Umwelt komplex und dynamisch - Innovative heutige Organisationen mit Projektstrukturen - Bsp.: Software- und Beratungshäuser wie Google, Apple oder Gartner
→ Pull to Collaborate
Organisationsdesign: Diversifizierte Organisation
• Struktur
- Ähnlich zu Bürokratie, keine starke Integration - Kleine Technostruktur, Support für alle Bereiche (Bsp. Jurist) - Limitierte vertikale Dezentralisierung - Jede Einheit hat eigene Struktur
• Koordinationsmechanismen
- Performanzkontrolle durch Supervision von Bereichen - Standardisierung durch Output
• Intention/Charakter
- Große, reife Organisationen - Produktlinienvielfalt, Ersetzung funktioniert durch marktorientierte Einheiten - Bsp.: General Electric
→ Pull to Balkanize
Ambidextrie
- Zweideutigkeit (zwei Ebenen, die man anschauen kann/zwei unterschiedliche Typen)
- Versuch unterschiedliche Arten von Modi zu erarbeiten, um Exploration und Exploitation zu ermöglichen
Exploration
- Erkundung und Erschließung neuer Märkte
- Organisationsstruktur: organic, adaptive, loose
- Organisationskultur: enterpreneurial, risk taking
- Führung: visionary, involved
Exploitation
- Ausschöpung vorhandener Ressourcen
- Organisationsstruktur: machanistic, formalized
- Organisationskultur: conservative, low risk
- Führung: autocratic, top to bottom
Typen organisationaler Ambidextrie
• Sequentiell
- Switch zwischen explorativ und exploitativ, kaum Anwendung
• Kontextuell
- Mitarbeitern wird ermöglicht, seine Zeit zwischen diesen widersprüchlichen Forderungen (Exploitation vs. Exploration) auf der Grundlage seines eigenen Urteils aufzuteilen (wie bei Google)
• Strukturell
- Zwei Modi, eine Hälfte was man schon immer gemacht hat, die andere etwas neues explorativ erarbeiten
• Temporär
- Zwischen Aspekten shiften. Leute aus Exploitation eine Zeit für Exploration arbeiten lassen
VUCA
Volatilität
• Geschwindigkeit, Umfang und Dynamik von Veränderungen größer, Spannungsbreite steigt
Unsicherheit
• Vorhersehbarkeit und Vorhersagbarkeit von Themen und Ereignissen immer geringer; kausale Zusammenhänge unklarer
Komplexität
• Anzahl von Handlungsmöglichkeiten steigt; Widersprüchliche Interessen nehmen zu
Ambiguität
• Rahmenbedingungen und Grenzen unscharf und schwer greifbar
Organisatorische Agilität
• Customer
- Kunden als Co-Creator von Innovationen betrachtet, Unterstützung in der Exploration und Exploitation
• Partnering
- Internes Wissen, Ressourcen und Kompetenzen externer Dienstleister dienen zur Exploration und Exploitation von Innovationen
• Operational
- Geschwindigkeit und Kosteneinsparungen bei der Exploitation von Innovationen verfolgt
Probleme bei Agilität
- Umfang und Budget für Projekt zu Beginn konkret festgelegt
- Kundenwünsche können stark schwanken und sich ändern und so Umfang vom Projekt sprengen oder obsolet machen
- Weiteres Problem: entwickeltes Artefakt (z.B. Software) muss dauerhaft betrieben und gewartet werden (z.B. Updates), was aber üblicherweise nicht im Umfang des Projektes ist
Horizontale Skalierung
- Verantwortung des Teams wird auf ganzen Produktlebenszyklus ausgeweitet
- Team hat/erarbeitet Fähigkeit zum dauerhaften Monitoring des Kundenverhaltens → Änderungen schnell erkennen
- Ziel: Commitment für Verantwortung für das entstandene Produkt
Vertikale Skalierung
• Mehrere Teams: Typischerweise 7 +- 2 Personen
→ Teams von Teams ermöglichen Skalierbarkeit
• Faktoren des Skalierens: Typ der Anwendung, Teamverteilung, Teamgröße/-anzahl
