Archive for the vendors Category

User groups

How useful are user groups?  That’s very much dependant on how much the members contribute.  They can operate as workshops for ideas for maximising the existing version of the software and as forums for the vendor to discuss potential new ideas.  We always try to gauge the strength and role of the local user group when assessing an application’s suitability to implementing at a site, and the convenor of the nearest user group is always on our list of referees, whether the vendor has listed them or not.

What German utility billing software would that be?

Stories have hit the Johannesburg press about problems with the city’s new water and electricity billing software.  It’s the thing that all billing managers fear – stories of incorrect bills and angry consumers getting into the newspaper.  Neither of the stories have reported the name of the software being used, but the chairman of the Finance Committee is reported as saying “German specialists were periodically brought in because the billing system had been designed by a German company.”  That’s all pretty clear then.  However the problems as reported seem to lie not so much with the software but with the implementation.  Mayor Amos Masondo admitted that Project Phakama - to set up the new billing system - had not been implemented fully, with two of five modules not put into effect.  There also seems to have been an issue with customers old accounts not having been migrated to the new system.  The two stories – and you can bet there will be others – about the electricity water billing system can be followed up here and here.

Seven myths of billing implementations

  1. Billing projects are IT projects
  2. Billing software is useful out of the box
  3. Billing vendors will provide all necessary project management skills
  4. I can manage my own billing project
  5. All billing systems are the same
  6. The budget for the project is the same as the quote I receive from the billing vendor
  7. I can put the people on the project the business will miss the least

Failing in the public sector

Two recent news events highlight the triumph of hope over … reality?  Historically ERP implementations have been a failure for the public sector as government really is different.  In the City of Gold Coast, in Australia, the local government has decided to go ahead with implementing SAP as its whole-of-government system.  This includes a property tax billing module that has never been shown to succeed in Australia or New Zealand.  Those in the know cite Wollongong and Christchurch as two examples where an SAP implementation has been less than successful

In June it was announced that the city of Indianapolis and Marion County have embarked on a $16 million technology overhaul designed to improve business processes, standardize technology and drive down costs.  Under the planned three-year effort, the city will replace its ancient mainframe-based back-office systems with technology based on Oracle’s PeopleSoft ERP suite.  (That’ll be the one Larry Ellison tried to kill off shortly after he acquired the company via a takeover).

Computerworld comments that “Several similar efforts by other state and local governments have failed in dramatic fashion over the past few years”, but Indianapolis IT officials are hopeful they can pull it off successfully by keeping the project focused tightly on business process improvements rather than technological ones.  "We are going to focus on business transformation and not the implementation of technology," said Glen Baker, the city’s CIO. "We are committed to implementing the products as vanilla as we can" to minimize technical complexity, he said. "We have as much opportunity as we need to modify them later"

Project failures

I guess it had to happen.  There’s now a blog about IT project failures.  I’ve added it to the sidebar for this blog.  I was drawn to their most recent story about EDS being sued for $460 million for a failed CRM inplementation.  At last the victims of the promises Systems Integrators make are getting their own back

Not the product manager

Not the product roadmap

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