2 - TOR - Specs (IMIS) 2.0

[Name of Client] Technical Terms of Reference
[Name of Client]
………………………………..
………………………………..
Contract Number: number
Supply and Implementation ofan Integrated

Management Information System for [name of Client]
Month / Year
Technical Terms of Reference
Table of Contents
1. Introduction...................................................................................................2
2. System Requirements..................................................................................4
3. Scope of Work............................................................................................17
4. Project Area................................................................................................21
5. Instructions to Bidders................................................................................23
488571860.docx Page: 1
1. Aims and Objectives of Project

1.1 The main objective of the project is the procurement and proper
implementation of Commercial and Technical Management Information
systemsthat conform to industry best practices and are able to meet all of
the Utility’s commercial and technical information requirements.
2. General- System Requirements

2.1 General
2.1.1 User friendly: The system must make use of the latest advances in IT
supporting industry standards such as Windows and NT, object-
oriented programming web-enabling, report generators, open client-
server and multi-tiered architecture. The systems must employ a
modular software design, enabling phased implementation and employ
distributed and scalable system architecture that allowing any system
size and configuration, whether in standalone mode, or in a multi-user
and multi-tiered distributed fashion.
2.1.2 Numerical database: The system should be able to support the latest
versions of both Oracle and Microsoft SQL databases. It should include
appropriate functionality with regard to (a) Backup and data recovery,
(b) Audit trails, (c) Data protection mechanisms and (d) Master data
dictionaries
2.1.3 Extensibility & integration: All proposed software modules must share
the same data model covering the entire range of Commercial and
Technical Utility functions.
2.1.4 Flexible System configuration and administration: The system should
allow for flexible parameterization in the following areas:
1) Help: The system must provide full context sensitive help
2) Localization: It should be possible to localise the system in any
language if required in an easy manner.
3) Project: The user should be able to define project parameters and
look up values (e.g. meter types).
2.1.5 Locate MechanismA mechanism must exist that is able to combine
available information to assist the user to pin point a graphical element.
The system must be customisable to locate elements depending on
available information such as street addresses, XY co-ordinates or links
to other elements.
2.1.6 Authorisation Control: The system must provide for parameterisable
user access rights to system functions. The user must be able to define:
the authorisation access to each module, a specific form or even a
specific field or operation per post; User Name and Password for each
employee and Audit trail criteria to record changes to the database and
trace changes to users. A strong password policy can be defined such
488571860.docx Page: 2
that will include various attributes like enforcing alphanumeric

passwords, of certain minimum length, expiry period etc.
2.1.7 System Maintenance:
1) General: The system must provide a set of tools in order to
perform maintenance tasks on the database. Special exception
reports must be provided to isolate specific inconsistencies
between tables or data contained in tables.
2) "Ad-hoc Backup & Restore": The system should be able to backup
and restore a database on ad-hoc basis in few steps using a
wizard
3) Scheduled Backups: The system must allow scheduling of daily
backups of the database and auto-compression of backup files
4) Upgrade database: The system should be able to synchronise
database version to software version in few steps using a wizard
and the latest html scripts.
5) Repair Database objects: The system should be able to re-index
tables, re-create database users triggers and views to improve
database performance and/or fix any database object
6) Merge Databases: The system should allow merging of two or
more databases in few simple steps
2.1.8 Geographical Information systems: The system should incorporate its
own GIS system making use of either shapefiles and/ or ESRI ArcGIS
Server software. It should further be able to use “Google-Earth” as
background for easier geographical reference.
2.1.9 Asset Location Referencing system: The system must include a
comprehensive system for locating and referencing network assets.
Acknowledging that in daily practice most assets are related to town-
planning features, assets must be referenced/ located by relating them
to Addresses, Streets and Landmarks. The system must adopt a
standard address encoding protocol for address encoding providing an
all-encompassing description of an address. Standardizing addresses
assists in (a) Establishing a common vocabulary for addresses; b)
Enabling address data interoperability and facilitating collation of
address data.
2.1.10 Linear referencing system (LRS): The Assets Location Referencing
system must be combined with a LRS where one can associate
attributes or events to locations or portions of a linear feature, such as a
pipe, a road or a railway. For example a road segment can be
associated with three event attributes such as the road surface, the
speed limit and the number of lanes. The event sections of the linear
feature should be referenced and created dynamically by indicating the
start and end locations along the feature without explicitly storing them.
488571860.docx Page: 3
2.1.11 Integration with ERP Systems: The systems should interface with the
Utility’s Financial systems as well as Stores, Support Services and
Human Resources systems, as follows:
1) Financial: The proposed system (Billing &Customer services)
effectively deals with all the accounting entries relating to debtors
and assumes responsibility for the entire revenue collection and
debt management functions. The interface will post all appropriate
summary figures to the Financial system
2) Stores: to establish availability of goods and costs and to forward
requisitions. If Utility's store system does not exist, the proposed
system should keep its own stores item list.
3) Support Services: to establish availability of plant and equipment
and costs and requisition such. If the Utility's support services
system does not exist, the proposed system should keep its own
plant and equipment item list.
4) Human resources (HR) to establish availability of skills and
workload of personnel. In the absence of such a system the
proposed system should keep its own HR information.
2.1.12 Reporting should include queries, graphical templates, mapping and.
A selection of common reports should pre-exist whilst the user should
be able to make custom made reports.
2.1.13 Communications: A centralized installation at the head-quarters of the
Utility is preferred. Branch offices will be linked through dedicated lease
lines or through the internet using a service provider, with users either
working on Web-applications or linked to head-quarters through VPN
(virtual private network) technology. In the odd case of neither of the
above being possible a decentralised solution should be deployed and
the proposed system should being able to synchronise databases on a
regular basis.
2.1.14 Deployment: The system should be deployed with various user and
authorization access codes as required for each module and relevant
function.
2.2 Land Information system (LIS)

2.2.1 Understanding:
1) An LIS is a GIS-based system used to manage and maintain Land
parcel information, including town planning data (land parcel, plot,
building, property).
2) Keeping and maintaining such data is not the responsibility of a
Utility but of local/ central government. In many cases, however
such information is unavailable or highly inaccurate.
3) Importance of geo-referencing connections: It is important that all
connections in the billing system are geo-referenced.In the ideal
situation the connection is attached to a property which is attached
488571860.docx Page: 4
to a building which is attached to a plot. As a result it becomes

possible to (a) automatically identify all properties without a
registered connection, (b) automatically attach the connection to the
distribution network for the purposes of Water balancing and
demand analysis (see sections that follow).
2.2.2 An LIS module must be supplied and it will form the basis of
integrating the commercial data with the distribution system for the
purpose of (a) identifying un-registered connections, (b) Balancing per
zone and (c) Demand Analysis
2.2.3 Use of LIS: Depending on current data availability each Utility will
choose the most appropriate way forward in achieving the objectives
said above. In the case of the current Billing database not having a link
to a reliable LIS database (most cases) the Utility will:
1) Use GPS (Global positioning systems) equipment to locate the
position of all the connections as given in the Billing system
2) Compile a LIS database using one of the following options
depending on data availability:
a) Use whatever data is available and update it accordingly through
field surveys on a continuous basis.
b) Use satellite imagery to establish a buildings database (by
digitizing building boundaries) and gradually build up a properties
database for each building through the connections
2.2.4 The LIS should be able to automatically link the GPS connections to
the LIS database. The LIS system supplied should have the
functionality to perform this function
3. Commercial systems (Billing & Customer Services)

3.1 Commercial Data Management
3.1.1 Purpose: The commercial database forms the backbone of all the
commercial operations, i.e.: Customer services, metering and billing
and revenue and debt management.
3.1.2 Commercial Management Data Model: The Data Model should include
all required entities for a full commercial management data model so
that a proper relationship between the entities is supported. Entities
include tenant, owner, plot, property, connection and meter. The data
model must support multiple connections to a property and multiple
properties to a plot, keep track of current and previous tenants and
owner(s).
3.1.3 Financial: The System shall maintain a (a) Statements Database that
shall include statement no, statement date, transactions, opening
balance, closing balance and arrears aging information, a (b)
Transactions Database that shall include transactions relating to :
invoicing, receipting, cash and adjustment transactions, penalties, dates
488571860.docx Page: 5
of transactions with a drill down facility, a (c) Receipting Database that

shall include : payments transactions for all system charges as well as
cash sales and (d) a Debt Management Database that shall include :
Reminders, disconnections, reconnections, bad debts history and setup
of different Debt Management policies.
3.1.4 Customer Services Database: The Customer Services data model
should be able but not limited to record all Customer Applications with
application information, request date, due date and completion status,
as well as Request for Activities where field work is required with
activity information, request date, due date, completion status, user
submitted and user authorized, scheduling of staff, equipment, vehicles
and other support resources, stores requisitions and others.
3.1.5 Commercial Database: The Commercial database shall include but
not be limited to a (a) Customer Database with records on customer
name, contact details, customer type, customer's application history,
debt management history and other customer attributes, a (b)
Connections Database with records for multiple services e.g. Sewer,
Water and Electricity : connection details, connection date, meters
installed history, connection status and allowance for zone reference, a
(c) Meters Database with the following data: meter make, meter type,
meter size, no of dials (for clock over cases), meter condition and store
location and (d) a Meter Reading Database, that includes: meter
readings history, reading dates, consumption information, meter reader
messages, note codes and reading validation information.
3.1.6 Data Conversion module: The system should allow Mapping,
conversion and importing of legacy data or any other data in digital
format. It should be noted that in performing data conversion from the
legacy system the system should produce discrepancy reports such as
(1) Orphan transactions, (2) Inconsistent Customer balances vs.
transaction totals and (3) Customers without transactions. Such
discrepancies will be investigated by the Utility prior to going live with
the system. The ability of the conversion process to immediately identify
problematic data is expected to result in an immediate improvement in
the Utility’s performance.
3.2 Commercial System configuration and administration

3.2.1 Station Synchronisation: The system must make provision for the
flexible deployment of stations. It should be able to manage
synchronization of offline databases through import and export routines
allowing for the flexible deployment of the system when a WAN is not
available
3.2.2 The system should allow for flexible parameterization of all parameters
required for setting up the system as per user requirements without
resorting to software code intervention
3.2.3 Project setup:
488571860.docx Page: 6
1) The user should be able to define project parameters such as

database and GIS links.
2) The user should be able to define various water elements, such as
connections and their link to GIS file
3) The user should be able to define look up values (e.g. banks,
ways of communication, complaint types and subtypes, consumer
types, meter types, meter makes, application priority levels,
rejection reasons, mandatory fields and others)
3.2.4 Components: The user must be able to define/ edit important
components, such as: Set up and edit activities, applications,
consumption categories and ledger accounts which are allocated to
financial transactions.
3.2.5 Receipting: The system should be able to define receipting related
parameters and parameters for controlling cashiers
3.2.6 Tariff structure: Should be user definable in terms of different
consumer categories and in terms of: Service deposits (fixed / variable),
Regular (time wise) charges (fixed / variable), Consumption Charges by
consumption rate per band, Activity charges like connection fees or
other application fees required, Surcharges or additional charges, VAT
charges, Cash Sales Costs, Statement Charges, Receipting Charges,
Penalties and any other possible charges that might be required. It
should be possible to create multiple tariffs and link them to customers
according to their consumer category, meter size or other related
characteristics.
3.2.7 Look up tables: The user should be able to define look up tables for all
relevant variables, such as meter types, meter makes, complaint types,
consumer types, application priority levels and other mandatory fields.
3.2.8 Consumption Categories: The system should allow definition of
different relevant categories like Consumption types, Land-use types,
properties, etc.. The system should be able to perform automatic
evaluations of relationships between heterogeneous categories, for
example: Land Uses versus Consumption types
3.2.9 Data Conversion: The system should provide tools used for routine
import of various data files to the system from other external sources or
systems like the import of Bank collection files, meter readings from
external source and other similar functions.
3.2.10 Custom Fields: User should be able to create additional fields in
various forms that may not be available. The steps to create them
should be simple and should not require the modification of the software
code to achieve that.
3.3 Management reports

3.3.1 Management Reporting: Management reporting should be available.
This should be easy to access and easy to operate to ease
488571860.docx Page: 7
Management staff to extract the various data from all modules of the
system from one single place or dashboard. The reporting should cover
all facets of the system using different tools embedded in the system to
produce numerical reports, Pie or other types of charts. Standard
available reports should cover: 1) Billing Reports, 2) Customer Services
Reports, 3) Debt Management Reports, 4) Enquiries Reports, 5)
Financial Reports, 6) Meter Reading Reports, 7) Receipting Reports
and. Entity related Management reports must also be available
(customer, property, connection or meter) providing various entity
statistics and exception reports. It should be possible to extract
Numerical reports into other formats like Excel, pdf, word, csv or others.
3.3.2 Be able to produce special “Watch Lists” of special customers for
closer monitoring.
3.3.3 Queries and Performance Indicators: The system should provide a list
of Queries and Performance Indicators (PI). The system must provide a
standard list of such queries and PI though. The user should also be
able to easily register new ones.
3.3.4 Audit Trail: The system should be configurable to monitor a detailed
audit trail analysis showing who, what and when something has been
updated or deleted in the database.
3.4 Enquiries and Customer Reports

3.4.1 General: The system must provide the user with access to all
information available in the system. A user must be able to make
enquiries on billing entities to gather information for internal use or to
answer customer enquiries. The system must enable the user to
answer customer questions in a timely and accurate manner both in
person and over the telephone.
3.4.2 Search Functions: The system must enable the user to access
information using attributes of the Customer, Meter and Property
entities to for searching, giving the user the ability to search on a wide
variety of keys for easy information retrieval. For example the user must
be able to search by the customer, meter and property/connection
attributes.
3.4.3 Customer Reports: The system must provide informative reports that
can be printed on customer request for the use of providing feedback to
customer enquiries. The system must be able to (1) print an interim
statement, (2) re-print issued statements and (3) print a schedule of
processed payments due to customer agreements and (4) other
Customer related reports like letters, notifications and others. The
system should be able to email directly the selected report as
attachment to customer with a click of a button. Where possible, the
system should also support the sending of customized SMS messages
to customers.
488571860.docx Page: 8
3.4.4 Enquiries History: The user should be able to capture in the system
the details of any simple queries from customers for further analysis
and operators’ performance evaluation. It should be able to record the
way of communication, the details of the query, classification of query,
date and time recorded, operator who responded.
3.5 Commercial Data Evaluation(CDE) & Customer Contact centre

3.5.1 The Commercial Data Evaluation module is expected to be run by the
Utility on a regular basis and will form the basis of identifying “apparent”
losses; resulting fieldwork will result in higher revenues. The module
should produce discrepancy lists summarized in a report with regard to:
1) Suspect meter readings
2) Missing data analysis exception report addressing: Plots,
Properties (dwellings), Connections, Consumption meters,
Customers information
3) Exceptions Analysis Reports (relationships between elements),
including: Plots vs. Properties, Connections vs. Consumptions,
Connections vs. Meters, Connections vs. Walk Routes, Consumer
vs. Properties, Consumer Categories Usage, Consumer Categories
Reconciliation (correct assignment)
4) Suspect problem meters: - List of meters that might need
replacing, including: Oversized Meters, Undersized Meters,
Malfunctioning Meters, stuck-meters
3.5.2 A Customer Contact centre module should exist, preferably that can
be operated through the web, whereby a customer can be contacted in
an organised manner with regard to addressing discrepancies identified
in the CDE analysis. The module should be able to keep records with
regard to contacts and further be able to communicate with the various
departments to initiate appropriate action.
3.6 Customer Services and Connections/meter management System

3.6.1 General: The system should enable the user to submit and manage all
the applications, requests, complaints or activities related directly or
indirectly to customers and his/her possessions and provide necessary
feedback
3.6.2 Connections/Meters Management: The system should make provision
for the management of maintenance tasks relating to connections and
meters generated by the meter reading cycle, other departments and
through ad hoc Connection/ Meter Repairs like the exchange of a
broken or problematic meter; the installation of a new meter in a
property; Meter/ connection repairs; To remove a meter from a
Property. These requests may be internally initiated or triggered by
other modules like Meter Reading (e.g. meter readers notes)
3.6.3 Stores interface: The system should be able to update the register of
meters in the Organisation's stores management system and in a meter
488571860.docx Page: 9
register held within the billing system. Allow the movement of meters
from one warehouse to another
3.6.4 Scheduling of Resources: The system should be able to schedule
staff, equipment, vehicles and other support resources, issue stores
requisitions, produce a job cost and others
3.6.5 Authorisation control should be based on user level allowing for review
and authorisation of applications by supervising officers
3.6.6 Workflow Design: User should be able to design the workflow to be
followed in all types of Applications such that they follow Organisation’s
business processes. User can define additional workflows for new
business processes related to Customers.
3.6.7 Submission of Applications/Requests: The system should
1) Provide a solution for the submission of customer applications
relating to both customer accounts and services provided by the
organisation.
2) Provide the ability to create custom applications for various
purposes and configure application workflow, notifications,
assignment task and access rights policy to meet organisation's
needs and policies.
3) Provide applications related to the customer details and
complaints, applications for services relating to existing services
and applications which deal with new metered or non-metered
services.
4) Allow Application forms to be viewed and printed for each
application type. Allow emailing of forms to customer or other staff
of the Organisation. The system should also have the
infrastructure to send SMS of short texts to customers for adhoc
notifications
5) Be able to capture details of any oral communication related to the
application for reference, with either customer or another
employee of the Organization or other.
6) Allow to assign the application, request or complaint to any other
employee and notify them for the assignment and/or send email to
notify.
7) Make provision for a mechanism for generating automatically
tasks from applications that have been logged where field work is
needed.
8) Restrict the escalation of the application at different stages of the
workflow of pre-defined post. Make sure that an application cannot
be authorized by the same user who has initiated that.
3.6.8 Applications types: Applications should include but not be limited to:
1) New Connection Investigation
488571860.docx Page: 10
2) New Connection
3) Temporary Connection
4) Voluntary Disconnection / Reconnection
5) Termination of Service by Tenant
6) Allocation of Service to a Tenant
7) Provision of other services
8) Meter exchange/removal/installation/repair/test
9) Customer Complaints: Be able to divert the problem to different
employee or department depending on the nature of problem.
10) Any other type of application: Be able to define new Application
types and design the appropriate workflow and access rights.
3.6.9 Application search capability: The system should have a user friendly
dashboard listing all applications/requests. It should be able to query,
retrieve and print any kind of customer service application submitted.
The system should provide multiple search criteria like application no,
customer account or name, status of application, type of application,
date range and others.
3.6.10 Processing Cycle: The system should be able to manage the
processing cycle as tasks generated by customer applications are
scheduled, completed and managed. The system should also be able
to query, retrieve and print any kind of tasks that has been generated
from a customer application.
3.6.11 GIS Link: The system should be able to link to GIS or Google Earth to
pin point the plot/property of the application and if take a snapshot of
the map to include in the work order or any other form.
3.6.12 Be able to upload attachments or use hyperlinks related to each
specific application. These should be accessible by any user of the
system that has access to the specific application
3.6.13 .Reporting: The system should:
1) Provide various management reports
2) Make provision for management and year-end reports
3) Provide summary and list reports reports for a specified period
4) Provide reports or queries on requests. These reports will be used
to manage the activity cycle relating to customer applications and
will be used to monitor department performance
3.7 Financial Services

3.7.1 General: The system should make provision for the management of
financial transactions other than regular consumption and service
transactions. It should have easy menu navigation and validation
checks should be in place to ensure accurate and easy data entry.
488571860.docx Page: 11
Authorisation control should be based on user level and allow for

review and authorisation of applications by supervising officers.
Authorisation level should be scalable depending on the amount of the
financial transaction. Make sure that a financial application cannot be
authorized by the same user who has started it.
3.7.2 Workflow Design: User should be able to design the workflow to be
followed in all types of Applications such that they follow Organisation’s
business processes. User can define additional workflows if required.
3.7.3 Submission of Requests:
1) The system shall allow for submission of ad hoc requests that
result in a financial adjustment on the balance of a customer's
account. Typically the user should be able to: credit (decrease) a
customer's balance; debit (increase) a customer's balance; do
financial adjustment between two customers.
2) The system should allow Entering of ad hoc invoices
3) The system should allow modification of meter readings either
billed or non-billed and calculate the appropriate adjustment
4) The system should allow initiation of an internal financial
investigation
5) The system should be able query, retrieve and print or email any
kind of financial request submitted.
6) Be able to capture details of any oral communication related to the
application for reference, with either customer or another
employee of the Organization or other.
7) Be able to upload attachments or use hyperlinks related to each
specific application. These should be accessible by any user of the
system that has access to the specific application
8) Allow to assign the application to any other employee and notify
them for the assignment and/or send email to notify.
3.7.4 Application search capability: The system should be able to query,
retrieve and print any financial application submitted. The system
should provide multiple search criteria like application no, customer
account or name, status of application, type of application, date range
and others
3.7.5 Processing Cycle: The system should be able to manage the
processing cycle as tasks generated by financial applications are
scheduled, completed and managed. The system should also be able
to query, retrieve and print any kind of tasks that has been generated
from a financial application.
3.7.6 .Reporting: The system should:
1) Provide various management reports
2) Make provision for management and year-end reports
488571860.docx Page: 12
3) Provide financial reports to show transactions for a specified

period
4) Provide reports on requests for financial transactions. These
reports will be used to manage the activity cycle relating to
financial requests and will be used to monitor department
performance
3.8 Meter Reading Systems

the meter reading activity cycle and other meter related non-cycle
activities. These functions will be used for the capturing/import of meter
readings, the identification and rectification of exceptions.
3.8.2 The system should have an interface to AMR (Automated Meter
Reading systems).
3.8.3 The system should have an interface to Hand Held Meter reading
devices (Mobile Data Terminals). The system should make provision for
the setup of the system and hand-held unit (HHU) parameters to
facilitate transfer of information from system to hand-held unit software
and in reverse.
3.8.4 Be able to import photos or GPS coordinates taken by the HHU;
compare and validate the imported GPS coordinates of meter
connections with those in the system (use a tolerance limit); this can be
used to evaluate the performance of meter readers and the quality of
readings.
3.8.5 Communicate with external meter reading systems: The system
should make provision for communication from external meter reading
systems through the definition and importation of ASCII files
3.8.6 Walk route management: Each connection should be assigned to a
walk-route and a sequence number. The user should be able to view
the walk route graphically and make adjustments, through introduction
of new connections and changing the sequence for easier reading. The
system should allow viewing of a selected walk route in GIS or Google
Earth.
3.8.7 Configuration: The system should enable the user to set-up meter
Books, exception controls and HHU file format
3.8.8 Walk route processing: Should make provision for the up loading and
down of meter walk routes to hand held units. In the absence of
automated hand held units it should make provision for manual meter
reading capturing
3.8.9 Processing of meter readings on returning from the field:
1) Meter readings should be evaluated and exceptions (high, low,
zero, negative and others) marked for re-reading before posting.
488571860.docx Page: 13
2) Provide various filtering options to easily focus to problematic

cases. Be able to isolate such cases and extract them for a
second round of readings verification
3) The user should be able to edit readings and messages
downloaded from HHU or record manual readings per Walk Route.
4) The system should analyse messages logged by the meter reader
and then initiate an appropriate activity automatically.
5) The system should be able to record any no access or other
messages taken by Meter Readers. The list of these messages
must be pre-defined and user must be able to easily add or modify
them.
6) The system should be able to automatically trigger various meter
related tasks (meter repair, meter exchange, meter test etc) based
on readings evaluation or messages from meter readers. The
triggered tasks should automatically be forwarded to the Meter
Maintenance department for further action. Relevant reports
should be available.
7) The system should evaluate consumption based on exception
controls defined and initiate user definable relevant actions when
needed. Various relevant summary and detailed reports should be
available for better analysis and assessment of readings quality.
8) The system should identify problematic meters and connections
and where applicable generate requests for maintenance (e.g. in
the case of a stuck meter)
3.8.10 Overall and approval of meter readings: The system should enable
review the overall analysis for the whole Area/Group of meters. This will
enable the user to determine whether the level of meter reading
accuracy is acceptable for invoicing. Statistical and exception reports
should be produced.
3.9 Smart Metering system (optional)

3.9.1 General: A smart meter is a meter that sends continuous information
to a smart metering database, supplied by specialized companies. The
Smart Metering system must add value to the Smart Meters. It must
manage large volumes of data, evaluate such data, manage the
maintenance of the system and provide Customer access to the
readings. More specifically it must have the following modules and
corresponding functionality.
3.9.2 Meter Data Management: The module must read and process the
readings in a suitable manner for other applications at the Utility, in a
way protecting such applications from high meter data volumes that
smart metering produces. Data should be extracted in a user definable
format. Such outputs should include but not be limited to:
1) Meter Readings for Billing systems
488571860.docx Page: 14
2) Instantaneous flow & pressure per property used in Hydraulic

analysis
3.9.3 Customer Web-Logs Portal : A web portal whereby the customer
can check for internal leaks and monitor his consumption to save
money as well as comply with any restrictions that may apply.
3.9.4 Meter Data evaluation: The module must evaluate data and identify
discrepancies to be processed by the Rehabilitation Management
module as well as prepare data for further processing by the Technical
information systems, i.e. the module must:
1) Incorporate Billing databases (meters, connections, properties,
plots and customers) as well as demand standards & restrictions
2) Identify Malfunctioning meters and calculate unmetered demand
3) Identify properties with internal leaks and quantify such leaks
4) Identify properties with high consumption
5) Identify wrong size meters
6) Produce discrepancy lists with above problems
7) Calculate total demand per property (metered consumption +
internal leakage + wastage + unmetered consumption).
8) Calculate average demand per consumption category
9) Identify connections with a sudden drop in pressure (in case of
pressure readings) probably signifying a large leak in the
distribution mains
3.9.5 Meter Rehabilitation Management : The module must:
1) Include an organised work flow system that manages resolution of
discrepancies. It must include a Customer contact center, keep
records and communicates with other departments to initiate
appropriate action.
2) Produce a file to be used by the 2-way communication system if it
exists to issue commands to shut off or restrict flow
3.10 Receipting/ Customer Payment

3.10.1 Receipting: The module should include enquiries with flexible
receipting and reconciliation options. Multiple security levels and audit
trails to ensure data integrity and prevent fraud must exist. In case of
power failure the receipting session must be suspended to be resumed
when power returns. Batch entries should also be made available with
due processing.
3.10.2 Payment by Customer should be through multiple options including (a)

payment at cashier, (b) payment through the internet (credit card), (c)
488571860.docx Page: 15
payment through banks, (d) payment using mobile phones if the Utility
comes to an agreement with local providers
3.10.3 Receipting Reports: The system should (a) print various receipting
related operational and management reports, (b) should monitor
efficiency of cashiers and (c) Should review method of payment by
customers.
3.10.4 Receipt Registration: The system should manage the registration of
receipts batches to ensure synchronisation of pre-printed form numbers
with system generated receipt numbers.
3.10.5 Offline Receipting: The system should be able to support any offline
receipting at remote stations or collection points. There should be daily
import and verification of the offline payments to the master database.
3.10.6 Cashier Session: The system should:
1) Record revenue collection by cashier and issue receipts
2) Offer a mechanism for user and session and float control.
3) Make provision for user error in issuing a receipt and printer mis-
feeds.
3.10.7 Cashier Status: The system should
1) Provide information on cashier session status
2) Provide a means of locking sessions that do not balance during
end-of-day reconciliation.
3) Make provision to submit the detailed breakdown of notes and
coins and prepare automatically the deposit slip for the bank
lodgment for cash and cheques.
4) Make provision for a user to change his/her password
5) In case of power failure, suspend the receipting session to be
resumed when power returns.
3.11 Billing
the billing processing cycle and generation of statements
3.11.2 Billing Processing Cycle Administration
1) General: The system should be able to generate tax invoices,
calculate estimations for metered services, calculate regular taxes
or other charges, consolidate all transactions and generate
accurate and timely bills
2) Cycle control: The system should make provision for strict cycle
control, providing for the management of groups of customer
accounts so that the organisation billing cycle can be staggered to
accommodate logistical and resource considerations. Various
488571860.docx Page: 16
exception reports should be prepared in order to ensure accurate

and transparent billing.
3) Print Bills: The system should make provision for batch printing
options based on user criteria such as customer account range or
walk route.
4) Email Bills: The system should be able to send batch emails to
customers attaching the bill.
5) SMS Bill details: The system should be able to send in batch short
sms text to customers notifying them for the charges of the period,
the due amount and due date.
6) Produce estimates: The system should make provision for the
optional production of estimates for metered services based on
organisation policy guidelines.
7) Invoice for consumption and other services: The system should
produce consumption and regular charges(variable or fixed) as
well as various taxes based on the organisation tariff structure.
The system should support VAT, interest on overdue debts,
surcharges and any other charges.
8) Transaction Reports: The system should produce detailed and
summary transaction reports or queries with charts where
applicable..
3.11.3 Generation of Bills: On completion of the Billing cycle the system
should be able to invoice accounts and produce statements to be
printed or emailed directly to customers. Statement imaging should be
available for both current and historical statements.
3.12 Debt Management

customer arrears and identify customers in arrears and manage
associated activities according to utility policy
3.12.2 Administration:
1) The system must be flexible to allow for the implementation of
Utility's policy at present and to allow for user definable variations
in the future.
2) The system should allow for setting up multiple policies for
different consumer types; the policies should cater for reminders,
disconnection, and reconnection actions, summons and even
write-offs.
3) It must have a controllable business workflow with access rights
and actions privileges per user. Be able to assign certain set of
customers to different Credit Control officers to follow up.
4) The system should be automatically updated for any new
transactions and accordingly include new customers in the Debt
Management Cycle or remove those who settled their debt.
488571860.docx Page: 17
5) The system should be able to produce full aging analysis of all or

selected group of customers.
3.12.3 Debt Management Cycle:
1) The system must make provision for the management of the debt
management cycle and list all customers eligible for each step in
the cycle, as well as monitor the change of customer status in the
cycle.
2) The system should be able to print, email customer notifications or
send short text sms
3) The system should be able to produce disconnection/reconnection
lists based on meter reading routes or other logical grouping and
order; it should also generate automatically any reconnection fees
against customer’s account
4) The system should allow for the generation of ad-hoc charges to
be issued in different occasions of the Debt Management cycle.
5) Full Debt Management history must be kept and easy query of
closed cases must be possible.
6) The system should allow for the generation of debt rescheduling
repayment agreements (payment of overdue debts in installments)
and automatically follow them up and monitor.
3.13 GIS and Land and Survey Department interface

3.13.1 The system should integrate with the GIS/LIS and have the ability to
use Google Earth as background for better reference. The user should
be able to drill down to the selected element from the GIS.The system
should incorporate its own GIS system making use of either shapefiles
and/ or ESRI ArcGIS Server software.
3.13.2 The system should provide a specialized module for the periodical
import of Georeferenced data from the Land and Survey Department.
These data must be semi-automatically imported, validated and
discrepancy reports against existing data must be produced.
3.13.3 The above module must have automatic facilities for discrepancy
resolution i.e. plots merge/split change of ownerships etc.
3.13.4 On conclusion of the georeferenced data import, validation and
discrepancy resolution the central Billing/LIS database should be
automatically updated.
3.13.5 History of the previous status of plots owners and other entities should
be maintained and easily archived.
3.14 Web-Portal
3.14.1 The system should provide a web enabled module that can give the
organisation customer point of contact over the internet. It should be
also possible to be used by Organisation’s employees to perform
488571860.docx Page: 18
basically daily tasks. The facility should be a template-based interface

with seamless integration into the organisation's web site.
3.14.2 The web access should be secure and follow the standard security
protocols
3.14.3 The facility should enable customers to: (a) Make enquiries to their
accounts and view their personal data, transactions, readings, bills,
applications, debt management activity an others, (b) Submit
applications and complaints and upload any necessary supporting
documents, (c) Submit their meter reading, (d) Make payment to their
account (e) Re-print an older bill or other report.
3.14.4 Customer services application tracking and management: The system
should ensure that customer applications logged through the website,
once investigated and authorised, that they will enter the organisation
work flow. The customer user should be able to track the status of his or
her application. The customer should be able to have an online
interactive communication with Utility’s officer regarding an application
3.14.5 Employees: Authorised personnel will be able to access the system
over the web and perform various daily tasks like Enquiries, meter
Reading, Collections, produce reports and others.
3.14.6 Meter Reading: Meter Reading operators should be able to capture or
edit readings as they could do if they were using the desktop
application.
3.14.7 Receipting: The system should allow the Utility's cashiers to collect
money from customers over the web as if they were at the head-
quarters. All validation and security controls must be also possible. This
is ideal for remote stations with low or no connectivity to the main
database via WAN or LAN.
3.15 Pricing & consumer analysis

3.15.1 The system should be able to carry out pricing analysis in effect
performing demand and revenue sensitivity analysis based on various
scenarios, like the change in tariffs/tax rates, change in tariff structures
or implementation of a given policy, such as water restrictions.
3.15.2 Revenue Analysis & forecasting: The system should analyse historical
revenues and identify patterns of consumption and other trends. It
should perform forecasting per category based on the consolidation of
the proposed tariff structures, demand vs. elasticity model and
consumption patterns.
3.15.3 Scenario Analysis & Price Regulation: What-if analysis should be
possible by comparing the projected results from different scenarios.
This will allow the user to determine the optimum tariff structure for
recovering costs while still providing an affordable service to the
Customer.
488571860.docx Page: 19
4. Technical Systems
4.1 Network Data Management Systems
4.1.1 Purpose: For all the technical functionality to exist a robust
geographical database must exist with proper functionality for the
capturing, structuring, maintenance and management of all the relevant
graphical data.
4.1.2 Data elements: The system must make provision for all the standard
Assets in the areas of Water Supply and Sewer disposal and any other
fixed assets the organisation might have.
4.1.3 Libraries: The system should maintain system libraries for all main
elements, such as pipes, pumps, etc.covering all required information
4.1.4 Other information: The system should allow the attachment of
pictures, video-clips and other information to different elements or sub-
elements.
4.1.5 Hierarchical Structure: The system should provide functionality to
present the network as well as keep data based on inheritance and
functional dependencies in a tree form
4.1.6 Network data analysis and evaluation: The system should evaluate the
network data (Attribute and Connectivity data) and provide a list of
exceptions according to the validation rules and business logic that can
be investigated and corrected by the Utility through field investigations.
The system should ensure that the exceptions are classified intelligently
to allow the user to focus on critical problems
4.1.7 Mapping: The user should be able to produce maps with user
definable templates, labeling, scales and sizes
4.1.8 DTM: The system should include a Digital Terrain Model capable of
producing contour lines and surface type representation of the terrain,
pressures and heads; it should also be able to assign elevations to the
network elements automatically.
4.1.9 Data publishing: The system should have provision to publish the data
on the web and enable on line viewing, querying, locating, map
production and reporting using labeling, thematic maps and legends.
4.2 Monitoring & Control Systems

4.2.1 Purpose: The main purpose of monitoring and control is the monitoring
and recording of data and events, required for (a) capturing information
(b) triggering a Maintenance request in the case of problems arising
and (c) statistical analysis for Maintenance and Rehabilitation Planning
purposes, (d) Water Quality Management, (e) Distribution/ NRW
Management and (f) Planning - Demand Analysis
488571860.docx Page: 20
4.2.2 Link to telemetry: The system should link to SCADA database

information repositories and should be able to read directly and take full
advantage of all data collected by telemetry systems. Telemetry data
should be further processed and grouped per asset and monitoring
point. In addition, it should be possible to accommodate links for future
extensions of the telemetry system and additional monitoring points.
4.2.3 Response: The system should be able to compare readings from
telemetry to raise alarms for various purposes and initiate predefined
activities.
4.2.4 Logging/ Metering/ Field data capture: Data will be collected in various
ways and the proposed system should be able to accept and convert all
such data for processing.
4.2.5 Data Processing: The system should filter, process raw readings and
give the user the ability to correct/ append readings and generate
corrected continuous records. The system should reduce bulk meter
readings into flows and store in a Flows database, evaluate supply
flows to Mass Balancing zones andgenerate peak factors and demand
distributions with time for setting consumption standards.
4.2.6 Event Management: Event management applies to monitoring of
sewers and pavements. Its main purpose is the monitoring and
recording of events. For example in the case of pavements, event types
include: Status, Location, Road Profile data (Width, Shoulders, lanes,
etc..), Pavement Design & Materials data, Limits data (speed, vehicle
types, etc..), Design Characteristics data (Gradient, Restrictions, etc..),
Multimedia data (pictures, video clips, etc..), Traffic Flow data (Annual
Average Daily Traffic, Percentage heavy, etc..), Toll Road point events
(charges, booth location, etc..), Accidents point events (severity, date &
time, injuries, etc..) and Condition Assessment data (Date, Assessor
name. Distress type, etc..)
4.2.7 Event evaluation: The system should evaluate events as per
predefined criteria and issue a maintenance request if required as well
as check and store recorded information.
4.2.8 Web based Network data Manager: The system should interface to
the Network Data Management system through the web to enable
capture/ update of element attributes and enable capture of bulk meter
readings and element logs.
4.3 Asset Management - General

4.3.1 Purpose: The main purpose of the Fixed Asset Management system is
the formulation of maintenance and rehabilitation plans with the
objectives of: (a) Minimizing the costs of asset ownership, (b)
Maintaining required service levels and(c) Sustaining the infrastructure.
4.3.2 Lifecycle Asset Management methodology: The system should use
statistically determined Operational Condition/Deterioration curves
(from literature) to simulate the deterioration of the infrastructure
488571860.docx Page: 21
components. As these assets are used and as they age, their condition
declines and eventually leads to investment for rehabilitation and
replacement. The system should provide a detailed valuation capability
incorporate condition assessment and rating tools, combined with
deterioration curves to predict current asset values and future asset
conditions.
4.3.3 System Functionality should include: Importing and properly storing
findings of condition assessment surveys, Risk Assessment, Life Cycle
Assessment and Asset Valuation including multiple costs, removal &
purchasing costs, multiple depreciation factors, market and residual
values.
4.3.4 Fixed Asset Management is carried out through three systems
described below, i.e.: (a) Condition Assessment & Evaluation, (b)
Financial Asset Valuation and (c) Rehabilitation Planning
4.4 Asset Management - Condition Assessment & Evaluation

4.4.1 Purpose: The module should assist in the capture of data from
condition assessment surveys and the assessment of the condition of
the assets.
4.4.2 Data: Flexible import routines must exist to allow the users to import
the results of a Condition Assessment exercise and maintain historical
asset information. Detailed inspection data should be stored and used
as input in the rehabilitation planning module.
4.5 Asset Management - Rehabilitation Planning

4.5.1 Purpose: The system should assess maintenance and rehabilitation
alternatives and prioritize rehabilitation and replacement of assets and
draw up a maintenance plan and a rehabilitation plan based on
budgetary constraints and priorities
4.5.2 Definitions: Standard and user definable categories should be
available to describe “Importance”, “Risk” and “Condition” (common to
all assets), where: Importanceis in terms of Consequence of Failure,
Risk is in terms of Likelihood of occurrence and Condition in terms of
remedial work required.
4.5.3 Prioritising Assets for rehabilitation: Both the (1) Aggregate Scoring
Method and the (2) Risk Assessment Method (Decision Matrices)
should be available in the system, where:
4.5.4 Aggregate Scoring Method:
1) For each asset type the user should be able to define
Rehabilitation Criteria and assign a weighting factor (WF) to each.
The user should be able to use (a) Importance, (b) Condition (as a
function of remaining useful life) and (c) Risk as criteria.
488571860.docx Page: 22
2) The user should be able to import data for each criterion from
shapefiles, arising from external surveys or from historical data kept
in the system (e.g. in the maintenance module).
3) The user should be able to assign bands with priority indices per
criteria as well as assign a PI (priority index) value per asset.
4) The system should calculate a weighted aggregate per asset (PI *
WF) and sum up all the criteria, thus calculating a single number
per asset. The Assets should be then ranked together with their
cost of rehabilitation/ replacement.
4.5.5 Risk Assessment Method:
1) Decision matrices: The user should be able to define a
Maintenance/ Rehabilitation (combined) Decision Matrix for each
asset type [relationship between risk and action to be taken]. The
user should further be able to assign a Risk category to each
Condition vs Importance combination (Risk Decision Matrix) per
Asset type.
2) Risk Assessment: Using the decision matrices as well as
information from the financial valuation exercise should come up
with recommended maintenance/ rehabilitation activities per asset
with appropriate costs that can be ranked in terms of risk and
importance
4.5.6 Reports: The output of the analysis should be a Proactive
Maintenance report and a Rehabilitation Plan within the defined
budgetary constraints.
4.6 Maintenance Management Systems

4.6.1 Purpose: The main purpose of the maintenance management system
is the improvement of productivity and efficiency of the maintenance
function and the improvement of service delivery (less breakdown time)
through the implementation of proper business procedures and work
flow.
4.6.2 The system should be a comprehensive technical information system
that deals with the scheduling and management of work orders and the
management of maintenance activities relating to water supply and
waste-water networks as well as related plants (water treatment,
pumping stations, etc..)
4.6.3 The system should allow the generation of custom elements to
monitor their maintenance. It should also allow the creation of a
hierarchical model linking the different elements (standard or custom)
and browse top down or reverse.
4.6.4 Plant Maintenance: In the case of Plant Maintenance the system
should be able to relate the data hierarchically with two methods, i.e.:
(a) in a tree structure and (b) in a schematics layout for quick and easy
component identification. Both methods should provide functionality to
488571860.docx Page: 23
present the plant equipment based on inheritance and functional

dependencies in a tree form (hierarchical structure)
4.6.5 Maintenance Management: The system should include but not be
limited to the following functions: (a) Recording and processing of
maintenance requests, (b) Predefined industry specific maintenance
activities, (c) Allocation of maintenance resources, (d) Scheduling and
management of resources (manpower, stores and support services) for
work orders, (e) Work order management (including job card scheduling
& processing), (f) Routine/ Preventive/ Proactive/ Reliability-driven
maintenance programs, (g) Maintenance decision matrices, (h)
Monitoring of networks, job costing, record keeping of history,
generation of thematic maps and Maintenance Management reporting.
4.6.6 Field Maintenance: The system should allow for Field Maintenance to
be carried out through the Web with portable computer equipment and
allow functionality with regard to Complaints Managements, Job Cards
Management and Reporting.
4.6.7 The system should integrate with the GIS/ Network Data Management
system and have the ability to use Google Earth as background for
better reference. The user should be able to drill down to the selected
element from the GIS or vice versa.
4.6.8 The system should have industry specific templates and procedures
be able to handle all relevant Maintenance Activities such as:
Investigations, Inspections, Operations (logs, meter reading, etc..),
Operations Opening/ Closing of Valves, Installation of New Connection,
Reconnection/ disconnection, Installation of bulk (flow) meters Leak
detection, Repairs/ Outage management, Pipe/ other asset
replacement, Servicing (Routine, Preventive Maintenance).
4.6.9 Maintenance Isolation Instructions: In case any maintenance activity
requires isolation of the network (for example for fixing leaks) the
system should be able to automatically identify the valves to be closed
and allow printing of a map to include with relevant instructions/Job
Card.
4.6.10 Maintenance Management reporting: The system should report on
Work in Progress for any action request at any given stage of
execution, generate a Daily Operations Work Report, issue Network
Fault Reports.
4.6.11 Maintenance Data Analysis: The system should keep historical
records of all maintenance activities and provide data analysis for Work
historical analysis, generate Job Costing analysis per activity, generate
Crew/ Employee usage/ performance report and provide Audit Trail
Reports. In addition the system should be able to carry out Failure &
Reliability Analysis as well as System Condition Assessment analysis
using breakages records for specific elements.
4.6.12 It is essential that the system be seamlessly integrated with related
systems: commercial and network systems for operation supply and
488571860.docx Page: 24
network maintenance; accounting systems for job costing data; stock

control systems/ stores for access to stock item records and stock
levels; human resources systems for access to manpower records; and
telemetry for data for network elements operations.
4.7 Maintenance Management System - Web Access

4.7.1 Purpose: The main purpose of the a Web maintenance management
system is to enable technical people to access the maintenance system
over the web while they on field (using tablets), at home or else to view
or update the progress of any specific work order.
4.7.2 The system should allow user to record a new problem or update an
existing, preview various reports and in general, perform most of the
operations as if he/she was in front of desktop application.
4.8 Distribution/NRW Management Systems

4.8.1 Purpose: The main purpose of Distribution Management is (a) to
ensure proper service delivery (quantity and pressure) and (b) identify,
localize and quantify system losses (leakage).
4.8.2 Zone Management: The Zoning Manager should be a tool for
modeling, managing, monitoring and controlling zones. The system
should automatically generate all different zone types,
including:Hydraulic zones (distribution supply networks separated from
the main transmission lines), Mass balancing zones (DMA), Pressure
zones (areas with equal static head) and System Component zones
(e.g. Reservoir zones, pump zones, etc.). The system should record
history of operational changes, such as opening and closing of zone
valves.
4.8.3 Schematics: The system should provide tools to intelligently analyse
and represent the network layout using orthogonal and geographical
schematics representation.
4.8.4 Routing functionality: The system should be able to provide a list of
valves that need to be closed in order to isolate a pipe
4.8.5 Advanced Metering Infrastructure for Distribution Network: The system
should allow for such infrastructure and have inherent understanding of
the relationships between bulk (flow) meters.
4.8.6 Link to Billing system: The system should integrate with the Billing
system to extract and analysis meter readings needed for the analysis
described in the sections below.
4.8.7 Present Authorised Demand: The system should make use of the
Commercial Data Evaluation module (described under commercial data
management) to establish present real demand (metered demand plus
metering inaccuracies) per connection for Mass Balancing purposes.
488571860.docx Page: 25
4.8.8 Un-accounted for water (UFW) Analysis: UFW analysis should be

performed per DMA. The analysis should include / allow for:Meter
reading data analysis, Consumption analysis, Bulk meter readings
analysis, Water Use Daily statistics [supply]. The system should
relatebulk meters and consumer meters to Mass Balancing zones
(DMA) to calculate supply - consumption - losses per user definable
and system definable periods in various forms.
4.8.9 Real time mass balancing: The system should be able to extrapolate
consumption and compare with supply flows from telemetry to raise
alarms if the difference jumps suddenly, probably indicating the
occurrence of a leak.
4.9 Planning: Demand Analysis

4.9.1 Purpose: Demand Analysis is important for (a) identifying illegal/
unregistered connections, (b) establishing Wastage and internal
leakage levels in authorized connections, (c) performing a detailed Non-
Revenue Water Audit (NRW) and (d) Establishing present and future
demand, correctly located, for planning purposes both for sizing major
system components (e.g. reservoirs) and network optimisation and
expansion.
4.9.2 Present Authorised Demand: The system should make use of the
Commercial Data Evaluation module (described under commercial data
management) to establish present real demand (metered demand plus
metering inaccuracies) per connection as well as to evaluate current
demand standards per demand category for planning purposes.
4.9.3 Land Usage analysis: The system should allow for land-usage
analysis superimposing town-planning data, data from other utilities
(e.g. electricity connections, municipal property database) and satellite
imagery to identify illegal/ unregistered connections and future
developments within the supply areas where town planning information
is absent, the system must allow the user to compare satellite imagery
(Google earth) with connections data to identify areas that show
development but no connection.
4.9.4 Wastage and Internal leakage analysis: The system should estimate
Wastage and Internal leakage for each consumer by comparing
consumer demand with average consumption of consumer’s category.
The analysis could also indicate potentially wrong consumer category
classification.
4.9.5 Demand generation: The system should generate demands including
demand from illegal/ unregistered connections, future developments
within supply areas and future developments adjacent to supply areas
and properly allocate such demands to the network.
4.9.6 NRW audit: The system should enhance NRW audit described under
distribution management to include Wastage & internal leakage as well
as illegal/ unregistered connections.
488571860.docx Page: 26
4.10 Planning: Network Analysis & Optimisation

4.10.1 Purpose: Network optimisation of the existing network is needed to
effectively rezone and optimise the system in order to balance the
pressure distribution and ensure proper flow conditions and equitable
distribution of water.
4.10.2 Network Optimisation Methodology: The Consultant must supply a
methodology for using the Demand analysis module and the Hydraulic
analysis model (as described below) to arrive at an optimised network.
4.10.3 Water Network Analysis Systems
1) The system should enable the accurate calibration and modeling
of water networks. It should make use of graphical user interfaces
and should support digital terrain modeling.
2) The water analysis system should include comprehensive
hydraulic and dynamic water quality modeling, energy
management, extended simulation, cost optimization (automatic
sizing) and steady state analysis, and should be based on an
internationally accepted analysis engine.
3) Emergency Response (Crisis) Planning: The system should be
able to analyse different scenarios of Contamination, Breakdown in
Supply and Fire and assist the user prepare appropriate manuals
for handling such crisis, mainly in terms of valves that have to be
opened/ closed.
4.11 Management reporting

4.11.1 Purpose: The objective of management reports are to provide
information on which decision-makers can base wise and prudent
judgments.
4.11.2 The proposed system shall cover effective management reporting at
all levels. Levels of reporting shall be from the basic system reports to
operational reports to department reports to consolidated management
reports.
4.11.3 System and operational reports should be designed mainly for
instigating corrective action, departmental reports to relate to objectives
and performance targets and management reports to relate to strategic
and financial objectives.
4.11.4 Management reports should cover all areas of the business with
regard to money earned or spend andinclude appropriate Key
performance Indicators.
4.11.5 The user should be able to “drill down” from management reports, i.e.
progressively go down to any level of information affecting the outcome
of a report.
488571860.docx Page: 27
5. Scope of Work
5.1 Project Duration: The system should be installed and training completed
within 12 months of commencement.
5.2 Project Management :A liaison group or steering committee will be formed

consisting of personnel from the Client and from the Consultant. The
liaison group will meet at regular intervals to discuss project progress,
training progress and further requirements. The project will be
administered and managed. Initially the Consultant shall submit a project
work plan for approval by the steering committee.
5.3 Activities: The following activities are identified to be carried out

1) Activity 1: Requirements definition & mapping
2) Activity 2: Data Conversion and Evaluation
3) Activity 3: System customization, setup & configuration
4) Activity 4: System acceptance
5) Activity 5: System installation & training
6) Activity 6: Post-implementation support
5.4 Activity 1: Requirements definition & mapping:

5.4.1 Understanding, review and recommendations regarding the systems
environment, including job descriptions, business processes and
procedures,
5.4.2 Analysis and appropriate recommendations regarding the gaps
between current business processes, best practices and the systems
offered by the Consultant,
5.4.3 Analysis of existing report and forms and design of reports and forms
to accommodate the proposed systems
5.5 Activity 2(a): Data Conversion and Evaluation– Technical systems

5.5.1 Data conversion routines should be established where required and
tested, and data should be converted from “shapefiles” prior to going
live with the new system.Data shall include Cadastral information
(plots), property data (if it exists), topographical data (contours/ spot
heights, landmarks, etc.), and Network data. The Utility will assist the
Consultant in collecting all available information.
5.5.2 The Consultant is required to provide a methodology and the
appropriate software tools for translating “AutoCAD“ drawings to
shapefiles and the proposed system. Utility personnel will execute the
work under the Consultant’s supervision.
5.5.3 Required Data that is not available in digital format must be captured
(digitized).The Consultant is required to provide a methodology and the
488571860.docx Page: 28
appropriate software tools for the data capture. Utility personnel will
execute the work under the Consultant’s supervision.
5.5.4 In the case where Billing software is not procured under this project
and where Distribution management is required, billing data will be
made available in text/Excel files with a given index to be converted to
the system. Billing data is needed for Water Balancing and Present
demand calculation purposes.
5.5.5 Furthermore in the case where Distribution management is required:
1) Bulk meter readings will also be made available and should be
imported into the system in soft copy.
2) Geographical reference of connections: It is important that all
connections in the billing system be geo-referenced. Where the
Cadastral data is reliable and a link exists in the billing system to
the plot number (in the cadastral) this link can be made directly. In
areas where no such link exists the Utility will use GPS (Global
positioning systems) equipment to locate the position of all the
connections as given in the Billing system. The Consultant will be
responsible for establishing this link and where field work is
required he must provide guidelines to the Utility for carrying out
this work.
5.5.6 Network data evaluation: Once all the data has been converted to the
proposed system the Consultant shall analyse the networks with regard
to connectivity and identify suspect areas that need to be investigated
further. Missing parameters per element with regard to dimensions,
material, type, date of installation should also be identified for further
investigation by the Utility. Critical omissions/ error will need field
investigation/ verification.
5.5.7 Data desktop editing: Once all the available data has been converted
the Consultant should meet with relevant department personnel and go
through the data and address any inconsistencies or gaps identified
during the data evaluation stage. The data register should be updated
as advised and where necessary action plans should be formulated by
the Utility to address the data problems through field surveys.
5.5.8 Assistance with data capture, cleaning and validation: This activity can
be lengthy and it will not delay the implementation of the project
(remaining activities). It will commence as soon as Activity 2 is finished
and might even continue after the end of the project. The objective of
this activity is to (a) Capture/ convert any missing/ not available data in
shapefiles to the system, (b) address data discrepancies identified
under data evaluation in the previous activity and validate/ capture
missing data through field investigations. The Consultant is required to
render the Utility assistance through the supply of the appropriate tools
and methodologies to carry out this activity.
488571860.docx Page: 29
5.6 Activity 2(b): Data Conversion & Evaluation – Commercial systems

5.6.1 Data conversion routines should be established where required and
tested, and data should be converted from legacy systems prior to
going live with the new system.
5.6.2 Prior to conversion certain data capture might be required. Capturing
data refers to data not available in digital format. If such data is required
for the proposed systems to be operated effectively, the Utility will
provide personnel to carry out data capturing. The Consultant must
coordinate and supervise this activity and must provide suitable
software utilities to enable the capture. Data capture of live data must
be coordinated to allow for data that has changed during the data
capturing activity.
5.7 Activity 3: System customization, setup & configuration

5.7.1 Based on the findings of Activity 1 the Consultant is expected to draw
up specifications and proceed with customizing the software to cope
with all the requirements.
5.7.2 Activity 3 is carried out in parallel with Activity 2.
5.8 Activity 4: System acceptance testing
5.9 Activity 5: System Installation and Training

5.9.1 Ensure system infrastructure is in place and tested for all necessary
communications.
5.9.2 Installation and final setting up of the complete system, including
database management systems and related, on the Utility’s actual
servers, workstations and networks and at outlaying offices and remote
sites where required
5.9.3 Users and management must be trained in all facets of the systems,
and training for system administrators must be provided. Training
should be adapted to include training on the operational procedures and
job descriptions
5.10 Activity 6: System post-implementation support:

5.10.1 General: Support services will be required by the Consultant on a
yearly basis. The extent of support required will be agreed upon prior to
commencement.
5.10.2 Software Maintenance: The consultant must ensure Software
Maintenance with software manufacturer for the entire support contract
duration entitling the Utility free upgrades and software related 3 rd level
support.
5.10.3 1st Level Support: 1st Level support to systems operational personnel
will be provided by the Utility’s support engineers (at least one for
commercial systems and one for technical systems) seconded to the
488571860.docx Page: 30
Consultant from commencement of contract, suitably trained and

certified by the software supplier as expert user of the system. 1 st level
support is essential for proper system operation and should include the
following services:
1) System administration functions
2) Supervise and execute new customized reports when required
3) Assist in the production of operational and management reports &
queries
4) Supervise the implementation of predetermined workflow
procedures
5) Provide ongoing user and management training
6) Assist with the appointment and training of additional or
replacement system personnel
7) Provide on-going user support to Utility personnel.
8) Implement system upgrades
9) Report to 2ndlevel support personnel problems they cannot resolve
5.10.4 2nd Level support: The Consultant must also provide 2nd level support
through suitably qualified personnel, through regular visits as well as
back-office support, including the following activities:
1) Supervise and execute changes in system configuration when
required
2) Provide training to 1stlevel support personnel on new system
upgrades when they become available.
3) Assist 1stlevel support personnel in resolving operational problems
they cannot cope with
4) Evaluate the nature of reported problems and in case of defects
forward through to software manufacturer
5) Report to software manufacturers operational problems they need
software solutions in resolving
6) Assist the Client in identifying new system requirements and in
overall coordination of problem resolution
5.10.5 Additional Training: The Consultant must see that the Client personnel
are at all times properly trained in operating the system and ensure that
all new personnel receive appropriate training.
5.11 Client Responsibilities

5.11.1 Executive Support: The Client undertakes to render the Consultant
strong executive support to the endeavour throughout the project,
5.11.2 Training facilities: The Client will make available suitable training
facilities for the Consultant
488571860.docx Page: 31
5.11.3 Computer Hardware, Operating systems and Communications: The

Client will ensure that the required infrastructure will be in place prior to
system deployment.
5.11.4 Staffing: The Client will make available adequately qualified personnel
to be trained in the different aspects of the system as per agreed
system deployment.
488571860.docx Page: 32
6. Project Area
6.1 [General description of Area]
6.2 [Brief description of Network – Bulk supply]
6.3 [Brief description of Network Data availability and format]
6.4 [Brief description of bulk flow meters availability as well as readings

available]
6.5 [Brief description of Current Legacy systems used]
6.6 [Brief description of other data available - describe what is available and in
what format]
6.6.1 Cadastral information (plots): [describe]
6.6.2 Topographical data (contours/ spot heights, landmarks, etc..)[describe]
6.6.3 Municipal Property data:[describe]
6.6.4 Other Utility Connection data:[describe]
6.7 Connections geographical reference: [In the Billing data geographical

reference of the connections is established through….]
488571860.docx Page: 33
7. Instructions to Bidders ( Deepak to check)

7.1 General
7.1.1 In order to obtain first-hand information on the assignment and the
local conditions, it is considered desirable that a representative of your
firm visits [Name of Client] before the proposals are submitted / and to
attend a pre-proposal conference to be held at Client's premises on the
date specified in clause 5.1.11. Your representative should meet with:
[Name of Client's Representative, title.]
7.1.2 The cost of preparing a proposal and of negotiating a contract,
including trips is not reimbursable as a direct cost of the assignment.
7.1.3 You are requested to hold your proposal valid for [90] days.
7.1.4 The Client is not bound to select any of the firms submitting proposals.
Further, the Client does not bind itself in any way to select the firm
offering the lowest price.
7.1.5 If you consider that your firm does not have the expertise required for
the assignment, there is no objection to your firm associating with
another firm to enable a full range of expertise and services to be
presented as required.
7.1.6 The Language of the proposal and all correspondence is English.
7.1.7 The Financial costs must be in [currency].
7.1.8 For local firms bidding Financial costs must clearly indicate any
amounts allowed for local taxes separately. Such taxes must include
import duties, Value Added Tax (VAT), General Sales Tax (GST),
withholding taxes, or any other applicable taxes under local law.
7.1.9 For international companies bidding financial costs shall not include
any local taxes such as import duties, Value Added Tax (VAT), General
Sales Tax (GST), withholding taxes, or any other applicable taxes under
local law.
7.1.10 No variation payments will be accepted for work done within the
defined scope of work. Any requests for variations must be submitted
prior to the cost being incurred for approval. With regard to escalation:
1) No escalation will be payable for prices quoted for the
implementation Phase.
2) The annual prices quoted for the Support and Software
Maintenance Services phase will be escalated for the first year
using as base month, the month in which the support and Software
Maintenance Services commences and thereafter on an annual
basis. In the case of the local currency component the cpi
(consumer price index) of the previous 12 months will be used. In
488571860.docx Page: 34
the case of the foreign currency component the bidder must

stipulate a fixed annual escalation rate.
7.1.11 The target time schedule is as follows:
Letter of invitation: Invitation date
Pre-proposal conference: Invitation date + 20 days
Submission of proposals: Invitation date + 30 days
Evaluation of proposals by: Submission date + 60 days
Contract negotiations: Submission date + 70 days
Project start date: Contract date + 30 days
7.2 Preparation of Proposal

7.2.1 The proposal must be organised in the following sequence:
1) Part 1: Bid Forms
2) Part 2: Financial Schedules
3) Part 3: Response to System Requirements
4) Part 4: Company Information
5) Part 5: Software Description
6) Part 6: Implementation Description
7.2.2 Part 1: Bid Forms: The following forms must be completed and
submitted. Form A2 must be submitted by each sub-consultant used.
1) Form A1: Proposal Submission Form
2) Form A2: Sub-Consultant Commitment Forms
3) Form A3: Manufacturer/Developer Authorization Form
This Part must also include proof that the proposal signatory has proper
authorization to sign the proposal. This must be confirmed by a resolution of the
Board of Directors of the consultant.
7.2.3 Part 2: Financial Schedules: The following standard financial
schedules, as included in AttachmentA, must be completed:
1) Schedule F1: Summary of Costs
2) Schedule F2: Breakdown of Manpower Costs
3) Schedule F3: Breakdown of Expenses
4) Schedule F4: Software Price List
7.2.4 Part 3: Response to System Requirement: Response to Client
requirements as set in Chapter 2 of this document.
7.2.5 Part 4: Company Information: A description of the bidder’s
organisation and its experience and standing must be presented by
making reference to:
488571860.docx Page: 35
1) Type of organisation (company, partnership, joint venture, etc)

together with organizational details, e.g. in case of a joint venture,
the nomination of the responsible partner
2) Background data on all Companies involved with this tender,
including information such as:
3) Specialization of the different Companies, with specific reference
to relevant experience in the water sector
4) Financial stability of the Company
5) Present/future support capabilities of the Company
6) Relevant experience of the bidder’s organisation in recent projects
involving the systems proposed in this tender submission must be
described in detail.
7.2.6 Part 5: Software description:
1) A detailed description of the proposed system's philosophy,
functionality, integration, interfaces to external systems and data
management characteristics.
2) System Architecture: schematic diagram depicting the proposed
system architecture to satisfy Client's needs, showing software
applications, servers, workstations, printers and network
components and recommended alternatives, if any.
3) Software Licenses: A schedule of software license requirements
and a copy of the relevant software license agreements.
4) Software Maintenance agreements: Include copies of the relevant
software maintenance agreements by the manufacturer.
5) Software Documentation: A list of documentation to be supplied
with the software.
6) Computer Hardware, Networking&Communication requirements:
detailed specifications of computer hardware, operating systems &
networking required. Note that computer hardware, networking and
communication requirements will be procured under a separate
contract if not already available. The bidder must specify however
requirements for his proposed solution.
7.2.7 Part 6: Implementation Description
1) Implementation Methodology: A description of the Bidder’s
proposed implementation methodology with emphasis on
minimizing risk of failure and disruption of current operations at the
Client.
2) Training schedule: A description of the Bidder's proposed training
courses for Client's Employees, aimed at familiarizing personnel
with procedures used in the entire project and teaching personnel
how to operate all components of the system effectively.
488571860.docx Page: 36
3) Activity schedule/ Timetable to be completed for the duration of

the project
4) Time Allocation for Professional Personnel (if applicable)
5) Project Responsibilities of Client: Describe the Client’s project
responsibilities.
7.2.8 Part 7: Support Methodology: A description of the Bidder’s proposed
support methodology and procedure with emphasis on work flow
leading to fast and effective problem resolution.
7.3 Preparation of the Financial Proposal

In preparing the financial proposal the following needs to be adhered to:
7.3.1 The prices quoted by the Consultant must be calculated on the basis
that the integrated system comprises a single entity (lump sum price).
Cost elements common to all the specified portions of the total system
must be proportionally apportioned.
7.3.2 All the necessary software, including: operating systems and ancillary
products needed to ensure a fully functional and operational system,
including report writers, GIS systems and relational database software,
must be specified. Software costs must also be shown in detail as per
the standard published price structures of the suppliers or
manufacturers.
7.3.3 Software Maintenance Costs: The Consultant must allow in his prices
maintenance of the software, entitling the Client to upgrades.
7.3.4 For the sake of Bid Comparisons the Consultant should price the
software supplied as per the quantities (if applicable) given in the table
below:
Description Quantity
Number of Connections 70,000
Number of Users – Commercial systems 50
Number of Users – Technical Systems 50
7.3.5 The Consultant must specify in this Part his acceptance of given
pricing qualifications and state any deviations or additional
qualifications.
7.4 Submission&Evaluation of Proposals, Award and Contract

7.4.1 Three (3) copies of your completed proposal should be delivered to:
Name of Client's General Manager
Name of Client
Address of Client
Not later than 12.00 noon Submission date.
7.4.2 Evaluation of Proposal
488571860.docx Page: 37
1) An evaluation committee will be set up. The committee will include

people from different departments of the Client.
2) The proposal will be evaluated for completeness as well as for
conformity to system requirements and will receive a technical
score.
3) The final score will be calculated by allocating a total of eighty (80)
percent to the technical score and twenty (20) percent to the price
score
4) The price score will be calculated in the following manner: the
percentage score allocated to the lowest bidder will be 100, and to
any other bidders (x/y) * 100, where "x" is the price of the lowest
bidder and "y" is the price of any other bidder.
5) The Technical proposal will be evaluated using the following
criteria:
6) The adequacy of the proposed system software in response to
requirements set in the terms of reference: (70 points)
7) The bidder organisation’s specific experience in the region and in
the field of assignment: (20 points).
8) The adequacy of the proposed work plan and methodology in
responding to the terms of reference for implementing the
information system (including training) (10 points)
9) Attachment B gives a detailed breakdown of the evaluation
process. The Bidder might be asked to demonstrate the software
functionality in a presentation using real data to be able to qualify
for compliance points as given in Attachment B.
7.4.3 Negotiations: The Client intents to negotiate a contract with the
Consultant which secures the highest overall weighted score as a result
of the evaluation. Should it not be possible to finalize an agreement with
that Consultant, negotiations will be terminated and the next highest
rated firm will be invited.
7.4.4 Contract:
1) The Consultants appointed for the assignment shall be required to
enter into a contract with the Client.
2) The Consultant must propose a schedule of payments that will be
discussed and finalised at negotiations.
3) The Client shall assist the consultant in obtaining work permits for
any of its foreign employees if required.
4) It should also be noted that the import of any materials or property
must be in accordance with the local laws.
7.4.5 General:
1) All bid documents become the property of the Client
488571860.docx Page: 38
2) The decision of the Client regarding the choice of a Consultant is

final and is not subject to appeal.
488571860.docx Page: 39

2 - TOR - Specs (IMIS) 2.0

Uploaded by

Copyright:

Available Formats

2 - TOR - Specs (IMIS) 2.0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 - TOR - Specs (IMIS) 2.0

Uploaded by

Copyright:

Available Formats

[Name of Client] Technical Terms of Reference

Contract Number: number

Supply and Implementation ofan Integrated

Technical Terms of Reference

1. Aims and Objectives of Project

2. General- System Requirements

that will include various attributes like enforcing alphanumeric

2.2 Land Information system (LIS)

to a building which is attached to a plot. As a result it becomes

3. Commercial systems (Billing & Customer Services)

of transactions with a drill down facility, a (c) Receipting Database that

3.2 Commercial System configuration and administration

1) The user should be able to define project parameters such as

3.3 Management reports

3.4 Enquiries and Customer Reports

3.5 Commercial Data Evaluation(CDE) & Customer Contact centre

3.6 Customer Services and Connections/meter management System

3.7 Financial Services

Authorisation control should be based on user level and allow for

3) Provide financial reports to show transactions for a specified

3.8 Meter Reading Systems

2) Provide various filtering options to easily focus to problematic

3.9 Smart Metering system (optional)

2) Instantaneous flow & pressure per property used in Hydraulic

3.10 Receipting/ Customer Payment

3.10.2 Payment by Customer should be through multiple options including (a)

exception reports should be prepared in order to ensure accurate

3.12 Debt Management

5) The system should be able to produce full aging analysis of all or

3.13 GIS and Land and Survey Department interface

basically daily tasks. The facility should be a template-based interface

3.15 Pricing & consumer analysis

4.2 Monitoring & Control Systems

4.2.2 Link to telemetry: The system should link to SCADA database

4.3 Asset Management - General

4.4 Asset Management - Condition Assessment & Evaluation

4.5 Asset Management - Rehabilitation Planning

4.6 Maintenance Management Systems

present the plant equipment based on inheritance and functional

network maintenance; accounting systems for job costing data; stock

4.7 Maintenance Management System - Web Access

4.8 Distribution/NRW Management Systems

4.8.8 Un-accounted for water (UFW) Analysis: UFW analysis should be

4.9 Planning: Demand Analysis

4.10 Planning: Network Analysis & Optimisation

4.11 Management reporting

5.2 Project Management :A liaison group or steering committee will be formed

5.3 Activities: The following activities are identified to be carried out

5.4 Activity 1: Requirements definition & mapping:

5.5 Activity 2(a): Data Conversion and Evaluation– Technical systems

5.6 Activity 2(b): Data Conversion & Evaluation – Commercial systems

5.7 Activity 3: System customization, setup & configuration

5.8 Activity 4: System acceptance testing

5.9 Activity 5: System Installation and Training

5.10 Activity 6: System post-implementation support:

Consultant from commencement of contract, suitably trained and

5.11 Client Responsibilities

5.11.3 Computer Hardware, Operating systems and Communications: The