TCO is a term slowly gaining acceptance in the process market. It has long been a term of endearment for many other industries- such as Risk Management, Banking/Finance, and others who have been very software- dependent. These were the industries who first gave us computing a la COBOL, and other historical giants. In fact, the first spreadsheets (anybody remember Visicalc, Lotus 123, etc.?) were designed for those industries.

Its not surprising therefore that the processing industry remains a step behind these other markets in acceptance of both technologies, and norms that seem everyday in those markets.

So, just what is TCO? Total Cost of Ownership is a measurement of the cradle-to-grave costs of owning a specific piece of software. It gives recognition to the fact that when you buy a specific piece of software, the price you pay is not your total cost of owning it. There are other factors to consider. As a result of this, the aforementioned industries generally have professional IT software guys who grill you about the underlying architecture of your product. They could care less about the features if the architecture is one that they know to be problematic. These days, most of them point to MS .NET ASP as the preferred platform, with thin-client web browser access to the components.  They've learned that no matter how attractive the features of a software may be, that if it takes a human pretzel to make it work, it just isn't worth the investment.

So, TCO should be top on your list when considering software, and many factors add up to influence it. What are some of those factors?

Ongoing license costs- Is this package all that you need? Are there additional licenses from this vendor, or other vendors that will be necessary to realize the desired benefit from this package? Some vendors try to cloud this picture by doing a very good job of listening to exactly what you think you expect, and giving you a price for only those pieces, failing to tell you that you will not resolve your problem until you expend further investment. Good software vendors listen closely to your problem, and help you to understand the additional software license costs involved and potentially other technologies invovled in handling that problem. We know of many clients who went with a competitor (who shall remain nameless) only to find out that the pieces they really needed were not included in what was delivered, because it was not specifically asked for.The old saying is be careful of what you ask for...

Ease of Use- What will be the learning curve associated with this package? Can I get in quickly and get many of the things I want, or will I need specific training? One good example of this is Microsoft Word. It does a lot of things I will never use, but for the most part, I can get into it, and type up a report, and print it out with very little help. One area to be very wary of in the technical arena is products that are built on Microsoft Excel. On the surface it seems like these would be the easiest to use. On the contrary, remember back to the first time somebody gave you their Microsoft Excel spreadsheet that they had designed. Each of us has learned how to use Excel in our own way, and we like to use it that way. Add to that the fact that when you use it as a product basis, you lock down certain things- so you may even be blocked from using it the way you like. And if the product is trying to do serious statistical calculations, you enter the realm of things like pivot tables, etc. Have you ever used them? If not, you won't like a tool that does. If you are attracted to Excel spreadsheets to resolve a technical issue, I would encourage you to build your own rather than buying somebody else's. It's much less frustrating, and the learning curve of what you CANNOT do is much less. Oh- and be sure that results are exportable to Excel- That part IS valuable whether for further processing, or for writing reports, and sharing.

Of course, most vendors who offer high-difficulty packages make up for it with a deep services offering. Their hope is that you will purchase the (hook) software having seen the demo. You’ll then try to fly into it like the experienced tech guy who demo’ed it to you and get lost. You then immediately phone for help, and experience what the guys at Fluor used to refer to as a change-order-driven income stream. It's not what you expected when you purchased, but you are now trapped. An initial small investment in software can lead to a very large investment in ongoing services to obtain the expected value. I wrote another blog referring to stone-soup software that approximates this problem. One way of checking this is to examine a vendor's historical and expected income. A true Software Vendor expects less than 20% of their income to come from services. And that means on any given project (so examine the quote for this balance) and for any given product. Note that some companies sell certain products that almost install themselves, but have higher services on others. If the latter is a smaller percentage of their business, they may skew the numbers when talking with a prospect to invite them into the trap fro the services-oriented piece.

A side note in the Alarm Management field here is that we’ve learned over the last few months that many people went to certain service vendors to get a rationalization performed. They didn’t really know what to expect when it was performed, but they did know that what they received for their money did not meet their expectations. (there’s some deep irony in that statement.) In fact, they’re still not sure just what they got for their money. TiPS is soon to release some standards that will help to shed some light on this issue, and increase both the expectation and understanding of the recipient of such services.

Speed of Processing the job- This often has to do with work flow built into the product, and the basic product design elements. It also gets into issues like ease of installation. Has the vendor made the software so it is easy to install, configure, and process the information necessary to accomplish the job? Or, will they be on site inventing a new way to tie their so-called OPC driver into your system, while you teach them how to do it? The sooner you start receiving results, the sooner you can recoup your investment. Conversely, the longer you spend making it work, the more its base installation is costing you, and the more man-hours are adding to TCO- whether they are apparent or not.

The next piece of that is of course, how much they have automated their product to perform the task at hand.  Did they build the product with the mindset that they would augment it with services, so it was not necessary to automate its actions? Or did they build it with the hope of making it so powerful they would never have to visit your installation site? Have they strived to make most functions have two-click access to the underlying information? One easy way of judging this is to find out how many of their clients are using the product to accomplish the end-use goals themselves. Is it greater than 50%? Or do they try to make excuses for how busy their clients are, and how this operation is one that just shouldn’t be tried by those not familiar with its intricacies.

One other test for this is to notice how many times they talk about what they have done for their users versus how many things their users have done. A very experienced technical person may often  be the sign of a very weak software package. The more they try to impress you with their own knowledge, and the less they try to show their software architecture, the greater chance their software is not designed with automation in mind.

Note that in some particular instances, software simply cannot do everything, and services will be necessary. In those instances, you’re looking for the package that requires the least amount of services, having built in as much automation as possible. The package which requires the least on-site time usually wins this category.

Costs to Upgrade- What will be the upgrade path? If it is a client server application, do I have to install a client package on every platform that wants to use it, or does it use pure thin-client architecture, requiring only server installation? The cost for this difference can be HUGE, and is the least examined. Many try to cloud the issue by having certain parts of their application be thin-client oriented, while the upper level application layers require additional client installations. The other dodge is to offer a "web-based" wrapper that accesses the legacy applications via a "look-in" window. This is very dangerous, and maintenance-prone. Think through the process of what will happen when Microsoft releases a new Service Pack, and you require an upgrade installed. The average software company has one major release a year, and almost quarterly releases for patches to accommodate Microsoft issues, etc. What is your corporate upgrade policy? Does it guard against periodic upgrades? What is the danger of being caught a few releases behind? What is your potential cost to stay up to date with their releases? Get a true IT professional involved in the negotiations to help examine these costs.

Training Costs- These costs go hand-in-hand with those mentioned above. Sometimes you may find that the company either requires extensive training, or doesn’t even offer training. The second Is acceptable if the product has high ease-of-use. Ask which different layers of personnel need training? Do you need specialized administrative training for DBA’s or such? How far does the invovlement string continue into your personnel? Does every department have to attend for the software to work? Or is it controllable at the source by a singular person? THese are two extremes, but it illustrates teh difference.

Periodic Maintenance- What is the maintenance cycle on the product? Doe it require constant attention? How often must an administrator go to the server that contains the application to keep it refreshed, and running? How does it fail when things go wrong? Does it fail “gracefully”, and restore itself without a hitch? Or does it require human intervention every time it has a glitch? The cumulative costs of this aspect can be staggering. Not to mention that operations personnel will eventually just turn it off, and you will find it is not running at the time you want its results the most.

Other intangibles- Has the vendor included any specialty features that add to the value, and lower the cost to operate? Some examples might be automated report generation, remote service access, error report generation, and even e-mail of glitches and system issues. Some even provide pager access to prevent extended down-time. Others provide remote service support of the application, so long as the client’s security procedures will allow it. For example, we maintain remote access keys to some systems, and we can actually log into the client systems from our offices. There may be small things which can greatly reduce TCO.

Examine TCO. This is just a primer. You'll find more to it than I have listed. A good look at these costs on the front end can help to avoid a massive unplanned outlay.