| State governments no longer need to be sold the virtues of e-enabling themselves. In fact, there is today an excessive zeal in pursuing e-governance, without realising what works and what does not.
|
| |
| A list of guiding principles, or simply dos and don’ts, is urgently needed for the states to be able to spend public money wisely.
|
| |
| The IT industry has a stake in this. A key reason why the domestic Indian IT industry is so modest in size, compared to, say, the Chinese, is the low level of government spending.
|
| |
| Now that this is likely to rise, it is necessary to ensure a reasonable RoI (return on investment), the current buzzword, and also avoid mishaps.
|
| |
| That can put the whole idea of widespread uses of IT in government into question and introduce bureaucratic controls in the way of such spending. Vendors, both local and global, need to sincerely join in a debate to evolve a charter of sound practices for IT procurement by governments.
|
| |
| The first thumb rule for state governments is to learn from one another. For this there has to be a forum with a website where certain types of documents are automatically posted and all stakeholders are able to freely share experiences.
|
| |
| Suresh Vaswani, president of Wipro Infotech, a leading domestic vendor active in the area, finds that today “the learning of one state is not getting passed on to other states. All of them seem to be starting from scratch. The IP created by one state should be shared across states.”
|
| |
| For example, there is anecdotal evidence that Rajasthan has gone about the business the right way, fairly early in the day, by having its IT department requisition all IT assets and then reissue them to departments according to assessed needs and priorities.
|
| |
| The second thumb rule is that there should be common guidelines and basic principles on how to go about the entire business. There is a difference of opinion here.
|
| |
| Some like Vaswani want there to be “a common body which looks at setting the standards and then the states can implement these as and when required. This body should set guidelines on implementation timeline, terms and conditions and contract details.”
|
| |
| Others are very wary about setting up a centralised controlling body whose guidelines would be mandatory. IT in government should not become a command and control exercise even before take-off.
|
| |
| Since there is a consensus only on guidelines in the true sense of the word, what should they be? Jim Snabe, a senior vice-president in the German enterprise software leader SAP, feels first things should come first.
|
| |
| A country’s first need is to have a harmonised IT infrastructure and India has been right to concentrate on it. But others are not so sure.
|
| |
| Vaswani feels that the “government needs to work out a common infrastructure which can be used by all as and when required. Instead RailTel, PowerGrid, the income tax department are all investing in infrastructure for their own use.”
|
| |
| Snabe makes a second point. “There is today a trend away from investing in new processes. Countries which want to leapfrog should invest in best practices, go for standard solutions. The best practices today are in fact what is called standard software.”
|
| |
| But you need to put the solutions together, so you will need a consultant to design the system. “It is critical to give the consultant the right brief.”
|
| |
| Rajeev Chawla, the e-governance secretary of Karnataka who has become well-known through his shepherding of the Bhoomi project, which has computerised the state’s land records, has clear ideas.
|
| |
| Keep the citizen and his needs at the centre and tender for services, not the IT requirements needed to deliver those services. That way you will insulate yourself from a lot of technical details.
|
| |
| Vaswani says the same thing when he calls for tight service level agreements (SLA)—for example, what kind of down time will be allowed and response time guaranteed.
|
| |
| “Typically, governments have rigid terms and conditions and SLAs are worked around these.” It should be the other way round. Chawla adds that SLAs have to look at security, scalability, openness (other systems should be able to connect). “The government should have logic control of the server, not what type of servers need to be bought.”
|
| |
| How to weave together these diverse elements like SLAs, tenders, consultants? A veteran in public sector computerisation gives this sequence.
|
| |
| You need an IT road map but who will do it? Who will select the cost-effective technologies, the standard solutions that Snabe talked about?
|
| |
| For this you need a consultant if competent in-house people are not available. This consultant has to prepare a key technical document for the chosen applications—systems requirement specifications—which form the basis for writing the codes.
|
| |
| With the software (applications, operating system, relational data base management system) has to come appropriate hardware. To make sure that software and hardware vendors don’t fight, it can be a good idea to have a turnkey contractor who handles all of it.
|
| |
| But you need someone to write the tender document for the turnkey contractor and also act as your agent to supervise him. If the turnkey operator can be a large or reputed Indian software vendor, then the supervising consultant can be a much smaller outfit like something run by groups of IIT faculty.
|
| |
| But no matter how much you outsource, you need a key government group to visualise and oversee it all. Chawla’s preferred model for this is the Infocom Development Authority of the Singapore government.
|
| |
| It is a core group with a critical domain knowledge of government but a loose structure enabling talented people from industry and academia to come in and go out after a stint.
|
| |
| He doesn’t spell it out, but Indian governments currently lack this flexibility—openness to lateral entry—something which his IAS colleagues typically do not have. |
| |
|
| |
Content Guide
|