How to Choose Your CTRM and Vendor
Once a company has decided that a CTRM solution may be required or, they think it is necessary to change CTRM providers, a software selection process will begin. Usually, as a part of this process, the CTRM vendors will be asked to demonstrate their software several times. It’s important to get the best from the time spent in software demonstrations and Amphora has many suggestions that might help you in that endeavour based on over 25-years of experience with selling and delivering its software solution.
Usually, the sale process occurs as follows:
Once the organisation has assembled a list of CTRM vendors that they want to participate in the search, they should make initial contact stating they are looking for a CTRM solution. Contact details can usually be found on the vendors’ website. At this stage an email is usually sufficient, in our case that email is email@example.com and your email should include a brief introduction to your needs including a list of the commodity groups to be covered by the software, e.g. crude oil and refined products.
After the vendor has received this initial email, a call will be organised, to determine if their solution could be a good fit for the buyer’s needs.
Typically, the vendor will drive this meeting, asking questions such as…
- What are you currently using to manage your trading risk, operations, and accounting?
- Why do you think you need a CTRM?
- How long have you been looking for a CTRM solution?
- How many users will require access to the CTRM?
- Where are these users based?
- What commodity is your primary focus?
- Have you agreed internally a budget for the CTRM solution?
The meeting will likely conclude with the vendor stating whether or not they think that their CTRM could be suitable for the buyer, and if it is not a fit, they will explain why this is not the case. If it appears to be a fit, then it is likely that the next step is an initial demo of the software.
The vendor will take full control of this initial demo, which usually occurs a couple of days after the initial call. The aim will be to provide the client with a broad overview of the solution at this stage that will include the look and feel (usability) of the software and overview of the main applications within their CTRM (core functionality), taking no more than 45 minutes. This initial walk though should cover the entire trade or commodity lifecycle so that users can be confident about the support for the trade/commodity lifecycle within the solution, using the main commodity the client trades…
🔷 Trade entry
- physical, pricing from a market quote with a premium
- swap, hedging the above price exposure
- additional cost
- B2B purchase against a sales trade
🔷 Risk Management
- Position reporting
- Profit & Loss / Mark-to-Market reporting
🔷 Out-of-the-box reporting
Again, the idea of the initial demo is to give an overview of the solution and to insure that, in general, it meets the non-specific objectives of the users.
Good meeting discipline is essential to be sure to get through the demo from start to finish and any specific questions should be recorded and addressed later.
Unfortunately, if the demo becomes an undisciplined meeting that drifts from the objectives, then neither the prospective buyer nor the vendor will be satisfied with it as the demo was not properly completed and the questions not properly answered. The best place for any specific questions is in the next step.
After the demo has concluded, the vendor will send documents to highlight any points covered in the demo, e.g., implementation process, training, current clients, etc.
The client will then be in control, deciding if they wish to proceed to the next stage. If they do, often an NDA is signed, before proceeding.
Demo Client Real Scenarios
The focal point for the client will be to reach out to their various teams to provide real trading scenarios that they currently encounter. The idea is to test the user’s real-world business needs in the system. Usually, this will consist of approximately 6-12 test cases. The vendor will request trades, operational activities, reference data and market prices to be used to validate P&L calculations for each scenario.
This in-depth demo can take the vendor’s business analysts 1-2 weeks to prepare and often during this period the vendor will have questions about the information provided. It is therefore required that the client’s focal point person is available to assist on any queries the vendor may have during this time.
Demo Client Real
The demo itself is usually completed within 2-4 hours. Afterwards, the vendor will often send screenshots of each scenario with P&L explanations.
Stage 4 can be repeated, if required, if during this demo additional scenarios are discussed and need to be modelled. Sometimes, users may attempt to score the demonstrated functionality against a list of needs as an aid in deciding which next step to take.
Sometimes, but not always, a brief trial period can occur with the client’s users, who will be guided through the core applications, using their own reference data and trades. Each user will have their own access to the CTRM to enter reference data, trades, schedule, create invoices, enter prices, create commodities, etc. The vendor will provide business analyst to assist in guiding the users for each action they want to perform. The trial can provide hands on experience with the solution; however, it needs active support from the vendor in order to ensure that the system is set up and used appropriately.
If the client wants to proceed, the next stage is to discuss the commercial terms. The vendor should now have a good understanding of the requirements to determine the cost and time frame of the implementation and if a cloud based or on-premises solution is required.
Once commercial terms have been agreed, the vendor will send the client contracts for signature. These should set out support & maintenance, professional services, and the modules to be covered.
As soon as the contract has been signed, the vendor will assign a team for the implementation project, often starting immediately, with reference data being collected. More of this can be found here.
Alternative CTRM Selection Methods
Instead of going through the above demo process, a client can create a Request for Quote, RFQ or similar. Commonly, this will consist of hundreds of questions about the functionality and technical architecture of the CTRM. A guide is often provided on the importance of each issue, commonly using the MoSCoW approach, (Must, Should, Could, Wont). The vendor responds with sometimes a simple yes/no to each of the questions*. Then a score is quickly obtained for each vendor based on this binary approach.
The downside of this approach is that although it is a quick way to assess multiple vendors, it does not consider user experience and quality of output. For example, if an RFQ was publish on baking a cake, a child would likely score the same as Gordon Ramsey, however, it could take a considerable amount of time longer, cost more and probably, wouldn’t taste as good. A better indication would be to watch the cake being made and then have a taste!
* Other methods can be a score, say, 0 to 4. 4 representing can be met out of the box with no config, 3 config needed, 2 local scripting required, 1 core code change, 0 cannot be met.
A CTRM selection process is a significant project for any client. The process highlighted above, provides a clear view of each step in the process with an indicative timeline for each event. At any stage the client can choose to stop the process without incurring additional costs.