Like many who have worked on large software projects, I have been following the failure of the NSW State Government's unified transport card project with great interest.
My family lived in Hong Kong for two years and we greatly enjoyed the "Octopus" stored value transport cards very much. Here's how it works: You go down to the station and pay an initial deposit of HK$150 (AU$22) and get an Octopus Card.
When you enter the MTR (Mass Transit Rail) system you wave the card past a contact-less reader as you go in. When you exit the MTR system you again wave your card and the amount of the fair is calculated and deducted from your balance. The barrier shows you the remaining balance. As needed you top it up either at a machine or one of many shops near the stations. It's quick and easy.
Now, a word about being contact-less. This is key, you can leave the card in your wallet or at the bottom of your bag and just wave it over the reader, no extraction of the card from a purse or unreliable reads due to corroded contacts or erased magnetic strips.
The same card works on busses, trams and ferries. I think the bus system was simplified to just have a flat fare for the route regardless of distance.
The system works well, is simple (once you know), and positively encourages use of public transport. Hong Kong is one of the densest populations in the world so it's not a fair comparison with Sydney, but there are lessons to be learned about the power of simplifying the system.
The most amazing thing I heard about the Octopus system is that it was designed by an Australian company, from Western Australia, none other than ERG Group.
I was surprised how badly this project had ended until I read in the SMH on January 31 that the State Government had "offered no co-operation in simplifying the fare structure of Sydney's public transport system". Apparently, ERG were trying to model the existing over complex system and this meant putting up to 73 fares on one ticket.
In my opinion, the introduction of a unified stored value ticket system should be accompanied by a drastic simplification of the fare system. Surely the costs of collecting all the current fares would be offset by the savings of the new efficient system, even with fare reductions for the longest travellers?
ERG has "lost $250 million building the system" so far. They have received no significant income from the government, (which is further threatening to sue them for $500 million), and worse it sounds like they haven't received the support needed for such a project.
The NSW State Government needs to have a good hard look at how they participate in IT projects. It's typical of government clients to go to market looking for existing software that closely matches their weird way of operating, riddled with perverse history, rather than going to market searching for worlds best practice and then bringing their operation into line with that.
Choosing (or changing) a business model to suit a technology choice is completely backwards IMHO. It's a recipe for disaster, because it completely bypasses any assessment of viability of the business. I can totally understand that the default position of any business undergoing technological change to be "your technology should suit the way we work" not the other way around.
ReplyDeleteOn the other hand - and I think this is what is happening here - business models are often subject to change as a result of the overall marketplace, and that can be highly sensitive to technological change. But the basic premise still remains that the viability of a proposed change to the business model needs to be considered carefully before choosing technology to suit.
In other words, the fare structure needs to change because the passengers demand it, because it simplifies processes, and because it drives demand in the service - NOT because the technology demands it.
I think there's two kinds of scenarios where automation comes to a business process, one is where the objective is to directly automate the existing business process so that it is transparent to inputs and outputs, the other scenario is where we need to change many processes in the business.
ReplyDeleteMy argument is that processes that were created before computerisation and in a politically charged environment with fiefdoms protecting their organisational structures, should be put aside and possibly replaced with new structures that assume automation.
Software is very flexible but the real world is very complex and it's hard to model the world as it is.