<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Kommentare zu: Was macht Prozesse lauffähig?</title>
	<atom:link href="http://www.computerwoche.de/soa-expertenrat/2008/07/01/was-macht-prozesse-lauffahig/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.computerwoche.de/soa-expertenrat/2008/07/01/was-macht-prozesse-lauffahig/</link>
	<description>Ein Experten-Blog der COMPUTERWOCHE</description>
	<pubDate>Fri, 05 Dec 2008 05:08:16 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>Von: Erich Ortner</title>
		<link>http://www.computerwoche.de/soa-expertenrat/2008/07/01/was-macht-prozesse-lauffahig/#comment-29191</link>
		<dc:creator>Erich Ortner</dc:creator>
		<pubDate>Tue, 01 Jul 2008 18:48:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.computerwoche.de/soa-expertenrat/?p=310#comment-29191</guid>
		<description>Hallo Herr Ostermann,

ich habe in unserem Arbeitsgebiet, der Geschäfts- und Betriebsprozessmodellierung im Hinblick auf den Einsatz von IT-Services ähnliche Schwierigkeiten wie Sie mit solchen Einteilungen wie "Top-Down" und "Bottom-Up". Man weiss nämlich nie, was der Gesprächpartner als Top (hier: die Ablauf- und Aufbauorganisation des Unternehmens) und was als Bottom (hier: das Rechnersystem und die IT-Services) verstanden wissen möchte. Zudem klingt "Top-Down" nach "grob" und "Bottom-Up" nach "detailliert". Dieser Sprachgebrauch ist jedoch in der Praxis vielfach anzutreffen.

Ich würde, um Mißverständnisse auszuräumen, unabhängig davon, ob wir uns auf der Ebene der Unternehmensorganisation oder auf der Ebene der IT befinden, lieber einen Modellierungsanfang "aus der Mitte" heraus suchen. Also: Auch bei der Aufgaben- und Arbeitsprozessmodellierung von Einheiten (Komponenten) mittlerer Größe ausgehen und dann einer Insight-The-Component/Outsight-The-Component-Dychotomie das Wort reden.

Je nachdem, wie genau wir die Modellierung hierbei jeweils durchführen können, kommen wir zu einer hohen "Runnability" (spezifizierte "Betriebsmittel" der Prozesse) sowie einer hohen "Applicability" (spezifizierte "Bezugsobjekte" der Prozesse) unserer Prozessmodelle. Ein Betriebsmittel eines Prozesses ist bspw. ein Arbeitsplan, der einzuhalten ist und ein Bezugsobjekt eines Prozesses könnte bspw. ein Störfall in einem Unternehmen sein, dessen Beseitigung das Prozessmodell (Runnability) garantiert.

Die Modellierungsrichtung wäre: From Applicability to Runnability! Denn warum soll ich Prozessen eine Runnability (Betriebsmittel) "aufmodellieren", wenn ich noch nicht spezifiziert habe, was eigentlich ihre Applicability (Bezugsobjekte) sein wird?

Beste Grüsse
Erich Ortner</description>
		<content:encoded><![CDATA[<p>Hallo Herr Ostermann,</p>
<p>ich habe in unserem Arbeitsgebiet, der Geschäfts- und Betriebsprozessmodellierung im Hinblick auf den Einsatz von IT-Services ähnliche Schwierigkeiten wie Sie mit solchen Einteilungen wie &#8220;Top-Down&#8221; und &#8220;Bottom-Up&#8221;. Man weiss nämlich nie, was der Gesprächpartner als Top (hier: die Ablauf- und Aufbauorganisation des Unternehmens) und was als Bottom (hier: das Rechnersystem und die IT-Services) verstanden wissen möchte. Zudem klingt &#8220;Top-Down&#8221; nach &#8220;grob&#8221; und &#8220;Bottom-Up&#8221; nach &#8220;detailliert&#8221;. Dieser Sprachgebrauch ist jedoch in der Praxis vielfach anzutreffen.</p>
<p>Ich würde, um Mißverständnisse auszuräumen, unabhängig davon, ob wir uns auf der Ebene der Unternehmensorganisation oder auf der Ebene der IT befinden, lieber einen Modellierungsanfang &#8220;aus der Mitte&#8221; heraus suchen. Also: Auch bei der Aufgaben- und Arbeitsprozessmodellierung von Einheiten (Komponenten) mittlerer Größe ausgehen und dann einer Insight-The-Component/Outsight-The-Component-Dychotomie das Wort reden.</p>
<p>Je nachdem, wie genau wir die Modellierung hierbei jeweils durchführen können, kommen wir zu einer hohen &#8220;Runnability&#8221; (spezifizierte &#8220;Betriebsmittel&#8221; der Prozesse) sowie einer hohen &#8220;Applicability&#8221; (spezifizierte &#8220;Bezugsobjekte&#8221; der Prozesse) unserer Prozessmodelle. Ein Betriebsmittel eines Prozesses ist bspw. ein Arbeitsplan, der einzuhalten ist und ein Bezugsobjekt eines Prozesses könnte bspw. ein Störfall in einem Unternehmen sein, dessen Beseitigung das Prozessmodell (Runnability) garantiert.</p>
<p>Die Modellierungsrichtung wäre: From Applicability to Runnability! Denn warum soll ich Prozessen eine Runnability (Betriebsmittel) &#8220;aufmodellieren&#8221;, wenn ich noch nicht spezifiziert habe, was eigentlich ihre Applicability (Bezugsobjekte) sein wird?</p>
<p>Beste Grüsse<br />
Erich Ortner</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Falk Ostermann</title>
		<link>http://www.computerwoche.de/soa-expertenrat/2008/07/01/was-macht-prozesse-lauffahig/#comment-29190</link>
		<dc:creator>Falk Ostermann</dc:creator>
		<pubDate>Tue, 01 Jul 2008 08:58:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.computerwoche.de/soa-expertenrat/?p=310#comment-29190</guid>
		<description>Hallo,

ich sehe die größte Herausforderung zur Erreicherung von lauffähigen, technischen Prozessen, welche auf der initialen fachlichen Modellierung (Kompetenz BPM) beruhen, in der Abkehr vom Bottom-Up-Prinzip (bspw. Anwendungsfallmodellierung in UML) als Folge der Top-Down-Modellierung (Geschäftsprozessmodelle). Vielmehr gilt es, in Form einer erweiterten Geschäftsprozessmodellierungsphase Hilfsmittel wie eine Prozesslandkarte, Domänenmodell, Anwendungslandschaft, Rollen, Geschäftsobjekte, etc. heranzuziehen und die fachlich modellierten Geschäftsprozesse mit Informationen aus den genannten Hilfsmitteln anzureichern. Dadurch entstehen (theoretisch) fachlich orientierte, technisch angereicherte, ausführbare Prozesse, welche als Grundlage (plus weitere Ergebnistypen wie eine Liste der fachlichen Schnittstellen und Geschäftsobjekte) für die eigentliche implementierungsnahe Modellierung (z.B. UML) dienen. Die sogenannte "Runnability" zeichnet sich ja nicht durch eine maximale Detailmodellierung auf technischer Ebene aus, sondern durch die Ausrichtung an der Fachlichkeit! Der Mitarbeiter handelt fachlich, nicht technisch. Daher ist die Übertragung der "Fachsemantik" aus den GP-Modellen in die durch Services unterstütze ausführbare Prozesse mit Hilfe sequenzieller, teils iterativer Modellierungsstufen ein Hauptanliegen zur Erreichung von "Runnability" - denn ohne Nutzer leben die Prozesse nicht (außer bei einer 100%igen Automatisierung).

Viele Grüße,
Falk Ostermann
SAPICON GmbH</description>
		<content:encoded><![CDATA[<p>Hallo,</p>
<p>ich sehe die größte Herausforderung zur Erreicherung von lauffähigen, technischen Prozessen, welche auf der initialen fachlichen Modellierung (Kompetenz BPM) beruhen, in der Abkehr vom Bottom-Up-Prinzip (bspw. Anwendungsfallmodellierung in UML) als Folge der Top-Down-Modellierung (Geschäftsprozessmodelle). Vielmehr gilt es, in Form einer erweiterten Geschäftsprozessmodellierungsphase Hilfsmittel wie eine Prozesslandkarte, Domänenmodell, Anwendungslandschaft, Rollen, Geschäftsobjekte, etc. heranzuziehen und die fachlich modellierten Geschäftsprozesse mit Informationen aus den genannten Hilfsmitteln anzureichern. Dadurch entstehen (theoretisch) fachlich orientierte, technisch angereicherte, ausführbare Prozesse, welche als Grundlage (plus weitere Ergebnistypen wie eine Liste der fachlichen Schnittstellen und Geschäftsobjekte) für die eigentliche implementierungsnahe Modellierung (z.B. UML) dienen. Die sogenannte &#8220;Runnability&#8221; zeichnet sich ja nicht durch eine maximale Detailmodellierung auf technischer Ebene aus, sondern durch die Ausrichtung an der Fachlichkeit! Der Mitarbeiter handelt fachlich, nicht technisch. Daher ist die Übertragung der &#8220;Fachsemantik&#8221; aus den GP-Modellen in die durch Services unterstütze ausführbare Prozesse mit Hilfe sequenzieller, teils iterativer Modellierungsstufen ein Hauptanliegen zur Erreichung von &#8220;Runnability&#8221; - denn ohne Nutzer leben die Prozesse nicht (außer bei einer 100%igen Automatisierung).</p>
<p>Viele Grüße,<br />
Falk Ostermann<br />
SAPICON GmbH</p>
]]></content:encoded>
	</item>
</channel>
</rss>
