• Business System Development — Als technischer Wissensträger für das Lean Management ist das KPO verantwortlich für die Entwicklung eines Business Systems im allgemeinen, bzw. eines Produktionssystems im speziellen (denken wir beispielsweise an TPS). Darüber hinaus müssen ein Curriculum und die entsprechende Bildungseinheiten um das System entwickelt werden.
• Change Management — Das KPO betreut sämtliche Veränderungen als Berater, Trainer, Betreuer und Katalysator. Es nimmt nicht die Rolle des Initiators an. Es kann lediglich Empfehlungen aussprechen.
• Personalentwicklung — Typischerweise wird ein Unternehmen kurze Zeit nach der Transformation von einem Kaizen-Sensei begleitet, bis es auf eigenen Beinen stehen kann. Das gelingt nur, wenn Kaizen von der gesamten Belegschaft eines Unternehmens verinnerlicht wird. Das KPO beteiligt sich aktiv an der Aus- und Weiterbildung des Personals, sowohl im technischen als auch im organisatorischen Bereich.
• Daily Kaizen etablieren — Der Übergang zum täglichen Kaizen steht dem systematischen Ansatz des Kaizen-Events gegenüber. Ersterer ist eine Frage der Tiefe der Durchsetzung von Kaizen, letzterer ein organisierter Systemansatz des Lean Managements. Beides zusammen ist das ultimative Ziel und verspricht den größten Nutzen der Transformation. Das KPO ist also beim Training der Belegschaft (wichtig hier: Train-the-Trainer) und der Entwicklung von Problemlösungsqualitäten die treibende Kraft. Es ist die einzige Instanz einer Organisation, welche eine echte Kaizen-Kultur auf jeder Ebene schaffen und erhalten kann.
• Kaizen-Events organisieren — Die Organisation von Kaizen-Events ist ganz klar die Domäne des KPO. Als technischer Wissensträger kann nur das KPO die richtigen Themen (Focus Areas), Vorbereitungen und die Nachbearbeitung vollständig organisieren. Das KPO ist hier ganz klar in einer aktiven Rolle.
• Office Management — Das Office im Sinne des Kaizen ist der virtuelle und physische Wirkungskreis des Kaizen Promotion Office. Es dreht sich alles um Informationsaufbereitung und -austausch, Planung von Weiterbildungsmaßnahmen und die Aufrechterhaltung der kontinuierlichen Verbesserungsmaßnahmen durch die jeweiligen Verantwortlichen.

Was braucht’s für einen Kaizen Promotion Office?

Die oben genannten 6 Aufgaben und Ziele des KPO erfordern in weiten Teilen ganz spezifische Fachkenntnisse und Fähigkeiten. Diese unterscheiden sich selbstverständlich sehr stark von der jeweiligen Position, die ein Protagonist innerhalb des KPO einnimmt. Beispielsweise hat ein KP Officer auf Unternehmensebene (meist ein Mitglied der Geschäftsleitung oder Bereichsleitung) einen anderen Focus als der einer Business Unit.

Dennoch lässt sich ein recht gutes Bild von den allgemeinen Kompetenzen solcher Funktionsträger zeichnen. Dazu zählen:

• Fähigkeit zur strategischen Planung und Ausrichtung
• Führungsstärke im Change Management
• Ausgeprägtes Zeit- und Selbstmanagement
• Führungsstärke im Team und die Fähigkeit das Team richtig zu positionieren (im Sinne von Konsensbildung)
• Verantwortung für getroffene Maßnahmen
• Flexibilität
• Das Gespür für Talente und deren Förderung
• Hohe soziale Kompetenz und Kommunikationsstärke

Ganz ohne Zweifel sind einige der genannten Soft-Skills nur sehr schwer zu erlernen (manche haben sie einfach) jedoch können Menschen mit Hilfe intensiven und gezielten Coachings (und nicht zuletzt durch die gesammelte Erfahrung) auf diesen Gebieten große Fortschritte erzielen.

Nun, was die technischen Kenntnisse angeht, quasi all das “was” zu tun ist, so sind es primär die drei Bereiche Lean Principles, Systeme und Werkzeuge (Techniken). Erfahrung ist der beste Lehrer, noch besser ist die Instruktion durch einen erfahrenen Sensei, doch irgendwo muss der Anfang gemacht werden. So bleibt oft nicht anderes übrig, als sich dem Studium des Lean Managements zu widmen.

Es mangelt ganz und gar nicht an Zertifizierungsprogrammen, allerdings wird in den meisten Fällen ein rigoroses Programm abgespult, das einen hohen Zeitaufwand und entsprechende Hingabe abverlangt. Insgesamt sollten auf jeden Fall eine natürliche Neugierde und das Verlangen nach intellektueller Erkenntnis (beides darf ruhig leicht obsessive Züge annehmen) vorhanden sein. Letztendlich bewegen wir uns alle im Kreislauf studieren, anwenden, lernen und leeren. Wissen ist zum Teilen da!

Ganz ähnlich gestalten sich auch die Herausforderungen an die Führungskräfte der Organisationen, welche sich auf die zunehmende Unsicherheit und Intensivierung des Wettbewerbs einstellen müssen. In den meisten Fällen heißt das: weniger ist mehr.

Das mittlere und das Top Management sehen sich meist Problemen gegenüber, für die es keinen klaren Lösungsansatz gibt. Erfolg setzt aber voraus, dass sich Entscheidungsträger gezielt den Innovationen widmen und neue Denkansätze im Unternehmen kultivieren. Das Selbstverständnis, welches Organisationen von sich haben, muss sich den neuen Umständen anpassen.

Historisch betrachtet hat das Training von Führungskräften die Problemlösungskompetenz stark vernachlässigt. So wurde nicht selten die Theorie vertreten, dass jedes Problem mit einer einfachen Lösung zu beseitigen sei, die Kunst bestünde nur darin, die richtige Lösung innerhalb eines akzeptablen Zeitfensters zu finden. Das “Flickschusterei” das Problem nur kurzfristig oder gar nicht beseitigt ist inzwischen hinreichend bekannt.

Die betroffenen müssen sich dann oft fragen lassen: Was hast Du Dir nur dabei gedacht? Dabei müßte man vielmehr fragen: Wie hast Du dabei gedacht?

Eines meiner 10 Prinzipien des Managements ist systemisches Denken, nämlich komplexe Interaktionen auf struktureller, technischer, politischer und personeller Ebene zu erkennen und zu analysieren. Systemisches Denken etabliert eine neue Perspektive, und erlaubt es Managern und Führungskräften das große Ganze besser zu verstehen. Auf diese Weise werden kluge und dauerhafte Lösungen für Probleme gefunden.

Unsere Arbeitsplätze haben sich in den letzten dreißig Jahren enorm verändert. Sie sind schnellebig geworden, wir sind einem Informationsüberluss unterworfen und stehen ständig unter Strom (glücklich ist, wer das spätestens an der Wohnungstür ablegen kann). Gekennzeichnet ist diese Tendenz von der Tatsache, dass, dominiert von der Orientierung an Werten und Zielen, oftmals das Wichtige durch das Dringliche verdrängt wird.

Damit verbunden ist eine der größten Hindernisse systemischen Denkens, nämlich die ungebremste Geschäftigkeit. Vertieft im Sumpf der unendlich vielen Details unserer Existenz ist es nicht schwer, das große ganze aus dem Blick zu verlieren. Das Management ist gefordert, Einfachheit, Klarheit und Sicherheit in einer flüchtigen und komplexen Umgebung zu schaffen.

Vor einigen Jahren, beispielsweise, konnte ich einen Kunden helfen zu erkennen, dass die Lösung zur Bekämpfung schlechter Recruiting-Ergebnisse nicht in der Zentralisierung der internationalen Bemühungen liegt. Als er das große Bild vor sich sah, konnte eine Recruiting-Infrastruktur geschaffen werden, die es erstmals ermöglichte, lokale Talente und hochspezialisierte Fachkräfte für die jeweiligen Standorte zu gewinnen. Das wurde durch systemisches Denken erreicht, weil wir endlich begannen, Beziehungen zu betrachten. Daraus resultierten Muster für nachhaltige Veränderungen und kontinuierliche Verbesserungen.

Aufbauend auf den 7 Todsünden der Verschwendung (YouTube) brachen Produktionsleiter mit Kaizen im Rucksack auf zur Suche nach Muda und Eliminierung derselben. Wurde das richtig und gut gemacht, konnten signifikante Verbesserungen in kurzer Zeit beobachtet werden, welche heute noch anhalten.

Heutzutage wird es immer wichtiger die Verwaltungen solcher Produktionsbetriebe ebenfalls einer solchen Aktivität zu unterziehen.

Warum ist das so? Weil Kunden bessere Produkte und Dienstleistungen zu geringeren Preisen möchten, das ganze natürlich auch schneller als üblich. Aus Kundensicht beginnt die Uhr mit dem Absenden der Bestellung an zu ticken und hört erst auf, wenn das Produkt geliefert oder die Dienstleistung erbracht wurde. Somit lohnt sich ganz gewiss ein Blick über den Horizont des Produktionsalltags hinaus.

Muda im Office

In der Produktion ist Lean Management ein alter Hut und bereits sehr gut etabliert. In der Verwaltung und Administration von Organisationen ist das noch nicht der Fall. Ein Grund ist sicher, dass dieser Bereich noch nicht so viel Aufmerksamkeit erhielt wie der Produktionsbereich, nicht zuletzt weil hier die größten Potentiale lagen.

Auf Produktionsseite verarbeiten wie Material und Teilerzeugnisse zu neuen Produkten. Der Fluß ist klar umrissen, wir können mit dem einzelnen Bauteil förmlich durch die Produktionsstufen wandern. Im Büro, mit all den unterschiedlichsten Tätigkeiten, Informationen und Interaktionen ist der Arbeitsfluß ganz und gar nicht so einfach zu durchschauen. Möchten wir unser Büro also von Muda befreien müssen wir einen anderen Blick auf die Prozesses werfen. Diesen Blick kann man sich aneignen. Wie das geht beschreibe ich diesen Blog Post.

Was ist Muda?

Im weitesten Sinne, kann Muda in jeder Operation oder Aktivität gefunden werden, die dem Endprodukt oder der Dienstleistung Mehrkosten auferlegt, ohne erkennbaren Mehrwert für den Kunden zu erzeugen. Betrachten wir administrative Aufgaben und Prozesse, so könnten folgende Aktivitäten potentielle Kandidaten sein:

• die Bewegung und Sortierung von Unterlagen
• Ablage von Unterlagen
• Wiederkehrende Tätigkeiten gleicher Art
• Wiederholung aufgrund von Fehlern
• Warten auf Freigaben von Dokumenten oder Tätigkeiten
• Unnötige Überprüfung getaner Arbeit
• Ineffiziente Workflows
• Veraltete und inadequate Software

Ein strategischer Ansatz zur Beseitigung von Quellen der Verschwendung würde, ebenso wie im Produktionsbereich, zu folgenden positiven Auswirkungen führen:

• Reduzierung der Verarbeitungszeiten, schnelle Antwortzeiten auf Kundenanfragen
• Eliminierung aller unnützen Aktivitäten
• Einfache, logische und schnell zu erlernende Arbeitsprozesse
• Reduzierung von Fehlern und damit verbundener Mehrarbeit
• Ständige Verbesserung durch das Team
• Geringere Kosten
• Hohe Moral und Leistungsfähigkeit des Teams

Wo fangen wir an?

Ein guter Ausgangspunkt sind immer Kernprozesse. Typischerweise gibt es in einem Unternehmen nicht so viele. Beispiele für Kernprozesse könnten die Auftragsbearbeitung oder die Produktentwicklung sein. Diese Prozesse untersuchen wir auf die Erfüllung Deiner subjektiven Erwartungshaltung hinsichtlich Qualität, Kosten und Zeitaufwand.

Zur Unterstützung sollten stets abstrahierte Flußdiagramme zur Hilfe genommen (Du hast doch welche, oder?) und die jeweilgen Prozess Owner (auch die existieren in Deiner Firma, nicht wahr?) hinzugezogen werden. Mit Hilfe der Diagramme besteht für alle beteiligten ein gemeinsames Verständnis für den aktuellen Prozessablauf und welche funktionalen Bereiche verantwortlich für welche Teilprozesse sind.

Anschließend müssen wir nur noch ein messbares Ziel und einen Zeitplan für die Prozessoptimiertung definieren. So etwas könnte beispielsweise lauten: “Beantwortung von 95% aller Kunden anfragen innerhalb von 12 Studen bis zum Ende des zweiten Quartals”.

Techniken und Werkzeuge

Als Kenner des Kaizen möchte ich daher besonderes Augenmerk auf folgende Werkzeuge zur Identifikation von Muda legen:

1. Analyse der Wertschöpfungskette
2. Prozessmodellierung
3. Pareto-Analyse und Fischgretendiagramme
4. Theory of Constraints (von SixSigma)

Zu den empfehlenswerten Techniken zur Beseitigung von Muda gehören:

5. Value Stream Mapping
6. One Piece Flow Processing
7. Prozesse mit minimalen Fehlerquellen (Poka Yoke)
8. Das sog. Cellular Processing

Diese acht Schritte sind der Schlüssel zum Lean Office.

Extrem wichtig ist bei der Implementierung der ausgewählten Strategie, das Du stets den gesunden Menschenverstand anwendest und nicht gegen ihn arbeitest.

Fazit

Das war ein kurzer Exkurs in das Lean Office, welches immer wichtiger wird um den Kreislauf der Optimierungsbemühungen, welche in der Produktion begannen, zu schließen.

Zusätzlich ist es enorm empfehlenswert, zusätzliche Anstrengungen im Bereich der Führungsqualität, der Selbstbestimmung und der Stärkung von Partnerschaften mit Lieferanten zu unternehmen, da hier ganz enorme Verbesserungspotentiale verborgen liegen.

Ausführlicher möchte ich an dieser Stelle ausdrücklich nicht werden, da sich ganze Bücher mit diesem Thema befassen und neben dem Kaizen-Aspekt insbesondere soziale und politische Betrachtungen eine wichtige Rolle spielen.

Um was geht es dabei? Nach der Auslieferung von XP, wollte Microsoft die Gelegenheit nutzen, neue TCP-Features in Windows Vista zu integrieren. Die meisten Probleme machte die neue Explicit Congestion Notification (ECN). Es ist in RFC 3168 spezifiert, welches kurz nach dem Release von Windows XP veröffentlicht wurde. Die Idee dahinter ist, daß ein Router in einem überlastetem Netzwerk dem Verursacher der Netzlast mitteilen könnte, er möge sich doch etwas zurückhalten und die Datenrate etwas reduzieren.

ECN verwendet zwei ungenutzte Bits im IP-Header, um das zu erledigen. Ohne ECN sind diese beiden Bits immer null. Doch es stellte sich heraus, daß einige Firewalls es ganz und gar nicht begrüßen, wenn Bits, die normalerweise immer null sind, plötzlich gesetzt werden. So werden eine ganze Reihe von Verbindungsversuchen verhindert, da die Firewalls die Pakete nicht passieren lassen. Es soll sogar Geräte geben die sich aufhängen, wenn die beiden besagten Bits gesetzt sind.

Der genannte Knowledge-Base-Artikel beschreibt einen Workaround für das Problem.

Simplicity is the ultimate sophistication. { Leonardo da Vinci }

Erinnerst Du Dich an Deine erste Präsentation? Wie war das Feedback? Hast Du überhaupt welches erhalten? Was hast Du in den Gesichtern der Anwesenden gelesen? Hast Du die Gesichter der Anwesenden gelesen? Hattest Du den Eindruck, Deine letzte Präsentation war richtig gut? Hat Dir das jemand gesagt, oder ist das Deine Meinung?

Meine erste Präsentation war zwar kein Disaster aber auch nicht wirklich gut. Zu schnell geredet, zu viel Text auf den Slides, die Botschaft zum falschen Zeitpunkt vermittelt und außerdem war sie viel zu lang. { nicht die Botschaft, die Präsentation }

Das Leid ist groß. Auf beiden Seiten.

Zuhörer wie Vorträger, selten freuen sich beide auf eine Präsentation. Die Gründe sind vielfältig, doch in der heutigen Zeit, welche von PowerPoint oder seinem coolen Cousin Keynote bestimmt wird, haben beide möglicherweise vor sehr langer Zeit das letzte mal eine wirklich beeindruckende Präsentation gesehen. Und wenn sich nichts ändert, warum sollte diese dann besser werden?

Erzähl’ Deine Geschichte.

Drei Grundprinzipien einer guten Präsentation sind Einfachheit, Zurückhaltung und Natürlichkeit. Das Ziel muß sein mit mehr Klarheit, Schönheit, Intelligenz und Integrität zu präsentieren. Unter diesen Gesichtspunkten sind wir einer Geschichte schon viel näher.

Eine Präsentation ist keine Lehrveranstaltung, kein Ersatz für ein Arbeitsmeeting aber auch kein Forum für Alleinunterhalter. Du präsentierst, um Deine Botschaft zu vermitteln, Deine Idee, Deine Kultur. Du möchtest überzeugen, unterhalten, und gewinnen.

Mit einfachen Methoden kannst Du Deine Technik verbessern, die Medien besser nutzen und das Publikum binden. So erreichst Du Dein Ziel.

Der Auftrag

Im Jahr 2005 erhielt ich den Auftrag, die Prozesse für die Logistik und die Produktentwicklung eines mittelständischen Unternehmens zu untersuchen und gegebenenfalls zu optimieren. Nachdem das Projektteam sich auf einen Maßnahmenplan einigen konnte, ging es nun um die Implementierung.

Da umfangreiche organisatorische Änderungen notwendig waren und die Kernbereiche identifiziert wurden, mußten wir die Führungskräfte der Bereiche von unserem Plan überzeugen. In einigen Fällen mußten Teams neu zusammengestellt, alte Positionen gestrichen und neue geschaffen werden. Wir beschlossen, eine Präsentation vorzubereiten, die alle Führungskräfte aller Bereiche (nicht die der betroffenen) anspricht und ihnen die Entscheidungsfindung, welche dem Maßnahmeplan zugrunde lag näher bringt.

Diese Präsentation möchte ich Dir vorstellen, um zu zeigen, daß für ein emotionales Thema eine emotionale Geschichte notwendig ist.

Die Geschichte

Vor der Erstellung der Präsentation müssen wir uns fragen:

• Welche Zielgruppe sprechen wir an?
• Welche Botschaft möchten wir vermitteln?
• Welche Stimmung möchten wir erzeugen?

Das Storyboard

Grundsätzlich empfehle ich, immer mit Papier und Bleistift zu beginnen und nicht mit dem Öffnen von PowerPoint oder Keynote. Versetze Dich in kreative Stimmung, versetze Dich in die Lage des Publikums und erzähle Deine Geschichte. Zeichne die einzelnen Kapitel der Geschichte auf und formuliere sie in Bildern. Bedenke, diese Präsentation richtet sich nicht an die Geschäftsführung, das wäre ein anderes Thema.

Desweiteren wurde ein umfangreiches Handout vorbereitet, welches wir nach der Präsentation ausgegeben haben. In diesem Handout sind alle Fakten und Details enthalten, die in der Geschichte nicht erzählt wurden.

Der Vortrag

In den 45 Minuten habe ich lediglich 11 Slides benötigt (die erste ist nur das Cover). Somit blieben mir etwa 4 Minuten pro Slide um meine Geschichte zu erzählen. Damit war das Tempo nicht zügig aber auch nicht langsam.

Unser Maßnahmeplan wurde in drei Kapitel aufgeteilt. Zu Beginn zeigten wir die Ausgangssituation (The journey) auf und machten deutlich, dass eine aktive Herangehensweise an die Fragestellung der richtige Weg war (You have to make it happen) und im Anschluß an die vollbrachte Leistung die Reise noch nicht vollendet ist, sondern wieder von neuem beginnen kann (Reflect).

Auf den nächsten vier Slides erzählten wir, welche Schritte wir unternahmen und zu welchen Erkenntnissen wir gekommen sind, beispielsweise, daß ein extrem großer Bedarf an der Vereinfachung von Prozessen bestand (Desire). Da die Straffung von Prozessen oftmals zu Personalabbau führen kann, haben wir bewußt die gezielte Nutzung des Wissens der hochqualifizierten MitarbeiterInnen des Unternehmens herausgestellt um die Angst vor Verlust von Einfluß und sogar des Arbeitsplatzes zu zerstreuen.

Der Höhepunkt unserer Geschichte ist die Frage, wie es weitergeht (Veni, vidi, what now?). Hier haben wir bewußt auf Diagramme verzichtet, da es die Aufgabe der Geschäftsleitung ist, diese Maßnahmen im einzelnen zu vermitteln. Das die anstehenden Veränderungen aber nicht ohne die Kooperation der MitarbeiterInnen durchgeführt werden können haben wir es nicht versäumt an die Motivation der Mitarbeiter zu appelieren (Commit).

Die Slides

Das Ergebnis kannst Du als PDF herunterladen oder gleich hier anschauen:

Qualitätsmanagement für Projektmanager

Qualitätsmanagement ist einer der wichtigsten Prozesse im Project Life Cycle um zu erfahren, ob ein Projekt noch im Zeitplan und im Budget liegt. Die durchgeführten Tests während des Qualitätsprozesses müssen sich direkt auf Anforderungen abbilden lassen. Ist das nicht der Fall, sollte der Prozess unbedingt überprüft werden.

Qualitätsprozesse umfassen alle Aktivitäten in einer Organisation zur Erfassung von Qualitätsrichtlinien, Identifikation von Zielen und Verantwortlichkeiten, so daß Projekte stets zu dem angedachten Ergebnis führen. Innerhalb des Projekts wird ein Qualitätsmanagement auf Basis der Qualitätsrichtlinien, -prozeduren und -prozesse implementiert. Diese beinhalten insbesondere Qualitätsplanung, Qualitätssicherung und Qualitätskontrolle, welche kontinuierlich im Laufe des Projekts verfeinert werden, sofern notwendig.

Die Disziplin des Qualitätsmanagers wird in größeren Projekten in der Regel von einer eigenen Instanz wahrgenommen, entweder vertreten durch eine Mitarbeiteren oder einer QM-Abteilung. Jedoch ist es Aufgabe des Projektmanagers Resourcen zur Wahrnehmung der QM-Aufgaben einzuplanen und freizustellen. Gute Beziehungen zu allen Mitgliedern des Projektteams und der Stakeholder erleichtern diesen Aspekt erheblich, insbesondere wenn Ihre Resourcen innerhalb einer Matrix organisiert und Ihnen nicht unterstellt sind.

Nun sind einige Begriffe aufgetaucht, die ich kurz zur Auffrischung definieren möchte:

• Qualitätsplanung – Identifikation für das Projekt relevanter Qualitätsstandards und Definition notwendiger Schritte zur Erreichung derselben.
• Qualitätssicherung – Anwendung systematisch geplanter Abläufe zur Überprüfung der Einhaltung von Qualitätsstandards eines Projektes. Damit wird sichergestellt, daß ein Projekt alle Prozesse implementiert, die zur Einhaltung der Standards notwendig oder vorgeschrieben sind.
• Qualitätskontrolle – Überwachung spezifischer Projektabläufe und Einzelergebnisse (beispielsweise von Meilensteinen) zur Überprüfung der Einhaltung relevander Qualitätsstandards. Dazu gehört insbesondere die Identifikation von Abweichungen und Einleitung entsprechender Schritte zur Beseitigung von Unregelmäßigkeiten.

All diese Prozesse interagieren untereinander und mit anderen Disziplinen (im PM-Jargon auch Knowledge Areas). Jeder Prozess involviert eine oder mehrere Personen, je nach Anforderung des Projekts. Desweiteren wird jeder Prozess in einem Projekt mindestens einmal ausgeführt, nicht selten in mehreren Phasen, je nach Art des Projekts. Theoretisch sind alle Prozesse in sich abgeschlossen und voneinander getrennt; in der Praxis jedoch überlappen die Prozesse und führen zu ganz unterschiedlichen Interaktionen, die ich hier nicht weiter erläutern möchte.

In diesem kurzen Artikel gehe ich auf grundlegendes Qualitätsmanagement nach ISO ein. Der Ansatz ist in der Regel weitgehend kompatibel mit propreitären Ansätzen wie etwa definiert von Juran oder Crosby oder offiziellen Verfahren, wie TQM (Total Quality Management), Six Sigma, FMEA (Failure Mode and Effect Analysis) oder COQ (Cost of Quality) und CI (Continuous Improvement).

Auch wenn Qualitätsmanagement von Projekten stets auf alle Projekttypen anwendbar ist steht es immer unter dem Einfluss der beiden Faktoren Projektmanagement und Produkt (quasi das Projektergebnis). Die Methoden zur Qualitätskontrolle und die Standards sind von Projekttyp zu Projekttyp verschieden und werden vom Produkt bestimmt.

Das Qualitätsmanagement von Softwareprodukten, beispielsweise, setzt völlig andere Ansätze voraus als die Projektierung und Realisierung von Bauwerken. Allerdings ist das Projektqualitätsmanagement (PQM) beider Projekte das gleiche. Die Nichteinhaltung von Qualitätsanforderungen einer der beiden Dimensionen kann ernste Folgen für alle Projektbeteiligten nach sich ziehen:

• Steht das Team unter Zeitdruck wird oftmals über QM-Prozesse hinweggegangen so daß Fehler möglicherweise unerkannt bleiben und später unerwartete Konsequenzen haben können.
• Die Überforderung des Teams oder die inkonsequente Einhaltung von PM-Prozessen kann das Team auslaugen, zu Fehlern führen und gleichzeitig die erfolgreiche Realisierung des Projekts gefährden, da von den definierten Zielen abgewichen wurde. Dies wiederum führt zu erhöhten Kosten und gar dem Projektstop.

Qualität und Präzision und Kundenzufriedenheit

Der Begriff der Qualität ist die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen (DIN EN ISO 8402) oder nach ISO 9000:

Vermögen einer Gesamtheit inhärenter (lat. innewohnend) Merkmale eines Produkts, eines Systems oder eines Prozesses zur Erfüllung von Forderungen von Kunden und anderen interessierten Parteien.

Ausdrücklich genannte und implizite Bedürfnisse sind notwendige Voraussetzungen für die Entwicklung von Projektanforderungen. Ein kritisches Element des Qualitätsmanagements im Bezug auf den Projektkontext ist die Umwandlung von Bedürfnissen, Wünschen und Erwartungen in Anforderungen. Während des Projekts kann das durch Stakeholder-Analyse oder in Workshops zum Project Scope Management geschehen.

Qualität und die Bewertung der Gesamtheit von Merkmalen sind nicht das gleiche. Schlechte Qualität ist immer problematisch, eine geringe Bewertung nicht unbedingt. So kann beispielsweise ein Softwareprodukt qualitativ sehr hochwertig sein (wenige Fehler, sehr gute Anleitung) aber in seiner Gesamtheit von Merkmalen nur gering eingestuft worden sein, weil es beispielsweise wenige Funktionen aufweist. Der Projektmanager und sein Team sind verantwortlich für die Identifikation und Erreichung erforderlicher Stufen hinsichtlich der Qualität und der Bewertung.

Desweiteren sind Präzision und Akkuratesse nicht das gleiche. Präzision bezieht sich auf das Ergebniss mehrerer zusammengefaßter Messungen mit möglichst wenig Streuung. Akkuratesse heißt, daß ein gemessener Wert sehr nah an dem tätsächlichen Wert ist. Im Umkehrschluß bedeutet diese Erkenntnis, daß präzise Messungen nicht zwingend akkurat sein müssen und eine akkurate Messung nicht unbedingt präzise. Das Projektteam muß selbst erkennen, wie viel Präzision und Akkuratesse notwendig sind.

Kundenzufriedenheit

Zur Kundenzufriedenheit aus sich des Projektteams gehören das Verständnis, die Bewertung und Identifikation von Erwartungen welche zur Erfüllung von Kundenanforderungen führen. Allerdings spielen hier zwei Faktoren eine Rolle: Erfüllung der Anforderungen und die Einsatzähigkeit des Produkts. Ersterer ist klar messbar (hat das Team die Anforderungen erfüllt?), letzterer ist schwieriger zu definieren, denn es bezieht sich auf den Nutzen (Business Value) des Produkts.

In jedem Fall können folgende Aspekte zur Erreichung beider Ziele beitragen:

• Fehler zu vermeiden ist auf lange Sicht weniger konspielig als sie zu einem bestimmten Zeitpunkt zu finden und zu korrigieren. Eine Faustregel besagt, daß die Kosten zur Beseitigung eines Fehlers mit dem Fortschritt des Projekts exponentiell wachsen. Die Kosten sind um ein vielfaches höher, wenn das Produkt ausgeliefert wurde. Neben dem wirtschaftlichen Schaden ist auch die öffentliche Wahrnehmung des Unternehmens betroffen.
• Der Erfolg eines Projekts wird von dem Engagement jedes einzelnen Projektmitglieds bestimmt, allerdings liegt es in der Verantwortung des Managements die entsprechenden Resourcen bereitszustellen und Strukturen für das Gelingen zu schaffen.
• Die kontinuierliche Verbesserung aller Prozesse während des Projektablaufs ist die Grundlage für eine Qualitätsverbesserung des Produkts. Allerdings kann eine solche Bemühung auch zur allgemeinen Optmierung des Projektmanagements beitragen. Verfahren wie Six Sigma oder oder TQM berücksichtigen diese Tatsache.

Die Kosten zur Erreichung einer bestimmten Qualitätsstufe umfassen alle Bemühungen die dazu unternommen werden müssen.

Der Kostenfaktor

Sämtliche Projektentscheidungen können Auswirkungen auf den spzeifischen Kostenfaktor Qualität eines Produkts haben. So könnten beispielsweise Reklamationen, Ausschuß, Nacharbeiten oder Mehraufwendungen ganz erheblich zur Kostensteigerung beitragen. Nun hat ein Projekt einen temporären Charakter, so daß sämtliche Investitionen in die Qualitätsverbesserung, insbesondere mittels Fehlervermeidung, erst vom Auftraggeber voll ausgenutzt werden können, da ein Projekt möglicherweise nicht lange genug existiert um aktiv beteiligt zu werden. In jedem Fall ist diese Investition seitens des Auftraggebers äußerst sinnvoll und sollte kommuniziert werden.

Zur Qualitätsplanung gehört eine Kosten-Nutzen-Analyse. Der größte Nutzen durch Einhaltung von Standards schlägt sich in deutlich weniger Nacharbeiten und Mehraufwendungen nieder, so daß daraus wiederum höhere Produktivität, gesteigerte Kundenzufriedenheit und geringere Kosten abgeleitet werden können. Die meisten Kosten zur Einhaltung von Qualitätsstandards entstehen bei der Ausübung von PQM-Aktivitäten.

Benchmarking kann bei der Bewertung eines Projekts hinsichtlich der Einhaltung von Qualitätsstandards helfen. Allerdings basiert Benchmarking auf dem Vergleich von Kennzahlen ähnlicher Projekte, so daß die Aussagekraft einer Auswertung nicht immer groß ist.

Die Komponente Qualität ist eine Säule des PM-Fundaments und darf nie vernachlässigt werden. Qualität wird vom Kunden am stärksten wahrgenommen.

Momentan ist SOA, die Service-orientierte Architektur, das große Ding. Nach Jahren der Definitionsfindung scheint endlich der Zeitpunkt gekommen, eine SOA implementieren zu können. Und der Zeitpunkt könne nicht besser sein. Unternehmen suchen bereits seit geraumer Zeit nach Möglichkeiten zur Optimierung ihrer Geschäftsprozesse im Hinblick auf die Integration mit IT-Dienstleistungen und -Architekturen. Die wichtigsten Ziele sind hier natürlich Senkung der Kosten und Erhöhung der Flexibilität.

Da SOA auf offenen Standards und Technologien basiert, hilft SOA effektiv, die IT reaktionsfähiger zu machen, indem echte Geschäftsanforderungen und funktionale Aspekte, wie Wiederverwendbarkeit von Code, Vereinfachung der Verwaltung und Entwicklung, sowie Agilität direkt miteinander verknüpft werden.

Warum brauchen Unternehmen SOA?

Ein großes Unternehmen, evtl. mit Niederlassungen und Partnern im Ausland, hat 20 verschiedene Anwendungen, die alle irgendwelche Steuerberechnungsfunktionen benötigen. Dazu kommt, daß jede Applikation den Code dafür im Bauch hat, jedesmal unterschiedlich realisiert, troztdem bringen sie die gleichen Ergebnisse.

Diese Art der Softwareverteilung läßt sich in vielen Bereichen beobachten. So verwenden viele Firmen innerhalb des Unternehmens unterschiedliche Buchhaltungsprogramme und ERP-Systeme. Nachdem viele Jahre in die Dezentralisierung, aber nur selten in eine gute, ausbaufähige, zukunftssichere IT-Architektur investiert wurde, erkennen Unternehmen nun, daß sie ihren Ansatz neu modellieren müssen, bevor neue Projekte realisiert werden können, die in eine SOA passen.

Neben technischen existieren eine ganze Reihe von disziplinarischen Herausforderungen, denn eine neue Organisationsstruktur muß etabliert werden, um die Innovationen in der Informationstechnologie voll ausschöpfen und in ein Geschäftsmodell integrieren zu können. Besonders in Umfeldern, deren Richtungen und Schwerpunkte sich häufig verändern, ist die Einführung auf Diensten ausgerichteten Architektur sehr attraktiv.

Die beschriebenen Probleme und Herausforderungen haben einiges gemeinsam:

• Es geht um die Integration heterogener IT-Systeme.
• Die Anforderungen an die Prozessintegration steigen rapide.
• Der nahtlose Informationsfluß wird immer wichtiger.

Mitarbeiter, Partner, Prozesse, Channels und Anwendungen miteinander zu verbinden um einen integrierte und konsistenten Zugang zu Geschäftsfeldern zu eröffnen und dazu noch die Kosten zu senken ist das Ziel eines jeden Unternehmens. Zur Erreichung ihrer Ziele, etablieren sie die Grundlagen einer SOA, indem sie:

1. Aufbau einer mehrfach nutzbaren (shared) IT-Infrastruktur zur Eliminierung redundater Dienste.
2. Einführung mehrfach nutzbarer unternehmensweiter Plattformen als Fundament für Interoperabilität und verteilte Applikationen.
3. Entwicklung autonomer, wiederverwendbarer Dienste, um beispielsweise Bereitstellungskosten für Kunden, Mitarbeiter und Partner zu senken.

Eine SOA bietet seinen Nutzern einen Satz definierter Dienste, die sie nutzen und in Geschäftsprozesse integrieren können, ganz wie sie sie benötigen. Sie entwickeln Systeme, die sich den geschäftlichen Veränderungen anpassen können.

Das beste an einer SOA ist, daß die Idee dahinter nicht neu oder gar radikal ist. Die schlummerte bereits seit langer Zeit in IT-Umgebungen, jedoch meist als propreitäre, untereinander inkompatible Variationen. Mit der Schaffung von Schlüsselstandards, insbesondere im Bereich der Web Services, wird die Einführung einer allgemein gültigen Service-Orientierten Architektur leichter als je zuvor, denn nun können Systeme und Komponenten miteinander kommunizieren, ohne sich zu kennen oder gar von der Existenz des anderen zu wissen. Dieser standardisierte Ansatz zur Service-Architektur hat das Potenzial, bestehende technische und geschäftliche Probleme zu lösen.

Letztendlich soll SOA die Führungsebene der Business- und IT-Abteilungen von eine unflexiblen, inkompatiblen und oft teuren, Ansammlung von IT-Systemen befreien, die viele Unternehmen im Laufe der Zeit angeschafft haben. Die Probleme und Kosten, solche Legacy-Systeme miteinander zu verbinden und dazu noch so zu verändern, daß sie mit aktuellen Veränderungen Schritt halten können, überfordert die meisten Budgets und verhindert Innovationen.

Das Ziel ist ein Abbau der Interoperabilitätsprobleme, indem monolithische und statische Systeme durch modulare und flexible Komponenten ersetzt werden, so daß sich die IT auf die Unterstützung des operativen Geschäfts konzentrieren kann, anstatt Geld und Zeit dafür afzubringen, die antiquierten System und Strukturen immer wieder nachzuziehen.

Im weiteren Verlauf des Artikels sind folgende Definitionen hilfreich:

Service (Dienst)

Ein eigenständiger, wiederholbarer Geschäftsablauf, wie beispielsweise die Berechnung von Steuern, Prüfung der Kreditwürdigkeit eine Kunden, oder die Eröffnung eines Kontos

Service-Orientierung

Integration eines Geschäftsprozesses in eine Kette wiederverwendbarer Dienste. Die Ausgabe, quasi das Ergebnis, dieser Kette ist Teil der Service-Orientierung

Service-orientierte Architektur

Eine IT-Architektur, die eine Service-Orientierung ermöglicht und z.T. implementiert.

Composite Applications

Integrierte Dienste zu Abwicklung von Geschäftsprozessen über unterschiedliche Anwendungen hinweg, die jeweils auf SOA-Prinzipien basieren.

Folgende Abbildung illustriert den Übergang von einer Säulenarchitektur hin zu einem Service-orientierten Modell:

In diesem Kontext werden Applikationen als Dienste betrachet und auch so verwaltet. Zusammen mit Web Services und anderen Anbindungen, ergibt diese Anwendungen Verbindungen, die den Bedürfnissen von Geschäftsprozessen entsprechen. Das Ziel ist die Eliminierung von Rundanzen, sowohl was die intern entwickelten Lösungen als auch die von Drittanbietern bezogenen betrifft, und die Bereitstellung von allgemeingültigen Geschäftsaufgaben (wie biespielsweise Steuerberechnungen). Das Ergebnis ist eine einfachere IT-Umgebung bestehend aus wiederverwendbaren Komponenten, die logisch miteinander verbunden werden können, um einen bestimmten Geschäftsprozess zu implementieren. Ein wichtiger Vorteil ist die Fähigkeit, schneller auf Markbewegungen reagieren und Probleme mit geringerem finanziellen Aufwand bewältigen zu können.

In einer Service-orientierten Struktur sind Applikationen und Geschäftsprozesse Teil einer Ansammlung von standardbasierten Komponenten (oder “Diensten”). Jeder von ihnen verrichtet eine diskrete Funktion. Die eigenständigen Prozesse sind locker gekoppelt (engl. loosely coupled) und so entworfen, daß sie beispielsweise ereignis- oder nachrichtenbezogen funktionieren und nicht mehr über festgeschriebene Funktionen betrieben werden. Die Dienste selbst sind können natürlich neu geschaffen werden oder durch Wrapper in existierende Geschäftsabläufe integriert werden, so daß ihre Funktionen mittels standardisierter Schnitttellen zugänglich gemacht werden.

SOA baut auf den Prinzipien modularer Entwicklung, wie wir es von modernen Fertigungen kennen. Denken sie dabei an die Autoindustrie. Hier wird ein Auto aus einem modularen Satz von Komponenten zusammengesetzt. Das gleiche gilt für die Computerindustrie. Wird ein Produkt (oder auch ein Geschäftsprozess modularisiert), sind Teile des Designkerns eigenständig und können beliebig neu integriert werden, solange eine formale Architektur oder ein formaler Plan berücksichtigt wird.

Aus Sicht eines Ingenieurs hat die Modularisierung eines Designs drei Ziele:

• Gewadmet für zukünftige Veränderungen zu sein
• Die Integration komplexer Systeme verwaltbar zu machen
• Parallele Evolution, Innovation und Verarbeitung zu ermöglichen

Modularisierung führt aber auch zu gewissen Unsicherheiten, denn Elemente der Architektur können sich ändern, um unvorhergesehenen Anforderungsänderungen gerecht zu werden. Dabei dürfen die Richtlinien der Architektur nicht außer Acht gelassen werden. So kann aber sichergestellt werden, daß eine alte Komponente gegen eine neue ohne großen Aufwand ausgetauscht werden kann.

Etablierung, Einführung und Verwaltung einer SOA

Wie wir aus den vorangegangenen Ausführungen erkennen können, bedarf die Einführung einer SOA mehr als zu Technologie. Sie bedarf einer systematischen Planung und ein starkes Management. Einfach nur Komponenten auf Web Services umzustellen ergibt noch lange keine SOA, obwohl sie ein wichtigen Teil der Implementierung darstellen. Ebenso ist SOA nur der Anfang, unterliegt ständigen Anpassungen und benötigt viel Zeit um erfolgreich eingeführt und in die existieren Unternehmensphilosophie zu werden. Desweiteren werden Tools und Prozesse und, sehr viel wichtiger, oranisatorische Umformungen der Geschäftsabteilungen und der IT benötigt. Für die meisten Unternehmen ist eine Stufenausbau die beste Lösung, da sie schnell Fortschritte messen können und gegebenenfalls früh auf Probleme bei der Implementierung reagieren können.

Einige Hersteller von SOA-Produkten verfolgen eine Strategie, die als “Rip and Replace” (dt. “rausreissen und ersetzen”) bezeichnet wird. Teil der Strategie ist die Identifizierung potentieller Vorteile einer SOA und die anschließende Implementierung einer Gesamtlösung. Damit würden Kunden durch eine schnelle Konsolidierung ihrer Dienste innerhalb des Unternehmens früh die Vorzüge einer SOA kennenlernen und davon profitieren.

Ein gewisser Grad and Konsolidierung spart sicherlich Kosten, jedoch sollte die Integration von Systemen, die Ausarbeitung neuer Dienste und die Errichtung von Composite-Applikationen nicht in einem Schritt vorgenommen werden. Eine so weitreichende Umstrukturieren des Unternehmens ist mit relativ hohem technischen und politischem Risiko verbunden.

Wenn es um die Einführung einer SOA geht, so sollte nicht alles auf einmal gemacht werden. Das wäre so, als würde man in seinem Haus saämtliche Rohre und Leitungen austauschen und während dessen weiter darin leben wollen. Das Leben würde sehr schnell ziemlich kompliziert werden und Küche, Bad und WC könnten nicht richtig verwendet werden solange nicht alles fertig ist. Keine wünschenswerte Situation.

Ein schrittweiser Ansatz ist viel leichter verwaltbar und führt zu kleinen aber unmittelbar spührbaren Ergebnissen. Ein Unternehmen SOA-fähig zu machen ist ein Langzeitvorhaben und wird von den Geschäftsanforderungen angetrieben, nicht von architektonischen Aspekten.

Eine mehrschichtige Herangehensweise vereinfacht den Wechsel, denn Unternehmen können inkrementelle Veränderungen beim Ausbau zu einer ganzheitlichen Lösung vornehmen. Geschäftsmetriken bestimmen letztendlich die Geschwindigkeit des Umstellungsprozesses. Dabei können die Metriken helfe, Bereiche zu identifizieren, die mehr Aufmerksamkeit benötigen und solche die vielleicht unverhältnismäßig stark berücksichigt werden. Gleichzeitig minimiert sich das Risiko und erhöht sich das ROI.

In der Regel basiert eine mehrstufige SOA-Einführung aus mehreren, aber nicht mehr als drei, Phasen.

Phase 1: Analyse

Es gilt zunächst jene Geschäftsbereiche zu identifizieren, die am nötigsten angepaßt werden müssen, aber gleichzeitig den größen Nutzen für das Unternehmen bergen. Dabei wird festgestellt, welche Anwendungen nicht richtig funktionieren und welche Geschäftsfelder es wert sind in sie zu investieren. Sobald die Erkenntnisse gewonnen und priorisiert wurden, können Modelle erstellt werden, ganz ähnlich wie bei der Renovierung eines Hauses. Ein wichtiger Punkt für das Design des Modells ist die Frage, wie viel eines bestimmten Bereichs umgebaut werden soll. Wir können ein Projekt umstellen, eine paar Abteilungen oder das gesamte Unternehmen.

Die auszuarbeitenden Pläne müssen berücksichtigen, daß der umzuformende Teil und andere periphäre Teile des Unternehmens während der Remodellierungsphase weiter arbeiten müssen. Für Führungskräfte bedeutet das, sie müssen Regeln, Auflagen, Managementpläne und andere Bestimmungen, so daß die beteiligten Personen, Abteilungen und Prozesse entsprechend geführt und koordiniert werden können. Desweiteren reduzieren sie das Risiko, die Kosten und den Aufwand kanz erheblich, denn selbst wenn ein Teilproblem auftritt, wird nicht der gesamte Prozess aufgehalten.

Phase 2: Rationalisierung

In der nächsten und längsten Phase werden die existierenden Strukturen überprüft und überarbeitet um sie auf die SOA-Umstellung vorzubereiten. Alle Änderungen, die an bestehenden Systemen gemacht werden müssen, sind in dieser Phase vorzunehmen. Dienste und Software werden entwickelt, implementiert und getestet. Anschließend wird ein Sicherheitskonzept auf die Komponenten übertragen. Gleichermaßen müssen die beteiligten Personen, Prozesse und Abteilungen in das Sicherheitskonzept einbezogen werden.

Phase 3: Transformation

Die letzte Phase besteht aus der Verwaltung und Wartung unseres neuen Gebäudes. Es wird nun kontinuierlich durch ein effektives System gestützt und verwaltet. Hochqualifizierte Mitarbeiter und detailliert ausgearbeitete Prozesse erlauben ständige Anpassungen der Geschäftsmodelle innerhalb der SOA. Der Erfolg einer SOA-Implementierung ist gekennzeichnet von der Fähigkeit, Geschäftsprozesse einfach zu implementieren, aber dennoch maximale Wirkung im Hinblick auf Agilität, Leistungsfähigkeit und Risikominimierung zu entfalten.

Ein solches Leitungs- und Entwicklungsmodell liefert die besten Ergebnisse mit den geringsten Beeinträchtigungen für das operative Geschäft.

Während des 3-Phasenprozesses ist es sehr hilfreich, Methoden zu entwickeln, die den Fortschritt über alle Abteilungen und Organisationsstrukturen des Unternehmens hinweg visualisieren. Ein Anwendungsbereich kann sich recht früh in der SOA-Landschaft positionieren, seine volle Wirkung kann er jedoch erst entfalten, wenn mehrere Domänen von diesem Gebrauch machen. Erinnern wir uns an das Beispiel mit der Berechnung von Steuern. Zuvor gab es eine Reihe von Modulen, die alle das gleiche getan haben, jetzt können alle das gleiche Modul (nach SOA-Manier als “Dienst” bezeichnet) nutzen, was eine deutliche Reduzierung des Verwaltungsaufwands bedeutet und gleiche Ergebnisse in allen Anwendungsdomänen liefert.

Eine SOA zu errichten, erfordert ein Verständnis der Verbindungen zwischen den Schlüsseldimensionen der Unternehmensstrategie, der Prozesse, der Anwendungen und der Infrastruktur. Um dieses Verständnis zu erlangen, müssen Organisationen innerhalb des Unternehmens weitreichende Einblicke in die Strukturen erhalten, was bedeutet, daß Unternehmen mit geringer Transparenz wenig Chancen haben, eine SOA erfolgreich zu etablieren. Nur so ist die Akzeptanz der eingeschlagenen Strategie zu vermitteln und die Kooperation der Belegschaft zu gewinnen.

Für SOA planen

Die Evolution in eine SOA müssen Unternehmen vorrausschauend planen. Das ist typisch für jede Revision einer größeren Architektur oder eines Projekts. Die folgenden Punkte sollen helfen, die richtigen Entscheidungen bei der Planung für eine SOA zu treffen. Anschließend betrachten wir eine Roadmap zur Ausrollung der Architektur.

Das wichtigste Element bei der Einführung einer SOA ist die Führung. Es liegt in der Verantwortung eines Teams oder einer Führungspersönlichkeit folgende Aufgaben zu bewältigen:

• Auswahl geeigneter Technologien für die Architektur
• Auswahl der Projekte und Prozesse, die unbedingt angegangen und welche nicht angerührt werden sollen
• Entwicklung einer geeigneten Ausbaustrategie
• Messung des Fortschrittes und der Vorteile gegenüber des herkömmlichen Modells

Für eine höchsteffiziente Transformation, empfehle ich folgende Schritte:

Setze Führungsstrukturen ein

Stelle ein Team von Experten zusammen, die abteilungsübergreifende Einführung und Akzeptanz der SOA sicherstellen. Analysiere die Herausforderungen, die eine Entwicklung SOA von der Konzeptionierung bis zu Einführung an Prozesse, Standards und Vorgaben stellen.

Erstelle eine Roadmap

Setze Dich mit den fundamentalen Grundlagen zur Ausarbeitung einer SOA-Strategie auseinander und beginne mit der Ist-Aufnahme der Geschäftsprozesse und erstelle ein Soll-Konzept. Stelle sicher, daß alle Prozesse in allen relevanten organisatorischen Einheiten sichtbar sind. Stichwort: Transparenz.

Versichere Dich der richtigen Ausrichtung der Prozesse, Applikationen und Infrastruktur

Das Ziel ist, die vorhandenen Mittel wie Systeme, Komponenten und Strukturen optimal auszunutzen und sie in neue Strukturen zu integrieren um Kosten zu sparen.

Erstelle einen Businessfall und implementiere ihn in mehreren Phasen

Übersetze die Roadmap die gewonnen Erkenntnisse einen echten ausführbaren Businessfall. Bestimme die Vorteile, welche Du durch Wiederverwendbarkeit von Code, Komponenten, Strukturen und Systemen erreichen kannst. Berücksichtige auch die Vorteile erhöhter Agilität und Transparenz des Unternehmens.

Erstelle eine Kompatibilitäts-Framework für die Integration

Entwickle Guidelines um echte Interoperabilität im gesamten Unternehmen zu gewährleisten.

Sichere die Umgebung

Unternimm praktische Maßnahmen zur Sicherung der Umgebung. Versuche den Zugriff auf Web Services über Identitäten zu regulieren.

Faktoren für die erfolgreiche Einführung einer SOA

Vergessen wir nicht: SOA ist keine Technologie oder ein Produkt. Man sie nicht kaufen oder als Service abonnieren. SOA ist ein architektonisches Konzept, welches sich unabhängig von der Technologie ausprägt. Um eine Unternehmensarchitektur in eine SOA umzuwandeln ist eine systematisch erarbeitete Roadmap unerläßlich.

Stelle das richtige Team zusammen. Wähle die richtigen Leute aus. Unter ihnen sollten Architekten aus allen organisatorischen Einheiten sein. Wähle einen von Ihnen als SOA-Architekt aus, der die richtigen SOA-Standards und -Technologien versteht. Stelle fest, was Du nicht weiß und gehen Kooperationen mit kompetenten Partnern ein, die zum Erfolg beitragen können. Schließlich, komnunizerien, komnunizerien, komnunizerien! Veröffentliche Deine Resultat in regelmäßigen Abständen beispielsweise einmal im Monat und spare nicht mit Grafiken. Sie sagen oft mehr als Worte, besonders in weniger technischen Abteilungen.

Organisiere Erfolg durch Etablierung eines Centers of Excellence in Form einer Expertengruppe. Zentralisiere das Projektmanagement, die Planung, Release-Management und Infrastrukturdienstleistungen. Erdenke Dir ein Auslieferungsmodell, standardisiere es und mach es zum Teil der Gesamtstrategie.

Nutze das vorhandene Wissen der Organisationen und Geschäftspartner. Versuche stets, breite Unterstützung durch die Führungsebene zu erhalten und etabliere Partnerschaften mit Herstellern, die bereits Erfahrung mit SOA und ihren Tools sammeln konnten. Finde ein ausgewogenes Gleichgewicht zwischen den Visionen der Führungsebene und Deinen Visionen, die auch den technischen Aspekt einbeziehen. Konzentriere dich auf kleine Erfolge, die das Management von dem Wert der Aufgabe für das Unternehmen überzeugen.

Bleib flexibel. Entwerfe Deine Strategie nicht zu abitioniert und nicht zu weit vorausschauend. Versuche, Deine Ziele überschaubar zu machen, um leichter auf Veränderungen reagieren zu können. Ein zu hochgegriffenes Ziel kann Dir den Blick für die Details nehmen. Halte die Infrastrukturdienstleistungen leicht und modular. Designkomponenten sollten abstrakt bleiben, um Wiederverwendbarkeit zu garantieren.

Microsoft beschreibt die Ziele des laut Astoria Online Service folgendermaßen:

Astoria soll Applikation erlauben, Daten als Datendienste zu exponieren, die von Web-Clients innerhalb eines Unternehmensnetzwerkes und über das Internet konsumiert werden können. Der Datendienst ist über HTTP zugreifbar und URIs identifizieren unterschiedliche Teile der Informationen, welche durch den Dienst bereitgestellt werden. Interaktionen mit dem Datendienst geschehen über HTTP-Verben wie GET, POST, PUT oder DELETE und die die Daten der Interaktionen werden über einfache XML-Formate oder mittels JSON repräsentiert.

Das Microsoft Codename “Astoria” Overview Document zeigt, wie Daten adressiert und von Astoria Datendiensten dargestellt werden. Um Daten mit Astoria Datendiensten zu adressieren wird folgendes Adressierungsschema verwendet:

http://host/vdir//{{<[predicate]>}

Beispielsweise zeigt http://myserver/data.svc/Customers auf eine Resource, die alle Customer-Instanzen enthält. Ein einzelner Kunde könnte beispielsweise mittels

http://myserver/data.svc/Customers[KEY]

abgefragt werden, wobei KEY einen eindeutigen Schlüssel innerhalb der Kundendaten repräsentiert.

Zusätzlich können Prädikate und Abfragestrings in die URIs integriert werden, welche die Ausgabe beeinflussen können:

http://myserver/data.svc/Customers?$orderby=City

http://myserver/data.svc/Customers?$top=5

http://myserver/data.svc/Customers?$skip=30&$take=10

Die Astoria-Daten liegen entweder als XML, JSON (JavaScript Object Notation) oder einer Untermenge von RDF+XML vor. Standardmäßig wird XML verwendet. So antwortet der Server auf den URI http://myserver/data.svc/Customers[KEY] mit:

<dataService xml:base="http://myserver/data.svc">
<customers>
	<customer uri="Customers[KEY]">
		<customerID>KEY</customerID>
		<companyName>Steve's Online Shop</companyName>
		<contactName>Maria Anders</contactName>
		<contactTitle>Sales Representative</contactTitle>
		<address>Obere Str. 57</address>
		<city>Berlin</city>
		<region />
		<postalCode>12209</postalCode>
		<country>Germany</country>
		<phone>030-0074321</phone>
		<fax>030-0076545</fax>
		<orders href="Customers[KEY]/Orders" />
	</customer>
</customers>
</dataService>

Die Wurzel DataService beinhaltet immer den Basis-URI einer von dem Dienst representierten Resource. Zusätzliche Navigationsknoten, die assoziierte Resourcem beschreiben sind immer mit relativen URIs versehen. In diesem Beispiel sind die Bestellungen (orders) des Kunden KEY verfügbar indem der relative URI mit dem Basis-URI verknüpft wird:

http://myserver/data.svc" + "/" + "Customers[ALFKI]/Orders

Außer GET kann auch HTTP PUT oder HTTP-POST genutzt werden.

Udi Dahan ist ziemlich skeptisch über den Nutzen und die Relevanz von Astoria und Microsoft’s Datenserviceansatz im Allgemeinen:

Ich muß sagen, ich war vom ersten Tag an gegen diese “Datendienste”. Der REST-Stil ist hauptsächlich nützlich für große, stückweise vorliegende Resourcen, während es scheinbar auch auf einzelne Tabellen in einer Datenbank absieht. Die Diskussion über REST vs SOA gibt einige Beispiele.

Danny Ayers jedoch denkt, daß Microsoft mit Astoria dem Symantischen Web näher kommt. Und Alex James gibt einen ausführlichen Überblick über den Astoria Buzz.

Diese Grabenkämpfe gehen manchmal sogar soweit, daß Abteilungsleiter und Manager Informationen zurückhalten und damit den Erfolg des Projekts gefährden. Ich kann mich an einen Fall erinnern, bei dem ein Abteilungsleiter seine Mitarbeiter angewiesen hat, nicht mit dem Projektteam einer anderen Abteilung zu kooperieren. Unnötig zu erwähnen, daß die Konsequenzen nach Bekanntwerden der Umstände sehr ernst waren.

Wie kommt es zu Gerangel um Zuständigkeiten?

Einer der häufigsten Gründe ist die Unantastbarkeit bestimmter Führungskräfte. Einige Positionen in Unternehmen werden viele Jahre, oftmals Jahrzehnte, innegehalten. Hinzu kommt eine freundschaftliche Verbindung zur Geschäftsführung oder anderen einflussreichen Personen, die die objektive Beurteilung von Meinungen, Führungsstilen und Handlungen auf beiden Seiten verklären können.

Während dieser Zeit haben sich diese Persönlichkeiten Freunde wie Feinde gemacht. Während die meisten über Meinungsverschiedenheiten hinweg blicken können, tun sich manchmal tiefe Gräben auf, die viele Jahre bestehen bleiben und die Zusammenarbeit nachaltig negativ beeinflussen können. Diese Konstellation ist der Ausgangspunkt vieler Kompetenzgerangel und nur schwer zu durchbrechen.

Quasi unantastbare Personen in Führungspositionen haben das Gefühl, nach Belieben walten und schalten zu können, ohne irgendjemandem Rechenschaft leisten zu müssen. Diese Tendenz wird zusätzlich verstärkt, wenn jährliche Bewertungen diesen Mitarbeitern fälschlicherweise (oft aus Unwissenheit) außerordentlich gute Leistungen bescheinigen. Aufgrund der Beziehungsdynamik in den Unternehmen, wie zuvor beschrieben, kommt das öfter vor als man denkt.

Ein weiterer Grund für Zuständigkeitsgerangel sind Informationssilos innerhalb von Abteilungen. Dabei geht es nicht um vertrauliche oder persönliche Informationen. Vielmehr sind damit standardisierte Vorgehensweisen, Arbeitsanweisungen und spezifische Abläufe von Abteilungen gemeint, die für den Erfolg von Projekten enorm wichtig werden können. Nicht selten jedoch sind viele Mitarbeiter nicht gewillt, diese Information mit anderen Abteilungen zu teilen, so daß Projektteams nicht optimal arbeiten können und das Vorhaben auf kritische Weise verzögern.

Erschwerend kommt hinzu, daß viele Abteilungen keine klaren Regelungen über den Austausch von Informationen getroffen haben, so daß einige Mitarbeiter teilweise das Gefühl haben, etwas Unerlaubtes zu tun, wenn Sie bestimmte Informationen freigeben.

Auswirkungen auf Projektteams

Neben steigendem Frustrationsgrad entstehen wenig wünschenswerte gruppendynamische Tendenzen. Beispielsweise hat ein Projektmitglied (bezugnehmend aus dem vorangegangenen Beispiel) fast über den gesamten Projektverlauf aufpassen müssen, was er wem sagt, um nicht unnötig zur Steigerung der ohnehin existierenden Spannungen beizutragen. Viele Mitglieder sehen sich genötigt, Partei für eine Seite zu ergreifen, in einem Kampf der nicht der ihre ist. Die Sache wird nicht einfacher, wenn mehrere Spannungsgefüge zur gleichen Zeit auftreten. Neben der Belastung durch die Projektarbeit müssen die Teams auch noch mit psychologischen Belastungen fertig werden. Eine Last, die sich langfristig negativ auf zukünftige Tätigkeiten aller Projektmitglieder auswirken kann.

Macht es aus Ihrer Sicht nicht Sinn, diese Spannungen soweit wie möglich von Ihrem Team fern zu halten? Gute Projektmanager tun das.

Was können Projektmanager tun?

Zugegebenermaßen gibt es keinen goldenen Pfad für die Auseinandersetzung mit Grabekämpfen und Spannungen zwischen Organisationseinheiten von Firmen und Abteilungen. Manchmal genügt schon ein klärendes Gespräch mit den wichtigsten Schlüsselpersonen.

Allerdings kommt es immer wieder vor, daß einige Personen nicht willens sind, etwas an der Situatio zu ändern, obwohl sie sich der Problematik bewußt sind. Sie sind sich ihrer Sache sicher, haben ihre Haltung innerlich gerechtfertigt und fühlen sich oftmals beleidigt, wenn sie aktiv auf ihre Rolle in der Situation angsprochen werden. In der Regel haben Sie nun zwei Möglichkeiten, wobei ich in der Regel nur eine empfehle und die andere als letzten Ausweg betrachte.

Eine sehr effektive Herangehensweise ist, Schlüsselpersonen (sprich mutmaßliche Beteiligte der Grabenkämpfe) in das Projektteam aufzunehmen und mit wichtigen Aufgaben zu betrauen. Das bringt die neuen Projektmitglieder in Zugzwang, denn im Falle einer Kooperationsverweigerung müssen sie sich vor dem Management rechtfertigen. Für die meisten, trotz ihrer starken Position eine sehr unangenehme Situation, der sie doch lieber aus dem Weg gehen.

Wenn das gar nicht in Frage kommt, aus welchen Gründen auch immer, oder alle anderen Versuche gescheitert sind, sollten Sie das Management aktiv einschalten. Zunächst ist das Gespräch des Projektleiter mit dem Management wichtig, idealerweise mit einer konflikterprobten Führungskraft. Anschließend, immer nacheinander, das Sechsaugengespräch mit den Konfliktparteien suchen. Dabei ist wichtig, Optionen für die Wiederaufnahme von persönlichen Beziehungen zur Konfliktpartei in Aussicht zu stellen, beispielsweise durch die Absicht, gemeinsame (Projekt-)Aktivitäten zwischen beiden Abteilungen/Organisationen unternehmen zu wollen. Das können auch gemeinsame Unternehmungen außerhalb der Arbeitszeit sein.

Wie auch immer die Situation ausgehen mag, in jedem Fall sollten Sie versuchen, die Situation frühzeitig zu erkennen. Basis dafür ist Erfahrung, aber auch eine vertrauensvolle Zusammenarbeit innerhalb des Projektteams. Meist sind es die Teammitglieder, die Spannungen als erste bemerken und das Mangement, in diesem Fall Sie benachrichtigen können.

Seit September letzten Jahres erscheint die Sanar’s Website nicht mehr unter den ersten Ergebnissen für Suchanfragen wie beispielsweise “diamond” oder “engagement ring”, was früher anders war. Was war passiert? Sanar kann nicht sicher sein aus welchem Grund seine Website aus dem primären Suchindex in den sog. Supplemental Index abgestiegen ist, der eine Art zweiten Pool für fragwürdige Inhalte darstellt und in Marketing-Kreisen als Google Hell bezeichnet wird.

Die Google-Hölle ist die größte Angst aller Anwender, ob Unternehmen oder Einzelpersonen, die Online-Handel betreiben und daher besonders stark von Suchmaschinen abhängig sind. In diese virtuelle Unterwelt abzusteigen bedeutet für viele enorme Umsatzeinbußen und kann unter Umständen sogar zum Bankrott der Unternehmung führen. Das eigentliche Problem liegt darin, daß man möglichweise nicht mehr aus diesem Kreis der fragwürdigen Inhalten herauskommt, da es für Seitenbetreiber oft nicht nachvollziehbar ist, wie sie überhaupt hineingeraten sind.

Google-Entwickler schufen den Supplemental Index, um die Suchmaschine zu entlasten und performanter zu machen. Dazu gehört auch der Spider, der Algorithmus zu Katalogisierung von Websites. Der Index dient als Auffangbecken für Inhalte, die entweder nicht den Richtlinien der Suchmaschine entsprechen oder einfach nur existieren, um das Ranking bestimmter Seiten zu verbessern.

Seiten in diesem Index werden bei weitem nicht so oft aktualisiert wie die im primären Index. Das bedeutet, daß Inhalte der Google-Hölle so lange in ihr verbleiben, bis Google sich entscheidet, sie erneut zu indizieren und zu bewerten. Diese Zeitspanne kann unter Umständen bis zu einem Jahr betragen. Während Google bemüht ist, daß ständig wachsende Web zu indizieren, landen immer mehr Seiten in der Hölle.

Diese Betrachtung soll nicht zwingend zu einem Negativurteil führen, denn Google ist selbst in einer schwierigen Position. Der führende Suchmaschinenanbieter muß ständig neue Seiten scannen und einordnen (dazu gehört die Zuordnung eines Rankings) und ist bemüht, die Spreu vom Weizen zu trennen. Das Web wird immer größer, so auch die Anzahl von Websites mit Junk-Text und Werbung, die lediglich das Ranking anderer Seiten aufwerten sollen und grundsätzlich keine wertvollen Inhalte liefern. Google erlangte seine Führung durch die Auslieferung erstaunlich guter Ergebnisse im Gegensatz zu seinen Rivalen Yahoo!, MSN oder Ask.com, die aber stetig aufholen.

Wie entscheidet Google, welche Websites im primären und welchen im Supplemental Index landen? Die Frage ist nur von Insidern verlässlich zu beantworten, denn Google hält sämtliche Details über diese Dinge gezielt zurück, um Mißbrauch vorzubeugen. Auf der anderen Seite wird es den Website-Betreibern wie Paul Sanar dadurch nahezu unmöglich gemacht, ihre Inhalte so zu ändern, daß diese vermeintlich fehlerhafte Einordnung nicht geschehen kann.

Sanar selbst glaubt, die Probleme auf einen Berater für Suchmaschinen-Marketing zurückführen zu können, dem er, nach eigenen Angaben, ca. 35.000 US-Dollar zahlte, um das Google-Ranking zu verbessern. Dieser habe wohl einige Fehler gemacht und verursachte damit eventuell das Verschwinden der Website aus dem primären Index. Selbst nachdem die Änderungen rückgängig gemacht wurden, befindet sich die Site noch immer in der Google-Hölle.

Chris Bartow ist Berater für Suchmaschinenmarketing für Revenco.com, eine Immobiliensite, derren Großteil der Unterseiten in Googles Supplemental Index gelandet sind und dort für etwa 6 Monate verblieben. Bartow glaubt, daß die Duplizierung von Inhalten auf 90% der Seiten dazu führte, daß Google die Inhalte als Plagiate deklarierte und sie aus dem primären Suchindex verbannte.

Ich weiß, daß sie versuchen, Seiten mit nutzlosen Inhalten loszuwerden, doch wenn Deine Seiten einfach verschwinden verlierst Du eine Menge Besucher und auch jede Menge Geld

sagt Bartow. Er glaubt, daß die Seiten in der Google-Hölle landeten, weil ein vorübergehender “Defekt” des Algorithmus die Seiten falsch bewertete. Andere Suchmaschinenexperten glauben jedoch, daß die Google-Hölle stetig an Größe und Strenge zunimmt:

Der Supplemental Index hat in der letzten Zeit einen erstaunlichen Aufschwung erfahren. Google ist agressiver bei der Verbannung von Webseiten geworden

erklärt Aaron Wall, Suchmaschinenexperte und Google-Beobachter. Diesen Trend bestätigt auch Marketing-Experte Michael Gray, der die angewandten Standards schon immer wieder zwischen Auflockerung und Verstärkung wecheln sah, jedoch festellen mußte, daß in letzter Zeit die “Brutalität” zugenommen habe und deshalb…

…viele Kollateralschäden bei einigen Entscheidungen aufgetreten sind. Google versucht das Kind mit dem Bade auszuschütten, was aber unmöglich ist. Ein Spammer kann legitime Websites leicht nachbauen, wenn er die richtigen Tricks kennt.

sagt Gray. Und genau hier liegt ein Großteil des Problems. Google kann in den meisten Fällen nur reagieren, so daß Spammer immer ausgefeilter werden, um der Abschiebung in die Google-Hölle zu entgehen.

Die Kriterien nach denen die Websites als für den Main Index akzeptablen Standard beurteilt werden bleibt weiterhin im Dunkeln. Allerdings wissen die meisten Web Designer inzwischen, daß Seiten, mit gleichen Inhalten automatisch das Ranking gefährden. Desweiteren sind wenig Bilder oder wenige Worte und das Fehlen von Links Anzeichen für Google, diese Website eventuell nicht in den Main Index aufzunehmen. Leider sind besonders neu eingestellte Seite besonders anfällig, da Sie oftmals wenige Inhalte und ebenso wenig Links aufweisen.

Google ist in dieser Angelegenheit wie immer sehr verschwiegen. Die Website für Web Designer sagt lediglich:

We’re able to place fewer restraints on sites that we crawl for this supplemental index than we do on sites that are crawled for our main index.

Diese Aussage gibt mehr Rätsel auf als sie löst. Zwar existieren Richtlinien für Webmaster, allerdings sind die Hinweise so allgemein gehalten, daß sie wenig Aussagen über die Algorithmik hinter Google’s Bewertungssystem zulassen. Fest steht für viele Experten nur eines: ist die Website erst einmal in der Google-Hölle, bleibt sie dort für sehr lange Zeit.