| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jul | Sep » | |||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | ||||||
- product manager (7)
- projects (40)
- resourcing (4)
- software selection (1)
- tax billing software (32)
- vendors (49)
- water billing software (38)
- 19. April 2011: User groups
- 19. April 2011: Detecting theft
- 13. February 2011: Automated water meter reads
- 27. January 2011: What German utility billing software would that be?
- 5. November 2010: Seven myths of billing implementations
- 24. October 2010: Comparing utility billing software
- 1. October 2010: Failing in the public sector
- 29. September 2010: Project failures
- 27. September 2010: Not the product manager
- 25. September 2010: Not the product roadmap
projects
Key points
From time to time bloggers comment on the “six [or five or ten] key points” about software vendor selection. Ignoring sticker shock (price) surely the principal element must be “does the vendor understand all of the elements of public sector billing?”. Sadly many do not. I reviewed a bespoke utility billing application recently where the billing side was world class. It carried out some of the elements of interval billing in the energy market like nothing else I’ve seen. However its designer knew nothing of double-entry book-keeping. It’s incapable of producing reliably even the most basic entries for export to a general ledger. It’s implemented, the bills are churning out, the customers are paying - and the utility has no idea, apart from money in the bank, how their business is faring.
Leave a Reply
You must be logged in to post a comment.