Hi Richard, this is really useful. A few points:
I think there's a tension between making the system fit to your work and making the work fit the system. Some of the most successful systems (the SAPs of this world) are very demanding that users fit their work to the system and not the other way around. I would suggest that when you're looking for a system you should find the one that best fits your needs (other things being equal) but once you're committed that you should be prepared to change your workflows to meet the quirks of the system, with the proviso that you monitor the changes and try to get the system improved where it is creating inefficiencies. This is related to work-arounds, which I find are often a case of people being unwilling to change their behaviour to fit the system, rather than just people designing the work around the system. I agree software-generated work-arounds should not be tolerated; pressure should be brought to bear on the software developer to make their system fit for purpose. But if users are simply being stubborn then that's not the software developer's fault.
Corporate ICT demands (eg document management, "paperless" systems) usually stop a system being used to its full functionality; the developer then spends all their time meeting your authority's bespoke integration and workflow requirements. Choices need to be made between practical departmental systems and those big ICT programmes - which takes precedence, should we make them work together or can we cope with them being separate, etc. There will never be "one system to rule them all", so as an authority you need to figure out how to make your various systems work together.
Standardising processes (where they are good processes) is a good idea, though in my experience it's better to learn from other authorities that are operating the same system rather than standardising with your neighbours (unless there's an intention to merge functions).
Software is often seen as the financial silver bullet that will cure your department's funding gap. More often than not it won't; it may transfer some revenue spending to capital spending, but the implementation will be costly and (as most systems are badly implemented and maintained) it will most likely transfer the costs onto overworked staff. The benefit of a new system will probably only be an improvement in quality of service (usually in the form of more accessible and better presented information) and in keeping up with the increasing demands on the service.
Reporting tools are frequently overlooked as they are used directly by very few people. Good reporting is invaluable and stops you from running your service based on people's moodiness levels (which is also a useful sign, but hard to quantify!) Most systems have shoddy built-in reporting tools and would be better served by running business objects or crystal alongside them. So many departments have a separate database, usually on access, that replicates the actual applications database in order to satisfy reporting requirements; it's important that you're clear as to what data you want the system to hold, and how you're going to get this out of the system, over and above its day-to-day operation by general users.
And another thing...! Sorry, that turned into a bit of a rant!
Rob
