Advertisment

Jump Those Hurdles

author-image
DQI Bureau
New Update

Electronic tendering was virtually unknown in India till 2002. Attempts were

made to automate the tender document download process for higher-value tenders

at around that time, but the success was limited at best-both in terms of

acceptance by end-users as well as in terms of how much of the tendering cycle

could actually be captured electronically.

Advertisment

Tendering is the most critical form of public procurement, and compulsorily

required the world over for governments to demonstrate transparency,

impartiality, and value-for-money to their electorates. Electronic tendering is

the migration of this process to an online, usually an Internet-based, system.

Nearly three years after  electronic tendering was launched in India, there is still a

surprising amount of confusion on its process.

Sealed

Bid Security:




The Minimum Requirement

A security electronic

tendering must at least address the following issues:

  • Access control

    based on both role and workflow

  • Appropriate use of

    encryption at different stages of a tender

  • Time

    locking-denial of access to bid data before cut-off date

  • The system must be

    tamper-proof or at least tamper-evident to effectively prevent

    collusion

  • The system must be

    able to transfer access control and privileges from one official to

    another without the need to share passwords, digital certificates, etc

    and otherwise breach security protocols

  • Be based on

    application-independent global standards such as PKI

The Supremacy of Workflow



One of the important reasons why early attempts at introducing electronic

tendering in India did not succeed is that the rules governing private

procurement are very different from those governing public procurement. Early

solution providers made the mistake of rehashing private procurement systems for

public use with predictably disastrous results. A successful electronic

tendering solution must successfully mirror them. Thus, the first requirement

for an electronic tendering system is that it must be fully workflow-driven.

However, workflows differ from government to government, and department to

department. To keep implementation costs and lead-times within reasonable

limits, an electronic tendering system must also be easily customizable. This

seemingly paradoxical requirement of rigidity (workflow) and flexibility

(customization) in electronic tendering is a challenge that few have

successfully met.

Advertisment

To be successful in the Indian situation, an electronic tendering system also

needs to be flexible in another sense: to ease the transition electronic

tendering must, at least initially, support alternate modes of submission.

The Technologist's Dilemma



Evangelism comes naturally to the technologist-early electronic tendering

attempts came with a strong dose of re-engineering for government business

processes. Although the motives behind such attempts may, to a large extent,

have been noble, they lost sight of an important fact of life: Indian government

bodies are exceptionally resistant to change.

The procedural obstacles to change are pretty formidable as well. Keeping

business process change to a minimum at the early adoption stage is therefore,

the only practical way of implementing electronic tendering on any reasonable

time frame.

Advertisment

The Cost Factor



In addition to being resistant to change, government bodies are also

understandably risk-averse. The huge license fees typically charged for

enterprise-level software by international software companies, without a clear

value proposition, constituted a major entry barrier for India's state

governments. The large investments that these companies had made in their

software and the high initial cost of implementation meant that there were no

easy solutions to this problem. The paradigm shift occurred when the “no

upfront cost to government” revenue model was introduced in Chhattisgarh in

2003. There are no licence fees in this model; all investments in server

hardware, hosting, and training are taken care of by the application service

provider. The source of revenue for the service provider, is a share in the

tender document fee—this can either be in the form of a fee for document

purchase (Chhattisgarh) or a fee for bid submission (Assam). These fees are

typically collected online through the tendering portal. The advantage for the

service provider is that he has an assured and reasonably predictable revenue

system without the irksome overhead of collecting from government.

The government, on the other hand, has a completely risk-free way of putting

its tendering processes online—the revenues earned by the service provider are

purely in the nature of a 'success fee'. Vendors/contractors pay service

fees equal to, and often less than, the document fees they have been used to

paying, providing an automatic incentive for them to migrate to the online

system.

Security: The Make or Break Issue



Across the world there are these security challenges. There are various

stages in the tendering cycle, and the security issues are different at each

stage:

Advertisment
The

Limitations of Existing Technologies

Conventional wisdom on document security

is not adequate for electronic tendering systems as 'the mere viewing'

of bid data is a fundamental compromise of security. The limitations of

existing technologies are well known:

HTTPS: This is the protocol for secure

transmission of data over the Internet. It is typically used for banking

and credit card transactions.  Data

residing on the server is vulnerable.



Time-stamping: This is easily defeated by bid substitution-multiple bids
with the same time stamp can be kept ready in advance.



Standard Encryption and Double Encryption: 'Decryptable' at any
time-all you need is to gain access to the appropriate key.



Digital Certificates and Hashing (Fingerprinting of Data): Again, bid
substitution defeats this.



Time locks can be compromised by anyone with access to the application
layer since it does not form part of Public Key Infrastructure (PKI).



Biometrics and Other Server-access Restrictions: Defeated by collusion
with the buyer and the need for offsite backups.



Read-Only Logs and Audit Trails: Oxymoron-logs and trails are written
and hence can be edited by a system administrator.



4-Eye Principle: Can be defeated by colluding with all buyer personnel
involved in bid opening.






Tender Preparation and Release: An

electronic tendering system needs to have workflow-based access for the person(s)

preparing the tender (maker), the person(s) validating the tender (checker), and

finally for the official who approves and releases it (approver).

Bid Preparation: Only the bidder

should be able to view the bid data at this stage. All data resides on the

server-it must be encrypted both during transmission and storage in such a way

that only the bidder can decrypt it.

Advertisment

Bid Submission: The bids

submitted must be in such a form that only the designated tender official can

open it, and not before the scheduled time. This last requirement is critical

for tendering.

Bid Storage: Even if the service

provider, buyer organization, one or more vendors and system administrators join

hands/collude, bid data should not be viewable before a cut-off date.

Bid Opening: Bids should be

available in an unencrypted format when opened.

Advertisment

Transfer of Privileges: Given

that transfer/retirement of tender officials during the life cycle of a tender

is not an unusual phenomenon, it should be possible to securely transfer access

rights/privileges from one official to another.

The challenges of secure electronic bidding are far from trivial. India is

the only country where a fool-proof solution to the security problem has been

successfully implemented. And there are international patents to prove this. The

reason why the developed countries of the West are nowhere near a level-5

electronic tendering system (in terms of the classification discussed above), is

that they have not been able to find an adequate solution to the security

problem. What is now practised in these countries is a hybrid system. Tenders

are downloaded electronically and submitted manually. The manually submitted

bids are then entered into bespoke systems that interface with the buyer

organizations' internal systems by software consultancy firms. Alternatively a

simple document exchange of bids, using HTTPS and at best a digital certificate

login is used. Ironically the latter system is more vulnerable to security

breaches than the traditional system.

The only system with level-5 aspirations outside India is a system designed

by an arm of the South Korean Government. But the security issue has been

glossed over to a large extent.

To make this this theoretical lead an actual one, we need to participate much

more actively in the formulation of international data exchange standards

through bodies such as UN/CEFACT. Secondly, we need to shed our traditional

contempt for the cosmetic aspects of a product -in international contexts

slickness is often at least as important as the inherent strength of a product.

Thirdly, we need to be aware that platform agnosticism (both as regards

operating system and database) is where the bright future lies where we would be

setting the tone for electronic public procurement globally in the years to

come.

Sujeet Bhatt and Tapan

Mehta



mail@dqindia.com


The authors are co-founders of Next Markets Group

Advertisment