<?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>Комментарии к записи: Стартовый сигнал BPMN</title>
	<atom:link href="http://mainthing.ru/item/318/feed/" rel="self" type="application/rss+xml" />
	<link>https://mainthing.ru/ru/item/318/</link>
	<description>BPM-блог Анатолия Белайчука</description>
	<pubDate>Tue, 14 Apr 2026 06:49:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>Автор: Scott</title>
		<link>https://mainthing.ru/ru/item/318/#comment-779</link>
		<dc:creator>Scott</dc:creator>
		<pubDate>Mon, 04 Oct 2010 19:25:21 +0000</pubDate>
		<guid isPermaLink="false">http://mainthing.ru/?p=318#comment-779</guid>
		<description>Interesting writeup.  This is, incidentally, how one BPM product always treated events (since 2004/5) - e.g. late binding of them to process starts and Intermediate messages across any number of instances.  Its a very useful abstraction.</description>
		<content:encoded><![CDATA[<p>Interesting writeup.  This is, incidentally, how one BPM product always treated events (since 2004/5) - e.g. late binding of them to process starts and Intermediate messages across any number of instances.  Its a very useful abstraction.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Anatoly Belychook</title>
		<link>https://mainthing.ru/ru/item/318/#comment-773</link>
		<dc:creator>Anatoly Belychook</dc:creator>
		<pubDate>Tue, 14 Sep 2010 11:31:13 +0000</pubDate>
		<guid isPermaLink="false">http://mainthing.ru/?p=318#comment-773</guid>
		<description>Dave

Regarding end-to-end processes: it'd be too simple if they could be implemented by a single-threaded diagram. It's an extremly vulgar view.

I'm going to get back to this topic because for me it's the coolest thing in BPM and BPMN.

Anatoly</description>
		<content:encoded><![CDATA[<p>Dave</p>
<p>Regarding end-to-end processes: it&#8217;d be too simple if they could be implemented by a single-threaded diagram. It&#8217;s an extremly vulgar view.</p>
<p>I&#8217;m going to get back to this topic because for me it&#8217;s the coolest thing in BPM and BPMN.</p>
<p>Anatoly</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: David French</title>
		<link>https://mainthing.ru/ru/item/318/#comment-772</link>
		<dc:creator>David French</dc:creator>
		<pubDate>Mon, 13 Sep 2010 20:05:29 +0000</pubDate>
		<guid isPermaLink="false">http://mainthing.ru/?p=318#comment-772</guid>
		<description>It allows the ultimate "late binding" of not having to design the world process ... only the bit you are in control of at the moment. When you come to an event that you know will be useful to another bit of the enterprise ... Signal ... then when a use is found in another bit of process design you do not have to redo the process design work again. Of course, you will need a way to hunt down these useful signals and some standardisation of how they will look in your enterprise.
Yes, I know that the end-end process is sacrosanct but the real world is better with some compartmentalising ... a bit like the IT world of programming.</description>
		<content:encoded><![CDATA[<p>It allows the ultimate &#8220;late binding&#8221; of not having to design the world process &#8230; only the bit you are in control of at the moment. When you come to an event that you know will be useful to another bit of the enterprise &#8230; Signal &#8230; then when a use is found in another bit of process design you do not have to redo the process design work again. Of course, you will need a way to hunt down these useful signals and some standardisation of how they will look in your enterprise.<br />
Yes, I know that the end-end process is sacrosanct but the real world is better with some compartmentalising &#8230; a bit like the IT world of programming.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
