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
Thursday, February 16, 2012
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.
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.
Posted by
Kalpa Shah
at
9:08 AM
1 comments
Labels:
bpm,
BPM POCs,
BPM Proof of Concept,
business process management
Subscribe to:
Posts (Atom)