On Total Cost of Ownership
Quite a bit of attention has been turned to reducing the Total Cost of Ownership (TCO) of Sage products for Sage customers. Does this mean Sage needs to reduce prices? Does this mean Business Partners need to reduce prices? Paradoxically the drive to reduce TCO has nothing to do with reducing prices. It is all about making sure that there is true value in everything the customer is paying money for. TCO also goes beyond just the price of the software, M&S and implementation costs; it is also the cost of down time, the cost of learning the software and the cost of inefficient processes. Within Sage all groups are mandated to look into ways to reduce the TCO for our customers.
This blog posting is about how this is affecting development. What problems we are looking to address. Some will be addressed quickly and some will take longer. This blog posting is specific to Accpac development, but each development team at Sage is working on these same sorts of TCO issues, just each product has a slightly different set based on their unique heritage.
The most visible area that customers complain about TCO is the cost of upgrading from version to version. There are many aspects to this and a great opportunity to reduce TCO here. To be fair, a lot of these problems were caused by development in the first place. Often to shorten development cycles we could push some work from development off to the channel. For instance requiring that all batches be posted before upgrading, saves development and QA time, since we don’t need to convert the data in the unposted batch files; but shifts the cost to the channel who now have to charge to make sure all the batches are posted as part of the pre-upgrade checklist.
Hopefully with 5.6A you can see some first steps in making the upgrade process easier. These include:
- Shipping all modules together at one time, including all the language translations.
- Installing all products from one single installation program.
- Combining product updates into a single install for all the applications.
- Allowing you to run data activation as one process to convert the database for all applications in one shot.
- Providing free training, to help customers get up and running on the new version quickly.
- Providing better documentation on all the changes in the new version so there are “no surprises”.
- Bringing in a large number of customer databases to test database conversion. Plus testing database conversion as part of the controlled release program.
Going forwards in the new versions we are going to be working hard to identify problem areas and address them. Note that the following list isn’t a commitment to do all these in 6.0, but you will be seeing them over the next few versions:
- Making reports upgrade safe. Allow you to skip the step of verifying and re-testing all your custom Crystal Reports.
- Make screen customizations upgrade safe. When we move away from VBA for screen customization, we don’t want anything like the problems with re-adding all the references and fighting the EXD files.
- Work hard to make database conversion from version to version as robust as possible. Work to speed up database conversion. Self-heal any problems.
- Work with the ISV community to ensure ISV products are available quickly with the new version. Take great care that changes we make don’t break ISV products.
- Remove workstation setup. As a web based application only the server needs to be installed/updated. No more visiting hundreds of computers to run Workstation Setup/Database Client Software.
- Work on reducing the pre-upgrade checklist down to just performing a database backup for safety.
- Work on reducing the post-upgrade checklist to nothing. After installing and running data activation, everything else should just work.
- Being careful about the TCO implications of adding new features. For instance if we come up with a nifty easy to code improvement to A/R Invoices, but that change would require all custom Invoice reports to be re-created, then we probably wouldn’t do that feature. The ROI would need to be astronomically high, or besides the simple code change we would need to produce a utility to seamlessly convert all existing reports.
- Take care in changes that require operating system, database or hardware upgrades. These are all part of TCO.
Another area of TCO being addressed is productivity and learnability of the software. We have been building a large User Centered Design (UCD) team to study customer’s usage of Accpac and develop ways to improve the software. We have an observation lab where we observe and measure real customers performing tasks. We compare the results of old ways versus new ways, so we know we have improved things. The UCD team has a great deal of skill with coming up with better ways to do tasks, but we always test these by measuring customers actually performing these tasks. The goal of the UCD process is to allow customers to:
- Be more productive. Accomplish routine daily tasks like entering invoices quicker and more accurately.
- Be able to accomplish a new task without requiring additional training. Make learning the software much easier.
- Find using the software more enjoyable. Find pain points or frustration points and find ways to remove these.
Generally TCO is a definite competitive factor in our industry. It is also a key factor in providing an Extraordinary Customer Experience. We want to make sure everything we do adds real value for the customer. A lot of these things start in R&D, but hopefully you are starting to see improvements as we move forwards with each new version.