Is the current context in energy trading changing your ETRM Strategy?

00:00

Gary Vasey Okay, so welcome everybody to Commodities People’s webinar: Is the Current Context in Energy Trading Changing Your ETRM Strategy?

And, we have a really good panel to talk about that this afternoon. But, before we get started, I'd just like to remind you that if you want to ask questions to the panel, please do use the facilities here on Zoom to do so. I will try my best to pick up on those questions and direct them accordingly.

Let's do some introductions to get started. My name is Gary Vasey. I'm the Managing Partner here in Europe with ComTech Advisory, and we also run CTRM Center. And, I'd like to ask the three gentlemen with me to do a short intro, starting with Alex. We’ll go alphabetical.

00:47

Alex Whittaker Afternoon, everyone. Alex Whittaker. I’m the General Manager at Bonroy Petchem,   startup and small trading house. I've run all of our post-trade, all of our technology, CTRM. And, before joining Bonroy, I was working in CTRM consulting for the previous 10 years.

01:05

Gary Vasey Sameer.

01:06

Sameer Soleja Hi, I'm Sameer Soleja, the Founder of Molecule, one of the largest cloud-native ETRM vendors in the world. We're excited to be here.

01:18

Gary Vasey Soren.

01:20

Soren Eriksen Hi, I'm Soren Eriksen. I'm Head of Partnering and Governance within Mabanaft, previously head of commercial capability. Basically, in touch with our ETRM strategy and the directions for the last 10 years.

01:31

Gary Vasey Great. Well so, to get started, obviously, things are changing and shifting very rapidly, almost on a daily basis. I think I've referred to the perfect storm – just about everything that can be happening seems to be happening in the commodities world. And of course, that must have a significant impact on CTRM/ETRM software and strategies.

I'd like to start out by asking, perhaps, Alex. What are the key things happening to your business right now that are impacting your ETRM software functionality?

02:06

Alex Whittaker Yeah, so obviously, we're in a period of very high volatility and changing markets, particularly in gas. So, there's a lot more focus on risk. I mean, even today, there's been a lot of questions I've been involved in with budgets for VaR and margin and things like that. Like, the board are putting a lot of pressure on those to understand those figures. And, I think that sums it up quite neatly in terms of risk capital.

You know, being able to understand your exposures quickly and accurately. So, for me, there's a lot of pressure on the CTRM to be working in the way it's designed. The way it should. You know, it's not acceptable anymore that we would just go a whole day without a position or a P&L report, for example. We need all of those things quickly and accurately.

Some of the newer things are a bit more pressure on understanding margins. Obviously, that's something that CTRMs… you know, they don't do that, at the moment. There are one or two vendors out there who are looking into margin risk and, say, margin-as-a-service. And, that's something as well, again, there's pressure on risk capital.

03:12

Gary Vasey Yeah, there's definitely some new requirements emerging.

Soren, what are you seeing? Anything on the ESG side, as well, specifically, perhaps?

03:21

Soren Eriksen Yeah, absolutely. Absolutely.

I mean, Mabanaft’s historic footprint, right? It's very much in the middle distillate oil product space, right? And, with a whole world aiming for decarbonization, emissions reductions, a whole concept of biofuels of emissions trading becomes significantly more important, right?

And, where 10 years ago, you were able to make a good margin by having better offset, better import price than others. Today, it's not just the lending price in ARA that is determining your margin. It's very much how you are able to manage your emissions; how you're able to do your blending; how you supply your biotopics. So, especially in markets which aren't quite as volatile and quite as liquid as other markets are.

04:18

Gary Vasey Sameer, as a vendor, what sort of pressure are you getting from your users around meeting functional requirements that are emerging under these current market conditions?

04:31

Sameer Soleja Yeah, that's a great question, Gary.

I think, you know, starting out, we figured near real-time position, P&L would be an important thing for folks, as Alex mentioned. But, that's just sort of table stakes for us. And, for anybody we talked to, it seems sort of table stakes.

What we see people asking for are certainly enterprises wanting access to raw data that they can combine with data from other systems, and for example, a data lake. And, also sort of to what Soren mentioned, everything and anything renewables related. Managing offsets, managing regulatory requirements around those offsets and/or credits. And, you know, keeping that madness straight is something that people are really looking for their ETRMs to handle.

05:21

Soren Eriksen Yeah, I think you've raised some very, very interesting points. And sorry, for jumping in, right.

It's not just the markets that are changing. It's – and then Alex was also pointing in that direction – technology is accelerating over the last 5, 6, 7, 8 years. It's tremendously… So, I'm always telling people who have a different view on IT, “how excited is it to be in IT?” Because, things that were theory 10 years ago are now everyday reality. Right? And, that clearly has an impact on ETRM/CTRM strategies and what you do and how you do it.

05:57

Gary Vasey Yeah, which is interesting because I see a lot of potential for automation. So, I'll go straight back to Sameer. Are you seeing a lot of interest in automating things? And if so, what are the steps that people need to consider in order to truly automate some activities?

06:16

Sameer Soleja Yeah, I think that's a great question, Gary.

Automation, at least from what we hear in the market, is another thing that seems to be table stakes for a modern piece of software. So, we built something like 30 integrations to other systems that are sort of out-of-the-box. And every day, we're being asked for more, and it's a totally reasonable thing to say in 2022. To say, “Look, I bought this large piece of software. It should integrate to other systems, and therefore, automate the ingestion of data and export of data to all those systems."

So yeah, I mean, from what we hear is integration to everything is important. And, the steps taken to do it sort of vary by vendor of the system that you have. For some companies, it's, “Okay, well please flip the switch for us.” But, for others, it's, “Well, let me stand up a whole project around it and make sure to validate the integration and, you know, test it and get it out the door.” So, it just really… I think the steps depend on the vendor that you have.

07:31

Gary Vasey Alex, Soren, what about you? Are you seeing any… Does automation have value for you? And if so, where? And, what are the prerequisites?

07:39

Alex Whittaker I think there's definitely value in automation. It's a tiki bar of having an open-mind about technology and what is possible. But, it's also very difficult. And, you have to accept the fact that a lot of the problems you have are to do with sets of choices that have been made over a long period of time or to do with difficult people in their roles seeing it their own individual way. So, I mean, the main prerequisite is to make sure that your administrative processes are automatable. Basically, I mean, you know, it's all very well. Going, “Oh, yeah, automation, brilliant technology. Brilliant.”

But, often what would happen is, if you found yourself getting sold down that road, and you sort of like deep into that, you'll find that your processes aren't good enough to automate. You won't get any benefits. So, this is where you have to be quiet. It can take a lot of time. And, it involves a lot of sort of investment in people and your internal processes. And then, when they're good enough, then of course, you can automate them. And again, you know, a technology project can be something that gives you the goal that we need to work on our processes to achieve the technology gains we know are available. But, we aren't in the right place for that, at the moment.

At Bonroy, I spent a lot of time recently working with our finance team or settlement team just to try and get them to understand that, you know, we need to set our processes and, like, have them in line with our CTRM. And then, we can start to consider what games may be available. And then, generally, I'd find that even though I find this person with like 20 years experience, next CFO, all of these things. And then, all they want to do is set up exactly like the last system they use, and it's a different CTRM.

So, I mean, you get intelligent people saying stupid things constantly. And, you have to work with them to be able to move that through to really understand in depth. You know, what we're trying to do and how that works. And, I mean, it amazes me how difficult that is and how narrow-minded people are now. Set in their ways they are. But, if you want to, technology benefits. That's what you have to do. You have to go right into those details. And, you have to work with them and it takes time. So, the best thing you can do is invest in time and people.

09:48

Sameer Soleja Just to add on to what Alex mentioned to that last point.

When we have worked with customers in the industry on automating something that is, sort of, nonstandard, one of the challenges that we run into is the separation of the what and why versus the how. And, sort of, as software people were really good at figuring out the how, but a lot of times we'll get dictated “the how” by a customer out in the field, which makes the whole process go a lot more slowly and a lot more deliberately and ends up with a bespoke solution for somebody as opposed to a generic solution for the industry. And so, that's definitely been a challenge for us.

10:32

Soren Eriksen And, I can’t imagine. I think one of the key points here is, what are you seeing your ETRM project like? Like, right is, is it an IT project, right? Is it a front-office project?

And, I personally always see projects like this full blown business transformation projects, right? Because, let's face it, that's what it is. We invest a lot of money in ETRM solutions, and ETRM solutions oftentimes come with pre-configured, pre-designed processes, right? And now, you have two ways you can tackle that, right?

On the one hand, you can do it as a transformation. You get a solution that has a built-in flow, which is proven to work, and it's gonna deliver the outcomes. And, you can check how that actually would work for your business. Or, you say, “Hey, let's start and customize and make the system do it our way.” And, I think the biggest risk in starting to customize early on and that also starts with doing climate entry on a white paper, white sheet of paper basically. Right? Is that you start to abuse the good functionalities in the systems. Not even the vendors – and, Sameer, please correct me if I get it wrong – always know exactly 100% where it breaks if you change stuff, right? And, it's crazy.

So, if you see these types of activities as transformation projects, and you start by looking at a system, what can the system do? How does the process look? And then, kind of do it was an MVP approach. Look at it, this is how the system would work. This is how the flow would work, then you have a lot of potential a) on the business side. But, as a result of that coming back – Gary, to your original question – that is where the automation comes in, right?

Because that is where you have the systems doing, what they are designed to do, doing, how they are built to do it. And then you can look at, “Hey, can I make that even more efficient by automating specific steps around that?” But, it is always about seeing it as a transformation, looking transparently at processes at people at data technology, also in that sequence. And then, you basically go from there when you automate.

12:48

Sameer Soleja Well, and just to add to Soren’s point there. as well. You know, automating versus adapting to an internal company's custom process. One of the neat things about automation today is that it’s not usually that hard if you're doing it between modern systems. But, a lot of times what we'll hear is, “We want automation, but we want to be able to modify the steps in the process, as well.”

So, it's automation combined with human intervention which is important for some folks but also can make the process a lot more difficult and a lot more expensive and risky to do.

13:28

Soren Eriksen And, isn't that contradicting? Parts of the automation processes? Because, my understanding is always that automation should help you move toward managed by exemption. Right? So, you focus on the stuff that's not standard, and the good automated process should drop those out. And, instead of manually doing 100 things, you only do five because those are the ones that didn't flow through. Right?

13:48

Gary Vasey Yeah, there was once a time when I was an executive in a big trading firm, and I had to sign all the confirmation statements. And, there were so many of them. I could never actually examine them. I just had to sign them. And, I'd spend hours signing these things. And, if someone could just have automated that for me and just pulled out the exceptions that I needed to look at… that would have made my job, not just more optimal, but I would have rested more easily at night knowing where the trouble might lie ahead.

In terms of the landscape out there, it's still fairly… It's a legacy landscape. It's older solutions, generally, particularly in places like North America – just doing our vendor perception study. And, it's quite clearly an older type environment in North America, not so much in Europe.

What kind of problems do you have with older solutions that have nicely worn in and been in place for several years? And, hopefully they're working for you, but they don't have all the bells and whistles, perhaps. And, they're not necessarily readily adaptable. Or – excuse me — the vendor can’t speedily bring things to the table. How do you work with that, Alex?

15:06

Alex Whittaker Well, yeah. It's an interesting problem at the moment.

I was having lunch with a vendor CEO yesterday and saying that, up against legacy systems, people will be interested in looking at alternative systems. They're generally not very happy with their legacy system. But, they're also… They're sort of afraid, or they find it very difficult to leave. It is so deeply embedded in the company that that's very difficult. And, I think given how bad a lot of implementations have been in the past, as well, in that if you go back to a legacy system, and you look at what was promised whenever it was done: how much it cost, how long it took… versus what it's delivered.

I think most people are probably actually quite frightened about doing that again. Because, you know, their experience of, say, an implementation of a CTRM vendor and project is so bad. They don’t want to take that on again.The risk becomes very high, certainly the perceived risk because of what they've experienced before.

So, in terms of how people get around that, I mean, I think some of the best projects I've heard of and seen myself have been hybrid projects where people really are willing to work alongside a vendor for a considerable amount of time. And, put that investment, not just in money, but in terms of developing that system and training their people, investing in their people.

And, it's really about, say, maybe working for 4 or 5 years with a small team rather than this idea that you can do a 30-person team and do it in 12 months. I mean, I would say that's completely discredited, that approach. I think it needs to be a longer, slower approach. And like, we were talking about with automation that you need to go back to your basics and look at what you were doing as your administrative choices yourselves. And then, working with a vendor alongside for a considerable amount of time.

That would be, I think, how you would be able to go away from an unhappy legacy system and develop something better. But, I think the amount of time it takes is going to be a lot longer than people were used to in the past. But, I think, if that's… I think that's the way to be successful.

17:08

Soren Eriksen Yeah, I think that there's some very, very interesting items in it. And for me, it comes back to also the question: what do I want my ETRM to do? Right. And, if I look at the ETRM that we operate, right. And, looking at Mabanaft specifically because I think we have a super strong physical logistics footprint in the organization, right. So, if I look at an ETRM, and I say, “Okay, what is my top priority?” It's the ETRM should be able to handle my lifecycle, right? And, that means from trade entry, all the way to creating a settlement. And then, basically it’s giving me the data on my exposure throughout the process of the lifecycle.

And it's… I think a lot of the issues that you see in the organization is not necessarily the HR system or the scale of the system. But, it's a way that the systems were introduced and implemented. Right? So, if you have over many, many years… I mean, that's the heritage of the ETRM systems, right? It’s customized by a big solution, by a monolith, and then customize the monolith as much as you can.

And, I think that clearly creates massive issues. And today, that is not how you would do it. So, even if you decide on following what I just outlined – if you select a system that quite nicely covers your trade lifecycle of the core businesses that you do, you need to stick to the system. You need to stick to the standards, right? You need to stay in line with that. And then, look at the whole ecosystem today. Because it's not just anymore, the core ETRM. Do what you do. You always need to talk about integration layers. You need to talk about data layers. You need to talk about the whole concept.

How do I get data in and out of that application? At what point in time was what frequency? What do I need? And then be very, very clear on what you're going to get where. Because, clearly, what you will not very likely get today is this one system that has everything. Because the trend toward today is more of an ETRM you do trade entry here, but you do reporting – let's say in Power BI or Tableau or whatever it is – oh and by the way, do your traders… Oh, do you use trayport for capturing certain deals and so on.

So, it's not a new concept, but it's getting I would say more popular in the industry also related to the technologies focused on what the stuff does. What solutions do well. And then, stick with that. And that can also mean – Alex, what you were referring to – co-developing an application together with a vendor that makes it hopefully then fit your needs but also basically an absolute of vendor forward.

19:53

Gary Vasey And so, Sameer, how do you respond to what those two gentlemen just said as a vendor? What lessons have you learned in terms of providing a platform that's agile and adaptable to business change?

20:08

Sameer Soleja Yeah, I mean, I think I agree with pretty much everything Alex and Soren just said.

You know, if I think back on our implementations and which ones went well versus the ones that may not… that may have taken longer were more difficult. The more difficult ones were the ones where there was a significant amount of feature set that the customer wanted that wasn't in the core platform. And, you know, it needed to be done in order to fulfill their particular business processes.

And, you know, the challenge around that is, as a vendor, you come up with what you believe is an abstract, standardized solution for this customer who's helping lead you down the path of building some feature set for them. It often doesn't agree with what the customer wants because now the customer is in the driver's seat of defining this abstract business process. And then, you wind up building sort of a customized stub which could end up being an orphan piece of software or something like that, rather than having, you know, a broadly applicable area of functionality in the trunk of the application that evolves over time.

So, I think, yeah, I think the customizations area – other than, you know, small integrations or reports or things like that – installs where we've had a large number of customizations and a large amount of feature development certainly are the ones that have taken longer.

21:42

Gary Vasey We have a question here that kind of fits this topic of standardization and automation. So, I'll just read it and see if we can get any answers from the panel.

What are your opinions around efforts at protocols, standardization efforts, such as FIX, FpML, CpML, and ISDA CDM. Anybody want to take that one on board?

22:04

Sameer Soleja I can take a crack at it, certainly with relationship to FIX.

You know, it's nice that that standard is out there. But, for anybody who's actually digested FIX before, it's a very, very difficult disaster. And there's, you know, 83 different versions of it. So, you know, from our perspective, FIX solves some guaranteed delivery problems but doesn't really solve message standardization problems because everybody sort of has their own version of it.

We haven't run into the others. But, the places where we've had an easier and easier time integrating with others is where people are using more broadly applicable – say, Silicon Valley type standards, like restful APIs, JSON interfaces, etc. That said, you know, definitely welcome a set of standards coming up because it would make everybody's life easier.

23:05

Gary Vasey Yeah, I don't want to go off on too much of a tangent. But, it does seem to me – I've been in the industry almost 40 years – that those standardization attempts never really are that successful. And, in order to automate a lot of stuff, we need to standardize stuff.

Any thoughts on that from anybody here? How we can better… is the more impetus to standardize now because of the market conditions, for example.

23:28

Alex Whittaker I think you can see, I mean just in general, the standardization – say that fact and Covantis and what they’re doing. That’s about processes, rather than, say, the technical side. But, I think when you look at what's happened there, and how they're trying to say use things like blockchain and modern technology, it looks to me like what the real heart of that is about standardization. And everybody, you know, just fundamentally doing the same thing, shifting commodities around. You know, we don't all need to have special, unique processes to do it.

If we all do the same paperwork the same way, then, then you can do it and that standardization seems like it's been quite successful. They're making progress on those products. And I think, again, that's actually quite a good sort of proof of concept and a way of showing people what a good way of doing a technology project is, which is basically a lot of investment and a lot of time.

24:19

Gary Vasey Anybody else?

24:22

Soren Eriksen Just totally share this view. I mean, we have seen over the last year, it's also with activities, like React or komgo with a lot of these blockchain initiatives. They are all pushing towards certain standards, right? Pushing certain activities out, making the homogenization effort across the board. And, I think that the direction is good.

I think the biggest risk that I still see is and just using an example I'd use PIDX, say, as an XML data standard, right? And then, there's a BP PIDX. And, there's the shell PIDX. And then, there’s 15 different versions of PIDX, right?. So, why do you still call them PIDX? If everyone has their own PIDX? Right?

It's… I think the industry needs to come together in certain ways to agree standards and then stick to them and sticking to them is probably what is what is the biggest challenge. But, it is also the thing that takes the most discipline from everyone engaged in the industry and everyone active in the industry to also stop diverting from the standards all the time.

25:31

Gary Vasey Yeah, that's that's been that's been my historical perspective is that like, givsby in North America. I remember that one very well. We ended up with a standard plus extensions. So, how can that be a standard? You know, if you want to automate, you need a standard. You can't have standard plus extensions. Yeah, absolutely.

I want to ask Alex and Soren, then. Given all of the things that are happening in the industry – we've talked about some of them, new risks, ESG, that kind of thing – how are your systems bearing up in terms of meeting the new demands upon them?

26:05

Alex Whittaker Our systems, we've got a bumble, have been working very well in all the volatility and this type of thing. I mean, it's not an issue. It's what they're designed for. I mean, like, if you didn't like volatility, you shouldn't be trading. So, in that respect, it’s a trading house. So, this has all been good for us.

We've worked very closely with our vendor over the last 18 months, just constantly, sort of, fixing small little problems about pricing and averages and things like that and just working very closely with them. And, always bringing it back to the same thing that we accept that if we want something done a certain way, and we move away from how the system is designed, then you know that that falls on us. And, you know, we have… we tried one or two things and then moved back towards it.

So, we just tried to keep thinking through what we're doing. Talking with the vendor. Listening to the vendor, and trying to stay close to how the system is designed, and then working with them in terms of the system design to get their input on the things that we want to change.

Now, overall, that's going very well. I mean, basically, all our reports are done by 7:30 every single morning with very few problems. We have all our risk reporting, risk limits, risk monitoring. Everything works to a very high standard. It's very accurate. It goes very well. But you know, that's taken 18 months of just, you know, sort of, dogged progress.

27:27

Gary Vasey Soren, anything to add?

27:29

Soren Eriksen Yeah, no. I think Mabanaft’s situation is slightly different with regard to that we are currently using an in-house built solution at two of our major locations. And, what we have actually done, is see solutions that are clearly super good in covering our trade lifecycle. So, we've always been very, very good at knowing our position in the system and being accurate about what is happening in the system, right?

And, what we've actually done to some degree is make sure that we have access to the data. And then, if we had rapid development needs, we cater for that on the outside of the system and our data and analytics environments. And, just to make sure that we're on top of the information that we have and that also worked fairly well. And for us, it showed, as long as you cover – as I was saying earlier, right – as long as you're clear on what you read, what you're supposed to do in our case covers a trade lifecycle as much as possible, as good as possible. And, if you then have access to the data, there's a lot of things you can do on the outside.

28:32

Gary Vasey And, Sameer, I guess, for you more of a… to what extent do you try as a vendor to anticipate the kind of what's going to drive fundamental changes in your functionality versus listening to the customers that you already have?

28:46

Sameer Soleja Yeah, it's definitely a difficult balance. Usually, what happens is after, you know, 5 or 6 different requests from different customers about features that may actually not sound the same, our product and our engineering team sit down and say, “Well, wait a second. Those are all various forms of trade status management. Why don't we make a, you know… why don't we focus on making the best trade status management feature we can, and then see if it can fit all of these use cases.”

So, we can try to make a standard, at least for our platform and share it with the customer base. It's easier said than done. 29:31

Gary Vasey Time's moving pretty quickly. So, I want to move on a little bit to we mentioned… I think Soren mentioned that we're moving towards a sort of new architectural idea for CTRM and have been for a long time, which is more of an ecosystem of bits and pieces really that work together.

To what extent do you think that this really solves the problem? Because, if you've been around as long as I have, it seems we go around in circular arguments about, you know, we build it ourselves. We customize. We buy. And, we need modular. No, we don't. And to some extent, even though the technology has shifted, and it seems different this time. To someone as old as myself, it sounds a bit familiar to something we've tried in the past and didn't really work.

30:22

Alex Whittaker Well, I think you have to identify the right problem. Really, the right problem is just making stupid decision after a stupid decision. If you make bad decisions, it doesn't matter what ecosystem you have or what technology you have. You've got HR. So really, what people should be looking at is what went wrong previously.

And, I think if they look at it, this thing about you buy an off the shelf product, and then you don't set your admin processes up to fit it, you know. You try to turn it into a bespoke product. Those bad choices that you then, sort of, compound and compound turn into project disasters. Now, if you can keep things simple, and sort of, in some ways, you know, like go for an unambitious project that really fits those very tight core needs.

So, you get your system up and running, doing the important things like position, P&L, VaR, these types of things. That's what you should be starting with. Now, at that point, where you're up and running. And, you've got 80% of your core needs going. Then, you can start to think about what other good decisions can I make to add to this?

But, I think the problem has been in the past, that everybody has this idea that I can do, you know… throw 10 million at it or more. Do it in 18, 24 months, all at the same time. It doesn't work. And, it's never worked. And, I think if you speak to people in the market, and you have sort of off the record conversations where people are willing to be honest. You’ll hear all about these disasters and things but it comes down to people making good decisions and learning from mistakes in the past. But, you can't learn if everyone's just covering it up with a lot of sales and marketing positivity.

31:56

Gary Vasey Absolutely. Absolutely. Well said.

Soren.

31:59

Soren Eriksen Yeah, totally share Alex’s view here. It's an iterative, step-by-step approach that you need to take, right? And, it's the same idea that if you think about an organizational transformation, right. When you want, we have two circles of centralization, decentralization, centralization, decentralization. In each of these steps that a company goes through, you learn, right, and you mature. And, you get to a new level, and then you – let's say you centralize to increase the maturity levels on your decentralized again. Get more flexibilities and decentralize again to improve your maturity level and so on. And, it's a never-ending circle.

And, it's going to be quite interesting to see what's happening, especially on the architecture side with ETRMs, right? Because, the trend at the moment really is modular, avoid customizations, and so on. But then again, monolithic architectures and monolithic systems did have a purpose, right? And, they do have a certain value and doesn't really matter if it's an ETRM or if it's an ERP, like SAP.

If you have a single system that has everything end to end, and you just at the end get the data out, it's a pretty neat and very convenient way to run. But the complexity of getting there is so significant.

So, it's going to be interesting to see how that actually evolves. So, in the next 10 years, I would say, yeah, and maybe we've all… the question would be the other way around, have we reached the peak yet? When it comes to modularization of solutions? Or, is it still awake?

33:31

Alex Whittaker I know at least one vendor who's changed the way that they do implementations, for example. They focus basically on like, doing a free month-implementation to get those core functions going. And, only then do they start, sort of, widening that out. And, sort of looking at what people might want in terms of Power BI and development, things like that. And, I think that's been going very well for them. They changed that about 18 months to 2 years ago.

And you know, and again, this thing about and then I think also, the way they run that is they push back on the client, and they make the client focused. And yes, they're quite happy to be, you know, a little bit bunchy with the client, rather than the client knows everything, and, we say yes to everything. Because that is the path to having tons of billables for a couple of years and delivering almost nothing. But, if you focus on this core product and getting the client working out and understanding that you're getting the client involved. And, your implementations go better, and I know people are doing.

34:23

Soren Eriksen Yeah, and I know this is overused, right? But, at the end of the day, this is agile implementations as agile project work, right? You set up an MVP, and that can be an off the shelf solution, right? Get it up. Get it running. Have good defined use cases. Put them through the system without touching it too much. And then, see what you really need to do. Right. And, I think that is the way to go for the time being and everything else. I have to admit, I wouldn't be willing to do it any other way. It's a moment.

34:57

Gary Vasey Right? So, let's ask Sameer because maybe you put your money where your mouth is, and you founded a new car and ETRM/CTRM entity, obviously, with a vision of doing it better.

So, what have you learned? And how can these? How can the industry apply some of the things that you've learned?

35:15

Sameer Soleja Yeah. One thing I've learned and that, sort of, addresses one of the questions that just got asked is, you know, financiers of solutions, like software-as-a-service solutions, for example, like to ask you to build an 80/20 solution. The problem in the ETRM industry or in the training industry is people don't buy the 80/20 solution. People buy something that looks like a 95% solution. And so, getting there for every use case is very, very difficult.

I mean, I think that… when I talk to people who are outside of our industry, about the complexity of the systems and the number of features they have, et cetera, I say basically, “Look, an ETRM system is kind of like an ERP for energy companies. It's got a similar order of magnitude in terms of features. And so, you know, building them all out takes time. Making sure they work for customers takes time. And, basically, building an ETRM system is a very, very difficult and long path to walk. It's expensive. The returns are slow. And, at some point, you hopefully reach critical mass and start to become a standard. But, that takes some real time.

36:41

Gary Vasey Yeah, back a couple of centuries ago when I was working with a vendor in North America, we used to say it was the sizzle not the steak that sold the solution. So, that kind of refers to your 80/20 being really 95/5%, because that 15% is the sizzle. And, that's what seems to be what the users tune into during the sales process rather than some of the things that Alex and Soren have mentioned about keeping it simple and sticking to your knitting and all that kind of thing.

So, perhaps we need, as an industry, to think through the procurement process and analyze what we're really doing during that procurement process and that we're not getting ourselves into trouble by taking a particular path.

We're coming up to the last few minutes. So, I do want to just take a quick look at some of the questions we've got here. Are the ETRM clients looking forward to SaaS models, managed services pay-per-use, that kind of thing?

So, I guess, Alex and Soren, what are your thoughts on software-as-a-service versus on-premise, traditional licensed, that kind of thing?

37:49

Alex Whittaker Yeah, I mean, we have a SaaS product that kind of goes very well. It can be frustrating, at times, in that… because I need people to be responding and fixing things within 15 to 20 minutes in the morning. And, if they can't do that, I'd rather be doing it myself. So, it really comes down to the vendor's service and what they're able to do and working with them on that. Because to be honest, the standard SLA, service-level agreement contract, saying four hours and eight hours, that's no good at all. I mean, that means I'm waiting all day. So, that's useless. If they're quite… if the vendor service is good, and you're able to work with them and get things done quickly, brilliant.

38:26

Gary Vasey Soren, any thoughts? Just shell competitive?

38:32

Soren Eriksen Yep. Just I share. It’s true. 

38:34

Gary Vasey So, an old buddy of mine, old friend, Roland just asked the question directed at you, Soren. So, that comment, I'm just going with the standard features and functionality initially and making changes when you have a better understanding of the capabilities is great.

But, what role does a proof of concept have these days? Because, I think this is an important step when evaluating software. I'd agree with this because that's part of that procurement process. Yeah. Why are people not doing more proof of concepts?

39:00

Soren Eriksen It's a very, very interesting question. And, we've just gone through a super lengthy selection process. And, we've asked ourselves very, very similar questions, right? So, how can you tackle these selection processes?

On the one hand, you need to have proper requirements documentation, right? And, you end up having hundreds and hundreds of functional and nonfunctional requirements… which in long spreadsheets which you've probably all seen, right? And, Sameer probably has sleepless nights over getting these spreadsheets, right? And, these have a role because you, kind of, need to tick boxes to make certain things. Sure.

But, for me, there's a second step in between. So, before you say, “Well, I think this is my preferred solution.” You do want to have – it's not always a proof of concept not necessarily – but you want to have properly defined business scenarios which you want the vendor to present until you always know that's going to be in… it's going to be as showcase, right? You have showcases. They're going to make a pretty and if they are good, they're going to make it look like everything works seamlessly and out of the box. You know, that's also not completely true.

So, I think it's a balance between having proper requirements, documentation, long list of requirements, – sorry, not getting out of that one – functional and nonfunctional, having super good scenario definitions. And then, having, also, an implementation approach that works along that road, right? That works along the footsteps of – if you call it, MVP, if you call it proof of concept, doesn't really matter. Try to get in early on in the project, get the prototype up and running, get something up and running, that is going to be your development system and see how the system behaves with the then even better defined business scenarios that you have.

And, even for the business scenario, 80/20, 90/10 – whatever you want to call it – makes this is winner a game. Because, a lot of your business scenarios are going to be the same. And, we as well move through with 100,000s of truckloads of truck movements a year, right and loadings a year. So, that alone, if a system is able to cover that flow alone, give us 60, 70% of our business activities. So, if the system was very, very good at that first box takes, and if the MVP is able to handle that quite nicely also on the implementation, that’s the first big win.

So, they do have a role. The questions went throughout the process. And, focusing on them, focusing on business scenarios clearly defined... this, I think, is what you need to do.

41:43

Alex Whittaker The best proof of concept I saw was… it was two weeks. And, they had tons of end users in front of the system using it and asking questions. So, you've got your business users. You've got the business knowledge, putting that to the vendors basically. It's best when I saw the fact that people don't do that. It's just again, it's symptomatic of the bad decisions that people make. I mean, they're happy to spend, say 10 million on a system. And they will want a two-day demo from the salesperson showing it to them. I mean, it's insane.

42:08

Gary Vasey And, Sameer, as a vendor, how do you feel about doing proof of concepts, especially if they're unpaid?

42:15

Sameer Soleja Unpaid is very difficult. But then, RFP processes are very difficult, as well, and rarely result in a good solution. I would not want to do unpaid proof of concepts. But, one thing that we do is we do extended paid proofs of concept. And, sometimes that can, you know, take some of the fear out of the conversation for the customer. You know. “Have I chosen that I choose the right one? Did they lie to me about features? Did they paper over some of the things that didn't quite work?”

I think a good vendor ought to be able to do a paid proof of concept for you know, a fair wage. And, I think it'd be… it's a great way to de-risk the problem.

42:59

Alex Whittaker The return on investment of paying the vendor to do the proof of concept it is enormous. The risk reward is fantastic.

43:07

Gary Vasey Yeah, well, we're coming up pretty close to time. So, I'm just looking at the questions we've got. I think we can have partially answered the first one, actually. And, in terms of the second, how does the vendor manage their 15 different client solutions in parallel?

Really quickly, Sameer. How do you do that?

43:23

Sameer Soleja Okay, so for managing those customizations. Essentially, what we do – which is maybe unusual – is that we have a core application with an API around it, and any customizations happen outside of the API. So, all we have to do is keep the core application moving forward and guarantee that the API stays the same or that the interfaces stay the same. And then, we can do as many customizations as we want outside of it, as long as they expect the same data, and we deliver the same data.

43:54

Gary Vasey Right. So, we're right on time. Time is up. So, thank you to all the panel. Thank you for those that listened and sent in questions. And yeah, thanks from me. And, that is the end of the show, folks.