Professional Documents
Culture Documents
Infrastructure project
BIDDING DOCUMENT
(SINGLE-STAGE)
Issued on: 5th May 2015
For the Integrated City Revenue Management System for Nairobi City
County
BID NO: KICTB/KTCIP/ICB/30/2014-2015
Project: Kenya Transparency & Communications Infrastructure Project
(KTCIP)
Purchaser: ICT Authority; Kenya
Pre Bid Meeting Date: May 19th 2015,
10.00 am East African Time
Closing Date: June 19th 2015, 10.00 am East African Time
CONTENTS
Section I. Instructions to Bidders (ITB) ..................................................................................6
Notes on the Instructions to Bidders (ITB) for a single-stage bidding process ..............6
Table of Clauses ..................................................................................................................7
Section II. Bid Data Sheet (BDS) ...........................................................................................47
Section III. Eligible Countries for the Provision of Goods, Works, and Services in BankFinanced Procurement ...........................................................................................................59
Notes on the Eligible Countries section ..........................................................................60
Section IV. General Conditions of Contract .........................................................................63
Notes on the General Conditions of Contract (GCC) ......................................................63
Table of Clauses ................................................................................................................64
Section V. Special Conditions of Contract (SCC) ...............................................................145
Table of Clauses ..............................................................................................................145
Section VI. Technical Requirements (including Implementation Schedule) ..................159
Section VII. Sample Forms ..................................................................................................315
Notes to the Purchaser on preparing the Sample Forms .............................................315
Notes to Bidders on working with the Sample Forms..................................................318
Table of Sample Forms ...................................................................................................322
1. This Invitation for Bids (IFB) follows the General Procurement Notice (GPN) for this
project that appeared in UNDB online on 2nd November 2007.
2. The Government of Kenya has received financing from the World Bank toward the cost
of Kenya Transparency & Communications Infrastructure Project (KTCIP). KTCIP will be
executed by the ICT Authority under the Ministry of Information and Communications.
The ICT Authority therefore intends to apply part of the proceeds to payments under the
agreement(s) resulting from this IFB: Integrated City Revenue Management System for
Nairobi City County and Transport Authority, Ministry of Transport and Infrastructure IFB
No: ICTA/KTCIP/ICB/30/2014-2015. The Government of Kenya is the recipient for the
proposed activity.
The ICT Authority serves as the implementing agency for the project and now invites sealed
bids from eligible Bidders for: Integrated City Revenue Management System for Nairobi
City County
Bidders must bid for all items. Bids quoting for incomplete items (i.e. any missing item
and/or missing required quantities) shall be considered non-responsive.
Item1: Integrated City Revenue Management System
Item2: Hardware Infrastructure for the Integrated City Revenue Management System
3. Bidding will be conducted using the International Competitive Bidding (ICB) procedures
specified in the World Banks Guidelines: Procurement under IBRD Loans and IDA
Credits, edition of IDA Credits: May 2004 (revised October, 2006), and is open to all
Bidders eligible as defined in these Guidelines, that meet the following minimum
qualification criteria:
Financial and Technical Capability
A minimum number of similar contracts specified below that have been satisfactorily and
substantially completed during the last four years:
i.
ii.
iii.
three contracts with a minimum value of US$3 million each - or the equivalent
amount in a freely convertible currency.
In order to be acceptable, these similar contracts should have incorporated supply,
installation, configuration, commissioning and maintenance of an Integrated City
Revenue Management System.
iv.
Liquidity: The Bidder shall demonstrate that is has access to, or has available, liquid
assets, lines of credit or other financial means sufficient to meet cash flow
requirements of US$3.5 million or equivalent.
v.
vi.
Submission of audited balance sheets or if not required by the law of the Bidders
country, other financial statements acceptable to the Purchaser for the last four
years.
5. Interested eligible Bidders may obtain further information from ICT Authority and inspect
the bidding documents at the address given below from 9.00 a.m. - 1.00 p.m. and 2.00
p.m.- 4.00 p.m. every day excluding weekends and public holidays. A pre-bid meeting
that potential bidders may attend will be held on May 19th 2015 at 10.00am East African
Time at the ICT Authority offices, 12th Floor Boardroom Telposta Towers, Kenyatta
Avenue Entrance, Nairobi.
6. A complete set of bidding documents in English may be obtained from the ICT Authority
Procurement Office at 12th Floor, Telposta Towers, between 9.00 a.m. 1.00 p.m. and
2.00 p.m. 4.00 p.m. Upon payment of a nonrefundable fee of Kenya Shillings (KES)
1,000/= or an equivalent amount in a freely convertible currency. The method of
payment will be in cash or bankers cheque payable to the ICT Authority. The document
may be down loaded free of charge form our website: www.icta.go.ke. Clarifications
may be obtained from email: procurement@ict.go.ke.
7. Bids must be delivered to the address below at or before: June 19th 2015. Bids need to be
secured by a bid security. The amount of Bid Security required is Kenya Shillings One
Million Five Hundred Thousand. Late bids will be rejected. Bids will be opened in the
presence of Bidders representatives who choose to attend at the address below at
10.00 a.m. East African Time on June 19th 2015 at the ICT Authority offices, (Main
Boardroom) 12th Floor Telposta Towers, Kenyatta Avenue Entrance, Nairobi.
8. The attention of prospective Bidders is drawn to (i) the fact that they will be required to
certify in their bids that all software is either covered by a valid license or was produced
by the Bidder and (ii) that violations are considered fraud, which can result in ineligibility
to be awarded World Bank-financed contracts.
9. Bids should be submitted in a plain sealed envelope clearly marked:
The Chief Executive Officer
Kenya Transparency & Communications Infrastructure Project (KTCIP)
ICT AUTHORITY,
12 FLOOR Telposta Towers- Kenyatta Avenue
P.O. BOX 27150 00100, Nairobi, Kenya
BID NO: Integrated City Revenue Management System for Nairobi City
County (REF: ICTA/KTCIP/ICB/30/2014-2015)
and placed in the Tender Box situated at ICT Authority entrance, 12th floor Telposta Towers
or mailed so as to reach the above address on or before June 19th 2015 , at 10.00am East
African Time.
Table of Clauses
A. General .................................................................................................................................9
1.
2.
3.
4.
5.
6.
7.
8.
32.
33.
34.
35.
36.
37.
38.
Instructions to Bidders
A. GENERAL
1. Scope of Bid
and Bidding
Process
2. Source of
Funds
1.1
The Purchaser named in the BDS and the SCC for GCC Clause
1.1 (b) (i), or its duly authorized Purchasing Agent if so
specified in the BDS (interchangeably referred to as the
Purchaser in these Bidding Documents), invites bids for the
supply and installation of the Information System (IS), as
briefly described in the BDS and specified in greater detail in
these Bidding Documents.
1.2
1.3
1.4
2.1
2.2
10
3.1
(ii)
In this context, any action taken by a bidder, supplier, contractor, or a sub-contractor to influence the
procurement process or contract execution for undue advantage is improper.
Another party refers to a public official acting in relation to the procurement process or contract execution].
In this context, public official includes World Bank staff and employees of other organizations taking or
reviewing procurement decisions.
A party refers to a public official; the terms benefit and obligation relate to the procurement process or
contract execution; and the act or omission is intended to influence the procurement process or contract
execution.
Parties refers to participants in the procurement process (including public officials) attempting to establish bid
prices at artificial, non competitive levels.
11
(v)
obstructive practice is
(aa) deliberately destroying, falsifying, altering or
concealing of evidence material to the
investigation or making false statements to
investigators in order to materially impede a
Bank investigation into allegations of a
corrupt, fraudulent, coercive or collusive
practice; and/or threatening, harassing or
intimidating any party to prevent it from
disclosing its knowledge of matters relevant
to the investigation or from pursuing the
investigation; or
(bb) acts intended to materially impede the
exercise of the Banks inspection and audit
rights provided for under sub-clause 3.1 (e)
below.
12
3.3
4.1
A Bidder, and all parties constituting the Bidder, may have the
nationality of any country, subject to the restrictions specified
in Section III, Eligible Countries. A Bidder shall be deemed to
have the nationality of a country if the Bidder is a citizen or is
constituted, incorporated, or registered and operates in
conformity with the provisions of the laws of that country.
4.2
4.3
(b)
13
(b)
(c)
5.1
14
6. Qualifications
of the Bidder
5.2
5.3
6.1
15
6.2
(c)
(d)
(d)
16
(f)
17
The Bidder shall bear all costs associated with the preparation
and submission of its bid, and the Purchaser will in no case be
responsible or liable for those costs.
8. Site Visit
8.1
The Bidder may wish to visit and examine the site or sites of
the Information System and obtain for itself, at its own
responsibility and risk, all information that may be necessary
for preparing the bid and entering into the Contract. The
costs of visiting the site or sites shall be at the Bidders own
expense.
8.2
The Purchaser will arrange for the Bidder and any of its
personnel or agents to gain access to the relevant site or
sites, provided that the Bidder gives the Purchaser adequate
notice of a proposed visit of at least fourteen (14) days.
18
9.1
Section II
Section III
Section IV
Section V
Section VI
Section VII
Sample Forms
19
10. Clarification of
Bidding
Documents
and Pre-bid
Meeting
11. Amendment of
Bidding
Documents
11.1 At any time prior to the deadline for submission of bids, the
Purchaser may, for any reason, whether at its own initiative
or in response to a clarification requested by a prospective
Bidder, amend the Bidding Documents. Later amendments
on the same subject modify or replace earlier ones.
11.2 Amendments will be provided in the form of Addenda to the
Bidding Documents, which will be sent in writing to all
prospective Bidders that received the Bidding Documents
from the Purchaser. Addenda will be binding on Bidders.
Bidders are required to immediately acknowledge receipt of
20
C. PREPARATION OF BIDS
12. Language of
Bid
12.1 The bid prepared by the Bidder and all correspondence and
documents related to the bid exchanged by the Bidder and
the Purchaser shall be written in the language specified in
the BDS, or, if the BDS so provides, in either one of two
languages specified there. Any printed literature furnished by
the Bidder as part of its bid may be in a language not
specified in the BDS, as long as such literature is accompanied
by a translation of its pertinent passages into the language of
the bid, in which case, for purposes of interpretation of the
bid, the translation shall govern.
13. Documents
13.1 The bid submitted by the Bidder shall comprise:
Comprising the
(a) Bid Submission Form completed and signed by a person
Bid
or persons duly authorized to bind the Bidder to the
Contract;
(b)
(c)
(d)
(e)
Attachments:
(i)
21
22
and
23
14.2 The price of items that the Bidder has left blank in the cost
tables provided in Section VII shall be assumed to be
included in the price of other items. Items omitted
altogether from the cost tables shall be assumed to be
omitted from the bid and, provided that the bid is
substantially responsive, an adjustment to the bid price will
be made during evaluation in accordance with ITB
Clause 28.6 (c) (iii).
14.3 Unit prices must be quoted at a level of detail appropriate for
calculation of any partial deliveries or partial payments under
the contract, in accordance with the Implementation
Schedule in Section VI, and with GCC and SCC Clause 12
Terms of Payment. Bidders may be required to provide a
breakdown of any composite or lump-sum items included in
the Cost Tables.
14.4 The prices for Goods components of the System are to be
expressed and shall be defined and governed in accordance
with the rules prescribed in the edition of Incoterms specified
in the BDS, and quoted in the appropriate columns of the
cost tables of Section VII as follows:
(a)
24
(c)
Inland transportation:
Unless otherwise stated in the BDS, inland
transportation, insurance and related local costs
incidental to the delivery of the Goods to the designated
Project Sites must be quoted separately as a Service
item in accordance with ITB Clause 14.5, whether the
Goods are to be supplied locally or from outside the
Purchasers country, except when these costs are
already included in the price of the Goods, as is, e.g., the
case, when ITB Clause 14.4 (a) specifies CIP, and the
named places of destination are the Project Sites.
14.5 The price of Services shall be quoted in total for each service
(where appropriate, broken down into unit prices), separated
into their local and foreign currency components. Prices
must include all taxes, duties, levies and fees whatsoever,
except only VAT or other indirect taxes, or stamp duties, that
may be assessed and/or apply in the Purchasers country
on/to the price of the Services invoiced to the Purchaser, if
the Contract is awarded. Unless otherwise specified in the
BDS, the prices must include all costs incidental to the
performance of the Services, as incurred by the Supplier, such
as travel, subsistence, office support, communications,
translation, printing of materials, etc. Costs incidental to the
delivery of the Services but incurred by the Purchaser or its
staff, or by third parties, must be included in the price only to
the extent such obligations are made explicit in these Bidding
Documents (as, e.g., a requirement for the Bidder to include
the travel and subsistence costs of trainees).
14.6 Prices for Recurrent Costs beyond the scope of warranty
services to be incurred during the Warranty Period, defined in
SCC Clause 29.4 and prices for Recurrent Costs to be incurred
during the Post-Warranty Period, defined in SCC Clause 1.1. (e)
(xii), shall be quoted as Service prices in accordance with ITB
Clause 14.5 on the Recurrent Cost Sub-Table in detail, and on
the Recurrent Cost Summary Table in currency totals.
Recurrent costs are all-inclusive of the costs of necessary
Goods such as spare parts, software license renewals, labor,
etc., needed for the continued and proper operation of the
System and, if appropriate, of the Bidders own allowance for
price increases.
14.7 Unless otherwise specified in the BDS, prices quoted by the
25
26
(b)
16. Documents
16.1 Pursuant to ITB Clause 13.1 (e) (iv), the Bidder shall furnish, as
Establishing
part of its bid, documents establishing the conformity to the
the Conformity
Bidding Documents of the Information System that the
of the
Bidder proposes to supply and install under the Contract.
Information
16.2 The documentary evidence of conformity of the Information
System to the
System to the Bidding Documents shall be in the form of
Bidding
written descriptions, literature, diagrams, certifications, and
Documents
client references, including:
(a)
27
17.1 The BDS for this Clause specifies whether bids must be
secured, and if so, whether by a Bid-Securing Declaration or
by a Bid Security. If a Bid Security is required or optional, the
BDS also specifies the amount.
17.2 Securing the bids shall be substantially in accordance with the
related sample forms included in Section VII or other forms
28
(b)
(c)
(d)
(b)
29
(d)
30
(b) in the case of the successful Bidder, if the Bidder fails to:
(i)
(ii)
18.1 Bids shall remain valid, at a minimum, for the period specified
in the BDS after the deadline date for bid submission
prescribed by the Purchaser, pursuant to ITB Clause 21. A bid
valid for a shorter period shall be rejected by the Purchaser as
non-responsive. For the convenience of Bidders, the BDS
spells out the minimal original expiration dates for the validity
of the bid and, if applicable pursuant to ITB Clause 17.1, for
securing the bid. However, Bidders are responsible for
adjusting the dates in the BDS in accordance with any
extensions to the deadline date of bid submission pursuant to
ITB Clause 21.2.
18.2 In exceptional circumstances, prior to expiry of the bid
validity period, the Purchaser may request that the Bidders
extend the period of validity for a specified additional period.
The request and the responses to the request shall be made
in writing. A Bidder may refuse the request without risking
31
32
D. SUBMISSION OF BIDS
20. Sealing and
Marking of
Bids
20.1 The Bidder shall seal the original and each copy of the bid in
separate envelopes, duly marking the envelopes as
ORIGINAL BID and COPY NO. [number]. The envelopes
shall then be sealed in an outer envelope.
20.2 The inner and outer envelopes shall
(a)
(b)
20.3 The inner envelopes shall also indicate the name and address
of the Bidder so that the bid can be returned unopened in
case it is declared late.
20.4 If the outer envelope is not sealed and marked as required by
ITB Clause 20.2 above, the Purchaser will assume no
responsibility for the bids misplacement or premature
opening. If the outer envelope discloses the Bidders identity,
the Purchaser will not guarantee the anonymity of the bid
submission, but this disclosure will not constitute grounds for
bid rejection.
21. Deadline for
Submission of
Bids
22.1 Any bid received by the Purchaser after the bid submission
deadline prescribed by the Purchaser in the BDS for ITB
Clause 21, will be rejected and returned unopened to the
Bidder.
23. Withdrawal,
23.1 The Bidder may withdraw, substitute, or modify its bid after
33
Substitution,
and
Modification
of Bids
(b)
bear the Contract name, the IFB Title and IFB Number,
and the words BID WITHDRAWAL NOTICE, BID
SUBSTITUTION NOTICE, or BID MODIFICATION NOTICE.
23.3 A notice may also be sent by electronic means such as fax or email, but in this case must include a scan of the mailing
receipt showing both the sender's and receiver's addresses
for the signed hardcopy of the notice, and a scan of the
power of attorney.
23.4 Bids requested to be withdrawn in accordance with ITB 23.1
shall be returned unopened to the Bidders. Bid withdrawal
notices received after the bid submission deadline will be
ignored, and the submitted bid will be deemed to be a validly
submitted bid.
23.5 The substitution or modification of the bid shall be prepared,
sealed, marked, and dispatched as follows:
(a)
(b)
34
35
Subsystem, lot, or slice, if the BDS for ITB Clause 28.1 permits
such discounts to be considered in the bid evaluation; and
any other such details as the Purchaser may consider
appropriate.
24.4 Bids and modifications that are not opened and read out at
bid opening shall not be considered for further evaluation,
irrespective of the circumstances. These bids, including any
bids validly withdrawn in accordance with ITB Clause 24.2, will
promptly be returned, unopened, to their Bidders.
24.5 The Purchaser will prepare minutes of the bid opening,
including the information disclosed to those present in
accordance with ITB Clause 24.3. The minutes will promptly
be distributed to all Bidders that met the deadline for
submitting bids.
25. Clarification of
Bids
26. Preliminary
26.1 The Purchaser will examine the bids to determine whether
Examination of
they are complete, whether any computational errors have
Bids
been made, whether required sureties have been furnished,
whether the documents have been properly signed, and
whether the bids are generally in order. In the case where a
prequalification process has been undertaken for the
Contract(s) for which these Bidding Documents have been
issued, the Purchaser will ensure that each bid is from a
prequalified Bidder, and in the case of a Joint Venture, that
partners and structure of the Joint Venture are unchanged
from those in the prequalification.
26.2 Arithmetical errors will be rectified on the following basis. If
there is a discrepancy between the unit price and the total
price, which is obtained by multiplying the unit price and
quantity, or between added or subtracted subtotals and
totals, the unit or subtotal price shall prevail and the total
price shall be corrected, unless in the opinion of the
Purchaser there is an obvious misplacement of the decimal
point in the unit or subtotal prices, in which case the line item
total as quoted shall govern and the unit price or sub-total
shall be corrected. If there is a discrepancy between words
36
28.1 The Purchaser will evaluate and compare the bids that have
been determined to be substantially responsive, pursuant to
ITB Clause 26. The evaluation will be performed on the basis
that the Contract will be awarded to the lowest evaluated
Bidder for the all the items in this bid.
37
(b)
Clow
T
1 X
X
C
Thigh
where
C
The bid with the highest Evaluated Bid Score (B) among
38
(ii)
39
(i)
(ii)
The score for each feature (i) within a category (j) will
be combined with the scores of features in the same
category as a weighted sum to form the Category
Technical Score using the following formula:
40
S j t ji w ji
i 1
where:
tji
wji
and
w
i 1
(f)
ji
T S j Wj
j 1
where:
Sj
Wj
and
W
j 1
28.6 The Evaluated Bid Price (C) for each responsive bid will be
determined as the sum of the Adjusted Supply and
Installation Costs (P) plus the Recurrent Costs (R);
where the Adjusted Supply and Installation Costs (P) are
determined as:
(a)
(b)
41
ITB 14.5;
(c)
(ii)
42
NM R
x
x
x 1 1 I
where
N = number of years of the Warranty Period, defined
in SCC Clause 29.4
M = number of years of the Post-Warranty Services
Period, as defined in SCC Clause 1.1.(e) (xii)
x
29. Domestic
Preference
30.1 From the time of bid opening to the time of Contract award,
if any Bidder wishes to contact the Purchaser on any matter
related to the bid, it should do so in writing.
30.2 If a Bidder tries to directly influence the Purchaser or
otherwise interfere in the bid evaluation process and the
Contract award decision, its bid may be rejected.
31.1 The Purchaser will determine at its own cost and to its
satisfaction whether the Bidder (including Joint Venture
Partners, and any Subcontractors for which the BDS for ITB
Clause 6.1 (a) permits that their qualifications count towards
the required Bidder qualifications) that is selected as having
submitted the Lowest Evaluated Bid is qualified to perform
the Contract satisfactorily, in accordance with ITB Clause 6. If
43
32.1 Subject to ITB Clause 34, the Purchaser will award the
Contract to the Bidder whose bid has been determined to be
substantially responsive and the Lowest Evaluated Bid,
provided further that the Bidder has been determined to be
qualified to perform the Contract satisfactorily, pursuant to
ITB Clause 31.
33. Purchasers
Right to Vary
Quantities at
Time of Award
(b)
44
34.1 The Purchaser reserves the right to accept or reject any bid or
to annul the bidding process and reject all bids at any time
prior to Contract award, without thereby incurring any
liability to the Bidders.
35. Notification of
Award
45
36. Signing of
Contract
37. Performance
Security
37.1 As soon as practically possible, but no more than twentyeight (28) days following receipt of notification of award
from the Purchaser, the successful Bidder shall furnish the
Performance Security in accordance with the GCC, using the
Performance Security form provided in the Bidding
Documents or another form acceptable to the Purchaser.
37.2 Failure of the successful Bidder to comply with the
requirements of ITB Clause 36 or ITB Clause 37.1 shall
constitute sufficient grounds for the annulment of the award
and, if and as applicable, execution of the Bid-Securing
Declaration or forfeiture of the Bid Security, in which event
the Purchaser may make the award to the next lowest
evaluated bid submitted by a qualified Bidder or call for new
bids.
38. Adjudicator
46
47
A. GENERAL
ITB 1.1
ITB 1.2
ITB 1.4
ITB 2.1
Bidders must bid for all items. Bids quoting for incomplete
items (i.e. any missing item and/or missing required quantities)
shall be considered non-responsive.
Alternative e-Tendering procedures are not available in this
procurement.
Name of the Borrower: Government of Kenya
48
ii.
iii.
iv.
v.
vi.
vii.
49
Manufacturer's Authorizations for Information Technologies except for those technologies which the Bidder itself
manufactures - are required for the following types/categories:
Any transition plan to hand over fully or partly the any work
that is subsequently handed over to the Subcontractor(s) in
the course of the project.
50
ITB 10.2
C. PREPARATION OF BIDS
ITB 12.1
ITB 14.1
51
ITB 14.4
Bidders must bid for all items. Bids quoting for incomplete
items (i.e. any missing item and/or missing required quantities)
shall be considered non-responsive.
The Incoterms edition is :Incoterms 2000 ICC Official Rules for
the Interpretation of Trade Terms published in 1st January 2011
by the International Chamber of Commerce, 38 Cours Albert 1er,
75008 Paris, France
For foreign goods priced on a CIP (named place of destination)
basis:
(i) The contract of carriage shall include the cost of
unloading the goods at destination, as well as
payment by the Supplier of the cost of custom
formalities, duties, taxes or other charges payable,
including Value Added Taxes (where applicable) on
the foreign Goods for their transit through any
country other than the Purchaser's country.
(ii) The named place of destination shall be the Project
Sites as indicated in Section VI-C-2.4.
(iii) Price for recurrent cost items during the warranty
period (i.e. 36 months from the date of Operational
Acceptance Certificate) shall be included with supply
& installation prices under Table 2.3 and 2.5 under
Section VII.
ITB 14.6
52
ITB 16.3
ITB 17.1
ITB 17.7
ITB 18.1
The bid validity period shall be 90 days after the deadline for bid
submission, as specified below in reference to ITB Clause 21.
Accordingly, each bid shall be valid through 17th /09/2015
Note: If Bidders have to secure bids pursuant to ITB Clause 17.1,
add:
Accordingly, a bid pursuant to ITB Clause 17.2 (f), a bid with a bid
security that expires before twenty-eight (28) days after the end
of the bid validity period i.e. 15th /10/2015 shall be rejected as nonresponsive.
ITB 19.1
53
D. SUBMISSION OF BIDS
ITB 20.2 (a)
ITB 21.1
Time, date, and place for bid opening are: Venue: ICT AUTHORITY,
12 Floor Telposta Towers Main Boardroom
Kenyatta Avenue Entrance
Date: 19th June 2015. Time: 10.00 am. East African Time (EAT)
ITB 27.1
ITB 28.1
ITB 28.4
54
Schedule.
ITB 28.6 (c) (ii)
ITB 33.1
ITB 38.1
2. Date of Birth:
3. Marital Status:
55
4. Citizenship:
Ugandan
B: Academic Qualifications
1. Ph.D. University of Southampton, England, October 1988 (UK Commonwealth
scholarship)
2. M.Sc.E University of New Brunswick, Canada, Feb 1979 (Canadian Commonwealth
scholarship)
3. B.Sc. (Eng.)
C: Personal Profile
A manager and a leader; able to work independently or as part of a team; time-conscious;
results oriented; self-motivated; quick grasp of issues; original thinker; responsive to change;
thrives on challenge; very good interpersonal skills; a good public speaker.
Internationally recognized information and communication technology (ICT) professional
with experience and strengths in: managing change; policy formulation and management;
project management from conception to implementation; ICT as a tool for development;
regulation and regulatory issues; information and communication technology (ICT)
infrastructure design and implementation.
Sociable, and socially responsible, with focus on sustainable development for the
disadvantaged and marginalised sections of society.
Driving philosophy: Be the change you want to see in the world Mahatma Gandhi
D: Professional Affiliations/Offices:
1. Fellow, Uganda Institution of Professional Engineers (UIPE) (Recipient of the UIPE
Presidential Citation of Merit for Exemplary Support of the Institution and the
Profession of Engineering 1998)
2. Member, Institution of Electrical Engineers, UK
3. Registered Engineer, Engineers Registration Board, Uganda
4. Chartered Engineer, Engineering Council, United Kingdom
E: Employment Record:
Employed by Makerere University since March 1975, conducting research, instruction, and
management, and rising through the academic levels to the current level of Associate
Professor (Telecommunications). Management levels in the university have included Head,
Department of Electrical Engineering; Associate Dean, Faculty of Technology; and Director,
Directorate for ICT Support.
1. 2001 to Oct 2007: Director, Directorate for ICT Support, Makerere University (ICT
Policy and Master Plan development; Implementation of ICT Services and Systems)
56
57
17. 1994 2000 Rainfall Characterisation and Ku Band Propagation Measurements (Part
of an ITU and EU sponsored international consortium)
18. 1993 1996 Principal Consultant (under Technology Consults Ltd.) supervising the
Installation of a Nationwide Radio Telecommunication Network for the Uganda
Revenue Authority.
19. 1993 Project Coordinator (under Technology Consults Ltd.) under the UNIDO
sponsored project: "Building Endogenous Capacity in Science and Technology".
20. 1992 2001 Propagation studies for Uganda; financed by Uganda Government
through Makerere University (initial stage). Also funded by the Government of Italy
and the Uganda Communications Commission.
21. 1992 Consultant on the Energy Sector (under Technology Consults Ltd.) under the
UNIDO sponsored project: "Building Endogenous Capacity in Science and
Technology".
G: Publications:
58
See www.fftusubira.com
H: Languages:
Language
Speaking
Writing
Reading
English
Excellent
Excellent
Excellent
Swahili
Fair
Fair
Fair
French
Poor
Poor
Poor
I: Certification:
I, the undersigned, certify that to the best of my knowledge and belief, these data correctly
describe my qualifications, my experience, and me.
Francis F Tusubira
59
60
61
Eligible Countries for the Provision of Goods, Works, and Services in BankFinanced Procurement
As of September 2007
1.
Eligible for this procurement are firms of, and goods manufactured in, all countries
except countries, if any, listed in the following restrictions.
2.
In accordance with para. 1.8 (a) of the Guidelines: Procurement under IBRD Loans
and IDA Credits, firms of a Country or goods manufactured in a Country may be excluded if
(i)
(ii)
3.
For the information of borrowers and bidders, at the present time firms, goods and
services from the following countries are excluded from this bidding:
With reference to paragraph (i) above: [ list the countries, if any, that meet the criteria
mentioned above; otherwise write: "none"]
With reference to paragraph (ii) above: [ list the countries, if any, that meet the
criteria mentioned above; otherwise write: "none"]
63
64
Table of Clauses
A. Contract and Interpretation .............................................................................................66
1.
2.
3.
4.
5.
6.
Definitions ................................................................................................................66
Contract Documents ................................................................................................75
Interpretation...........................................................................................................75
Notices ......................................................................................................................78
Governing Law .........................................................................................................79
Settlement of Disputes ............................................................................................79
C. Payment .............................................................................................................................87
11.
12.
13.
14.
Copyright ..................................................................................................................90
Software License Agreements ................................................................................91
Confidential Information .........................................................................................93
Representatives .......................................................................................................95
Project Plan ..............................................................................................................97
Subcontracting .........................................................................................................98
Design and Engineering ...........................................................................................99
Procurement, Delivery, and Transport .................................................................102
Product Upgrades ..................................................................................................104
Implementation, Installation, and Other Services ...............................................106
Inspections and Tests ............................................................................................106
Installation of the System .....................................................................................107
Commissioning and Operational Acceptance ......................................................108
32.
33.
65
66
1.1
contract elements
(i)
(ii)
(vi) Technical
Requirements
means
the
Technical Requirements Section of the Bidding
Documents.
(vii) Implementation Schedule means the
Implementation Schedule Sub-section of the
67
Technical Requirements.
viii) Contract Price means the price or prices
defined in Article 2 (Contract Price and Terms
of Payment) of the Contract Agreement.
(ix) Procurement Guidelines refers to the
edition specified in the SCC of the World Bank
Guidelines: Procurement under IBRD Loans
and IDA Credits.
(x)
(b)
entities
(i)
(ii)
68
scope
(i)
(ii)
(iii)
69
(v)
(vi)
(vii)
70
(x)
(xi)
71
Software.
(xiii) Source Code means the database
structures, dictionaries, definitions, program
source files, and any other symbolic
representations
necessary
for
the
compilation, execution, and subsequent
maintenance of the Software (typically, but
not exclusively, required for Custom
Software).
(xiv) Materials means all documentation in
printed or printable form and all instructional
and informational aides in any form
(including audio, video, and text) and on any
medium, provided to the Purchaser under the
Contract.
(xv) Standard Materials means all Materials not
specified as Custom Materials.
(xvi) Custom
Materials
means
Materials
developed by the Supplier at the Purchasers
expense under the Contract and identified as
such in Appendix 5 of the Contract Agreement
and such other Materials as the parties may
agree in writing to be Custom Materials.
Custom Materials includes Materials created
from Standard Materials.
(xvii) Intellectual Property Rights means any and
all copyright, moral rights, trademark, patent,
and other intellectual and proprietary rights,
title and interests worldwide, whether
vested, contingent, or future, including
without limitation all economic rights and all
exclusive rights to reproduce, fix, adapt,
modify, translate, create derivative works
from, extract or re-utilize data from,
manufacture, introduce into circulation,
publish, distribute, sell, license, sublicense,
transfer, rent, lease, transmit or provide
access electronically, broadcast, display,
enter into computer memory, or otherwise
use any portion or copy, in whole or in part,
72
activities
(i)
(ii)
73
(ii)
(iii)
74
Gregorian Calendar.
(viii) Year means
Months.
twelve
(12)
consecutive
75
2. Contract
Documents
2.1
3. Interpretation
3.1
Governing Language
3.1.1 All
Contract
Documents
and
related
correspondence exchanged between Purchaser
and Supplier shall be written in the language
specified in the SCC, and the Contract shall be
construed and interpreted in accordance with that
language.
3.1.2 If any of the Contract Documents or related
correspondence are prepared in a language other
than the governing language under GCC Clause 3.1.1
above, the translation of such documents into the
governing language shall prevail in matters of
interpretation. The originating party, with respect
to such documents shall bear the costs and risks of
such translation.
3.2
3.3
Headings
The headings and marginal notes in the GCC are included
for ease of reference and shall neither constitute a part
of the Contract nor affect its interpretation.
3.4
Persons
Words importing persons or parties shall include firms,
corporations, and government entities.
3.5
Incoterms
Unless inconsistent with any provision of the Contract,
the meaning of any trade term and the rights and
obligations of parties thereunder shall be as prescribed
by the current Incoterms (Incoterms 2000 or a more
recent version if and as published). Incoterms are the
76
Amendment
No amendment or other variation of the Contract shall
be effective unless it is in writing, is dated, expressly
refers to the Contract, and is signed by a duly authorized
representative of each party to the Contract.
77
78
4. Notices
4.1
4.2
4.3
79
5.1
6. Settlement of
Disputes
6.1
Adjudication
6.1.1 If any dispute of any kind whatsoever shall arise
between the Purchaser and the Supplier in
connection with or arising out of the Contract,
including without prejudice to the generality of the
foregoing, any question regarding its existence,
validity, or termination, or the operation of the
System (whether during the progress of
implementation or after its achieving Operational
Acceptance and whether before or after the
termination, abandonment, or breach of the
Contract), the parties shall seek to resolve any such
dispute by mutual consultation. If the parties fail to
resolve such a dispute by mutual consultation
within fourteen (14) days after one party has
notified the other in writing of the dispute, then, if
the Contract Agreement in Appendix 2 includes and
names an Adjudicator, the dispute shall, within
another fourteen (14) days, be referred in writing
by either party to the Adjudicator, with a copy to
the other party. If there is no Adjudicator specified
in the Contract Agreement, the mutual consultation
period stated above shall last twenty-eight (28)
days (instead of fourteen), upon expiry of which
either party may move to the notification of
arbitration pursuant to GCC Clause 6.2.1.
6.1.2 The Adjudicator shall give his or her decision in
writing to both parties within twenty-eight (28)
days of the dispute being referred to the
Adjudicator. If the Adjudicator has done so, and no
80
Arbitration
6.2.1 If
(a) the Purchaser or the Supplier is dissatisfied
with the Adjudicators decision and acts before
this decision has become final and binding
pursuant to GCC Clause 6.1.2, or
(b) the Adjudicator fails to give a decision within
the allotted time from referral of the dispute
pursuant to GCC Clause 6.1.2, and the
Purchaser or the Supplier acts within the
following fourteen (14) days, or
81
(b)
7.1
82
implementation
(including
procurement,
quality
assurance, assembly, associated site preparation,
Delivery, Pre-commissioning, Installation, Testing, and
Commissioning) of the System, in accordance with the
plans, procedures, specifications, drawings, codes, and
any other documents specified in the Contract and the
Agreed and Finalized Project Plan.
8. Time for
Commencement
and Operational
Acceptance
9. Suppliers
Responsibilities
7.2
7.3
8.1
8.2
9.1
The Supplier shall conduct all activities with due care and
diligence, in accordance with the Contract and with the
83
84
10. Purchasers
Responsibilities
85
86
10.12
87
C. PAYMENT
11. Contract Price
(b)
88
89
90
D. INTELLECTUAL PROPERTY
15. Copyright
91
be:
92
(i)
nonexclusive;
(ii)
(ii)
for
safekeeping
or
backup
93
(v)
94
the
95
96
97
98
99
100
101
102
103
insurance certificate;
104
certificate of insurance;
23. Product
Upgrades
(i)
(ii)
105
106
107
affected.
25.5 If any dispute shall arise between the parties in
connection with or caused by an inspection and/or with
regard to any component to be incorporated in the
System that cannot be settled amicably between the
parties within a reasonable period of time, either party
may invoke the process pursuant to GCC Clause 6
(Settlement of Disputes), starting with referral of the
matter to the Adjudicator in case an Adjudicator is
included and named in the Contract Agreement.
26. Installation of the 26.1 As soon as the System, or any Subsystem, has, in the
System
opinion of the Supplier, been delivered, Precommissioned, and made ready for Commissioning and
Operational Acceptance Testing in accordance with the
Technical Requirements, the SCC and the Agreed and
Finalized Project Plan, the Supplier shall so notify the
Purchaser in writing.
26.2 The Project Manager shall, within fourteen (14) days after
receipt of the Suppliers notice under GCC Clause 26.1,
either issue an Installation Certificate in the form specified
in the Sample Forms Section in the Bidding Documents,
stating that the System, or major component or
Subsystem (if Acceptance by major component or
Subsystem is specified pursuant to the SCC for GCC Clause
27.2.1), has achieved Installation by the date of the
Suppliers notice under GCC Clause 26.1, or notify the
Supplier in writing of any defects and/or deficiencies,
including, but not limited to, defects or deficiencies in the
interoperability or integration of the various components
and/or Subsystems making up the System. The Supplier
shall use all reasonable endeavors to promptly remedy
any defect and/or deficiencies that the Project Manager
has notified the Supplier of. The Supplier shall then
promptly carry out retesting of the System or Subsystem
and, when in the Suppliers opinion the System or
Subsystem is ready for Commissioning and Operational
Acceptance Testing, notify the Purchaser in writing, in
accordance with GCC Clause 26.1. The procedure set out in
this GCC Clause 26.2 shall be repeated, as necessary, until
an Installation Certificate is issued.
26.3 If the Project Manager fails to issue the Installation
108
27.1 Commissioning
27.1.1 Commissioning of the System (or Subsystem if
specified pursuant to the SCC for GCC Clause 27.2.1)
shall be commenced by the Supplier:
(a)
(b)
(c)
109
110
(b)
(c)
111
(b)
112
113
114
115
the Purchaser;
(b) normal wear and tear;
(c) use of the System with items not supplied by the
Supplier, unless otherwise identified in the Technical
Requirements, or approved by the Supplier; or
(d) modifications made to the System by the Purchaser,
or a third party, not approved by the Supplier.
29.7 The Suppliers obligations under this GCC Clause 29 shall
not apply to:
(a) any materials that are normally consumed in operation
or have a normal life shorter than the Warranty Period;
or
(b) any designs, specifications, or other data designed,
supplied, or specified by or on behalf of the Purchaser
or any matters for which the Supplier has disclaimed
responsibility, in accordance with GCC Clause 21.1.2.
29.8 The Purchaser shall give the Supplier a notice promptly
following the discovery of such defect, stating the nature
of any such defect together with all available evidence.
The Purchaser shall afford all reasonable opportunity for
the Supplier to inspect any such defect. The Purchaser
shall afford the Supplier all necessary access to the
System and the site to enable the Supplier to perform its
obligations under this GCC Clause 29.
29.9 The Supplier may, with the consent of the Purchaser,
remove from the site any Information Technologies and
other Goods that are defective, if the nature of the defect,
and/or any damage to the System caused by the defect, is
such that repairs cannot be expeditiously carried out at
the site. If the repair, replacement, or making good is of
such a character that it may affect the efficiency of the
System, the Purchaser may give the Supplier notice
requiring that tests of the defective part be made by the
Supplier immediately upon completion of such remedial
work, whereupon the Supplier shall carry out such tests.
If such part fails the tests, the Supplier shall carry out
further repair, replacement, or making good (as the case
may be) until that part of the System passes such tests.
116
117
118
(b)
(c)
32.2 Such indemnity shall not cover any use of the System,
including the Materials, other than for the purpose
indicated by or to be reasonably inferred from the
Contract, any infringement resulting from the use of the
System, or any products of the System produced thereby
in association or combination with any other goods or
services not supplied by the Supplier, where the
infringement arises because of such association or
combination and not because of use of the System in its
own right.
32.3 Such indemnities shall also not apply if any claim of
infringement:
(a)
119
120
(b)
121
(b)
G. RISK DISTRIBUTION
34. Transfer of
Ownership
35.1 The Purchaser shall become responsible for the care and
custody of the System or Subsystems upon their Delivery.
The Purchaser shall make good at its own cost any loss or
122
123
124
has so failed to notify the Purchaser within the twentyeight (28) day period, the Purchaser shall make no
admission that may be prejudicial to the defense of any
such proceedings or claim. The Purchaser shall, at the
Suppliers request, afford all available assistance to the
Supplier in conducting such proceedings or claim and shall
be reimbursed by the Supplier for all reasonable expenses
incurred in so doing.
36.4 The Purchaser shall indemnify and hold harmless the
Supplier and its employees, officers, and Subcontractors
from any and all losses, liabilities, and costs (including
losses, liabilities, and costs incurred in defending a claim
alleging such a liability) that the Supplier or its employees,
officers, or Subcontractors may suffer as a result of the
death or personal injury of any person or loss of or
damage to property of the Purchaser, other than the
System not yet achieving Operational Acceptance, that is
caused by fire, explosion, or any other perils, in excess of
the amount recoverable from insurances procured under
GCC Clause 37 (Insurances), provided that such fire,
explosion, or other perils were not caused by any act or
failure of the Supplier.
36.5 If any proceedings are brought or any claim is made
against the Supplier that might subject the Purchaser to
liability under GCC Clause 36.4, the Supplier shall promptly
give the Purchaser notice of such proceedings or claims,
and the Purchaser may at its own expense and in the
Suppliers name conduct such proceedings or claim and
any negotiations for the settlement of any such
proceedings or claim. If the Purchaser fails to notify the
Supplier within twenty-eight (28) days after receipt of
such notice that it intends to conduct any such
proceedings or claim, then the Supplier shall be free to
conduct the same on its own behalf. Unless the
Purchaser has so failed to notify the Supplier within the
twenty-eight (28) days, the Supplier shall make no
admission that may be prejudicial to the defense of any
such proceedings or claim. The Supplier shall, at the
Purchasers request, afford all available assistance to the
Purchaser in conducting such proceedings or claim and
shall be reimbursed by the Purchaser for all reasonable
expenses incurred in so doing.
125
37.1 The Supplier shall at its expense take out and maintain in
effect, or cause to be taken out and maintained in effect,
during the performance of the Contract, the insurance set
forth below. The identity of the insurers and the form of
the policies shall be subject to the approval of the
Purchaser, who should not unreasonably withhold such
approval.
(a)
126
127
(b)
rebellion,
revolution,
insurrection,
mutiny,
usurpation of civil or military government,
conspiracy, riot, civil commotion, and terrorist acts;
(c)
confiscation,
nationalization,
mobilization,
commandeering or requisition by or under the order
of any government or de jure or de facto authority
or ruler, or any other act or failure to act of any local
state or national government authority;
(d)
(e)
(f)
128
(b)
129
39.1.2
130
131
132
133
134
41.1.2
135
(ii)
(iii) deliver
to
the
Purchaser
all
nonproprietary drawings, specifications,
and other documents prepared by the
Supplier or its Subcontractors as of the
date of termination in connection with
the System.
41.1.3
136
137
(i)
(ii)
(iii)
obstructive practice is
(aa) deliberately destroying, falsifying,
altering or concealing of evidence
material to the investigation or
making false statements to
investigators in order to materially
impede a Bank investigation into
allegations of a corrupt, fraudulent,
coercive or collusive practice;
and/or threatening, harassing or
intimidating any party to prevent it
Another party refers to a public official acting in relation to the procurement process or contract execution].
In this context, public official includes World Bank staff and employees of other organizations taking or
reviewing procurement decisions.
A party refers to a public official; the terms benefit and obligation relate to the procurement process or
contract execution; and the act or omission is intended to influence the procurement process or contract
execution.
Parties refers to participants in the procurement process (including public officials) attempting to establish bid
prices at artificial, non competitive levels.
138
If the Supplier:
(a) has abandoned or repudiated the Contract;
(b) has without valid reason failed to commence
work on the System promptly;
(c) persistently fails to execute the Contract in
accordance with the Contract or persistently
neglects to carry out its obligations under the
Contract without just cause;
(d) refuses or is unable to provide sufficient
Materials, Services, or labor to execute and
complete the System in the manner specified
in the Agreed and Finalized Project Plan
furnished under GCC Clause 19 at rates of
progress that give reasonable assurance to
the Purchaser that the Supplier can attain
Operational Acceptance of the System by the
Time for Achieving Operational Acceptance as
extended;
then the Purchaser may, without prejudice to any
other rights it may possess under the Contract,
give a notice to the Supplier stating the nature of
the default and requiring the Supplier to remedy
the same. If the Supplier fails to remedy or to
take steps to remedy the same within fourteen
(14) days of its receipt of such notice, then the
Purchaser may terminate the Contract forthwith
by giving a notice of termination to the Supplier
that refers to this GCC Clause 41.2.
41.2.3
139
41.2.5
140
If:
(a) the Purchaser has failed to pay the Supplier
any sum due under the Contract within the
specified period, has failed to approve any
invoice or supporting documents without just
cause pursuant to the SCC, or commits a
substantial breach of the Contract, the
Supplier may give a notice to the Purchaser
that requires payment of such sum, with
interest on this sum as stipulated in GCC
Clause 12.3, requires approval of such invoice
or supporting documents, or specifies the
breach and requires the Purchaser to remedy
the same, as the case may be. If the Purchaser
fails to pay such sum together with such
interest, fails to approve such invoice or
141
41.3.3
142
immediately:
(a) cease all further work, except for such work as
may be necessary for the purpose of
protecting that part of the System already
executed, or any work required to leave the
site in a clean and safe condition;
(b) terminate all subcontracts, except those to be
assigned to the Purchaser pursuant to
Clause 41.3.3 (d) (ii);
(c) remove all Suppliers Equipment from the site
and repatriate the Suppliers and its
Subcontractors personnel from the site.
(d) In addition, the Supplier, subject to the
payment specified in GCC Clause 41.3.4, shall:
(i)
(ii)
143
42.l Neither the Purchaser nor the Supplier shall, without the
express prior written consent of the other, assign to any
third party the Contract or any part thereof, or any right,
benefit, obligation, or interest therein or thereunder,
except that the Supplier shall be entitled to assign either
absolutely or by way of charge any monies due and
payable to it or that may become due and payable to it
under the Contract.
145
C. Payment ...........................................................................................................................149
11.
12.
13.
14.
146
31.
32.
33.
147
The Contract shall continue in force until the Information System and
all the Services have been provided unless the Contract is terminated
earlier in accordance with the terms set out in the Contract.
2.
GCC 2
Applicable
148
3.
GCC 3.1.1
4.
GCC 4.3
5.
GCC 5.1
6.
GCC 6.1.4
GCC 6.2.3
149
8.
GCC 8.1
GCC 8.2
9.
GCC 9.9
10.
GCC 10.12
C. PAYMENT
11.
GCC 11.2 (b)
30 days
150
12.
GCC 12.1
Ten (10) percent of the Total Training Cost upon signing the
Contract, and submission of an accepted training programme
ii.
151
GCC 12.4
For Goods and Services supplied locally, the Purchaser will pay the
Supplier in the currency stated in the Contract Agreement and the
Price Schedules it refers to.
GCC 12.5
13.
GCC 13.2.1
GCC 13.2.2
GCC 13.3.1
GCC 13.3.4
14.
GCC 14.4
D. INTELLECTUAL PROPERTY
15.
GCC 15.3
152
GCC 15.5
16.
GCC 16.1 (b) (vii) In addition to the persons specified in GCC Clause 16.1 (b) (vi), the
Software may be disclosed to, and reproduced for use by, employees
of the Purchaser subject to the same restrictions as are set forth in
this Contract.
GCC 16.2
17.
GCC 17.1
153
The provisions of this GCC Clause 17 shall survive the termination, for
whatever reason, of the Contract for the period specified in the GCC
GCC 18.1
GCC 18.2.2
19.
GCC 19.1
(b)
(c)
Training Plan
(d)
(e)
(f)
(g)
(h)
Within thirty (30) days from the Effective Date of the Contract, the
Supplier shall present a Project Plan to the Purchaser. The Purchaser
shall, within fourteen (14) days of receipt of the Project Plan, notify
the Supplier of any respects in which it considers that the Project Plan
154
(ii)
20.
GCC 20
21.
GCC 21.2
155
The Supplier shall prepare and furnish to the Project Manager the
following documents for which the Supplier must obtain the Project
Managers approval before proceeding with work on the System or
any Subsystem covered by the documents:
22.
(*)
(*)
GCC 22.4.3
GCC 22.5
The Supplier shall provide the Purchaser with shipping and other
documents as specified in the GCC.
23.
GCC 23.4
The Supplier shall provide the Purchaser: with all new versions,
releases, and updates to all Standard Software during the Warranty
Period, for free, as specified in the GCC
24.
GCC 24
25.
GCC 25
26.
GCC 26
27.
GCC 27.2.1
156
GCC 28.2
GCC 28.3
29.
GCC 29.1
The Supplier warrants that the following items have been released to
the market for the following specific minimum time periods: No specific
minimum time requirements are established for this Contract other than
that the Information Technologies must have been previously released to
the market
GCC 29.4
GCC 29.10
During the Warranty Period, the Supplier must commence the work
necessary to remedy defects or damage within 1 working day of
notification.
30.
GCC 30
31.
GCC 31
157
32.
GCC 32
33.
GCC 33
G. RISK DISTRIBUTION
34.
GCC 34
35.
GCC 35
36.
GCC 36
37.
GCC 37.1 (c)
158
38.
GCC 38
40. Extension of Time for Achieving Operational Acceptance (GCC Clause 40)
GCC 40
41.
GCC 41
42.
GCC 42
159
160
161
TECHNICAL REQUIREMENTS
A. BACKGROUND
0.1 The Purchaser
0.1.1
The ICT Authority was established as a State Corporation under the State
Corporations Act Cap. 446. ICT Authority was founded with the aim of
coordinating and promoting the ICT industry in Kenya. The ICT Authority
also seeks to promote ICT investments both locally and abroad.
0.1.2
162
to
IT
The overall objective of the ICRMS is to automate the revenue management cycle
from assessment, recognition, collection and accounting. Through the ICRMS,
NCC expects to have a single view of the citizen to drive the principles of service
delivery described above. Through the single view of the citizen, services will be
aggregated per each service line and be made conveniently accessible to the NCC
and the citizen as illustrated by the diagram below;
Term
IFMIS AP
IFMIS AR
BABOK
BPM
BPR
IFMIS CE
ERP
ESB
Ethernet
ETL
IFMIS FA
FIFO
GB
GIS
IFMIS GL
GoK
GUI
HDD
Hz
ICRMS
IEEE
IFMIS
IFMIS INV
IFMIS PO
IPRS
IVR
JMS
KB
KES
kVA
LAIFOMS
LAN
LED
LIFO
MB
MTBF
Explanation
IFMIS Accounts Payable Module
IFMIS Accounts Receivable Module
Business Analysis Body of Knowledge
Business Process Management
Business Process Reengineering
IFMIS Cash Management Module
Enterprise Resource Planning
Enterprise Service Bus
IEEE 802.3 Standard LAN protocol
Extraction Translation and Loading
IFMIS Fixed Assets Module
First In First Out
Gigabyte
Geographic Information System
IFMIS General Ledger Module
Government of Kenya
Graphical User Interface
Hard Disk Drive
Hertz (cycles per second)
Integrated City Revenue Management System
Institute of Electrical and Electronics Engineers
GoK Integrated Financial Management Information
System
IFMIS Inventory Module
IFMIS Purchasing Module
Integrated Person Registration System
Interactive Voice Recognition
Java Messaging Services
Kilobyte
Kenya Shillings
Kilovolt ampere
Local Authorities Integrated Financial Operations
Management System
Local area network
Light Emitting Diode
Last In First Out
Megabyte
Mean time between failures
163
164
NCC
NIC
NOS
PC
PDF
RAID
RAM
RISC
RPM
SAN
SATA
SCSI
SNMP
SOA
SSH
SSL
TB
TCP/IP
UAT
USB
V
VLAN
VPN
WAN
XML
165
B. OVERVIEW OF REQUIREMENTS
1.0
NCC Departments
Requirements take into consideration the following lines of services that bring revenue
to the NCC.
Department
Role
FINANCE
AND Responsible for the following areas:
ECONOMIC PLANNING Economic, Fiscal and Monetary
Accounting Services
Fisheries
HEALTH SERVICES
Veterinary services
profession)
(excluding
regulation
Ambulance services
of
the
166
EDUCATION, YOUTH
AFFAIRS, CULTURE,
CHILDREN AND
SOCIAL SERVICES
PUBLIC WORKS,
ROADS AND
TRANSPORT
Liquor licensing.
Racing
Cinemas
Libraries
Museums
County roads
Street lighting
PUBLIC
SERVICE Responsible for the following areas:
MANAGEMENT
Public Service Management and Development Policy
Performance
Innovations
Management
and
Public
Service
TRADE,
INDUSTRIALIZATION,
COOPERATIVE
DEVELOPMENT,
TOURISM
AND
WILDLIFE
LANDS, HOUSING
AND PHYSICAL
PLANNING
Procurement Services
Legal services
167
Markets
Local tourism
Cooperative societies.
Housing
City Planning
WATER,
ENERGY, Responsible for the following areas:
FORESTRY,
Implementation of national government policies on
ENVIRONMENT AND
natural resources and environmental conservation,
NATURAL
including--soil and water conservation - forestry.
RESOURCES
Refuse removal, refuse dumps and solid waste disposal
INFORMATION,
COMMUNICATION
AND EGOVERNMENT
2.0
Energy regulation
County e-government
Public participation
County branding
For clarity and guidance, the following are the critical revenue areas that must be
considered in scope for this project.
168
3.0
Each of the listed revenue streams above has got business rules that involve workflow
process to fulfill the service to the citizen. NCC expects that the selected bidder shall
spend the initial phase of the project gathering, rationalizing and developing use-cases to
be signed off by the NCC as part of requirements gathering before the customizations
are made. The requirements gathering process shall be driven by the vendors Business
169
Analyst(s) who will work closely with NCC Functional Users for each of the department
that will be impacted by the design of the named revenue sources. The NCC shall avail
the Functional Users required for this exercise as shall be determined by the project
schedule which the vendor will have prepared and communicated in advance.
4.0
Functional Architecture
The citizen will access county services through Service Request Channels, currently
identified as NCC Portal, eCitizen Portal and County Offices. The electronic channels
will give the citizen ability to initiate service requests by themselves while the physical
channels will broker the service request on behalf of the citizen by processing the
request from a manually completed hard copy document that is submitted to and
entered by the County office.
The service request will go through a workflow process. Workflow processes will be
unique and shall be defined for each of the services as listed Section 2.0 Key
Revenue Streams. The flow diagram above gives the generic flow of a request.
170
The ICRMS (responsible for Revenue Management) will receive, validate and
generate bills for billable services. ICRMS will receive payment from Payment
Channels (Jambo Pay, Debit Card, Credit Card, Cash, Direct Debit, RTGS, Mobile
Money). It should be noted that for existing services such as property rates and
single business permits that require renewal, there should be capacity for the system
to generate a bill on its own, without the citizen applying initiating the process (this is
illustrated in the red arrow of the envisaged diagram).
The ICRMS will update the service account of the requestor acknowledging payment
and activating the service for which payment has been made.
The ICRMS will perform account reconciliation with the bank to tie up what is in the
bank and what is in the system.
The ICRMS will receive revenue feeds from Feeder Systems (Ad Manager, Building
Permits, and Hospital System) for consolidation.
The ICRMS will send a consolidated feed to the Centralized Accounting System
(IFMIS) for consolidation and centralized reporting.
5.0
Types of Users
Citizens The end consumer of services provided by the County. Citizens will
access the ICRMS through channels like eCitizen Portal and NCC Portal.
NCC Functional Users The NCC staff who will provide services to citizens. They
will be a cross functional team from the various departments as described in
Section B: Overview of Requirements. They will perform the bulk of
transactional activities in the ICRMS.
NCC Executive Users The executive management of NCC including the
Governor, the deputy Governor and the county executive. These users will
access the system for queries, extraction of reports and to perform approvals.
NCC Technical Users The NCC IT team. Their role will be maintenance of the
system including access rights management, service maintenance, performing
backups, resolving issues raised by the NCC functional users, and acting as
liaison for vendor risk and issue escalations.
171
C. TECHNICAL SPECIFICATIONS
2.0 GENERAL TECHNICAL REQUIREMENTS
2.0.1
This section articulates the requirements for a robust user interface, flexible and
extensible workflows, open standards integration, and agile technical architecture.
1. Web-based and Mobile devices-based solution to allow users to log in from
any internet ready device and supporting standard web browsers including
but not limited to Internet Explorer, Mozilla, as well as standard operating
system for mobile devices etc.
2. The system shall have the availability to allow customization and
personalization of GUI by NCC e.g. creation of top 10 list of functions, reordering the notification work list etc.
3. Ability to access reports and workflow notifications via mobile devices e.g.
Android, Apple, Windows etc.
4. Ability to support multi-currency support: System should allow
transactions to be done in different currencies
5. Ability of the system to import or export data in industry standard formats
such as XML, CSV etc. for user mass data load
6. Ability of the system to allow display of data from external systems via
frames or ports, etc., in a context-sensitive manner via secure web APIs
e.g. viewing of GIS information from the GIS system once it is available.
7. Ability to support multiple counties / government / county agencies on the
platform but with proper access controls to meet confidentiality and
constitutional requirements. The user interface must contain a link back to
central government and respective county systems once these services
become available on the eCitizen Portal.
8. Availability of visual modeling tools (in a workbench) to enable intuitive
modeling of business processes with features such as check-in and checkout support of multi-user modeling environment.
9. Capability to perform process simulation before actual deployment of the
process for use.
10. Ability to easily create data entry forms and user-interfaces (screens) for
any future processes to aid NCC users in defining new workflows that may
not be envisioned in the scope of this implementation.
11. Ability to utilize NCC defined approval hierarchy to set up approvals within
process workflow. These definitions shall be developed as part of use case
development in the Requirements Definition phase of the project as
described in Section F on implementation plan.
172
173
26. Ability to enable outbound SOA-based integrations e.g. sending out status
of Business Permit Application based on a query by an external system like
the NCC Portal, eCitizen Portal
27. The system shall provide a module to archive data / messages after a
number of predefined days from date of creation of data
28. The database administrator will be able to easily set media, timing and
cycle for data archiving by setting parameters from a user interface
29. The archiving module will maintain an index of archived data.
30. The archiving module will provide an easy to use interface for selecting and
restoring archived data
31. The database servers shall include redundancy and support high availability
mechanisms to allow for data recovery and instant restoration in case of
failure respectively.
32. Ability to read information that is external to the system's native database
e.g. from another transactional system (e.g. NCC Portal or Jambo Pay) via
BPM / SOA platform
33. The Bidder shall ensure that its recommended hardware solutions perform
optimally with the software solution as expected and warranted. This
responsibility shall be based on signed off successful load / capacity testing
that is accepted by the County for current and identified future
environment characteristics. (Refer to section H sub section 4 on
infrastructure considerations.)
34. The Bidders proposal must describe the methodology used for sizing the
proposed solution server computing platforms, whether for Web,
application or database servers. Refer to section H sub section 4 on
infrastructure considerations.
35. The Bidder must include a description of any necessary server clustering
technology for the proposed solution platform architecture, specifying
load balancing, performance scaling and hot switchover technologies for
the processor and memory. (Refer to section H sub section 4 on
infrastructure considerations.)
36. The server operating system must be a high performance server operating
system that supports a multi-user environment. (Refer to section H sub
section 4 on infrastructure considerations)
37. It is expected that the application software will use a relational data base
management system (RDBMS). (Refer to section H sub section 4 on
infrastructure considerations.)
38. The Bidder should indicate which of the RDBMS engines (type and version)
is the recommended or preferred platform and why. Refer to section H sub
section 4 on infrastructure considerations.
39. It is expected that referential integrity will be enforced at the RDBMS level.
174
40. It is expected that the RDBMS has adequate features to aid in the data
recovery process (backup, rollback and recovery). (Refer to section H sub
section 4 on infrastructure considerations.)
41. The bidder shall describe the requirements for the following environments:
(Refer to section H sub section 4 on infrastructure considerations.)
Development
QA / Testing
Production
42. Describing the configuration for each and justification for storage, memory
and processing capacity.
43. The bidder shall describe the component movement (release
management) methodology from Development-> QA / Test -> Production
showing how version control is managed. (Refer to section H sub section
4 on infrastructure considerations.)
175
the
interfaces
with
other
Monthly: System.
(SANS) Institute
Technology (NIST).
176
10. The system platform shall provide a staging/deposit area with strictly
controlled access for third parties to deposit interface data. The data shall
be validated on the staging server before being imported on base system.
Refer to Section H sub-section 3 for illustration of the staging area.
11. It shall be possible to perform all remote operation and maintenance tasks
via encrypted protocols (e.g. ssh, ssl).
12. The system must provide a mechanism to authenticate any remote user
(i.e. verification of network address, dial back mode, etc.).
13. The system shall provide an access control mechanism to be able to show
which data entities / transactions any particular individuals may read,
modify, execute, approve, reject, suspend, reassign (given a user ID) and
conversely, which data entities any particular individuals may read, modify,
execute.
14. The system shall provide the capability to create different access control
levels (i.e. admin, developer, end-user) according to roles that are defined
by the NCC
15. The system shall provide the capability to further add or restrict menu and
submenu options for individual users. Ideally, it shall be based on a policy
where by default no one is allowed to access anything, unless explicitly
permitted so. Users modes of access shall be set accordingly to include
read, write, execute, create, delete etc
16. The system shall use encrypted connections (e.g. SSL v.3) for services that
transfer sensitive (e.g. financial) data. All security sensitive information and
especially personal data shall be stored encrypted or with the appropriate
protection mechanisms. The transmission of this data shall be done in
secure way (e.g. via encrypted protocol, i.e. VPN with SSL v.3).
17. All passwords stored in the system shall be appropriately encrypted.
18. The passwords used or required for the administration and for the
operation of the platform shall NOT appear in plain text in any file, or
database.
19. Interfaces/Protocols should provide encryption and authentication, to
commercial best-practice standards, where the interfaces are exposed
outside the security domain and for administrative access.
20. All used encryption methods and algorithms shall conform to standards
and use the latest versions of cryptographic libraries.
21. The encryption solution must generate strong encryption keys based on
industry-tested and accepted algorithms, along with strong key lengths
and proper key-management practices. Examples of industry-tested and
accepted standards and algorithms for encryption include;
177
22. The encryption solution must distribute keys securely, meaning the keys
are distributed only to authorized NCC custodians as shall be defined by
the County security policy. The keys must NOT be distributed in the clear.
23. The encryption solution must store keys securely, for example, by
encrypting them with a key encrypting key.
24. The system shall provide for access control to cryptographic keys using the
County-defined security policy.
25. The system must NOT store the personal identification number (PIN) or
the encrypted PIN block. Storage means, in any or all of the following
forms:
History files
Trace files
Database contents.
26. After successful authorization, the system must NOT store card verification
code or value (three-digit or four-digit number printed on the front or back
of a payment card). Storage means in any or all of the following forms:
History files
Trace files
Database contents.
27. PAN must be masked when displayed such that only NCC Users with a
legitimate business need (as shall be determined by the County in the
security policy) shall have full view of the PAN.
28. The system shall store secret and private keys used to encrypt/decrypt
cardholder data in one (or more) of the following forms at all times:
29. Encrypted with a key-encrypting key that is at least as strong as the dataencrypting key, and that is stored separately from the data encrypting key
30. Within a secure cryptographic device (such as a host security module
(HSM) or PTS-approved point-of-interaction device)
178
179
System logs
Database logs.
52. System logs shall NOT be deleted even by a system administrator. It shall
be possible for logging to be stored in separate server controlled by
another administrator as defined in the County security policy.
53. Security log files shall be protected against manual modification even by
the super user. The methods applied have to be described. Access to audit
logs shall be safeguarded to prevent any possible misuse or compromise
(i.e. access limited to authorized personnel only through specific
application or system tools).
54. Access to the logging system and data shall be restricted to privileged
accounts and user profiles (e.g. root, system administrator)
55. The system shall provide the capability to detect multiple logons (including
geo-location based logons) from the same user ID and restrict users to one
session at a time.
56. The number of unsuccessful log-on attempts shall be limited to, at most,
three attempts per session; afterwards the session will be terminated.
57. For a given user ID, after a set number of continuous unsuccessful log-on
attempts (from different sessions) the account shall be time-locked
suspended. (e.g. 2 sessions * 3 incorrect logons for each session = max 6
trials). The temporary suspension action shall be documented in a log file.
180
58. A notice shall be displayed indicating that only authorized users are
allowed access to the system in accordance with any legal/corporate
obligations.
59. Users shall be required to enter their passwords (after a certain period of
inactivity / time-out to be defined and configured centrally) before the
session can be re-started.
60. All components shall be used in the latest version with all security patches /
service packs applied.
61. The supplier shall provide a mechanism to inform the system custodian
regularly about relevant security updates and patches. This includes
custom product components as well as integrated third party components.
62. Security log files shall be protected against manual modification even by
the super user. The methods applied shall be described
63. Access to audit logs shall be safeguarded to prevent any possible misuse or
compromise (i.e. access limited to authorized personnel only through
specific application or system tools).
64. The system shall be able to set maximum size of audit logs. When the file
gets full, it shall either switch to a second file or overwrite itself AFTER
proper back-up has automatically taken place.
65. The system shall provide the capability to export audit logs into Database
or Word-processing formats.
66. A configurable automated process shall be implemented to send log files
or defined logged event to a security log server.
67. The system shall provide audit trails on different software layers (OS,
database, application) allowing a tight control of accessed functions and
information.
68. The system shall provide the means to detect and alarm unauthorized or
improper use of the system.
69. The system shall provide for mechanisms to protect the system against
attacks (use with improper data or malicious code, overload, blocking of
accounts, denial of service, brute force...) shall be described and include
how the system restricts access during an attack or system failure. Such
mechanisms include but not limited to use of CAPTCHA to distinguish
HUMAN from MACHINE interaction.
70. The bidder shall describe a back-up plan. The plan shall showing the
frequency (daily, weekly, monthly), scope (incremental, full, etc.) and
restore process that shall be tested and signed off by NCC. The back-up
plan shall cover the following four types of data:
Applications
Operating System
181
Data (the data specific to each part of the system that is susceptible
to being modified frequently)
Log (the set of traces on what is made on/from each part of the
system).
182
Registration Module
This section articulates the requirements that fulfill the envisioned process of onboarding
a citizen in the ICRMS for billable and non-billable services. All services will have a service
account associated with them and the service account will be associated with a citizen or
an entity (business or organization). Refer to the single-view concept in part A of the
background of requirements.
1. The system should provide users with ability to capture citizen / entity details that
are workflow initiated by eCitizen Portal, NCC Portal or Jambo Pay and activate
the citizen account in the revenue management system (It should be easy to
classify between individuals and corporates at registration and upon saving the
record in the system)
2. The system should provide users with ability to associate an entity (e.g. business
or individual) with the revenue categories applicable to the entity as shall be
configured in the revenue services module for purposes of determining the fees
applicable to that category of entity and the frequency of collection.
3. The system should have the ability to fulfill service requests (initiated by NCC
Portal, Jambo Pay or eCitizen) for account activation (e.g. business permit
request) by generating the account for revenue or non-revenue based service and
associating the account with the citizen profile. The system should have the ability
to manually create a citizen / entity account (e.g. business permit application)
directly in the ICRMS.
4. The system should have the ability to create citizen / entity accounts in mass using
secure data transport mechanisms either from excel file or directly from
LAIFOMS. This data import process should be provided as an automated process
or a user-driven process with proper controls against duplication and integrity of
existing data.
5. Ability to update selected citizen details (such as contacts) that are workflow
initiated by the eCitizen Portal or NCC Portal and update the respective record in
the ICRMS
6. Ability to fulfill eCitizen Portal and NCC Portal initiated service request for account
update (e.g. payment preferences, day / month of billing) by updating the service
account for revenue or non-revenue based service
7. Ability to manually update a citizen / entity service account (e.g. change of billing
rules) in the ICRMS through a workflow process.
8. Ability to suspend any service account when such an account is under
investigation and freezing any fulfillment request lodged by the citizen through
eCitizen Portal or NCC Portal
9. Ability to deactivate any service account when the service is delivered and there
are no more pending or outstanding collections on that account e.g. expiry of
leases that are not renewed or vacation of a market stall by the entity / citizen
183
10. The system should give NCC staff the capability to search or look up an entity
based on any criteria stored in the entity record (e.g. Name, Identifier, Creation
Date, Entity Type) based on their access rights to such records.
11. The system should maintain the uniqueness of a citizen / entity account based on
a unique identifier. For individuals this unique identifier is the citizen identification
as contained in the IPRS system. Citizen registration process for individuals shall
be authenticated by the IPRS system as described in Section H, sub section 2
Integration Touch Points. For entities, the unique identifier shall be taxpayer
identification number as provided by the national tax authority, KRA. This is to
safeguard against multiple registrations by the same individual / entity and to
maintain a single consistent view of the citizen.
184
2.1.2
This section articulates the requirements that fulfill the definition of revenue services for
accounting purposes. The unique characteristics of services and the associated
accounting ledger codes.
1. The system should allow the capture of revenue generating assets (as an interface
with the IFMS FA module) - Classification coding of what is a revenue generating
assets required. Refer to the integration requirements and standards in Section H,
sub section 2 Integration Touch Points
2. The system should be able to define various categories of billable services such as
(Permits, Licenses, Fees, Charges)
3. The system should allow the association of the imported asset with the revenue
services offered within that asset e.g. A building owned by the county could have
housing units that bring revenue through leases
4. The system should share general ledger codes with the (IFMIS) for each of the
billable service as described in Section H, sub section 2 Integration Touch Points
5. The system should provide multiple parameters for setup of rating rules per each
billable service (e.g. Single Business Permit may have parameters for type of
business e.g. large, medium, small or location, etc.). These parameters may be
amended routinely. The system shall provide for ability to make amendments on
these parameters as per the legislation passed by NCC following the necessary
workflow process and safeguarding the integrity of existing open transactions
associated with the parameters that are subject to change.
6. The system should be flexible in allowing deactivation of any asset that either has
been retired or disposed and no longer in use to generate revenue. The
deactivation should take into account any active subscriptions by citizens for that
service that havent been processed for billing.
7. The system should be flexible in allowing deactivation of billable service defined
when such need arises (e.g. when a service is retired or no longer offered). The
deactivation should take into account any unprocessed service requests that
reference that billable service
8. The system should be flexible in allowing deactivation of a parameter or
parameters for a particular billable service defined when such need arises (e.g. a
certain fee or charge within the business permit service is retired or no longer
offered). The deactivation should take into account any unprocessed service
requests that reference that billable service
9. The system should be flexible in allowing of grouping of related services into a
single workflow process that branches out to specific services for fulfillment
within the main workflow e.g. grouping the single business permit application
process and health permit for food handling business
10. The system should be flexible in allowing definition of multiple payment methods
for the billable services to be exposed to citizens. These payment methods must
185
be plugged into the payment aggregators who the county government has / will
sign agreements with for payment collection (e.g. Cash, Direct Debit, Mobile
Payments, ATMs, Credit Card, Debit Card, Agencies). These methods should be
visible to citizen facing portals (Jambo Pay, NCC Portal and eCitizen Portal)
11. The system should be flexible in allowing deactivation of payment methods for
the billable services as and when the county deems the payment method no
longer suitable. All unprocessed transactions linked to the payment method must
process to completion before the payment method is deactivated.
12. The system should provide for definition of transaction numbering types for
various revenue streams and associate those transaction numbering types with
the various revenue services.
13. The system should provide for definition of transaction numbering sequences
(defined in requirement number 13 above in this section) associated with
document types for various revenue streams. The document sequences should
have effective start and end dates. Transaction numbering types should be
associated with one or many transaction numbering sequences but only one
document sequence should be active for a particular document type. The county
should have the ability to generate physical hard copy print using the same
sequence or maintain the electronic version in correspondence with the citizen.
186
2.1.3
This section articulates the requirements that fulfill the definition of non-revenue services
for accounting purposes. The unique characteristics of services and the associated
accounting ledger codes.
1. The system should allow the capture of non-revenue generating assets (through
an external Asset Management System) - Classification coding of what is a nonrevenue generating assets required
2. The system should be able to define various categories of non-billable services
such as (Dog Permits etc.)
3. The system should allow the association of the imported asset with the nonrevenue services offered within that asset (e.g. Recreational parks, etc.)
4. The system should be flexible enough to cascade the non-billable service
(including amendments) to other upstream systems (like the web portal) so that
they are visible to the citizen
5. The system should be flexible in allowing deactivation of any asset that either has
been retired or disposed and no longer in use.
6. The system should be flexible in allowing deactivation of non-billable service
defined when such need arises (e.g. when a service is retired or no longer
offered).
7. The system should be flexible in allowing suspension of non-billable service
defined when such need arises (e.g. to prevent citizens from accessing the service
when it is undergoing revision of business rules associated with it).
187
188
13. The system should have the ability to add a new parcel to the property history
data for respective citizen / entity account.
14. The system should have the ability to record sufficient property address
information to include such items as location, street, etc. that is linked to the GIS
system for geo location
15. The system should have the ability to maintain complete, integrated parcel history
for all splits and mergers of parcels of land
16. The system should have the ability to maintain property ownership history when
two or more parcels are combined into one parcel
17. The system should have the ability to maintain original parcel ID on new parcels
created from mergers or splits.
18. The system should allow the option of moving all pertinent data automatically to
the appropriate parcel.
19. The system should have the ability to keep a history record when the current legal
owner of a property changes.
20. The system should have the ability to record multiple transfers of a single parcel.
21. The system should have the ability to maintain property ownership history when a
parcel is split into two or more parcels.
22. The system should have the ability to maintain property ownership history when a
parcel is retired.
23. The system should have the ability to set effective dates for ownership
information changes.
24. The system should have the ability to search the property history database by a
variety of methods such as current owner, previous parcel number, previous
owner, address (these search criteria should be easily configurable by the NCC
user based on the property history)
25. The system should have the ability to generate a bill automatically for rates due
and notify the land owner.
189
2.1.5
This section articulates the requirements that fulfill citizen services on property
management (sell or lease).
The system should have the ability to:
1. Import property in the IFMIS FA module and generate or inherit a unique
reference number for property acquisitions (either through build or buy process).
The reference number shall be used to track all payments in the IFMIS AP module.
Section H, sub section 2 Integration Touch Points
2. Define lease types based on the various rental rules (available in the County and
to be configured in the system) and payment schedules per each lease type
3. Capture the basic details of the property like;
Address
4. Generate vacant units and their details and the lease types to invite bidders to
apply for tenancy
5. Have a tenancy lifecycle management capability from processing of applications
for rental housing, to prequalification and award, signing of leases and
maintenance of tenant in the property (on boarding and exit)
6. Automatically generate rental billings based on the type of lease and send
notifications in advance to the tenants (using the contact information in the
REGISTRATION module) to demand payment when it falls due
7. Generate alerts and notifications to tenants where property is earmarked for
repairs as dictated by the maintenance schedule from the Maintenance module
whose requirements are described in the requirements for service maintenance.
8. Capture charges and penalties levied against the tenant and collection of such
charges in the collections module
9. Update tenant accounts and notify / confirm to tenant when payment has been
made upon settlement of rental due - through the collections module- based on
billing cycles.
10. Generate a pre-sale plan for the disposal of property based upon the asset
disposal management decision by the county executive.
11. Generate an RFP for the sale of its property. The RFP should at the minimum have
the following parameters;
190
12. Capture details of the Sale Agreement and link the agreement with the document
management system that is currently under implementation. The bidder should
demonstrate how the ICRMS would associate content from a document
management system using industry standard protocols with the property on sale
on the GUI.
13. Assign a transaction reference number to track the disposal of property
14. Schedule a payment structure for the disposal of property
15. Allow other departments like legal to make comments on a specific disposal and
also trigger the of release title documents for property in a work flow
16. Generate a bill for the buyer to make payment which is recorded in the Collections
module
17. Trigger disposal of the property in the IFMIS asset register.
191
192
12. The system should have the ability to view and print all forms for a business license
account and all related accounts from a single display screen or printed report.
13. The system should have the ability to display the business license information based
on a pre-defined search criteria taking into account access control for public and
private information as shall be determined by the County.
14. The system should have the ability to display delinquent accounts to county
enforcement officers when querying a business account.
15. The system should have the ability to track the compliance of each business with
approvals necessary from the county based on the type of license.
16. The system should have the ability to interface with the revenue collection module
(requirements in section 10.0) for purposes of recognizing and updating account
status for settled payments or outstanding billings.
17. The system should have the ability to capture account status for each license based
on the configurable status types e.g. Expired, Renewed etc.
18. The system should have the ability to link to, import and display information from the
property record including but not limited to Current assessed value; Square footage;
and Ownership history.
19. The system should have the ability to automate the classification process based on a
series of yes or no answers to questions or key word identifiers.
20. The system should have the ability to expose the classification rules to eCitizen Portal,
Jambo Pay and NCC Portal that initiates the classification process and submits the
request to the ICRMS for fulfillment and computation of license fees.
21. The system should have the ability to allow for a check-list of application
requirements based on business type or category, which must be satisfied as part of
the application and licensing process (e.g., Customer may be required to provide
health permits, zoning approvals, contractor has passed exam(s), etc.). Attached
documents should be stored in a repository that is associated to the application
record.
22. The system should have the ability to allow the check-list to be updated as needed, by
County staff having appropriate security/permissions.
23. The system should have the ability to allow the County's Citizens to apply and pay for
Business License Applications via E-Citizen portal, and in doing so, provides security
measures to protect customers data and assure data confidentiality.
24. The system should have the ability to alert business owners/contractors when
applying online for a business license, that County required forms, data are missing.
25. The system should have the ability to allow the County's citizens to re-new and pay a
Business License via a citizen portal, and in doing so, provides security measures to
protect customers data and assure data confidentiality.
26. The system should have the ability to print a bill for a license fee due without issuing
the license.
193
27. The system should have the ability to generate a batch of billing information that will
be sent to print.
28. The system should have the ability to generate a bill automatically for renewal against
all license holders and notify them of the renewal due.
29. The system should have the ability to apply a late filing penalty based on configurable
penalty rules.
30. The system should have the ability to apply a late payment penalty.
31. The system should have the ability to apply a county-defined administrative fee for
the management of delinquent accounts.
32. The system should have the ability to calculate and apply interest on delinquent
accounts based upon County defined parameters.
194
2.1.7
This section articulates the requirements that fulfill citizen services on various fees and
charges as described in Section A subsection 2.0 for list of key revenue streams.
1. The system should have the ability to define facilities (assets) - pulling the information
from the asset management system in IFMIS - and associate them with fees
chargeable for use of those facilities. E.g. Set up of Cemeteries and classifying
charges based on size etc., Set up of Parking bays and locations and classifying them
accordingly and allocating the fees chargeable, setting up of public utility grounds like
parks and setting parameters for chargeable services, setting up of stadiums and
setting up the charges for the different tiers / terraces.
2. The system should be able to set up fees and charges types for various ad hoc
requests with respective pre-requisite checklist, attachments definition where
required and audit trail information. An example would be AD HOC REQUEST FOR
BURIAL PERMIT SHOULD HAVE RULES THAT REQUIRE A DEATH CERTIFICATE ETC AS
PRE-REQUISITES FOR THE APPLICATION PROCESS. These fees and charges are based
on the NCC Finance Act and a list of the key ones has been highlighted in Section A
subsection 2.0 for list of key revenue streams.
3. The system should keep a trail of changes to the configuration of those fees and
charges showing who created, when, who updated,
4. The system should be able to process ad hoc applications for permits (these are
permits that are not pre-determined e.g. burial permit for deaths etc. The list of such
adhoc requests will be discussed during the BPR process) applying the pre-requisite
check list rules in the process. The submission of request should have options where
it can be submitted online via NCC Portal, eCitizen Portal or in the back end processed
by a County officer. The system must keep an audit trail of the application process at
various stages of the workflow showing what action was taken, by who and when.
5. The system should be able to cascade the ad hoc request to the billing and collection
module for payment collection.
6. The system should be able to refresh the ad hoc request upon payment confirmation
from the collections module and allow the permit to be generated and sent to the
requester via various channels e.g. email or downloaded from the citizen portal by
the registered requestor or collected from the County Office nearest to the
requestor.
7. The system should be able to accept and process ad hoc payments for parking linked
to the facilities configured and validated by the charge rates defined.
8. The system should be able to accept and process periodic payments for long term
parking linked to the facilities configured and validated by the charge rates defined.
This process should create an account in the registration module for purposes of
single view of the entity.
9. The system should provide subsequent rules within the main rules for certain services
like parking. For example in setting up the facility called public parking and the
195
associated fees, there should be penalties where parking fees are not paid each
classified within the facility such as Clamping charges and towing charges.
10. The system should provide a mechanism to book in a car that has been clamped and
towed. Details of the car should be captured in the booking.
11. The system should provide a mechanism to process ad hoc requests for payment of
parking fees, clamping charges and towing charges where such cases arise and
cascade the processing of that request to the collection module for update of the
request status.
12. The system should provide a mechanism that once the clamping, parking and towing
charges have been settled, an alert is sent to the officer asking for unclamping and
releasing the car from the yard and updating the clamping book in the system
accordingly.
13. The system should be able to accept and process ad hoc payments for market stalls
linked to the facilities configured and validated by the charge rates defined.
14. The system should be able to accept and process periodic payments for market stalls
linked to the facilities configured and validated by the charge rates defined. This
process should create an account in the registration module for purposes of single
view of the entity.
15. The system should be able to accept and process ad hoc payments for stadium seats
linked to the facilities configured and validated by the charge rates defined.
16. The system should be able to accept and process periodic payments for stadium seats
linked to the facilities configured and validated by the charge rates defined. This
process should create an account in the registration module for purposes of single
view of the entity.
17. The system should have the ability to process request for collection of fines for
offences committed by accused citizens. The offences should be pulled from the case
management module
18. The system should have the ability to process request for collection of fees for
ambulance services offered. The details of the service should be linked to the fleet
management module
19. The system should have the ability to process request for collection of fees for use of
grounds in the public parks for meetings. The details of park and respective fees
should be pulled from the configuration information of the facility.
196
Garbage Trucks
Towing Trucks
2. The system should record and assign a job and route for vehicle. The job should have
unique reference number e.g. Ambulance service for patient transfer. The request
may be initiated via NCC Portal, eCitizen Portal or directly entered in the system
3. The system should provide ability to assign a vehicle to a driver capturing driver
name, driving license number, contact information like phone, email for contact in
case of an assignment or preventive maintenance alerts.
4. Upon confirmation and release of vehicle, the system should have the ability to
generate a dispatch document(s) for the driver. . By interfacing with a contracted 3rd
party vehicle tracking system, the system should be able to record the time of
departure from site. The dispatch document should contain:
Dispatch Date
Vehicle Number
Driver Name
Service description
Billing address
Billing contact
5. The system should be able to record the route, fuel, kilometers and link it to the
Dispatch note number generated in requirement number 4 above in this section.
6. The system should generate route completion note signed by the driver linking it to
the Dispatch note number generated in requirement number 4 above in this section,
and the job closed in the system.
197
7. The system should enable capture of the cost of running fleet in delivering services
using various metrics e.g. consumption per KM, Mile. Average distance before tyres
wears out etc. The costs of running should be configurable to indicate whether they
are to be borne by the citizen or not for ease of administration by the NCC users.
8. System capture insurance details against each fleet showing the policy number,
insurance company, policy start and end date and have the ability to generate a
notification to NCC officers in charge of renewals, within a configurable lead time, to
initiate process of insurance renewal.
9. The system should process electronic information (through an integration with the
IFMIS AP system) from service providers for settlement of bills due e.g. Fuel and
other service providers that give the county Fuel Cards for fuelling the fleet of
vehicles which keeps a log of the fuel-top ups and sends a periodic electronic file for
settlement by the county.
10. The system should provide the ability to interface with a 3rd party vehicle tracking
system to be contracted.
11. The system should have the ability to query fleet information using a set of
parameters such as:
Job Route
Registration Number
Driver Name
Job Number
Jobs Summary
Vehicle Summary
Maintenance History
198
199
200
13. The system should provide account balances per citizen across multiple revenue
streams e.g., Rates, single business permits, rents, markets, parking, advertisements,
development control etc.
14. The system should provide a mechanism to pull fees and charges via an interface
from other County revenue systems like E-Construction Permit System, the Hospital
System, the Mortuary System, and process those payments and send back updates to
the respective systems of collected fees. (Refer to Section H subsection 1 for List of
Systems and Section A subsection 2.0 for list of key revenue streams)
15. The system should provide a period end process cycle to close periods and transfer
billings and collections to the IFMIS AR module through an interface as described in
Section H subsection 2 Integration Touch Points
16. The system should provide a view of citizen receipts by bank range, customer range,
receipt status, transaction type, date range, year and period range, and receipt
number range. Access to the view should be restricted as per NCC security policy.
201
202
Property register
Accounts in Arrears
Adjustment list
3. Provide a full Market research and portfolio analysis, and also the hold/sell analysis
reports
4. Provide analysis off a dashboard of the various comparisons between economic rate
of return and the market rate of the property
5. Generate forms such as tenancy registration form using the preconfigured
information for various types of tenancies
6. Generate of listing of properties by type e.g. Houses, Stalls etc.
7. Generate of statements for various types of rental properties e.g. Houses, Stalls
8. Generate of Listing of arrears for rent due
9. Easily generate a listing of filing forms (e.g., businesses that have filed a business
license) as shall be determined by the County.
10. Use machine-readable technology to read renewal forms with preprinted account
number, and license type.
11. Print licenses and license renewal applications via mass mailings, e-mail, and
individual in-house print based on county-defined criteria.
12. Generate a file that contains all business license renewal information and business
license certificate information that will be sent to a print vendor or printed in-house.
13. Flag accounts for inconsistencies, reporting discrepancies, and/or the suggestion to
audit such account.
203
14. Identify associated additional records (when a business is closed to) that should also
be reviewed. (For example, a citizen that has multiple business licenses that also need
to be reviewed as well.)
15. Generate updated business lists and distribute via mail or Internet to interested
entities.
16. Display geographic locations for all business license accounts utilizing Geographic
Information System (GIS) functionality.
17. Produce a list of registered businesses
18. Produce a list of Business Activity Code as defined in the setups
19. Provide an account status analysis by preconfigured parameters such as zone / ward
20. Generate a penalty table for various license categories configured in the system
21. Produce a list of inactive businesses
22. Produce forms for registration of businesses for various permits as an alternate to
online registration.
23. Extract a Jobs Summary report
24. Provide a Vehicle Summary report
25. Provide a report on the cost of running the vehicle fleet.
26. Provide Maintenance History report
27. Produce a Days Collection Outstanding" report by service line and ward / zone to
identify trends and performance. Refer to List of Services in Section A Sub-section 2.0
28. Provide Invoice reports based on different parameters for example, Customer, Date
range etc.
29. Provide receipt reports based on different parameters for example, Customer, Date
range etc.
30. Generate Customer Statements showing aged debt analysis as well as the billing and
receipt history.
31. Allow citizens to generate their statement of account via a web portal that is securely
accessible based on the login credentials for registered citizens.
32. Send statements and invoices to customer's billing address, customer's e-mail
address, or contact's e-mail address or for the customer to download the statement
directly from the web portal accessible based on secure login credentials for
registered citizens.
33. Provide a Cashier Analysis Report by various parameters such as:
Cashier Name / Cashier Name Range - Showing Collection activities per Cashier
Receipt Date / Date Range Showing collection activities per selected day
204
Revenue line / range of revenue lines Showing collection activates per select
revenue line or range
Asset / range of assets showing collection activities per select asset / range
of assets
205
54. Provide drill down capabilities directly via the graphical display e.g. click on a location
on a map to get a breakdown of revenue or click on a section of a pie chart to get a
detailed breakdown.
55. Provide end user with easily navigable visualization from text-based display to
graphical display of the data
56. Show end users various configurations on a report e.g. current active filters, hidden
section, sorting etc.
57. Support ad hoc queries. Use of queries to generate ad hoc reports should only be
restricted to authorized users as shall be defined in the County access matrix
58. Provide pre-built dashboards that can be easily configured to meet specific
requirements. Examples include; revenue performance, tracking actual revenue
against target, tracking collection achievement against target set per sector / revenue
stream, tracking list of top sources
59. Intuitive, user-friendly on-demand querying and report generation
60. Schedule various reports to be generated at certain times and delivered via various
mechanisms
61. Support report delivery via various messaging platforms such as email, text-based
etc.
62. Provide County users with options to subscribe to various reports that have been
availed for subscription (based on the County user access rights that shall be defined)
without the need of intervention from the system administrator
63. Provide County users with options to schedule their own reports
64. Provide County users with options to determine the format they would like to receive
reports in e.g. Excel, pdf etc.
65. Provide county users with options to customize their page layout including the
following:
Favorite reports: This will provide a shortcut to the Favorite reports without
the need for the user to dig through all the accessible reports
66. Categorization of reports based on various criteria e.g. the kind of data that a report
provides. The system should allow the user to define his/her own categories and add
desired reports into these categories
67. Search capabilities to allow user to search for various items such as report, subject
area, field etc.
206
Project Plan
The bidder should provide a detailed project plan with achievable timelines and
responsibilities upon contract award and at least 2 weeks prior to commencement
of the project. The project plan shall be signed off by NCC. (See section F on
indicative implementation schedule).
Note: The NCC is the process of procuring services for build of a data center. There is a
likelihood that the ICRMS project may start before the data center project is
completed. Bidders are advised that NCC has taken measures to source for an interim
location to co-locate its infrastructure within a government facility until the data
center project is completed. Therefore there is a likelihood that this assignment will
use the interim solution to be provided by the NCC. The winning bidder will have the
chance to inspect the selected facility as part of discovery of the operating
environment of NCC. The bidder is expected to migrate the solution to the NCC data
centre once the build is complete, therefore the bidder is expected to provide (in this
bid) for the plan, effort and cost required to migrate the solution from the interim
data center to the primary data center.
207
DOMAIN
ROLE
RESPONSIBILITY
STEERING
COMMITTEE
208
DOMAIN
ROLE
RESPONSIBILITY
PROJECT
MANAGEMENT
OFFICE
Implementation.
Communicate
project
progress
to
various stakeholders;
Identify
and
manage
risks
and
Manage
and
control
the
project
budget; and
through
the
Project
Director.
PROJECT
EXECUTION
representatives
TEAM
departments.
from
various
DOMAIN
209
ROLE
RESPONSIBILITY
have been assigned.
provide
implementation
suitable
team
as
mapping,
Section
2.2.3
on
Implementation.
training
validation,
to
configuration,
ensure
successful
accountable
Management
to
Team
the
on
Project
the
tasks
Relevant and adequate training aligned to NCC training requirements and types of
staff to be trained (Refer to sections B sub-sections 5).
210
the expected involvement of NCC staff and other 3rd party interface service
providers. (Refer to Section E - Testing and Quality Assurance)
4. The bidder should describe the approach to quality assurance of the solution and
how it is aligned to the desired target architecture in accordance with the guidance
provided in Section E - Testing and Quality Assurance
5. The bidder should describe the approach to perming product support immediately
after going live and thereafter. The approach must identify the resources required,
the people involved the types of calls expected and what the bidder expects the
county to do to make this happen. The bidder must take into consideration the
existing investment in IT support by the county. (Refer to Section E sub section 3.2
on Support Process)
6. The bidder shall describe the time allocation per resource showing what is to be
done, by whom, when and for how long and the validation that such task has been
done within the planned time. This shall be in a structure that can be measured and
assessed during implementation.
7. The bidder shall describe approach to risk management showing how risk is
identified, recorded, communicated, mitigated and monitored throughout the
project
8. The bidder shall describe the approach to change management showing what would
be impacted by change, suggesting ways of seamlessly transition without disrupting
the operations of the county. NCC shall be responsible for implementing change.
9. The bidder shall provide a detailed approach to data conversion that describes the
data to be considered for migration, the extraction, the validation, the cleansing, the
loading and the verification process. The bidder shall at best propose best practice
approaches to data conversion based on the experience in prior implementations.
The County would like to understand how the bidder will approach developing the
data conversion plan, and what processes will be undertaken by the bidders project
team to convert existing data as well as to interface with identified source systems.
A conversion schedule should identify;
Planned conversion steps,
Estimated hours;
What resources will be required (by County or bidder)
10. The bidder is expected to assist the County in the conversion of both electronic and
paper-based data to the new system. (Refer to Section C sub-section 2.3 on for data
migration)
11. Project reporting must be in form of a monthly report and a quarterly summary
progress report showing:
Results accomplished during the prior period;
Cumulative deviations to date from schedule of progress milestones as
specified in the Agreed and Finalized Project Plan;
211
212
23. Bidder staffing must have a Project Manager with the following qualifications:
24. Bidder staffing must have a Business Analyst(s) with the following qualifications:
25. Bidder staffing must have a Developer (s) and / or Configuration Expert(s) and / or
Integration Architect and / or Quality Tester with the following qualifications:
26. Bidder staffing must have a Trainer(s) with the following qualifications:
213
27. Bidder staffing must have a System Administrator / Database Administrator / System
Architect with the following qualifications:
28. Bidder provide at least 3 sites where a similar implementation was done with the
following details for each site.
Customer Name:
Customer Location:
Contact Person:
Contact Address:
Email Address:
Telephone Number:
29. Bidder describe for each site, how any or all of these modules were implemented
including any specific customizations, reports, workflows and technologies used
Registration
214
Land Rates
Licenses
Fleet Management
Case Management
Collections Management
Service Maintenance
Reports
Security
30. Bidder describe for each site, describe the hardware architecture, showing any form
of clustering, high availability configuration, backup setups, operating system and
the databases as well as the linkage with a disaster recovery site (if any)
31. For each of the reference site quoted, the bidder must describe what resources
where used in the assignment, their skillsets and if they are currently still working
for your organization.
215
The extraction criteria must be verified and approved and pre-tested by the County to
confirm the adequacy of transactional and setup data in supporting operations after
go-live.
The ETL process must go through several iterations with sign off before actual
migration to the production environment. At a minimum, the county expects 3
iterations as follows;
o Iteration 1 on the development environment to test the scripts and
identify key areas of cleansing
o Iteration 2 on the test environment to provide data for testing and also
to test the migration process and prepare the migration run book.
o Iteration 3 on the production environment upon successful sign off of
iteration 2 as part of UAT.
DATA SUBJECT
DESCRIPTION
CURRENT SYSTEM
Active Citizen /
Entity Accounts
LAIFOMS, Manual
LAIFOMS
LAIFOMS
Revenue generating assets for the services listed LAIFOMS, IFMIS FA,
in Section B subsection 2.0 for list of key Manual Sources
revenue streams.
Defects List
216
Active
Accounts
Bank All active accounts used by the county for IFMIS, LAIFOMS
collection of payments for services listed in
2.5 TRAINING
The bidder should provide a curriculum of training for the various categories of NCC users
of the system as described in sub section 9 types of users. The indicative number of
those to be trained is 25 NCC Functional Users, 10 NCC Technical Users and 20 NCC
Executive Users. These estimates have been provided to enable the vendor give an
indication of training costs for evaluation purposes, this number is expected to change
and shall be determined with certainty once a training needs analysis is conducted during
the Implementation Phase.
A training plan which shall contain;
The training course / syllabus
The training audience (based on types of users)
The learning objectives
The mode of training i.e. instructor-led, computer based training or e-learning
The duration
Any special conditions to fulfill the training like (training room, desks,
connectivity, computers etc.) Note that this is important so that the Purchaser
can make arrangements to fulfill such conditions in time before the actual
training.
The training shall be should be conducted as practical exercise. Labs and simulations
should be emphasized.
217
The bidder will demonstrate how to evaluate the evidence of the training undertaken by
the trainee. The NCC shall independently verify that training was conducted as part of
acceptance of the training deliverable.
218
For upgrades, licenses the bidder should explain how they shall cover the following:
Bug fixing This is any hindrance of normal operation of the system for components that
are out of the box.
Enhancement This is slight change of requirement that was not part of initial signed off
requirement but not a complete change of the original requirement.
Upgrade This is significant change by the manufacturer of the version of the application
or select module(s).
Sandbox testing The ability to test upgrades in a controlled environment to evaluate
impact of change in terms of duration, cost and resources required.
Backward compatibility The ability to support lower versions after upgrades where
NCC opts not to immediately take up the newer releases of the system.
Product roadmap The vendor shall provide the envisioned upgrade roadmap of the
product in the next five (5) years.
The basis of licensing should be broken down as guided below;
Tier
ONE OFF
LICENCES
YEAR 1
YEAR 2
YEAR 3
YEAR 4
YEAR 5
Web Tier
Application Tier
Database Tier
Other Tools and
Utilities
2.7 WARRANTY
Warranty Terms
The vendor will maintain and support the signed off and fully accepted ICRMS within a
three (3) year warranty period.
The preconditions for operational acceptance by NCC are based on the following;
219
Bug fixing;
Upgrades;
Patches; and
For extensions and customization, the bidder must provide mechanisms and standards
that allow for upgrades to the system without loss of customized features and/or
functionality.
Maintenance
The target range of maintenance shall include all the proposed devices / materials
including hardware and software (including any mobile applications, integration
works to third party systems and mobile devices)
Free maintenance period shall be 12 months after the completion of local validation
and acceptance. Any items that are found to have any defect during the same period
shall be replaced or repaired at no charge. Thereafter, NCC expects to enter into a
maintenance contract (the terms of the contract must be supplied in the bid showing
how the vendor shall charge for maintenance)
Equipment manufacturers shall certify the maintenance capacity of the Bidder for all
major equipment during the free maintenance period. If this requirement cannot be
met, other proper measures shall be proposed.
The Bidder shall conduct regular inspections (monthly in the first year then quarterly
thereafter) and maintenance work for any detected error.
220
The Bidder shall clearly describe in the proposal how it will guarantee maintenance
along with a maintenance plan.
The Bidder shall state how to respond to specific situations that may occur during the
free maintenance period (e.g. replacement of broken equipment).
The Bidder shall specify how to provide sufficient maintenance for all the proposed
hardware and software, which shall be detailed by each category. As for maintenance
work that incurs a charge, its price conditions should all be explained.
Bidder shall submit its proposal with the assumption that all maintenance will be
performed locally.
Technical Support
The Bidder shall deliver verbal and written information and technical advice about the
equipment / software during the construction and maintenance period.
The Bidder shall offer and carry out a detailed technology transfer plan for system
installation and operation.
Installation, upgrading, maintenance support for server software, server OS and any
other system software
Undertake day to day system administration services required at the O/S and
application layer for the development, test and production environment
Design and implement user management processes for the creation, amendment and
deletion of end user profiles and accounts
Monitor system operation including CPU and memory usage and performance tuning
to ensure agreed SLAs are adhered to
Identify, troubleshoot and resolve system faults to ensure agreed SLAs are adhered
to
221
Database Support
Taking regular system back-ups and data backups as per the prescribed procedure in
tape drives/CDs/DVDs/hard disks at the local level as well as the centralized level
Installation, upgrading and maintenance of the ICRMS system hand held devices
issued to traffic police, motor vehicle inspectors or other mobile devices connected
to the ICRMS system
Support the LAN(s), including switch and router maintenance, across all NCC offices
using the ICRMS system
Provide training and handholding to end users on correct use of the ICRMS system
and its associated equipment - PCs, peripheral devices and hand held enforcement
devices
Replenish consumables
222
Maintain user manuals including updating them for any changes to the ICRMS system
or NCC processes
2.8 DOCUMENTATION
In the course of implementation the following documents shall be expected at each
stage of delivery. These documents much be signed off by NCC as usable.
STAGE
DOCUMENT
REQUIREMENTS DEFINITION
Functional Requirements
Integration Requirements
Testing Requirements
SOLUTION DESIGN
Functional design
Integration Design
Infrastructure Design
SOLUTION DEVELOPMENT
Customizations
SOLUTION TESTING
TRAINING
Functional NCC User Training
223
224
In order for the county to accept the system as usable, the following tests shall be
conducted;
System Integration Testing (SIT) This shall be the first level of testing by the
technical teams to ensure that the configured / developed system ready for UAT. The
tests to be conducted will be quality checks on the logic and confirmation of the
technical soundness of the system before hand over to the NCC users for functional
testing.
User Acceptance Testing (UAT) This shall be the next level of testing to validate the
ability of the developed / configured system to fulfill the requirements of NCC as
detailed in the signed off functional requirements and design documents. The bidder
is expected to provide test scripts, which NCC will validate and sign off before
actually executing the tests.
Load / Performance Testing This test shall be performed on the configured
production environment prior to going live as a validation of the ability of the system
to handle increase in volume of transactions given the various metrics that shall be
provided by the county such as peak times, key revenue areas, frequently used
services etc.
At, a minimum, the NCC expects the follow as the acceptance criteria on performance
Item
Home Page Load Time
Range
15 seconds maximum on 56k modem with 350ms
latency
3 seconds maximum on High Speed Network
25 seconds maximum on 56k modem with 350ms
latency.
5 seconds maximum on High Speed Network.
5 seconds maximum on 56k modem with 300ms
latency.
10 seconds maximum on 56k modem with
350ms latency.
NCC expects the system to be generally available
at 99.5% of availability. This time excludes any: 1)
NCC mandated time for hardware, software or
network maintenance and upgrades; and 2) any
unplanned outages in hardware, NCC provisioned
software (OS, database) or network.
The system is expected to be used for providing
citizen services to residents of Nairobi County
including government agencies with low
226
Business Continuity
Data Migration Testing This test shall be performed within the iteration 2 of data
migration to confirm that the extraction and loading scripts perform accurately as
defined in the data extraction criteria. This shall be verified through reconciliation
reports from source and target systems for the various subject areas of data
identified for migration. This test shall be conducted on data a migration instance
(which could be a re-used environment from existing instances other than production
environment)
3.2
SUPPORT PROCESS
SERVICE REQUEST
An issue will be raised via Service Request, which at a minimum will contain the
following:
Issue Number:
Issue Date
Raised By
Issue Description
SEVERITY ASSESSMENT
The vendor will be expected to review and categorize the issue as illustrated below. The
following severity levels have been given as guidelines:
S1 Critical Business Impact (Production Impacting)
This severity is reserved for production environments and applies to situations where
business operations are halted due to the crash, hang, or failure of the custom
component in performing as expected. An example of this would be inability to complete
service fulfillment due to failure of a workflow.
The indicative response and resolution times are as illustrated in the table below:
Priority
Response Time
Work Around
Resolution Time
S1 Critical
Business Impact
(Production
Impacting)
1 Business Day
2 working hours
228
S2 Major
Business Impact
5 working hours
4 Business Days
8 working hours
7 Business Days
12 working hours
10 Business Days
S3 Minimal
Business Impact
S4 No Business
Impact
ISSUE LIFECYCLE
NCC expects the issues submitted to vendor technical support follow the illustrated flow
shown below. The vendor may suggest alternate flow as long as it addresses NCC
concern of rapid response and resolution.
1. Acceptance and Acknowledgement. Upon submission of an issue, technical
support will acknowledge the Service Request within 1 hour of submission.
2. Initial Assessment. Vendor shall analyze and validate the Service Request, scope
and request for additional information if necessary to progress the issue. During
the initial assessment, a hypothesis will be developed along with an action plan
that will be executed in order to confirm the hypothesis.
3. Investigation and Diagnosis. This step shall be a detailed discovery of the issue
that may involve running scripts, replicating the situation in a test or development
platform and collection of vital information to provide an accurate diagnosis.
4. Recovery. For high severity cases (S1, S2), the vendor will focus on recovery, or
restoring the business to normal operations. A work around may be provided as
a means of recovery.
5. Resolution. This step shall involve the delivery of the final solution, be it a patch,
workaround, or set of action steps. For low severity issues, resolution may include
Level 1 Support shall be responsible for diagnostic routines as first line support. First
line support tasks are meant to isolate physical faults; operational issues etc. Some of
the activities of first line support will be the following:
Recording faults;
Deeper troubleshooting;
230
SUPPORT
LEVEL
First 3 Months
Next 3 Months
NCC- Led
(On-site vendor
shadowing)
NCC Led
Level 1
Level 2
Onsite Vendor
NCC Led
Level 3
Vendor
Vendor
Vendor
Escalation Procedures
The vendor shall describe how a fault shall be logged and the escalation procured for
unresolved issues guided by the following illustration;
Priority
Escalation Step I
To be attended
Escalation Step II
If not resolved
S1
Who (individual or
team) should
immediately be
contacted?
Who (individual or
team) should be
contacted within 1
hour?
S2
Who (individual or
team) should
immediately be
contacted?
Who (individual or
team) should be
contacted within 2
hours?
S3-4
Who (individual or
team) should be
contacted within 1
hour?
Who (individual or
team) should be
contacted within 6
hours?
Availability of support
The vendor shall provide the contact information for each of the teams / individual to be
contacted in the escalation illustration taking into account availability based on severity
as illustrated below;
Priority
Contact
Contact
Contact
S1
Name / Role:
Phone(s):
Email:
Availability:
Name / Role:
Phone(s):
Email:
Availability:
Name / Role:
Phone(s):
Email:
Availability:
S2
Name / Role:
Phone(s):
Email:
Availability:
Name / Role:
Phone(s):
Email:
Availability:
Name / Role:
Phone(s):
Email:
Availability:
S3-4
Name / Role:
Phone(s):
Email:
Availability:
Name / Role:
Phone(s):
Email:
Availability:
Name / Role:
Phone(s):
Email:
Availability:
232
E. IMPLEMENTATION SCHEDULE
STAGE
REQUIREMENTS
DEFINITION
- CRP Training
- Functional
Requirements
- Integration
Requirements
- Data Migration
Requirements
- Testing
Requirements
SOLUTION DESIGN
SOLUTION
DEVELOPMENT
- Development
environment
setup
- Configuration
- Interfaces
- Extensions
- Reports
SOLUTION
TESTING
- Test
Environment Set
Up
- System
Integration
Testing
- User Acceptance
Testing
- Performance and
TIME IN MONTHS
M1
M2 M3 M4 M5 M6 M7
M8
Load Testing
- Data Migration
Testing
Iteration
1
Iteration 2
TRAINING
- Training
Environment
Setup
- Functional NCC
User Training
- Technical NCC
User Training
- Executive NCC
User Training
MIGRATION
- Production
environment set
up (hardware, )
- Data Migration
IT3
- User Set Up
- Module
Activation and
phased out decommission of
the legacy
system as
dictated by the
change
management
plan
POST MIGRATION
SUPPORT
4.1
4.1.1
Schedule of Works
The bidder is expected to use this indicative schedule as a guideline to the
preparing a proposed plan for the implementation.
234
2015
2016
1
2
3
4
5
6
7
8
9
10
11
12
1
0
2
0
1
1
0
0
0
2
0
3
1
0
2
0
1
1
0
0
0
2
0
3
235
5.2
5.3
5.1.1
5.1.2
5.2.1
236
5.4
5.3.1
5.3.2
237
(b)
(c)
to ensure that each Bidder includes along with a specific response to the
Purchaser, a cross reference to the supporting information provided elsewhere in
its Technical Bid.
It is important that the tables be prepared carefully and completely, with accurate
references to the relevant section and paragraph numbers in the Technical Requirements
so that Bidders will be more likely to submit complete information, particularly regarding
the mandatory and scored Requirements. In preparing each Checklist entry, Purchasers
should start with an abbreviated text of each Requirement so that Bidders can quickly
confirm that they are responding to the right Requirement. Inconsistencies between the
Checklist and the referenced section in the Technical Requirements should be avoided.
Giving Bidders a revisable, "electronic" version of the Checklist as part of the Bidding
Documents will enhance the completeness of bids.
Technical Responsiveness Checklist
Note to Bidders: The following Checklist is provided to help the Bidder organize and
consistently present its Technical Bid. For each of the following Technical Requirements, the
Bidder must describe how its Technical Bid responds to each Requirement. In addition, the
Bidder must provide cross-references to the relevant supporting information, if any,
included in the bid. The cross reference should identify the relevant document(s), page
number(s), and paragraph(s). The Technical Responsiveness Checklist does not supersede
the rest of the Technical Requirements (or any other part of the Bidding Documents). If a
requirement is not mentioned in the Checklist, that does not relieve the Bidder from the
responsibility of including supporting evidence of compliance with that other requirement
in its Technical Bid. One- or two-word responses (e.g. "Yes," "No," "Will comply," etc.) are
normally not sufficient to confirm technical responsiveness with Technical Requirements.
The column headed M/P on the checklist depicts Mandatory and Preferred attribute
of the requirement respectively.
Bidders shall use the following options to indicate the DEGREE OF SUPPORT OF
COMPLIANCE their solution provides for each of items listed in this section:
1. FS - (Fully Supported) the application fully supports the requirement without any
modifications.
2. PS - (Partially Supported) the application supports the requirement with use of a system
or workflow workaround.
238
3. NS - (Not Supported) the system is not capable of supporting the requirement and
cannot be modified to accommodate the requirement.
Please tick the appropriate column to indicate one of the responses listed above for each
item and add as many comments, as you may feel relevant in the BIDDERS TECHNICAL
REASONS SUPPORTING COMPLIANCE section.
To enhance the completeness of bids, a revisable/expandable version of this Checklist is
available to bidders in electronic form. Where a requirement is expanded by the inclusion of
bullet points in the REQUIREMENTS column, the bidder is requested to enter a response
against each bullet point and add any comment as they feel relevant in the BIDDERS
TECHNICAL REASONS SUPPORTING COMPLIANCE column.
Wherever a REQUIREMENT is not Fully Supported by the bidders solution, they are
requested to provide a clear and concise explanation in the BIDDERS TECHNICAL REASONS
SUPPORTING COMPLIANCE section.
Questions that require a more qualitative response do not require the DEGREE OF
SUPPORT OF COMPLIANCE column to be populated. In such instances, the DEGREE OF
SUPPORT OF COMPLIANCE cell has been shaded in gray and the vendors are requested to
only complete the BIDDERS TECHNICAL REASONS SUPPORTING COMPLIANCE section of
the question.
239
REQUIREMENT
TECHNICAL REQUIREMENTS
0.2
4.0
TECHNICAL SPECIFICATIONS
2.0
2.0.1
M/P
FS
PS
NS
BIDDERS TECHNICAL
REASONS SUPPORTING
COMPLIANCE
BIDDERS CROSS
REFERENCES TO
SUPPORTING INFO IN
TECHNICAL BID
240
2.
The system shall have the availability to allow
customization and personalization of GUI by NCC e.g.
creation of top 10 list of functions, re-ordering the
notification work list etc.
3.
Ability to access reports and workflow
notifications via mobile devices e.g. Android, Apple,
Windows etc.
4.
Ability to support multi-currency support:
System should allow transactions to be done in
different currencies
5.
Ability of the system to import or export data in
industry standard formats such as XML, CSV etc. for
user mass data load
6.
Ability of the system to allow display of data
from external systems via frames or ports, etc., in a
context-sensitive manner via secure web APIs e.g.
viewing of GIS information from the GIS system once
it is available.
7.
Ability to support multiple counties /
government / county agencies on the platform but
with proper access controls to meet confidentiality
and constitutional requirements. The user interface
must contain a link back to central government and
respective county systems once these services
become available on the eCitizen Portal.
8.
Availability of visual modeling tools (in a
workbench) to enable intuitive modeling of business
processes with features such as check-in and checkout support of multi-user modeling environment.
9.
Capability to perform process simulation before
actual deployment of the process for use.
10. Ability to easily create data entry forms and userinterfaces (screens) for any future processes to aid
NCC users in defining new workflows that may not be
envisioned in the scope of this implementation.
11. Ability to utilize NCC defined approval hierarchy
to set up approvals within process workflow. These
definitions shall be developed as part of use case
development in the Requirements Definition phase of
the project as described in Section F on
implementation plan.
12. Ability to allow NCC users to approve workflows
on mobile devices.
13. Support for automated or semi-automated
processes within a workflow i.e. the system should be
able to allow for user selected approval actions or
perform auto approval actions within a process based
on pre-defined business rules that satisfy the
conditions for such approval actions as shall be
determined during the BPR process.
14. Capability to export process models in standard
formats
15. Capability to import process models that have
been created using standard formats for process
modeling.
16. Support for the following features: Create,
Release, Complete, Save, Cancel, Schedule,
Reschedule, Approve, Reject, Suspend, Reassign
workflow process
241
242
243
244
System Security
1.
The security concept shall include an
explanation of the system architecture, describing
how the functional components are distributed /
localized in the architecture.
2.
The security concept shall include the standard
platforms (e.g. hardware, OS, middleware,
applications and databases.
3.
The security concept shall include the interfaces
with other systems/applications and protocols.
4.
The requirements of the system concerning
security of the network infrastructure (e.g. DMZs)
shall be described. If necessary, the requirements
shall be adapted to the existing security
infrastructure
245
246
5.
The security mechanisms to protect connections
to public networks (e.g. firewalls, tunneling) shall be
described.
6.
For each user profile a description of the
password parameters and how they can be
configured shall be offered (e.g. forced minimum
password length and complexity, maximum password
lifetime, screen lock timeout, maximum number of
failed login attempts).
7.
The process to archive log files shall be in a
trustworthy way and for a configurable time
according to resources and requirements.
8. The supplier shall provide its back-up
recommendations that will be validated by Client
according to its needs (details of which data is saved,
frequency of data modification, etc.). The following is
an example of the minimum frequency for saving
data:
Daily: for Data, Confidential Information, Logs;
Weekly : Data; and
Monthly : System.
9. System configuration standards must be consistent
with industry accepted hardening standards such as
Center for Internet Security (CIS)
International Organization for Standardization
(ISO)
SysAdmin Audit Network Security
(SANS) Institute
National Institute of Standards; and
Technology (NIST).
247
248
249
250
251
252
253
254
2.1
255
256
2.1.1
Registration Module
1.
The system should provide users with ability to
capture citizen / entity details that are workflow
initiated by eCitizen Portal, NCC Portal or Jambo Pay
and activate the citizen account in the revenue
management system (It should be easy to classify
between individuals and corporates at registration
and upon saving the record in the system)
2.
The system should provide users with ability to
associate an entity (e.g business or individual) with
the revenue categories applicable to the entity as
shall be configured in the revenue services module for
purposes of determining the fees applicable to that
category of entity and the frequency of collection.
3.
The system should have the ability to fulfill
service requests (initiated by NCC Portal, Jambo Pay
or eCitizen) for account activation (e.g. business
permit request) by generating the account for
revenue or non-revenue based service and
associating the account with the citizen profile. The
system should have the ability to manually create a
citizen / entity account (e.g. business permit
application) directly in the ICRMS.
4.
The system should have the ability to create
citizen / entity accounts in mass using secure data
transport mechanisms either from excel file or
directly from LAIFOMS. This data import process
should be provided as an automated process or a
user-driven process with proper controls against
duplication and integrity of existing data.
5.
Ability to update selected citizen details (such as
contacts) that are workflow initiated by the eCitizen
Portal or NCC Portal and update the respective
record in the ICRMS
6.
Ability to fulfill eCitizen Portal and NCC Portal
initiated service request for account update (e.g.
payment preferences, day / month of billing) by
updating the service account for revenue or nonrevenue based service
7.
Ability to manually update a citizen / entity
service account (e.g. change of billing rules) in the
ICRMS through a workflow process.
8.
Ability to suspend any service account when
such an account is under investigation and freezing
any fulfillment request lodged by the citizen through
eCitizen Portal or NCC Portal
9.
Ability to deactivate any service account when
the service is delivered and there are no more
pending or outstanding collections on that account
e.g. expiry of leases that are not renewed or vacation
of a market stall by the entity / citizen
10. The system should give NCC staff the capability
to search or look up an entity based on any criteria
stored in the entity record (e.g. Name, Identifier,
Creation Date, Entity Type) based on their access
rights to such records.
11. The system should maintain the uniqueness of a
citizen / entity account based on a unique identifier.
For individuals this unique identifier is the citizen
identification as contained in the IPRS system. Citizen
registration process for individuals shall be
authenticated by the IPRS system as described in
Section H, sub section 2 Integration Touch Points. For
entities, the unique identifier shall be taxpayer
identification number as provided by the national tax
authority, KRA. This is to safeguard against multiple
registrations by the same individual / entity and to
maintain a single consistent view of the citizen.
257
258
2.1.2
6.
The system should be flexible in allowing
deactivation of any asset that either has been retired
or disposed and no longer in use to generate revenue.
The deactivation should take into account any active
subscriptions by citizens for that service that havent
been processed for billing.
7.
The system should be flexible in allowing
deactivation of billable service defined when such
need arises (e.g. when a service is retired or no longer
offered). The deactivation should take into account
any unprocessed service requests that reference that
billable service
8.
The system should be flexible in allowing
deactivation of a parameter or parameters for a
particular billable service defined when such need
arises (e.g. a certain fee or charge within the business
permit service is retired or no longer offered). The
deactivation should take into account any
unprocessed service requests that reference that
billable service
9.
The system should be flexible in allowing of
grouping of related services into a single workflow
process that branches out to specific services for
fulfillment within the main workflow e.g. grouping
the single business permit application process and
health permit for food handling business
259
260
2.1.3
1.
The system should allow the capture of nonrevenue generating assets (through an external Asset
Management System) - Classification coding of what
is a non-revenue generating assets required
2.
The system should be able to define various
categories of non-billable services such as (Dog
Permits etc.)
3.
The system should allow the association of the
imported asset with the non-revenue services offered
within that asset (e.g. Recreational parks, etc.)
4.
The system should be flexible enough to
cascade the non-billable service (including
amendments) to other upstream systems (like the
web portal) so that they are visible to the citizen
5.
The system should be flexible in allowing
deactivation of any asset that either has been retired
or disposed and no longer in use.
6.
The system should be flexible in allowing
deactivation of non-billable service defined when
such need arises (e.g. when a service is retired or no
longer offered).
7.
The system should be flexible in allowing
suspension of non-billable service defined when such
need arises (e.g. to prevent citizens from accessing
the service when it is undergoing revision of business
rules associated with it).
2.1.4
261
262
2.
The system should have the ability to record
and store assessments for county defined number of
years as dictated by legislation that is passed by the
county assembly.
3.
The system should have the ability to store data
(including historical data) for land values related to
residential, commercial, industrial, multi-family and
agricultural land
4.
The system should have the ability to capture
characteristics of a parcel for land use based on predefined parameters for that land that can be
extended as and when the county desires.
5.
The system should have the ability to associate
electronic files with a system record, including but
not limited to PDF, MS Word, MS Excel, etc. It should
support integration with an external document
management system and have capacity to store such
content within its own content management
database.
6.
The system should perform security scan of all
documents that have been submitted by users before
using the documents.
7.
The system should have the ability to provide an
automated way of identifying "orphan" image files
(based on scanned images) that are not attached to a
specific system record.
8.
The system should have the ability to interface
with a GIS system for uniqueness and location
relationship. The system should provide a unique
identifier for each parcel of land as provided by the
GIS-based valuation system. It should be able to
integrate (using industry standard protocols) with
standard GIS systems to read GIS data and display on
the GUI.
9.
The system should have the ability to link
scanned documents to specific property record. It
should be able to integrate (using industry standard
protocols) with standard document management
systems to read content and display on the GUI.
10. The system should have the ability to export an
image file directly for document storage.
11. The system should have the ability to email a
linked image file to another party.
12. The system should have the ability to maintain
and search property ownership history for all parcels.
This search should be linked to the defined citizen /
entity account categorized accordingly
13. The system should have the ability to add a new
parcel to the property history data for respective
citizen / entity account.
14. The system should have the ability to record
sufficient property address information to include
such items as location, street, etc. that is linked to the
GIS system for geo location
15. The system should have the ability to maintain
complete, integrated parcel history for all splits and
mergers of parcels of land
16. The system should have the ability to maintain
property ownership history when two or more
parcels are combined into one parcel
17. The system should have the ability to maintain
original parcel ID on new parcels created from
mergers or splits.
18. The system should allow the option of moving all
pertinent data automatically to the appropriate
parcel.
263
264
2.1.5
265
266
2.1.6
2.
The system should have the ability to query GIS
data when adding a new business to determine if it is
within the County or not. Describe how the proposed
system integrates (using industry standard protocols)
with standard GIS systems to read GIS data and
display on the GUI.
3.
The system should have the ability to calculate
fees based on county-defined metrics for the billable
services configured and applicable for Permits and
Licenses for the business entity defined
4.
The system should have the ability to support
licensing fee structures by type.
5.
The system should have the ability to integrate
citizen / business records, Business License, Related
Taxes, Permits and Business Property into a single
system with a consistent look and feel as acceptable
and accessible by the NCC.
6.
The system should have the ability to provide
user friendly and intuitive navigation among the
various associated licensing accounts related to a
business entity and provide a single view of all
accounts for an entity from one display screen to the
NCC Users.
7.
The system should integrate with an online
portal (NCC Portal and eCitizen Portal) to update
selected entity information including tenants located
in count-owned facilities like County Markets etc.
Refer to Section H Sub Section 2 on Integration Touch
Points
8.
The system should have the ability to change
trade name through a workflow approval process.
Record of the previous trade name should be
retrievable at any time as audit trail of change.
267
268
9.
The system should have the ability to set up an
unlimited number of business license accounts for
each entity and an unlimited number of business
(license) types for each license account established
for a business. Example: A hotel chain has multiple
locations, and there is a distinct business license
associated with each location. Each hotel may also
have multiple business (license) types associated with
such, restaurants (retail), valet services (personal
service), gift shops (retail with food), etc. The system
must provide for the creation and association of all of
these accounts and they must be associated by a
unique identifier.
10. The system should have the ability to associate a
citizen account with multiple business accounts e.g.
person x runs a shopping mall, owns a garage and has
bar in various parts of the county.
11. The system should have the ability to add, delete,
and modify, business license accounts through a
workflow approval process and audit trail of changes.
12. The system should have the ability to view and
print all forms for a business license account and all
related accounts from a single display screen or
printed report.
13. The system should have the ability to display the
business license information based on a pre-defined
search criteria taking into account access control for
public and private information as shall be determined
by the County.
14. The system should have the ability to display
delinquent accounts to county enforcement officers
when querying a business account.
269
270
271
272
4.
The system should be able to process ad hoc
applications for permits (these are permits that are
not pre-determined e.g burial permit for deaths etc.
The list of such adhoc requests will be discussed
during the BPR process.) applying the pre-requisite
check list rules in the process. The submission of
request should have options where it can be
submitted online via NCC Portal, eCitizen Portal or in
the back end processed by a County officer. The
system must keep an audit trail of the application
process at various stages of the workflow showing
what action was taken, by who and when.
5.
The system should be able to cascade the ad hoc
request to the billing and collection module for
payment collection.
6.
The system should be able to refresh the ad hoc
request upon payment confirmation from the
collections module and allow the permit to be
generated and sent to the requester via various
channels e.g. email or downloaded from the citizen
portal by the registered requestor or collected from
the County Office nearest to the requestor.
7.
The system should be able to accept and
process ad hoc payments for parking linked to the
facilities configured and validated by the charge rates
defined.
8.
The system should be able to accept and
process periodic payments for long term parking
linked to the facilities configured and validated by the
charge rates defined. This process should create an
account in the registration module for purposes of
single view of the entity.
9.
The system should provide subsequent rules
within the main rules for certain services like parking.
For example in setting up the facility called public
parking and the associated fees, there should be
penalties where parking fees are not paid each
classified within the facility such as Clamping charges
and towing charges.
10. The system should provide a mechanism to book
in a car that has been clamped and towed. Details of
the car should be captured in the booking.
11. The system should provide a mechanism to
process ad hoc requests for payment of parking fees,
clamping charges and towing charges where such
cases arise and cascade the processing of that
request to the collection module for update of the
request status.
12. The system should provide a mechanism that
once the clamping, parking and towing charges have
been settled, an alert is sent to the officer asking for
unclamping and releasing the car from the yard and
updating the clamping book in the system
accordingly.
13. The system should be able to accept and process
ad hoc payments for market stalls linked to the
facilities configured and validated by the charge rates
defined.
14. The system should be able to accept and process
periodic payments for market stalls linked to the
facilities configured and validated by the charge rates
defined. This process should create an account in the
registration module for purposes of single view of the
entity.
273
274
275
276
8.
System capture insurance details against each
fleet showing the policy number, insurance company,
policy start and end date and have the ability to
generate a notification to NCC officers in charge of
renewals, within a configurable lead time, to initiate
process of insurance renewal.
9.
The system should process electronic
information (through an integration with the IFMIS
AP system) from service providers for settlement of
bills due e.g. Fuel and other service providers that
give the county Fuel Cards for fuelling the fleet of
vehicles which keeps a log of the fuel-top ups and
sends a periodic electronic file for settlement by the
county.
10. The system should provide the ability to interface
with a 3rd party vehicle tracking system to be
contracted.
11. The system should have the ability to query fleet
information using a set of parameters such as:
Job Route
Registration Number
Service Due Dates
Driver Name
Job Number
Jobs Summary
Vehicle Summary
Maintenance History
2.1.9
277
278
2.
The system should provide the ability to capture
types of offences and link them to the types of cases
as they are defined by county by-laws / county laws to
be supplied by the County.
3.
The system should provide the ability to capture
types of penalties and link them to the types of
offences as they are defined by city by-laws / county
laws to be supplied by the County.
4.
The system should have the ability to capture
different categories of evidence that can be produced
in a case as they are defined by city by-laws / county
laws to be supplied by the County.
5.
The system should have the ability to open a
case and generate a unique case number based upon
a report created by county law enforcement officers.
The case should have a date, the offender, the type of
case, the type of offense and all the details of
possible penalties should be populated on the case
6.
The system should have the ability to attach
evidence to a case using the types of evidence
configured. The evidence can be a picture, a video
clip, sound recording which is verifiable and credible
witness that is well defined in the case
7.
The system should have the ability to record the
outcome of hearing and update the case status
including attaching the fines (as shall be determined
by the County magistrate) to be paid by the offender
8.
The system should have the ability to transfer
the fine to be paid by the offender to the fees and
charges module for collecting and update of the
status of the case
9.
The system should have the ability to close a
case once hearing is heard and fines are paid
279
280
6.
The system should support different types of
remittances for fees, charges and rates e.g. Cash,
Check, EFT, Real time gross settlement (RTGS)
payments, Mobile Money etc.
7.
The system should automatically match
payments to the billing generated and automatically
update citizen / entity balance account balance.
Matching should happen upon successful processing
of payment.
8.
The system should provide for ability to reverse
payment for collections. The reversal of such
payments should have configurable reasons
(exceptions) and subjected through a workflow
process. The successfully reversed payments un apply
the bill to the account and return the account as due
for settlement.
9.
The system should allow the creation of prepayments by citizens i.e. Payments can be made
without a bill and the funds are applied on the citizen
on account
10. The system should allow the processing of
refunds to citizens where business rules require that.
The processing should send an instruction of the
IFMIS AP System to generate an Invoice for onward
refund payment.
11. The system should allow the application of prepayments based on flexible application rules that are
configurable e.g. LIFO, FIFO etc.
12. On transaction enquiries the system should
display the foreign currency value, base currency at
historical rate and base currency at current rates
281
282
2.
The system should provide the ability to record
findings of the defective asset e.g. a building with a
leaking roof, or a street light that is broken or a road
that has pot holes. The system should provide
location information of the defective assets,
dimensions and sizes of the defects where they are
measurable e.g. how many lights are non-functional
along a particular street. The Recording of faults by
citizens should be made via NCC portal or NCC social
media coming to the NCC maintenance team and
consolidated for manual entry in the maintenance
module of ICRMS.
3.
The system should generate a list of defective
assets with the defect details and the dates recorded
and create a maintenance register for review.
4.
The system should provide the ability to review
the maintenance register and classify each of the
defects in accordance with configurable type of
maintenance e.g. minor or major
5.
The system should initiate a request for
maintenance of a particular asset listing the parts
required, the service provider required and the date
required for maintenance (this would be integrated
with the requisition process in the procure to pay
process of IFMIS). The asset selected should be
inactive for use in the services attached to it.
6.
The system should record the parts fitted, the
tests conducted and the status of the defect after
maintenance work is completed. Once it is passed,
the system should alert the Procure to Pay process to
perform a purchase order receipt in IFMIS so that
once the supplier bills, the invoice can be processed
and paid.
2.1.11
7.
The system release the asset for use again and
update the asset register in IFMIS with details of any
changes in value based on the parts fitted to it after
maintenance
Reporting Module
The system should have the ability to:
1.
Produce forms for registration of property rates
as an alternate to online registration.
2. Generate a Property Listing showing:
Property register
Property sub division
Accounts in Arrears
Generate Operational reports showing
Property rates statements
Properties payment list
Adjustment list
Property rates Outstanding balances
3.
provide a full Market research and portfolio
analysis, and also the hold/sell analysis reports
4.
provide analysis off a dashboard of the various
comparisons between economic rate of return and
the market rate of the property
5.
Generate forms such as tenancy registration
form using the preconfigured information for various
types of tenancies
6.
Generate of Listing of properties by type e.g.
Houses, Stalls etc.
7.
Generate of statements for various types of
rental properties e.g. Houses, Stalls
8.
283
284
9.
provide ad hoc reports as detailed requirements
39 to 062 in this section. (DELETED)
10. easily generate a listing of filing forms (e.g.,
businesses that have filed a business license) as shall
be determined by the County.
11. use machine readable technology to read
renewal forms with preprinted account number, and
license type.
12. print licenses and license renewal applications
via mass mailings, e-mail, and individual in-house print
based on county-defined criteria.
13. generate a file that contains all business license
renewal information and business license certificate
information that will be sent to a print vendor or
printed in-house.
14. flag accounts for inconsistencies, reporting
discrepancies, and/or the suggestion to audit such
account.
15. Identify associated additional records (when a
business is closed to) that should also be reviewed.
(For example, a citizen that has multiple business
licenses that also need to be reviewed as well.)
16. generate updated business lists and distribute via
mail or Internet to interested entities.
17. display geographic locations for all business
license accounts utilizing Geographic Information
System (GIS) functionality.
18. Produce a list of registered businesses
19. Produce a list of Business Activity Code as
defined in the setups
20. Provide an account status analysis by
preconfigured parameters such as zone / ward
285
286
287
288
2.2.1
Project Plan
The bidder should provide a detailed project plan with
achievable timelines and responsibilities showing
show the proposed solution will be rolled out in the
interim data centre and migrated to the primary data
centre as explained in section 2.2.1
2.2.2
Project Governance
289
290
Implementation Requirements
1.
The system should be implemented in modules
as guided by the overall modular architecture. Bidders
may propose alternative implementation flavors that
they view as being more advantageous to the County.
Alternate Implementation approaches will however
need to be in line with the indicative implementation
plan in Section F: Implementation Schedule and
governance structure in Section C: Subsection 2.2.2
2.
The bidder should describe the approach to
training showing the various levels of training and
expected learning outcomes. The training should
cover both functional and technical aspects of the
solution (Refer to Section C Sub Section 2.5 on
Training)
3.
The bidder should describe the approach to User
Acceptance Testing (UAT), System Integration
Testing (SIT), data migration testing and load /
performance testing and the expected involvement
of NCC staff and other 3rd party interface service
providers. (Refer to Section E - Testing and Quality
Assurance)
4.
The bidder should describe the approach to
quality assurance of the solution and how it is aligned
to the desired target architecture in accordance with
the guidance provided in Section E - Testing and
Quality Assurance
5.
The bidder should describe the approach to
perming product support immediately after going live
and thereafter. The approach must identify the
291
292
293
294
of IT project management
Experience working in implementing large scale IT
projects in developing countries
Project management certification is required
Experience in designing, implementing, and
managing related projects (3 sites minimum)
24. Bidder staffing must have a Business Analyst(s)
with the following qualifications:
Graduate degree in Computer Information Systems
or equivalent qualifications.
6 or more years relevant experience in Business
Analyst role with strong analytical, problem-solving
and communication skills. (Refer to Section B subsection 3 BPR and use-case development)
At least 6 years project participation (as a business
analyst) in implementation of similar system(s).
Relevant certification in business analysis from
industry bodies such as BABOK or equivalent would
be an added advantage.
Relevant industry experience in BPR and use case
development
295
296
297
298
2.3
299
300
2.5
Training
2.6
2.7
Warranty
301
302
Documentation
The bidder shall provide templates showing how each
of the types of documents listed in section 2.8 shall
be produced describing the objective of the
document, the audience, the key deliverables, the
prerequisites and the sign off requirements.
3.1
3.2
SUPPORT PROCESS
The bidder shall describe the support structure,
process and tools guided by the framework described
in section 3.2
303
H. ATTACHMENTS
1. List of systems currently used by the county
System
Description
Platform
Operating
System
Architect
ure
Database
IFMIS
Purchasing
Oracle
Sun Solaris
10 and file
system
configured
on RAID 5
3
tier
architectu
re
Oracle 10g
Microsoft
Windows
Server 2008
Client
Server
MS SQL
Server
2008
JAMBOPAY
Windows
Server 2012
SOA on
an
inhouse
develope
d
middlewa
re for B2B
integratio
n through
SOAP API
and ISO
8583,
supportin
g DES and
Triple-DES
Encryptio
n
algorithm
AD MANAGER
Java
Windows
SQL
Server
eConstruction
PHP
Windows
MySQL
LAIFOMS
E-
Business
Suite
MS SQL
Server
304
Permit / eDevelopment
System
Pumwani
Hospital
System
City Mortuary
System
BIRTH
CERTIFICATES
TPS
MANGEMENT
SYSTEMDANDORA
C++
IPRS
305
eCitizen
National
Portal
url: http://ecitizen.go.ke/
NCC Portal
PHP
Linux
Apache
HTTP
Server
MySQL
306
DIRECTION
IFMIS CE
IFMIS AR
IFMIS AP
IFMIS INV
Jambo Pay
IFMIS PO
IFMIS PO
IFMIS FA
SYSTEM
MODULE
307
DIRECTION
for activation of service
eCitizen Portal
eCitizen Portal
eCitizen Portal
Hospital System
NCC Portal
NCC Portal
NCC Portal
eCitizen Portal
ADMANAGER
Advertising
System
Building
and
Construction
Permits System
Mortuary System
IRPS System
308
3. Staging Area
NCC expects the vendor to provide for a staging area / repository within the production
database / operating system. Inbound interface data shall be staged (held) by feeder
systems in this area prior to import by the ICRMS. The staging area shall also serve as a
transit area for data from ICRMS to other systems for outbound interfaces. Refer to the
schematic diagram below for an illustration of the envisioned process.
309
4. Infrastructure Considerations
The ability to provide System Integration across various systems in NCC shall include using of
available storage and server systems for all data and software that may need server and
storage systems
The bidders solution must show how they propose to integrate with, and use the already
available infrastructure that includes; SAN/Storage management systems, Severs, a secure
managed networks infrastructure that includes firewalls, application management,
monitoring and associated security infrastructure.
It is important to note that the NCC is currently in the process of building its own data
center, which is at sourcing stage. However, plans are underway to secure a co-located data
center for projects that are expected to be implemented before the build is completed.
Therefore, bidders should take note that the ICRMS may reside in a co-located data center
within Nairobi at least during the implementation and upon successful go-live and
stabilization. Migration to the completed data center will be a project to be undertaken
outside the scope of this implementation but guided by the warranties and maintenance
agreements that will be in force.
While proposing the technical and deployment architecture for the ICRMS the vendor must
pay consideration to:
Scalability
Active- Passive (AP) This approach utilizes a fully redundant set of services that are
only initialized when the primary service set fails
310
Active- Active (AA) In this approach, both set of services remain active and take user
load. In case of any failure of the primary service set, traffic or data is seamlessly routed
to the secondary (hot) service set
Load Balancing
The bidder must describe how the ICRMS will distribute processing load across available
processors or servers.
The bidder must describe the optimal architecture for HA deployment of the ICRMS and
give justification for the same.
At a high level, the following diagram represents the possible traffic in and out of the
ICRMS both from Intranet and Internet.
Intranet users will be the NCC users who will access the ICRMS via the LAN or remotely
through a secure VPN connection.
External users will access ICMS via the internet through designated interfaces. External
users will not directly access the ICRMS.
311
Number of Instances
NCC anticipates having at least 3 instances of the ICRMS. These are;
INSTANCE
DESCRIPTION / PURPOSE
DEVELOPMENT
TEST / QA
This shall be the test bed and quality assurance instance for any bugs fixed,
extensions, new releases that have been tested and passed in development
instance. This instance will also be the source database for which
development instance will be refreshed. Data in this instance shall be
randomized immediately after being copied from production to protect
confidentiality. Functional and end to end acceptance testing shall be on this
environment.
312
INSTANCE
DESCRIPTION / PURPOSE
This shall be the operational environment used by the NCC users and the
citizens. This environment must fully meet the requirements for high
availability, load balancing and scalability.
This instance shall be the source database for which test instance shall be
refreshed.
The management and version control during deployment of deliveries from development to
test to production is as described by the diagram in the next page. The vendor must describe
the process of movement of releases between the instances taking into account changes in
versions.
Hardware Inventory
This is a turnkey project. The bidder shall be expected to provide and set up the required
hardware (either directly or through a sub-contractor) for all the instances described in the
previous section. The table below gives a guidance of how to respond to this requirement:
313
PRODUCTION INSTANCE
DOMAIN
OS
CPU
MEMORY
STORAGE
OS
CPU
MEMORY
STORAGE
CPU
MEMORY
STORAGE
Web Tier
Application Tier
Database Tier
Others
TEST INSTANCE
DOMAIN
Web Tier
Application Tier
Database Tier
Others
DEVELOPMENT INSTANCE
DOMAIN
Web Tier
Application Tier
Database Tier
Others
OS
314
315
316
which case domestic preference does not apply in this SBD). It is essential that Bidders submit their
prices in the manner prescribed by the Price Schedules. Failure to do so may result in loss of the
preference, if applicable.
For the more straightforward or well specified Systems that are covered by the single-stage
bidding process, the Purchaser is encouraged to fill in the precise System, Subsystem, component,
and item/description details in the Price Schedules prior to issuance of the Bidding Document. This
will result in bid pricing that is more uniform, making the comparison of bid prices more efficient and
reducing the number of ambiguities that require clarification. If Bidders are left to fill in
item/description details (which may be necessary for complex Systems when such details cannot be
easily identified in advance by the Purchaser), the commercial evaluation becomes more difficult.
Other guidance and instructions appear in the subsection containing the schedules and in the
schedules themselves.
Manufacturers Authorizations and agreements by key subcontractors: In accordance with
ITB Clauses 6.1 (b) and (c), Bidders may be required to submit, as part of their bids, Manufacturers
Authorizations and written agreements by Subcontractors proposed for key services. For the
Manufacturer's Authorization, the format provided in the SBD should be used. There is no particular
format for Subcontractor agreements.
List of Proposed Subcontractors: In accordance with ITB Clause 6.3, a Bidder must submit, as
part of its bid, a list of major goods and/or services that the Bidder proposes to subcontract. The list
should also include the names and place of registration of the Subcontractors proposed for each
item and a summary of their qualifications.
List of Software and Materials: In accordance with ITB Clause 13.1 (e) (vi) (ITB
Clauses 13.1 (c) (vi) and 25.1 (e) (vi) in the two-stage SBD), a Bidder must submit, as part of its bid, a
list of all the Software it will provide, assigning each item to one of the following categories: (A)
System, General-Purpose, or Application Software; or (B) Standard or Custom Software. The Bidder
must also submit a list of all Custom Materials. These should be recorded in the sample List of
Software and Materials Table included in the Bidding Document. If provided for in the Bid Data
Sheet, the Purchaser may reserve the right to assign key System Software items to a particular
category.
Bidder Qualification forms: As required by ITB Clause 6.1.
Forms for securing the bid: If the BDS for ITB Clause 17 (ITB Clause 29 in the two-stage SBD)
requires that bids be secured, the Purchaser should include the related form(s) in the Bidding
Document, as provided in this Section of the SBD. Depending on what type of security the BDS
requires, one form (Bid-Securing Declaration), two forms (Bank Guarantee and Bid Bond), or all three
forms, should be included. If the Purchaser wishes to use another form, it must obtain the World
Banks prior no-objection. Some of the variable fields (such as the duration of sanctions in case of
the Bid-Securing Declaration) need to be pre-filled by the Purchaser.
Performance Security: Pursuant to GCC Clause 13.3, the successful Bidder is required to
provide the Performance Security within twenty-eight (28) days of notification of Contract award.
Advance Payment Security: Pursuant to GCC Clause 13.2, the successful Bidder is required to
provide a bank guarantee securing the Advance Payment, if the SCC related to GCC Clause 12.1
provides for an Advance Payment.
Installation and Operational Acceptance Certificates: Recommended formats for these
certificates are included in these SBD. Unless the Purchaser has good reason to require procedures
317
that differ from those recommended, or to require different wording in the certificates, the
procedures and forms shall be included unchanged. If the Purchaser wishes to amend the
recommended procedures and/or certificates, it may propose alternatives for the approval of the
World Bank before release of the Bidding Document to potential Bidders.
Change Order Procedures and Forms: Similar to the Installation and Operational Acceptance
Certificates, the Change Estimate Proposal, Estimate Acceptance, Change Proposal, Change Order,
and related Forms should be included in the Bidding Document unaltered. If the Purchaser wishes to
amend the recommended procedures and/or certificates, it may propose alternatives for the
approval of the World Bank before release of the Bidding Document.
318
Bid Submission Form: In addition to being the place where official confirmation of the
bid price, the currency breakdown, the completion date(s), and other important
Contract details are expressed, the Bid Submission Form is also used by the Bidder to
confirm - in case adjudication applies in this Contract - its acceptance of the
Purchasers proposed Adjudicator, or to propose an alternative. If the bid is being
submitted on behalf of a Joint Venture, it is essential that the Bid Submission Form be
signed by the partner in charge and that it be supported by the authorizations and
power of attorney required pursuant to ITB Clause 6.2. Given widespread concern
about illegal use of licensed software, Bidders will be asked to certify in the Bid
Submission Form that either the Software included in the bid was developed and is
owned by the Bidder, or, if not, the Software is covered by valid licenses with the
proprietor of the Software.
319
Price Schedules: The prices quoted in the Price Schedules should constitute full and
fair compensation for supply, installation, and achieving Operational Acceptance of
the System as described in the Technical Requirements based on the Implementation
Schedule, and the terms and conditions of the proposed Contract as set forth in the
Bidding Documents. Prices should be given for each line item provided in the
Schedules, with costs carefully aggregated first at the Subsystem level and then for
the entire System. If the Price Schedules provide only a summary breakdown of
items and components, or do not cover some items unique to the Bidders specific
technical solution, the Bidder may extend the Schedules to capture those items or
components. If supporting price and cost tables are needed for a full understanding
of the bid, they should be included.
Arithmetical errors should be avoided. If they occur, the Purchaser will correct them
according to ITB Clause 26.2 (ITB Clause 38.2 in the two-stage SBD) without
consulting the Bidder. Major omissions, inconsistencies, or lack of substantiating
detail can lead to rejection of a bid for commercial non-responsiveness. Presenting
prices according to the breakdown prescribed in the Price Schedules is also essential
for another reason. If a bid does not separate prices in the prescribed way, and, as a
result, the Purchaser cannot apply the domestic preference provision described in
ITB Clause 29 (ITB Clause 41 in the two-stage SBD), if they are applicable in this
bidding, the Bidder will lose the benefit of the preference. Once bids are opened,
none of these problems can be rectified. At that stage, Bidders are not permitted to
change their bid prices to overcome errors or omissions.
List of Proposed Subcontractors: In accordance with ITB Clause 6.3, a Bidder must
submit, as part of its bid, a list of proposed subcontracts for major items of
Technologies, Goods, and/or Services. The list should also include the names and
places of registration of the Subcontractors proposed for each item and a summary
of their qualifications.
List of Software and Materials: In accordance with ITB Clause 13.1 (e) (vi) (ITB
Clauses 13.1 (c) (vi) and 25.1 (e) (vi) in the two-stage SBD), Bidders must submit, as
part of their bids, lists of all the Software included in the bid assigned to one of the
following categories: (A) System, General-Purpose, or Application Software; or
(B) Standard or Custom Software. Bidders must also submit a list of all Custom
Materials. If provided for in the Bid Data Sheet, the Purchaser may reserve the right
to reassign certain key Software to a different category.
320
Qualification information forms: In accordance with ITB Clause 6, the Purchaser will
determine whether the Bidder is qualified to undertake the Contract. This entails
financial, technical as well as performance history criteria which are specified in the
BDS for ITB Clause 6. The Bidder must provide the necessary information for the
Purchaser to make this assessment through the forms in this sub-section. The forms
contain additional detailed instructions which the Bidder must follow.
Securing the bid: If the BDS for ITB Clause 17 (ITB Clause 29 in the two-stage SBD)
requires that bids be secured, the Bidder shall do so in accordance with the type and
details specified in the same ITB/BDS Clause, either using the form(s) included in
these Sample Forms or using another form acceptable to the Purchaser. If a Bidder
wishes to use an alternative form, it should ensure that the revised format provides
substantially the same protection as the standard format; failing that, the Bidder runs
the risk of rejection for commercial non-responsiveness.
Bidders need not provide the Performance Security and Advance Payment Security
with their bids. Only the Bidder selected for award by the Purchaser will be required to
provide these securities.
The following forms are to be completed and submitted by the successful Bidder
following notification of award: (i) Contract Agreement, with all Appendices;
(ii) Performance Security; and (iii) Advance Payment Security.
Contract Agreement: In addition to specifying the parties and the Contract Price, the
Contract Agreement is where the: (i) Supplier Representative; (ii) if applicable,
agreed Adjudicator and his/her compensation; and (iii) the List of Approved
Subcontractors are specified. In addition, modifications to the successful Bidders
Bid Price Schedules are attached to the Agreement. These contain corrections and
adjustments to the Suppliers bid prices to correct errors, adjust the Contract Price to
reflect if applicable - any extensions to bid validity beyond the last day of original
bid validity plus 56 days, etc.
Performance Security: Pursuant to GCC Clause 13.3, the successful Bidder is required
to provide the Performance Security in the form contained in this section of these
Bidding Documents and in the amount specified in accordance with the SCC.
Advance Payment Security: Pursuant to GCC Clause 13.2, the successful Bidder is
required to provide a bank guarantee for the full amount of the Advance Payment - if
an Advance Payment is specified in the SCC for GCC 12.1 - in the form contained in this
section of these Bidding Documents or another form acceptable to the Purchaser. If
a Bidder wishes to propose a different Advance Payment Security form, it should
submit a copy to the Purchaser promptly for review and confirmation of acceptability
before the bid submission deadline.
The Purchaser and Supplier will use the following additional forms during Contract
implementation to formalize or certify important Contract events: (i) the Installation and
Operational Acceptance Certificates; and (ii) the various Change Order forms. These and the
321
procedures for their use during performance of the Contract are included in the Bidding
Documents for the information of Bidders.
322
Preamble ................................................................................................................329
Grand Summary Cost Table ...................................................................................331
Supply and Installation Cost Summary Table .......................................................332
Recurrent Cost Summary Table ............................................................................335
Supply and Installation Cost Sub-Table [ insert: identifying number ] ...............337
Recurrent Cost Sub-Table [ insert: identifying number ] ....................................341
Country of Origin Code Table ................................................................................343
323
324
Loan/Credit No.:
IFB:
Contract:
plus
plus
325
or such other sums as may be determined in accordance with the terms and conditions of
the Contract. The above amounts are in accordance with the Price Schedules attached
herewith and made part of this bid.
We undertake, if our bid is accepted, to commence work on the Information System
and to achieve Installation and Operational Acceptance within the respective times stated in
the Bidding Documents.
If our bid is accepted, and if these Bidding Documents so require, we undertake to
provide an advance payment security and a performance security in the form, in the
amounts, and within the times specified in the Bidding Documents.
[ As appropriate, include or delete the following paragraph ]
We accept the appointment of [ Purchaser insert: name of proposed Adjudicator
from the Bid Data Sheet ] as the Adjudicator.
[ and delete the following paragraph, or, as appropriate, delete the above
and include the following, or, if no Adjudicator is stated in the Bid Data
Sheet, delete both the above and the following ]
We do not accept the appointment of [ Purchaser insert: name of proposed
Adjudicator from the Bid Data Sheet ] as the Adjudicator, and we propose instead that
[ insert: name ] be appointed as Adjudicator, whose rsum and hourly fees are attached.
We hereby certify that the Software offered in this bid and to be supplied under the
Contract (i) either is owned by us, or (ii) if not owned by us, is covered by a valid license from
the proprietor of the Software.
We agree to abide by this bid, which, in accordance with ITB Clauses 13 and 16,
consists of this letter (Bid Submission Form) and the enclosures listed below, for a period of
[ Purchaser insert: number from Bid Data Sheet ] days from the date fixed for submission of
bids as stipulated in the Bidding Documents, and it shall remain binding upon us and may be
accepted by you at any time before the expiration of that period.
Commissions or gratuities, if any, paid or to be paid by us to agents relating to this
Bid, and to Contract execution if we are awarded the Contract, are listed below:
Name and
Address of Agent
Etc.
Amount and
Currency
Purpose of
Commission or
Gratuity
326
Until the formal final Contract is prepared and executed between us, this bid,
together with your written acceptance of the bid and your notification of award, shall
constitute a binding contract between us. We understand that you are not bound to accept
the lowest or any bid you may receive.
Dated this [ insert: ordinal ] day of [ insert: month ], [ insert: year ].
Signed:
Date:
In the capacity of [ insert: title or position ]
Duly authorized to sign this bid for and on behalf of [ insert: name of Bidder ]
ENCLOSURES:
Price Schedules
Bid-Securing Declaration or Bid-Security (if and as required)
Signature Authorization [plus, in the case of a Joint Venture Bidder, list all other
authorizations pursuant to ITB Clause 6.2]
Attachment 1. Bidders Eligibility
Attachment 2.Bidders Qualifications (including Manufacturers Authorizations and
Subcontractor agreements if and as required)
Attachment 3.
Attachment 4.
Conformity of the Information System to the Bidding
Documents
Attachment 5.
Proposed Subcontractors
Attachment 6.
327
Note: Bidders should expand and (if appropriate) modify and complete the following table.
The purpose of the table is to provide the Bidder with a summary checklist of items that
must be included in the bid as described in ITB Clauses 13.1 and 16, in order for the bid to be
considered for Contract award. The table also provides a summary page reference scheme
to ease and speed the Purchasers bid evaluation process.
Item
Bid Submission Form......................................................
Price Schedules ..............................................................
Bid-Securing Declaration / Bid-Security (if and as
required) .........................................................................
Signature Authorization (for Joint Ventures
additionally including the authorizations listed in ITB
Clause 6.2) ......................................................................
Attachment 1 ..................................................................
Attachment 2 ..................................................................
Manufacturers Authorizations ...............................
Subcontractor agreements .....................................
Attachment 3 ..................................................................
Attachment 4..................................................................
Attachment 5 ..................................................................
Attachment 6 .................................................................
.........................................................................................
present: y/n
page no.
328
329
2.1
Preamble
Note: Purchasers should highlight any special requirements of the System and Contract in a
Preamble to the Price Schedules. The following is an example of one such preamble.
General
1.
2.3
2.4
2.5
2.6
2.7
The Schedules do not generally give a full description of the information technologies
to be supplied, installed, and operationally accepted, or the Services to be performed
under each item. However, it is assumed that Bidders shall have read the Technical
Requirements and other sections of these Bidding Documents to ascertain the full
scope of the requirements associated with each item prior to filling in the rates and
prices. The quoted rates and prices shall be deemed to cover the full scope of these
Technical Requirements, as well as overhead and profit.
3.
If Bidders are unclear or uncertain as to the scope of any item, they shall seek
clarification in accordance with the Instructions to Bidders in the Bidding Documents
prior to submitting their bid.
Pricing
4.
Prices shall be filled in indelible ink, and any alterations necessary due to errors, etc.,
shall be initialed by the Bidder. As specified in the Bid Data Sheet, prices shall be fixed
and firm for the duration of the Contract.
5.
Bid prices shall be quoted in the manner indicated and in the currencies specified in ITB
Clauses 14 and 15 (ITB Clauses 27 and 28 in the two-stage SBD). Prices must correspond
to items of the scope and quality defined in the Technical Requirements or elsewhere
in these Bidding Documents.
6.
The Bidder must exercise great care in preparing its calculations, since there is no
opportunity to correct errors once the deadline for submission of bids has passed. A
single error in specifying a unit price can therefore change a Bidders overall total bid
330
price substantially, make the bid noncompetitive, or subject the Bidder to possible loss.
The Purchaser will correct any arithmetic error in accordance with the provisions of ITB
Clause 26.2 (ITB Clause 38.2 in the two-stage SBD).
7.
Payments will be made to the Supplier in the currency or currencies indicated under
each respective item. As specified in ITB Clause 15.1 (ITB Clause 28.1 in the two-stage
SBD), no more than three foreign currencies may be used. The price of an item should
be unique regardless of installation site.
331
2.2
1.
2.
3.
Name of Bidder:
Authorized Signature of Bidder:
[ insert: Foreign
Currency A ]
Price
[ insert: Foreign
Currency B ]
Price
[ insert: Foreign
Currency C ]
Price
332
2.3
System or Subsystem number: [ if a multi-lot procurement, insert: Subsystem number; otherwise state entire System
procurement ] [ as necessary for supply, installation, and achieving Operational Acceptance of the System, specify items in the
Table below, modifying, deleting, or expanding the sample line items and sample table entries as needed. ]
Costs MUST reflect prices and rates quoted in accordance with ITB Clauses 14 and 15 (ITB Clauses 27 and 28 in the two-stage SBD).
Supply & Installation Prices
Line
Item
No.
Subsystem / Item
Locally
supplied
items
Supply and
Installation
Cost SubTable No.
[ insert:
Local
Currency ]
Price
[ insert:
Local
Currency ]
Price
[ insert:
Foreign
Currency A]
Price
[ insert:
Foreign
Currency B]
Price
[ insert:
Foreign
Currency C]
Price
--
--
--
--
--
Project Plan
--
Headquarters Subsystem
1.1
1.2
Database System
1.3
Training
333
Line
Item
No.
Subsystem / Item
Supply and
Installation
Cost SubTable No.
2.1
2.2
Training
j.1
j.2
j.3
Training
:
k
k.1
WAN
k.2
k.3
Training
Locally
supplied
items
[ insert:
Local
Currency ]
Price
[ insert:
Local
Currency ]
Price
[ insert:
Foreign
Currency A]
Price
[ insert:
Foreign
Currency B]
Price
[ insert:
Foreign
Currency C]
Price
334
Line
Item
No.
Supply and
Installation
Cost SubTable No.
Subsystem / Item
Locally
supplied
items
[ insert:
Local
Currency ]
Price
[ insert:
Local
Currency ]
Price
[ insert:
Foreign
Currency A]
Price
[ insert:
Foreign
Currency B]
Price
[ insert:
Foreign
Currency C]
Price
:
m
m
SUBTOTALS
- - indicates not applicable. indicates repetition of table entry above. Refer to the relevant Supply and Installation Cost SubTable for the specific components that constitute each Subsystem or line item in this summary table
Name of Bidder:
Authorized Signature of Bidder:
335
2.4
System or Subsystem number: [ if a multi-lot procurement, insert: Subsystem number, otherwise state entire System
procurement ] [ as necessary for the operation of the System, specify items in the Table below, modifying the sample line items
and sample table entries as needed. ]
Costs MUST reflect prices and rates quoted in accordance with ITB Clauses 14 and 15 (ITB Clauses 27 and 28 in the two-stage
SBD).
Post-Warranty Service Period
Quantities/Requirements
Component
No.
Component
1.
2.
3.
Relevant
Technical
Specifications
No.
Y4
336
Name of Bidder:
Authorized Signature of Bidder:
2.5
337
Line item number: [ specify: relevant line item number from the Supply and Installation Cost Summary Table (e.g., 1.1) ]
[ as necessary for supply, installation, and achieving Operational Acceptance of the System, specify: the detailed components and
quantities in the Sub-Table below for the line item specified above, modifying the sample components and sample table entries as
needed. Repeat the Sub-Table as needed to cover each and every line item in the Supply and Installation Cost Summary Table
that requires elaboration. ]
Prices, rates, and subtotals MUST be quoted in accordance with ITB Clauses 14 and 15 (ITB Clauses 27 and 28 in the two-stage
SBD). Unit prices for the same item appearing several times in the table must be identical in amount and currency.
Unit Prices / Rates
Supplied
Locally
Component
No.
1.1
Hardware
Finance
Department
1.1.1
Supply of
Advanced
workstations
1.1.2
1.1.3
--
--
Standard
Workstations
12
High-speed
Laser Printer
Total Prices
[ insert:
local
currency]
[ insert:
local
currency]
[ insert:
foreign
currency
A]
[ insert
foreign
currency
B]
[ insert:
foreign
currency
C]
--
--
--
--
--
Supplied
Locally
[ insert:
[ insert:
local
local
currency] currency]
[ insert:
foreign
currency
A]
[ insert:
foreign
currency
B]
[ insert:
foreign
currency
C]
338
1.1.4
1.1.5
Standardspeed Laser
Printer
Continuousfeed Printer
Total Prices
[ insert:
local
currency]
[ insert:
local
currency]
[ insert:
foreign
currency
A]
[ insert
foreign
currency
B]
[ insert:
foreign
currency
C]
1.1.6
Design and
Programming
Services
related to
Financial
Report
:1.1.7
Local
transport and
insurance
2.
LAN Headquarters
--
--
--
--
--
--
2.1
Supply of
Wiring Closet
Hardware
--
--
--
--
--
--
2.1.1
Hubs
Supplied
Locally
[ insert:
[ insert:
local
local
currency] currency]
[ insert:
foreign
currency
A]
[ insert:
foreign
currency
B]
[ insert:
foreign
currency
C]
339
Total Prices
[ insert:
local
currency]
[ insert:
local
currency]
[ insert:
foreign
currency
A]
[ insert
foreign
currency
B]
[ insert:
foreign
currency
C]
2.1.2
Punch-down
panel
2.1.3
Uninterrupte
d Power
Supply
(small)
2.1.4
Lockable
Equipment
Rack
2.2
In-Building
Wiring
--
--
--
--
--
--
2.2.1
Server Room
--
--
--
--
--
--
2.2.1.1
Dedicated
Telephone
Lines (data)
2 nodes
--
--
--
--
--
2.2.2
Backbone
and Risers
(Fiber optic)
28
nodes
2.2.3
Departmenta
l Wiring
--
Supplied
Locally
[ insert:
[ insert:
local
local
currency] currency]
[ insert:
foreign
currency
A]
[ insert:
foreign
currency
B]
[ insert:
foreign
currency
C]
340
2.2.3.1
Finance
Department
2.3
In-Building
Wiring
(Goods)
2.4
Local
transport and
insurance for
Region 1 sites
3.
Supply of
GeneralPurpose
Software
Total Prices
[ insert:
local
currency]
[ insert:
local
currency]
[ insert:
foreign
currency
A]
[ insert
foreign
currency
B]
[ insert:
foreign
currency
C]
--
--
--
--
--
--
--
--
--
--
--
--
40
nodes
--
Subtotals (to [ insert: line item ] of Supply and Installation Cost Summary Table)
Supplied
Locally
[ insert:
[ insert:
local
local
currency] currency]
[ insert:
foreign
currency
A]
[ insert:
foreign
currency
B]
[ insert:
foreign
currency
C]
341
2.6
Lot number: [ if a multi-lot procurement, insert: lot number, otherwise state single lot procurement ]
Line item number: [ specify: relevant line item number from the Recurrent Cost Summary Table (e.g., z.1) ]
Currency: [ specify: the currency of the Recurrent Costs in which the costs expressed in this Sub-Table are expressed ]
[ as necessary for operation of the System, specify: the detailed components and quantities in the Sub-Table below for the line
item specified above, modifying the sample components and sample table entries as needed. Repeat the Sub-Table as needed to
cover each and every line item in the Recurrent Cost Summary Table that requires elaboration. ]
Costs MUST reflect prices and rates quoted in accordance with ITB Clauses 14 and 15 (ITB Clauses 27 and 28 in the two-stage
SBD). Unit prices for the same item appearing several times in the table must be identical in amount and currency.
Entire System Procurement
Component
1.
2.
Relevant
Technical
Specifications
No.
Y4
342
3.
Component
Relevant
Technical
Specifications
No.
Name of Bidder:
Authorized Signature of Bidder:
343
2.7
Country of Origin
Country
Code
Country Code
Country of Origin
Country
Code
346
3.1
Manufacturers Authorization
.
We hereby confirm that, in case the bidding results in a Contract between you and
the Bidder, the above-listed products will come with our full standard warranty.
Name
In the capacity of
Signed
Duly authorized to sign the authorization for and on behalf of :
________________________
Note: This authorization should be written on the letterhead of the Manufacturer and be
signed by a person with the proper authority to sign documents that are binding on the
Manufacturer.
347
3.2
Item
348
3.3
Software List
Software Item
System
Software
GeneralPurpose
Software
Application
Software
Standard
Software
Custom
Software
349
3.4
350
Name of firm
2.
3.
Telephone
Contact
4.
Fax
Telex
5.
Nationality of owners
Name
Nationality
1.
2.
3.
4.
5.
/
351
Turnover
US$ equivalent
1.
2.
3.
4.
5.
/
bids
352
Total value of annual turnover, in terms of Information System billed to clients, in US$
equivalent, converted at the rate of exchange at the end of the period reported:
Annual turnover data (applicable activities only; US$ equivalent)
Partner
1. Partner
in charge
2. Partner
3. Partner
4. Partner
5. Partner
6. Etc.
Totals
Form
3.5.2
page
no.
Year 1
Year 2
Year 3
Year 4
Year 5
353
354
Number of contract
Name of contract
Country
2.
Name of Purchaser
3.
Purchaser address
4.
Nature of Information Systems and special features relevant to the contract for which
the Bidding Documents are issued
5.
Prime Supplier
Management Contractor
Subcontractor Partner in a
Joint Venture
6.
7.
Currency
Currency
Subcontract: $_______;
8.
Date of award/completion
9.
Contract was completed _____ months ahead/behind original schedule (if behind,
provide explanation).
10.
Contract was completed US$ _________ equivalent under/over original contract amount
(if over, provide explanation).
11.
12.
Indicate the approximate percent of total contract value (and US$ amount) of
Information System undertaken by subcontract, if any, and the nature of such
Information System.
355
1.
2.
3.
4.
5.
etc.
Purchaser,
Value of
contact
outstanding
address/tel./fax Information
System (current
US$ equivalent)
Estimated
completion date
Average monthly
invoicing over
last six months
(US$/month)
356
Name of banker
Address of banker
Telephone
Fax
Telex
Summarize actual assets and liabilities in U.S. dollar equivalent (at the rates of
exchange current at the end of each year) for the previous five calendar years. Based
upon known commitments, summarize projected assets and liabilities in U.S. dollar
equivalent for the next two calendar years, unless the withholding of such
information by stock market listed public companies can be substantiated by the
Bidder.
Financial
information in
US$ equivalent
Actual:
Projected:
5
1. Total assets
2. Current
assets
3. Total
liabilities
4. Current
liabilities
5. Profits
before taxes
6. Profits after
taxes
357
1.
2.
3.
4.
358
1.
Title of position
Name of prime candidate
Name of alternate candidate
2.
Title of position
Name of prime candidate
Name of alternate candidate
3.
Title of position
Name of prime candidate
Name of alternate candidate
4.
Title of position
Name of prime candidate
Name of alternate candidate
359
Position
Candidate
Candidate
information
Name of candidate
Prime
Alternate
Date of birth
Professional qualifications
Present
employment
Name of Employer
Address of Employer
Telephone
Fax
Telex
To
Company/Project/
experience
Position/Relevant
technical
and
management
360
361
Award FOR Name of client, cause of litigation, and matter Disputed amount
or AGAINST in dispute
(current value, US$
Bidder
equivalent)
362
4. BID-SECURING DECLARATION
IFB: [insert: title and number of IFB]
To: [insert: name and address of Purchaser]
We, the undersigned, declare that:
We understand that, according to your conditions, bids must be supported by a BidSecuring Declaration.
We accept that we, and in the case of a Joint Venture all partners to it, will
automatically be suspended from being eligible for participating in bidding for any
contract with you for the period of time of [Purchaser insert: number of months or
years], in case of, and starting from the date of, breaching our obligation(s) under the
bidding conditions due to:
(a)
withdrawing our bid, or any part of our bid, during the period of bid validity
specified in the Bid Submission Form or any extension of the period of bid
validity which we subsequently agreed to; or
(b)
having been notified of the acceptance of our bid by you during the period of
bid validity, (i) failing or refusing to execute the Contract Agreement, or (ii)
failing or refusing to furnish the performance security, if required, in
accordance with the Instructions to Bidders.
We understand this Bid-Securing Declaration shall expire if we are not the successful
Bidder, upon the earlier of (i) our receipt of your notification to us of the name of the
successful Bidder; or (ii) twenty-eight days after the expiration of the period of bid
validity.
If the submission of alternative bids was permitted, and in case we did submit one or
more alternative bids, this Bid-Securing Declaration applies to these parts of our bid
as well.
Signed: [insert: signature of person whose name and capacity are shown below]
Name: [insert: name of person signing the Bid-Securing Declaration], in the capacity
of [insert: legal capacity of person signing the Bid-Securing Declaration]
Duly authorized to sign the bid for and on behalf of: [insert: name of Bidder]
Dated on ____________ day of __________________, 20__
[add Corporate Seal (where appropriate)]
363
[Note to Bidders: Joint Ventures need to ensure that, their Bid-Securing Declaration meets the
requirements for Joint Ventures as stated in the ITB Clause on "Securing the Bid".]
364
has withdrawn the Bid (or any parts of it) during the period of bid validity
specified by the Bidder in the Bid Submission Form or any extension of the
period of bid validity which the Bidder subsequently agreed to; or
(b)
having been notified of the acceptance of the Bid by you during the period of
bid validity, (i) failed or refused to execute the Contract Agreement, or (ii)
failed or refused to furnish the performance security, if required, in
accordance with the Instructions to Bidders.
This guarantee will expire: (a) if the Bidder is the successful bidder, upon our receipt
of copies of the contract signed by the Bidder and the performance security issued to
you upon the instruction of the Bidder; or (b) if the Bidder is not the successful
bidder, upon the earlier of (i) our receipt of a copy of your notification to the Bidder
of the name of the successful bidder; or (ii) twenty-eight days after the expiration of
the Bid's validity.
Consequently, any demand for payment under this guarantee must be received by us
at the office on or before that date.
365
This guarantee is subject to the Uniform Rules for Demand Guarantees, ICC
Publication No. 458.
_____________________________
[Signature(s)]
[Note to Bidders: Instructions on amount and currency can be found in the ITB Clause and BDS for
"Securing the Bid." Joint Ventures need to also ensure that their Bank Guarantee meets the requirements
for Joint Ventures as provided in the same Clause.]
366
withdraws the Bid (or any parts of it) during the period of the Bid's validity
specified in the Bid Submission Form, or any extension of the period of the
Bid's validity the Principal subsequently agreed to, notice of which to the
Surety is hereby waived; or
(b)
having been notified of the acceptance of the Bid by the Purchaser during the
period of the Bid's validity, (i) fails or refuses to execute the Contract
Agreement, or (ii) fails or refuses to furnish the performance security, if
required, in accordance with the Instructions to Bidders;
then the Surety undertakes to immediately pay to the Purchaser up to the above
amount upon receipt of the Purchaser's first written demand, without the Purchaser
having to substantiate its demand, provided that in its demand the Purchaser shall
state that the demand arises from the occurrence of any of the above events,
specifying which event(s) has/have occurred.
The Surety hereby agrees that its obligation will remain in full force and effect up to
and including the date 28 days after the date of expiration of the Bid's validity.
IN TESTIMONY WHEREOF, the Principal and the Surety have caused these presents to
be executed in their respective names this ____ day of ____________ 20__.
Principal: _______________________
______________________________
Surety:
367
_______________________________
___________________________________
_
[state: printed name and title]
[Note to Bidders: Instructions on amount and currency can be found in the ITB Clause and BDS for
"Securing the Bid." Joint Ventures need to also ensure that their Bid Bond meets the requirements for
Joint Ventures as provided in the same Clause.]
368
5. CONTRACT AGREEMENT
THIS CONTRACT AGREEMENT is made
the [ insert: ordinal ] day of [ insert: month ], [ insert: year ].
BETWEEN
(1)
(2)
WHEREAS the Purchaser desires to engage the Supplier to supply, install, achieve
Operational Acceptance of, and support the following Information System [ insert:
brief description of the Information System ] (the System), and the Supplier has
agreed to such engagement upon and subject to the terms and conditions appearing
below in this Contract Agreement.
NOW IT IS HEREBY AGREED as follows:
Article 1.
Contract
Documents
1.1
369
(f)
1.2
1.3
Article 2.
2.1
Contract Price
and Terms of
Payment
Article 3.
Effective Date
for
Determining
Time for
Operational
Acceptance
3.1
370
Clause 13.3;
(c)
Article 4.
3.2
If the conditions listed under 3.1 are not fulfilled within two
(2) months from the date of this Contract Agreement
because of reasons not attributable to the Supplier, the
parties shall discuss and agree on an equitable adjustment to
the Contract Price and the Time for Achieving Operational
Acceptance and/or other relevant conditions of the Contract.
4.1
4.2
Appendixes
APPENDIXES
Appendix 1.
Appendix 2.
Appendix 3.
Appendix 4.
Appendix 5.
Appendix 6.
Appendix 7.
Suppliers Representative
Adjudicator [if there is no Adjudicator, state not applicable]
List of Approved Subcontractors
Categories of Software
Custom Materials
Revised Price Schedules (if any)
Minutes of Contract Finalization Discussions and Agreed-to
Contract Amendments
371
IN WITNESS WHEREOF the Purchaser and the Supplier have caused this Agreement to
be duly executed by their duly authorized representatives the day and year first
above written.
For and on behalf of the Purchaser
Signed:
in the capacity of [ insert: title or other appropriate designation ]
in the presence of
For and on behalf of the Supplier
Signed:
in the capacity of [ insert: title or other appropriate designation ]
in the presence of
CONTRACT AGREEMENT
dated the [ insert: number ] day of [ insert: month ], [ insert: year ]
BETWEEN
[ insert: name of Purchaser ], the Purchaser
and
[ insert: name of Supplier ], the Supplier
372
[ insert: name and provide title and address further below, or state
to be nominated within fourteen (14) days of the Effective Date ]
Title:
In accordance with GCC Clause 4.3, the Supplier's addresses for notices under the
Contract are:
Address of the Supplier's Representative: [ as appropriate, insert: personal
delivery, postal, cable, telegraph, telex, facsimile, electronic mail, and/or EDI
addresses. ]
373
Appendix 2. Adjudicator
In accordance with GCC Clause 1.1 (b) (vi), the agreed-upon Adjudicator is:
In accordance with GCC Clause 6.1.3, the agreed-upon fees and reimbursable
expenses are:
Pursuant to GCC Clause 6.1.4, if at the time of Contract signing, agreement has not
been reached between the Purchaser and the Supplier, an Adjudicator will be
appointed by the Appointing Authority named in the SCC.
374
Item
Approved Subcontractors
Place of Registration
375
Software Item
System
Software
GeneralPurpose
Software
Application
Software
Standard
Software
Custom
Software
376
Custom Materials
377
378
379
380
6.1
________________________________
[insert: Banks Name, and Address of Issuing Branch or Office]
Beneficiary: [insert: Name and Address of Purchaser]
Date: [insert: date]
PERFORMANCE GUARANTEE No.: [insert: Performance Guarantee Number]
We have been informed that on [insert: date of award] you awarded Contract No.
[insert: Contract number] for [insert: title and/or brief description of the Contract]
(hereinafter called "the Contract") to [insert: complete name of Supplier] (hereinafter
called "the Supplier"). Furthermore, we understand that, according to the conditions
of the Contract, a performance guarantee is required.
At the request of the Supplier, we hereby irrevocably undertake to pay you any
sum(s) not exceeding [insert: amount(s)1 in figures and words] upon receipt by us of
your first demand in writing declaring the Supplier to be in default under the
Contract, without cavil or argument, or your needing to prove or to show grounds or
reasons for your demand or the sum specified therein.
On the date of your issuing, to the Supplier, the Operational Acceptance Certificate
for the System, the value of this guarantee will be reduced to any sum(s) not
exceeding [insert: amount(s)1 in figures and words]. This remaining guarantee shall
expire no later than [insert: number and select: of months/of years (of the Warranty
Period that needs to be covered by the remaining guarantee)] from the date of the
Operational Acceptance Certificate for the System,2 and any demand for payment
under it must be received by us at this office on or before that date.
This guarantee is subject to the Uniform Rules for Demand Guarantees, ICC
Publication No. 458, except that subparagraph (ii) of Sub-article 20 (a) is hereby
excluded.
_______________________
[Signature(s)]
The bank shall insert the amount(s) specified and denominated in the SCC for GCC Clauses
13.3.1 and 13.3.4 respectively, either in the currency(ies) of the Contract or a freely
convertible currency acceptable to the Purchaser.
In this sample form, the formulation of this paragraph reflects the usual SCC provisions for
GCC Clause 13.3. However, if the SCC for GCC Clauses 13.3.1 and 13.3.4 varies from the
usual provisions, the paragraph, and possibly the previous paragraph, need to be adjusted to
precisely reflect the provisions specified in the SCC.
381
6.2
________________________________
[insert: Banks Name, and Address of Issuing Branch or Office]
Beneficiary: [insert: Name and Address of Purchaser]
Date: [insert: date]
ADVANCE PAYMENT GUARANTEE No.: [insert: Advance Payment Guarantee Number]
We have been informed that on [insert: date of award] you awarded Contract No.
[insert: Contract number] for [insert: title and/or brief description of the Contract]
(hereinafter called "the Contract") to [insert: complete name of Supplier] (hereinafter
called "the Supplier"). Furthermore, we understand that, according to the conditions
of the Contract, an advance payment in the sum of [insert: amount in numbers and
words, for each currency of the advance payment] is to be made to the Supplier
against an advance payment guarantee.
At the request of the Supplier, we hereby irrevocably undertake to pay you any sum
or sums not exceeding in total the amount of the advance payment referred to
above, upon receipt by us of your first demand in writing declaring that the Supplier is
in breach of its obligations under the Contract because the Supplier used the advance
payment for purposes other than toward the proper execution of the Contract.
It is a condition for any claim and payment to be made under this guarantee that the
advance payment referred to above must have been received by the Supplier on its
account [insert: number and domicile of the account].
For each payment after the advance payment, which you will make to the Supplier
under this Contract, the maximum amount of this guarantee shall be reduced by the
ninth part of such payment.3 At the time at which the amount guaranteed becomes
nil, this guarantee shall become null and void, whether the original is returned to us
or not.
This guarantee is subject to the Uniform Rules for Demand Guarantees, ICC
Publication No. 458.
______________________
[Signature(s)]
This sample formulation assumes an Advance Payment of 10% of the Contract Price
excluding Recurrent Costs, and implementation of the main option proposed by this SBD in
the SCC for GCC Clause 13.2.2 for gradually reducing the value of the Advance Payment
Security. If the Advance Payment is other than 10%, or if the reduction in amount of the
security follows a different approach, this paragraph would need to be adjusted and edited
accordingly.
382
383
7.1
Installation Certificate
Date: [ insert: date ]
384
7.2
[ insert:
This letter shall not relieve you of your remaining performance obligations
under the Contract nor of your obligations during the Warranty Period.
For and on behalf of the Purchaser
Signed:
Date:
in the capacity of: [ state:
Purchasers organization ]
385
386
8.1
2.
3.
4.
5.
6.
387
Description
7.
8.
Procedures to be followed:
(a)
Your Change Proposal will have to show what effect the requested Change
will have on the Contract Price.
(b) Your Change Proposal shall explain the time it will take to complete the
requested Change and the impact, if any, it will have on the date when
Operational Acceptance of the entire System agreed in the Contract.
(c)
(d) You should also indicate what impact the Change will have on the number
and mix of staff needed by the Supplier to perform the Contract.
(e)
9.
You shall not proceed with the execution of work related to the requested
Change until we have accepted and confirmed the impact it will have on
the Contract Price and the Implementation Schedule in writing.
As next step, please respond using the Change Estimate Proposal form,
indicating how much it will cost you to prepare a concrete Change Proposal that
will describe the proposed approach for implementing the Change, all its
elements, and will also address the points in paragraph 8 above pursuant to GCC
Clause 39.2.1.
Your Change Estimate Proposal should contain a first
approximation of the proposed approach, and implications for schedule and
cost, of the Change.
388
8.2
2.
3.
4.
5.
Initial Cost Estimate for Implementing the Change: [insert: initial cost estimate]
6.
Cost for Preparation of Change Proposal: [ insert: cost in the currencies of the
Contract ], as detailed below in the breakdown of prices, rates, and quantities.
389
390
8.3
2.
3.
4.
5.
6.
391
to the amount estimated for this purpose in the Change Estimate Proposal, in
accordance with GCC Clause 39 of the General Conditions of Contract.
For and on behalf of the Purchaser
Signed:
Date:
in the capacity of: [ state:
Purchasers organization ]
392
8.4
2.
3.
4.
5.
6.
7.
Description
393
8.
9.
10.
11.
Effect on the other terms and conditions of the Contract: [ insert: description ]
12.
Validity of this Proposal: for a period of [ insert: number ] days after receipt of
this Proposal by the Purchaser
13.
Procedures to be followed:
(a)
(b) The amount of any increase and/or decrease shall be taken into account in
the adjustment of the Contract Price.
For and on behalf of the Supplier
Signed:
Date:
in the capacity of: [ state: Suppliers Representative or other higher level authority
in the Suppliers organization ]
394
8.5
(Purchasers Letterhead)
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem and
number of Contract ]
To: [ insert: name of Supplier and address ]
Attention: [ insert: name and title ]
Dear Sir or Madam:
We hereby approve the Change Order for the work specified in Change Proposal
No. [ insert: number ], and agree to adjust the Contract Price, Time for Completion,
and/or other conditions of the Contract in accordance with GCC Clause 39 of the
Contract.
1.
2.
3.
4.
5.
395
7.
396
8.6
2.
3.
4.
5.
6.
7.
397
8.