Glossar Agilität: kurz - knapp - klar 9783744865692

Table of contents :
Cover Page
Glossar Agilität
Inhaltsverzeichnis
Vorwort
Kapitel A
Kapitel B
Kapitel C
Kapitel D
Kapitel E
Kapitel F
Kapitel G
Kapitel H
Kapitel I
Kapitel J
Kapitel K
Kapitel L
Kapitel M
Kapitel N
Kapitel O
Kapitel P
Kapitel Q
Kapitel R
Kapitel S
Kapitel T
Kapitel U
Kapitel V
Kapitel W
Kapitel Z
Impressum

Citation preview

Inhaltsverzeichnis

Vorwort

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

W

Z

Vorwort

Projektmanagement ist „in“. Seit einiger Zeit sind Begriffe entstanden, wie „Digitalisierung“, „Industrie 4.0“ und vor allen Dingen: „Agiles Management“. Das sind wohl die neuen Projektgötzen, die unsere Projekte und damit die Welt retten sollen.

Dieser Hype nach diesen Themen tritt immer mehr in den Vordergrund der Wünsche der Projektverantwortlichen. Doch häufig sind damit unterschiedliche Wünsche verbunden, je nach Interessenlage und Schwerpunkt: 1. Der systemische Ansatz, ein neues Management generell zu denken und umzusetzen, 2. Der Wunsch und der Wettbewerbsdruck, Projekte schneller umzusetzen und Entwicklungszyklen zu verkürzen und 3. Digitalisierungs-projekte als reine ITProjekte zu betrachten

Es gibt keine Begriffsdefinitionen, so passiert es natürlich schnell, dass Begriffe synonym verwendet werden und allein dadurch Missverständnisse entstehen.

Mit diesem Glossar will ich den Versuch unternehmen und einige Begriffe aus ihrer jeweiligen Perspektive erläutern. Dieser Versuch mündet darin, dass ich einige technische ebenso erkläre wie Aspekte aus der Systemtheorie.

Das beinhaltet sicherlich die Aufgabe, diese Begriffe ständig zu erweitern und zu ergänzen.

Mal sehen, ob der Spagat gelingt.

Dietmar Prudix

Sindelfingen, September 2017

A

Abteilung

(engl.: department) Größere Einheit der Strukturorganisation, in der mehrere Stellen zusammengefasst sind.

Abweichung

(engl.: deviation) Unterschied zwischen dem Wert eines Attributs im Sollzustand und dem Wert desselben Attributs im Istzustand.

Agil

(engl.: agile) Unter Agil werden viele Themen zusammengefasst, die sich mit der schnellen Umsetzung von Projekten ohne größere, übergeordnete Planungen beschäftigen.

Grundlage ist das Agile Manifest aus dem Jahr 2001, welches die 4 Werte und 12 Prinzipien beschreibt und online frei verfügbar ist (siehe Agiles Manifest).

Agile Coach

„Agile Coach“ ist ein besonders verwaschener Begriff, der oft eines von zwei Dingen meint. Manchmal wird er als Unterschied zum Scrum Master verwendet und soll ausdrücken, dass die Rolle sich neben den Team- und Prozess-Aufgaben auch darum kümmert, Kollegen persönlich weiterzuentwickeln und evtl. die Organisation als Ganze. Manchmal wird er verallgemeinernd verwendet als Oberbegriff für Scrum Master und die analoge Rolle im Kanban-Prozess und soll ausdrücken, dass der Inhaber der Rolle beide Arten von Vorgehensmodellen begleiten kann.

Agile Softwareentwicklung

(engl.: agile development) Agile Development ist eine kundenorientierte Methodik zur Softwareentwicklung, die auf schnellen Einsatz der entwickelten Systeme zielt, indem Teilprozesse einfach und beweglich gehalten sowie dabei insbesondere auch weiche, nicht nur formale Kriterien im Projektmanagement berücksichtigt werden. Agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand, wenigen Regeln und meist einem iterativen Vorgehen auszukommen.

Agiler Entwicklungsprozess/Agiles Entwicklungsvorgehen

Auf der Grundlage des Agilen Manifests bzw. seiner Werte und Prinzipien entstanden zahlreiche Ansätze mit dem Ziel, den Prozess der Softwareentwicklung durch Abbau von Bürokratie und stärkere Berücksichtigung menschlicher Aspekte effizienter zu gestalten. Es gibt keine klaren Kriterien, wann ein Softwareentwicklungsprozess als agil gelten kann, jedoch zeichnen sich viele Entwicklungsvorgehen durch diese Eigenschaften aus:

iterativ. Die Phasen der Softwareentwicklung werden mehrfach durchlaufen, um das Produkt schrittweise zu entwickeln und hierbei Erfahrungen aus vorangegangenen Entwicklungsschritten zu nutzen.

inkrementell. In jedem Durchlauf wird die Software um weitere Funktionen ergänzt; das Ergebnis ist ein Software-Inkrement, das prinzipiell für den produktiven Einsatz geeignet ist.

leichtgewichtig. Neben der Software entstehen nur wenige zusätzliche Artefakte.

kundennah. Der Kunde wird direkt in die Produktentwicklung einbezogen und hat die Bereitschaft, die Verantwortung für Entscheidungen und Risiken zu teilen.

Agiles Manifest

Im Februar 2001 wurde von der Agile Alliance, einem Zusammenschluss 17 führender Vertreter der agilen Bewegung, das Agile Manifest (Manifest für Agile Softwareentwicklung, engl. Manifesto for Agile Software Development) verabschiedet. Es formulierte ein Wertesystem und „Zwölf Prinzipien Agiler Software-entwicklung“.

Der kleinste gemeinsame Nenner aller agilen Vorgehensmodelle - und damit auch Scrum - ist das Agile Manifest (Agile Manifesto). Ins Deutsche übersetzt, besagt es Folgendes:

Wir suchen nach besseren Wegen, Produkte zu entwickeln, indem wir es selbst praktizieren und anderen dabei helfen, dies zu tun.

Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.

Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation.

Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.

Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

Wir erkennen dabei sehr wohl den Wert der Dinge auf der rechten Seite an, wertschätzen jedoch die auf der linken Seite noch mehr.

Verallgemeinerungen im Vergleich zum Originaltext:

„Produkte“ hieß ursprünglich nur „Software“.

„Funktionsfähige Produkte“ hieß ursprünglich nur „lauffähige Software“.

Diese Verallgemeinerungen sollen deutlich machen, dass agile Werte nicht nur

auf Software-Entwicklung anwendbar sind, sondern auch auf andere Projekte bzw. Produktionsprozesse. Nicht von ungefähr kommen die Parallelen von Scrum zur Schlanken Produktion (lean production) bzw. zum ToyotaProduktionssystem .

Zu den Unterzeichnern des Agilen Manifests gehören u.a. Ken Schwaber, Mike Beedle und Jeff Sutherland, drei der Begründer von Scrum. Daneben gehören auch bekannte Vertreter der XP-Szene wie Kent Beck dazu.

DIE 4 WERTE IM AGILEN MANIFEST

Menschen und Interaktionen stehen über Prozessen und Werkzeugen.

Funktionierende Software steht über einer umfassenden Dokumentation.

Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung.

Reagieren auf Veränderung steht über dem Befolgen eines Plans.

DIE 12 PRINZIPIEN IM AGILEN MANIFEST

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen! Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

DAS AGILE MANIFEST IN DER PRAXIS

Kurz zusammengefasst geht es darum, den Prozess der Softwareentwicklung flexibler („agil“) zu gestalten, um noch schneller noch bessere Software zu entwickeln. Klar, das will (und wollte auch schon vor der Ära der Agilität) jeder Software-Entwickler. Aber das Agile Manifest hat neue Routen zum Ziel aufgezeigt:

Vorhandene Ressourcen wie das Know-how der Mitarbeiter werden besser genutzt.

Bürokratischer Aufwand und Regeln werden auf ein Minimum reduziert.

Vorbildliche Dokumentation weicht funktionierender Software.

Der Kunde ist stärker eingebunden und iterative Prozesse ersetzen das alte

Phasenmodell „Entwurf - Realisierung - Test“.

In kleinen Schritten werden Teilziele realisiert, die ständig vom Kunden gegengeprüft werden. Das Feedback kann sofort in Verbesserungen einfließen.

Da das Projekt zum Startzeitpunkt ganz bewusst nicht vollständig ausgeplant wird, ist eine Anpassung an neue Anforderungen und veränderte Rahmenbedingungen auch während der Projektlaufzeit vergleichsweise problemlos möglich.

Und doch: Bei aller Begeisterung zeigt sich in der praktischen Umsetzung, dass das Umdenken im Kopf oft schwerer fällt als gedacht. Alte Denk- und Handlungsmuster halten sich hartnäckig, Vorbehalte in den Teams müssen abgebaut werden, und im Management besteht erfahrungsgemäß sehr viel Erklärungsbedarf zur Vertragsgestaltung agiler Projekte.

Häufig führt außerdem die Werte-Definition des Agilen Manifests zu Missverständnissen. Entgegen vieler Fehlinterpretationen gelten die Werte auf der rechten Seite nämlich auch im agilen Umfeld keinesfalls als unwichtig - die links aufgeführten Werte sind lediglich noch wichtiger! Auch in Scrum oder Kanban sind sinnvolle Prozesse für einen reibungslosen Ablauf unverzichtbar, und selbstverständlich wird auch in agilen Software-Projekten dokumentiert. Doch der ausgefeilteste Prozess nutzt nichts, wenn die Kommunikation im Team nicht passt, und die ausführlichste Dokumentation hilft nicht über Schwächen in der Software hinweg.

Ein agiles Mindset in Unternehmen zu verankern ist deshalb eine Herausforderung, die oft Monate dauert - die sich aber lohnt!

Agiles Projektmanagement

„Agiles Projektmanagement“ ist ein Oberbegriff für verschiedene Vorgehensmodelle bei der Software-Entwicklung wie z.B. Scrum oder Extreme Programming. Zunehmend wird es auch als Begriff für eine neue Denkweise im Projektmanagement als Gegensatz zum traditionellen, planungsorientierten Projektmanagement verwendet.

Mit dem Adjektiv „agil“ wollen die Vertreter der „agilen“ Prozesse bzw. des „Agilen Projektmanagements“ zum Ausdruck bringen, dass sie Management und Steuerung von Projekten und Prozessen sehr dynamisch und flexibel gestalten wollen. „Agil“ ist dabei der Nachfolgebegriff von „leicht“ oder „leichtgewichtig“ und soll die positiven Aspekte geringer Planungs- und Führungsintensität deutlicher herausheben.

Die Motivation für die Formulierung agiler Vorgehensweisen in der SoftwareEntwicklung kommt aus einer Reihe von Rahmenbedingungen, die herkömmliche Projektplanung als zu träge und starr erscheinen ließen:

Die sehr hohe Innovationsgeschwindigkeit im IT-Bereich erzwingt entsprechend schnelle Produktzyklen. Kunden und Markt sind nicht mehr in der Lage, eigene Anforderungen zu definieren, sondern reagieren nur noch auf die Präsentation neuer technischer Möglichkeiten und Produkte. Die Erstellung von Software ist für sich bereits ein hoch strukturierter Prozess, so dass die Notwendigkeit für ein übergeordnetes, systematisches Projektmanagement für SoftwareEntwicklungsprojekte oftmals nicht erkannt wird.

Die Anfänge des „Agilen Projektmanagements“ waren geprägt von einer mehr oder weniger offenen Ablehnung systematischen Projektmanagements mit intensiver Planung und Controlling. Beispielhaft dafür ist das sog. „Agile

Manifest“.

Erste Ansätze „leichtgewichtiger“ Software-Entwickungsprozesse wie z. B. das sog. Extreme Programming, lehnten Vorgehensmodelle vollständig ab und konzentrierten sich unmittelbar auf die Erstellung von ablauffähigem Code gemäß den Anforderungen des Auftraggebers.

Grundprinzip aller agiler Ansätze ist das Arbeiten in kurzen Iterationszyklen, bei denen jeweils der Auftraggeber mit dem vorläufigen Ergebnis konfrontiert wird und entsprechende Teilabnahmen oder Änderungsanforderungen bekundet. Dadurch entsteht die Spezifikation des Produktes erst im Laufe des Projekts selbst, zu Beginn liegt oft nur eine grobe Aufgabenstellung vor.

Während am Anfang des agilen Projektmanagements also die Einbindung des Kunden in den Entwicklungsprozess mit einer sehr offenen Gestaltung des Konfigurationsmanagements stand, so sind mittlerweile die Bereiche Risikomanagement und Qualitätsmanagement weitere wesentliche Bestandteile geworden. Indem zunehmend traditionelle Methoden und Aspekte des Projektmanagements in die agile Vorgehensweise integriert werden, verschwimmt die Abgrenzung zwischen beiden Projektmanagement Auffassungen immer mehr.

Gleichzeitig verkürzen sich auch die Produktlebenszyklen für HardwareProdukte. Dies trifft selbst für bisher als langlebig eingeschätzte Produkte wie Automobile oder Flugzeuge zu. Daher greifen auch von traditionellem Projektmanagement geprägte Branchen immer mehr Elemente des agilen Projektmanagements auf.

Je mehr die Ideen der „agilen“ Vorgehensweise in Methoden (z. B. Time Boxing) und Vorgehensmodelle (z. B. Scrum und V-Modell XT) Eingang finden,

desto mehr erhalten auch „agil“ geführte Projekte einen festen Handlungsrahmen. Von einer Synthese zwischen deterministischer Projektplanung und „Agilem Projekt-management“ kann diesen Entwicklungen zum Trotz noch nicht gesprochen werden.

Alle Welt spricht von „Agiler Software-Entwicklung“, von Methoden wie Scrum, Kanban und Extreme Programming - aber woher kommt die agile Bewegung eigentlich? Ein wichtiger Eckpfeiler für das Verständnis von Agilität ist das „Agile Manifest“, dem wir deshalb einen eigenen Glossar-Beitrag widmen.

Agiles Vorgehen

Unter agilem Vorgehen versteht man Methodiken, die auf große Vorabplanung der Durchführung (nicht der Inhalte) eines Projektes verzichten. Dies geschieht in Anerkennung der Tatsache, dass während der Umsetzung häufige Änderungen der Umwelt, der Voraussetzungen oder der Ziele eines Projektes solch eine Planung meist wertlos machen. Statt dessen setzen agile Ansätze darauf, so schnell wie möglich den kleinstmöglichen sinnvollen Teil des Projektes umzusetzen, davon zu lernen und mit diesem Wissen den nächsten sinnvollen Teil umzusetzen. Beispiele für agile Vorgehensmethoden sind etwa Scrum oder Kanban.

Agility

Das große Schlagwort des 21. Jahrhunderts. Firmen, Menschen alles muss agiler werden, um mit den komplexen, schnelllebigen Veränderungen mithalten zu können. Die Unternehmensberatung McKinsey hat in einer globalen Studie unter 1000 Unternehmen und 2 Millionen Befragten untersucht, was Unternehmen erfolgreich macht. Erst Agilität, also die Kombination von schneller Reaktion

auf sich verändernde Gegebenheiten und Stabilität, sorgt für die Gesundheit der Organisation. Als agil stellten sich nur 12 Prozent der untersuchten Unternehmen heraus, 58 Prozent waren durchschnittlich, 22 Prozent langsam und 8 Prozent einfach nur schnell - also stark wachsende Startups ohne jegliche Stabilität.

Akteur

Akteure (handelnde Systeme) sind Urheber einer Wirkung. Eine Einzelperson oder eine Organisation können Akteure sein, doch auch technische Geräte können als Akteure aufgefasst werden. Akteure werden je nach Paradigma unterschiedlich komplex konzeptualisiert, beispielsweise als simple Akteure mit eindimensional optimierender Verhaltenslogik oder aber als Akteure mit komplexem Innenleben, selektiver Informationsverarbeitung und multiplen, situativ sich verändernden, Zieldimensionen. Die Verhaltensökonomie untersucht beispielsweise unter welchen Bedingungen Personen eher Eigennutzen-orientiert oder kooperativ handeln. (→ Parsons; Dörner)

ALE

Annual Loss Exposure bzw. Annual Loss Expectancy; Erwartungswert für den pro Jahr aufgrund von Sicherheitsgefährdungen zu erwartenden Schaden.

Alternativstrategie

Strategie, welche die aus einem Szenario abgeleiteten Aussagen enthält, die nicht in die den Szenarien gemeinsame Leitstrategie integriert werden können.

Altsystem

(engl.: legacy system) Anwendungssystem, das aus Sicht einer neuen Technologie als nicht mehr dem Stand der Technik entsprechend beurteilt wird, das funktional aber seinen Zweck noch weitgehend erfüllt.

Analyse

Möglichst exakte Bestimmung und Charakterisierung von Teilen eines Systems (eines Ganzen) sowie der Beziehungen der Teile untereinander und zum Ganzen mit dem Zweck, das Ganze zu erklären.

Anforderung

(engl.: requirement) Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist. Synonym: Qualitätsanforderung.

Anforderungsprofil

Aus dem Aufgabenprofil einer Stelle zur Aufgabenerfüllung abgeleitete Qualifikation (Wissen, Können, Fähigkeiten, Fertigkeiten).

Antrag

(engl.: request for proposal)

zeitlich befristeter Vertragsantrag eines potenziellen Auftragnehmers an einen potenziellen Auftraggeber über die Realisierung eines Beschaffungsprojekts.

empfangsbedürftige Willenserklärung, die alle wesentlichen Vertragsbestandteile enthält, sodass das Zustandekommen des Vertrags nur vom Einverständnis des Empfängers abhängt.

Anwendungsarchitektur

(engl.: application architecture) Modell der Funktionalität und des Zusammenhangs der Anwendungssysteme eines Unternehmens oder Aufgabengebiets.

Anwendungssystem

(engl.: application system) Teil eines Informationssystems, das zur Unterstützung einer bestimmten Aufgabe eingesetzt wird; Kombination von Anwendungsprogramm oder -programmen und zugehörigen Daten.

Application Lifecycle Management (ALM)

Ein ganzheitlicher Ansatz, der das Ziel verfolgt, bestehende oder zukünftige Software als Objekt mit einem umfassenden Lebenszyklus zu verstehen. Software bzw. Applikationen existieren in der Regel nicht für die Ewigkeit und haben irgendwo ihren Ursprung/Endpunkt. ALM hat das Ziel, dieses Asset über den kompletten Lifecycle zu begleiten.

Arbeitsvorbereitung

(engl.: job scheduling) Planung, Überwachung und Steuerung aller für die RZProduktion erforderlichen Tätigkeiten. Synonym: Fertigungsvorbereitung.

Architektur

Organisation eines Systems, die sich in seinen Komponenten und deren Beziehungen zueinander sowie zum Systemumfeld manifestiert.

Architekturprinzip

Grundlegende Aussage zur Konstruktion, Beschreibung und Evaluierung von Architekturen.

ARIS

Architektur integrierter Informationssysteme; Referenzmodell zur Modellierung von Informationssystemen vom Fachkonzept bis zur Implementierung.

Artefakt

Die Ergebnisse der verschiedenen Phasen eines Softwareengineering-Prozesses werden als Artefakte (von lat.: „ars“ Kunst; „factum“ das Gemachte) bezeichnet. Der Begriff umfasst z.B. Anforderungsspezifikationen, Entwurfsdokumente, Diagramme, Programmcode und Testdokumente

Audit

Von unabhängigen Personen durchgeführte Überprüfung, ob QM-Systeme, Prozesse oder Organisationen bestimmte Kriterien erfüllen.

Aufgabenanalyse

Zerlegen von Aufgaben in Teilaufgaben und dieser in Tätigkeiten zwecks Bestimmung des Möglichkeitsraums der Arbeitsteilung.

Aufgabenprofil

Aus dem Leistungsprogramm abgeleitete Teilleistung einer Stelle bzw. eines Aufgabenträgers im Sinne von Aufforderungen, an bestimmten Objekten (Aktionsobjekte) bestimmte körperliche oder geistige Verrichtungen (Aktionsarten) durchzuführen, um definierte Ziele zu erreichen.

Aufgabensynthese

Zusammenfassen von Teilmengen des durch Aufgabenanalyse ermittelten Möglichkeitsraums der Arbeitsteilung zu Aufgaben.

Aufgabenträger

(engl.: task bearer) Mensch (Person oder Gruppe) oder Mensch/Technik-System, dem eine Aufgabe zur Aufgabenerfüllung übertragen ist.

Auftrag

(engl.: job, order) Aufforderung zur Erbringung einer definierten Leistung.

Auftraggeber

(engl.: orderer) Natürliche oder juristische Person, die einen Auftrag vergibt.

Auftragnehmer

(engl.: contractor) Natürliche oder juristische Person, die einen Auftrag übernimmt und in der Regel auch durchführt (Hersteller, Softwarehaus, Systemhaus).

Ausgliederung

(engl.: outsourcing) Übertragung von Aufgaben an ein mit dem OutsourcingNehmer rechtlich verbundenes Unternehmen.

Auslagerung

(engl.: outsourcing) Übertragung von Aufgaben an ein vom OutsourcingNehmer rechtlich unabhängiges Unternehmen.

Ausschreibung

(engl.: tendering) Vorgang der Einholung von Angeboten auf Grundlage definierter Anforderungen (z. B. in einem Pflichtenheft).

Authentifizieren

(engl.: authentication) Überprüfen der durch Identifikation behaupteten Identität eines Subjekts oder eines Objekts. Synonym: Authentifizierung

B

Backlog Grooming

Im Rahmen des Vorgehensmodells Scrum gibt es keine Vorgabe, wie eine gute Pflege des Product Backlogs sichergestellt wird. Als ein Best Practice haben sich Backlog Grooming-Workshops herausgestellt. Dies kann einfach mit Backlogpflege übersetzt werden. Dieser Workshop wird teilweise auch als „Scrum Product Backlog Grooming“ bezeichnet, obwohl er nicht Bestandteil des „offiziellen“ Scrum-Vorgehensmodells ist.

Ziel des Workshops ist die Erschaffung eines gut gewarteten Product Backlogs. Die Anforderungen sollen soweit vorbereitet werden, dass sie in einem Sprint Planungsmeeting problemlos eingeplant werden können.

Elemente des Backlog Groomings:

Hinzufügen von User Stories und Epics.

Herunterbrechen/Zerkleinern (Konkretisieren) von Epics und Stories.

Ggf. entfernen überflüssiger/ersetzter Stories.

Beschätzung von Stories.

Beispielhafter Ablauf eines Backlog Groomings

Der Product Owner bringt eine Reihe von Backlog Items (Anforderungen, Fehler, Aufgaben) ein, die in der nächsten Zeit realisiert werden sollen. Auch andere Teammitglieder bringen Items ein. Dies kann in der Form erfolgen, dass der Product Owner diese in priorisierter Reihenfolge auf einem Stapel vorlegt.

Nach und nach werden die Anforderungen von den Teammitgliedern gezogen und mit dem Team besprochen. Es werden Lösungsvorschläge erarbeitet und besprochen. Es wird über die Granularität der User Story gesprochen: „Ist sie soweit unterteilt und definiert, dass sie für eine Umsetzung eingeplant werden kann? Ist sie ready?“ (siehe dazu die Definition of Ready). Ist eine Anforderung fertig besprochen, wird eine Beschätzung durchgeführt.

Ergebnis sind letztlich Backlog Items, die wohldefiniert, mit dem Team besprochen und geschätzt sind.

Teilnehmer des Backlog Groomings

Wird mit Scrum gearbeitet, sollten das Team, der Product Owner und der ScrumMaster teilnehmen. Wird mit Kanban gearbeitet, auf jeden Fall das Team und der Board-Owner.

Tipps für Backlog Grooming Workshops

Die Integration aller Beteiligten sorgt für interdisziplinäre, aus verschiedenen Gesichtspunkten „durchdachte“ Lösungen.

Ein fester Termin vereinfacht die Organisation und stellt sicher, dass das Meeting nicht vergessen geht.

Das Backlog Grooming klingt zunächst nach einem zusätzlichen Termin und damit zusätzlicher Belastung für das Team. Durch die gute Vorbereitung des Backlogs kann somit aber viel Zeit beim Sprint Planning Meeting und bei der Besprechung von Anforderungen gespart werden.

Backsourcing

Übertragung von vorher durch einen Outsourcing-Geber erbrachten Leistungen an einen internen Dienstleister (z. B. die interne IT-Abteilung).

Bedarf

(engl.: requirement) Übertragung von vorher durch einen Outsourcing-Geber erbrachten Leistungen an einen internen Dienstleister (z. B. die interne ITAbteilung).

Bedürfnis

(engl.: need) Wunsch, Notwendigkeit oder Bereitschaft zur Beseitigung eines Mangels

Begriff

(engl.: concept) Wissenseinheit der Merkmale für ein Objekt, die durch einen Namen (Bezeichner) oder die Vorstellung einer Person darüber kommunizierbar wird; die Merkmale umfassen das Wissen, das über das Objekt existiert. Begriffe werden definiert.

Begriffssystem

(engl.: system of concepts) Gesamtheit der Fachwörter, Fachausdrücke, Fachbegriffe oder Terme (von lat. terminus technicus) einer Wissenschaft, eines Fachs oder eines Wissenschaftsbereichs.

Benutzerforschung

(engl.: user research) Forschungsrichtung der Wirtschaftsinformatik, welche die Erklärung des Benutzersystems zum Gegenstand hat und die auf Grundlage der Erklärungen bestrebt ist, eine den Anforderungen der Benutzer entsprechende Gestaltung des Benutzersystems zu ermöglichen.

Benutzungsschnittstelle

(engl.: usage interface) Hardware und Software, mit denen Kommunikation zwischen Menschen und Techniksystemen stattfindet.

Beobachtung

Woher weiß ein Akteur, was «Wirklichkeit» ist – was also in seiner Umwelt real stattfindet? Der Akteur kann zwar über seine Sensoren die Außenwelt beobachten. Beobachtung ist aber immer abhängig von den verfüg-baren Unterscheidungskategorien. Wer keine Sinneszellen für Farbe besitzt, für den besteht die Welt nur aus Grautönen. Was nicht erkannt und unterschieden werden kann, wird zum «blinden Fleck». Die Wahrnehmungs-psychologie kennt zahlreiche solche verzerrende Effekte (Biases). Zur Identifizierung von komplexeren Objekten und Prozessen ist meist Vorwissen und konzeptuelles Wissen notwendig, daher gibt es kaum «objektive», Beobachter-neutrale Beobachtung. Selten können wir alle für uns relevanten Aspekte der Umwelt selbst beobachten, wir beobachten daher Beobachter. Manchmal erkennen wir deren blinden Fleck. In Führungs- und Beratungs-gesprächen kann durch die Verwendung gezielter Fragen das Gegenüber dazu angeregt werden, eine Situation aus einer anderen Position oder mit alternativen Unterscheidungskategorien zu betrachten.(→ von Foerster; Watzlawick; Maturana; Varela; Luhmann)

Besichtigungsanalyse

(engl.: inspection analysis) Form der Istzustandserfassung, deren Zweck durch bloßes Besichtigen erreicht werden kann; ihre Ergebnisse werden meist zur Vorbereitung einer tiefer gehenden Analyse verwendet.

Bestandsmanagement

(engl.: asset management; inventory management)

systematischer Einsatz von Methoden und Werkzeugen mit dem Ziel der Wertsteigerung von Vermögensgegenständen.

Erfassung und bewusste Verwendung der im Unternehmen vorhandenen ITRessourcen (insbesondere Betriebsmittel).

Best Practice

Der Begriff Best Practice, ursprünglich aus der angloamerikanischen Betriebswirtschaftslehre, bezeichnet die bestmögliche (bereits erprobte) Methode oder Maßnahme zur Durchführung von etwas.

Betriebsmittel

(engl.: production facility) zur Abarbeitung eines Auftrags zur Verfügung stehende Hardware und Software sowie Personal und andere Hilfsmittel.

Betriebsvergleich

(engl.: comparison of organizations) systematische Gegenüberstellung von

Kennzahlen eines Unternehmens und denen anderer, vergleichbarer Unternehmen, um Informationen über die relative Stellung des Unter-nehmens zu gewinnen.

Beziehungszahl

(engl.: relative figure) Verhältniszahl, die zwei unterschiedliche, aber in einem Sinnzusammenhang stehende Zahlen in Beziehung setzt.

Big-Bang

Ein Vorhaben im Modus „Big-bang“ umzusetzen bedeutet zu einem Zeitpunkt alle Änderungen gleichzeitig durchzuführen, anstatt beispielsweise iterativ einzelne Schritte umzusetzen und danach die jeweils nächsten. Bigbang ist tendenziell eher unagil, da es das Lernen aus Erfahrungen nicht ermöglicht, aber manchmal ist solch ein Vorgehen unvermeidlich.

Bleisure

Arbeit und Freizeit verschmelzen zunehmend, von der Digitalisierung beflügelt. Wir sind überall erreichbar, ob wir wollen oder nicht, checken eMails im Bett und am Strand, machen Team Calls im Wohnzimmer und Skype-Interviews auf der Terrasse. Bleisure ist gleichzeitig Fluch und Chance: wir können unser Leben selbstbestimmter gestalten, müssen aber aufpassen, uns nicht zum Spielball von allzu übergriffigen Vorgesetzten machen zu lassen. Daher: regelmäßiges Digital Detox und ab in die Natur.

Blocks List

Vom ScrumMaster gepflegte, täglich aktualisierte Liste von ProjektHemmnissen (Impediments), blockierenden Faktoren und ausstehenden, das Projekt betreffenden Entscheidungen.

Bottom-up

Eine Entscheidung betrifft in der Regel Mitarbeiter auf verschiedenen Hierarchiestufen des Unternehmens. Wenn sie von denen getroffen wird, die hierbei auf den eher niedrigen Hierarchiestufen stehen, wird sie als bottom-up bezeichnet. Vorgehensweise bei Analyse, Entwurf, Testen usw., bei der mit den Systemteilen begonnen wird, die sich auf der untersten Ebene des hierarchisch gegliederten Systems befinden. Im Gegensatz dazu: Top-down-Ansatz.

BPEL

Business Process Execution Language, Kurzform für WS-BPEL

BPML

Business Process Modeling Language

BPMN

Business Process Modeling Notation

BPR

Business Process Reengineering

Brooks’sches Gesetz

(engl.: Brook’s law) Erfahrungsgrundsatz, nach dem das Hinzuziehen weiterer Bearbeiter zu einem in Terminnot geratenen Projekt dieses noch mehr verzögert. (Adding manpower to a late project makes it later.)

BSC

Balanced Scorecard; ein kennzahlenbasiertes Führungsinstrument

BSI

Bundesamt für Sicherheit in der Informationstechnik (Deutschland).

Burndown Chart

Grafik, die den Projektfortschritt eines Produktes, Sprints oder Releases in einer Kurve visualisiert. Die Kurve gibt für jeden Punkt auf dem horizontalen Zeitstrahl an, wieviel Arbeit nach jeweils aktueller Schätzung zu jedem Zeitpunkt noch übrig war/ist, um das Ziel zu erreichen. Mittels einer auf den vergangenen Schätzwerten basierenden Trendlinie durch die Kurve läßt sich das voraussichtliche zeitliche Ende des Projektes vorhersagen bzw. können sich andeutende Abweichungen vom Zeitplan innerhalb eines Sprints prognostiziert und Gegenmaßnahmen ergriffen werden.

Burn-Down-Chart

Im sogenannten Burn-Down-Chart tragen die Mitglieder eines Scrum-Teams täglich, in der Regel im Anschluss an das Daily Scrum-Meeting, die Anzahl der verbleibenden Aktivitäten oder Stunden ab, die noch zur Erledigung aller Aufgaben des Sprints zu erfüllen sind. Somit erhält das Team täglich einen Überblick über den verbleibenden Aufwand für die restliche Sprintdauer.

Das Burn-Down-Chart kann im Rahmen des Review-Meetings und der Retrospektive hilfreich sein, um den Verlauf der Abarbeitung der Arbeiten aus dem Sprint Backlog helfen.

Business Case

Ein Business Case ist die Prognose eines geschäftlichen Szenarios hinsichtlich seiner Kosten, Nutzen und Risiken.

Typischerweise werden damit Geschäftsmodell-Erweiterungen oder zu startende Projekte bewertet.

Business Intelligence

IT-basierter Ansatz zur Unterstützung der betrieblichen Entscheidungsfindung.

Business-Impact-Analyse

Methode, mit der kritische Geschäftsprozesse eines Unternehmens ermittelt und Prioritäten für den Wiederanlauf nach Eintritt eines Notfalls festgelegt werden.

Business-IT-Alignment

Abstimmung bzw. gegenseitige Ausrichtung von Unternehmensstrategie und ITEinsatz; zum Teil abgekürzt als IT-Alignment oder Alignment (von engl. adjusting a line).

Business Model Canvas (BMC)

Reduzierung des klassischen Business Plans auf die wichtigsten Fragen, die auf einer Seite dargestellt werden.

BYOD

Bring Your Own Device.

C

CAB-Sitzung

CAB-Sitzung ist ein regelmäßiges Treffen (idealerweise alle 2-4 Wochen) von fest definierten Personen, die sicherstellen, das verschiedene Änderungen/Themen rechtzeitig für die nächsten Releaseplanung berücksichtigt und eingeplant werden. Das CAB Meeting ist der zentrale Entscheider für die Einsteuerung von Anforderungen an die IT.

Änderungen/Themen können sowohl technisch, prozessbedingt, gesetzlich, satzungsrechtlich und/oder regulatorisch begründet sein. Ein hoher Anteil kostenintensiver IT-Service-Störungen lässt sich häufig auf schlecht koordinierte oder unzureichend gesteuerte Änderungen an der IT-Servicelandschaft zurückverfolgen. Diesen Störungen soll das CAB durch entsprechende Planungs- und Freigabemaßnahmen präventiv entgegen wirken.

CFIA – Component Failure Impact Analysis

Die Component Failure Impact Analysis, abgekürzt CFIA, ist eine einfache, etablierte, von IBM in den 1970ern entwickelte Methode. Die CFIA ist eine Auswirkungsanalyse für den Ausfall von Komponenten. Die Auswirkung von Ausfällen auf Services können (aus technologischer Sicht) prognostiziert und evaluiert und folglich Gegenmaßnahmen geplant werden. Die CFIA ist neben der SFA (Serviceausfallanalyse) und der FTA (Fault Tree Analysis – Fallbaumanalyse) eine der empfohlenen best practice Methoden aus der ITIL© Service Design Publikation. Das Ergebnis einer CFIA kann dabei helfen

herauszufinden, wo zusätzliche Ausfallsicherheit benötigt wird und wo nicht, in welchen Bereichen detaillierte Wiederherstellungs- und Entstörungsdokumente benötigt werden und schließt eine Risikobetrachtung auf Komponentenebene ein.

Change Evaluation

In ITIL 2011 wurde der Prozess „Change Evaluation“ hinzugefügt. Bei vielen Unternehmen läuft dieser Prozess als sogenanntes Vorprojekt ab, bei dem der durchzuführende Change erst mal im Kleinen durchgeführt und evaluiert wird. Vor allem bei größeren, komplexeren Änderungen (Changes) ist es sinnvoll, den Umfang und die Auswirkungen eines solchen im Vorfeld im Rahmen eines kleinen Testprojektes zu evaluieren - sowohl kostentechnisch als auch aus Sicht der ein zusetzenden Ressourcen. Sobald das Ergebnis vorliegt, kann das CAB über die Durchführung entscheiden und mit der Releaseplanung gestartet werden.

Change Request

Anforderung einer (Ver-)Änderung. Synonym: Request for Change.

Chaos

Das Verhalten eines chaotischen Systems ist kaum oder nicht vorhersagbar. Selbst wenn das System über kein Gedächtnis verfügt, ist sein Verhalten hochgradig von Anfangsbedingungen abhängig, da kleinste Unterschiede des aktuellen Systems zu teilweise radikal anderen Folgeschritten führen können

(Schmetterlingseffekt). Chaotische Systeme können sehr unterschiedliche Zustände einnehmen, aber auch zeitweise in engen Bahnen kreisen bis sie diese wieder verlassen. Solche zeitweise bevorzugten Verhaltensmuster werden Attraktoren genannt. Diese Begriffe wurden auf Organisationen übertragen, beispielsweise können Streik-Situationen Aspekte beinhalten, die der Chaostheorie entsprechen: Geschehnisse eines Streiktages lassen die Ereignisse des Folgetages kaum vorhersehen; teilweise kreisen Verhandlungsdiskussionen um denselben Problem-punkt, können aber auch unerwartet in einen anderen Problem-Aspekt kippen. (→ Prigogine)

Chicken

Am Projekt interessierte, jedoch nicht direkt an der Umsetzung und am Projektrisiko beteiligte Person. Im Gegensatz zu den Chickens gibt es noch die Pigs.

Clean Code

Clean Code beschreibt eine Menge von Prinzipien und Best Practices, die dafür sorgen, dass Software Code sauber aufgesetzt, ordentlich formatiert, klar strukturiert und dokumentiert ist. Das Ziel besteht darin, eine klar verständliche Programmierung zu hinterlassen, dies auch einem anderen Entwickler ermöglicht, das Projekt ohne große Probleme übernehmen zu können.

C-Level

Sammelbezeichnung für das Top-Management einer Unternehmung, nämlich die Positionen der CxO, also Chief Executive Officer (CEO), Chief Operating

Officer (COO), Chief Financial Officer (CFO), Chief Information Officer (CIO) und so weiter.

Cloud Computing

bedarfsgerechter Zugriff auf IuK-Technologien (Hardware, Software Plattformen) als Service über ein Netzwerk (Internet bei Public Clouds, Intranet bei Private Clouds).

Bereitstellung elektronischer Dienste (z. B. Speicherkapazität), die von Anwendern über Internet genutzt werden.

Gängige Ausprägungen: IaaS /PaaS / SaaS / BPaaS (Infrastructure- / Platform- / Software- / Business Process-asa-Service)

CMDB

Configuration Management Database; Datenbank, mit der CIs verwaltet werden.

CMM

Capability Maturity Model; vom SEI herausgegebenes, mittlerweile durch das CMMI abgelöstes Reifegradmodell für Entwicklungsprozesse.

CMMI

Capability Maturity Model Integration; vom SEI herausgegebenes Reifegradmodell zur Evaluierung und Verbesserung von Entwicklungsprozessen.

Consulted

Diese Person (bzw. Personengruppe) kann beratend hinzugefügt werden und fungiert als Experte bzw. Wissensträger für ein konkretes Themengebiet. Diese Person ist in der Regel nicht aktiv am Prozess beteiligt. Je nach Definition muss oder soll diese Person beratend hinzugezogen werden.

Coaching

Beratung und Begleitung von Fach- und Führungskräften mit dem Ziel, deren Fähigkeit zur Lösung komplexer Probleme zu verbessern.

Betreuung von Mitarbeitern durch Experten zur kooperativen Lösung fachlicher und/oder persönlicher Probleme.

Collaboration Tools

Computer-basiertes Werkzeug, das eine Gruppe von Personen bei der Planung, Durchführung und/oder Kontrolle einer gemeinsam zu erledigenden Aufgabe unterstützt. Synonyme: Collaborative Software, Groupware.

Communities of Practice

Freiwillig und spontan gebildete Gemeinschaften von intrinsisch motivierten Fachleuten, die eine bestimmte Frage erörtern oder ein Problem lösen wollen.

Compliance

Einhaltung von Regelwerken, z. B. Gesetze, rechtliche Bestimmungen, vertragliche Vereinbarungen und unternehmensinterne Vorschriften.

Corporate Governance

Gesamtheit der Leitungs-, Kontroll- und Steuerungsmechanismen, Regeln für die Verteilung von Rechten und Pflichten sowie der Rechenschaftspflicht und Haftung in einem Unternehmen.

Co-Working Space

Sie sprießen aus den urbanen Böden wie die Pilze. Gemeinschaftsbüros, in denen Einzelunternehmer und Startups sich mit Gleichgesinnten vernetzen und miteinander kooperieren. Das Credo: Less isolation, more fun and collaboration.

CRM

Customer Relationship Management

Crowd-Innovation

Unternehmen setzen bei Innovation zunehmend auf externes Know-how - da redet dann etwa bei der Produktentwicklung der Kunde mit. Für das Unternehmen ist das quasi Marktrecherche und Produkttest in einem. Interessant: Solche Crowd-Innovatoren wollen zunehmend entlohnt oder erfolgsbeteiligt werden. Entsteht da eine neue Ebene der Mitarbeiterschaft?

Crowdsourcing

Auslagerung von Arbeits- und Kreativprozessen an unternehmensfremde Personen wie Kunden oder Liefer-anten, im Extremfall an die Masse der Internetnutzer.

D

Daily Scrum

Kurzes, tägliches Status-Meeting innerhalb einer 15-minütigen Time-Box, in dem die Team Members einander berichten, was sie seit dem letzten Daily Scrum getan haben, was sie bis zum folgenden Daily Scrum erreichen wollen und was sie bei ihrer Arbeit behindert hat (Impediments). Der ScrumMaster ergänzt seine Blocks List um die genannten Impediments und versucht, diese für das Team zu aus dem Weg zu räumen.

Daily Scrum Meeting

Nachdem ein Sprint begonnen hat, treffen sich das Team und der Scrum Master täglich zum Daily Scrum Meeting.

Das informelle Planungsmeeting dauert maximal 15 Minuten. Es wird oft im Stehen abgehalten, um es kurz zu halten. In dem Meeting hat jedes Teammitglied die Aufgabe, drei Fragen zu beantworten:

Was habe ich gestern getan, um das Sprintziel zu erreichen?

Was werde ich heute tun, um es zu erreichen?

Gibt es ein Problem, welches mich davon abhält, meine Aufgabe zu realisieren?

Daily Stand-up: siehe Stand-up

Data Mining

Sammelbezeichnung für Verfahren der Statistik, der Künstlichen Intelligenz und der Mustererkennung, mit denen domänenunabhängig in strukturierten Datenbeständen nach bisher unbekannten Zusammenhängen (Mustern) gesucht werden kann.

Data Warehouse

Datenbank, in die Daten aus verschiedenen Quellen in einem einheitlichen Format mit dem Ziel gespeichert werden, sie analytisch auszuwerten, wobei die Daten über Fortschreibungsregeln (ETL).

Daten

(engl.: data) Zuordnungen von Zeichen(folgen) zu Objekten und Sachverhalten der Wirklichkeit, die maschinell verarbeitbar sind und die zu Information werden können.

Datenmodell

(engl.: data model) Beschreibung des Inhalts, der Struktur und der Bedeutung von Daten, beispielsweise mit der Entity-Relationship-Notation.

Datenqualität

(engl.: data quality) Gesamtheit der Merkmale von Daten bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.

Datensystem

(engl.: data system) Abbildung der Wirklichkeit in Daten für die Aufgaben eines Unternehmens.

DBMS

Database Management System; Datenbankmanagementsystem. Synonym: Datenbankverwaltungssystem.

Definition

Sprachlich präzise Beschreibung von Objekten mit dem Zweck, den mit dem

Begriff gemeinten Sinn verständlich zu erfassen und in gleicher Weise zu verwenden. Eine Definition ist Nominal- oder Realdefinition.

Design Thinking

Ein Designansatz, bei dem durch Studium der Bedürfnisse der Endanwender versucht wird, bessere Designideen zu generieren, und deren Qualität mittels Prototypen zu validieren.

Deskriptor

Größe, mit der ein Einflussfaktor wertneutral zur Kennzeichnung des Istzustands und des zukünftigen Zustands einer Entwicklung beschrieben wird.

Dialektik

Schlüssige Darstellung kontrovers diskutierter Themen durch These und Antithese mit anschließender Synthese (Konklusion).

Dienstleistung

(engl.: service) Selbstständige, marktfähige Leistung, die mit der Bereitstellung und/oder Verwendung von vorhandenen Fähigkeiten verbunden ist, deren Erstellung interne und externe Faktoren mit dem Ziel kombiniert, an Menschen und/oder Objekten eine Nutzen stiftende Wirkung zu erreichen.

Dienstleistungsqualität

(engl.: service quality) Übereinstimmung von definierten Anforderungen für Eigenschaften von Dienstleistungen mit den tatsächlich realisierten Anforderungen. Synonym: Servicequalität.

Disruption

Nahezu jede Branche, jede Sparte wird in Zukunft von disruptiven Geschäftsmodellen aufgewirbelt und sogar zum Teil zerstört werden. Überall kann ein Uber, ein Airbnb oder ein Tesla lauern. Credo, um in der neuen Arbeitswelt muss daher sein: Zerstöre dich selbst, bevor es ein anderer tut. Auch wenn viele Manager und vor allem Eigentümer das nicht so gern lesen.

Done

Eine Aufgabe gilt dann als fertiggestellt („Done“), wenn sie gemäß den geltenden, gemeinsam vereinbarten Standards implementiert, getestet und dokumentiert ist. Wenn im Daily Scrum jemand einen Task als erledigt meldet oder im Sprint Review Meeting jemand eine Funktionalität vorführt, muss sie gemäß Konvention den Anforderungen an „Done“ genügen.

Drag Factor

Sonderfall eines Adjustment Factors, der angibt, in welchem Maße

beispielsweise der Grad der Erfahrenheit eines Mitarbeiters oder der Grad der Vertrautheit mit dem Scrum-Prozeß oder einer neuen Technologie normale Aufwands-Schätzwerte nach oben treibt (to drag = verschleppen).

Durchlaufzeit

(engl.: cycle time, lead time) Zeit, die ein Objekt zum Durchlaufen eines Systems benötigt (z. B. Zeit zwischen Auftragseingang und –erfüllung); setzt sich zusammen aus Bearbeitungs-, Rüst-, Warte- und Transportzeiten.

Dynamik

Systeme, die über Rückkopplungsmechanismen verfügen, weisen oft Verzögerungseffekte und Nichtlinearitäten des Verhaltens auf. Unser Denkapparat kann nur beschränkt mit nichtlinearen und verzögerten Dynamiken umgehen. Während wir beispielsweise die Falllinie eines Balls relativ gut vorhersagen können, sind wir mit dem Verständnis von komplexen Dynamiken wie z. B. Wetterphänomenen und Börsenkursen oft überfordert, was zu falschen Prognosen führen kann. Visuelle Darstellungstechniken sowie Computersimulationen erlauben es, Zusammen-hänge zwischen dynamischen Variablen zu erfassen und kontraintuitive Effekte besser nachzuvollziehen. (→ Forrester; Vester; Dörner)

E

Eigenvektormethode

(engl.: eigenvector method) Mathematisches Verfahren zur Berechnung der Gewichtungsvek-toren auf Basis von Paarvergleichsmatrizen.

Einsatzplan

(engl.: initiative guide, plan of action) Teilplan des Notfallplans, der die im Notfall sofort zu ergreifenden Maßnahmen beschreibt.

Einsatzstrategie

(engl.: operational strategy) Teilstrategie, die beschreibt, in welche Geschäftsfelder, betrieblichen Aufgaben bzw. Geschäftsprozesse mit welcher zeitlichen Priorität und mit welchen Budgets (Investitionshöhe) wann investiert werden soll.

Emergenz

Wenn Elemente zusammenwirken, können auf der Ebene der Gesamtheit der

Elemente unerwartete und qualitativ neue Eigenschaften auftreten. Emergente Phänomene können bei-spielsweise neue Prozesse, Muster und Strukturen sein. In Organisationen treten ständig kleinere und größere emergente Phänomene auf, beispielsweise wenn in einem beiläufigen Pausengespräch Ideen für neue Prozessabläufe entstehen. Übermäßige Top-Down Steuerung blockiert emergente Phänomene zeitweise. Es ist die Aufgabe von Führung, vielversprechende spontane Phänomene zu identifizieren und diesen den nötigen Raum zu verschaffen. (→ Bunge; Holland)

Empathy Maps

Werkzeug, um sich in eine Rolle oder Persona hineinzudenken, und dadurch neue Erkennt-nisse zu gewinnen.

Employer Branding

Employer Branding meint alle Aktivitäten oder auch deren Ergebnis um eine Unternehmung als attraktiven Arbeitgeber zu platzieren, quasi als „Arbeitgebermarke“ aufzubauen.

Entgrenzung

Philosophisch gesehen führt die Entgrenzung zum Gefühl der Unsicherheit und Instabilität. Sicher mit ein Grund, warum der Ruf nach starken Männern wieder lauter wird und diese auch wieder an die Macht kommen. Die Grenzen schwinden - zwischen Ländern durch die Globalisierung, zwischen Unternehmenssparten, weil neue Hybridkonzepte entstehen und zwischen Arbeit und Freizeit, wie es eben auch Bleisure beschreibt. Menschen arbeiten in der

Wissensgesellschaft zunehmend, wann und wo sie wollen - mobil, im Büro, im Home Office. Und sie arbeiten an kleineren, befristeten Projekten. Auch die Rolle der Mitarbeiter wird ent-grenzt: Man hat nicht mehr nur mehr eine Funktion inne, sondern mehrere projektbezogene Aufgaben. Das kann sogar bedeuten, dass man im Projekt A einfacher Mitarbeiter ist, parallel im Projekt B aber Projektverantwortung hat.

Entscheidungsregel

(engl.: decision rule) Vorschrift, die für eine Entscheidungssituation angibt, wie eine Menge von Zielwerten für eine Menge von Handlungsalternativen zum Gesamtnutzen aggregiert wird. Synonym: Aggregationsfunktion.

Entwicklungsgespräch

Auch Mitarbeitergespräch genannt, ist ein Gespräch zwischen Mitarbeiter und Führungskraft, das regelmäßig in größeren Abständen (vielleicht zweimal pro Jahr) stattfinden sollte. Dort geben sich beide Feedback zur zurückliegenden Arbeit, reflektieren die Zusammenarbeit, sprechen über die weitere Entwicklung des Mitarbeiters und vereinbaren die Zielrichtung und Maßnahmen zur weiteren Entwicklung des Mitarbeiters.

Entwicklungsrückstau

(engl.: application backlog) Nicht abgearbeitete Aufgaben der Systementwicklung, deren Erledigung die Anforderungen der Geschäftsprozesse erfordern. Synonym: Anwendungsrückstau.

Entwicklungsteam

Ein Scrum Team sollte zwischen fünf und zehn Mitglieder umfassen, die alle Aufgaben selbst organisieren. Innerhalb des Teams gibt es keine Hierarchie. Im Hinblick auf die Rechte und Pflichten unterscheiden sich die Teammitglieder nicht, lediglich in Bezug auf die Kompetenzen und die dazugehörigen Zuständigkeiten.

Entwurfsmuster

(engl.: design pattern) wieder verwendbare Vorlage zur Lösung eines Entwurfsproblems, die in einem spezifischen Kontext genutzt werden kann.

EPK

(engl.: event-driven process chain) ereignisgesteuerte Prozesskette; Modellierungssprache für Geschäftsprozesse.

Ereignis

(engl.: event) Geschehnis, Vorkommen oder Begebenheit, das bzw. die zeitpunktbezogen ist.

Ereignisaufzeichnung

(engl.: event logging) Erfassung sämtlicher oder definierter Ereignisse während eines Verarbeitungs-vorgangs in einer Log-Datei unter der Steuerung des Abrechnungssystems.

Erfolgsfaktor

(engl.: success factor) Eigenschaft eines Objekts (hier der IT), deren positive Ausprägung zur Schaffung und Sicherung von Unternehmenserfolg beiträgt.

Erfolgspotential

(engl.: success potential) durch Art und Umfang verwendeter Technologien bestimmte Fähigkeit der Informationsinfrastruktur, Leistungspotenzial der Informationsfunktion in Unternehmenserfolg umzusetzen.

Erkenntnisobjekt

(engl.: scientific object) aus dem weiteren Erfahrungsobjekt, hier Betrieb oder Unternehmen, durch gedankliche Konstruktion gewonnener engerer Gegenstand, der Forschungs- oder Gestaltungsgegenstand ist.

Estimated Work Remaining

Anzahl von Stunden, Function Points o.ä., die gemäß Schätzung noch übrig bleiben, um einen Task oder ein Requirement abzuschließen.

Estimation Game

Beginn des Estimation Games

Alle geschätzten User Stories liegen als Stapel von einzelnen Story Cards vor. Jemand aus dem Team nimmt sich die oberste Story und liest sie laut vor. Gibt es Verständnisschwierig-keiten, kann er Rückfragen zu dieser Story stellen. Dann legt er sie auf den Tisch.

Das nächste Teammitglied zieht eine weitere Story Card aus dem Stapel. Es liest sie laut vor und kann ggf. Rückfragen stellen. Nun muss sich das Teammitglied überlegen, wie komplex die Story im Vergleich zur bereits auf dem Tisch liegenden Story ist:

Schätzt es die Story genauso komplex wie die erste ein, legt es diese daneben.

Schätzt es die Story weniger komplex als die bereits liegende ein, legt es die Karte unter-halb der bereits liegenden Story.

Schätzt es die Story komplexer als die bereits liegende Story ein, legt es die Story Card über die liegende Karte.

Neue Optionen ab der dritten Karte

Jedes Teammitglied hat, sobald die ersten zwei Karten eingeordnet wurden, die Wahl zwischen drei Optionen:

Es nimmt eine neue Anforderung und ordnet diese ein (wie oben beschrieben).

Es nimmt eine Verschiebung in der Reihenfolge der bisher eingeordneten Items vor. Dies erfolgt immer mit Begründung.

Es setzt eine Runde aus.

Zuordnung zu StoryPoints

Wenn alle Backlog Items in eine Reihenfolge gebracht wurden, werden die Karten eines Planning Poker-Sets zugeteilt und Cluster gebildet.

Das Estimation Game ist dann zu Ende, wenn die Timebox abgelaufen ist oder wenn das Team mit der Zuordnung der Backlog Items zu den StoryPoints zufrieden ist.

Magic Estimation

Ein spezielles Verfahren, bei dem die direkte Kommunikation zwischen den Teammitgliedern bewusst ausgeschaltet wird. Es wurde entwickelt für die Beschätzung von großen Mengen an Backlog Items in kurzer Zeit.

Jedes Teammitglied nimmt eine individuelle Schätzung vor und platziert die Backlog Items bei den Story Points.

Sobald es selbst alle Stories ausgelegt hat, überprüft das Teammitglied die Schätzungen der anderen und nimmt, falls erforderlich, Korrekturen vor.

Der Product Owner markiert die sogenannten „Fall-Outs“, die eine Nachbereitung benötigen, da sie entweder zu groß sind oder keine klare Zuordnung finden. Das ist für den Product Owner ersichtlich, wenn sie immer wieder hin und her geschoben werden.

Diese Fall-Outs werden dann gesondert durchgesprochen und eine Einigung über die Be-schätzung angestrebt (eine Option ist es, hierfür dann wieder ein Planning Poker einzusetzen).

Rahmenbedingungen für die Schätzung

Alle zu beschätzenden Items liegen vor (auf handschriflichen StoryCards oder z.B. als JIRA-Ausdrucke mit Hilfe des AgileCards-Plugins)

Das gesamte Team inklusive Product Owner ist anwesend.

Die Regeln der Schätzung sind allen bekannt und hängen möglichst noch einmal im Raum aus. Vorteile dieses Vorgehens bei der Schätzung:

Schnelle Schätzungen, die trotzdem eine hohe Treffgenauigkeit aufweisen.

Es schätzt immer das Team, dass sich später um die Umsetzung kümmert. Dadurch werden keine Schätzungen „vorgesetzt“, die für das Umsetzungsteam unrealistisch sind.

Schätzungen bereiten keine Bauchschmerzen mehr, sondern werden zu etwas „spaßigem“.

Berücksichtigung der Komplexität der Umsetzung. inspect&adapt, das Team wird immer besser in den Schätzungen.

Evaluierung

(engl.: evaluation) zielbezogene Beurteilung von Objekten auf Grundlage eines Systems von relevanten Eigenschaften (Evaluierungskriterien). Synonym: Evaluation.

Evaluierungkriterium

(engl.: evaluation criterion) Eigenschaft des Evaluierungsobjekts, die unter Berücksichtigung des Evaluierungsziels aus diesem abgeleitet und mit der im Einzelnen festgelegt wird, was zu evaluieren ist.

Evaluierungsprojekt

(engl.: evaluation object) beliebiges Objekt, für das ein Evaluierungsbedarf besteht und das zur Evaluierung vorgegeben ist

Evaluierungsziel

(engl.: evaluation objective) Aussage darüber, welche Information der Auftraggeber einer Evaluierungsstudie erwartet bzw. der Evaluator erarbeiten soll.

Extrem-Szenario

(engl.: extreme scenario) Szenario, das am Rand des Szenario-Trichters liegt.

Extremalkriterium

(engl.: unlimited criterion) Kriterium, das hinsichtlich des Ausmaßes der Zielerreichung unbegrenzt (maximal oder minimal) formuliert

F

Fehler

(engl.: defect) Abweichung von einer Anforderung.

Festpreis

Abrechnungsart für eine Leistung, bei der die Höhe der Vergütung vorab vereinbart wird. Gegensatz dazu ist die Abrechnung nach tatsächlichem Aufwand.

Formalziel

(engl.: goal) Ziel, dessen Zielinhalt die Qualität oder Güte beschreibt, mit der ein Sachziel verfolgt werden soll (wie soll ein Zweck erreicht werden?).

Fragebogenmethode

(engl.: questionnaire technique) schriftliche Form der Befragung mit einer geordneten Menge von offenen oder geschlossenen Fragen.

Fragmentierung

Das bezeichnet die Zergliederung der Arbeitsschritte, die dann zum Teil outgesourced oder automatisiert werden.

Freemium

Ein Prinzip zum Absatz von Produkten, bei denen der Grundumfang kostenlos beziehbar ist (free), aber mit Zusatzfunktionen zum Update auf ein kostenpflichtiges Premiummodell verführt werden soll.

Führung

(engl.: leadership, management)

im Sinne von Unternehmensführung die zweck- und zielorientierte Koordination arbeitsteiliger Prozesse, im Sinne von Personalführung die Bildung, Durchsetzung und Sicherung eines Führungswillens und die Motivation der Mitarbeiter.

Aufgaben der zweck- und zielorientierten Harmonisierung des arbeitsteiligen sozialen Systems Organisation, um die Erfüllung der Organisationsziele zu sichern.

Führungsaufgabe

(engl.: management task) betriebliche Aufgabe, die der Entwicklung, Gestaltung und Lenkung eines Unternehmens, seiner Teileinheiten oder Teilbereiche (z. B. IT-Bereich) oder Struktureinheiten (z. B. IT-Abteilung) dient.

Functional Requirement

Funktionale Anforderung im Product Backlog. Siehe Requirement.

G

Ganzheitlichkeit

(engl.: completeness) Analyse, Beschreibung und Erklärung eines Objekts in seiner Ganzheit mit dem Zweck einer weit vorausschauenden Beachtung aller Aspekte seiner Struktur (abgeleitet vom Abstraktum Ganzheit des Adjektivs ganz).

Gatekeeping

Prozess zum Kontrollieren eines Informationsflusses, um sich einen persönlichen Vorteil, in der Regel auf Kosten anderer, zu verschaffen.

Gefahr

(engl.: threat) Einflussfaktor, welcher sicherheitsrelevante Elemente beeinträchtigen und Schäden verursachen kann.

Gegenstandbereich

(engl.: subject area) in einer Realwissenschaft der Ausschnitt der Wirklichkeit,

dessen Phänomene untersucht werden.

Genossenschaft

Ein altes Modell erlebt eine Renaissance: Einzelunternehmer schließen sich zur Genossenschaft zusammen, arbeiten als Angestellte, entscheiden autark (bzw. Vorstands- oder Steuerungsteams entscheiden). In der Berliner Agentur Dark Horse arbeiten und entscheiden etwa 30 Personen gleichberechtigt.

Geschäftsarchitektur

(engl.: business architecture) Modell der Organisation eines Unternehmens, der wesentlichen Komponenten, Ressourcen und deren Beziehungen sowie der Austauschbeziehungen des Unternehmens mit seiner Umwelt.

Geschäftsmodell

(engl.: business model) Modell, das Aussagen darüber macht, durch welche Kombination von Produktionsfaktoren die Unternehmensstrategie verfolgt wird, wie Erlöse erzielt werden und welche Rolle die daran beteiligten Akteure spielen.

Geschäftsprozess

(engl.: business process) Abfolge von zeitlich und sachlich zusammenhängenden

Tätigkeiten zur Erstellung eines betriebswirtschaftlich relevanten Ergebnisses.

Gewerk

Der Begriff „Gewerk“ charakterisiert eine Art von vertraglich geschuldeten Leistungen, z. B. von einem Dienstleister. Beim Gewerk ist immer der Erfolg geschuldet, d. h. das fertige Werk. Der Gegensatz dazu ist die Dienstleistung. Hier wird nur die Bemühung geschuldet, nicht das Ergebnis. Beides ist streng zu unterscheiden von der Abrechnungsart, z. B. als Festpreis. So gibt es Dienstleistungsverträge, die zum Festpreis abgerechnet werden, und Gewerke, die nach Aufwand abgerechnet werden.

Gliederungszahl

(engl.: constructional figure) Verhältniszahl, mit der ein Teil einer statistischen Masse zur Gesamtmasse in Beziehung gesetzt wird.

GPM

Geschäftprozessmanagement.

Green IT

Bezeichnung für das Bestreben, IuK-Technologien über den gesamten Lebenszyklus hinweg umwelt- und ressourcenschonend zu gestalten und zu

nutzen.

Gremium

(engl.: commitee) aus mehreren Personen über einen längeren Zeitraum bestehende Struktureinheit zur Bearbeitung bestimmter Aufgaben.

Grenzkosten

(engl.: marginal costs) Kosten, die durch Veränderung der Beschäftigung um eine Produktionseinheit zusätzlich entstehen bzw. entfallen.

Grundbegriff

(engl.: basic term) Begriff, der zur Definition weiterer, abgeleiteter Begriffe verwendet wird. Synonyme: Basisbegriff, Elementarbegriff.

Grundsatz

(engl.: principle) Regel, Richtlinie oder Richtschnur für Denken, Handeln und/oder Verhalten; eine empfehlenswerte, in der Praxis bewährte Handlungsanweisung. Synonym: Prinzip.

Grundschutz

(engl.: baseline protection) Methode zur Entwicklung von Sicherheitskonzepten, bei der Sicherungsmaßnahmen anzuwenden sind, die für einen normalen Schutzbedarf als angemessen und ausreichend betrachtet werden.

Grundschutzmaßnahmen

(engl.: baseline controls) Mindestumfang von Maßnahmen zur Sicherung einer Informationsinfrastruktur mit einem normalen Schutzbedarf

H

Hallway-Test

Bei einem Hallway-Test versucht man auf zufällige „auf dem Gang vorbeigehende“ Personen zuzugreifen, um diese etwas ausprobieren zu lassen.

Handlungsspielraum

(engl.: action scope) mehrdimensionaler Begriff, der Entscheidungsspielraum, Tätigkeitsspielraum und Freiheitsspielraum umfasst.

Hierarchie

(engl.: hierarchy) ein System von Elementen, die einander über- bzw. untergeordnet sind und somit einer Ordnungsrelation unterliegen.

Holacracy:

Wer braucht schon einen Chef? Der Ansatz Holacracy (Holakratie) von Brian J. Robertson macht jeden einzelnen Mitarbeiter zur Führungskraft und schafft Hierarchien de facto ab. Die Unternehmensorganisation wird über

selbstorganisierte Teams gesteuert, die Entscheidungen werden mehr oder weniger basisdemokratisch und lokal (alle Stimmen zählen, Gremien entscheiden etc.) getroffen. Arbeitsprozesse und Organisationsstruktur unterliegen einem ständigen Update. Alle Regeln und Bestimmungen sind transparent für alle sichtbar. Robertson ist nicht nur Management-Vordenker, sondern hat Holacracy auch in seinem Software-Unternehmen umgesetzt. Ein Beispiel für erfolgreich umgesetzte Holakratie ist die US-Firma Zappos, die deutsche Firma Hauffe-Umantis oder der Wiener Technik-Dienstleister Tele Haase.

Human Resources (HR)

Auch als „Personalabteilung“ bekannt ist die Abteilung einer Unternehmung, die sich um die Mitarbeiter im Großen kümmert. Zu den Aufgabenbereichen sollten zählen: Employer Branding, Recruiting, Mitarbeiter-betreuung sowohl administrativ als auch inhaltlich, Eskalations- und Vertrauensinstanz bei Problemen zwischen Mitarbeiter und Führungskraft, Mitarbeiter-entwicklung (Weiterbildung, Entwicklungsmodelle und -möglichkeiten), Entwicklung der Aufbauorganisation, Firmenkultur und evtl. interne Kommunikation.

Humanvermögen

(engl.: human resource) auf Erziehung, Ausbildung, Erfahrung usw. beruhendes, für den Unternehmenserfolg relevantes Leistungsvermögen der Mitarbeiter (Arbeitsvermögen). Synonym: Humankapital.

I

ICANN

Internet Corporation for Assigned Names and Numbers; Non-ProfitOrganisation mit Sitz in Kalifornien, koordiniert die Vergabe von Namen und Adressen im Internet.

Impediment

Projekt-Hemmnis, welches das Vorankommen des Teams behindert, z.B. fehlende Software-Lizenzen, kranke Ansprechpartner ohne Stellvertreter, zu hohe Beanspruchung eines Entwicklers durch Kundensupport, langsamer PC, Nichtverfügbarkeit des Mainframes für Tests an Samstagen etc. Impediments werden beim Daily Scrum vom Team genannt, damit der ScrumMaster sich um ihre Beseitigung kümmern kann.

Increment

Produktfuntionalität, welche während eines Sprints vom Team entwickelt wird

Increment of Potentially Shippable Functionality

Beschreibt die Grundanforderung an ein Increment: Was immer sich das Team als Sprint Goal setzt und dann am Ende des Sprints abliefert, soll potenziell auslieferbare und in sich abgeschlossene Funktionalität bieten, so daß der Product Owner die Option wahrnehmen kann, das Increment innerhalb eines Zwischen-Sprints produktiv setzen zu lassen.

Indexzahl

(engl.: index figure) Verhältniszahl, mit der gleichartige und selbständige statistische Massen zueinander in Beziehung gesetzt werden; durch Indexzahlen bestimmte Größen können zu Reihen zusammengefasst und Veränderungen der Reihen durch Bezug auf eine gemeinsame Basis verglichen werden.

Information

Information ist gemäß Bateson «ein Unterschied, der einen Unterschied macht». Nur ein Bruchteil dessen, was in der Außenwelt geschieht, wird aufgrund der begrenzten Verarbeitungskapazität von einem Akteur auch registriert. Systeme müssen daher selektiv entscheiden, welche Signale gezielt aufgenommen sowie verstärkt werden – und was als unerwünschtes Rauschen ausgeblendet und in den Hintergrund gerückt wird. Jede Führungsperson entwickelt ihre eigenen Filter, z. B. welchen Fach-informationen, News und Kritiken nachgegangen und was ausgefiltert wird. (→ Shannon; Bateson)

Information Engineering

Entwicklung und Anwendung von Methoden und Werkzeugen zur Unterstützung

der Erfüllung der Aufgaben des Informationsmanagements.

Methodik des Informationsmanagements im Sinne einer Lehre von den Methoden und ihrer planmäßigen, wissenschaftlichen Anwendung.

Information Radiator Möglichst öffentlichkeitswirksame Mittel, um Informationen zum Status des Projekts zugänglich und transparent zu machen, z.B.

Großbildschirm mit aktuellen Infos im Foyer

Burndown Chart am Schwarzen Brett

gut gepflegtes Projekt-Wiki

Info-Mails.

Information Retrieval

Informations(wieder)gewinnung; Methoden zur Speicherung und Repräsentation sowie zum Zugriff auf unstrukturierte Daten.

Informationsverhalten

Auf Information gerichtetes Tun oder Unterlassen von Personen oder Personengruppen.

Information Systems Disciplines

Vor allem im angelsächsischen Sprachraum etablierte Wissenschaft mit einem der Wirtschaftsinformatik gleichen Gegenstandsbereich, aber mit einer teilweise unterschiedlichen Forschungskonzeption (Primat der Erklärungsaufgabe).

Informationelles Gleichgewicht

(engl.: informational balance) Schnittmenge von Informationsnachfrage und Informationsangebot. Synonym: Informationsstand.

Informationsaufnahme

(engl.: information reception) Registrierung von Reizen über Zustände und Vorgänge durch Sinnesorgane mit der Folge der Erweiterung des Wissensbestands.

Informationsbedarf

(engl.: information requirement) Art, Qualität und Menge der Information, welche Aufgabenträger zur Erfüllung einer bestimmten Aufgabe benötigen.

Informationsbedarfsanalyse

(engl.: information needs assessment) Erfassen, Strukturieren und Beurteilen des Informationsbedarfs.

Informationsbedürfnis

(engl.: information need) von einem Aufgabenträger zur Erfüllung einer Aufgabe für erforderlich gehaltene Information. Synonym: subjektiver Informationsbedarf.

Informationsdefizit

(engl.: information deficit) tatsächlicher oder wahrgenommener Mangel an Information.

Informationsfunktion

(engl.: information function) Teilmenge des betrieblichen Aufgabensystems, dessen Zwecke Information und Kommunikation sind.

Informationsinfrastruktur

(engl.: informations infrastructure) Einrichtungen, Mittel und Maßnahmen zur Beschaffung, Verteilung und Nutzung von Information und Ermöglichung von Kommunikation.

Informationsnachfrage

(engl.: information demand) von einem Aufgabenträger geltend gemachter Bedarf an Information.

Informationsrecht

(engl.: information law) Rechtsvorschriften und Rechtsprechung im Zusammenhang mit der rechtlichen Beurteilung von Tatbeständen, die für die Wirtschafts-informatik relevant sind.

Informationssystemarchitektur

(engl.: information systems architecture) Modell der informationstechnischen Infrastruktur, der Daten und Anwendungsprogramme, der von dem Informationssystem unterstützten Aufgaben sowie der dazu benötigten Aufbauund Ablauforganisation des entsprechenden Unternehmensteils.

Informationssystemplan

(engl.: information system plan) Teil des strategischen IT-Plans, der die Absichten zur Veränderung bestehender und zur Schaffung neuer Informationssysteme beschreibt.

Informationsüberlastung

(engl.: information overload) Zustand eines Aufgabenträgers, in dem eine weitere Erhöhung des Informationsangebots zu einer Verschlechterung der Wahrnehmung eines Objektes führt, welches durch die Information beschrieben wird.

Informed

Der Informationsempfänger soll über einen Status, Fortschritt oder ein Ergebnis im Prozess informiert werden. Er hat demzufolge ein Informationsrecht und muss über den Verlauf oder das Ergebnis durch den Responsible informiert werden (=Informationspflicht für R).

Initial Estimate

Ursprünglicher Schätzwert im Product Backlog ohne Berücksichtigung von Adjustment Factors.

Inkrementell

(engl.: incremental) Schrittweise.

Innovation

Auf neuen Erkenntnissen beruhende Schaffung oder Änderung eines Systems, die zu neuartigen wirtschaftlichen Realisierungen führt.

Innovationspotenzial

(engl.: potential for innovation) Voraussetzungen und Mittel, die Innovationsfähigkeit und Innovations-bereitschaft gewährleisten, wie Teamfähigkeit, Motivation, Kooperation, Organisationsentwicklung oder Mitarbeiter-führung.

Insourcing

Bezug von Leistungen von einem unternehmensinternen Anbieter, der sich in einem von Marktmechanismen geprägten Auswahlverfahren gegen externe Anbieter durchsetzen konnte.

Integration

In verschiedenen Wissenschaftsdisziplinen verbreiteter, meist unterschiedlich

definierter Begriff, in der Terminologie der Wirtschaftsinformatik eine spezifische Form der Verknüpfung von Elementen zum Ganzen eines Systems.

Interdepenzanalyse

(engl.: interdepence analysis) Untersuchung der Beziehungen zwischen zwei Objektmengen, um deren gegenseitige Beeinflussung festzustellen.

Intrapersonelles Informationsverhalten

(engl.: intrapersonal information behavior) Mentaler, in einer Person ablaufender Prozess und daraus resultierende Verhaltensformen in Bezug auf Information.

Investment Center

Ergebnisverantwortliche Struktureinheit, deren Leistungen marktfähig sind und die über IT-Investitionen entscheiden kann.

Istzustand

(engl.: current system) Gesamtheit der technischen, organisatorischen, personellen, sozialen und rechtlichen Bedingungen und Regelungen eines bestehenden Systems.

IT-Abteilung

(engl.: IT department) Struktureinheit, der administrative und operative Aufgaben des Informationsmanagements zugeordnet sind und die als Kostenstelle, Profit Center oder Investment Center geführt wird.

IT-Dienstleister

(engl.: IT service provider) Struktureinheit, die IT-Dienstleistungen für unternehmensinterne oder –externe Kunden erbringt.

IT-Dienstleistung

(engl.: IT-Service) Dienstleistung im IT-Bereich, die für einen oder mehrere unternehmensinterne oder -externe Kunden erbracht wird. Synonym: IT-Service.

IT-Governance

Teil der Corporate Governance, der auf die IT bezogen ist.

IT-Grundschutzkatalog

(engl.: baseline catalogues) Publikation des BSI mit Beschreibungen von

Sicherheitsgefährdungen und Empfehlungen zu Maßnahmen, die ein Mindestmaß an Sicherheit gewährleisten sollen.

IT-Servicemanagementsystem

(engl.: IT service management system) Gesamtheit der Hilfsmittel zur Realisierung des IT-Servicemanagements.

IT-Verbund

(engl.: information processing facility/ies) Gesamtheit der infrastrukturellen, organisatorischen, personellen und technischen Komponenten, die der Aufgabenerfüllung in einem bestimmten Anwendungsbereich der IT dienen.

Iterativ

Eine bestimmte Folge von Aktivitäten wiederholend.

J

Job Rotation

Systematischer und regelmäßiger Wechsel von Arbeitsplatz und Aufgaben.

Jukebox

Speichersystem für optische und magneto-optische Speichermedien.

K

Kanban

Das japanische Wort Kanban setzt sich zusammen aus kan (= ‚Signal‘) und ban (=‚Karte‘), bedeutet demnach ‚Signalkarte‘. Es ist eine Technik aus dem ToyotaProduktionssystem, die für eine Minimierung der parallel durchgeführten Arbeiten (Work in Progress) und damit für einen gleichmäßigen Fluss (Flow) der Arbeit sorgt.

Was ist Kanban?

Kanban in der IT ist ein Vorgehen, das bei der Softwareentwicklung die Anzahl paralleler Arbeiten, den Work in Progress (WiP), reduziert und somit schnellere Durchlaufzeiten erreicht. Probleme, wie etwa Ressourcen-Engpässe oder Blocker in der Softwareentwicklung werden schnell sichtbar und können beseitigt werden. Kanban als Gesamtkonzept für die IT hat als erster David Anderson übertragen und in seinem Buch „Kanban – Evolutionäres Change Management für IT-Organisationen“.

Kanban zeichnet sich durch drei Grundprinzipien und fünf Kerneigenschaften aus.

Die drei Grundprinzipien

Beginne dort, wo du dich im Moment befindest.

Komme mit anderen überein, dass inkrementelle, evolutionäre Veränderungen angestrebt werden.

Respektiere den bestehenden Prozess sowie die existierenden Rollen, Verantwortlichkeiten und Berufsbezeichnungen.

Damit setzt sich Kanban u.a. deutlich von Scrum ab, dass bereits bei der initialen Einführung diverse Veränderungen fordert, wie etwa die neuen Rollen.

Die fünf Kerneigenschaften

Visualisiere den Fluss der Arbeit (Workflow).

Begrenze den Work in Progress (Menge an begonnener Arbeit).

Führe Messungen zum Fluss durch und kontrolliere ihn.

Mache die Regeln für den Prozess explizit.

Verwende Modelle, um Chancen für Verbesserungen zu erkennen.

Arbeit visualisieren und den Fluss sicherstellen.

Das zentrale Hilfsmittel für die Visualisierung von Arbeit ist ein Kanban Board.

Erklärungen und Beispiele zu Kanban Boards:

Kanban Board

Kanban als Change Management-Ansatz

Kanban ist als Change Management-Ansatz zu verstehen, der auf das bestehende Vorgehen der betroffenen Teams aufbaut und inkrementelle Veränderungen durchzuführen.

Dies verdeutlicht, dass Kanban als solches nicht als Projektmanagement- oder Softwareentwicklungs-Methode zu verstehen ist.

David Anderson betont die Bedeutung der individuellen Anpassung von Methoden und Praktiken auf die individuellen Rahmenbedingungen in den Teams. Kanban soll den Teams dabei helfen zu erkennen, welcher Prozess und welche Praktiken wirklich zu mehr Erfolg verhelfen.

Unterschiede zu Scrum

Ein wesentlicher Unterschied zu Scrum ist, dass Kanban keine Vorgabe über die Rollen und Meetings macht. Weiterhin gibt es keinen im Vorhinein festgelegten Umfang für ein Release. Vielmehr wird immer an nur einer kleinen Auswahl der wichtigsten Aufgaben gearbeitet. Es kann dennoch mit festen ReleaseZeitpunkten gearbeitet werden. Es werden dann immer nur die Anforderungen, die zum Stichtag vollständig umgesetzt sind, in das Release aufgenommen.

Austausch zu Kanban - Die Limited WIP Society

Da Kanban zu sehr individuellen Prozessen und Praktiken in Unternehmen führen kann, besteht häufig ein Interesse an einem Austausch mit anderen Anwendern.

Kanban: Kanban ist eine agiles Vorgehensmodell in der Softwareentwicklung (streng genommen heißt es Scrumban). Im Unterschied zu Scrum gibt es bei Kanban keine Iterationen, sondern Aufgaben werden kontinuierlich vom Team bearbeitet. Kanban hat das Ziel die Menge gleichzeitig begonnener Arbeit zu begrenzen, Engpässe im Arbeitsfluss sichtbar zu machen und dadurch insgesamt die Durchlaufzeiten von Arbeitspaketen zu verringern.

Kapazität

(engl.: capacity) mengenmäßiges Leistungsvermögen von Betriebsmitteln (z. B. Fassungsvermögen von Speichern).

Kardinale Konsistenz

(engl.: metric consistency) Widerspruchsfreiheit von Aussagen, die sich aus der Konsistenz der metrischen Relationen im Aussagensystem ableitet (z. B. A ist zwei Mal sobedeutsam wie B / B ist zwei Mal so bedeutsam wie C / A ist vier Mal so bedeutsam wie C).

Karrierepfad

Ein Karrierepfad ist eine durch die Unternehmung vorgegebene Abfolge von Titeln, die man bei Beförderungen verliehen bekommt. Ein einfaches Beispiel sind die Abstufungen Junior-, Professional- und Senior-Irgendwas. Ursprünglich sind Karrierepfade als Instrument zur Mitarbeiter-Einschätzung und entwicklung gedacht.

Klassisches Projektmanagement

Mit klassischem Projektmanagement sind hier nicht-agile Methoden des Projektmanagements gemeint, wie Wasserfall-Modelle, ein PMBOK-Ansatz oder vergleichbare Methoden, die vor allem auf viel Vorausplanung setzen und Anpassungen am „Projektplan“ eher als Ausnahme denn als Regel verstehen.

Kennzahl

(engl.: metric) Zahl über Daten mit konzentrierter Aussagekraft zur Planung, Überwachung und Steuerung sowie zur Diagnose eines Systems.

Kennzahlenanalyse

(engl.: metric analysis) systematisches Verfolgen des durch Kennzahlen erkannten Veränderungspotenzials zur Verifizierung und Ursachenerkennung.

Kennzahlensystem

(engl.: metric system) ganzheitlicher Zusammenhang einer Menge von Kennzahlen, die zur Erreichung eines gemeinsamen Zwecks zusammenwirken.

Klickdummy

Weiter ausgearbeiteter Prototyp einer grafischen Oberfläche, der zwar schon bedienbar ist, aber noch keinerlei Geschäftslogik enthält.

Kodifizierung

(engl.: codification) dokumentenbasierte Wissensbewahrung und -verteilung.

Koevolution

Koevolution bezeichnet die Art und Weise, wie sich Akteure in gegenseitigem Bezug entwickeln und ihre Umwelt mitgestalten. Dadurch können neue Nischen

entstehen, welche die Entwicklungen anderer Akteure erst ermöglichen. Beispiele sind Tier- und Pflanzenarten, die sich symbiotisch entwickeln, Kognitive Entwicklung und kulturelle Entwicklung, Zulieferer und Distributoren, die sich in ihrer Entwicklung beeinflussen oder Innovationen bei Hardware und darauf laufender Software. (→ Kauffman; Luhmann).

K.o.-Kriterium

(engl.: decisive factor) ein Kriterium, das eine als unabdingbar angesehene Anforderung mit einem limitierten Zielertrag beschreibt und zur Eliminierung der Alternativen im Bewertungsprozess führt, welche diesen Zielertrag nicht erreichen.

Kollegiale Fallberatung

Die kollegiale Fallberatung ist ein Instrument zur Entwicklung von Mitarbeitern, das insbesondere gut geeignet ist für die Reflektion von Führungsaufgaben. Hierfür kommt eine Gruppe von Mitarbeitern zusammen, die nicht direkt zusammen arbeiten müssen. Einer der Gruppe trägt in einem speziellen Ablauf eine aktuelle Herausforderung aus seiner Arbeitspraxis vor. Die anderen Teilnehmer reflektieren und diskutieren anschließend über den Fall. Die Idee dabei ist es neue Perspektiven auf die Herausforderung zu geben und damit bessere Lösungen zu entwickeln.

Kollektive Intelligenz (Schwarmintelligenz)

Eine große Anzahl durchschnittlicher Individuen kann kollektiv intelligenter sein als eine kleine Anzahl von Spezialisten. In der Biologie sind

Koordinationsleistungen von Ameisenstaaten und Vogelschwärmen bekannte Beispiele. Auf Unternehmen übertragen, bedeutet dies, dass der Einbezug des Wissens unterschiedlichster Personen zu besserer Situationseinschätzung, Prognose und auch innovativen Leistungen beitragen kann. Wenn es jedoch um komplexe Entscheidungen geht, scheinen Entscheidungsgremien mittlerer Größe ein Optimum darzustellen: Sie sind genügend groß, um verschiedene Sichtweisen miteinzubeziehen und genügend klein, um vertieftes gegenseitiges Verständnis noch zu ermöglichen. Große Gruppen können unter Umständen auch zu schlechteren Entscheidungen führen. (→ Page)

Kommunikation

Kommunikation beinhaltet die Auswahl von Information, deren Übermittlung und den Prozess des Verstehens. Da Handeln in sozialen Systemen auf Kommunikation basiert, bergen Kommunikations-Pannen verschiedene Risiken. Durch Metakommunikation, also eine Kommunikation über die Kommunikation, kann der Fokus zeitweise vom Alltagsgeschehen auf den Prozess des Kommunizierens selbst gerichtet werden. (→ Bateson; Watzlawick; Luhmann)

Kompetenz

(engl.: competence) Handlungsspielraum eines Aufgabenträgers, der zur ordnungsgemäßen Aufgabenerfüllung erforderlich ist.

Kompetenzzentrum

(engl.: competence center, center of excellence) unternehmensinterne

Expertengruppe, welche für spezifische Gebiete Wissen entwickelt.

Komplexität

Grad der Überraschung in einem System; Unvorhersehbarkeit des Zusammenhangs zwischen Aktion und Reaktion.

Komponente

(engl.: component) Durch Zerlegung bestimmter Teil eines Ganzen, der selbst wieder zerlegt werden kann.

Konfiguration

(engl.: configuration)

Menge definierter Elemente eines Systems, die zu einem bestimmten Zeitpunkt gemeinsam eine Aufgabe erfüllen sollen und dazu in Wirkungsweise und Schnittstellen aufeinander abgestimmt sind.

Zusammenstellung der Funktionseinheiten eines Systems, die zur Erfüllung einer bestimmten Aufgabe erforderlich sind.

Konsens

Der Konsens ist die gängige demokratische Entscheidungsform. Um eine Entscheidung zu treffen, müssen alle Mitwirkenden sie mittragen. Der Vorteil ist eine breite Unterstützung einer derart getroffenen Entscheidung. Der Nachteil liegt darin, dass eine Entscheidung häufig nur nach sehr langer Diskussion oder mit so weitreichenden Kompromissen getroffen werden kann, dass sie nicht effektiv ist. Eine Alternative ist der Konsensentscheid.

Konsensentscheid

Ein Konsensentscheid erfordert im Gegensatz zum Konsens keine aktive Zustimmung aller Mitwirkenden. Eine Konsensentscheidung gilt als getroffen, wenn alle Mitwirkenden die Entscheidung bejahen oder sich dazu neutral verhalten. Ist man gegen die Entscheidung, kann man ein Veto einlegen, muss dieses jedoch begründen und evtl. eine Alternative vorschlagen. Der Fokus eines Konsens liegt also im Gegensatz zum nicht darauf, möglichst breite Mehrheiten zu erzielen, sondern Einwände konstruktiv zu integrieren. Siehe dazu auch: Verbunden im Konsens – Was ist Soziokratie?

Konsistenz

(engl.: consistency) in der Logik die Widerspruchsfreiheit einer Menge von Aussagen.

Konsumerisierung

(engl.: consumerization) Ausrichtung der IT-Anwendungen an den Bedürfnissen der Benutzer, auch unter Einbeziehung privater Endgeräte. In der Praxis häufig als BYOD (Bring Your Own Device) bezeichnet.

Kontinuierliche Integration

(engl.: continous integration) Kontinuierliche Integration steht für die fortlaufende Neubildung und Tests einer Softwareanwendung. Die Softwareentwickler checken dabei ihren Code sehr regelmäßig in die Versionsverwaltung ein. Dies ist besonders im Rahmen der agilen Softwareentwicklung relevant, wenn Teams sehr eng miteinander arbeiten und häufig gemeinsam die Umsetzung einer User Story vornehmen.

KonTraG

Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (Deutschland); es erweitert die Haftung der Unternehmensleitung und zwingt diese, ein Risikofrüherkennungssystem einzuführen sowie Aussagen zur Risikostruktur des Unternehmens zu publizieren.

Kontrolle

(engl.: inspection) Teil der betrieblichen Aufgabe Überwachung, welcher der Beobachtung des tatsächlichen Verhaltens eines Systems und seiner Beurteilung anhand von Verhaltenserwartungen durch prozessunabhängige Personen dient.

Kontrollierbarkeit

(engl.: checkability) Möglichkeit der Beobachtung des Verhaltens eines Objekts und seiner Beurteilung anhand von Verhaltenserwartungen.

Kooperation

In der Natur sind sowohl Wettbewerb als auch Kooperation zu finden. Die Zusammenarbeit von Akteuren mit unterschiedlichen Eigenschaften kann Vorteile mit sich bringen. Sind Akteure von begrenzten Ressourcen abhängig, kann Kooperation sogar überlebenswichtig für eine Gruppe werden. Lange galt die Annahme, dass sich Kooperation in Gruppen nur durch übergeordnete Kontrolle entwickelt. Mittlerweile gibt es verschiedene Ansätze, die zeigen, wie Kooperation auch in selbstorganisierten Gruppen entstehen kann. Dabei wird unter anderem auf die mathematische Spieltheorie zurückgegriffen. Während der Zusammenarbeit können sich Regeln zu Aspekten wie Gruppenzugehörigkeit, Wissensteilung, Fortschritts Monitoring oder Konfliktlösung entwickeln. Zudem ist – je nach Situation – eine passende Balance zwischen Normierung und Vielfalt sowie Effizienz- und Explorationsorientierung auszuhandeln. (→ Axelrod; Ostrom).

Koordination

Abstimmung der Tätigkeiten mehrerer Aufgabenträger, zwischen deren Aufgaben Interdependenz besteht.

Kosten

(engl.: costs) mit Geldeinheiten bewerteter betriebsnotwendiger Ressourcenverbrauch einer Periode.

Kosten/Nutzen-Analyse

(engl.: cost value analysis) Variante der Nutzwertanalyse, bei der die Kosten der Alternativen zunächst nicht in das Zielsystem aufgenommen werden; nach der Ermittlung des Nutzwerts wird dieser mit dem Kostenwert in Beziehung gesetzt.

Kostenart

(engl.: cost item) Ergebnis der Zerlegung von Kosten nach der Art des Verbrauchs an Ressourcen.

Kostenmanagement

(engl.: cost management) Managementprozess, dessen Zweck die Erfassung und Analyse der Kosten und deren zielgerichtete Beeinflussung ist.

Kostenstelle

(engl.: cost center) Aufgaben- und Verantwortungsbereich, der Leistungen beansprucht und dem nach vereinbarten Gestaltungszielen Kosten zugerechnet

werden.

Kostenstruktur

(engl.: cost structure) Zusammensetzung von Kosten nach Kostenart und Kostenhöhe bzw. relativer Anteil der Kosten je Kostenart.

Kostenträger

(engl.: cost unit) Leistungseinheit, der Kosten zugerechnet werden, idealer Weise die Kosten, die sie verursacht hat.

Kostenumlage

(engl.: cost allocation) Verteilung von Kosten, die den Leistungen nicht direkt zugerechnet werden, mittels Kostenverteilungsschlüssel.

Kostenverteilungsschlüssel

(engl.: cost allocation key) nach bestimmten Prinzipien gebildeter Algorithmus zur Verrechnung von Kosten auf Kostenstellen oder Leistungen.

KPI

Key Performance Indicator

Kreativitätstechnik

(engl.: creativity technique) Heuristik zur Problemdefinition und zum Problemlösen sowie zum Entwerfen von Alternativen in Situationen, die durch schlecht strukturierte Probleme und eine offene Entscheidungssituation gekennzeichnet sind.

Krisenstab

(engl.: crisis team) Gruppe von Aufgabenträgern der IT- und der Fachabteilungen, die den Notfallplan erstellen und pflegen und im Notfall die Einsatzleitung übernehmen.

Kriterienertrag

(engl.: criterion production) Ausmaß der Zielerreichung der Kriterien.

Kriteriengewicht

(engl.: criterion weight) relative Bedeutung der Kriterien in einer bestimmten Evaluierungssituation (Präferenzordnung).

Kriterium

(engl.: criterion) Eigenschaft eines Objekts, dessen Ausmaß durch Messung, Schätzung oder Prognose ermittelt wird. Synonym: Zielkriterium.

Kritischer Erfolgsfaktor

(engl.: critical success factor) Erfolgsfaktor, von dessen Ausprägung der Unternehmenserfolg entscheidend abhängt.

Kritischer Wettbewerbsfaktor

(engl.: critical competitive factor) Wettbewerbsfaktor, der für den Erfolg oder Misserfolg des Unternehmens maßgeblich bestimmend ist.

Kunde

(engl.: customer) Abnehmer von Leistungen innerhalb oder außerhalb von Unternehmen (interner oder externer Kunde).

Künstliche Intelligenz

(engl.: artificial intelligence) Automatisierung von intelligentem Verhalten; Repräsentation und automatisierte Verarbeitung von Wissen.

Kurzprüfung

(engl.: rapid audit) mit einem Arbeitsaufwand von zwei bis drei Mitarbeitertagen einschließlich Auswertung und Dokumentation durchgeführte Prüfung.

L

Lastenheft

In einem Lastenheft definiert ein Auftraggeber seine Anforderungen an die Lieferungen und Leistungen eines Dienstleisters. Es ist typischerweise Bestandteil des Vertrages. Das Pflichtenheft wird hingegen auf Grundlage des Lastenheftes vom Dienstleister erstellt und beschreibt die konkrete Lösung.

Lean

Unter „Lean Management“ oder „Lean Enterprise“ werden Ansätze subsummiert, die Prozesse und Organisation „schlank“ halten, d. h. so reduziert, dass sie schnell anpassbar bleiben und den Mitarbeitern bzw. der Unternehmung keine unnötigen und verlangsamenden Verhaltensweisen auferlegen. Vorbild ist das Toyota-Produktionssystem.

Lean Startup

Die Methode „Lean Startup“ geht davon aus, dass eine (neu gegründete) Unternehmung die Bedürfnisse des Marktes, bzw. der Kunden nicht sicher kennen kann. Daher werden Hypothesen darüber formuliert und diese schnellstmöglich in minimaler Form umgesetzt um sie in der Realität validieren zu können. Aus den bestätigten oder widerlegten Hypothesen lernt die Unternehmung und entwickelt somit fortlaufend ein immer besseres Produkt.

Lebenszyklus

(engl.: life cycle) nach Phasen strukturierte Lebensdauer eines Objektes (z. B. eines Produktes oder einer Dienstleistung).

Lebenszyklusmodell

(engl.: life cycle model) geordnete Menge von Phasen, die ein Produkt oder eine Dienstleistung in bestimmter Anordnung idealtypisch durchläuft.

Leistung

(engl.: performance)

Fähigkeit eines Systems, eine bestimmte Aufgabe in vorgegebener Zeit erfüllen zu können (Aufgabenerfüllung pro Zeiteinheit).

Größe, die für die ökonomische Beurteilung des Outputs eines Systems von Bedeutung ist und als Bezugsgröße für Kosten dient.

im Sinne der Erfolgsfaktorenanalyse der von den Befragten geschätzte Beitrag eines Erfolgsfaktors zum Unternehmenserfolg.

Leistungsdifferenz

(engl.: performance gap) Unterschied zwischen Priorität und Leistung je Erfolgsfaktor.

Leistungspotenzial

(engl.: performance potential) durch Art und Umfang der Informations- und Kommunikationsaufgaben möglicher Beitrag der Informationsfunktion zum Unternehmenserfolg.

Lernen und Adaptivität

In neuartigen Situationen ist die Wahrscheinlichkeit, Fehler zu machen groß. Lernen, Exploration und Anpassungsfähigkeit sind daher kein Luxus, sondern eine grundlegende Notwendigkeit. Single-Loop-Learning bezeichnet das Lernen durch Fehlerkorrekturen; Double-Loop- Learning beinhaltet hingegen die Veränderung der grundlegenden Leitwerte und Ziele. Ein Unternehmen kann lernen, indem es beispielsweise seine Wissensbasis und Problemdiagnostik erweitert oder indem es nach schlechten Erfahrungen riskante Tätigkeiten einstellt und stattdessen neue Ziele und Handlungsfelder verfolgt. (→ Argyris; Holland).

Leitstrategie

(engl.: key strategy, mission strategy) Strategie, die unter den Rahmenbedingungen der betrachteten Szenarien erfolgreich verfolgt werden kann.

Lenkungsausschuss

(engl.: steering committee) Gremium, das Aufgaben der strategischen ITPlanung wahrnimmt (z. B. über IT-Investitionen entscheidet).

Limitierungskriterium

(engl.: limited criterion) Kriterium, das hinsichtlich des Ausmaßes der Zielerreichung begrenzt formuliert ist.

Lizenz

Vertragliche Einräumung eines Rechts zur Benutzung eines Objekts.

M

Machbarkeitsstudie

Entwicklung des Projektgegenstands mit einer für die Projektpriorisierung ausreichenden Detailliertheit und Genauigkeit.

Malware

Software mit dem Ziel, Schäden oder Anomalien in Informationsinfrastrukturen zu verursachen, z. B. Viren, Würmer, Trojanische Pferde.

Management

Funktion der Führung einer Organisation oder eines Organisationsteils oder deren Institutionen und der in diesen tätigen Personen.

Meilenstein

(engl.: milestone) Ereignis oder Zustand, das bzw. der für den Fortschritt eines bestimmten Objekts kennzeichnend ist (z. B. der Zustand eines Fachgebiets).

Mensch-Computer Informationsverhalten

(engl.: human-computer information behavior) den Menschen betreffende Teile der Mensch-Maschine-Inter-aktion, die sich auf Information beziehen.

Mentale Modelle (Schemata)

Ein Modell ist ein vereinfachtes Abbild. Mentale Modelle sind interne Abbildungen der Außenwelt oder des Zustandes des eigenen Systems und ermöglichen dem Akteur komplexeres Handeln. Explizite oder implizite Modelle können z. B. beschreiben, wie die Lage der Situation ist (IST-Modell), was für eine Zukunft erstrebenswert ist (Soll-Modell) und wie vorzugehen ist (Vorgehens-Modell), um ein bestimmtes Ziel zu erreichen. Fehlt die Reflexion zu solchen Aspekten, besteht die Gefahr, dass aufgrund veralteter Modelle gehandelt wird. Mentale Modelle sind immer Vereinfachungen der Realität, die mehr oder weniger nützlich sein können. Je höher die Geschwindigkeit des äußeren Wandels ist, desto wichtiger wird die kritische Reflexion und Revision der mentalen Modelle. Das Infrage stellen und Verlernen von veralteten Modellen ist ein wichtiger, aber oft auch schwieriger Aspekt von ChangeProzessen. (→ Senge)

Mentoring

Begleitung, Beratung und Förderung einer weniger erfahrenen Person im Hinblick auf ihre persönliche und berufliche Entwicklung durch einen erfahrenen Mentor.

Messen

(engl.: measuring) Zuordnen von Zahlen oder anderen Symbolen zu Eigenschaften von Objekten, Ereignissen oder Situationen nach einem festgelegten Verfahren (einer Regel).

Messgröße

(engl.: indicator, measuring figure, metric) Eigenschaft eines Objekts, deren Ausprägung mit einer Messmethode ermittelt werden kann. Synonym: Metrik.

Messgrößentransformation

(engl.: indicator transformation) Vorschrift zum Überführen von Messgrößen in einen Wert, der mit dem Sollwert des Controlling-Ziels verglichen werden kann

Messinstrument

(engl.: measuring instrument) organisatorisches, hardwaremäßiges und/oder softwaremäßiges Werkzeug zum Messen.

Messmethode

(engl.: measuring technique) Verfahren zum Messen (z. B. Messen der Komplexität von Software mit dem Function-Point-Verfahren).

Messobjekt

(engl.: measuring entity) Element des Controlling-Objekts (z. B. der ITAbteilung), das den Zielinhalt des Messziels beschreibt (z. B. Personalkosten).

Messpunkt

(engl.: measuring point) Stelle eines Messobjekts, an der eine Messgröße erfasst werden kann (z. B. Projekttagebuch).

Messziel

(engl.: measuring goal) operationales und für bestimmte Messzwecke wirtschaftlich verwendbares Ziel (z. B. Wirtschaftlichkeit).

Metadaten

(engl.: meta data) Daten, mit denen Nutzdaten beschrieben werden.

Metrik

(engl.: metric) Synonym für Messgröße und für Kennzahl.

Minimal Viable Product (MVP)

Ein MVP ist ein experimenteller Prototyp, der dem Zweck dient, kritische Annahmen des Geschäftsmodells oder der Produktvision mit möglichst geringer Investition zu überprüfen.

Modell

(engl.: model) vereinfachte Abbildung eines Ausschnitts der Wirklichkeit oder Konstruktion eines Vorbilds für die Wirklichkeit.

Modellierungswerkzeug

(engl.: modeling tool) Werkzeug zur Abbildung, Analyse und Simulation von Geschäftsprozessen.

Multi-Agenten-System

Um Aussagen über das Verhalten einer großen Zahl an Individuen zu machen, analysiert die Multi-Agenten-Modellierung das lokale Wahrnehmen, Wissen und Entscheiden der Akteure, sowie Veränderungen ihrer Einstellungen, Bedürfnisse

und Absichten. Die lokalen Verhältnisse und Verhaltensweisen jedes einzelnen Akteurs werden berechnet, dies lässt Effekte erkennen, die einfache Gleichungssysteme nicht aufzeigen können. Auf diese Weise lassen sich beispielsweise relativ gute Modelle von Staus auf der Autobahn, von sozialer Segregation in Städten oder der Adoption von Innovationen nachbilden. Auch die Ausbreitung von sozialen Unruhen und die emotionale «Ansteckung» zwischen Beteiligten lassen sich auf diese Weise besser verstehen. (→ Page)

Muss-Projekt

(engl.: essential project) Projekt, dessen Realisierung für das Unternehmen von existenzieller Bedeutung ist (z. B. wegen hoher operativer Risiken im Falle der Nichtdurchführung).

N

Nachfrage

(engl.: demand) Geäußerter Bedarf nach einem Gut, verbunden mit der Bereitschaft, dafür eine Gegenleistung zu erbringen.

Nichtfunktionale Produktqualität

Neben dem Funktionsumfang eines Produkts, der beschreibt, was dieses Produkt leistet, gibt es zahlreiche nichtfunktionale Qualitätsattribute, mit denen beschrieben werden kann, wie gut das Produkt dies leistet. Die nichtfunktionale Produktqualität eines Softwareprodukts umfasst z.B. Qualitätsdimensionen wie Performanz, Usability, Sicherheit, Zuverlässigkeit, Wartbarkeit, Über-tragbarkeit oder Flexibilität.

Nominaldefinition

(engl.: nominal definition) Definition, die der Erklärung des Namens eines Objekts dient.

Non-functional Requirement

Nicht-funktionale Anforderung im Product Backlog, z.B. Aufsetzen eines BuildProzesses oder Projekt-Wikis, Erstellung von Schulungsunterlagen, Organisation eines Akzeptanz-Tests usw. Siehe Requirement.

Non-territoriales Büro

Bürokonzept, das ein Angebot unterschiedlicher Arbeitsplatztypen vorsieht, die verschiedenen Anforderungen gerecht werden. Mitarbeiter können beliebig oft zwischen den Arbeitsplatztypen wechseln; es sind keine Schreibtische permanent an bestimmte Mitarbeiter vergeben.

Homebase: Teams sind sogenannten Homebases zugeordnet, in denen 0,5 Arbeitsplätze pro Mitarbeiter vorgehalten werden.

Quiet Area: Räume für konzentrierte Einzelarbeit.

Project Areas: Räume, die für Projektarbeit in Teams genutzt werden.

Business Garden: Individuell und nach verschiedenen Themen gestaltete Arbeitsbereiche. Es sind die einzigen Bereiche mit Pflanzen.

Think Tank: Rückzugsräume für spontane Besprechungen und Telefonate.

Office: Rückzugsräume für konzentrierte Einzelarbeit oder vertrauliche Gespräche.

Media Wall: Bildschirm mit großem Stehtisch, um in kleinen Gruppen spontan Präsentationen zu zeigen und sich dazu auszutauschen.

Touch Down: Zusätzliche Arbeitsmöglichkeit für konzentrierte Einzelarbeit, auch gut für Besucher geeignet.

Home Office: Arbeiten von zu Hause.

Open Space: Großraumkonzept.

Clean Desk (Aufgeräumter Tisch): Regelung über das Aufräumen eines Arbeitsplatzes nach der persönlichen Nutzung im Zusammenhang mit dem Konzept Desk-Sharing und non-territorialen Belegungskonzepten. Synonym: Desk-Sharing

Normstrategie

(engl.: norm strategy) Strategie, die bei Vorliegen bestimmter Ausprägungen von Beurteilungskriterien grundsätzlich empfehlenswert ist.

Notfall

(engl.: case of emergency) Störung, durch die ein hoher bis sehr hoher Schaden

entsteht und deren Bewältigung spezifische Maßnahmen erfordert.

Notfallorganisation

(engl.: emergency case organization) Zuweisung von Teilaufgaben des Notfallmanagements auf verschiedene Struktureinheiten, d. h. Rollen, Stellen oder Organisationseinheiten.

Notfallplan

(engl.: business continuity plan, disaster plan) Dokument, das Vorgehensweise und Maßnahmen im Notfall beschreibt.

Nutzen

(engl.: benefit)

Maß für die Fähigkeit von Gütern, Bedürfnisse zu befriedigen.

Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. Synonym: Nutzwert.

Nutzenpreis

(engl.: benefit rate) Preis für die Bearbeitung eines Auftrags, den ein Auftraggeber zu zahlen bereit ist. Synonym: Knappheitspreis.

Nutzungsrecht

(engl.: usufructuary right) Recht, das den Inhaber einer Nutzungsbewilligung berechtigt, ein urheberrechtlich geschütztes Werk im vereinbarten Umfang zu nutzen.

Nutzwert

(engl.: value of benefit) Synonym für Nutzen.

O

Open Innovation

2003 von Chesbrough geprägte Bezeichnung für die Einbeziehung unternehmensexterner Wissensträger in Innovationsprozesse.

Open Space Offices

Offene Büroflächen mit Arbeitstischen in Kombination mit gemeinschaftlich genutzten und hochwertig gestalteten Funktionen in räumlicher Nähe. Dazu gehören zum Beispiel geschlossene Rückzugräume und Besprechungsräume, halboffenen Sitzecken und Projektzonen sowie akustisch abgetrennte Infrastruktureinheiten (Versorgungszeile mit Aufenthaltsbereich, offene Besprechungsbereiche und Treffpunkte, Bürotechnik, etc.).

Operation

Handlung oder Tätigkeit, die im betrachteten Zusammenhang nicht weiter zerlegt werden soll. Synonyme: Aktivität, Arbeitsschritt.

Operational

Eigenschaft einer Handlungsanweisung, so formuliert zu sein, dass sie von den für sie bestimmten Adressaten befolgt werden kann.

Operationelles Risiko

(engl.: operational risk) Risiko, das sich aus der betrieblichen Tätigkeit ergibt. Synonyme: operationales oder operatives Risiko.

Operator

Mitarbeiter der Struktureinheit Operating, der ein IT-System von einem Leitstand aus bedient, ganzheitlich überwacht und steuert.

Optimale Informationsversorgung

(engl.: optimal information provision) Zustand in einer Organisation bzw. bei einem Individuum, bei dem sich Angebot, Nachfrage und Bedarf an Information decken.

Ordinale Transitivität

(engl.: ordinal transitivity) Widerspruchsfreiheit von Aussagen, die sich aus der Konsistenz der Ordnungsrelationen im Aussagensystem ableitet (z. B. A ist bedeutsamer als B / B ist bedeutsamer als C / A ist bedeutsamer als C).

Ordnungsmäßigkeit

(engl.: regularity) zusammenfassende Bezeichnung für Vollständigkeit, Richtigkeit, Zeitgerechtigkeit und Sicherheit einschließlich der Prüfbarkeit dieser An-forderungen durch einen sachkundigen Dritten (Prüfer, Revisor) in angemessener Zeit.

Organisationales Lernen

(engl.: organizational learning) jegliche, d. h. sowohl zufällige als auch bewusst herbeigeführte, Veränderung der Wissensbasis einer Organisation.

Outsourcing

Kontraktion der Wörter out[side] und [re]sourcing bzw. out[side] und [re]sourc[e] und [us]ing; Erfüllung von IT-Aufgaben durch Unternehmensexterne; zusammenfassende Bezeichnung für Auslagerung und Ausgliederung.

Outsourcing-Geber

(engl.: outsourcing provider) Unternehmen, dem IT-Aufgaben übertragen werden. Synonyme: Outsourcing-Anbieter, Outsourcing-Dienstleister.

Outsourcing-Grad

(engl.: degree of outsourcing) Maß für den Umfang des Outsourcings. Synonym: Outsourcing-Reichweite.

Outsourcing-Nehmer

(engl.: outsourcing client) Unternehmen, das einem anderen Unternehmen ITAufgaben überträgt. Synonym: Outsourcing-Kunde.

Outtasking

Auslagerung einzelner IT-Aufgaben. Synonym: Selektives Outsourcing.

P

Paarvergleich

(engl.: paired comparison) Verfahren zur direkten Gegenüberstellung von zwei Objekten, und zwar mit dem Ziel, eine Ordnungsrelation hinsichtlich eines betrachteten Kriteriums herzustellen. Synonym: Paarweiser Vergleich.

Paarvergleichsmatrix

(engl.: paired comparison matrix) eine Tabelle, in der die relative Bedeutung von Kriterien zueinander erfasst wird, wobei die Anzahl der durchzuführenden Paarvergleiche in der Matrix durch die Formel n × (n-1) / 2 bestimmt wird; n = Anzahl der zu vergleichenden Kriterien.

Paradigma

(engl.: paradigm) Allgemein anerkannte, in den Lehrbüchern dokumentierte Begriffe, Theorien und Erläuterungen einer Wissenschaftsdisziplin, die herrschende Meinung oder gemeinsame Auffassung ihrer Vertreter.

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionsfähige Produkte mehr als ausgedehnte Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Eingehen auf Änderungen mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Partizipation

(engl.: participation) umfassender Begriff zur Bezeichnung der Ansätze der Teilnahme von Betroffenen an gesamt und einzelwirtschaftlichen Entscheidungen.

PDCA

Plan-Do-Check-Act; Zyklus der kontinuierlichen Verbesserung.

Penetrationstest

(engl.: penetration test) Prüfung der Sicherheit der Komponenten und Anwendungen eines Informations-systems mit Mitteln und Methoden, die ein Angreifer anwenden würde, um unautorisiert in das System einzudringen.

Personalisierung

(engl.: personalization) personenzentrierte Wissensbewahrung und -verteilung.

Phase

Gruppierung von Aktivitäten.

Phasenmodell

(engl.: phase model) systematische Gliederung einer Aufgabe in mehrere aufeinander folgende Phasen, die inhaltlich, technisch und organisatorisch unterscheidbar sind, charakteristische Ziele haben, Methoden erfordern und Ergebnisse erzeugen.

Pig

Bezeichnung für eine Person, die direkt am Projekt beteiligt ist, indem sie eine formale Scrum-Rolle (Team Member, Product Owner, ScrumMaster) ausfüllt oder auf sonstige Weise zu den Stakeholdern gerechnet werden kann. Ein Pig trägt im Gegensatz zu einem Chicken ein Risiko bzw. eine Last im Projekt und ist „committed, not just involved“, also mehr als ein interessierter Außenstehender.

Planning Poker

Planning Poker ist das wahrscheinlich bekannteste Schätz-Spiel, das sehr häufig von agilen Softwareentwicklungs-Teams angewendet wird.

Neben allen Teammitgliedern und dem Product Owner werden für das Planning Poker benötigt: Ein Stapel der zu beschätzenden Backlog Items (z.B. als User Stories auf Story Cards) sowie für alle Personen, die an der Schätzung teilnehmen sollen, ein Stapel Planning Poker-Karten.

Häufig verwendet werden Planning-Poker-Karten mit den folgenden Optionen verwendet:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100,?, Kaffeetasse. Das Fragezeichen kann gezeigt werden, wenn sich jemand unsicher ist, was eine realistische Beschätzung ist. Die Kaffeetasse steht dafür, dass derjenige eine Pause benötigt.

Der Product Owner nimmt die erste Story Card und liest diese vor. Er beschreibt sie dann noch kurz und mögliche Fragen werden besprochen. Alle haben nun kurz Zeit, sich Gedanken über ihre Einschätzung zu machen. Auf ein Signal hin zeigen alle die von ihnen gewählte Karte.

Nun wird ersichtlich, ob es eine sehr ähnliche oder sehr ungleiche Einschätzung der Komplexität der Stories gibt. Sofern eine sehr ähnliche Einschätzung vorliegt, einigen sich die Teammitglieder meist schnell auf den Wert, den der Großteil als realistisch ansieht. Sind die Einschätzungen weiterhin eher ungleich, gilt folgende Regel:

Eine der Personen, die die höchste Einschätzung gemacht hat und eine der Personen, die die niedrigste Einschätzung gemacht hat, stellen dar, warum sie die Komplexität so hoch bzw. gering sehen. Dadurch werden mögliche Knackpunkte („Wir müssen noch bedenken, dass..“) oder auch Erleichterungen („Wir haben doch schon...“) aufgedeckt, die allen eine bessere Einschätzung ermöglichen. Dann wird eine erneute Schätzrunde vorgenommen.

Dieses Spiel wird so lange durchgeführt, bis alle Stories mit einer Schätzung versehen sind.

PMO

Project Portfolio Management Office

Portfolio-Planung

grafische Darstellung der Zielerträge mehrerer Objekte mit zwei Merkmalen in einem meist in Quadranten eingeteilten Koordinatensystem.

Potenzialfaktor

(engl.: potential factor) Eigenschaft einer Technologie, die bei deren Nutzung die Ausschöpfung des Nutzenpotenzials unterstützt (z. B. Erhöhung der Produktivität).

Präferenz

(engl.: preference) Vorziehenswürdigkeit eines Objekts (z. B. einer Alternative, eines Kriteriums) gegenüber anderen Objekten.

Präferenzordnung

(engl.: preference order)

durch ein Individuum oder eine Gruppe vorgenommene Ordnung einer Menge von Kriterien aufgrund bestehender Präferenzen.

Ordnung von Objekten (z. B. Alternativen, Kriterien) aufgrund bestehender Präferenzen.

Principle of Least Effort

theoretischer Ansatz zur Erklärung der Informationsaufnahme.

Prinzip

(engl.: principle) Regel oder Richtschnur für Denken, Handeln und/oder Verhalten; eine empfehlenswerte, in der Praxis bewährte Handlungsanweisung. Synonym: Grundsatz.

Priorität

(engl.: priority) im Sinne der Erfolgsfaktorenanalyse die von den Befragten beurteilte Wichtigkeit eines Erfolgsfaktors bezüglich seines Beitrags zum Unternehmenserfolg.

Product Backlog

Das Product Backlog ist ein sogenanntes Artefakt der agilen Projektmanagement Methode Scrum und gehört dem Product Owner. Hierin werden alle Anforderungen, die während eines Projektes bekannt werden, gesammelt und strukturiert. In der Regel geschieht das anhand von sogenannten Epics (übergeordneten Anforderungen) und daraus abgeleiteten User Stories (sehr konkrete Anforderungen), die priorisiert und dementsprechend detailliert werden. Zu Beginn handelt es sich bei dem Product Backlog um eine Art von Ideenpool, in dem alle möglichen Anforderungen gesammelt und gewichtet werden. Die Anforderungen, die frühzeitig umgesetzt werden sollen, müssen zuerst konkretisiert/detailliert werden. Ob eine Anforderung konkret genug ist, also der Definition of Done entspricht,

entscheidet das Developer Team im sogenannten Sprint Planning. Sofern das nicht der Fall ist, muss der Product Owner seine Anforderungen noch weiter konkretisieren, wobei ihm der Scrum Master mit Hilfe verschiedener Techniken helfen kann.

Das Dokument wird laufend und von allen Projektbeteiligten gepflegt. Änderungswünsche oder neue Produktanforderungen werden direkt im Product Backlog vermerkt und dokumentiert. Wichtig ist in diesem Kontext, dass das Team Änderungswünsche und neue Anforderungen nicht als Störung bewertet, sondern vielmehr als Korrektiv, das hilft, ein zielgerichtetes Ergebnis zu produzieren.

Product Backlog Item

Anforderung (Requirement) im Product Backlog. Ein Product Backlog Item ist in der Tendenz umso fein-granularer und genauer geschätzt, je näher es aufgrund seiner höheren Priorität am Anfang des Product Backlogs steht und je höher somit die Wahrscheinlichkeit ist, dass es in einem der nächsten Sprints bearbeitet wird.

Product Owner

Die für die Pflege des Product Backlogs verantwortliche Person. Der Product Owner vertritt die fachliche Auftraggeberseite und somit sämtliche Stakeholders im Projekt. Er priorisiert die Product Backlog Items in einer Weise, die dazu geeignet ist, den Business Value des Produkts zu maximieren. Beispielsweise überlegt er sich, welche Menge von Anforderungen (Requirements) als erste implementiert werden sollen, um ein frühes erstes Release des Produkts, verbunden mit einem frühen Return On Investment, zu realisieren.

Product Vision Board

Weiter reduzierte Alternative zum Business Model Canvas, mit Fokus auf Entwicklung eines einzelnen Produkts.

Produkt

Ergebnis eines Leistungserstellungsprozesses, also nicht nur materielle, sondern auch immaterielle Produkte und Dienstleistungen.

Produktaktivierung

(engl.: product activation) Form des Softwareschutzes zur Verhinderung von Softwarepiraterie. Synonym: Softwareaktivierung.

Produktionsfaktor

(engl.: production factor) Güter (Produkte und Dienstleistungen), die zur Herstellung und Verwertung betrieblicher Leistungen erforderlich sind.

Profildiagramm

(engl.: profile diagram) Grafische Darstellung der Zielerträge mehrerer Objekte zu mehreren Zielkriterien.

Profit Center

Ergebnisverantwortliche Struktureinheit, deren Leistungen marktfähig sind.

Prognose

(engl.: forecast) Voraussage oder Vorhersage einer zukünftigen Entwicklung oder eines zukünftigen Zustands auf der Grundlage systematisch ermittelter Daten und der Verwendung wissenschaftlicher Erkenntnisse.

Project Management Office

Ein Project Management Office (PMO) ist eine Stabsabteilung in einer Unternehmung, die sich um Projekte kümmert. Es ist oft eines von zwei Typen zu finden: Das schwache PMO bündelt Wissen zu Projektmanagementthemen und bietet dieses den Fachabteilungen, die Projekte durchführen, als beratende Unterstützung an. Ein starkes PMO ist viel tiefer in die Projektmanagementthemen eingebunden. So entscheidet es über Projektanträge und gestaltet so das Projekt-Portfolio, stellt selbst die Projektmanager für Projekte oder kontrolliert zumindest die Fortschritte im Projekt unmittelbar.

Projektorganisation

(engl.: project organization) Art und Weise, in der die Projektleitung eine Projektgruppe führt und die projektbezogenen Aufgaben in den am Projekt beteiligten Unternehmensbereichen beeinflussen kann.

Projektplanung

(engl.: project planning) Prüfung der Realisierbarkeit der Anforderungen eines Projekts durch Herausarbeitung seiner organisatorischen, technischen, personellen, rechtlichen und wirtschaftlichen Konsequenzen (z. B. Aufgabenplanung, Terminplanung).

Projekt-Portfolio

Unter einem (Projekt-)Portfolio versteht man die Gesamtheit aller Projekte bzw. Vorhaben eines Unternehmens zu einem Zeitpunkt.

Proto-Personas

Einfach gehaltene, auf das wesentliche reduzierte virtuelle Charaktere, die jeweils auf sehr empathische Weise ein Kundensegment repräsentieren sollen.

Prozess

(engl.: process) Menge interdependenter Teilaufgaben (Arbeitsschritte), die durch Eingaben (Input), interne Funktionen und Ausgaben (Output)

gekennzeichnet ist.

Prozesseigner

(engl.: process owner) Für einen Prozess verantwortlicher Mitarbeiter.

Prozesselement

(engl.: process element) Teil eines Prozesses; Teilprozess, Prozess- oder Arbeitsschritt.

Prozesskostenrechnung

(engl.: process cost allocation) Verrechnung der nicht direkt zurechenbaren Kosten auf Produkte und Dienstleistungen proportional zu den Prozessmengen, die sie beansprucht haben.

Prozessorientierung

(engl.: process orientation) Ausrichtung eines Unternehmens primär an Geschäftsprozessen statt an Funktionalbereichen.

Prüfliste

(engl.: checklist) Hilfsmittel zum Überprüfen von Systemeigenschaften mit dem Zweck, Systemmängel auf zudecken. Synonyme: Prüfungsfragebogen, Checkliste.

Prüfung

(engl.: audit)

auf die Vergangenheit gerichtete Untersuchung von Vorgängen und Ereignissen durch prozessunabhängige Personen.

Vergleich der tatsächlichen mit den vorgesehenen bzw. geforderten Eigenschaften eines Objektes mit dem Ziel, Abweichungen bzw. Fehler zu finden.

Portfolio-Planung

Die mittel- bis langfristige Priorisierung und Einplanung der umzusetzenden Vorhaben anhand einer Strategie. Product Owner

Der Product Owner (PO) ist eine Rolle in Scrum, die man auch als Produkt- und Anforderungsmanager beschreiben könnte. Der Product Owner verantwortet die Entwicklung und den Erfolg des Produktes. Dazu gehören die kontinuierliche Entwicklung einer Produktvision, genauso wie das Erfassen der Anforderungen

als Stories im Backlog und dessen Pflege. Er priorisiert die Stories für das Team, klärt Rückfragen und nimmt die Umsetzung am Ende formal ab.

Q

QA

QA steht für „Quality Assurance“, entspricht dem deutschen „QS“ für „Qualitätssicherung“ und meint Verfahren um die Qualität eines Produktes systematisch im Entwicklungs- oder Produktionsprozess zu kontrollieren und zu verbessern.

QM-Maßnahme

(engl.: quality management measure) Maßnahme, deren Zweck es ist, die Realisierung einer definierten Qualitätsanforderung zu gewährleisten.

Qualitätsmerkmal

(engl.: quality characteristic) Relevante Eigenschaft eines Objektes, die sich auf eine Anforderung bezieht. Synonym: Qualitätseigenschaft.

Qualitätsmodell

(engl.: quality model) System aus Qualitätsmerkmalen und deren Beziehungen

zur Spezifizierung von Anforderungen und zur Beurteilung der Qualität eines Objekts.

Qualitätsniveau

(engl.: quality level) Ausmaß an geforderter oder vorhandener Qualität.

Qualitätsplanung

Teil des QM, der Qualitätsziele, notwendige Prozesse sowie Ressourcen zur Erreichung der Qualitätsziele festlegt.

Qualitätspolitik

(engl.: quality policy) Durch das Top-Management formell ausgedrückte Absichten und Ziele des Unternehmens zur Qualität.

Qualitätssicherung

(engl.: quality assurance) Teil des QM, der darauf ausgerichtet ist, Vertrauen zu erzeugen, dass Qualitätsanforderungen erfüllt werden.

Qualitätsverbesserung

(engl.: quality improvement) Teil des QM, der darauf ausgerichtet ist, die Fähigkeit zur Erfüllung von Qualitätsanforderungen zu verbessern.

Qualitätsziel

(engl.: quality objective) Qualität betreffendes, strategisches Formalziel.

R

RACI-Modell

RACI ist ein Akronym für eine Methode, die die Verantwortlichkeiten eines Prozesses oder einer Aktivität definieren soll. Abgeleitet aus dem Englischen stehen die vier Buchstaben für: Responsible, Accountable, Consulted and Informed.

Rahmenvertrag

(engl.: blanket agreement) Vertrag mit Vertragsinhalten, die längerfristig gültig und daher für mehrere Verträge relevant sind.

Rationalisierung

(engl.: rationalization) Vorgehensweise, ein System so zu gestalten, dass es gesetzten Zielen besser entspricht (von lat. ratio = Vernunft).

Realdefinition

(engl.: real definition) Definition, die der Erklärung des Objekts dient, etwa

durch Beschreiben der Merkmale, die für das Objekt kennzeichnend sind.

Realisierungsstrategie

(engl.: realization strategy) Strategie, die den Weg vom Istzustand zum angestrebten Sollzustand beschreibt.

Redundanz

(engl.: redundancy) Mehrfachauslegung eines Systems mit Systemteilen gleicher Funktion.

Reengineering

Zusammenfassende Bezeichnung für Reverse Engineering und Restrukturierung.

Re-Evaluierung

(engl.: re-evaluation) Erneute Evaluierung eines Objekts nach erfolgter Vornahme von Änderungen am Objekt auf Grundlage einer Evaluierung.

Referenzmodell

(engl.: reference model)

Eine zweckorientierte Spezifikation des generellen Modellbegriffs, die als Vorlage für das Gestalten von Artefakten dient.

Modell, das einen gewollten oder geplanten Zustand eines Systems abbildet, an dem dessen gegenwärtiger Zustand beurteilt werden kann, oder ein Modell, das als Vorbild zur Ableitung eines spezifischen Modells dient.

Regeln

Es gibt zwei Arten von Regeln. Algorithmische Regeln sind streng zu befolgende Anweisungen, während heuristische Regeln ergebnisoffene Vorgehensempfehlungen («Faustregeln ») sind. Auch wenn Menschen nicht rein regelbasiert funktionieren, beruht ein Anteil ihres sozialen Verhaltens auf expliziten oder impliziten Regeln im Sinne von «wenn-dann»- Aussagen. Regeln helfen, Unsicherheit zu reduzieren und das Eintreffen von wunschgemäßem Verhalten zu erhöhen. Es gibt auch Regeln, die bestimmen, wann welche Regeln gelten und wann nicht. Beim Eintritt in eine Firma oder beim Besuch eines fremden Landes werden implizite kulturelle Regeln rasch über-sehen; deren Beachtung ist hingegen ein Zeichen sozialer Kompetenz. Für Organisationen besteht die Herausforderung darin, die richtige Menge an Regeln und Vorgaben zu definieren und doch genügend Freiraum für situativ entstehende Regeln zu geben. (→ Wiener; Holland)

Regressionstest

(engl.: regression test) Wiederholte Ausführung eines Testobjekts mit Testdaten, um Fehler in bereits getesteten, aber danach modifizierten Elementen von Softwaresystemen zu finden.

Rekursion

(engl.: recursion) Definition eines Problems oder eines Verfahrens durch sich selbst (z. B. ein Programm, das sich selbst aufruft).

Release

Freigabe einer Produktversion nach Abschluss eines oder mehrerer Sprints. Grundsätzlich hat der Product Owner nach jedem Sprint die Option, ein Release der bis dahin implementierten Funktionalität zu initiieren. Er ist sich dabei der Tatsache bewußt, daß ein Release das Team Zeit kostet – üblicherweise legt es einen Release Sprint oder Stabilisation Sprint ein, welcher dem Zweck der Produktivsetzung dient. Der Product Owner wägt jeweils ab, ob er den Return On Investment für das Release der bestehenden Funktionalität und den Wert des Feedbacks der Benutzer für das Team und die weitere Produktentwicklung hoch genug einschätzt, um den Beginn des nächsten Entwicklungs-Sprints zu verschieben.

Anmerkung: Es ist durchaus im Sinne agiler Softwareentwicklung, frühe und häufige Releases zu haben („release early, release often“). Gemäß dem Grundsatz, daß das Team in jedem Sprint ein Increment of Potentially Shippable Functionality abliefert, sollte ein Release kein größeres Problem darstellen – sonst hätte das Team etwas falsch gemacht und Scrum nicht verstanden.

Rentabilität

(engl.: profitability) Verhältnis von Kapitalrückfluss und Kapitaleinsatz einer Investition.

Requirement

Funktionale oder nicht-funktionale Anforderung an das Produkt im Product Backlog aus Sicht des Product Owners. Alle Requirements werden später in den Sprint Backlogs jeweils in Tasks heruntergebrochen.

Requirements Engineering

Der Begriff Requirements Engineering beschreibt die Spezifikation und das Management von Anforderungen an ein zu erstellendes System (z.B. Softwareprodukt). Neben dem Erheben und Prüfen der Anforderungen umfasst dies das Herstellen von Konsens unter den betroffenen Stakeholdern, das adäquate [standardkonforme] Dokumentieren sowie die systematische Verwaltung der Anforderungen über den gesamten Entwicklungsprozess des Systems.

Responsible

Der/die Durchführungsverantwortliche ist der eigentliche Macher, d.h. von dieser Person wird die Aufgabe operativ durchgeführt.

Restrisiko

(engl.: residual risk) Risiko, das nicht durch Sicherungsmaßnahmen ausgeschaltet oder durch Versicherungsverträge überwälzt werden kann oder soll.

Rettungsplan

(engl.: rescue guide) Teilplan des Notfallplans mit Anweisungen darüber, wer und was wie zu bergen ist. Synonym: Evakuierungsplan.

Reverse Engineering

Umkehrung des Entwurfs- und Entwicklungsprozesses, d. h. Rückführung eines physischen Modells in ein logisches Modell, von dem aus das physische Modell erneuert wird.

Review

Mehr oder weniger formaler Prozess der Analyse, Bewertung, Kommentierung und Genehmigung von Zwischen- oder Endergebnissen durch Gutachter.

Risiko

(engl.: risk) Kombination aus zu erwartender Häufigkeit bzw. Eintrittswahrscheinlichkeit eines gefährdenden Ereignisses und dem beim Ereigniseintritt zu erwartenden Schadensausmaß.

Risikoanalyse

Prinzip zur Entwicklung von Sicherheitskonzepten, bei dem Schadenshöhen und Eintrittswahrscheinlichkeiten von Bedrohungen bzw. sicherheitsgefährdenden Ereignissen detailliert ermittelt werden.

Rolle

(engl.: role) Menge von Erwartungen, die das Verhalten von Individuen mit bestimmten Positionen beschreiben.

Rückkoppelung (Feedback)

Rückkopplung ist der zentrale Begriff der Kybernetik. Der Output eines Systems wird beobachtet und als Wert wieder in das System hineingeführt, um das weitere Verhalten zu steuern. Führt die Rückkopplung zu einer Verstärkung, wird sie «positive Rückkopplung» genannt. Führt die Rückkopplung zu einer Dämpfung oder Stabilisierung des Verhaltens, wird sie «negative Rückkopplung» genannt. Negativ und positiv sind hier keine wertenden Begriffe; beide Mechanismen können erwünscht oder unerwünscht sein. Der Heizungs-thermostat ist Beispiel einer negativen Rückkopplung, während der Pfeifton zwischen Mikrofon und Lautsprecher als Eskalation der Situation eine

positive Rückkopplung ist. In einem Unternehmen können Projekterfolge zu Kompetenzgewinnen beitragen, die im nächsten Projekt zu weiteren Erfolgen und Kompetenzgewinnen führen. Umgekehrt kann eine überhöhte Selbsteinschätzung zum Nach-lassen von Anstrengungen führen, was zeitversetzt den Erfolg reduzieren kann. (→ Wiener; Forrester; Senge)

S

SAFe-Framework

Das Scaled Agile Framework ist ein komplexes Modell um agile Entwicklung über viele Teams abzustimmen und zu integrieren. Es betrachtet die vier Ebenen Team, Programm, Value Stream und Portfolio.

Sarbanes-Oxley Act

Gesetz, mit dem die Corporate Governance von Unternehmen verbessert werden soll, die an US-Börsen notiert sind; zum Teil abgekürzt als SOX.

Scaling Model

Für die Organisation größerer Einheiten und mehrerer Teams gibt es spezielle Frameworks wie das Scaled Agile Framework oder Large Scaled Scrum. Diese Frameworks definieren weitere Rollen, die in großen agilen Entwicklungsorganisationen benötigt werden.

Schlüsselbereich

(engl.: key domain) nach den Eigenschaften Service, Kommunikation, Personal und Positionierung geordnete Menge von Erfolgsfaktoren.

Schlüsselfaktor

(engl.: key factor) Kombination Erfolgsfaktor/ Wettbewerbsfaktor, die für den Beitrag der IT zum Unternehmenserfolg von besonderer Bedeutung ist.

Schlüsselfertiges System

(engl.: turnkey system) System, das Anwendern mit allen Komponenten aus einer Hand (z. B. von einem ASP) produktiv nutzbar zur Verfügung gestellt wird.

Schrittmachertechnologie

Im Entwicklungsstadium befindliche Technologie, von der ein erhebliches Veränderungspotenzial erwartet wird.

Schulung

(engl.: training) Mittel und Maßnahmen, deren Zweck es ist, die Qualifikation der Mitarbeiter so zu gestalten, dass sie die ihnen zugeordneten Aufgaben erfüllen können.

Schutzbedarf

(engl.: security requirements) angestrebtes oder erforderliches Sicherheitsniveau einer Informationsinfrastruktur.

Schwäche

(engl.: weakness) negative Abweichung der Eigenschaft eines Systems von einem definierten Standard (z. B. Sollzustand). Synonym: Schwachstelle.

Schwachstelle

(engl.: vunerability, weakness) Umstand, der das Eintreten gefährdender Ereignisse begünstigen oder deren negative Folgen verstärken kann.

Scrum

Scrum ist ein Begriff aus dem Rugby-Sport und bezeichnet dort das so genannte «Angeordnete Gedränge». Als Technik wurde es ursprünglich im Softwarebereich ent-wickelt, ist aber davon unabhängig. Scrum wird in der Zwischenzeit in vielen anderen Domänen eingesetzt und ist eine Umsetzung von Lean Development für das Projektmanagement. In der Softwareentwicklung ist es eine Methode zur Komplexitätsreduktion. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um einen voll-

umfänglichen Plan erstellen zu können. Die Unklarheit sowohl von Anforderungen als auch Lösungsansätzen lässt sich bei komplexen Aufgabenbeseitigen, indem iterativ und inkrementell Zwischenergebnisse geschaffen werden.

Scrum Master

Er ist vor allem Moderator, Coach und Dienstleister für das Projektteam. Er sorgt dafür, dass Hindernisse und Störfaktoren im Umfeld des Teams beseitigt werden. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Scrum-Regeln eingehalten werden. Der Scrum Master arbeitet eng mit dem Product Owner zusammen.

Der Scrum Master ist eine Rolle in Scrum, die sich allein um den Prozess kümmern soll. Der Scrum Master organisiert die Zeremonien und führt sie teilweise durch, hilft dem Team in der täglichen Arbeit durch das Beseitigen von Impediments (Hindernissen) und unterstützt es bei der kontinuierlichen Reflektion und Verbesserung der eigenen Arbeitsweisen.

Die für den Scrum-Prozess verantwortliche Person. Der ScrumMaster sorgt für die korrekte Implementation und den maximalen Nutzen des Prozesses.

Anmerkungen:

Der ScrumMaster sollte kein Vorgesetzter der Team Members sein.

Der ScrumMaster sollte keine Doppelfunktion als Team Member oder Product Owner haben. Interessenkonflikte wären die unvermeidliche Folge.

Der ScrumMaster ist kein Projektleiter im herkömmlichen Sinn, sondern ein Vermittler und Unterstützer (Facilitator), dessen Hauptaufgabe darin besteht, Hindernisse (Impediments) für das Team aus dem Weg zu räumen.

Scrum of Scrums

Wenn in einem Scrum-Projekt die ideale Team-Größe von sieben Personen wesentlich überschritten wird, wird ein skalierter Scrum-Prozess benötigt. Das ist relativ einfach möglich, indem mehrere Teams gebildet werden, die sich in der Folge untereinander mit möglichst wenig Overhead koordinieren und abgleichen müssen. Jedes Team funktioniert zunächst eigenständig. Aus jedem Team wird ein Mitglied in den Scrum of Scrums entsendet. Die TeamBotschafter — es müssen nicht immer dieselben sein — berichten dort aus ihrem Teilprojekt und gleichen sich auf diese Weise bzgl. Übergeordneter Themen ab. Sie nehmen die Informationen mit zurück in ihre jeweiligen Teams, um sie dort nach Bedarf zu verbreiten.

Anmerkung: Der Scrum of Scrums kann auch mehrstufig angelegt sein, wenn es sehr viele Teams gibt. Dies wurde bereits häufig in der Praxis mit bis zu mehreren hundert Team-Mitgliedern umgesetzt und zeigt, wie gut Scrum als Prozess mit sehr wenig Overhead skaliert.

Scrum Sprint

Ein Sprint ist ein kurzes Entwicklungsintervall, das sich wiederholen kann, an

dessen Ende jeweils eine fertige Funktionalität vorliegt. Sprints umfassen also machbare Kundenanforderungen, die in eine entsprechend überschaubare Spezifikation der technischen Anforderungen münden und auf Quick-wins zielen.

Scrum Team

Das Scrum Framework kennt drei Rollen mit jeweils verschiedenen Verantwortungen:

Product Owner, Entwicklungsteam und Scrum Master.

Die Gesamtheit dieser Rollen wird als Scrum Team bezeichnet. Ein Scrum Team tritt mit vielen weiteren Rollen in der Organisation in Kontakt. Diese Rollen werden als Stakeholder (Beteiligte) bezeichnet.

Selbstorganisation

Selbstorganisation steht als Begriff als Gegensatz zu Fremdorganisation oder Fremdbestimmung. Das Verhalten eines Systems wird zu einem großen Teil nicht durch äußere, sondern durch innere Ereignisse angestoßen und zwar in einer Weise, die im System zu einer zunehmenden Ordnung führt. Diese innere Dynamik ist meist nicht hierarchisch gesteuert, sondern geschieht über das System verteilt. In der Physik ist Laserlicht als Beispiel einer selbstorganisierten Ordnung bekannt. Der Kreisverkehr ist ein alltägliches Beispiel eines verteilten, selbstorganisierten Prozesses. Dieser läuft oft hoch geordnet ab, obwohl kein übergeordneter Akteur (z. B. eine Ampel oder ein Verkehrspolizist) das Gesamtgeschehen dirigiert. Die Ordnung in selbstorganisierten Systemen bewegt

sich teils «am Rande des Chaos» – ihre Ordnungsmuster sind nicht vorsehbar, aber dennoch nicht zufällig. Auf Organisationen bezogen, stellt sich die Frage, was jeweils das passende Verhältnis von hierarchischer Einflussnahme versus selbstorganisiertem Handeln ist. Gelingt Selbstorganisation, kann sie mit Effizienzgewinnen und Synergieeffekten verbunden sein. (→ Prigogine; Kauffman; Haken)

Selbstreferenz

Selbstreferenz bedeutet, dass etwas auf sich selbst Bezug nimmt. Das Verhalten eines Systems erklärt sich nicht nur durch Außenbedingungen, sondern in Bezug auf aktuelle oder vergangene Zustände des Systems. Ein Diskussionsbeitrag in einem Gespräch ist nicht nur eine Reaktion auf die Außenwelt, sondern er bezieht sich meist auch auf eine zuvor geäußerte Aussage, an die der Beitragende gedanklich anknüpft. Ob, wann und in welcher Weise angeknüpft wird, ist meist schwer vorhersehbar. Selbstreferenz ist eines der grundlegendsten Prinzipien von menschlichem Verhalten und von Zusammenarbeit. (→ Maturana und Varela; von Foerster)

Selbstzeugnis

(engl.: personal testimonial) Literarisches Zeugnis eigenen Tuns, Denkens, Erlebens oder Ähnliches, eine Teilmenge der Ego-Dokumente.

Self Organisation

Selbstorganisation ist einer der augenfälligsten Aspekte, wenn man ScrumTeams beobachtet. Das Team als Ganzes ist einer der drei Manager in Scrum

(neben dem ScrumMaster und dem Product Owner). Es organisiert und verwaltet sich selbst (Self-Management), trifft eigenständig und ohne Anweisungen eines Vorgesetzten Entscheidungen. Es ist einzig dem Scrum-Prozess und seinen Regeln verpflichtet. D. h. beispielsweise, dass es, kulinarisch ausgedrückt, Sashimi bzw. Carpaccio abliefern muss – darunter verstehen wir in jedem Sprint ein Increment of Potentially Shippable Functionality, auf dessen Umfang und Inhalt sich das Team im Sprint Planning Meeting selbst verpflichtet hat, und zwar im Einklang mit den Priotitäten im Product Backlog.

Anmerkung: Selbstorganisation passiert nicht automatisch, weil die meisten Menschen auf das Command-and-Control-Verhaltensmuster konditioniert sind. Erst wenn die Team Members die Erfahrung machen, dass sie z.B. im Daily Scrum einander und nicht dem ScrumMaster oder dem Product Owner berichten, dass sie auch von keinem Außenstehenden unterbrochen werden, beginnt allmählich das Verständnis für die Eigenverantwortung und somit der Prozess der Selbstorganisation. Und dann – werden Teams wirklich effektiv!

Sequenziell

(engl.: sequential) Aufeinander folgend; der Reihe nach.

Service Desk

Struktureinheit, der operative Aufgaben des Störungsmanagements zugeordnet sind. Synonyme: Helpdesk, User-Help-Desk, Benutzerservice-Zentrum.

Serviceebene

(engl.: service level) Qualitätsniveau einer Dienstleistung (Dienstgüte).

Serviceebenenmanagement

(engl.: service level management) Führungsaufgaben, die mit der Festlegung von Serviceebenen und der Vereinbarung von Serviceebenen zwischen Dienstleistungsnehmer und Dienstleistungsgeber im Zusammenhang stehen.

Servicegrad

(engl.: service degree) Verhältnis von tatsächlichem zum vereinbarten Ausmaß der Dienstleistungsqualität.

Servicekatalog

(engl.: service catalogue) Beschreibung der von einem IT-Dienstleister angebotenen Services.

Servicekultur

(engl.. service culture) Ausmaß der Akzeptanz des Dienstleistungsgedankens und des gelebten Dienstleistungsbewusstseins im Unternehmen.

Sicherheit

(engl.: security, safety) Zustand, in dem alle schutzwürdigen Belange der Informationsinfrastruktur vor Beeinträchtigungen geschützt sind.

Sicherheitsgefährdung

(engl.: threat) Synonyme: Bedrohung, sicherheitsgefährdendes Ereignis.

Sicherheitskonzept

(engl.: security concept, security plan) Entwurf des Vorgehens zur Erreichung und Erhaltung des gewünschten oder geforderten Sicherheitsniveaus.

Sicherheitskriterien

(engl.: evaluation criteria) Kriterien zur Evaluierung von Produkten der ITSicherheit.

Sicherheitsleitlinie

(engl.: Information security policy; IT security policy) Beschreibung der wichtigsten Aussagen der Sicherheitsstrategie eines Unternehmens.

Sicherheitsmanagement

(engl.: security management) Gesamtheit der Führungsaufgaben, die sich mit Sicherheit der Informationsinfrastruktur befassen.

Sicherheitsmanagement-System

(engl.: security management system) Gesamtheit der Hilfsmittel des Sicherheitsmanagements.

Sicherheitsniveau

(engl.: security level) Ausmaß an geforderter oder vorhandener Sicherheit.

Sicherheitsstrategie

(engl.: security strategy) grundsätzliche Festlegungen der Unternehmensleitung zum Stellenwert der Informationssicherheit; die wichtigsten Aussagen der Sicherheitsstrategie werden in einer Sicherheitsleitlinie dokumentiert.

Situationsanalyse

(engl.: situation analysis) systematische Untersuchung der für ein System zu einem bestimmten Zeitpunkt oder Zeitraum relevanten Bedingungen.

Softwarearchitektur

Die Softwarearchitektur beschreibt die Strukturen eines Softwaresystems, dessen Komponenten und Schnittstellen sowie deren Zusammenspiel. Zur Beschreibung von Softwarearchitekturen werden verschiedene textuelle oder graphische Notationen eingesetzt.

Softwareengineering

Das Softwareengineering beschäftigt sich mit der ingenieurmäßigen Entwicklung von Software. Es umfasst Methoden, Techniken und Instrumente zur Erstellung von Software, das Management von Entwicklungsprojekten für Software sowie die Inbetriebnahme, den Betrieb und die Wartung von Software. Ziele des Softwareengineerings sind die Vermeidung von Fehlern, die Reduktion von Aufwänden und die Erhöhung des Kundennutzens von Software.

Softwarehinterlegung

Hinterlegung von Software-Quellcode durch den Lizenzgeber zugunsten des Lizenznehmers einer Software bei einer unabhängigen Stelle.

Soll/Ist-Vergleich

(engl.: target-performance comparison) systematische Gegenüberstellung von Kennzahlen mit Sollwerten und den gleichen Kennzahlen mit Istwerten.

Sollzustand

(engl.: target system) Gesamtheit der technischen, organisatorischen, personellen, sozialen und rechtlichen Bedingungen und Regelungen eines zu schaffenden Systems.

Source-Make-Deliver-Prinzip

An den drei Kernprozessen Beschaffung, Herstellung und Lieferung des Managements orientierter IM-Ansatz.

Sourcing

Beschaffung von Produkten oder Dienstleistungen von unternehmensinternen oder -externen Anbietern.

Sourcing & Vendor-System

Informationssystem zur Unterstützung der Verwaltung, Steuerung und Überwachung von Beziehung zu Lieferanten und Vertragspartnern.

Sourcingstrategie

(engl.: sourcing strategy) Teilstrategie, die beschreibt, in welchem Umfang Aufgaben und Betriebsmittel ausgelagert und welche Formen des Outsourcing in Anspruch genommen werden sollen (z. B. Cloud Computing).

Soziale Medien

(engl.: social media) Softwareanwendungen und darauf aufbauende Dienste, wie z. B. Weblogs, Wikis und soziale Netzwerke, die es Nutzern ermöglichen, miteinander zu kommunizieren und Inhalte gemeinschaftlich zu gestalten.

Soziale Systeme

Soziale Systeme basieren auf der Kommunikation und Interaktion von Akteuren. Die kommunikativen Koppelungen einzelner Akteure sind nicht zeitüberdauernd, sondern können je nach Aufgabenart rasch wechseln. Um die Effektivität zu steigern und komplexe Aufgaben besser bearbeiten zu können, differenzieren sich soziale Systeme in Subsysteme mit jeweils eigenen Logiken und Codes. In einem Unternehmen beispielsweise sind die Logiken und Erfolgsdefinitionen in der Finanzabteilung ganz andere, als in der Produktion oder Forschungsabteilung. In einem Staat funktioniert das Wirtschaftssystem nach anderen Erfolgsgrößen, als das Bildungssystem. Um in inter-disziplinären Projekten Probleme bearbeiten zu können und nicht an unterschiedlichen Logiken zu scheitern, sind Dialogbereitschaft und die Fähigkeit zum

Perspektiven-wechsel erforderlich. (→ Parsons; Luhmann)

Soziales Netzwerk

(engl.: social network) Web-basierte Plattform, z. B. Facebook, LinkedIn oder Xing, die es Nutzern ermöglicht, Beziehungen herzustellen und zu vertiefen.

Soziales Netzwerk

Der Netzwerkbegriff wird als Alternative zum Begriff des Systems verwendet. Während der Begriff «System» oft lokal nahe, eher starke sowie zeitstabile Elemente-Verknüpfungen nahelegt, ist der Begriff Netzwerk weiter und offener gedacht. Abgeleitet von der Graphentheorie besteht ein Netzwerk aus Elementen (Knoten, engl.: nodes, vertices) und Verbindungslinien (Kanten, engl.: edges). Soziale Beziehungen werden z. B. erfasst durch die Auflistung von Personen und sämtlicher Kontaktlinien zwischen den Personen.

Jacob Levy Moreno hat bereits in den 1930er Jahren Sozialstrukturen auf diese Weise dargestellt und dies Soziometrie genannt. In den 1970er Jahren wurde u. a. aufgezeigt, dass sich Innovationen eher über „schwache“ Beziehungen (engl. weakties) zwischen Menschen verbreiten, als über „starke“, nahe Beziehungen (engl. strong ties). Seit Ende der 1990er Jahre hat der moderne Netzwerk-Ansatz und seine computergestützten Analyse- und Testverfahren in Disziplinen wie Physik, Biologie, Medizin sowie den Sozialwissenschaften stark an Bedeutung gewonnen. Der leichte Zugriff auf internet-basierte Datenmengen von PersonenNetzwerken (beispielsweise auf Twitter und Facebook) haben das Interesse zahlreicher Forscher geweckt und die Verbesserung der Analyseverfahren vorangetrieben. (→ Barabasi; Strogatz; Watts)

Spezifikation

(engl.: specification) Dokument, das Anforderungen an ein Objekt festlegt.

Sprint

Mit „Sprint“ benennt Scrum eine Iteration, in der ein bestimmter Arbeitsumfang (Sprintziel) geplant wird. Ein Sprint ist als ein möglichst störungsfreier Arbeitsbeziehungsweise Entwicklungszyklus von zwei bis vier Wochen definiert.

In einer ersten Besprechung werden die Rahmenbedingungen abgesteckt: Wo und wann finden die täglichen Team-Meetings statt? Wie soll der allgemeine Aufbau des Produkts und/oder das Projektergebnis aussehen? Welche Meilensteine sind definiert? In welche Teilaufgaben lässt sich das Projekt untergliedern? Welche Konventionen und Schnittstellen sind einzuhalten?

Eine einzelne zu erledigende Aufgabe wird Scrum Task genannt. Alle Tasks sind im sogenannten Sprint Backlog aufgeführt, quasi die To-do-Liste für das Entwicklerteam. Aus jedem Arbeitszyklus kann das Team im Sprint Review sogenannte „Lessons Learned“ ableiten und für die weiteren Zyklen nutzen. Das Produkt gewinnt mit jeder Iteration an Umfang und Qualität. Der Projektfortschritt bleibt für den Kunden auf diese Weise stets transparent.

Eine Time-Box von 30 aufeinanderfolgenden Kalendertagen im klassischen Scrum. Inzwischen haben viele ScrumMasters die Erfahrung gemacht, dass in vielen Projekten kürzere Sprints von zwei Wochen oder sogar einer Woche besser geeignet für die Problemdomäne bzw. die Organisation des Kunden sind. (Die Wahl der richtigen Sprint-Länge ist ein Thema für sich und würde den

Rahmen dieses Glossars sprengen.)

Innerhalb eines Sprints tut das Team alles, um sein Versprechen einzulösen, die im Sprint Planning Meeting ausgewählte Menge von Requirements in ein Increment of Potentially Shippable Functionality zu transformieren und somit das Sprint Goal zu erreichen.

Während eines Sprints gibt es keine neuen oder geänderten Anforderungen von außen – der Product Owner und alle anderen Stakeholders sowie insbesondere die Chickens lassen das Team in Ruhe arbeiten. (Der ScrumMaster hat dafür Sorge zu tragen, dass diese Regel auch eingehalten wird.)

Was der Product Owner während des Sprints sehr wohl darf, ist, den Product Backlog im Hinblick auf zukünftige Sprints zu verändern, also Requirements in Form von Product Backlog Items neu in die Liste aufzunehmen oder Einträge zu streichen sowie Prioritäten und somit die Reihenfolge der Einträge zu verändern.

Sprint Backlog

Das Sprint Backlog ist eines der drei Artefakte innerhalb der agilen Projektmanagement Methode Scrum. Es gehört dem Development Team, welches hierin alle Anforderungen verwaltet, die es innerhalb des aktuellen Sprints abarbeiten wird.

Das Sprint Backlog wird während des Sprint Planning erstellt und beruht auf den Anforderungen des Product Owners. Damit diese überhaupt in das Sprint Backlog gelangen, müssen diese die sogenannte Definition of Ready (DoR) erfüllen und vom Team angenommen worden sein. Anders gesagt, nur

Anforderungen die kon-kret/detailliert genug sind und vom Team im Sprint Planning Phase I akzeptiert wurden, gelangen in diese Anforderungsliste.

Sobald das Sprint Planning Phase I abgeschlossen ist, startet das Developer Team mit der detaillierten Planung des Sprints, in dem es die angenommenen Anforderungen in einzelne Tasks zerlegt, in Reihenfolge bringt und untereinander zuordnet. Wie genau das geschieht, bleibt dem Team überlassen.

Das Sprint Backlog ist also letztendlich eine Sammlung aller Aufgaben (Tasks) innerhalb eines Sprints und wird von nun an täglich beim Daily Scrum aktualisiert. Auf-gaben, die erledigt sind, werden entsprechend markiert was dazu führt, dass man ein Echtzeitbild der Arbeit erhält, welches sich idealerweise in einem Burndown-Chart grafisch darstellen lässt.

Eine Liste von Tasks, welche den Arbeitsumfang des Teams für den Sprint festlegt. Die Liste präzisiert sich während des Sprints und wird täglich von allen Team Members gepflegt, so dass sie immer den aktuellen Bearbeitungsstand reflektiert. Der Sprint Backlog ermöglicht es dem ScrumMaster, jederzeit zu erkennen, wo das Team steht und ggf. steuernd einzugreifen, damit das Sprint Goal nicht in Gefahr gerät.

Sprint Backlog Task

Eine der konkreten Aufgaben im Entwicklungsprozess (inkl. Test und Dokumentation), welche das Team als notwendig zur Erreichung des Sprint Goals identifiziert hat.

Anmerkungen:

Ein Task ist eher technischer Natur im Gegensatz zu den fachlich orientierten Requirements im Product Backlog. Ein Task, dessen Umfang über zwei Personentage hinaus geht, sollte im Normalfall in weitere kleinere Tasks heruntergebrochen werden, weil ansonsten die Granularität der Schätzwerte nicht mehr zum Zweck des Sprint Backlogs passt. Üblicherweise besteht ein 1:nVerhältnis zwischen Requirements und Tasks. Alleine daraus ergibt sich schon, dass Tasks feingranularer als Requirements sind.

Sprint Cancellation

Der vorzeitige Abbruch eines Sprints durch den Scrum-Master sollte eine absolute Ausnahme sein. Gerade unerfahrenen Teams passiert es am Anfang oft, dass sie sich verschätzen und den ScrumMaster zum Abbruch des Sprints drängen. Meistens ist das jedoch nicht erforderlich, wenn geeignete Gegenmaßnahmen – Details würden den Rahmen des Glossars sprengen – rechtzeitig ergriffen werden. Mögliche Gründe für eine Sprint Cancellation sind z. B. unvorhersehbare drastische Änderungen des Arbeitsumfelds, die Unmöglichkeit, Hindernisse (rechtzeitig) aus dem Weg zu räumen oder eine massive Fehleinschätzung der Aufwände für den aktuellen Sprint.

Sprint Goal

Kurze, „knackige“ Formulierung des zu erreichenden Ziels für einen Sprint, möglichst in einem Satz. Das Sprint Goal wird durch den Product Owner formuliert, muss aber vom Team akzeptiert werden, damit es Gültigkeit erhält. P.S.: Das Sprint Goal ist ein optionales Scrum-Element, hilft dem Team aber, seine „Mission“ für den jeweiligen Sprint im Auge zu behalten.

Sprint Planning

Im Sprint Planning werden zwei Fragen beantwortet:

Was kann im kommenden Sprint entwickelt werden?

Wie wird die Arbeit im kommenden Sprint erledigt?

Die Sprint Planung wird daher häufig in zwei Teile geteilt. Die Sprint-Planung dauert in Summe maximal 2 Stunden je Sprint-Woche (also z. B. max. acht Stunden für einen 4-Wochen-Sprint).

Sprint Planning Meeting

Eintägiges Meeting am Anfang eines jeden Sprints innerhalb einer 8-stündigen Time-Box. Das Meeting ist aufgeteilt in zwei weitere Time-Boxes von jeweils 4 h:

In der ersten Hälfte präsentiert der Product Owner dem Team die Product Backlog Items mit der höchsten Priorität. Gemeinsam bestimmen beide Seiten, welche Untermenge des Product Backlogs das Team im kommenden Sprint in „Sashimi“ bzw. „Carpaccio“ (vgl. Increment of Potentially Shippable Functionality) verwandeln kann. Das Team verpflichtet sich (engl. „to commit“) auf den besprochenen Lieferumfang, welchen es soeben selbst mitbestimmt hat.

Während der zweiten Hälfte des Meetings plant das Team im Detail, wie es sein gegebenes Versprechen einlösen kann, indem es die betreffenden Requirements in Tasks herunterbricht und letztere zu einem Arbeitsplan in Form eines Sprint Backlog konsolidiert.

Sprint Retrospective Meeting

Meeting innerhalb einer 3-stündigen Time-Box im Anschluss an das Sprint Review Meeting, moderiert vom ScrumMaster. Das Team diskutiert rückblickend den soeben zu Ende gegangenen Sprint und überlegt sich, was weshalb gut oder schlecht gelaufen ist und was man tun könnte, um den nächsten Sprint produktiver und/oder angenehmer zu machen.

Sprint Review/ Retro-spektive

Die Sprint Retrospektive ermöglicht dem Team, systematisch zu lernen. Hier wird analysiert, welche Arbeitsprozesse verbessert werden müssen, damit das Team effektiver arbeiten kann. Die Resultate aus der Retrospektive werden im sogenannten Impediment Backlog festgehalten und lassen sich so als konkrete Verbesserungsvorschläge in die nächste Sprintplanung einbeziehen.

Sprint Review Meeting

Meeting am Ende eines jeden Sprints innerhalb einer 4-stündigen Time-Box. Hier zeigt das Team selbst – nicht irgendein übergeordneter Manager – dem Product Owner und anderen interessierten Personen live am funktionierenden System, was es innerhalb des Sprints erreicht hat.

Wichtig: keine Dummies, kein Powerpoint! Nur fertige Produktfunktionalität darf vorgeführt werden.

Stabstelle

(engl.: staff position) Struktureinheit (Abteilung oder Stelle) zur spezialisierten Aufgabenerfüllung mit einer unterstützenden Funktion für Führungs- oder Leitungsstellen.

Stakeholder

Der Begriff Stakeholder (Interessenvertreter, von engl. stake: Anteil) bezeichnet alle Personen oder Gruppen, die von der Entwicklung und vom Betrieb eines Systems in irgendeiner Weise betroffen sind, die also ein berechtigtes Interesse an diesem System haben.

Stand-Up

(auch „Daily Stand-up“ oder „Daily“): Tägliches Treffen aller Mitglieder eines agilen Teams – meist morgens/vormittags und tatsächlich im Kreis stehend. Innerhalb kürzester Zeit (typischerweise 15 Minuten) berichten alle Teammitglieder reihum, was sie seit dem letzten Stand-up geschafft haben, woran sie als nächstes arbeiten werden und was sie dabei gegebenenfalls behindert. Durch dieses Format soll das Team täglich in kürzester Zeit den vollen Überblick darüber bekommen, wer woran arbeitet, und kann erkennen wo Abstimmungs- und Unterstützungsbedarfe liegen.

Stärke

(engl.: strength) Entsprechung oder positive Abweichung der Eigenschaft eines Systems von einem definierten Standard (z. B. Sollzustand).

Stelle

(engl.: position) Kleinste Einheit der Strukturorganisation, der bestimmte Aufgaben, Kompetenzen, Sachmittel und Aufgabenträger zugeordnet sind.

Stellenbeschreibung

(engl.: job description) Schriftliche Aufzeichnung der einer Stelle zugeordneten Aufgaben und Aufgabenträger, der Über- und Unterstellungsbeziehungen, der Kompetenzen sowie der Anforderungen an die Qualifikation des Stelleninhabers.

Steuerung

(engl.: control) Betriebliche Aufgabe, die mit geeigneten Maßnahmen auf Abweichungen reagiert, um die bei der Planung getroffenen Entscheidungen durchzusetzen.

Stichprobe

(engl.: sample) nach einem Auswahlverfahren (z. B. dem der Zufälligkeit) festgelegter Teil der Grundgesamtheit, von dem gefordert wird, dass er repräsentativ ist.

Störereignis

(engl.: disturbance event) Ereignis, das zu einer unerwünschten Veränderung der Entwicklung und damit zu einem anderen als dem ursprünglich angestrebten Szenario führt.

Störung

(engl.: incident) unerwünschtes Ereignis, das IT-Dienstleitungen beeinträchtigen oder zum Ausfall eines Elements der IT-Infrastruktur führen kann.

Story- Points

In Scrum-Projekten wird häufig mit der Größe „Story Points“ gearbeitet. Mit den Story Points wird die Komplexität von Stories beschätzt. Nicht gleichzusetzen ist das mit einer Aufwandsschätzung.

Es handelt sich um einen Verhältniswert, die absolute Zahl ist unwichtig. Die Aussage: „Diese Story wurde mit 5 Story Points beschätzt“ kann also von

Projekt zu Projekt und von Team zu Team ganz unterschiedliche Implikation-en haben, was den Kostenrahmen angeht.

Was aber in jedem Fall gegeben sein soll, ist ein passendes Verhältnis der Beschätzung innerhalb eines Backlogs. Hat also in einem Backlog eine Story zwei Story Points zugewiesen bekommen, sollte dies das Doppelte von einer Story sein, die mit einem Story Point beschätzt wurde.

Eine gängige Zuordnung sieht in etwa wie folgt aus:

Punkte

Aufwand

T-Shirt-Größe

1

minimal

XS

2

klein

S

3

mittel

M

5

groß

L

8

sehr groß

XL

13

riesig

XXL

Agile Schätzverfahren

Die Aktivität „Schätzung“ ist die Erstellung einer Verknüpfung von Stories zu Komplexität. Es gibt verschiedene Vorgehensweisen, mit denen solche eine Verknüpfung hergestellt werden kann.

Strategie

(engl.: strategy) langfristig und unternehmensweit angelegte Verhaltens- und Verfahrensweise zum Aufbau und Erhalt von Erfolgspotenzial.

Strategieansatz

(engl.: strategy approach) systematische, auf Thesen oder Hypothesen beruhende Vorgehensweise bei der Strategieentwicklung.

Strategietyp

(engl.: strategy type) Positionierung einer Wettbewerbsstrategie bei Verwendung der Dimensionen Wettbewerbsfeld und Art des Wettbewerbsvorteils.

strategisch

(engl.: strategic) unternehmensweite, grundsätzliche und langfristig wirksame, den Unternehmenserfolg maßgeblich beeinflussende Handlung oder ein Objekt mit diesen Eigenschaften (z. B. ein Informationssystem).

strategische Lücke

(engl.: strategic gap) negative Abweichung der Ausprägung einer Eigenschaft der Informations-infrastruktur oder das Fehlen einer Komponente, wodurch die Erreichung der strategischen IT-Ziele negativ beeinflusst wird.

strategisches IT-Ziel

(engl.: strategic IT objective) Ziel, das die langfristige, unternehmensweite und den Wettbewerb positiv beeinflussende Veränderung der IT lenkt.

Struktureinheit

(engl.: organizaional unit) Strukturelement einer Organisation, unabhängig von Aufgabenumfang (z. B. sowohl Stelle als auch Abteilung) und Aufgabenart (z. B. sowohl Leitungs- als auch Ausführungsaufgabe). Synonyme: Organisationseinheit, Instanz.

Strukturelle Koppelung

Strukturelle Koppelung bedeutet, dass zwei Systeme aneinander angepasst sind und sie sich gegenseitig beeinflussen können. Während beispielsweise Körper und Psyche in vielen Aspekten als Systeme autonom funktionieren, sind sie jedoch zu gewissen Teilen strukturell gekoppelt, wie psychosomatische Phänomene illustrieren. Psyche und soziale Systeme sind über Sprache gekoppelt. In der Gesellschaft sind beispielsweise Regierungssystem und Wirtschaftssystem strukturell gekoppelt durch Steuern und Gesetze.

Ist die Koppelung zu eng oder einseitig, so verliert eines der beiden Systeme an eigenständiger Wirkungskraft. Entkoppeln sich Systeme zu stark, so besteht die Gefahr, dass der Kontakt schließlich ganz abbricht, wie bei einer Wissenschaftsdisziplin, die den Bezug zur Praxis verloren hat. (→ Maturana; Luhmann)

Strukturierte Daten

(engl.: structured data) Daten, für deren Elemente eine bestimmte Anordnung bzw. Struktur vorgeschrieben ist (z. B. in operativen Datenbanken oder DW). Synonym: formatierte Daten.

Strukturiertheit

(engl.: task structure) Ausmaß, in dem eine Aufgabe in genaue, einander eindeutig zuordenbare Tätigkeiten zerlegt werden kann.

subjektiver Informationsbedarf

(engl.: information need) von einem Aufgabenträger zur Erfüllung einer Aufgabe für erforderlich gehaltene Information. Synonym: Informationsbedürfnis.

Systeme

Wir sprechen von einem System, wenn es sich um eine Ganzheit handelt, die von ihrer Umwelt abgegrenzt/ unterschieden werden kann. Aus einer physikalischen Sichtweise bestehen Systeme aus Elementen und Relationen. Ein Sandhaufen ist kein System. Hingegen sind Zellen, Organismen, Menschen, Familien, Organisationen, Städte und Nationen vielseitige Beispiele für Systeme. Auch Theorien, Probleme und Projekte können als Systeme betrachtet werden. In Projektverläufen ist es sinnvoll, wiederholt zu klären, welche Elemente, Aspekte und Personen zum Kern gehören und was als Kontext vom System abgegrenzt werden soll. Die konstruktivistische Sichtweise argumentiert, dass Systeme nicht in der Welt klar abgegrenzt existieren, sondern dass diese Grenzen erst aus der Sicht eines Betrachters gezogen werden, was natürlich zu Mehrdeutigkeiten und Missverständnissen führen kann. (→ Bertalanffy; Vester; Luhmann)

Systemgrid

(engl.: system grid) zweidimensionales Raster mit in der Regel zwei oder drei Ausprägungen je Dimension zur Ordnung von Objekten.

Systemtheorie

(engl.: system theory) Wissenschaftsdisziplin, die allgemeingültige Gesetze über

Zustände und Verhalten von Systemen erarbeitet.

Szenario

(engl.: scenario) Darstellung eines möglichen zukünftigen Zustands eines Systems als Ergebnis der Anwendung der Szenariotechnik (von griech. Skene = Schauplatz einer Handlung, eine Szenenfolge). Synonym: Zukunftsbild.

Szenarioarchetyp

(engl.: scenario archetype) jedes der (in der Regel) beiden in sich konsistenten, stabilen und disjunkten Szenarien, aus denen die Leitstrategie abgeleitet wird.

Szenariotechnik

(engl.: scenario technique) Verfahren zur Gewinnung von Information über zukünftige Entwicklungen offener Systeme für die Formulierung von grundlegenden Konzepten wie Strategien und Teilstrategien.

Szenariotrichter

(engl.: scenario cone) grafische Darstellung mehrerer möglicher Abläufe, die zwischen der Gegenwart und der Zukunft liegen, sowie zukünftiger Zustände zwischen zwei Extremszenarien unter dem Einfluss von Störereignissen und von Maßnahmen.

T

Tailoring

Anpassung (z. B. eines Vorgehensmodells) an die aktuelle Aufgabe.

Tätigkeit

(engl.: work element) Teilaufgabe, die bei einem gegebenen Untersuchungszweck nicht weiter zerlegt werden kann. Synonyme: Aktivität, Arbeitsschritt, Operation.

TDD

Bei der sogenannten „Test-Driven Development“, also bei der testgetriebenen Entwicklung werden Tests dazu benutzt, um die Softwareentwicklung zu steuern. Dies befolgt stets zyklisch in den drei Stufen: 1. Schreiben, 2. Implementieren, 3. Refaktorisieren.

Team

Der Dreh- und Angelpunkt eines Scrum-Projektes. Das Team ist eine gemischte,

interdisziplinäre Gruppe aus z.B. Entwicklern, Testern und Redakteuren für die Dokumentation. Grundsätzlich gehören dem Team Leute aus allen Disziplinen an, die notwendig sind, damit in einem Sprint ein Increment of Potentially Shippable Functionality entwickelt werden kann, also etwas, das das Attribut Done verdient.

Wichtig: Das Team ist sein eigener Manager (vgl. Self-Organisation).

Teammitglied

(engl.: team member) Scrum definiert die Rolle des Teammitglieds als Bezeichnung für die interdisziplinären Kollegen im Scrum-Team wie Entwickler, Architekt, UI-Designer, Tester etc. Das Team agiert selbstorganisiert und ist gemeinschaftlich verantwortlich für das Erreichen der Sprintziele.

Teamvelocity

Eng mit den Schätzungen zusammen hängt die Messung der Geschwindigkeit, mit der ein Team Product Backlog-Items umsetzen kann. Diese wird als „Teamvelocity“ bezeichnet und in Story Points angegeben.

In Scrum-Projekten wird die Größe zum Ende eines jeden Sprints erhoben. Einbezogen werden nur die Stories, die vom Product Owner im Review-Meeting oder im Sprint-Verlauf als abgeschlossen gewertet werden. Nicht entsprechend der „Definition of Done“ abgeschlossene Arbeiten werden mit 0 Story Points bewertet. Bereits nach wenigen Sprints bildet sich eine Vorstellung heraus, wie viele Story-Points das Team pro Sprint realisieren kann.

Diese Angabe hilft dem Team wiederum, im Rahmen der Sprint-Planung eine realistische Einschätzung dessen abzugeben, was es innerhalb eines Sprints umsetzen kann.

Technologielücke

(engl.: technology gap) Abstand zwischen der technologisch möglichen Qualität und der tatsächlichen Qualität eines Produkts oder einer Dienstleistung, der durch die Technologieentwicklung verursacht wird.

Technologischer Korridor

(engl.: technological trajectory) Phänomene, die dafür verantwortlich sind, dass ein Unternehmen aus ökonomischen und/oder technischen Gründen an bestimmten Technologien festhält, obwohl neue Technologien zur Verfügung stehen.

Teilstrategie

(engl.: substrategy) Strategie, die sich auf bestimmte Objekte, Eigenschaften, Ziele, Technologien oder auf Phasen des Technologieeinsatzes bezieht.

Testdaten

(engl.: test data) Eingabewerte, die bei der Testdurchführung verwendet werden.

Testdatenkombination

(engl.: test data combination) Testdaten, die gemeinsam bei der Ausführung eines Testobjekts verwendet werden.

Testen

(engl.: test) Prüfung eines Softwaresystems oder von dessen Komponenten durch Ausführen mit Testdaten mit dem Ziel, Fehler zu finden.

Testfall

(engl.: test case) Klasse von Eingabedaten, mit denen ein bestimmter Aspekt des Verhaltens eines Testobjekts geprüft werden soll.

Testobjekt

(engl: test object) zu testender Gegenstand (z. B. eine Softwarefunktion, ein Softwaremodul oder ein Softwaresystem).

Testverfahren

(engl.: test method) begründete Vorgehensweise zur Aufdeckung einer bestimmten Klasse von Fehlern.

Time-Box

Zeitabschnitt, der nicht überschritten werden darf und in dessen Grenzen ein Meeting abläuft. Beispiel: Ein Daily Scrum endet nach Ablauf der Time-Box von 15 Minuten, egal ob jemand noch etwas sagen zu müssen glaubt oder nicht. Die Time-Box ist eines der grundlegenden Konzepte in Scrum und trägt maßgeblich zur Effizienz des Prozesses bei. Das Konzept aufzuweichen, indem man es nicht ernst nimmt, ist ein zielsicherer Pfad zur Verschlechterung das Projektergebnisses.

Top-down

Eine Entscheidung wird top-down genannt, wenn sie von in der Hierarchie höherstehenden Mitarbeitern getroffen wird, aber Auswirkungen auf die in der Hierarchie niedrigeren Mitarbeiter hat.

Totalerhebung

(engl.: total survey) Form der Querschnittsanalyse, bei der Merkmale aller Untersuchungseinheiten einer statistischen Grundgesamtheit erfasst werden.

TQM

Total Quality Management; ganzheitliches bzw. umfassendes QM.

Transaktionskosten

(engl.: transaction costs) Kosten für Anbahnung, Vereinbarung, Abwicklung, Steuerung, Kontrolle und Anpassung der Leistungserstellung.

Trendszenario

(engl.: trend scenario) Szenario, das sich durch Trend-Extrapolation aus dem Istzustand (Null-Szenario) ergibt; es liegt im Mittelpunkt des Szenario-Trichters.

U

Überwachung

(engl.: monitoring) betriebliche Aufgabe der Beobachtung und Beurteilung, die in die Teilaufgaben Revision und Kontrolle gegliedert ist.

Unternehmenskultur

(engl.: corporate culture) Muster von Prämissen (z. B. Normen, Werte und Wahrnehmungen), das von den Unternehmensmitgliedern im Umgang mit der externen und internen Umwelt erlernt und durch Sozialisation weitergegeben wird.

Unternehmensstrategie

(engl.: corporate strategy) Strategie, die auf die Beantwortung der Frage gerichtet ist, was das Unternehmen in Zukunft aus welchen Gründen sein will.

Unternehmenstypologie

(engl.: enterprise typology) Systematik zum Einschätzen der strategischen Rolle

der Informationsfunktion in Abhängigkeit vom Leistungspotenzial.

User Experience

Der Begriff User Experience (kurz: UX, deutsch: Nutzererfahrung, Nutzererlebnis) beschreibt die Wahrnehmungen und die emotionalen, psychologischen sowie physiologischen Reaktionen einer Person, die sich bei bzw. nach der Benutzung oder durch die erwartete Benutzung eines Produktes ergeben. Diese Wahrnehmungen und Reaktionen werden beeinflusst von der Gestaltung, der Funktionalität und den Leistungsmerkmalen des Produktes, von den Vorkenntnissen und Eigenschaften des jeweiligen Nutzers sowie von der Markenwahrnehmung und dem Kontext der Nutzung. Der Begriff User Experience wird insbesondere in Zusammenhang mit Websites oder Apps verwendet, bezieht sich aber auch auf nichtdigitale Produkte.

User Experience Engineering

User Experience Engineering bezeichnet die systematische Verwendung von Prinzipien, Methoden und Werkzeugen, mit denen eine positive User Experience bei den späteren Nutzern eines Produkts erzeugt werden soll. Das User Experience Engineering findet parallel zur klassischen Planungs- und Entwicklungsarbeit.

User Story

User Stories sind eine Technik zur Beschreibung von Anforderungen aus der Perspektive eines Benutzers unter Verwendung von Alltagssprache.

User Story Maps

Eine User Story Map ist eine zweidimensionale, tabellenartige Darstellung einer Sammlung von User Stories, mit dem Zweck einen Überblick über das System zu bekommen.

V

Validierung

(engl.: validation) Prüfung der Tauglichkeit eines Objektes für die vorgesehene Aufgabe.

Validität

(engl.: validity) Ausmaß, mit dem eine Messgröße die Eigenschaft, die sie messen soll, auch tatsächlich misst.

Velocity

Agile „Velocity“ ist eine spezifische Kennzahl, die sagt, wie viel Arbeit ein Software-Entwicklungs-Team innerhalb eines Sprint-Zeitraums erledigen kann.

Veränderlichkeit

(engl.: task variability) Häufigkeit und Vorhersagbarkeit von Änderungen, die vom Aufgabenträger bei der Aufgabenerfüllung zu berücksichtigen sind.

Verfahren

(engl.: procedure) festgelegte Art und Weise, eine Tätigkeit oder einen Prozess auszuführen (vgl. DIN EN ISO 9000).

Verfahrensdokumentation

(engl.: procedure documentation) eine aus System-, Programm- und Benutzerdokumentation bestehende Dokumentation.

Verfügbarkeit

(engl.: availability) Fähigkeit eines Systems, seine konstruktionsbedingten Funktionen erfüllen zu können.

Verifizierung

(engl.: verification) Prüfung eines Objektes gegen die Spezifikation.

Verrechnungspreis

(engl.: transfer rate) Preis für innerbetriebliche Leistungen, die zwischen den Struktureinheiten ausgetauscht werden. Synonym: Lenkungspreis.

Version

(engl.: version) Ausprägung eines Systemelements zu einem bestimmten Zeitpunkt.

Vertrag

(engl.: contract) das durch Antrag und Annahme zwischen zwei oder mehreren Personen zum Abschluss gelangende Rechtsgeschäft.

Vertragsbestand

(engl.: contract inventory) Gesamtheit der im Unternehmen vorhandenen Verträge über die Lieferung und Wartung von Produkten und das zur Verfügung stellen von Dienstleistungen des IT-Markts.

Vertragsrecht

(engl.: contract law) Recht, das die zwischen Privatpersonen oder juristischen Personen frei verhandelten und vereinbarten Rechtsbeziehungen regelt.

Virtualisierung

(engl.: virtualization) Erzeugung nicht-physikalischer (virtueller) Objekte (z. B. logische Hosts), die in Form und Wirkung einem realen Objekt entsprechen (z. B. einem physischen Host).

VUCA

Akronym: 1. Volatility (Schwankung), 2. Uncertainty (Unsicherheit), 3. Complexity (Komplexität) und 4. Ambiguity (Ambiguität)

W

Wartbarkeit

(engl.: maintainability) Eigenschaft eines Objekts (z. B. eines Anwendungsprogramms), an veränderte Anforderungen anpassbar zu sein.

Wartung

(engl.: maintenance) Erhaltung oder Wiederherstellung der Funktionsfähigkeit oder der Leistungsfähigkeit von Betriebsmitteln.

Wettbewerbsfaktor

(engl.: competitive factor) Eine Wettbewerb kennzeichnende Eigenschaft des Marktes, in dem ein Unternehmen tätig ist (z. B. Lieferzeit, Qualität, Preis).

Wettbewerbsfeld

(engl.: competition site) gedanklicher Raum, in dem ein Unternehmen mit seinen Produkten in Kontakt mit Kunden und in Konkurrenz mit anderen Anbietern tritt.

Wettbewerbsstrategie

(engl.: competitive strategy) Teilstrategie der Unternehmensstrategie, die festlegt, wie bei der Verfolgung strategischer Marktziele vorgegangen werden soll.

Wettbewerbsvorteil

(engl.: competitive advantage) Eigenschaft des Unternehmens, die es von seinen Mitbewerbern unterscheidet und im Wesentlichen durch den Wert bestimmt ist, den es seinen Kunden durch Kostensenkung und/oder Leistungssteigerung bietet.

WIP

WIP (= Work In Progress) ist ein Strategie, die darauf abzielt, Engpässe zu verhindern, indem die Zahl der angefangenen Arbeiten limitiert wird.

Wireframe

Grob ausgearbeiteter Prototyp einer grafischen Oberfläche, der aus wenig mehr als nur Strichen besteht, und so vom Aussehen her an ein „Drahtgitter“ erinnert.

Wirtschaftlichkeit

(engl.: efficiency) Verhältnis von Nutzen und Kosten eines Objekts.

Wissen

(engl.: knowledge) Gesamtheit der Kenntnisse und Fähigkeiten zur Lösung von Problemen.

Wissen und Gedächtnis

Nur sehr einfache Systeme verwenden zur Steuerung ausschließlich den direkt vorliegenden externen Input. Komplexere Systeme beziehen bisherige Erfahrung und fremdes Wissen mit ein. Dies birgt viele Vorteile, bringt aber auch gewisse Nachteile mit sich. In komplexen und dynamischen Situationen besteht dauernd ein Dilemma: Sich ständig komplett neu zu orientieren ist zu aufwändig und würde zeitgerechtes Handeln verhindern. Andererseits können die auf früherer Erfahrung beruhenden «Karten» veraltet sein und daher Fehler und Lücken aufweisen. Eine mögliche Strategie besteht darin, das aktualisierte Wissen nicht von einer einzelnen Fachperson verwaltet zu lassen, sondern dass alle Akteure gemeinsam zur Hinterfragung und Erneuerung des zentralen Wissensbestandes beitragen. Firmeninterne Informationstafeln und Wikis bieten solche Möglichkeiten. (→ Vester; Willke)

Wissensbasis

(engl.: knowledge base, organizational memory) Gesamtheit des in einem Unternehmen verfügbaren relevanten Wissens.

Wissensbestand

(engl.: knowledge asset) inhaltlich zusammenhängende Teilmenge der Wissensbasis.

Wissenschaftsaufgabe

(engl.: scientific task) zur Erreichung der Wissenschaftsziele erforderliche Aufgabe zur Untersuchung ihres Gegenstandsbereichs (Beschreibung, Erklärung, Prognose und Gestaltung)

Wissensentwicklung

(engl.: knowledge development) unternehmensinterne Entwicklung von Wissen.

Wissenserwerb

(engl.: knowledge acquisition) Erwerb externen Wissens.

Wissenskarte

(engl.: knowledge map) grafisches Verzeichnis von Wissensquellen bzw. Wissensträgern, Wissensbeständen, Wissensstrukturen oder Wissensanwendungen.

Wissenslücke

(engl.: knowledge gap) benötigtes, aber nicht verfügbares Wissen (Synomym: Wissensdefizit).

Wissensmanagement

(engl.: knowledge management) Führungsaufgabe, die sich mit der zielorientierten Nutzung und Weiterentwicklung von Wissen im Unternehmen befasst.

Wissensmanagementstrategie

(engl.: knowledge management strategy) grundsätzliche Festlegungen zur Gestaltung des Wissensmanagements.

Wissensobjekt

(engl.: knowledge object, knowledge bearer) Einheit, welche Wissen

repräsentiert (Synomym: Wissenselement).

Wissensträger

(engl.: knowledge bearer) Aufgabenträger, der über relevantes Wissen verfügt

Wissenstransformation

(engl.: knowledge transformation) Umwandlung von Wissen von einer Repräsentationsform in eine andere.

Workflow

ausführbares Abbild eines Geschäftsprozesses.

Z

Zeitvergleich

(engl.: period comparison) systematische Gegenüberstellung von Kennzahlen mit Werten aus verschiedenen Perioden. Synonym: Periodenvergleich.

Zeremonie

Elitärer Sammelbegriff für Prozess-Artefakte, d. h. bestimmte Bräuche, die agile Methoden mitbringen. Beispiele sind bestimmte Meeting-Formen wie das Daily Stand-up, Retrospektiven oder ähnliches.

Zerlegung

(engl.: decomposition) systematisches, zielorientiertes Verändern eines Objekts so, dass Teilobjekte entstehen, die bzgl. der verfolgten Ziele möglichst homogen sind.

Zertifizierung

(engl.: certification) Bestätigung durch eine autorisierte Prüfstelle, dass ein

Objekt definierten Anforderungen entspricht.

Ziel

(engl.: objective) angestrebter Endpunkt eines menschlichen Handlungsprozesses.

Zielbeziehung

(engl.: goal relation) Tatsache, dass die Erfüllung eines Ziels die Erfüllung eines anderen Ziels beeinflusst.

Zielertrag

(engl.: goal profit) Ausmaß der Zielerreichung bezüglich eines Zielkriteriums. Synonym: Zielerreichungsgrad.

Zielertragsmatrix

(engl.: goal profit matrix) Matrix, die in den Zeilen die Alternativen und in den Spalten die Kriterien enthält; die Elemente der Matrix sind die Zielerträge.

Zielhierarchie

(engl.: goal hierarchy) stufenmäßig aufgebaute Ordnung der Elemente eines Zielsystems in Form einer Rangordnung mit von oben nach unten abnehmender Bedeutung.

Zielorientierung

Systeme, die ihre Ziele und Erfolgskriterien selbstgesteuert verändern können, werden auch als autonom bezeichnet. Russell Ackoff spricht von zweckorientierten respektive zielorientierten Systemen. Organisationen entstehen nicht einfach von selbst, sondern werden aufgrund menschlicher Absichten als zweckorientierte Systeme gestaltet, betont Hans Ulrich. Organisationen greifen beispielsweise gesellschaftliche Probleme auf und entwickeln daraus für ausgewählte Kunden gezielte Dienstleistungen und Produkte. Niklas Luhmann weist darauf hin, dass psychischen und sozialen Systemen im Grunde immer mehr Möglichkeiten zum Handeln offen stehen, als sie pro Zeiteinheit realisieren können. Auf-grund dieser Komplexität erfordert die Auswahl von Handlungsschritten eine ständige Aktualisierung dessen, was gerade sinnvoll ist und den Zweck am besten erfüllt. (→ Ulrich; Luhmann)

Zielplanung

(engl.: goal setting) Prozess des Festlegens (Setzens) von Zielen nach Inhalt, Maßstab, Ausmaß der Zielerreichung und zeitlichem Bezug.

Zielsystem

(engl.: goal system) geordnete Menge von Zielen, zwischen denen Beziehungen bestehen, die idealtypisch gesehen komplementär, konfliktär oder indifferent sind.

Zielwert

(engl.: goal value) Abbildung eines Zielertrags auf einer nominalen, ordinalen oder kardinalen Skala (Skalierung). Synonym: Teilnutzen.

Zielwertmatrix

(engl.: goal value matrix) Matrix, die in den Zeilen die Alternativen und in den Spalten die Zielkriterien enthält; die Elemente der Matrix sind die Zielwerte.

Zirkularität und Autopoiese

Viele Prozesse, die über längere Zeit bestehen, wirken auf sich selbst zurück und haben als eines ihrer Ziele, sich selbst aufrecht zu erhalten. Der Begriff Autopoiese bezeichnet die Fähigkeit eines Systems, „sich selbst zu schaffen“. Auch in Unternehmen gibt es zahlreiche autopoietische Prozesse. Einige davon sind überlebensnotwendig, andere sind wenig konstruktiv, aber widersetzen sich einer Auflösung.

Unter diesem Gesichtspunkt können Routinen, Traditionen und Gewohnheiten reflektiert werden. (→ Maturana und Varela; Luhmann)

Impressum:

Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über www.dnb.de abrufbar.

© 2017 Dietmar Prudix

Herstellung und Verlag: BoD – Books on Demand GmbH, Norderstedt ISBN 9 783 744 865692

Vom selben Autor erschienen:

Co-Autor, Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit Projektweisheiten Einfache Regeln für ein effektives Projektmangement Glossar Claim Management Erfolgreiches Projektmanagement