Not a Packaged Software Market?

Since my days at TransEnergy Management in the late 1990’s, I have made an argument (and repeated it periodically) that the CTRM software market is not a traditional packaged software market. It is a message the ComTech has, of course, promoted as once you understand this, everything makes much more sense. Since new people are coming into our industry all of the time, it is good to periodically revisit this concept and its consequences. First of all, let’s revisit the meanings of packaged software and custom software.

For me anyway, packaged software is a commercial software offering that is available to meet a set of general and standard requirements for a reasonable price. Think word processing and MS Word, for example. The ability to offer the software at a reasonable price in part relies on the fact that there is a large market for that software so the provider can sell that standard software many times over. Custom software is a software developed specifically for a particular company, business, or set of processes that are uncommon, differentiated in some way, and so on. There is no ‘mass’ market for this software – it is essentially a one-off.

If we look at the types of businesses that have some need for software to support commodity transactions, it crosses many different industry segments from banks and funds to CPG and manufacturers. If you examine the business processes of each of these segments you notice that while there are many commonalities, there are also vast differences in required functionality both at a macro level and certainly at a more granular level. If you look with any segment – let’s say power utilities, for example – it is also immediately obvious that a power utility in Florida has different needs than a utility in California and those differences may become huge when moving geographically further away. Not only are there geographic differences but what type of generation asset is it that is being used? Each has different requirements as well. The size and scope of the utility can further complicate things. Back in the days of TransEnergy, we used to look at the industry as having two components – a merchant function and the management of physical assets function. There are vast differences in required functionality between these two objectives and each utility is a mixture of the two. So, what we are establishing here is that almost every potential CTRM software using company is actually different. Each has a different set of requirements dictated by location, assets employed, regulations, business processes employed, strategic differentiation, and so on. In other words, we can eliminate the idea that there is a mass market for CTRM software – at least once we get into a level of granularity. Each customer will share some needs with others but each will also have a number of processes that may be unique. Basically then, CTRM is a custom software market place.

Hang on though. There are over 100 vendors offering packaged software solutions? How so?

Let’s consider how vendors usually get started in CTRM historically (although there has been a shift in this in the last few years). Usually, they end up building a ‘custom’ solution for a customer but seeing that there are other companies that superficially anyway, look like that customer, they design in a bit of flexibility. They go to customers 2 and 3 and add in the functionality they need to satisfy them and make certain functions even more generic and ‘customizable’ to fit. By customers 7 and 8, they have really taken a lot of ‘fixed’ functionality and made it ‘customizable’ and they have added a lot of custom functionality for the different customers as well. You can see where this is going right? It’s a software package, it’s customizable and configurable but it is only a 70% fit to the broad requirements of any new prospect. In order to be able to offer the core package at a cost people can afford, it has to be customizable and configurable and it has to be a partial fit. In this way, we can make a custom software market into a packaged software market of sorts. And that is exactly what happened. Now over time, there has been a push to reduce costs and to standardize where possible so some of the complexity of these businesses has been eliminated yet, being a very creative industry, new ones have been added. The result is, we are no closer to the ‘all-singing, all-dancing’ solution of utopia.

In recent years, we have started to see some of this get resolved through advances in technology and architectures. Newer vendors will have been founded by people on their second or third go-around of building solutions in this market. They learned a lot and they apply this learning by limiting the scope of what they build or by building it in bite-sized junks of functionality and assembling an ecosystem of interacting services or modules and so on. This has brought us a bit closer to potential CTRM nirvana. But it is still essentially a custom software market and the same issues are met eventually.

But what does this mean?

Well, it explains why many vendors have lots of customers but none use exactly the same software – each has some custom coded content specific to them. It explains why there are not just 2-3 massive vendors dominating the space but are over 100 vendors with new ones emerging periodically. Recognition of this truism also helps those looking to select software as they can better know what traps and dead ends they might fall into with any particular approach. It also explains why the ComTech dislocation model is apt and works to explain the vendor and product landscape far better than some quadrangle model. In fact, approaching CTRM software with this understanding simply helps in every facet of decision making whether you are a buyer or a vendor, consultant, or an implementor.

For more information or explanation, do contact us.

 

Keep in touch and sign up to our Newsletter