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
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