Thursday, February 16, 2012

INVENSYS SKELTA PARTNER CONTEST!

DEAR PARTNER,

THANK YOU FOR TAKING THE TIME TO PARTICIPATE IN 'NAME THE WHITEPAPER' CONTEST.









CONTEST DETAILS

1. DOWNLOAD THIS NO NAME WHITEPAPER LINK:
http://www.skelta.com/newsletter/Skelta-Communique/february-2012/Whitepaper-Invensys-Skelta-Contest.pdf

2. SEND US THE TITLE TEXT THAT YOU THINK BEST REPRESENTS THE CONTENT TO invensysskelta.marketing@invensys.com

The marketing folks at Invensys Skelta (who know a thing or two about Whitepapers!) will announce a winner in a week.

SO WHAT DOES THE WINNING ENTRY BAG?

1. A White Paper named by you! - This White Paper will be featured prominently on the Invensys Skelta corporate website, Partner Portal and all Social Media Sites
2. Your company's name in the title credit
3. Links to your company's unique profile page on our corporate website

For any clarifications, please email us on invensysskelta.marketing@invensys.com





Tuesday, February 14, 2012

The Proof is in the Pudding?



Following up on my post last week on what goes into the making of a BPM project, let’s talk a little more about Proof of Concepts (POCs). To truly gain traction from Discovery to Automation and to zero in on the right BPM software, a POC showing your vendor’s competency on a number of issues is essential. It’s simple really – Don’t Invest till you Test!

When it comes to evaluating a POC, there are the usual suspects

-         - Time to delivery from start to finish
-         - Sustainability (does the vendor have the bandwidth and skill to support optimization over a long time period)
-        -  Human reaction to change
-        -  Ability of the product to react to change

But apart from these the most critical test of concept is the scope of the POC. A scope bound POC which is a sub set of the actual BPM project offers enormous clarity to the process owner.  More importantly, as a BPM customer you should be cognizant of your exact BPM requirement before evaluating vendors ... the idea is to map the software to your needs rather than spend time and money on a POC to reinforce its inherent strengths.

A BPM customer should drive the outcome of a POC and test for compatibility with existing IT environments among other things. Introduce scenarios that test vendor agility and response to process change – indication of a strong services team means that you gain from the vendor’s BPM project experience when it comes to building a new application around the product.  For a BPM vendor of course, a well defined POC directly translates to cost efficiencies and in depth understanding of the client’s requirement.


Invest more technical resources in rolling out a POC and you have yourself a sustainable BPM customer who views you more as a BPM partner and less as a software vendor.