1 Informationssysteme und IS-Management ★★
Hier geht es um die Frage, wie digitale Güter überhaupt entstehen: Wer plant, baut, steuert und betreibt die Systeme, mit denen ein Unternehmen Wert für Kund:innen und andere Stakeholder schafft? Die Antwort liefert das IS-Management.
Was ein Informationssystem ist
Informationssystem (IS): ein System aus Menschen und Maschinen, die Information erzeugen und nutzen und über Kommunikationsbeziehungen miteinander verbunden sind.
Wichtig ist das Wort „Menschen“: Ein IS ist nicht nur Technik. Zum IS einer Bäckerei gehören die Kassa, das Bestellprogramm und der Server, aber genauso die Verkäuferin, die Bestellungen eintippt, und der Chef, der am Abend die Umsätze auswertet.
Einfach erklärt: Ein Informationssystem ist wie ein Nervensystem im Unternehmen. Technik (Kabel, Rechner, Software) und Menschen (die Information liefern, lesen und danach handeln) arbeiten zusammen, damit die richtige Information zur richtigen Stelle kommt.
Prüfungsfalle: „Ein Informationssystem besteht ausschließlich aus Hardware und Software“ ist falsch. Zu einem IS gehören Menschen und Maschinen samt ihrer Kommunikationsbeziehungen.
Was IS-Management bedeutet
IS-Management: alle organisatorischen, planerischen und dispositiven (steuernden, anordnenden) Tätigkeiten, die nötig sind, um betriebliche Informationssysteme zu planen, zu entwickeln, zu betreiben und zu kontrollieren.
Die vier Aufgaben lassen sich gut mit einem bekannten Kreislauf merken:
Der PDCA-Zyklus als roter Faden
PDCA-Zyklus: ein Kreislauf aus Plan – Do – Check – Act (planen – umsetzen – prüfen – handeln/verbessern), der immer wieder von vorne beginnt.
| Phase | Bedeutung | Im IS-Management |
|---|---|---|
| Plan | vorausdenken | IS-Planung (was brauchen wir, welche Software?) |
| Do | umsetzen | IS-Entwicklung (System bauen, anpassen, einführen) |
| Check | prüfen, steuern | Kontrolle und Steuerung, etwa durch IT-Governance und Tests |
| Act | handeln, laufend betreiben | IS-Betrieb (System am Laufen halten, mit Daten und Wissen weiterentwickeln) |
Dieses Kapitel deckt vor allem Plan, Do und Check ab. Der laufende Betrieb (Act) wird mit dem Thema Daten, Datenbanken und betriebliche Anwendungssysteme fortgesetzt.
Prüfungsfalle: Die IS-Entwicklung gehört zur Phase Do, nicht zu Plan. Die IS-Planung ist Plan, der IS-Betrieb ist Act.
VertiefungWarum ein Kreislauf und keine Einbahnstraße?
Ein Informationssystem ist nie „fertig“. Gesetze ändern sich, Kund:innen wollen neue Funktionen, Hardware veraltet, neue Sicherheitslücken tauchen auf.
So schließt sich der Kreis. Der Gedanke passt zur Leitidee der Betriebswirtschaft: Unternehmen schaffen Wert für ihre Stakeholder, indem sie sich durch laufende Innovation an neue Bedürfnisse anpassen. Das IS-Management ist die Maschinerie, die solche digitalen Innovationen hervorbringt und am Leben hält.
Ein Beispiel durch alle vier Phasen: Ein Fahrradverleih will eine Buchungs-App.
2 IS-Planung und Softwarestrategie ★★★
Bevor ein System gebaut oder gekauft wird, muss man es durchdenken. Kernfrage der IS-Planung ist vor allem: Welche Software soll das Unternehmen verwenden und wie kommt es zu ihr?
Was Planung heißt
Planung: ein vorbereitendes Durchdenken. Man nimmt künftige Aktivitäten gedanklich vorweg, legt ihre sinnvolle Reihenfolge fest und stellt die nötigen Ressourcen bereit.
Das Ziel: Die Aktivitäten sollen später mit möglichst geringen Reibungsverlusten ablaufen.
Einfach erklärt: Wer vor dem Umzug plant, welche Kisten zuerst ins Auto kommen und wer wann hilft, spart sich am Umzugstag Chaos. Genauso spart gute IS-Planung später teure Umwege.
Strategische Softwareplanung
Software ist das Kernstück jedes Informationssystems: Sie sorgt dafür, dass IT-gestützte Funktionen und Prozesse automatisch ablaufen.
An Software kommt ein Unternehmen auf mehreren Wegen:
Welcher Weg der beste ist, hängt von der jeweiligen Situation ab. Es gibt also keine Pauschalantwort.
Software-as-a-Service (SaaS)
Software-as-a-Service (SaaS): Die Software wird nicht auf dem eigenen Rechner installiert, sondern läuft auf den Servern des Anbieters und wird über das Internet genutzt.
Einfach erklärt: SaaS ist wie Streaming statt DVD. Du besitzt den Film nicht, sondern darfst ihn nutzen, solange du zahlst. Ein Kaffeehaus, das sein Kassensystem online im Abo nutzt, verwendet SaaS.
Prüfungsfalle: Bei SaaS kauft man die Software nicht und installiert sie auch nicht lokal. Man erhält nur Nutzungsrechte, die Software bleibt beim Anbieter.
Die zwei Grundentscheidungen
Bei der strategischen Softwareplanung sind zwei Fragen zu klären. Sie sind voneinander unabhängig:
| Frage | Option A | Option B |
|---|---|---|
| 1. Wie allgemein soll die Software sein? | Standardsoftware | Individualsoftware |
| 2. Kaufen oder frei nutzen? | Kommerzielle Software | Open-Source-Software |
Standardsoftware (packaged software): vorgefertigte Programme, die auf allgemeine Anwendbarkeit und mehrfache Nutzung ausgelegt sind. Viele Anwender:innen setzen sie für ähnliche oder wiederkehrende Aufgaben ein (z. B. Tabellenkalkulation, Buchhaltungsprogramm).
Individualsoftware (custom software): Programme, die speziell für einen bestimmten Anwendungsfall entwickelt und meist auf ein konkretes Aufgabenprofil zugeschnitten sind (z. B. eine Tourenplanung, die nur genau für die Lieferwege einer Bäckereikette gebaut wurde).
Kommerzielle Software (commercial software): von Unternehmen entwickelt mit dem Ziel, durch Verkauf oder Nutzung Geld zu verdienen.
Open-Source-Software (OSS): Software, deren Quelltext für alle einsehbar und frei verfügbar ist. Es gibt verschiedene Lizenzen, die unterschiedlich viel Freiheit beim Verwenden und Weiterverbreiten gewähren.
Prüfungsfalle: Standard vs. Individual und kommerziell vs. Open Source sind zwei verschiedene Fragen. Open Source ist nicht das Gegenteil von Standardsoftware, sondern das Gegenstück zu kommerzieller Software.
Prüfungsfalle: Open Source heißt nicht „ohne Regeln“. Es gibt verschiedene Lizenzen mit unterschiedlichen Freiheitsgraden.
Vorteile von Standardsoftware
| Vorteil | Warum? |
|---|---|
| Kostengünstigkeit | Die Entwicklungskosten teilen sich viele Käufer:innen. |
| Zeitersparnis | Ein ausgereiftes Programm anpassen geht meist viel schneller als neu entwickeln. |
| Engpässe ausgleichen | Fehlendes Personal oder Know-how im eigenen Haus wird kompensiert. |
| Zukunftssicherheit | Seriöse Anbieter entwickeln ihre Produkte ständig weiter. |
Vorteile von Open-Source-Software
| Vorteil | Warum? |
|---|---|
| Individualisierung | Zugriff auf den Quellcode: Man kann das Programm beliebig anpassen und sicherheitskritische Funktionen selbst prüfen und bei Bedarf abschalten. |
| Transparenz | Weil der Code offen ist, werden Fehler schneller entdeckt und behoben. |
| Kollaboration | Kein einzelnes Unternehmen schränkt die Nutzung ein; eine Community im Internet pflegt die Software gemeinsam. |
| Flexibilität | Pflege und Weiterentwicklung hängen nicht von einer Firma ab; jede interessierte Person könnte sie übernehmen. |
Prüfungsfalle: Zukunftssicherheit ist ein Vorteil der Standardsoftware (Anbieter entwickelt weiter). Flexibilität im Sinn von „hängt nicht von einer Firma ab“ ist ein Vorteil von Open Source. Diese Zuordnungen werden gern vertauscht.
Prüfungsfalle: Transparenz bei Open Source bedeutet: Fehler werden durch den offenen Code schneller gefunden. Es heißt nicht, dass Open-Source-Software fehlerfrei ist.
VertiefungKombinationen und Gegenargumente
Die zwei Fragen lassen sich kombinieren:
Die Kehrseite (Allgemeinwissen zur Einordnung):
Warum Software „Kernstück“ ist: Hardware ohne Software tut nichts. Erst die Software legt fest, welche Abläufe automatisch passieren, z. B. dass nach einer Online-Bestellung automatisch eine Rechnung erstellt wird.
3 IT-Governance ★★★
Ein Unternehmen gibt viel Geld für IT aus. IT-Governance sorgt dafür, dass man diese IT durchschaut, steuern kann und dass sie in dieselbe Richtung zieht wie das restliche Unternehmen.
Begriff und Ziel
IT-Governance: Maßnahmen, Strukturen und Prozesse, die die IT-Leistungen eines Betriebs transparenter und leichter steuerbar machen.
Ein zentrales Ziel: Die IS-Strategie soll mit der übrigen Unternehmensstrategie übereinstimmen.
Einfach erklärt: Will ein Kaffeehaus vor allem mit persönlichem Service punkten, wäre es seltsam, das ganze IT-Budget in einen Bestellroboter zu stecken. IT-Governance sorgt dafür, dass IT-Entscheidungen zur Gesamtstrategie passen.
Frameworks: Was und Wie
In der IT-Governance werden Frameworks, Rahmenmodelle oder Standards als Richtlinien vorgeschlagen, um bestimmte Vorgaben oder Anforderungen zu erfüllen. Sie beantworten zwei Fragen:
COBIT und ITIL
Zwei der wichtigsten Rahmenmodelle:
| Modell | Langform | Wofür? |
|---|---|---|
| COBIT | Control Objectives for Information and Related Technology | Framework für IT-Governance |
| ITIL | Information Technology Infrastructure Library | Sammlung von Richtlinien für IT-Servicemanagement |
Beide Rahmenwerke enthalten den PDCA-Zyklus.
Prüfungsfalle: COBIT = IT-Governance-Framework. ITIL = Richtlinien für IT-Servicemanagement. Merkhilfe: ITIL hat ein „I“ wie „Infrastruktur und Services“, COBIT ein „C“ wie „Control“.
Die sechs Prinzipien von COBIT 2019
COBIT 2019 ist ein Framework für Steuerung (Governance) und Management von IT, das auf das Gesamtunternehmen ausgerichtet ist. Es folgt sechs Prinzipien:
Einfach erklärt: Die sechs Prinzipien als Satz gemerkt: „Für alle Stakeholder, im ganzen Unternehmen, mit einem stimmigen Rahmen, ganzheitlich, Steuern und Ausführen getrennt, und immer beweglich.“
Prüfungsfalle: Ein COBIT-Prinzip ist die Trennung von Governance und Management, nicht deren Zusammenlegung.
Prüfungsfalle: COBIT 2019 bezieht sich auf das gesamte Unternehmen, nicht nur auf die IT-Abteilung. Und das Governance-System ist dynamisch, nicht starr.
VertiefungGovernance vs. Management: was der Unterschied ist
Governance heißt: Richtung vorgeben, Ziele und Prioritäten festlegen und überwachen, ob sie erreicht werden. Das ist Aufgabe der obersten Ebene (etwa Geschäftsführung oder Aufsichtsrat).
Management heißt: im Rahmen dieser Vorgaben planen, bauen, betreiben und überwachen, also die Arbeit tatsächlich organisieren.
Warum trennen? Wer die Arbeit macht, soll sich nicht selbst die Ziele setzen und sich selbst kontrollieren. Das ist dieselbe Idee wie bei der Corporate Governance: Kontrolle und Ausführung werden auseinandergehalten.
Zu den anderen Prinzipien kurz erklärt:
4 IS-Entwicklung und Requirements-Engineering ★★★
Die IS-Entwicklung ist die Do-Phase: Hier wird umgesetzt, was in der Planung beschlossen wurde. Der wichtigste und fehleranfälligste Schritt ist der allererste: herausfinden, was das System überhaupt können soll.
Begriff
IS-Entwicklung: setzt die in der IS-Planung erstellten Projektaufträge um. Sie entwickelt, passt an und führt ein.
Dabei muss sie:
Der IS-Entwicklungszyklus
Die Entwicklung läuft in vier Phasen, die einen Kreislauf bilden. Am Ende geht das System in den IS-Betrieb über.
Einfach erklärt: Wie beim Hausbau: Zuerst klärst du mit den Bewohner:innen, was sie brauchen (Anforderungen). Dann zeichnet die Architektin Pläne (Entwurf), dann wird gebaut (Implementierung), dann wird abgenommen (Test). Erst danach zieht man ein (Betrieb).
Prüfungsfalle: Die richtige Reihenfolge ist Requirements-Engineering → Entwurf → Implementierung → Test. Getestet wird nach der Implementierung, entworfen vor ihr.
Requirements-Engineering (Anforderungsanalyse)
Requirements-Engineering: die möglichst vollständige Gewinnung und Aufzeichnung der Anforderungen an ein neues oder zu erweiterndes System. Man kann es auch als Prozess sehen: Bedürfnisse und Erwartungen der Stakeholder werden identifiziert, analysiert, dokumentiert und verwaltet.
Ergebnis ist die Anforderungsspezifikation (requirements specification). Weil die ganze weitere Entwicklung darauf aufbaut, soll sie sein:
Warum diese Phase so wichtig ist
Einfach erklärt: Merkt man beim Plan, dass das Bad zu klein ist, radiert man eine Linie weg. Merkt man es, wenn das Haus steht, muss man Wände abreißen.
Prüfungsfalle: Gescheiterte IT-Projekte scheitern laut dieser Sicht meist an falschen oder lückenhaften Anforderungen, nicht in erster Linie an schlechter Programmierung.
Prüfungsfalle: Korrekturen werden später teurer, nicht billiger. Je früher ein Fehler auffällt, desto günstiger.
Funktionale und nicht funktionale Anforderungen
| Art | Was beschreibt sie? | Beispiel (Lern-App) |
|---|---|---|
| Funktionale Anforderung | welche Funktionen das System bieten soll (was es tut) | „Die App soll Karteikarten anlegen und abfragen können.“ |
| Qualitätsanforderung (= nicht funktionale Anforderung) | welche Qualitätseigenschaften das System haben soll (wie gut es etwas tut) | „Die App soll eine Abfrage in unter einer Sekunde laden.“ |
Typische Qualitätsmerkmale sind etwa Zuverlässigkeit (läuft stabil, ist nach einer Störung schnell wieder da) und Leistung (reagiert schnell auf Anfragen).
Prüfungsfalle: „Das System soll ausfallsicher und schnell sein“ ist keine funktionale Anforderung, sondern eine Qualitätsanforderung (nicht funktional). Funktional ist nur, was das System tut, nicht wie gut.
VertiefungMehr Beispiele zum Unterscheiden
Ein Foodtruck lässt sich eine Vorbestell-App bauen.
| Anforderung | Art |
|---|---|
| Kund:innen können ein Gericht vorbestellen. | funktional |
| Die App zeigt den aktuellen Standort des Trucks. | funktional |
| Die Bezahlung per Karte ist möglich. | funktional |
| Die App bleibt auch bei 500 gleichzeitigen Nutzer:innen schnell. | Qualität |
| Nach einem Absturz ist die App in wenigen Minuten wieder online. | Qualität |
| Die App ist ohne Anleitung bedienbar. | Qualität |
| Zahlungsdaten werden verschlüsselt übertragen. | Qualität |
Faustregel: Kannst du die Anforderung als Tätigkeit beschreiben („die App macht X“), ist sie meist funktional. Beschreibt sie eine Eigenschaft („die App ist schnell, sicher, einfach“), ist sie eine Qualitätsanforderung.
Wer liefert Anforderungen? Alle Stakeholder: Kund:innen, die Köchin im Truck, die Buchhaltung, eventuell Behörden (Datenschutz). Werden wichtige Gruppen übersehen, fehlen Anforderungen, und genau daran scheitern viele Projekte.
5 Entwurf, Versionen und Tests ★★★
Zwischen der ersten Idee und der fertigen Software gibt es mehrere Vorabversionen. Und bevor Software in Betrieb geht, wird sie auf verschiedene Arten getestet. Beide Begriffsreihen sind typischer Detailstoff.
Arten von Entwürfen (Versionsstufen)
Die Stufen von „früh und unfertig“ bis „final“:
| Stufe | Was ist fertig? | Wer bekommt sie? |
|---|---|---|
| Prototyp | demonstrierbare Vorabversion, die bestimmte Aspekte besonders zeigen soll | zum Vorführen und Ausprobieren |
| Alphaversion | nicht alle wesentlichen Funktionen umgesetzt, aber schon weitergebbar | Personen außerhalb des engen Entwicklungsteams |
| Betaversion | alle wesentlichen Funktionen umgesetzt, aber noch nicht vollständig getestet | Testnutzer:innen |
| Release Candidate | alle Funktionen vollständig, bereits ausgiebig getestet | größerer Personenkreis vor der Freigabe |
| Release-Version | finale Version | wird an Dritte weitergegeben |
Einfach erklärt: Bei einer neuen Torte in der Bäckerei ist der Prototyp das Probestück, das zeigen soll, wie die Creme schmeckt. Die Alpha bekommen die Kolleg:innen aus dem Verkauf, auch wenn die Deko noch fehlt. Die Beta ist komplett, aber noch nicht oft gebacken. Der Release Candidate geht als Kostprobe an Stammkund:innen. Die Release-Version steht in der Vitrine.
Prüfungsfalle: Alpha und Beta werden gern vertauscht. Alpha: noch nicht alle wesentlichen Funktionen. Beta: alle wesentlichen Funktionen da, aber noch nicht fertig getestet.
Prüfungsfalle: Ein Release Candidate ist schon ausgiebig getestet und funktional vollständig. Er ist nicht die finale Version, sondern geht vor der allgemeinen Freigabe an einen größeren Kreis.
Was ein Softwaretest ist
Softwaretest: der Prozess, in dem man prüft, ob ein Softwaresystem den zugrunde liegenden Spezifikationen entspricht und ob es in der vorgesehenen Systemumgebung lauffähig ist.
Testarten nach Umfang
| Test | Was wird getestet? |
|---|---|
| Modultest | einzelne Softwarekomponenten auf ihre korrekte Funktion |
| Integrationstest | Konfigurationen oder Subsysteme gemeinsam (arbeiten die Teile zusammen?) |
| Systemtest | das komplette Softwaresystem, grundsätzlich das fertig installierte IS |
| Akzeptanztest | Funktionstest aus Sicht der Benutzer:innen |
Testarten nach Blickwinkel und Zweck
| Test | Kerngedanke |
|---|---|
| White-Box-Test | schaut in die interne Struktur des Quellprogramms und prüft u. a. die Qualität des Codes |
| Black-Box-Test | prüft „von außen“, ob die Anforderungen erfüllt sind; die Testerin kennt das Innere nicht |
| Regressionstest | stellt sicher, dass ein vorher korrekt laufendes Programm nach Änderungen immer noch der Spezifikation entspricht |
Einfach erklärt: Beim White-Box-Test schraubt der Mechaniker die Motorhaube auf. Beim Black-Box-Test fährt jemand eine Runde und schaut nur, ob das Auto bremst, lenkt und beschleunigt. Beim Regressionstest prüft man nach dem Reifenwechsel, ob die Bremsen immer noch gehen.
Prüfungsfalle: Beim Black-Box-Test kennt die Testerin die Interna nicht. Wer den Quellcode untersucht, macht einen White-Box-Test.
Prüfungsfalle: Ein Regressionstest prüft nicht neue Funktionen auf Herz und Nieren, sondern ob bisher Funktionierendes nach einer Änderung noch funktioniert.
Prüfungsfalle: Modultest = einzelne Komponente, Integrationstest = mehrere Teile zusammen, Systemtest = das ganze installierte System. Der Akzeptanztest nimmt die Sicht der Nutzer:innen ein.
VertiefungAlle Tests an einem Beispiel
Eine Lern-App bekommt ein neues Quiz-Modul.
Zusammenhang mit den Phasen: Die Tests sind die Test-Phase im Entwicklungszyklus. Sie vergleichen das Ergebnis mit der Anforderungsspezifikation. Deshalb ist eine saubere Spezifikation so wichtig: Ohne klare Anforderungen weiß man gar nicht, wogegen man testet.
6 Vorgehensmodelle, Scrum und IS-Betrieb ★★
Wie organisiert man die Entwicklung? Es gibt viele Vorgehensmodelle, von schwergewichtig und planlastig bis leichtgewichtig und agil. Scrum ist das bekannteste agile Modell.
Grundsätze der IS-Entwicklungsprozesse
Prüfungsfalle: „Es gibt ein bestes Vorgehensmodell, das für alle Projekte gilt“ ist falsch. Die Wahl hängt von Projektgröße, Dauer, Klarheit der Spezifikation und Teamgröße ab.
Agile Entwicklungsprozessmodelle
Agile Entwicklungsprozessmodelle: leichtgewichtige, weitgehend unbürokratische Vorgehensmodelle. Typisch sind:
Sie sind die Alternative zu komplexen Prozessmodellen, die für große Entwicklungsteams gedacht sind. Als Inspiration diente auch die Open-Source-Entwicklung: Dort koordinieren sich oft hunderte Entwickler:innen ohne komplizierte Prozessmodelle und schaffen trotzdem hervorragende Software.
Einfach erklärt: Statt ein Jahr lang still eine riesige App zu bauen, liefert ein agiles Team alle zwei bis vier Wochen ein kleines, funktionierendes Stück. Kund:innen geben Feedback, und der Plan wird angepasst.
Prüfungsfalle: Agile Modelle sind leichtgewichtig und unbürokratisch, mit anpassbaren Vorgaben. Starre, im Voraus vollständig festgelegte Pläne sind gerade das Gegenteil von agil.
Scrum: Herkunft und Merkmale
Scrum: ein agiles Entwicklungsprozessmodell.
Prüfungsfalle: Scrum stammt ursprünglich aus dem Wissensmanagement (Nonaka und Takeuchi). Sutherland und Schwaber haben es 1995 auf die Softwareentwicklung übertragen, nicht erfunden.
Die sechs Rollen in Scrum
| Rolle | Verantwortlich für |
|---|---|
| Product Owner | Anforderungen definieren und priorisieren; sorgt dafür, dass das Team die nötigen Infos hat |
| Scrum Master | Einhaltung des Scrum-Prozesses; unterstützt das Team, beseitigt Hindernisse, fördert laufende Verbesserung |
| Entwicklungsteam | Umsetzung der Anforderungen, entwickelt das Produkt; arbeitet eng mit Product Owner und Scrum Master |
| Stakeholder | geben Feedback, sind am Erfolg des Projekts interessiert |
| Management | stellt Ressourcen bereit und unterstützt das Scrum-Team bei den Projektzielen |
| Scrum-Team | umfasst alle oben genannten Rollen; verantwortlich für den erfolgreichen Abschluss |
Einfach erklärt: Drei Freundinnen bauen eine Lern-App. Lena entscheidet, welche Funktion zuerst kommt (Product Owner). Jonas achtet darauf, dass Sprint-Treffen stattfinden, und räumt Probleme aus dem Weg (Scrum Master). Mira und zwei weitere programmieren (Entwicklungsteam). Studierende testen und geben Rückmeldung (Stakeholder). Die Studienvertretung stellt Server und etwas Budget (Management).
Prüfungsfalle: Der Product Owner priorisiert die Anforderungen (das Was). Der Scrum Master kümmert sich um den Prozess und beseitigt Hindernisse (das Wie der Zusammenarbeit). Der Scrum Master ist kein klassischer Chef, der Aufgaben verteilt.
Prüfungsfalle: Ressourcen bereitstellen ist Aufgabe des Managements, nicht des Product Owners. Feedback geben vor allem die Stakeholder.
VertiefungWie ein Scrum-Durchlauf abläuft
Gearbeitet wird in kurzen, festen Zeitabschnitten, den Sprints (oft 1 bis 4 Wochen). Die Besprechungen strukturieren jeden Sprint (die Begriffe sind gängiges Allgemeinwissen zu Scrum):
Danach beginnt der nächste Sprint. Das spiegelt die Grundidee wider: Aktivitäten werden wiederholt durchlaufen, Vorgaben bleiben anpassbar.
Hinweis zu den Rollen: In vielen Darstellungen besteht der Kern von Scrum nur aus Product Owner, Scrum Master und Entwicklungsteam. Hier zählen zusätzlich Stakeholder und Management als Rollen, und das Scrum-Team bezeichnet alle zusammen. Für die Prüfung gilt diese Sechs-Rollen-Sicht.
VertiefungKlassische und agile Modelle im Vergleich
Neben agilen Modellen gibt es schwergewichtige, phasenorientierte Modelle (Allgemeinwissen zur Einordnung):
| Situation | Eher passend |
|---|---|
| großes Projekt, klare, stabile Anforderungen, viele Beteiligte | klassisch, phasenorientiert |
| kleines Team, unklare oder sich ändernde Anforderungen | agil |
IS-Betrieb
IS-Betrieb: vor allem die organisatorischen Maßnahmen, die den laufenden Betrieb eines Informationssystems in einer dynamischen Umwelt sicherstellen. Im PDCA-Zyklus ist das die Phase Act.
Einfach erklärt: Die Buchungs-App des Fahrradverleihs ist live. Jetzt muss jemand Updates einspielen, Störungen beheben, Daten sichern und auf neue Anforderungen reagieren, damit die App jeden Tag läuft.
7 Geschäftsprozesse und Geschäftsprozessmanagement ★★★
Informationssysteme sind kein Selbstzweck: Sie unterstützen die Abläufe, mit denen ein Unternehmen Wert schafft. Diese Abläufe heißen Geschäftsprozesse.
Prozess und Geschäftsprozess
Prozess: eine sachlogische Abfolge von Aktivitäten, die durch ein Startereignis ausgelöst wird und mit einem Endereignis endet.
Geschäftsprozess: eine zielgerichtete, zeitlich-logische Folge (Vorgangskette) von Aktivitäten, die für das Unternehmen einen Beitrag zur Wertschöpfung leistet.
Jeder Geschäftsprozess ist ein Prozess, aber nicht jeder Prozess ist ein Geschäftsprozess. Entscheidend ist der Beitrag zur Wertschöpfung des Unternehmens.
Prüfungsfalle: Das Merkmal, das einen Geschäftsprozess von einem bloßen Prozess abhebt, ist der Beitrag zur Wertschöpfung. Start- und Endereignis haben beide.
Die Merkmale eines Geschäftsprozesses
Prüfungsfalle: Ein einmaliges Projekt (z. B. die einmalige Übersiedlung in ein neues Büro) ist kein Geschäftsprozess. Geschäftsprozesse sind Routine.
Prüfungsfalle: Aktivitäten müssen nicht immer streng nacheinander laufen. Sie können auch parallel, wiederholt oder alternativ stattfinden.
Prüfungsfalle: An einem Geschäftsprozess ist in der Regel mehr als eine Organisationseinheit beteiligt, oft auch Externe wie Lieferanten.
Beispiel: Kaffeebohnen nachbestellen
Ein Kaffeehaus merkt jeden Montag, dass die Bohnen knapp werden. Die Filialleiterin prüft den Lagerstand und bestellt beim Röster nach. Ist die Bestellung teurer als 500 €, muss der Inhaber zustimmen. Der Röster liefert, die Buchhaltung bezahlt die Rechnung.
| Merkmal | Im Beispiel |
|---|---|
| Wertschöpfung | Bohnen sind die Grundlage für den Kaffee, der verkauft wird |
| Auslöser | Lagerstand der Bohnen ist niedrig |
| Ergebnis | volles Bohnenlager, Rechnung bezahlt |
| Ablauf | großteils nacheinander; eine Alternative bei der Freigabe (über 500 € oder nicht) |
| Beteiligte | Filialleitung, Inhaber, Röster, Buchhaltung |
| Routine | passiert jede Woche |
Geschäftsprozessmanagement
Geschäftsprozessmanagement (BPM, Business Process Management): der systematische Umgang mit Geschäftsprozessen. Prozesse werden erhoben, modelliert, analysiert, verbessert, umgesetzt und laufend überwacht.
Das Werkzeug zum Darstellen (Modellieren) ist eine Modellierungssprache wie BPMN. Weitere Modellierungssprachen sind z. B. EPK (ereignisgesteuerte Prozesskette), UML oder Petri-Netze.
Einfach erklärt: Geschäftsprozessmanagement ist wie ein Rezeptbuch für die Abläufe im Unternehmen: Man schreibt auf, wie etwas gemacht wird, sucht Stellen, wo es hakt, und verbessert das Rezept.
VertiefungWarum Prozesse und IS zusammengehören
8 BPMN: Prozesse grafisch darstellen ★★★
Damit alle Beteiligten über einen Prozess reden können, braucht es eine gemeinsame Bildsprache. Das ist BPMN. Du musst die Grundelemente und ihre Bedeutung in Worten erklären können.
Begriff, Zweck und Nutzen
BPMN (Business Process Model and Notation): eine grafische Notationssprache, mit der man Geschäftsprozesse modellieren kann und die für alle Beteiligten leicht zu verwenden und zu verstehen ist.
Prüfungsfalle: BPMN ist nicht nur für IT-Fachleute. Sie soll gerade für alle Beteiligten verständlich sein: Analyst:innen, Entwickler:innen und Anwender:innen.
Prüfungsfalle: BPMN ist eine grafische Notation zur Modellierung, keine Programmiersprache und kein Softwareprodukt.
Die Grundelemente
| Element | Bedeutung im Prozess | Wie es aussieht |
|---|---|---|
| Startereignis (Ereignis) | Auslöser des Prozesses, sein Start | ein Kreis mit dünnem Rand |
| Endereignis (Ereignis) | Ergebnis, das Ende des Prozesses | ein Kreis mit dickem Rand |
| Aktivität (Objekttyp) | ein Arbeitsschritt, der erledigt wird | ein Rechteck mit abgerundeten Ecken, darin der Schritt (z. B. „Bestellung prüfen“) |
| Gateway (Objekttyp) | ein Entscheidungspunkt, an dem sich der Ablauf verzweigt oder zusammenführt | eine Raute |
| Pool (Objekttyp) | die Beteiligten des Prozesses | ein großes Rechteck um alle Schritte eines Beteiligten, mit dessen Namen am Rand |
Die einzelnen Elemente werden mit Pfeilen verbunden, die die Reihenfolge zeigen (Sequenzfluss).
Einfach erklärt: Lies ein BPMN-Diagramm wie einen Brettspielplan: Beim dünnen Kreis geht’s los, die abgerundeten Kästchen sind Felder, auf denen etwas zu tun ist, an der Raute musst du dich entscheiden, beim dicken Kreis ist das Spiel aus. Der Pool ist der Spielbereich einer Spielerin.
Prüfungsfalle: Start- und Endereignis sind Ereignisse. Aktivität, Gateway und Pool zählen zu den Objekttypen. Ein Gateway ist kein Arbeitsschritt, sondern ein Entscheidungspunkt.
Prüfungsfalle: Der Pool stellt die Beteiligten dar, nicht eine Entscheidung und nicht einen einzelnen Arbeitsschritt.
Die wichtigsten Gateways (Entscheidungspunkte)
| Gateway | Symbol in Worten | Bedeutung |
|---|---|---|
| Exklusives Gateway (XOR) | Raute, leer oder mit einem X | genau ein Weg wird genommen (entweder/oder) |
| Paralleles Gateway (AND) | Raute mit einem Plus (+) | alle Wege laufen gleichzeitig; beim Zusammenführen wird auf alle gewartet |
| Inklusives Gateway (OR) | Raute mit einem Kreis (O) | einer oder mehrere Wege, je nach Bedingung |
Gateways bilden genau die Merkmale von Geschäftsprozessen ab: alternative Aktivitäten (XOR) und parallele Aktivitäten (AND).
Prüfungsfalle: XOR = genau einer der Wege. AND = alle Wege gleichzeitig. OR = mindestens einer, eventuell mehrere. „Parallel“ und „exklusiv“ werden gern vertauscht.
Rechenbeispiel Den Bohnen-Prozess in BPMN lesen
So sieht der Kaffeehaus-Prozess aus Abschnitt 7 als BPMN-Modell aus, in Worten beschrieben:
Ergebnis: Alle Merkmale eines Geschäftsprozesses sind sichtbar: Auslöser (Start), Ergebnis (Ende), Arbeitsschritte, eine Alternative (Gateway) und mehrere Beteiligte (Pools).
VertiefungWeitere BPMN-Elemente
Über die Grundstruktur hinaus gibt es zusätzliche Symbole, die man je nach Detailgrad verwendet (Allgemeinwissen zur Einordnung):
Warum wenige Grundsymbole reichen: Für ein Gespräch mit der Geschäftsführung genügen Start, Aktivitäten, Gateways, Ende und Pools. Für die IT-Umsetzung kann dasselbe Modell später viel feiner ausgebaut werden. Genau das meint „unterschiedlicher Detaillierungs- und Komplexitätsgrad je nach Bedürfnis der Stakeholder“.
Checkliste: Das musst du können
Dieses Kapitel ist im STEOP-Pass enthalten.
Mit dem Pass bekommst du alle Zusammenfassungen, alle Übungsfragen, unbegrenzte Probeklausuren, den Lernplan, Lernkarten und Telegram-Support – einmalig 39,99 € 79,98 €, kein Abo.