session 4: eprocurement business models

<Back |Next>

E-Procurement for Improving Governance

Session 4: eProcurement

Business Models

A World Bank live e-learning event addressing the design and

implementation of e-procurement infrastructure


<Back |Next>


<Back |Next>


In this session, you will review:

• The context of eGP BM Decisions

• Understanding and analyzing risk areas

• An analysis of outsourcing options

• Designing the basic business model

• Adding risk mitigation features

• Designing pricing model

• Understanding ownership options

Topics

eProcurement Business Models

Select Next to continue

<Back |Next>


Context of eGP Business Model (BM) decisions : Scope of Reform

Institutional change

• Increased regulation – new Regulator (?)

• Centralized processing – new Operator

• Decentralized management

• Transparent costing

• Re-designed processes

Legal/Regulatory change

• Procurement law

• Code of Ethics

• E-Commerce

• Electronic signatures

• Consumer protection

• RTI – Grievance redress

Technology change

• Web-oriented SW system

• Secured processing facility

• Telecommunications

• Internet dependency

Culture change

• Intermediation of contacts

• Transparency of information/process

• Standardized procedures

• Public scrutiny


EProcurement is not just a technology problem

It involves: legal and regulatory change, culture change, changes in how the government institutions are

managed, and reforms resulting from implementing the

eProcurement technology.

<Back |Next>


Context of Business Model decisions : Scope of eProcurement System

Processing Center

Publication / Search / Disclosure Facilities

E-Tendering

Buyer/Seller Support Facilities

E-Reverse Auction

E-Catalog Purchasing

System integration/ Collaboration

Transaction FacilitiesPublic Sector

systems

Asset management

Contract management

Indent management

Financial management

Budgeting

Private Sector systems

Bid/Proposal Preparation

Catalog management

Order management

Invoicing


<Back |Next>


Context of BM decisions : Scope of eGP system

Processing Center

Publication / Search / Disclosure Facilities

E-Tendering

Buyer/Seller Support Facilities

E-Reverse Auction

E-Catalog Purchasing

System integration/ Collaboration

Transaction FacilitiesPublic Sector

systems

Asset management

Contract management

Indent management

Financial management

Budgeting

Private Sector systems

Bid/Proposal Preparation

Catalog management

Order management

Invoicing

When defining the initial scope of a system:


Limit the system scope – understand

that the initial system will not be able to fully automate all

procurement functions.

Begin with initially focusing on a smaller portion of the public

procurement activities, then expand and build

up additional capacity as you gain experience.

Think in terms of what constitutes a

practical first iteration of your eProcurement

system.

<Back |Next>


Risk analysis – Main Types of Risk in Information Systems

Tacticalsystems

Strategicsystems

Technical Business Financial

Does solution work on a

technical basis?

Will the system take root with

users?

Will system costs exceed

benefits

Lifecycle – Will system quickly

become obsolete

Will system meet user needs, or

become discredited and

abandoned

Will system costs exceed

benefits


Typical Information Systems Risk Areas

<Back |Next>


Risk Analysis for Software Technology Choices (Strategic System )


Factors:1- Complexity2- Effort3- Reliability

Factors:1- Performance2- Quality of support3- Vulnerability

Factors:1- Cost to develop2- Cost to change3- Cost to exit4- Cost to operate

Bespokedevelopment

ERP Platform

Best of Breed Package 2,3,4

1

1,2,3 1,2,3

1,2 2,3,4

2.32,3,4

1M

M+

L

H

M

L+

M

M+

L

1,2,3


<Back |Next>


Risk Analysis for Technology Outsourcing Choices (Strategic System )


Factors:1- Complexity2- Effort3- Reliability

Factors:1- Performance2- Quality of support3- Vulnerability

Factors:1- Cost to develop2- Cost to change3- Cost to exit4- Cost to operate

ASP

Cloud

BPO1, 2, 3

L

L

L+

1, 2, 3

1, 2, 3

1, 2

2, 3

M

H

H+

1, 2 2, 3, 4H

H

H+

2, 3, 4

1, 3, 4


<Back |Next>


Outsourcing eGP: An analysis

Arguments for Outsourcing Cost savings Evading unresponsive IT

function Reducing technology risk Facilitating institutional

reform and driving change Introducing business-

oriented practices Expediting CAPEX financing


<Back |Next>


Capabilities that should not be outsourced• Management of IT

• Linking IT to business

• Formulating and implementing IT strategy

• Managing contracts and partnerships

• Monitoring operations

• Managing business continuity

Arguments for Outsourcing Cost savings Evading unresponsive IT

function Reducing technology risk Facilitating institutional

reform and driving change Introducing business-

oriented practices Expediting CAPEX financing

Outsourcing eGP: An analysis


Important to balance impacts of outsourcing with challenge of maintaining a highly capable in-house IT

department

Outsourcing can lead to frustration within the in-

house departments

Even if outsourcing specific development functions,

ministry still needs highly capable IT people

It is always important to upgrade and train the

internal staff

<Back |Next>


Outsourcing Analysis: Clarification of Concepts

In-house system development is different from custom (bespoke) development

Custom development today means software development + integration of

existing tools.

Coding the software from scratch is unreasonable in eGP

In-house development means internal accountability for results, not doing everything in-house.

Software contractors are usually hired.

Outsourcing of SW development is here understood as the “Build” part of a PPP.

Select Net to continue

<Back |Next>


Cost-Risk Analysis of Outsourcing Options

Internal Cost - Outside Cost

Risk Outside – Risk Internal Risk factors

System Specification - + Poor domain knowledge

Difficult access to users

Software Development + + Loss of control over cost, time and quality of

developmentLoss of strategic knowledge

System Operation + + Vendor opportunism

Loss of control over system operationDifficult change management

Hardware maintenance + + Loss of reliability

Loss of control over disaster recovery

System evolution - + Vendor opportunism

Loss of control over change agenda

* Adapted from Jaak Jurison in “Strategic Sourcing of Information Systems”, Leslie Willcoks & Mary Lacity editors, Wiley, 1998, Chapter 6


<Back |Next>


Shared Service – A third-party e-procurement service that is fully managed, owned and operated by the third party and used by one or more governments and their suppliers.

Public Private Partnership (PPP) – A government e-procurement solution that is managed, owned and operated by a third-party service provider, often with the intent to transfer the platform back to the government in the future.

Government Owned and Operated – A government developed and operated e-procurement solution that may or may not have been delivered by third-party partners.

Government Managed Service – A government managed e-procurement solution that is operated and owned by a third-party partner.

Common eProcurement Business Models


<Back |Next>


Cost/Risk-based Outsourcing Decisions

Cost Internal > Cost-Outside

Cost Internal < Cost-Outside

Outsourcing zone

In-sourcing zone

System evolution

Hardwaremaintenance

System operation

System specification

SW development (tactical)

SW development

(strategic)

Risk Internal > Risk Outside Risk Internal < Risk Outside


<Back |Next>


Business Model design: Parties and Roles

GovernanceC = Private firm as Contractor

GovernanceP = Private firm as Partner

GovernanceS = Private firm as Supplier

Private sector

GovernanceG = Government as Principal

GovernanceB = Government as Buyer

GovernancePSP = Government as Public Service Provider

Public sector


<Back |Next>


Work Accountability

Resources

Results

Government

Partner

Government

Contractor

Partner

Financial Responsibility

Government

Supplier

Buyer

Capex

Opex

Government

Partner

Government

Partner

User Fees

General Business Model

Government

Partner

Contractor

Third Party

Ownership


<Back |Next>


Work accountability $ Responsibility

Component Results Resources CAPEX OPEX

Specification

Software Development

Operation

Expansion

G G G

G G

GG

G G G

Governance

GGovernance

G

C

CC

C

B

sFees

G

Government-Centered Business Model

C


<Back |Next>




Specification


Operation

Expansion

G G G

G G

GG

G G G

Governance

GGovernance

G

C

CC

C

B

sFees

G

Government-Centered Business Model

C


According to a May 2007 survey of MDBs, out of 14 countries:

• In 11 countries the government owns the intellectual property rights, which suggests custom development.

• 8 countries say that they do not pay a license fee for the software, but that may be because some pay licensing fess for components of the system, even though the base system is bespoke development.

• In all 14 countries the government paid for the system development.

• Only 1 country charges buying agencies for system use, while 6 countries charge suppliers for system use.

<Back |Next>




Specification


Operation

Expansion

G G G

G

P

G

P

P

G

PPP-Centered Business Model

P PP

P

P P

P P P

G GStrategic

System

PilotSystem

Bs

Fees

GG


<Back |Next>


Adding Risk mitigation features to BM

Certification requirements

Project Management

Professional standards

Reporting obligations

Contractual provisions

Formal change mgmt.

Early cancellation

Performance bond

Optional exit milestones

SLAs

Penalty clauses

Risk/revenue sharing

Fee caps

Fixed fees.

Revenue caps

Cost sharing

Revenue sharingSelect Next to continue

<Back |Next>


Designing Pricing Model

The pricing model defines how you will pay for the development effort and your private partners.

Fees should paid by whoever benefits from the system

The government benefits from increased competition, so the government should pay for elements such as

bidding fees.

Suppliers really do not benefit from bidding – they benefit from winning contracts - so

their fees should be related to contract value

Buying agencies benefit every time they use the system, so they should

pay the transaction fees.

Governments tend to pay the majority of fees, because

eProcurement systems have been shown to result in

significant savings for the government.

Supplier fees can adversely impact system adoption and use in early stages of system

development.


<Back |Next>


Designing Pricing Model

User Fees PROS CONS CONTROLS

Operational functionality (paid by G)

- Offsets start-up losses- Promotes early deployment- Spurs innovation

- Increases government's financial risk

- Cap to cover fraction of Opex

# of Participants (Paid by G)

- Promotes competition- Spurs supplier activation

- Discourages participation if paid by Suppliers

- Pay by G (as shadow fees)

# of Transactions (Paid by Purchasing units)

- Maximizes system benefits

- Penalizes O&M procurement

- Bias against activation of high value depts.

- Cap fee expenseRetain control of activation program

Contract value (paid by suppliers)

- Maximizes system benefits- Promotes demand aggregation- Cost-sharing equity

- Penalizes high value procurement- Increases government financial risk.

- Sliding % cap by slab- Cap supplier's fee expense


<Back |Next>


Ownership analysis

Application software

For risk mitigation, buy license even if outsourced solution

Retain IPR over customizations

For bespoke development, retain exclusive or shared ownership

When using FOSS, adherence to GNU license is equivalent to ownership.

Processing FacilityGovernment may own and operate when internal scale economies are large

For risk control purposes, DRS should be under G control when processing is outsourced

Data Government must always own and suitably protect the data.


<Back |Next>


eGP Business Model Decisions: Summary

Start by understanding the full context of reform required for eProcurement success.

Use results to design the business model in terms of work accountability, financial responsibility and ownership options.

Complement your business model with risk mitigation features

• If scope of initial implementation is primarily tactical, government-centered Business models are probably indicated.

• When system scope is strategic (all functions, all users), do careful cost-risk analysis of outsourcing options. This is difficult and may require inviting bids first.


<Back |Next>


• The scope for successful PPPs in eProcurement is limited and difficult - However, PPPs can facilitate institutional reform, drive change and help overcome resistance to eProcurement

• Try to structure fees as a function of the number of participants, transactions, and contract value, and have government, buyers, and sellers pay each component respectively. Evaluate other options if these do not work.

• Single-source technology solutions (ASP, Cloud, BPO) require careful, complex risk mitigation features.

All sound business model options involve Government ownership of Software, facilities and data (BOO, BOOT not recommended for eProcurement ). So be prepared to pay.

eGP Business Model Decisions: Summary


session 4: eprocurement business models

Documents

eprocurement system

eprocurement technology

governance eprocurement

basic business model

pricing model

procurement laws

regulatory context

implementation of e