<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Process for the Enterprise - Latest Comments</title><link xmlns="http://www.w3.org/2005/Atom" rel="http://api.friendfeed.com/2008/03#sup" href="http://disqus.com/sup/all.sup#forumcomments-fae1e77d" type="application/json"/><link>http://bp3-process-enterprise.disqus.com/</link><description></description><atom:link href="http://bp3-process-enterprise.disqus.com/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Fri, 27 Jan 2012 19:06:42 -0000</lastBuildDate><item><title>Re: Appian 2011 Results</title><link>http://www.bp-3.com/blogs/2012/01/appian-2011-results/#comment-422657029</link><description>Lots of orders at $1 is not the same as lots of orders at $250,000.  &lt;br&gt;Without ASP, Revenue, or any other metric, # of orders isn't very &lt;br&gt;meaningful. &lt;br&gt;&lt;br&gt;Sure, revenue recognition applies, but they still get revenue. they can call it bookings (sold, not necessarily recognized yet), cash, or accrual basis.  If they said revenue without any qualifier I wouldn't assume that it is all recognized unless it was in a financial disclosure of the official variety. If what they really meant was that their "bookings" increased by 200+% they should just say that - it is clear and really quite impressive.   &lt;br&gt;&lt;br&gt;Having worked at a few private companies, we never counted orders as an interesting metric by itself. &lt;br&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Fri, 27 Jan 2012 19:06:42 -0000</pubDate></item><item><title>Re: Appian 2011 Results</title><link>http://www.bp-3.com/blogs/2012/01/appian-2011-results/#comment-422640510</link><description>Revenue recognition rules typically apply. Until a project is complete it is deferred revenue.  Even for private companies. Orders is a legit reference and not a bad benchmark for business performance particularly for doing year over year comparisons.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jcristobal</dc:creator><pubDate>Fri, 27 Jan 2012 18:31:44 -0000</pubDate></item><item><title>Re: BPM Mobility: Server Architectures Reviewed</title><link>http://www.bp-3.com/blogs/2012/01/bpm-mobility-server-architectures-reviewed/#comment-420411015</link><description>The portal has been with BPM practically from the very beginning and it &lt;br&gt;exists today mostly in its original form as web-application. Loud Castle Media increase conversions and reduce cost of acquisition for online lead &lt;br&gt;generation companies – from lead buyers to lead sellers - in the &lt;br&gt;healthcare, education, automotive, home improvement, and other franchise&lt;br&gt; systems.For more visit &lt;a href="http://www.loudcastle.com" rel="nofollow"&gt;mobility leads &lt;/a&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mobility leads</dc:creator><pubDate>Wed, 25 Jan 2012 04:07:10 -0000</pubDate></item><item><title>Re: Happy New Year! (2012 Edition)</title><link>http://www.bp-3.com/blogs/2012/01/happy-new-year-2012-edition/#comment-406307943</link><description>Thanks Jakob- and indeed it does seem like we have a lot of parallels, both coincidental (like our relative youth as companies) and intentional (culture, dedication to BPM as a practice not just a technology choice).  Really enjoy following your company's developments as well!  If I get anywhere near Berlin I will try to connect with you in person!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Mon, 09 Jan 2012 10:36:47 -0000</pubDate></item><item><title>Re: Happy New Year! (2012 Edition)</title><link>http://www.bp-3.com/blogs/2012/01/happy-new-year-2012-edition/#comment-405609210</link><description>congratulations, Scott. Actually I think BP3 and camunda are quite similar somehow, because we are both young companies, very dedicated to BPM and just love what we do, and fortunately we are both doing well without becoming too proud about it. Interesting to watch that kind of similar development about 8.5 thousand km away from each other (Austin-Berlin). Have a good 2012!&lt;br&gt;&lt;br&gt;Jakob</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jakob Freund</dc:creator><pubDate>Sun, 08 Jan 2012 18:24:58 -0000</pubDate></item><item><title>Re: A New Process for Products?</title><link>http://www.bp-3.com/blogs/2011/12/a-new-process-for-products/#comment-396834659</link><description>case in point: twine. asked for $35,000 to be the minimum for a production run, raised over $400,000... &lt;br&gt;&lt;a href="http://www.businessinsider.com/twine-kickstarter-2011-12" rel="nofollow"&gt;http://www.businessinsider.com...&lt;/a&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Thu, 29 Dec 2011 16:46:55 -0000</pubDate></item><item><title>Re: BPM Methods: A Change in Software LifeCycle</title><link>http://www.bp-3.com/blogs/2011/12/bpm-methods-a-change-in-software-lifecycle/#comment-395187023</link><description>eliminating barriers to these specialists working together is key.  I'm often reminded of the scene from office space (the movie), where they're interviewing the liaison between technical and business people at the company and he defends his paper pushing with "I'm a people person!"</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Tue, 27 Dec 2011 15:46:26 -0000</pubDate></item><item><title>Re: A New Process for Products?</title><link>http://www.bp-3.com/blogs/2011/12/a-new-process-for-products/#comment-395184153</link><description>Max, it goes without saying that it is for small product launches.  (at least, when physical goods are in the picture).  Apple will not need to use this kickstarter process for their next product ;) &lt;br&gt;&lt;br&gt;But, for those with ideas, but not capital - this is a great mechanism to bridge the gap.  Of course it works particularly well for niche products and markets - but it may also work well for demand that we perceive as niche- but discover it isn't.  &lt;br&gt;&lt;br&gt;The book analogy is interesting - but if you go the ebook route there's no cost of goods sold.  You can't show someone the cover of a book and have them decide they want to pre-buy.  But you can show someone a watch. Or a stylus.  Or a iPhone doc.  Or a tripod.  Physical goods that can be demonstrated in a video, for example. &lt;br&gt;&lt;br&gt;The process is interesting because it lowers the barriers to marketing that you just mentioned.  Fewer dollars required to get that niche demand solidified. Social media from earlier adopters can help you build from niche to small market.  The scope of your market isn't your town or locale, but "kickstarter" + its social media reach.  &lt;br&gt;&lt;br&gt;These same people and crafts can exist without kickstarter, and yet they can't unlock the value of their own products and designs easily - the company they work for may not be in that business or may not be interested in investing in a niche idea.  Or they may not have the access to capital they need for even a small 100 unit run - even small retailers will want some volume to put on a store shelf.  &lt;br&gt;&lt;br&gt;As for movies and books - the key difference is that you can produce these items with little incremental (variable) cost.  Movies and books can be distributed electronically.  It doesn't mean that there will be demand, it just means that you don't have to spend money first, to find out if there is demand (you used to have to do this, which is why finding a publisher was so important).  Can't really do that with a physical stylus or a watch.  Producing physical product *in advance of demand* is expensive.  Kickstarter and other sites like it reduce the up-front capital costs.  &lt;br&gt;&lt;br&gt;The process is interesting precisely because it gets non-creative elements out of the way (finding a financial backer, fundraising, inventory management) until AFTER you have a hit on your hands, rather than before you have a hit... &lt;br&gt;&lt;br&gt;scott</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Tue, 27 Dec 2011 15:42:48 -0000</pubDate></item><item><title>Re: BPM Methods: A Change in Software LifeCycle</title><link>http://www.bp-3.com/blogs/2011/12/bpm-methods-a-change-in-software-lifecycle/#comment-395090076</link><description>Trygve Reenskaug: Lean secret: "...unite specialists together in one room: everybody, all together, from early on." from a review of "Lean architecture" by James O. Coplien. Did a training with him not to long ago, everything is spot on, even for BPM although he did only partly recognize that since he sees BPM as a DSL in the 'software development' process.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ronald van Kuijk</dc:creator><pubDate>Tue, 27 Dec 2011 13:03:46 -0000</pubDate></item><item><title>Re: A New Process for Products?</title><link>http://www.bp-3.com/blogs/2011/12/a-new-process-for-products/#comment-394880465</link><description>Scott, the process of design-sell-build is a good idea, but it will only work for a small product. As soon as it is something bigger it won't. The biggest issue will be that it is not possible to get a large number of customers to commit and then wait. Neither did the grand innovators work this way. Most of their ideas were kind of improvements on existing products that didn't require a kind of radical change of mind either. Most fats catching on ideas do spend a substantial amount on marketing as well. &lt;br&gt;&lt;br&gt;Example: I have written a number of novels and everyone who reads them says they are great, but without spending the money on advertizing that won't do anything. Plus, just throwing the idea out is not yet everything. Additionally, like with a movie, even when you have a great script, so much depends on the chemistry of creation. The same thing is true for any product. It is not the process, but it is the people and the entrepreneur must be able to find and build a team of people that will be able to turn the idea into reality. &lt;br&gt;&lt;br&gt;So while you mention the craftsmanship part as an element of process, I recommend to focus on people and don't waste your time on process. It is utterly irrelevant to the outcome when we talk about creativity.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Max Pucher</dc:creator><pubDate>Tue, 27 Dec 2011 04:06:54 -0000</pubDate></item><item><title>Re: A Short Review of Cosmonaut</title><link>http://www.bp-3.com/blogs/2011/12/a-short-review-of-cosmonaut/#comment-394319969</link><description>Thanks for the hint.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anatoly Belychook</dc:creator><pubDate>Mon, 26 Dec 2011 02:38:17 -0000</pubDate></item><item><title>Re: The Not-Integrated Approach</title><link>http://www.bp-3.com/blogs/2011/12/the-not-integrated-approach/#comment-388054437</link><description>Maybe one of the ironies is that people classified RIM as "integrated"... but clearly there's a difference between RIM's notion of integrated, and Apple's...</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Fri, 16 Dec 2011 11:30:41 -0000</pubDate></item><item><title>Re: How Big a Role for BPMN?</title><link>http://www.bp-3.com/blogs/2011/12/how-big-a-role-for-bpmn/#comment-384994508</link><description>Very informative tips. I agree. Thank you. &lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;a href="http://www.scanmyessay.com/plagiarism-detection-software.php" rel="nofollow"&gt;Plagiarism detection&lt;/a&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tim Jonson</dc:creator><pubDate>Mon, 12 Dec 2011 12:51:30 -0000</pubDate></item><item><title>Re: More BPM Acquisitions in 2011</title><link>http://www.bp-3.com/blogs/2011/12/more-bpm-acquisitions-in-2011/#comment-382875096</link><description>Interesting point by Dave Brakoniecki on valuation: &lt;br&gt;&lt;a href="http://blog.brakoniecki.com/bpm-valuation-metric-kofax-singularity" rel="nofollow"&gt;http://blog.brakoniecki.com/bp...&lt;/a&gt;&lt;br&gt;"Singularity went for 3x revenues but interestingly their revenue mix was heavily weighted towards services (over 50% was service revenue compared to under 20% license revenue).&lt;br&gt;&lt;br&gt;At that mix, they might be arguably be valued more like a consultancy with some IP than a product business."&lt;br&gt;&lt;br&gt;Hm. probably consulting revenue was valued around 1x revenue.  So purchase price was 3x, valuation of consulting was likely around .5x.  And therefore, the remaining 50% of the business was valued at about 5x (5 * .5x = 2.5x).&lt;br&gt;&lt;br&gt;Consulting revenue might have been valued higher, but probably not as high as 3x.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Fri, 09 Dec 2011 10:41:10 -0000</pubDate></item><item><title>Re: A Defense of Taylorism</title><link>http://www.bp-3.com/blogs/2011/11/a-defense-of-taylorism/#comment-374263369</link><description>you're right, it was keith who made that point.  I think he overstated the case (there's still a ton of routine work out there, for one thing), but he did make that case. &lt;br&gt;&lt;br&gt;I think "automate" is not the right word though.  The way you're using it I believe you mean "remove humans from the process". That is such a narrow definition of that term, and of BPM.  In my view it is barely a process at all if it can be "automated" as in, computers alone do all the work - at that point it is more accurate to describe it as a program.  &lt;br&gt;&lt;br&gt;For a process, I think a starting assumption is that it can not be 100% automated.  So the goal is to provide the best possible framework for teeing up the work, and integrating information sources and decisions.  &lt;br&gt;&lt;br&gt;I guess my issue is that I think the people who focused only on automation essentially "lost" the BPM debate. The BPEL folks lost to BPMN, the folks who basically had good systems integration software ended up acquiring the more human-oriented BPMS's out there, in order to stay relevant and grow their business.  So to me, coming from one of those more people-oriented vendor backgrounds, it is a bit ironic that it is at that moment of victory, in a sense, that part of our BPM community decides to rename that part of the work that is knowledge work as "ACM" :)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Mon, 28 Nov 2011 11:43:05 -0000</pubDate></item><item><title>Re: A Defense of Taylorism</title><link>http://www.bp-3.com/blogs/2011/11/a-defense-of-taylorism/#comment-373993782</link><description>I think it was Keith (Swenson) that pointed out that the success of the tools and methodologies for routine work is causing the current interest in ACM - those tools allow people to be freed up to spend more time on knowledge work. Now it is time to for the process community to provide more assistance to knowledge work - hence ACM.&lt;br&gt;&lt;br&gt;My stance is that if you can automate a process, you should, because it really isn't knowledge work. That is exactly what a BPMS is for. But the real win is for a company to use routine process automation (Taylorism) to free up the organization to focus on the real differentiating work (knowledge work). That is where BPMS falls down.&lt;br&gt;&lt;br&gt;I agree that ACM isn't new - only the name is. The desire to use computing technology to manage knowledge work (and collaboration) actually pre-dates BPM, it is just that it was overshadowed (and mostly ignored) by BPMS community. It is time for the pendulum to swing back.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jacob Ukelson</dc:creator><pubDate>Sun, 27 Nov 2011 23:35:56 -0000</pubDate></item><item><title>Re: BPM and Healthcare</title><link>http://www.bp-3.com/blogs/2011/11/bpm-and-healthcare/#comment-369418748</link><description>Jeoff - I used "case" as shorthand for the ACM approach - proponents of which typically start with the presumption that no experts are involved designing the process, for example (no modeling, no BPMN, no integrations, etc.).  Processes like "treating a patient" allegedly can't be managed by BPM, because they're emergent, or unpredictable, or simply not known in advance.  &lt;br&gt;&lt;br&gt;ACM typically rejects scientific approaches to process, eschewing them in exchange for the ability of individual actors to define their processes (task lists, approvals, etc.) on the fly.  Obviously the ACM community isn't of a single mind on these issues, but those are common threads if you read Keith Swenson's blog, for example, or Jacob Ukelson's, two of the more thoughtful writers on the subject.&lt;br&gt;&lt;br&gt;This blog: &lt;a href="http://www.bp-3.com/blogs/2010/06/less-controversial-bpm-vs-case-management-comparison/" rel="nofollow"&gt;http://www.bp-3.com/blogs/2010...&lt;/a&gt;&lt;br&gt;gives a good example of how ACM tends to focus on the singular - how can I make the treatment of THIS patient better.  But BPM efforts are typically more focused on the aggregate - how can I improve average outcomes for all my patients moving through the hospital or treatment center. &lt;br&gt;&lt;br&gt;So, to answer your question - it isn't that case strategies make it harder, or preclude aggregating data - it is just that the act of basing process improvements on that data is a BPM approach, not a "case" approach (or at least not an ACM approach) because it starts with the assumption that a process expert might know something the individual actors in the process don't.  In the ACM approach, why would any data be tracked about the autoclave at all? It (a) requires integration, and (b) isn't directly related to the process of treating the patient.  Why would one examine bed layout in aggregate rather than a particular patient's bed location?  &lt;br&gt;&lt;br&gt;There's no reason why ACM and BPM approaches to problem solving can't be combined.  In fact, I consider it only one software market because they're both addressing similar business problems, but with a different emphasis.  Two sides of the same coin of business process improvement and management, in my opinion.  Much like 5s and Lean are related, and complementary, but are not the same thing. And yet they tend to be applied together, by the same teams and experts. However, the ACM folks are trying to split it into a separate, distinct market, and often use doctors treating patients as a prime example of a place where BPM simply can't help because the treatment can't be known in advance ... this article (and others like it ) are stark proof that this argument is simply wrong because it misses the whole point.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Mon, 21 Nov 2011 11:34:10 -0000</pubDate></item><item><title>Re: BPM and Healthcare</title><link>http://www.bp-3.com/blogs/2011/11/bpm-and-healthcare/#comment-369307709</link><description>I'm trying to understand your point better. It sounds like you're saying that "case" strategies make it harder to aggregate data. Please elaborate on why a case approach would never address changing bed layouts or find a malfunctioning autoclave.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jeoff Wilks</dc:creator><pubDate>Mon, 21 Nov 2011 08:28:32 -0000</pubDate></item><item><title>Re: The Trouble with Rules (and who owns them)</title><link>http://www.bp-3.com/blogs/2011/11/the-trouble-with-rules-and-who-owns-them/#comment-368410534</link><description>Check out Larry Goldberg's book The Decision Model.  It's a great methodology for creating business-vetted and -maintained rule sets, when there are literally thousands of them.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Bruce Silver</dc:creator><pubDate>Sat, 19 Nov 2011 14:55:52 -0000</pubDate></item><item><title>Re: Lamenting Definitions</title><link>http://www.bp-3.com/blogs/2011/11/lamenting-definitions/#comment-364751606</link><description>Bruce, to your point about "implemented by BPMS" - to me this doesn't necessarily mean that a consultant or IT specialist will implement, it means a product developer at a BPM vendor will implement.  Second, its a fair point that for CM/ACM of certain profiles a modeling notation would make sense (insurance claims come to mind).&lt;br&gt;&lt;br&gt;I was tempted to make this point myself, but I felt like I might be putting words in your mouth.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Wed, 16 Nov 2011 11:46:16 -0000</pubDate></item><item><title>Re: Lamenting Definitions</title><link>http://www.bp-3.com/blogs/2011/11/lamenting-definitions/#comment-364743935</link><description>Actually I made both points, first that "most" case management can and ultimately will be implemented by BPMS rather than dedicated ACM tools, although current BPMS may not be good enough yet.  And second, to the extent that ACM benefits by having any modeling notation at all (maybe Keith thinks it does not), it would be better to try to *extend* BPMN than start over completely.  The second point really follows from the first.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Bruce Silver</dc:creator><pubDate>Wed, 16 Nov 2011 11:36:19 -0000</pubDate></item><item><title>Re: Lamenting Definitions</title><link>http://www.bp-3.com/blogs/2011/11/lamenting-definitions/#comment-363713761</link><description>Jacob -this comment hits home: "for many BPM vendors the goal is make business processes 'non-knowledge' processes" - that's a very fair criticism.  I'm not sure if that comes more from the vendors or the customers but it is unfortunate that that is often the case.&lt;br&gt;&lt;br&gt;And your next comment about the model - "not that it isn't important, it just isn't what makes the business special" - Amen. &lt;br&gt;&lt;br&gt;I'm all for a more productive "language" to describe work or business.  I think that's what BPMN represents for a certain class of business problems.  Just as Ruby might be better for a certain class of coding problems than, say, cobol.  &lt;br&gt;&lt;br&gt;But even within a BPMS, BPMN isn't the only "language" - it just happens to be the business-oriented one.  There are technical languages as well.  I think there's room for another "language" for describing work/business.  Maybe the principles behind ACM will drive that.  Or maybe a product's vision will become the de-facto standard.  Thinking of the way MS Outlook does calendaring. There wasn't a "standard" for the language of seeing and setting reminders and calendar entries and color coding, etc.  But it is a bit of a standard - in the sense that it had wide adoption and it represents the expectations that other tools get measured against.  &lt;br&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Tue, 15 Nov 2011 10:37:18 -0000</pubDate></item><item><title>Re: Lamenting Definitions</title><link>http://www.bp-3.com/blogs/2011/11/lamenting-definitions/#comment-363698583</link><description>Keith - fair enough.  Rather than try to explain what I think Bruce is getting at, I'll concede the point :) &lt;br&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Tue, 15 Nov 2011 10:25:55 -0000</pubDate></item><item><title>Re: Bruce Silver Weighs in on Metaphysical Questions</title><link>http://www.bp-3.com/blogs/2011/11/bruce-silver-weighs-in-on-metaphysical-questions/#comment-363693094</link><description>Keith, thanks for the corrections - I'm guilty of muddying the water between the singular and the plural (its hard to keep each person's views on ACM separate - and my language around this got a bit lazy). &lt;br&gt;&lt;br&gt;This is the core argument: "I understand quite well that you and Bruce are taking the position that the market will choose one category for the 'spectrum.'  My position is precisely the opposite: that these markets are distinct." &lt;br&gt;&lt;br&gt;Which ties into the analogy you made - a car and a boat.  The question isn't whether you should build an amphibious vehicle. The question is whether they are really cars and boats, or two types of car. &lt;br&gt;&lt;br&gt;Example:  Phone, and MP3 player, hand-held gaming devices, and GPS.  Everyone assumed these were different categories of device.  And then the iPhone came out.  And it turns out, they were all just apps on top of a good handheld, touch-based computer.  We just didn't know it yet. &lt;br&gt;&lt;br&gt;So you might be right that these are separate markets-  and my hypothesis that it is one market may be right.  The real question comes down to whether customers (companies) buy both BPM and ACM solutions, or just one or the other.  If it is just one or the other, then it is one market, right?  If they largely buy both, it is two markets until substantially all of the vendors offer both or sell them as a package. &lt;br&gt;&lt;br&gt;(much as word processors and spreadsheets were separate markets until Microsoft sold them as a suite, that created one "office productivity application" market).  &lt;br&gt;  &lt;br&gt;Thanks for patiently re-explaining this to me - really helps my understanding of why we're in disagreement - we just have different hypotheses (or positions, if you like) that we think are true.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Tue, 15 Nov 2011 10:18:57 -0000</pubDate></item><item><title>Re: Bruce Silver Weighs in on Metaphysical Questions</title><link>http://www.bp-3.com/blogs/2011/11/bruce-silver-weighs-in-on-metaphysical-questions/#comment-363685122</link><description>You've cited examples consistent with ACM before - I'm interested in a company that self-identifies as ACM.  I think those are the most interesting cases to look at to understand how the market might evolve on the "enterprise side".  Mind you, consumer-inspired tech may be winners (twitter, yammer, something like these tools).  But that's a separate series of blog posts :)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sfrancis</dc:creator><pubDate>Tue, 15 Nov 2011 10:08:53 -0000</pubDate></item></channel></rss>
