One of the key steps in purchasing a BPMS is often to conduct some level of POC to ensure the BPMS matches the organizational needs. In order to obtain the maximum amount of value from the POC effort, there is a significant amount of preparation and planning which should happen before the POC begins. When planning for the POC, there are three main focus areas which must be defined.
1. Scope
Process beginning and ending
Integration to underlying systems
POC participants
Time frame
2. Scoring Criteria
What will be scored (key features, usability, performance, etc.)?
How will it be scored?
Who performs the scoring?
3. Next Steps
What if the POC is successful and what if it isn’t?
Note: If a vendor doesn’t ask about these criteria, consider it a significant warning flag for their delivery capabilities.
Scope
In order for a POC to be of value to an organization, the objectives must be clearly defined and communicated to all participants before the POC begins. This is especially important if the POC is a competitive evaluation where multiple vendors are participating. Organizations need to clearly define the scope and should provide a Q&A session before the POC begins in which all participants are invited to ask questions to clarify any objectives. This will ensure all participants understand the process defined for the POC, are introduced to the appropriate internal resources, and understand the time frame. Additionally, the POC process should be a subset of the larger process which would be implemented upon successful completion of the POC. A successful POC will drive momentum for continuing the implementation of the larger process.
Scoring Criteria
At a minimum, scoring a POC typically contains the following elements:
Functional Capabilities (Process modeling, process execution, simulation, etc.)
Technical Capabilities (System integration, infrastructure requirements, development speed, etc.)
Architectural Fit
End User Experience
The weight of each element will be based upon the importance of the functionality within the organization. For example, simulation capabilities may be highly important in some organizations while not a consideration of the POC for another. When creating the POC socring criteria, both the business and IT functions need to work collaboratively in order to ensure both areas heard evenly in the POC. Additionally, agreement on which function, IT or LOB, is scoring each item should be defined before the POC begins in order to ensure an accurate final score is agreed upon. This will help to identify a solution that may be an architectural fit, but does not meet the business requirements or vice versa.
Next Steps
Before beginning a POC, define next steps upon the completion of a POC communicate the steps both internally and externally. Organizations should also consider both successful and unsuccessful scenarios in their planning phases. Organizations often plan for successful POCs, but tend to not plan for next steps should a POC not be successful. An unsuccessful POC does not necessarily mean a BPMS is not a good fit for an organization. Unsuccessful POCs should have full reviews to evaluate why the POC was not successful. Depending on the identified reasons, an unsuccessful POC can be a catalyst for organizations to further define how a BPMS can best be deployed and also help to further refine the “flavor” of BPMS which will best match the organizational needs. It is much better to find out during a POC that a BPMS doesn’t fit for an organization than to find out while committed to a production delivery timeline.
Successful POC next steps:
Communication of scoring to participants
Selection of a BPMS provider (if a competitive POC)
Extension of the POC into a full implementation
Unsuccessful POC next steps:
POC post mortem (poor product fit, poorly selected process, insufficient involvement, poor delivery partner, etc.)
Evaluation of performing another POC (what are the associated costs, who would be invited to participate, etc.)
Summary
POCs are often a very good way to ensure a BPMS will fit organizationally. With the multitude of flavors of BPMS systems available (document-centric, human-centric, integration-centric, pure-play BPM, etc.) it is often difficult for an organization to properly identify which BPMS system fits their needs without a POC. While a POC is not necessary for all BPMS evaluations, organizations are wise to consider how and where a particular BPMS fits within their organization before executing a license agreement.