Blog metals trading system implementation
- 1. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 1 of 7 Metals Trading System Implementation Introduction We recently implemented the Eka CTRM (commodities trade risk management) system. The accounting system that the client was using was SAP. The project was a rescue project for us. The client had already started the project and had run into difficulties. As such, it is a good case study to highlight the importance of project planning and the monitoring and clarifying the progress of the project during project management. The project ran for longer that the client had expected and so illustrates the importance of having realistic expectations and of the time and effort required to get a new system off he ground. Although this blog concentrates on the issues above with a view to learn from the experience, this is not a criticism. At all times, all staff remained commendably positive and professional and all the issues were worked through successfully. Staff levels and cost savings when having a system. The benefits of having a CTRM are the following. Transparency Methodical business process Scale-ability Meeting Financial Control Objectives We can give you information on what each of these means and how an ETRM delivers them separately, if you wish. Reducing costs is not on this list for a reason…although, if business volume increases, there will be cost savings.
- 2. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 2 of 7 We created two extra roles, in fact. A risk/ performance analyst An extra hand for putting in trades to the system. The risk analyst was a role required to run the reports, check them, manage any corrections required and present them to management. Especially important as the client was keen to ensure managers only saw profit reports for their area. A junior role was created in the ops department who would put in many of the required trades, working from the operators existing and various spreadsheets. There was no option in this system to upload trades. Cost Business Volume There is an initial cost with introducing a CTRM, but as business volume increases, costs increase slowly. With no CTRM, risk measured on spreadsheets etc, costs increase proportionally to business volume. Notice also, that with increased volume and no CTRM, transparency decreases, represented by the colour of the line. Cost increasing proportionately withscale Cost increasing slowlywith scale Witha CTRM Withouta CTRM Initial cost
- 3. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 3 of 7 Selection We were not involved in the CTRM selection process and we saw much evidence that, as we always say, it is worth getting consultants involved with this process. It is in the nature of people selling a system to emphasise what it does well and give it the best spin. Equally salespeople will not draw your attention to what will not work, or what can be done…but not very elegantly. It was clear that the client had been left with an over-inflated view of what the system would be like to use and what it could do. This does not mean that we think the client necessarily made the wrong decision on the system. The metals commodity training business is notorious for not having a single system satisfactory in every way. Selection is also about getting the right people to do the job. The client started the project by putting in a relatively junior member of staff in charge of delivery. His was a mistake and very unfair on the poor person. Without the experience and without a clear plan of delivery, he was never going to be able to mange to do this. The inevitable happened, and he crashed and burned. To make matters worse, when he was taken off the project, no one in the company was really sure what had been achieved to that point. Milestones that had been reported as being delivered, had in fact not been successful. This all made it more difficult for us, coming in at a later stage, to make a proper assessment of the amount of work required to rescue the project and get it to a point where the system was up and running. Definition Scope Selection Design Build Deliver All projects go through six stages as above. Design and build are the most expensive. Getting the first three right saves costs lateron.
- 4. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 4 of 7 Cut-over Cut-over is the process of putting the initial transaction data onto the new system. When you are cutting over from a replaced system, you have to make sure that all profits a reported in one system or the other and not both. For the CTRM on this project, since we were not replacing an existing daily reporting system, we did not have to make sure of this. Our cut-over rule was simple: All business where title was delivered to a customer after the cut-over date, 1 October in our case, was put into the Live system. That meant that all the purchases made in October onwards as well as the purchases for the stock that existed on 1 October would go into the system. All secondary costs from 1 November went into the system. This meant that although the system had live data for October, profit reports would not be meaningful until November. It also meant that the ops, because ops entered the trades, were putting in a lot of extra data in…simultaneously into Eka, as part of ‘lift off’, and into their spreadsheets, as part of their ongoing work. The extra resource that we had in the Ops team to do this was, therefore, invaluable. Paper Trading Eka handles paper trading pretty well. We worked together with Eka to build the reports for the paper traders in the way that they needed them. The have a good process for transferring the unrealised profit to realised profit once the derivatives are no longer traded. In fact, you cannot do an EOD until this is done. The process is pretty easy and we got the accounts team doing this with 15 minutes training. Reporting Some CTRMs have what they call real time reporting. This is often not real time in the sense that the M2Ms are being calculated from the real time values on the market screen, but that the profit on trades can be interrogated on the system screen. They do not require that an end of day (EOD) process has been run. Eka cannot report in this way. It requires the EOD process to be run first, and then PnL reports can be accessed which shows the profit on any of the days that EOD has been run. This can be frustrating during the implementation period as you can’t run EOD unless quite a lot of information has been put in and all the required details on trades entered are complete. So, we were well into the process before we could run reports. The error in deal entry only then became apparent and resulted in us rolling back EODs, correctly trades and then rolling forward again. I think that this is something to be aware of in the future in order to deal with the client’s expectations.
- 5. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 5 of 7 When we did manage to start running PnL reports, we found that there were arithmetic errors in the reports. The explanation for this was that the repors didn’t work well for metals trading as they had not been used before, Eka not having many metal clients. The reports have now been fixed and it should be no problem, or less of a problem, in future metal implementations of Eka. A benefit of the way Eka reports PnL is that ordinary employees using the system can’t see the profits made. This fits in well with the client’s culture where the profit numbers are regarded as being private. Eka has plenty of queries to use – by which I mean that you can run lists in the system. The operators use these as operational reports to process business. One shortcoming of Eka is that they cannot tie in the derivative trades with the physical liftings that they are hedging – the ‘strategy’ label is held at the (‘term’) trade level not the lifting level. This makes some of the reporting that we would like to do for our client impossible. Eka are looking at doing some development work in this area. Interface The scope of the project only included interfacing the invoices, product and secondary cost, from Eka to SAP, and the new counterparty details. We consider his to be the minimum piece of work and the one that offers the most benefit. The system was capable of producing stock and accrual reports, and full paper profit reports (realised profit, commission and open equity) that were sufficient information for the accounts team to calculate and generate month end journals. Eka can be configured to generate these journals too. A project to do that configuration and implementation is something that can be done as a later phase. The interface function in Eka is well developed. It has a fully functioning process that manages the posting of journals that ensures that they are not posted twice, they are reversed before being cancelled etc. They also, helpfully, allow this process to be overridden during the implementation of the system. They have a tool that allows users to define the account codes that invoices will be posted to. It also manages the passing of the XML generated to the receiving system, and handling error messages.
- 6. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 6 of 7 This meant that it was straightforward, although time consuming, for a user to set up the accounting rules without having technical knowledge of script writing, for instance. One thing that was missing was the functionality of dealing with VAT from more than one country. We got Eka to fix this behind the scenes using special script. The journal is generated in an XML form and sent as a message to the receiving system. If the receiving system sends back a message to say that the journal has succeeded, then Eka makes sure that the journal cannot be sent again. Otherwise it indicates that there is an error which must be investigated. The system is not run in the background, it needs a human to kick it off, but it works pretty well, doesn’t take a lot of time to operate and is generally satisfactory for small or medium businesses. Handling the interface from the SAP side proved to take more effort to set up. The model that we built was to have SAP run as a simple ledger. Daily reporting, including inventory reporting, will be done on Eka. SAP would be required to produce monthly accounts only. There was no need to post stock entries to SAP, for instance. Instead the monthly closing entries would ensure that the inventory in SAP agreed to Eka. When the XML was received by SAP, it ran a script on the XML to generate a journal in that system. As this was handled by a separate contractor, we couldn’t say why it took as long as it did to set up in the correct way. The accounts team were not confident to switch on the interface before copying the live SAP database and having Eka post to the copy for a month in a genuine parallel run. In the end it took 10 weeks from starting to work on the interface before it was switched on. EKA New Counterparty details SAP Reference data New trades Ops data Trade finance data Daily journals (i) invoices Monthly journals (i) paper closed in month (ii) brokers fees (iii) accruals for paper trades (iv) accruals for trades and costs not invoiced (v) missing trades (vi) stock adjustments Reference data (i) New customers (ii) other reference data Interim report Trade finance reports Daily profit reports Daily Exposure & VAR reports Monthly accounts/ Annual accounts Sundry accounting reports Sundry volumetric reports Credit reports Bank movement details
- 7. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 7 of 7 Project Management We managed the project using modern project software, Monday.com. This was web based which meant that stakeholders in different locations could all access the same data on the project. Each project task was held on a ‘pulse’, which is a line on the main table. But each pulse was capable of holding all of the communications about that task in a social media type format (similar to Facebook) that felt very familiar to everyone using it. Monday.com allows you to build custom tables, with each project task represented bya line or ‘pulse’. Attached to each pulse is all of the correspondence,files, documents that were relevant to tackling the task. Once the system was up and running, we withdrew from the project. There were still just a few outstanding tasks on the project that the client could work with Eka to complete. This saves the client money on our fees. Using Monday.com meant that when we, as implementors and project manages, withdrew from the project, we could leave the client with this tool to monitor and follow up on those remaining tasks.
- 8. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125 b5e03f18f5d8blog-metalstradingsystemimplementation- 190703210215.docx Page 8 of 8 Things to learn from this project. Even on a project in a small company, it is worth formally going through all the stages of a project, eg Definition, Scope and Selection, and making sure that they are complete. And in the case of selection, it is well worth getting a consultant, like ourselves, involved so as to be sure to understand what a vendor can really deliver, and what is just sales talk. It should be recognised that running costs will be higher with a CTRM. The extra junior resource that we had in the ops team really helped. It would have also been helpful to have recruited the risk analyst earlier so that they could have helped in setting up the project and, for instance, entered pricing data and ran EOD procedures for us during the implementation instead of us having to do this ourselves. Leaving a project to internal staff and expecting them to deliver a system in addition to their existing tasks is a recipe for disaster. It increases the risk that the project will fail; and it increase the risk that those people will make errors in their existing work. The cost in the goodwill of other members of staff who will also be asked to help in a project that doesn’t get off the ground, also hurts the company. Having project management software that you can leave with the client is really helpful in making a good, professional handover to them at the point when it is more cost effective for the client to take the project back in house. If you are taking over a project that has already been started in house, don’t assume that what the client tells you has already been achieved, really has been achieved. Conclusion of project The project was a success and the client has a system that is running, is interfacing to their accounting system and is reporting profit to them every day. There are certainly areas where the system and process can be improved. This is always the case, and we would be happy to go back to the client to help with this if they think this would be helpful. In the meantime, they will bed in the process, get used to it and get value from it.