Archive for the vendors Category

Screwing up

The Register has a recent, chatty article about successful implementations – ERP (again) but the general principles apply.  Their first point goes to the heart of the services we offer:

It’s obviously necessary to define your requirements appropriately and select a package that fits. Indeed, one of the most prominent recommendations coming back from Reg readers is to minimise the amount of development work associated with customisations and extensions. You can only do this if you start out with a reasonable match between the software and your requirements. And of course when modifications to standard functionality are necessary it helps if the software you have chosen is based on an open platform that is easy to work with from a development and integration perspective.

Do projects ever end?

In the public sector, the billing system usually represents the biggest single entity within the IT environment.  However even if the billing system  doesn’t account for a lot of the infrastructure per se, it is one of those applications (or suites of applications) a lot of other stuff needs to be plugged into. It’s therefore not something you can easily put to one side and forget about.

The truth is that while everyone focuses on the initial implementation project when considering the cost and resource requirements of the billing system, it doesn’t all come to a nice sweet end after the initial go-live. Whether it’s looking after the beast itself from an operations, maintenance or enhancement perspective, or making sure it remains properly integrated with everything around it, the end result is typically a significant ongoing effort on the part of the IT department.

In terms of routine activity, there’s the usual application of patches and fixes from the vendor, which could be to do with minor functional enhancements, the implementation of regulatory changes, or more systems related things such as supporting the latest upgrade to the database management system upon which the application depends. There’s then the more traditional systems ops side of the equation, ranging from patch management and maintenance of the underlying hardware and platform software, through storage and information management, to performance monitoring and management, including troubleshooting server, storage and network issues as they arise.

In addition to this core activity, an area that has become more of a consideration over the past few years in particular is security and access. As billing systems have been opened up to broader and faster moving audiences, especially customers, more thought and effort has needed to be given to user provisioning and making sure access routes are properly secured. And, of course, the billing system needs to be kept in sync with everything else from a policy perspective.

Some of these developments have come about quite naturally as technology has evolved and opportunities have arisen to take advantage of new ways of doing things within the business. In other areas, technology advancements have also enabled efficiencies to be introduced into the underlying platform. Modern servers, for example, can reduce the cost of ownership considerably when you look at improvements to price performance, energy consumption, space requirements and - not least - manageability. And improvements at this level are not going to let up, so the occasional replatforming project is inevitable in most organisations, with all of the migration work that goes with it.

Beyond the systems side of things we have the day-to-day keeping up with what’s going on in the business. This includes handling change requests for minor modifications and enhancements to the system, and here it is not just the technical work that needs doing, but managing the whole review and approval process, which can understandably be quite strict in some organisations where even a relatively minor mistake could easily have disastrous consequences from a business integrity, continuity and regulatory point of view. All of this adds to the overhead on IT, without even thinking about more substantial projects such as major package upgrades, implementation of new components/modules, extension and customisation work, and integration overhauls as other systems with which billing is inter-dependant are changed or added, etc.

In some organisations, the level of ongoing activity is such that they maintain permanent development and test environments alongside the live system to control and manage the throughput.

Project costs

There are many variables that impact the final project price. The mistake many companies make when initially trying to estimate the cost of a project is paying attention to only the actual software license costs. However, a recent white paper outlines four elements that need to be considered in every software budget.

One of them is “implementation services”. This term can seem vague, especially if it is a company’s first large software project. The white paper includes a definition of the 8 services you are paying for. It also outlines minimum software to services ratios, 8 questions to ask to know when to add more money to the budget and a sample quote. The buyer is also given the pros and cons of the two methods of pricing software implementations: “Time and Materials” versus “Fixed Fee”.

The White Paper is a useful overview that can alert readers to potential costs they may have overlooked

Implementing the software wisely

In the second part of a recent Computerworld series on ensuring software implementation project success, Ian Anderson, director at SAP services company DNAstream sets out four elements that he regards as critical:

The first one is a telling reflection on SAP in particular:

“The chosen software must be able to meet the required business processes, not absolutely, but at least to a level that is agreed in advance as acceptable, perhaps a 70% to 80% fit. This is often achieved through a level of compromise, such as adapting the business processes to fit the software where possible.

It is essential to have these business processes identified, documented, understood, mapped to the software and signed off by the business before you start implementation.”

A lot of billing folks would regard a 70 to 80% fit for billing to be a failure.  To be fair to Anderson, he was talking about ERP.

The second is “choose the vanilla flavor”.  In billing that’s not always possible, as billing rules are often mandated by external agencies and regulators.  Here’s what Anderson says:

“The overwhelming advice is to keep the software as standard as possible to avoid potentially costly effort on support and future developments, including upgrades. This is often referred to as vanilla ERP.”

His third point is always a timely one, especially where utilities rush out to get advice from a big-name consulting firm, as if that minimises their risk – use a consultant who understands your business and will know the best approach for you, rather than simply repeating the method he used at his previous client.

Lastly, “Constantly check and review during the project.”  A well-managed project is a prerequisite for a successful implementation.

Dealing with regulation

One of the issues with regulated and partially-regulated utilities such as those in the public sector, is that the actions of the regulator may impact projects already started.  That’s the cautionary tale this week out of New Zealand:

TrustPower announced to the stock exchange this month that it had suspended work on an $18 million project to replace its billing and customer management systems with Oracle software and would probably have to write off a portion of the $9.5m it had spent on the system to date.

Meridian Energy put a project to install Oracle software on hold in December in similar circumstances. Contact Energy last year raised eyebrows within the industry by budgeting up to $80m to replace its systems with software from Germany’s SAP.

Contact would not comment on whether it believed any unnecessary complexities in the electricity market were behind the big bill, or had contributed to a decision by its original implementation partner, IBM, to pull out of the project, but said it was now pressing ahead with the investment.

TrustPower spokesman Graeme Purches says it became clear Oracle’s software would need to be extensively changed to meet the demands of the New Zealand market, so TrustPower had decided to review its options.

Oracle had tendered software used in Australia that both companies believed would do the job, but the difficulty of dealing with 28 electricity lines companies that had their own ways of calculating tariffs, reconciliation with the wholesale market, and a variety of metering technologies meant the software would need to be largely rewritten.

"New Zealand is a complex market and it is probably no coincidence that three companies have had to pause projects and they are all in New Zealand."

Oracle was not to blame, he says. "Maybe there was an issue about us not communicating in enough detail what we were expecting."

When projects go bad

The stoush between SAP and Waste Management as reported by PC World highlights the issues at the heart of vendor selection:

SAP used "fake" and "rigged" software demonstrations to convince Waste Management its products were a good fit, according to the trash hauler. But after years of work and great expense, the product did not work satisfactorily, Waste Management claims.

But SAP has denied any wrongdoing and counters that Waste Management breached its contracts with SAP by failing to "timely and accurately define its business requirements" and provide "sufficient, knowledgeable, decision-empowered users and managers" to work on the implementation.

First: identify your business requirements.  Setting out a checklist of essential functionality might sound like overkill, but incorporating the checklist and the vendor’s responses into the contract may help give clarity later.  Checklist availability can be found on our main site and at Public Sector Assets

Second: be in control of the selection process.  Define the script of what you want the vendor to demonstrate.  Home in on the key aspects.  Ask who else uses the software in that way

Taking care of the people

Any new billing implementation will challenge the people who will be using it to carry out their day-to-day jobs.  Anticipation of changes in process and culture that occur when implementing a new system can cause considerable anxiety throughout the business. It is important to foster confidence, support, and active engagement from the end-user community. This will help lead to quicker adoption of any new business processes and a stronger return on your investment.

Anytime a change as significant as implementing a billing system is made, the business must seriously rethink how all the people, processes, and technologies fit together to support the business goals.  A strategic planning process including change management should reinforce implementation plans and identify potential pitfalls early on so that they can be addressed them in advance.

Vendor associates

Sierra Systems, one of the companies in the same stable as Infor Global Solutions, has been selected to conduct an analysis of Ls Angeles County’s current property tax system and business processes, and working closely with the Auditor-Controller,
Treasurer and Tax collector, and Assessment Appeals Board, will develop the
desired business process and functional requirements for an eTax system.

Upon completion of this analysis, Sierra Systems will develop a logical system
architecture and implementation plan which will serve as the basis for the
implementation of eTax. The project will conclude with the creation of the
request for proposal and evaluation criteria that will be released by the County
to solicit bids for the eTax implementation.

Mentored implementations

Good project managers don’t just happen.  Mentored implementation accomplishes two goals - it improves the nuts and bolts of a project, and it also creates new leaders and project managers.  The important thing for the site where such mentoring is going on is that it doesn’t add to the cost of the project – some vendors like loading up the project staff with trainees who add little value to a project while being trained at the customer’s expense.

The care and feeding of the product manager

Henry Ford once declared that if he had only listened to his customers he would have built a better horse and buggy.  While listening to a customer is an important part of the effective product manager’s role, turning what he has heard into enhanced functionality needs a different skill-set than just listening.  The produce manager must be able to make the leap of how emerging software technologies may be able to deliver the outcome in an entirely new way.  What Henry Ford heard was his customers expressing a desire to get from A to B quickly, safely and cheaply.  He was able to turn that desire into a completely different transport paradigm.  The effective billing manager should be able to do the same.