CTRM IMPLEMENTION
buying once and selling twice. His company, DC Systems, developed GasMaster and was acquired by Caminus in 1999. The product was rebranded and sold as ZaiNet Physical for a time. He then formed Trinity Apex Solutions and reacquired the rights to the code base for subsequent development. Now calling the product TIES, Dick sold Trinity Apex to SolArc in 2006. TIES was rebranded as SolArc Natural Gas. Dick notes a common dynamic. Flexibility and customer focus make the small firm successful and attractive to the acquirer. A slew of large, brand name
companies have tried and failed to enter the space for lack of these same skills. The best resources are deployed on the front lines. Highly skilled people are on the help desk and on QA. Development is done using rapid application development. Culturally, the team is tight, everyone has skin in the game, where disagreement and debate are encouraged.
are focused on building and managing the business. Long term considerations matter. The weak are looking to cash out. It’s hard to take the time to understand the nuances of products with one eye on the exit. This intent must be inferred from management’s actions. Asking is pointless. In 13 years in the CTRM business, I can recall only one instance
where an acquired product was fully integrated into the flagship product. ‘Fully integrated’ means all functionality is migrated into the flagship product and the shell of the old product is discarded. If you hear the word ‘interface’, it is not fully integrated. The CTRM buyer might try to negotiate discounts upon a
change of control. The clause might stipulate a discount on maintenance or on the purchase of source code.
Incompatible New Version A second way CTRM buyers are pushed back into the market
“I can recall only one instance where an acquired product was fully integrated into the flagship product”
These advantages can be lost in
the culture of the acquirer, where waterfall development is preferred, kids work on the help desk, dissent is not tolerated and senior resources tend to leave. As a result, customers can grow dissatisfied with the acquirer’s responsiveness. Changes aren’t turned around quickly and the vendor doesn’t seem to know as much about their business. So they begin to look around for another product offering, perhaps from a smaller start up, and the cycle repeats. Does the acquirer’s product
portfolio look like a grab bag of incompatible solutions? That’s another red flag. If the acquirer is looking to gobble up market share in hopes of selling out, how much attention will be dedicated to your system? Dick notes management’s intention as a key differentiator between strong and weak firms. The strong never intend to sell. They
66 September 2011
is when the vendor introduces a new version or product which is incompatible with the prior version or product. So you can’t upgrade: you have to re-implement. Implementations are hugely expensive undertakings. Forced back to square one, many buyers decide to take one more step back and start the whole selection process over from scratch. Vendors don’t relinquish the powerful advantages of incumbency without giving the matter some thought. I know of two such cases. In one, there wasn’t enough thought. The new product was sold to a dozen or so clients before the company changed course. The CEO is gone. In the other, the change was driven by engineering considerations. A more modern architecture was required to support multi-commodities, and 95% of customers came along. The company provided migration tools and ran parallel systems for 8 years. With a 29% compound growth rate over the past 6 years, they
would seem to have made the right call. To mitigate this risk, the CTRM buyer might push for the ability
to upgrade to any follow on product or version, or for continued support of the existing product for 5 years after any new product introduction.
Too Far Behind A third way CTRM buyers are cut adrift is by falling too far behind the current version. In much the same way that vendors don’t want to have to support overlapping products, they also don’t want to support multiple versions of any one product. There may be contractual language that requires the CTRM buyer to stay within 3 versions of the current release. If they fail to upgrade, they are ultimately on their own. Upgrading is a complex, expensive process and it only gets
worse the longer it is delayed. Pietro Diont, a director at Contrix who has done two implementations and one upgrade of an industry leading CTRM system comments, “The flip side of a highly customizable system is lots of configuration. The system is delivered as a ‘shell’ without pre-configured modules. It’s almost like a development environment. This makes for a messy upgrade process with lots of moving parts. In addition to the application, changes may be required to the hardware, middleware, communication channels, scripts and the database. The process is just too complicated”.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92 |
Page 93 |
Page 94 |
Page 95 |
Page 96