There are some limitations in the free trial, such as a reduced controls and risk library and you don’t have access to Alyne’s risk management module. If your organisation wants to understand Alyne’s full capability in the context of your organisation, a Proof of Concept is the best way to go. It enables decision makers to get hands on experience with the solution and learn what it means to experiment with RegTech in an agile way. We have run a number of successful Proof of Concepts with some great customers and I would like to share our learnings.
- Define one or two specific use cases
Think of a use case where Alyne can demonstrate value and you see optimisation potential in your current setup. In our experience it is important to have an objective by which to measure the success of the PoC.
- Interact with the solution
It is important you get participants to actually interact with the solution. Alyne is very easy to use, but we know that there is always a small threshold that needs to be crossed to try something new. Actually working with the solution rather than just watching demos is essential.
- Obtain stakeholder awareness
Make stakeholders and decision makers aware of the PoC and ensure they have enough engagement with the project to be in a position to support an informed decision at the end of the PoC.
- Decide your approach to data
You can either work with test data or implement a use case on production data. Using test data may reduce the effort for obtaining approval for the PoC internally, however using production data will increase the re-useability of the PoC’s outcomes. Making a strategic decision up front is necessary, however.
Before you start the PoC, it is essential you ensure the participants have enough time to invest in the project. If one group cannot spend sufficient time on the project, the PoC may waste others’ time needlessly. You have Alyne’s commitment that we will be transparent of the involvement and support required from you and use your time efficiently. For a successful PoC you should involve at least the following user groups.
- Alyne Power User
Define at least one resource to become an Alyne power user. The objective of this role is to build internal expertise around Alyne during the PoC to be able to function as a multiplier in later project stages and a subject matter expert in the decision processes.
- Friendly Business Users
Include users from a business unit that can provide feedback and are open to the process and the outcomes of the PoC. These should be users that have an appetite and mindset for change and can evaluate the solution in context of the rest of the organisation.
- PoC Project Manager
Nominate one person to lead the project and coordinate activities between the Alyne Support, business users and the power users. This person should also be in charge of the evaluation of the PoC outcomes and the recommendation to the sponsors.
You may of course have your own criteria catalogue, but at Alyne we always provide at least a suggestion of functional content to apply. The same is true for your PoC evaluation criteria. We recommend including the following factors.
- Is the usage of the platform intuitive?
- Could PoC users execute the defined use case with acceptable assistance?
- Did the solution work well on our devices and workstation configuration?
- Cost and Benefit
- How do the expected operational cost compare against current solutions or alternative options?
- Based on PoC experience, what is the effort to implement the use case for production?
- What are the estimated usage and operational costs on an ongoing basis for the planned use case and how does this compare to on premise solutions over the product life cycle?
- Use Case Coverage
- How well does the solution cover the use case requirements end to end?
- Is the required input data able to be captured?
- Does the content library cover topics, standards and regulations relevant to the use case?
- How does the produced output compare to alternative solution?
- Is the output generation sufficiently scalable for the use case at hand?
- Does reporting allow to drill down into sufficient levels of depth to answer management questions?
- Is the information design of the reported data helpful for analysis?
- Is the underlying data readily available for further analysis as needed?
- Is the defined availability of the solution sufficient for the intended use case?
- Does the solution support the desired level of authentication?
- Has the security architecture been designed to enable a sufficient level of protective measures across the solution?
- Does the solution comply with internal guidelines?
- Solution Platform
- Does the solution enable agile implementation and configuration effort?
- Can the solution be managed largely through the business owners?
- Is the solution pipeline aligned with the solution life cycle plans internally?
- Does the vendor of the solution meet internal vendor requirements?
The actual execution of the proof of concept depends highly on the specific use case you are looking to cover, however the following plan gives you an idea of timeframes, focus points and sequence.
Start your own Proof of Concept
Our team is happy to assist you in shaping your own proof of concept and learning more about the value you can generate with Alyne. Contact us at firstname.lastname@example.org or reach out to our sales team.
Image credit: flickr / thelostlollypop