| Begriff | Definition |
|---|---|
| Release - Management | Grosse Vorhaben können heutzutage nicht mehr in einem Ganzen realisiert und umgesetzt werden. Systeme müssen schon vor ihrem Bau in kleinere Einheiten zerlegt werden, um die Teilsysteme schneller zu erstellen und somit möglichst schnell vom Endanwender eingesetzt werden zu können. Nachfolgend wird versucht, folgende Fragen zu beantworten:
Release Konzept Um Releases sinnvoll bilden zu können, muss das Gesamt-System näher betrachtet werden.
Die funktionale Gliederung eines Systemes steht dabei klar im Vordergrund unseres Betrachtungswinkels.
Ein Release baut auf einer logischen und möglichst sinnvollen Bildung von Paketen auf; die Summe aller Pakete ergibt wieder zu hundert Prozent das Gesamtsystem.
Die Kunst respektive Schwierigkeit dieses Unterfangens besteht vor allem darin, für den zukünftigen Benutzer des Systemes klar erkennbare „logische Pakete“ zu definieren, welche auch technisch gesehen eine einfache Handhabung der Schnittstellen garantieren. Primär sollte also die Nutzung des Systemes im Vordergrund stehen respektive die Startnutzung mit Paket 1 — in Aufstockungsschritten mit den Paketen 2 bis n — und schliesslich mit dem End-Paket. Eine Konsequenz daraus: ohne sorgfältige Planung geht es nicht!
lnvolvierte Organisationen Wirft man einen Blick auf alle Beteiligten, so wird eine weitere, meist unterschätzte Komplexitat sichtbar: je grösser die Organisationsstruktur, desto umfangreicher die Schnittstellen und Kommunikationswege.
lnvolvierte Organisationen
Support
Konkurrenz
Die Entwicklung selbst ist sicherlich die wichtigste Gruppierung. Als Autor der Software müssen sie darauf bedacht sein, die verschiedenen Programmversionen derart zusammenzusetzen, dass ein lauffähiges Software-Paket entsteht.
Um die Promotion einer neuen Programmversion frühzeitig in Angriff nehmen zu können, muss auch der Verkauf rechtzeitig ins Bild gesetzt werden und mit entsprechenden Informationen beliefert werden.
Die PR-Abteilung muss — in Anlehnung an die Verkaufsabteilung - ebenfalls ins Bild gesetzt werden, damit der richtige Zeitpunkt für die Publizierung der neuen Version optimal genutzt wird.
Der Support ist eine sehr empfindliche Stelle, welche in der Regel vom Kunden genutzt wird, wenn er nicht mehr weiter kommt Um Hilfestellung überhaupt zu ermöglichen, müssen alle Supporter optimal ausgebildet sein, bevor sie in der Supportstelle eingesetzt werden können. Die Konkurrenz zwingt uns schliesslich, noch schneller, mit noch mehr Funktionalität, immer bessere und trotzdem preisgünstigere Produkte herzustellen. Durch Marktbeobachtungen sollte erkennbar sein, wer in welchem Ausmass wirklich Konkurrent ist — und wer nicht.
Das allerwichtigste aber ist der Benutzer. Denn es nützt absolut nichts, wenn alle anderen involvierten Stellen tadellos ineinandergreifen, der Benutzer als letztes Glied in der Verkaufskette aber nicht mitspielt.
Regeln Natürlich existieren Regeln — nur müssen diese Regeln von jeder Firma selbst erstellt werden. Diese Regeln sollten Punkte wie Unternehmungsziele, Software stellt andere Anforderungen als vom Benutzer gewünscht; eigene Anwender können das Programm nicht, die Firma hat eigene Standards, usw.
Release-KetteRelease-Ketten stellen die logische Aufeinanderfolge der Releases dar. Aus der Kette ist ebenfalls ersichtlich, ob der jeweilige Release ein neuer oder ein Sub-Release ist.
Sub-Releases werden in der Regel dann erstellt, wenn kleinere, neue Funktionen in den Funktionsumfang aufgenommen werden oder wenn Fehler behoben worden sind. Hat ein produktiver Release gravierende Fehler oder müssen spezielle zusätzliche Funktionen eingebaut werden, entsteht in der Regel ein neuer Zweig.
Ein Zweig ist eine zusätzliche, zum normalen Release parallel verlaufende Release-Kette. Solch ein Zweig kann auch entstehen, wenn z.B. bei einer Standard-Software spezielle Funktionen für einen bestimmten Kunden eingebaut werden müssen, um das Produkt überhaupt verkaufen zu können.
Release-Letter Der Release-Letter verkündet dem Empfänger des neuen Releases den Funktionsumfang des ausgelieferten Software-Paketes, das er erhalten hat.
Insbesondere ist bei dem Inhalt des Release-Letters darauf zu achten, dass die Aussagen immer auch im Zusammenhang stehen mit dem Gesamt-System, sodass der Empfänger die Möglichkeit erhält, die vorliegenden Änderungen / Erweiterungen im Gesamtsystem nachzuvollziehen. Durch die Positionierung innerhalb des Gesamtsystemes kann der Empfänger ebenfalls abschätzen, ob weitere Teile im Gesamtsystem von den Veränderungen der neu ausgelieferten Objekte direkt oder auch indirekt betroffen sind.
Vergleicht man die einzelnen Release-Letters miteinander, so kann man feststellen, dass vom ältesten zum jüngsten hin eine Reihenfolge der Veränderungen dargelegt ist. Dadurch ist eine lückenlose Nachvollziehbarkeit gewährleistet. Nebst der Reihenfolge wird auch ersichtlich, was von einer zur anderen Version hinzugetan oder weggenommen worden ist.
Da ja immer wieder auch neue Kundschaft einen solchen Release als Start mit der Software installiert, müssen die Voraussetzungen für den Einsatz dieser Version klar ersichtlich sein; dabei spielen Abhängigkeiten eine ganz wichtige Rolle.
Ist hingegen nur ein Zweig eines Releases von Änderungen betroffen, so werden nur zusätzliche, vom Hauptrelease abweichende Funktionen beschrieben. In aller Regel werden solche Zweige erstellt, um z.B. bei der Herstellung von Standard-SW auch auf individuelle Kundenwünsche und —bedürfnisse eingehen zu können.
Solche Release-Zweige werden auch dazu verwendet, bei speziellen Kunden zusätzliche Funktionen, die sie nur dieser Kundschaft zur Verfügung stellen möchten, ins Release-Management einbinden wollen.
Release-Letters sind in der Regel die Begleitpapiere zur Antwort von Change-Anträgen.
Aenderungs-Antrag Der Benutzer eines Systemes hat Wünsche oder konkrete Vorstellungen, wie sein Hilfsmittel „Software“ funktionieren soll, dabei soll es grösstmöglichen Nutzen für die Firma bringen.
Auch Fehlverhalten des produktiv eingesetzten Systemes können den Benutzer dazu veranlassen, einen „Änderungsantrag“ zu formulieren und einzureichen.
Im Change-Management (CM) wird dieser Änderungsantrag (Change-Antrag CA) geprüft. Kommt man zum Schluss, diesen CA weiterzubearbeiten, muss dieser priorisiert werden; andernfalls wird der CA abgelehnt.
Nach der Priorisierung wird der CA im CM-Controlling eingestellt; dadurch kann ein CA geplant, überwacht und kontrolliert werden. Jetzt erst kommt das Projektteam zum Zuge, welches gemäss Definitionen des CA‘s Änderungen vornimmt ‚ dokumentiert und abschliessend testet. Nach Abschluss dieser Arbeiten erfolgt die Rückgabe an das CM-Controlling, welches seinerseits noch Tests durchführt.
Da mehrere Änderungen vom CM-Controlling miteinander koordiniert werden müssen, so wird auch hier in der Regel eine Bündelung von CA vorgenommen. Nach zusätzlichen Tests im CM-Controlling erfolgt die Freigabe der enthaltenen Softwareteile.
Redesign Redesign, Re-Engineering oder Reverse-Engineering — die Einflüsse auf das Release-Konzept sind die selben.
Einfluss (TeiI-)Redesign Grundsätzlich kann davon ausgegangen werden, dass bei einem Redesign die Komplexität höher ist, als dies der Fall ist bei einem erstmaligen Design eines Systems. Weshalb? Insbesondere wenn nur Teile eines Systems überarbeitet werden, muss den bestehenden Schnittstellen zu anderen Teilen des Systems — oder auch aus dem System heraus —besondere Beachtung geschenkt werden. Denn in der Regel müssen diese Schnittstellen auch für den neuen Design (Redesign) berücksichtigt werden, damit aus dem Teilsystem heraus kommuniziert werden kann.
Zeitpunkt eines Re-Engineering Wann ist denn der „richtige“ Zeitpunkt für einen Redesign? Die Antwort kann nicht eine einfache Zeitpunktangabe sein! Die Antwort ist von vielen Faktoren abhängig z.B. Umwelteinflüsse, Marktsituation, Konkurrenzlage, Kundenstamm, ...).
Erfolgt der Re-Design bereits während des Baus der 1. Version der Software, so wird dies nur eine Verspätung der „General Availability“ bewirken. Entwicklungstechnisch betrifft der Re-Design aber nur einen Release; deshalb ist zu diesem Zeitpunkt der Re-Design wohl am günstigsten.
Zum Zeitpunkt 2 sind bereits 2 Versionen produktiv. Für die Arbeiten des Re-Design bedeutet dies, 2 Versionen zu analysieren! Je nach Funktionsumfang und Realisierungsvariante derselben müssen beide Versionen überarbeitet werden. Hier rächt sich somit bereits das Führen von zwei unterschiedlichen Versionen des Software-Produktes.
Der wohl schwierigste Zeitpunkt ist der 3. hier dargestellte Punkt. Stellen Sie sich vor, alle drei Versionen ihrer Software anpassen zu müssen! Die hier gezeigte Konstellation zeigt 3 Zweige (differenter Funktionsumfang), welche alle einen von den anderen unterschiedlichen Startpunkt in der Releasekette aufweisen. Solche Verkettungen sind im besten Fall für den Kunden von Vorteil, für den Hersteller jedoch fuhren solche Gebilde automatisch zu Schwierigkeiten, da unterschiedliche Funktionalität unterschiedlich überarbeitet werden muss. Dadurch entsteht in der Regel 3 mal mehr Aufwand (oder noch mehr ... im Falle eines Re-Designs.
Checkliste „Änderungsantrag“ Um entscheiden zu können, ob ein vorgelegter Change-Request (CR; Änderungsantrag) umzusetzen ist, muss Klarheit herrschen in einigen, wichtigen Punkten. In der Regel trifft nicht eine einzelne Person diese Entscheide, sondern ein Team. Damit aber jedes Mitglied dieses Teams mit gleichen Ellen misst, wird in der Regel eine „Checkliste“ definiert, wonach sich alle zu richten haben.
Auszug aus einer beispielhaften Checkliste:
Eine solche Checkliste macht erst richtig Sinn, wenn sie auch den Erstellern eines CR‘s zur Verfügung steht, denn dadurch ist eher gewährleistet, dass auch alle Ersteller von CR‘s denselben so erstellen, wie er vom empfangenden Team begutachtet wird.
Durch ein solches Vorgehen wird der Bearbeitungsaufwand minimiert, die Vergleichbarkeit einzelner CR‘s erhöht und dadurch die Möglichkeit geschaffen, die Planung planbarer zu gestalten und transparenter zu halten.
QS-Massnahmen im CM-Prozess Der Titel dieses Kapitels verwirrt: sind nun QS-Massnahmen Teil des Change-Management-Prozesses oder umgekehrt? — Weder noch! Der CM-Prozess entspricht der Verkettung von QS-Massnahmen!
Dies bedeutet nichts anderes, als dass mit dem Change-Management-Prozess versucht wird, Produkte-Aenderungen in geordneten, planbaren, kontrollierbaren und nachvollziehbaren Bahnen durchzuführen.
Abnahme-Richtlinien Ist es Ihnen auch schon passiert, dass sich bei der Einführung eines (Teil-)Systems die Abnahme immer mehr und mehr hinauszögerte, weil das Abnahmeteam immer wieder eine Stelle fand, die sie nicht akzeptieren wollte? — Weshalb war das so?
Das Abnahmeprozedere wurde nicht oder nicht vollständig definiert, bevor es zur Durchführung kam! Für die Abnahme müssen klare Prämissen geschaffen werden; Unterlassung führt zwangsläufig zu Bewegungsfreiheit, die vom Abnahmeteam zu eigenen Gunsten ausgenutzt werden (können).
Unter Prämissen sind z.B. zu verstehen: o Zu wieviel Prozent muss ein Test erfolgreich sein, damit er als bestanden gilt? o Welche Teile müssen zumindest voll verfügbar sein, damit eine Teilabnahme möglich ist? o Welche Personen muss das Abnahmeteam umfassen, damit eine „produktionstaugliche“ Abnahme gewährleistet ist? o usw.
SOLL- / IST-Vergleich Der „Vorher — Nachher“ — Vergleich soll dazu führen, den Nutzen aus verschiedenen Blickwinkeln zu betrachten. Werden z.B. die geplanten / versprochenen Einsparungen durch das neue System erzielt werden können ? Ist dem Produkt (und dem Hersteller) mehr Erfolg garantiert ? Wird durch die Neuerungen die Marktposition gefestigt oder gar ausgeweitet? Hat die neue Version des Produktes wirklich die „Schlüssel-Position“ inne, die ihr zugedacht wurde ? Wird das Ansehen des Herstellers und des Produktes durch die Neuerungen ansteigen ? — Alles Fragen, welche einen SOLL- / IST-Vergleich rechtfertigen. Nur nach eingehender Abschlussanalyse und Beurteilung der Ergebnisse ist eine stetige Verbesserung im gesamten Hersteller-Prozess umsetzbar.
Abnahme durch den Fachbereich Die Abnahme ist immer etwas besonderes, weil der zukünftige Benutzer resp. Benutzer-Vertreter durch ihr Einverständnis die Software in die Produktion übergehen lassen.
Sie wünschen sich ebenfalls eine störungsfreie und möglichst hilfreiche Software. Da sie nun voll konfrontiert werden mit der Umsetzung ihrer Anforderungen ans System, hinterfragen sich die meisten Vertreter zukünftiger Benutzer, ob die Anforderungen wirklich korrekt umgesetzt worden sind.
Gibt das Abnahmeteam einmal sein Einverständnis, kann ein in der Regel später entdeckter Fehler nicht festgehalten werden mit dem Vermerk, er habe diesen Fehler vorher noch niemals produziert— damit würde er allen klar vor Augen zu führen, dass er nicht korrekt getestet hätte.
In der Regel besitzt ein Abnahme-Flow mehrere Entscheidungspunkte:
Make or Buy „Make or Buy“ Überlegungen im Informationssystem-Management sicherstellen
Outsourcing-Partnerschaften „Outsourcing“ ist je langer je mehr ein Thema. Outsourcing bedeutet ja, einen Teilprozess, welchen man bisher selbst bearbeitet hat, einem Dritten überlassen zur getreuen Ausführung für uns. Bei der Suche nach dem „richtigen“ Partner werden deshalb viele Kriterien herangezogen, damit man ja den „richtigen“ auswählt — und nicht einen falschen.
Outsourcing-Bereiche Bevor man auf die Suche nach einem geeigneten Outsourcing-Partner geht, sollte klar sein, für welche Prozesse man einen Partner sucht. Zum besten Resultat wird man über die eigene Wertschöpfungskette der Unternehmung geführt.
Daraus ist nämlich ersichtlich, welche Kernkompetenz im Unternehmen selbst enthalten sind, welche Prozesse durch Dritte geleistet werden könnten und gegebenenfalls wird sogar erkannt, dass Prozesse wegfallen.
Kooperation mit Outsourcingfirmen Nachdem erkannt worden ist, welcher Bereich oder welche Bereiche nicht Kernkompetenz der Unternehmung sind, werden diese Bereiche überprüft, welche Konsequenz die Ausgliederung (Outsourcing) z.B. bezüglich Abhängigkeit, usw. ... auf die Unternehmung selbst effektiv hat.
Bereiche wie die Logistik sind dabei prädestiniert, weil auf dem Markt einerseits sehr viele Anbieter vorhanden sind, und so andererseits nie eine Abhängigkeit entstehen kann.
Es gibt Unternehmen, welche mehr als einen Bereich outsourcen. Der Hauptgrund für viele ist die vermeintliche Kosteneinsparung! Ein möglicher Punkt ist sicherlich, dass beim Outsourcen die Kosten praktisch mit voller Bestimmtheit berechenbar und somit vorausschaubar sind.
Inhouse- vs. Outsourcing-Lösungen Vorwiegend aus Kostengründen, nicht zuletzt aber auch immer mehr wegen Human-Ressourcen-Problemen muss vielfach bei der Überlegung, ob eine inhouse- oder Outsourcing-Lösung zu evaluieren ist, auf Dritte zurückgegriffen werden.
Miteinander möglich - oder sinnvoll? Wie sinnvoll sind Outsourcing-Varianten? — Wer sich eine solche Frage stellt, sollte die eigene Unternehmung hinterfragen bezüglich marktpolitische Sicht; mit der Sicht „wer macht was“ werden die unternehmerischen Sichten aufgezeigt. Alles hat seinen Preis — auch hier. Der Vorteil der Kostentransparenz liegt klar auf der Hand. Nicht unwichtig ist auch die Konkurrenz frage: stehen wir als Unternehmung besser oder schlechter da?
Chancen und Risiken beim Outsourcing Chancen: Risiken:
Zugriffe - 468
|