Aufgabe: Zielorganisation bewerten |
|
 |
Diese Aufgabe beschreibt, wieder aktuelle Zustand einer Organisation bewertet wird und wie dieser mit aktuellen Prozessen, Tools, Qualifikationen und Marktumfeld beschrieben wird. |
Disziplinen: Geschäftsmodellierung |
|
Zweck
-
Den aktuellen Zustand der Organisation, in der die
Anwendung implementiert werden soll, auf der Basis des aktuellen Prozesses, der Tools, der Kompetenz der
Mitarbeiter, den Einstellungen der Mitarbeiter, Kunden, Mitbewerbern, technischen Trends, Problemen und
verbesserungswürdigen Bereichen beschreiben.
-
Begründung für die Umstrukturierung der Zielorganisation.
-
Stakeholder der Geschäftsmodellierung identifizieren.
|
Beziehungen
Rollen | Primärer Ausführender:
| Zusätzliche Ausführende:
|
Ausgaben |
|
Prozessverwendung |
|
Hauptbeschreibung
Zur Auswahl der effizientesten Methode für die Geschäftsmodellierung müssen Sie die den aktuellen Zustand der
Zielorganisation mit ihren Personen, Prozessen und Tools kennen. Das Ziel dieser Aufgabe ist, die Problembereiche und
das Verbesserungspotenzial und alle Informationen zu externen Aspekten wie Wettbewerbern oder Markttrends zu verstehen.
Nach Abschluss dieser Aufgabe sollten Sie Folgendes kennen:
-
den aktuellen Zustand der Zielorganisation,
-
die vorhandenen Personen, ihre Kompetenz, Qualifikation und Motivation,
-
die derzeit in der Zielorganisation verwendeten Geschäftstools,
-
Detaillierungsgrad der Beschreibung und Einhaltung aktueller Prozesse,
-
die Bereiche, die das meiste Verbesserungspotenzial aufweisen.
Gründe für die Bewertung des aktuellen Zustands:
-
Auswahl des Geschäftsmodellierungsszenarios (siehe Konzept: Umfang der Geschäftsmodellierung).
-
Identifizierung der Bereiche, die zuerst berücksichtigt werden sollten.
-
Begründung, warum Prozesse, Tools und Personen in der Zielorganisation geändert werden müssen.
-
Motivation der Personen in der Zielorganisation, die direkt oder indirekt von den Änderungen betroffen sind, und
Vermittlung eines allgemeinen Verständnisses.
Diese Aufgabe ist nur von Wert, wenn Sie die Geschäftsmodellierung für das Business-Engineering einsetzen. Wenn Sie lediglich ein Diagramm einer vorhandenen
Organisation erstellen möchten, um Systemanforderungen abzuleiten, ist eine vollständige Bewertung nicht erforderlich.
Lesen Sie auch die Seite Konzept: Umfang der Geschäftsmodellierung.
|
Schritte
Bewertung einleiten
Es wird empfohlen, die Bewertung mit einem Workshop einzuleiten, in dem Sie die wichtigsten (derzeit bekannten)
Stakeholder zusammenbringen. In einem solchen einleitenden Workshop werden Geschäftsanalytiker und Stakeholder der
Geschäftsmodellierung einander vorgestellt und die Probleme der Stakeholder des Projekts in einer Liste erfasst werden.
Einzelheiten zum Abhalten eines solchen einleitenden Workshops finden Sie auf der Seite Technik: Bewertungsworkshop.
|
Stakeholder identifizieren
Identifizieren Sie die Stakeholder der Geschäftsmodellierung. Identifizieren Sie Stakeholder außerhalb der
Zielorganisation, z. B.:
-
Kunden. Wer sind die Kunden? Welche Anforderungen haben Kunden an die Produkte in Bezug auf Markteinführungszeit,
Merkmale, Sicherheit, Zuverlässigkeit und Sicherheit sowie Komplexität.
-
Mitbewerber. Wer sind die Mitbewerber? In welchen Bereichen sind die Mitbewerber stark? Was kann man von den
Mitbewerbern lernen?
-
Andere Stakeholder. Sind andere Stakeholder involviert? Sind Lieferanten und Partner involviert? Gibt es in den
Beziehungen mit diesen Stakeholdern Probleme? Gibt es Personen, die starken Einfluss und Meinungen haben, die auf
dem Laufenden gehalten werden müssen, um Überraschungen zu vermeiden?
Identifizieren Sie die Stakeholder innerhalb der Zielorganisation, z. B.:
-
Projektleiter
-
Verkaufspersonal
-
Vertriebsbeauftragte
-
Marketing
Befragen Sie jeden Stakeholder (Stellvertreter) nach seinen Erwartungen in Bezug auf die Zielorganisation. Dies kann im
Rahmen eines Bewertungsworkshops oder mit einem Fragebogen geschehen.
Interviewen Sie die Leute, um ihre Haltung bezüglich Änderungen zu verstehen. Wenn Leute der Änderung negativ oder
skeptisch gegenüberstehen, ist es unmöglich, mit der Änderung Erfolg zu haben, sofern Sie diese negative Haltung nicht
in eine positive umwandeln können.
Sie müssen die derzeitigen und künftigen Erwartungen Ihrer Kunden analysieren und quantifizieren. Treffen Sie keine
Annahmen bezüglich der Kundenerwartungen. Diese Informationen müssen direkt von den Kunden stammen. Sie können den
Kunden mehr oder weniger formell interviewen oder andere Marktforschungstechniken wie Telemarketing verwenden.
|
Struktur der Zielorganisation beschreiben
Beschreiben Sie kurz die Struktur der Organisation, die Rollen und die Teams. Schauen Sie sich auch die Beziehung
zwischen den verschiedenen Teilen der Zielorganisation an. Wie ist beispielsweise die Beziehung zwischen Verkauf und
Wartung oder zwischen Produktentwicklung und Verkauf?
Es kann einladend sein, die Geschäftsmodellierungsnotation zu verwenden, um diese Informationen darzustellen, aber
häufig eignet sich ein beschreibender Stil besser, an den die Stakeholder gewöhnt sind, z. B. Text,
Organisationsdiagramme oder UML (Unified Modeling Language).
|
Schlüsselpersonen identifizieren
Identifizieren Sie alle Schlüsselpersonen in der Zielorganisation. Eine Schlüsselperson ist eine Person, die eines oder
mehrere der folgenden Merkmale aufweist:
-
Sie ist "eng am Geschehen dran".
-
Sie kann als Mentor auftreten.
-
Sie ist ein Experte in einigen Bereichen.
-
Sie ist gegen die Geschäftsmodellierung.
-
Sie ist für das Budget verantwortlich.
Um mit dem Business-Engineering Erfolg zu haben, ist es wichtig, die Schlüsselpersonen "an Bord zu haben". Sie müssen
sie an folgenden Aufgaben beteiligen:
-
Erfassung von Informationen während des verbleibenden Teils der Bewertung.
-
Als Experten für die Identifizierung von Änderungen an der Zielorganisation.
-
Als Lieferant für Beiträge zu einem Pilotprojekt, dann als Mentor.
Achten Sie auf Personen, die lieber über die Prinzipien der Geschäftsmodellierung diskutieren, als eine effektive, neue
Organisation implementieren möchten.
|
Geschäftsidee und Geschäftsstrategie bewerten
Die meisten Organisationen besitzen eine ausführliche Dokumentation über ihre Geschäftsidee und Geschäftsstrategie.
Wenn Sie eine "virtuelle" Zielorganisation dokumentieren (d. h. eine Geschäftsmodellierung durchführen, um die
Geschäftsprozesse der Zielkunden zu verstehen und damit bessere Produkte zu erstellen), kann dieser Schritt ausgelassen
werden.
Untersuchen Sie die Strategie, um zu bewerten,
-
ob die aktuellen Prozesse im Einklang mit der Strategie stehen,
-
ob sie konkret genug ist, um von den Personen, die in der Organisation arbeiten, verstanden zu werden,
-
ob sie messbar ist,
-
ob sie als realistisch empfunden wird.
Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Bewertung der Zielorganisation.
|
Vergleichsanalyse
Legen Sie Folgendes fest:
-
Wer sollte für eine Vergleichsanalyse herangezogen werden? Wenn Sie eine detaillierte Vergleichsanalyse durchführen
möchten, suchen Sie nach Geschäften, mit denen Sie nicht im Wettbewerb stehen, aber dennoch genügend Ähnlichkeiten
aufweisen.
-
Welche Metriken sollen für die Vergleichsanalyse verwendet werden? Relevante Metriken sind häufig eine Kombination
von Zeit, Kosten und Qualität.
-
Wie soll die Vergleichsanalyse durchgeführt werden? Handelt es sich um eine Partnerschaft mit einer anderen
Organisation, oder reicht es aus, um nach öffentlich verfügbaren Informationen zu suchen?
Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Bewertung der Zielorganisation.
|
Zielorganisation bewerten
Bei der Beurteilung einer Organisation geht es um das Verständnis ihrer Geschäftsprozesse und deren Beurteilung. Sie
müssen Folgendes berücksichtigen:
-
Definieren Sie eine Gruppe von Metriken, die sich aus Metriken aus Kundensicht (z. B. Einhaltung von
Lieferterminen) und internen Metriken (z. B. Produktionskosten) zusammensetzt.
-
Legen Sie fest, von wem Metriken erfasst werden sollen.
-
Definieren Sie effektive Mittel für die Erfassung der Metriken. Sie müssen einfach und problemlos sein, da die
Personen ansonsten dazu neigen, keine Zeit dafür aufbringen zu können.
Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Bewertung der Zielorganisation.
|
Gründe für die Änderung identifizieren
Fragen Sie die Stakeholder, warum sie ihre Geschäftsprozesse und Geschäftstools ändern möchten. Im Folgenden sind
einige typische Antworten und deren Auswirkung darauf beschreiben, wie Sie die Geschäftsprozesse untersuchen und
einführen:
-
"Wir möchten diese neue Technologie verwenden und wissen, wie sie sich auf unsere Arbeitsweise auswirkt."
Ein Beispiel hierfür ist ein Unternehmen, das beschlossen hat, eine E-Commerce-Website zu erstellen. In vielen
Fällen ist der am wenigsten kontroverse Ansatz, die Änderungen als neuen Geschäftsbereich anstatt als Änderung
einer vorhandenen Gruppe von Geschäftsprozessen.
-
"Wir müssen unserer Geschäftsprozesse effektiver machen, um wettbewerbsfähig zu bleiben."
In diesem Fall müssen Sie einige Folgefragen stellen, um verstehen zu können, wie hoch die Effizienzsteigerung
sein muss. Wird über geringfügige Verbesserungen oder über grundlegende Umstrukturierungen und die Unterstützung
vieler neuer Technologien gesprochen? Außerdem müssen Sie verstehen, wer diese Wettbewerber sind und welche Art von
Metriken für den Vergleich verwendet werden.
-
"Unsere alten traditionellen Systeme brechen aus den Nähten, und wir müssen sie ersetzen, bevor sie
zusammenbrechen." Auch diese Antwort macht einige Folgefragen nötig, um verstehen zu können, ob erwartet wird, dass
sich die Geschäftsprozesse ändern oder nicht. Wenn nicht, wird häufig zunächst eine Geschäftsmodellierung auf hoher
Ebene durchgeführt, um sich ein Bild von der aktuellen Organisation zu machen. Manchmal reicht auch ein
Domänenmodell aus.
|
Kapazitäten für Änderung einschätzen
Analysieren Sie die Kapazität für Änderungen in der Zielorganisation. Organisationen können sich wie Personen an
Änderungen anpassen, aber nur in einem gewissen Maß. Einige Organisationen sind besser auf Änderungen vorbereitet als
andere. Um die Kapazität der Organisation für Änderungen verstehen zu können, empfehlen wir, die Personen in der
Organisation zu interviewen, um die Haltung und Bereitschaft für Änderungen einzuschätzen.
Die folgenden Faktoren müssen berücksichtigt werden:
-
Sind die Personen der derzeitigen Bedingungen überdrüssig? In diesem Fall besteht das Risiko, dass jede
vorgeschlagene Änderung als Wende zum Besseren verstanden wird und deshalb nicht richtig nachgefragt wird.
-
Sind die Personen der Änderungen überdrüssig? Die Organisation hat möglicherweise aus verschiedenen Gründen bereits
mehrere Umstrukturierungen vorgenommen, die von den Stakeholdern als nicht erfolgreich empfunden wurden. In diesem
Fall müssen alle vorgeschlagenen Änderungen relativ konkret formuliert und gut begründet werden, damit die
Personen, die in der Organisation arbeiten, sich überhaupt damit beschäftigen, ob die Änderung sinnvoll ist.
Außerdem empfiehlt es sich zu untersuchen, warum die vorherigen Änderungsversuche nicht erfolgreich waren.
-
Wie ist die allgemeine Haltung der Personen, die in der Zielorganisation arbeiten? Sind sie "jung und hungrig" oder
"erfahren und festgelegt"?
-
Ist die Zielorganisation vorhanden oder muss sie ganz neu aufgebaut werden? Im letzteren Fall müssen Sie die
gewünschten Qualifikationen der Personen in der neuen Organisation verstehen und feststellen, wie viel
Einarbeitungszeit ihnen gegeben werden kann.
Zusätzlich zu den oben genannten veränderlichen Faktoren müssen Sie auch die grundsätzliche Bereitschaft für neue
Technologien einschätzen, z. B. solcher, die zum Erstellen einer e-business-Lösung erforderlich sind. Beispiele für
solche Technologien sind [CONA99]:
-
Client/Server,
-
Datenbankmanagement,
-
Programmiersprachen, z. B. HTML, XML, Java,
-
Scriptgesteuerte Serverseiten und Servlets, z. B. Microsoft Active Server Pages, Java Server Pages,
-
Protokolle für die Kommunikation zwischen Objekten, z. B. OMG Common Object Request Broker Architecture
(CORBA), der Java-Standard Remote Method Invocation (RMI) und Microsoft Distributed Component Object Model
(DCOM),
-
Komponenten, z. B. Microsoft ActiveX/COM,
-
Frameworks von Webanwendungen, wie z. B. IBM WebSphere Microsoft Windows DNA.
Diese Bewertung hat einen starken Einfluss auf die Ebene der Risiken, die Sie bereit sind einzugehen, wenn Sie die
Architektur für Ihre Lösung erstellen. Weitere Informationen hierzu finden Sie auf der Seite Aktivität: Projektumfang und -risiken auswerten.
|
Probleme identifizieren
Probleme lassen sich am besten identifizieren, indem eine Reihe von Schlüsselpersonen zu einer Problemerkennungssitzung
zusammengerufen werden. Allgemeine Empfehlungen zum Organisieren einer solchen Sitzung finden Sie auf der Seite Richtlinie: Brainstorming und Reduzierung auf das Wesentliche.
Stellen Sie Fragen wie die folgenden:
-
Was sind die Probleme in der Zielorganisation?
-
Besteht der Eindruck, dass etwas nicht richtig läuft?
-
Liegen die Projekte ständig hinter dem Zeitplan oder über dem Budget?
-
Welche Probleme gibt es in den Projekten?
-
Wurden Metriken erfasst, die analysiert werden können?
Stellen Sie fest, welche negativen Auswirkungen die einzelnen Probleme auf die Projekte haben oder haben werden,
wenn sie nicht beseitigt oder vermindert werden. Um die Auswirkungen eines Problems einschätzen zu können, müssen Sie
verstehen, wie kritisch es ist, das Problem zu beseitigen oder zu mindern.
Ermitteln Sie die eigentlichen Ursachen für die einzelnen Probleme. Wenn Sie die eigentliche Ursache eines
Problems kennen, können Sie besser verstehen, wie das Problem beseitigt oder gemindert werden kann und wie viel dies
kostet. Tannenbaumdiagramme könnten hierbei hilfreich sein. Wenn es mehrere Ursachen für ein
Problem gibt, müssen Sie sie gegeneinander abwägen. In diesem Fall kann ein Pareto-Diagramm hilfreich sein.
Warnung: Häufig wird zu schnell versucht, eine Lösung zu entwickeln, obwohl das Problem selbst noch nicht im Detail
verstanden wurde. Schreiben Sie das Problem auf und stellen Sie fest, ob alle dieser Definition zustimmen.
Klassifizieren Sie die Probleme nach ihren Auswirkungen. Verwenden Sie beispielsweise eine Skala von 1 bis 5, wobei 5
für Probleme mit den gefährlichsten Auswirkungen und 1 für harmlose Probleme steht. Das primäre Ziel ist, die relative
Bedeutung der Probleme zu verstehen.
Die einfachste Methode, um Einigkeit über die Definition eines Problems zu erhalten, ist es, das Problem aufzuschreiben
und festzustellen, ob alle zustimmen. Listen Sie die Probleme in einer Tabelle auf:
Problem
|
Auswirkung
|
Eigentliche Ursachen
|
Rangfolge
|
Die Qualität der gelieferten Software ist schlecht.
|
- Die Kunden sind unzufrieden.
- Wir müssen direkt nach dem Haupt-Release Fehlerkorrekturen ausliefern.
|
- Die Testfälle bieten keine vollständige Deckung.
- Die Tests sind nicht automatisiert.
- Die Testpersonen sind nicht ausreichend geschult.
|
#5
|
...
|
...
|
...
|
...
|
|
Schlussfolgerungen ziehen
Analysieren Sie die Ergebnisse der erfassten Informationen und stellen Sie eine Liste mit Bereichen und Problemen
zusammen, auf die der Schwerpunkt gelegt werden soll. Probleme, die früh angegangen werden müssen, können gewöhnlich
den folgenden Kategorien zugeordnet werden:
-
Hauptproblembereiche. Bereiche, in denen Sie die Leistung der Geschäftsprozesse erheblich verbessern können.
-
Bereiche, in denen Sie kurzfristige Erfolge erzielen können. Bereiche, in denen Sie schnelle Ergebnisse liefern
können.
-
Bereiche, in denen eine Verbesserung besonders deutlich sichtbar wird.
Dokumentieren Sie die erfassten Informationen und die Schlussfolgerungen im Arbeitsergebnis Bewertung der Zielorganisation.
|
Empfehlungen geben
Sie müssen in die Bewertung einige Empfehlungen für die Zukunft einschließen. Die Empfehlung sollte einen Ansatz für
die Geschäftsmodellierung beschreiben. Auf der Seite Konzept: Umfang der Geschäftsmodellierung sind einige typische Szenarios beschrieben.
|
|
Weitere Informationen
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|