Invitation:

Expressions of Interest

for the provision of

Local Government Software, Integration Services, and Application Services

for a syndicate of NSW Councils.

Final Version : September 2000

Each of the Councils comprising the syndicate invite expressions of interest from prospective supplier(s) in the following areas:

The scope of these services is represented diagrammatically at Appendix C.

Responses to this Expression of Interest (EOI) document can be submitted in relation to any or a combination of the above 3 options. However, where an organisation indicates that it wishes to undertake parts 1 and 2, the ability to fulfil both roles, without any negative impact on service levels, needs to be clearly demonstrated. Some Councils’ experience with software providers also performing the role of software integrators has not been positive.

The syndicate is seeking innovative solutions that may not be limited to complying with specific requirements contained in this EOI. Respondents are therefore encouraged to suggest broad-ranging solutions. Each syndicate member reserves the right to implement any or all of the options dependent on the responses to the EOI and the needs of the individual syndicate members.

Following an evaluation of the expressions of interest the syndicate members expect to proceed to a selective tender process to evaluate prospective supplier(s). The expected timeframe for this is as follows:

• Selective Tender Early 2001
• Tender Selection Second quarter 2001
• Contract Negotiation Mid 2001
• Pilot/phased implementation Third quarter 2001 – end 2002

The anticipated timeframe is subject to variation and the syndicate members will not be liable for any changes to the anticipated time frame.

At the conclusion of the tender selection process it is anticipated that a preferred contractor or contractors will be selected to enter into negotiations with a view to entering into contracts with individual members of the syndicate.

Prospective suppliers are advised that it is the present intention of the syndicate members that the process be conducted by the syndicate on behalf of the individual Councils but that the ultimate contracts for supply will be between the successful supplier(s) and the individual Councils. Any one or more of the syndicate members may elect to withdraw from the process at any time prior to it entering into a formal contract.

The syndicate will evaluate Expressions of interest received in order to assess which prospective suppliers (if any) will be invited to participate in the selective tender process.

In the course of the evaluation process, the syndicate may request additional information by way of clarification or otherwise. The cost of providing any additional information must be borne by the prospective supplier.

Prospective suppliers are advised that the syndicate reserves the right to seek clarification, verification and additional information from third parties, and the potential prospective suppliers authorise the syndicate to do so.

All valid Expressions of Interest will be evaluated in accordance with the General Evaluation Criteria, the Technical Evaluation Criteria and the other criteria specified for the various components of the software and services. The criteria are not listed in any special order, will not be accorded equal weight and are not exhaustive.

Criteria for the evaluation of the expressions of interest will include the following:

• The ability to meet the explicit and implicit requirements contained in this Expression of Interest document.
• A proven commercial track record including references.
• The ability to work and form partnerships with other supplier(s) within the context of the overall solution.
• The preparedness to foresee the future business opportunity which may be presented by the proposal.
• The commitment to be involved in a long-term partnership with the syndicate.
• Ability to manage a variable timetable and individual syndicate member issues.
• Supplier(s) profiles

• Supplier(s) demonstrated ability to deliver, including reference sites
• Supplier(s) Project Management Experience
• Supplier(s) Project Management Methodology
• Innovation

• Potential to provide benefits from innovative solutions for syndicate members.

• Ability to deliver improved business processes.

• The approach to customer service.
• The flexibility to meet current and emerging needs of customers in a progressive manner.
• Supplier customer service support structure, framework and history
• Cost structures including flexible licensing arrangements.

Additional criteria have been specified and included in each of the three segments that respondents may wish to respond to: Software, Integration and Application Service Provision.

All responses will be assessed in terms of feasibility of proposal provided, based on accepted industry technical standards and criteria.

After evaluation of valid Expressions of Interest the syndicate intends to invite selected prospective suppliers to lodge a formal tender in respect of provision of the services.

The syndicate is not bound to proceed with a selective tender process and is entitled to elect not to invite any prospective supplier to lodge a tender.

In submitting an Expression of Interest, prospective suppliers acknowledge and agree with each of the syndicate members that the decision of the syndicate members in relation to Expressions of Interest received by the syndicate in response to this invitation will be final and not subject to challenge, dispute, explanation or further correspondence.

The syndicate has no predetermined format for expressions of interest. However, it is expected that responses will include: how the requirements will be met, organisational profile, details of comparable projects and products, commitment to quality services, details of products, partners and relationships, details of flexibility, options, how shortfalls in product functionality (if any) can be addressed, the relationship foreseen with the syndicate and the potential for future business from the proposal for all parties. Responses must include a completed "Supplier Profile" (Appendix B) for each supplier included in any proposed solution.

Expressions of interest must:

1. Be Clearly Marked as: EOI for Local Government Software, Integration

Services, and Application Services

2. Be Addressed to: Hayden Pauley

Parramatta City Council,

30 Darcy St. Parramatta

N.S.W. 2150

3. Be received/placed in the Tender Box, by 4.00 p m October 27^th, 2000
4. Include a soft copy of the Expression of Interest, either on disk or cd – Rom for ease of use and distribution to each of the syndicate Councils. Where material is submitted that is not included in the electronic copy, 9 copies should be supplied.

An information session for prospective respondents will be held as follows

The syndicate is interested in a long-term partnership relationship with supplier(s). Supplier(s) are expected to have an ongoing commitment to Local Government. This includes an ongoing commitment to research and development and evaluating emerging technologies.

Councils are seeking to develop relationships with the supplier(s) that are mutually beneficial. The end result of the successful implementation of the specified system(s) is seen as a highly marketable product within the local government industry.

Further information may be obtained from: Mr Ron Posselt

Lake Macquarie City Council (02) 49210270

This section specifies the functional requirements of the software. The scope covers most council functions and these are identified in the diagram below. The Overall Aspects section (Appendix D) covers the issues that exist across all the applications and include broader governance issues. Individual module descriptions are broadly described in Appendix E. Software nominated in responses must meet the requirements of the main functions or identify where additional functionality will be required and how that functionality will be achieved.

In addition to the general evaluation criteria on page 3 the evaluation of responses to this section may include any or all of the following:

• Ability to meet/address the main functions listed for each business module as identified at the beginning of each module and included in Appendix E.
• Ability to address the issues identified in the ‘Overall Aspects’ Section – Appendix D
• The ability of each software module to integrate/interface with others as specified.
• The ability to meet syndicate needs through flexible approaches (scalability, implementation, change management, parameterisation).
• Ability of software to accommodate easy integration of data, products or any other tool.
• Relationship management arrangements proposed for multiple suppliers.

Integration is a major issue for the syndicate and Local Government in general. The wide variety of applications required by Local Government and the level of integration required across all applications and through management information systems, corporate workflow and document management has made integration a testing issue in the past. Often a software supplier has been forced into the role of integrator with less than satisfying results. Performing both roles of supplier & integrator has often led to negative impacts on service levels.

The syndicate wishes to explore the options and benefits of an independent system integrator to coordinate the integration, interfacing and delivery of the software applications identified in Section 1. The syndicate is seeking expressions of interest from companies who are interested in performing this role.

To some extent the services required from an integrator are dependent on the products being integrated. Integration issues also have a heavy presence in the software functionality in Section 1. Some of the services required by the syndicate are:

• The design and delivery of an integration layer or application to integrate the products
• The design and delivery of an interface regime across the products
• The integration of a corporate workflow system within the solution
• The management of contractual relationships with all software supplier(s) to ensure integration issues are adequately addressed over time
• The ability to work with the supplier(s), client councils and if necessary an application service provider

Additionally, the syndicate is seeking details as to how the integrator would manage and achieve the integration of:

• Core software applications common to all members as identified in the earlier scope diagram.
• Existing and future peripheral software applications

In addition to the general evaluation criteria on page 3 the evaluation of responses to this section may include any or all of the following:

• Demonstrated experience as integrator
• Integration Methodology
• Demonstrated ability to work with multiple platforms and multiple suppliers
• Demonstrated ability to co-ordinate software vendors to improve integration process
• Ability to integrate new software module releases seamlessly, in a timely and cost effective manner
• Ability to allow flexibility between real time and batch updates

The syndicate is seeking expressions of interest from companies interested in hosting the application services outlined in Sections 1 and 2. The application suite will be required to be delivered to the participating councils in the Sydney region, to Lake Macquarie in the Hunter Valley and Wyong on the Central Coast. The service should have the potential to be delivered to any local government area in Australia.

It is recognised that the ASP may also seek to perform the integration services. The ASP may also seek to host services and work with a separate systems integrator. The syndicate has an open mind on these relationships.

Responses should include:

• The structure and infrastructure of the ASP
• The performance which can be guaranteed to users
• How security is managed within the ASP environment
• The options and recommendations in relation to communications infrastructure
• Management processes required/recommended such as Service Level Agreements
• How the ASP would work with the service providers responding to Sections 1 & 2
• Scalability of the hosting infrastructure
• Redundancy provided
• Disaster recovery arrangements
• An indication of potential implementation timeframes based on the syndicate members profiles as per Appendix A
• Cost structures: including estimates and licensing arrangements

In addition to the general evaluation criteria on page 3 the evaluation of responses to this section may include any or all of the following:

• Ability to provide flexible and unrestricted syndicate member access to individual member data
• Business service continuity processes
• ASP Methodology
• Security provided
• Communications infrastructure
• Quality of service level agreement arrangements
• Scalability and redundancy

Data is indicative only and as at June 2000.

Appendix D - Overall Aspects – Software

Individual application requirements are defined in the requirements for each module in Appendix E. There are, however, a number of requirements which flow across all applications and which need to be considered on a system-wide basis. While the functionality of the individual modules is important it is as equally important that the overall aspects of the system are met.

1. Broad Functionality

It is expected that the system will utilise current technology such as graphical user interfaces, drop down menus with point and click actions and run on current architecture (eg 32 bit).

1. User Interface

• Windows graphical user interface with as much commonality as possible;
• Provision of user-definable forms;
• Quick access for the user, ie. ‘Hot Keys’ to enable jumping around the application while in an option;
• Help facilities accessible via function key. These should be able to be updated by ‘customised User Procedures’;
• Availability of ad-hoc Screen Print;
• All screen enquiries should optionally print to a printer or file;
• User-definable screen customisation by user and by application with relevant security.

1. Functionality

• System application parameterisation;
• Ability to utilise SQL tools;
• Dynamic links to MS Office (Excel, Word, Access, PowerPoint etc.);
• Extensive search facilities with alpha/numeric search on key fields;
• ODBC compliance;
• Interface to an EIS product; (PowerPlay/ CorVu etc);
• Data purging should be at user discretion and easily retrievable and should allow archiving to CD/optical disk;
• Provision of electronic signatures;
• Central calendar and application level calendar to enable flagging of weekends, public holidays etc;
• Provision of ‘test company’ ie a training or test area within the system with appropriate test data.

1. Reporting

• User-definable report writer application allowing flexibility in parameters chosen eg range of date, account numbers etc;
• All reports should print to screen, file, e-mail, PC disk/CD and printer;
• Ability to print, fax, e-mail all letters and forms;
• Full drill-down facility from enquiry to original transaction and source document;

All applications should reference the central NAR to ensure data integrity and consistency. The NAR is a central point for all contacts doing business with the councils both internally and externally. There are multiple contacts held in the NAR such as:

• Supplier(s)
• Employees
• Ratepayers
• Property owners
• Developers
• Councillors

The information held in the NAR is governed by privacy legislation and requires strict security controls.

There are a number of requirements for the NAR and these are highlighted below.

1. The system should be scalable.
2. The ability to identify and profile each customer held on the database.
3. Provision of a de-duping mechanism.
4. Provision of user-defined fields for additional information on customers.
5. Ability to provide for ‘smart searching’ to find information readily eg phonetic searches.
6. The requirement to market to customers using the NAR to generate profiles.
7. Being able to recognise saleable data in the name lists.
8. Ability to link to every application within the system.
9. Provision for multiple roles (employees could also be ratepayers.)
10. Provision of links to e-mail and Internet.

See section 9 for a sample NAR specification.

 

2.2 Property Register

11. One centralised property database is required and is defined in the Land Information System details.

Interfaces are expected to be ‘user-defined’ mapped data taken up into any proposed system in batch mode, whilst integrated data should be real-time information updated upon confirmation of transaction detail. Whilst there have been a number of interfaces identified, there may be options available to provide the required information elsewhere, this must be clearly addressed/defined in any future solution. The required ‘interfaces’ should be seamless, interactive and automated and should require no human intervention. These interfaces should include interfacing to the Internet and web-based sites and systems.

It is expected that a consistent user-interface be provided across the system.

In particular, all applications are required to link to the document management system and interfacing is expected to the applicable GIS systems currently in place at each council

The system is required to have a cross-application workflow system that will enhance the way work is processed within the councils and automate processes leading to increased efficiency. The following functionality should be supported in workflow system that will need to be closely integrated with the document management system.

• Graphical event-driven procedures defined by the appropriate system administration function.
• There is a strong need to work collaboratively on documents with anybody, both internally and externally. This should be supported.
• The merging of correspondence (both incoming and outgoing) seamlessly with a document management system is critical in an organisation where paper and documents are generated everywhere.
• Workflow structure should be easily maintainable with given security.
• Automated event triggered e – mails where any process falls outside the defined criteria.
• The workflow system must be platform independent, but would operate in a standard networking environment.
• Links should be provided to both KPI reporting and ABC.
• Workflow should be rule-based and auditable eg. exception, delegation, escalation.

Reporting must be a simple process; either by the utilisation of standard reports with sort keys for dates and groups and/or by the use of ‘point and click’ reporting tools which may be manipulated and downloaded to MS Office or EIS tools. Through the use of these tools users should be able to view data through any method/view required.

These tools must:

• Be user driven and not require the expertise of IT personnel
• Be available for local desktop use
• Be self selective and automatic
• Have an easy to use data dictionary
• Have the ability to access historical data
• Report on key items (KPIs) and data that are critical to the business on a daily, weekly and monthly basis
• Have a graphical user interface
• Be flexible
• Support strong graphical representation

User-defined reporting should allow the following attributes:

• Report scheduling or chaining of reports together
• Visibility of data
• Environmental reporting
• Boolean reporting in plain English eg and, or, if, else, >,<, =
• Report delivery by e-mail, mobile, v-mail, other
• Export to screen, file, e-mail, pdf
• Allow templates to be defined for reports
• Store reports at system or user level
• Corporate defined reports

KPI’s are many and varied, dependent on the business unit and the style of service delivered. The following attributes are required at a minimum:

• KPI’s should be available at any level and council defined;
• KPI’s should be linked to workflow;
• Links to events;
• KPI’s should be linked to Human Resources;
• KPI’s should be linked to Customer Requests;
• Capability of presenting quantitative and qualitative data for management analysis and benchmarking;
• Provision of drill-down on KPI’s;

There is a requirement for software to aid councils in the development and maintenance of integrated strategic plans that deal with planning data, financial data and organisational performance data. These tools should be easy to use and broadly be able to achieve the following:

• The ability to use financial data and Management planning data simultaneously as part of an integrated planning, budgeting and performance management process.
• The ability to integrate data from the wide array of plans produced by Councils (eg management, strategic, social, environmental, asset management, and business unit) electronically.
• Access and input by a wide variety of staff
• User defined parameters and flexible reporting

It is as yet unclear as to what data might be converted by the councils. In making this decision, there are a number of issues that need to be clarified:

• What should be converted?
• Where should data be archived?
• How data conversion will be managed?
• How non-converted data will be accessed?

If a third party is used to manage the data conversion, clear definition of: data responsibility; development of translation tables for the mapping of data; and data conversion acceptance will need to be provided.

The provision of a ‘testing/training system’ is required to allow training of staff in a non-production environment and to test system updates without impact on the production environment. It will also be required to test conversion procedures.

The syndicate has no preconceived implementation plan but wishes to work with supplier(s) on suitable implementation options. This will include different implementation timeframes for each Council.

Proposed systems should be supported by clearly defined contracts and Service Level Agreements covering the following areas:

• 24 hour by 7 day service and support
• enhancements
• change management control
• user group support
• inclusions and exclusions (cost)
• hardware and software help desk
• performance guarantees covering interfaces, downtime etc.
• other options such as; shared services, outsourcing and facilities management

In changing the existing applications software systems, the syndicate members recognise that this will involve a major change transformation of their organisation. The opportunity that is presented is not just simply to replace the software but more importantly to add value to the Syndicate members’ organisational operations. This can be achieved by reviewing and improving services to enhance efficiencies. Potential supplier(s) will need to work with syndicate members to maximise this opportunity to add value to Syndicate members’ operations.

Respondents are to indicate what services and support they will be able to provide to assist in this process.

The syndicate is seeking flexible licensing/pricing models for software. This will need to reflect usage but must also seek to address maintenance and variations to the way work is undertaken in Councils. Enterprise–wide licensing should be considered.

It is anticipated that any future system will have a minimum system life of 10 years and therefore the supplier(s) must be committed to a long-term partnership with the syndicate. To ensure longevity of source code, software in escrow should be considered and updated on a regular basis. Maintenance charges should cover product upgrades for at least this period.

The inherent security layer of the application system should be centralised for all applications. This should allow a "one profile many links scenario". This central profile maintenance function should take into account different level of access to applications. Additionally, the different levels of access could be based on a "group" security profile or "individual" profile. e.g. Once a person is registered in the system all applications link to this one profile making it unnecessary to have multiple security profiles individually maintained at the application level. This should be supported by a central Authorisation/Responsibility code that also contains delegated authority information. Security should allow for compliance with acceptable internal process controls, Industry and Best Practice Standards.

History of changes to data should be maintained and be available for review and tools such as exception reports/enquiries should be available. The systems should support a single sign on with user-defined access periods where screens are logged off automatically after non-use. Flexibility in security levels should be supported and easily maintainable with archiving and audit trails as required. Audit trails of all master file changes and transaction file updates should be standard.

In order to support the changing face of council business and to provide better service and information to our customers, any prospective system should support e-Business. This means many things but the requirement includes, but is not limited to:

• Support of Internet with both static and interactive web information available;
• Business to business support to allow the management of council supplier(s) and contractors;
• Business to consumer support allowing all viable information to be available on the web (including up to date information from back office systems) eg. library books, development applications, customer requests, rates payments;

All the above information would be tailored to suit the council’s individual needs and must be supported by security, audit trails and accountability. Information should be automatically updated on the internet, from the corporate system, without data re-keying.

Environmental Accounting will provide for the management and accounting of non-financial assets into the future. It will provide a focus on certain assets with relevant KPI’s and reporting. The maintenance of environmental assets and their related costs should be captured.

An integral part of Local Government is being more competitive through increased efficiency and productivity. This requires that any proposed system allow for the apportioning of costs based on Business Units. The ability to allocate costs via an Activity Based Costing system (ABC) or similar mechanism in a manner that is flexible and largely transparent is also required.

Some of the councils within the syndicate are already reviewing and indeed considering the implementation of a suitable Customer Relationship Management system (CRM). This functionality would support the business by managing much of the day to day contact with customers and tracking a full history of interaction between the councils and customers.

Any proposed system should support the CRM strategy and should be capable of integrating to the information systems proposed.

The syndicate recognises that any proposed CRM system is a substantially more comprehensive system for managing our customers than a traditional ‘Customer Request’ system, as identified in the scope diagram. This has been the basic system used in Local Government for the generation work orders.

The system should capture, maintain and report on GST as appropriate and in accordance with the standards provided by the ATO without manual interference by council staff.

The system should provide for remote access via telephone line, mobile, web, microwave link, with access via laptop, PDA’s, communicators, etc. Remote Access should be supported by appropriate security measures including user identification and audit trails.

Ref #

Person/Company (P or C)

Title

Surname/Company Name

Given Names (if P)

Contact Name (if C)

Alias

Date of Birth (if P)

Sex (if P)

ABN (if C)

TFN (if P and secured)

Licence No/s (ie Builders Licence No. etc.)

Interpreter Required (Y/N)

Language/s (other than English)

Home Phone

Work Phone

Extn (if Work Phone)

Silent

Mobile (multiple)

Fax Number

e-mail (multiple)

Website

Suppression (Y/N)

Pensioner Type (parameterised)

Pensioner No.

Property Address

Property Address Australia Post Barcode

Preferred Address (either property Address or other address (this other address must have preset fields)

Preferred Address Australia Post Barcode

Bank Account Details (secured)

Credit Card Details (secured)

**Web Access Security ID

**Web Access Password

**Web Access Status (C-Current, S-Suspended, I-Inactive, H-Historical)

Name and Address Link File (multiple links must be supported)

Application Code

Application Reference

Name Reference No.

Link Address (being either property address, preferred address or other address)

Link Address Australia Post Barcode

**By holding these details on the Name and Address Register, we could restrict access to records within any application to those that have a link to this name. ie. Could only view applications with a link to this name, rates details linked to this name as either an owner or ratepayer or debts linked to this name etc.

Local Government must ensure that their management plans and budgetary controls will enable actual income and expenditure to be monitored on a monthly basis and compared to estimates of income and expenditure. Variations between planned and actual expenditure and income must be reported at council meetings and supported by adequate documentation detailing the variations.

It is essential that council’s accounting records and accounting practices are in accordance with the Local Government (Financial Management) Regulation 1999 and AAS27.

The business functions that support financial management are:

• General Ledger;
• Budgeting and Costing;
• Cash Management;
• Bank Reconciliation; and
• Loan and Investments.
• Fixed Asset Accounting.

The general ledger should reflect the results of the day to day business of the councils. It may include the cash management and budgeting modules or they may appear as separate subsidiary modules. However these are handled they should be accessible via relevant security measures and should allow full drill-down to each of the supporting modules across the system.

General Ledger - should allow multiple control accounts for bank, debtors and creditors and should be flexible to manage change. It should handle both commitment and statistical accounting and should allow simple and complex reporting for all aspects of data held.

Cash Management - should allow the maintenance of multiple bank accounts and their respective bank reconciliations with integration via the web of the daily bank statements. It should allow cash flow management and simple to use reporting tools.

Budgeting - this is a complex area for the councils and should allow for commitment accounting ie. allocation of commitment against budget on a period and year to date basis. Obviously, a simple report writer would be necessary together with easy and dynamic links to Excel.

Cost Accounting - The cost accounting system includes the General Ledger, Activity Based Costing and the Works Order System. A relationship should exist within the overall cost accounting system that provides a separation between cash (revenue and expenditure) which is external to Council and transfers within the organisation. Cash expenditures should be classified as Labour, Material or General while transfers should be either Material or General.

Transactions should be able to identify both the provider (organisation unit incurring the expenditure) and the purchaser (organisation unit responsible for payment) for both cash and transfer transactions. However, this development should not assume full transfer pricing or internal invoicing as a direct consequence but as a possible option.

Security should be placed on transactions to protect organisational units from expenditures made on their behalf by unauthorised users.

The Loans and Investments module must provide for the management of loans and investments made by the Council as well loans taken by the Council. The system must enable tracking of the source of original funds and allocate the associated interest.

The management of assets across the enterprise is complex due to the variety and nature of the assets held. This business area should be read in conjunction with Asset Management and Maintenance module and supports the financial aspects of all assets.

The Asset Management system is broken down into three main areas:-

1. Financial aspects of an asset
2. Management of assets to ensure they are utilised and costed appropriately.
3. Maintenance of assets in order to prolong the life of assets and maintain a standard which is in keeping with projected KPI’s. The maintenance of assets is critical in reducing risk to the councils.

The management of inventory is wide-ranging and covers a multiple of business units and application.

The inventory purchased is:

• used in a job or project
• purchased based on a works order
• bought for internal stores and based on re-order levels
• asset purchases
• administration assets

Inventory is held in multiple locations and is managed locally.

Inventory can be purchased based on:

• purchase requisitions with approval process
• purchases orders within authority levels
• ad-hoc purchases ie. prompt purchases
• purchases based on budgeted expenditure

Suppliers are accredited and are stored as preferred suppliers on the inventory master file. Where a new job/project is anticipated calls for tenders from suppliers are generated and need to be tracked to successful awarding of supply contracts.

The business functions that support supply and inventory management are:

• Accounts Payable (Creditors);
• Contracts and Agreements;
• Inventory Management; and
• Purchasing.

The Accounts Payable module should provide management of the payment relationship with creditors to ensure that the most optimum terms are achieved for the council and ensuring maximum discount taken when appropriate. This module should facilitate the efficient payment of creditors while contributing to the cash flow management process.

Contracts are many and sometimes complex to manage.

They include managing the relationship with the supplier, ensuring they are performing to the agreements that have been made and the times committed. The process of managing contracts is time consuming and tedious and is mostly manual.

The tracking of monies due, retentions, progress claims and variations are all closely linked with the Project/Job costing systems and therefore must be tightly interfaced. Links with the purchasing and tendering process from suppliers is also critical in order to co-ordinate the process and maintain historical information of suppliers and sub-contractors.

The councils require an easy to use application or tool to provide flexible functionality in the area of inventory management. Inventory is held in many locations, and all locations are highlighted within the GIS system.

The requirement in this area should allow for multi-location, multi-category, barcoded stock that is easily identified and costed at stock-take time. Stock may be held by location ie. store, business unit, person, job, department and can be purchased from any of the accredited suppliers.

Inventory should be requisitioned by customers following appropriate approvals and automatically be forwarded to the store electronically. This should be possible from external sources.

The purchase orders system requirement covers all aspects of requisitioning and purchasing for all business units within the council. The council wishes to move towards a ‘self service approach’ . This is seen a an integral part of the future.

The purchasing system and subsequent purchase orders should reflect against budgets allocated by business unit and/or cost centre (commitment accounting) and should allow reporting/enquiry against a budget at any time.

Purchasing must be linked to work flow to allow the delegation of authority ie. allow the approval of a purchase order by the appropriate officer.

Requisitions should be able to be generated by any staff member and appropriately approved based on authority level. These requisitions should, once approved be automatically converted to a firm purchase order subject to the appropriate approval, budgets levels and classification of goods required.

Purchase orders should allow electronic submission to approved suppliers with subsequent receipt of order confirmation from these suppliers.

Managing Council projects and assets is a challenging task. With some components of the functionality in finance and some components in Engineering, the disparate nature of the modules is not conducive to effective project management.

The councils must have full integration through the following areas of functionality, and these must be ‘user-friendly’ with workflow tools managed throughout.

The business functions that work planning and assets include are:

• Asset Management/Maintenance;
• Plant;
• Fleet;
• Works Estimating; and
• Project Management and Job Costing.

The management of assets for councils has huge implications across the planned Information Systems. This stems from the fact that assets are many and varied and are maintained in a number of different ways which may alter from year to year with the introduction of any new legislation ie. environmental accounting.

Whilst the councils have standard assets, they must maintain all the following types:

Maintaining these assets crosses over a variety of areas within the organisation and must provide real-time links within these.

Management of Environmental Assets should be allowed for with user-defined attributes.

Standard depreciation schedules will be applicable and assets may be revalued or upgraded at any time. Assets may be funded from a variety of sources, and this must be tracked also, along with the approval code and council minute.

Assets maintenance works orders may be triggered or generated from a variety of sources:

• customer request
• staff member
• schedule or ad-hoc maintenance
• budget improvement
• capital works

Assets require tracking by all the asset attributes but also to ensure that each asset is maintained to lengthen its useful life and provide the forecasting capability to enable careful planning for replacement as well as identifying resources required to perform the tasks.

A number of small and major plant allocated to works are currently costed using asset journals that have the effect of debiting an expense account, and crediting an income account, (plant costs recovered) as well as crediting the income on the asset in the subsidiary assets ledger. The plant manager uses the plant recoveries per asset, and in total, to manage the setting of charge rates on plant usage to offset the expenses also allocated against that asset. It is important that this is managed either by the allocation of costs against works orders directly or some other efficient manner.

It should be noted that there are a number of specialist asset management systems in use by the councils (and they differ), and these may need to be used in any new environment e.g. PARRMS, SMEC for the management of pavements, and others. A full list of which will be included for further information. Interfaces may need to be considered on a case by case basis.

The Works Estimating requirement covers the expected functionality that the councils need to estimate any given project/ job and also to collate data from many areas of the organisation such as:

• customer requests review, rates and their subsequent review, special skill requirements, projected fund requirements, asset allocations, suppliers and tenders, overheads.
• estimates converted to actual project/job pending approval by council and funds allocated.

Estimates should be kept for a user-defined period and may change a number of times prior to the actual finalisation and conversion into a project. History of this type of information is critical and should be maintained for ad-hoc reporting. Projects may be of a varied nature, and should be hierarchical in their set-up i.e. grandparent/parent/child. These estimates should be security controlled by set-up and should contain user-defined tables for flexibility.

An estimate could be initiated as part of standard upgrades to facilities (based on budgets) or by the receipt of a customer request (rate payer, councillor, staff member). Regardless of how the estimate came about, the system must be capable of collating costs (labour, materials and overheads), allocating funds (Source of Funds) and scheduling resources when the project begins life. The management of the expected timeframe for the project is also critical.

Naturally, when all data is entered any number of reports or "what-if" analysis may be required and this should be very user friendly in order to ensure that end-users utilise the full functionality of the systems.

Plant and Fleet covers the management of existing plant/fleet assets for the purposes of ensuring utilisation, cost recovery and timely allocation to jobs/projects across the organisation.

The management of hire rates and the calculation of utilisation should be easily catered for together with the integration to Asset Maintenance to ensure the assets are repaired as required in order to ensure assets have a prolonged useful life.

There are many and varied projects running concurrently throughout the council organisations. The objectives of these projects must be managed and measured against pre-defined Key Performance Indicators.

Projects may be of any size or nature, from the upgrading of facilities to the design and build of a new library. They may be financed from different funds sources and may or may not be capitalised dependant on the project.

Works estimates are completed and submitted for approval; these are then processed and converted to live projects. It is expected that any future system would manage this process from conception to completion and then forward to maintenance for care. Projects collect a variety of costs (labour, materials and overheads) and these must be tracked daily, weekly, monthly and by project as a project my cross over a financial year end.

Resources on these projects must be tracked and timesheets should be accurately entered to ensure labour costs are correctly allocated.

Invoicing for selected projects must be catered for covering both internal and external projects.

All projects must be monitored and comparisons against original estimates for all resources must be managed. Where a surplus of funds exist against a project, these should be identified in an exception report.

Council’s must effectively manage the processes of forecasting, calculating and collecting revenue to ensure sufficient cash flows to provide required levels of service to the community. Council has the opportunity to raise revenue through a limited number of sources, the primary being levying of rates, and secondarily through provision of services (such as facility hire, child care, waste collection), application of fees and fines (such as infringements, application fees and licence fees) and sale of good (such as bins, plants and mushroom farms).

The ability to perform revenue projections based on actual data is essential, as is the tracking of actual revenue against these projections.

The business functions that support revenue management are:

• Rates Accounting;
• Cash Receipting;
• Debtors; and
• Debt Recovery.

It is the Council’s preferred objective that the Rates Accounting functionality is seamlessly integrated with the Land Information System and that all property data is stored in the Land Information System without duplication. The Rates Accounting functionality must be flexible to accommodate changes in methods of calculation, additional rates charges, types and rating categories.

Cash receipting should provide the council with "intelligent" point of sale functionality that supports the customer service representative through the provision of adequate detail during the interaction with the customer. The system must be capable of receiving payments for all Council revenue sources at both on line and off line point of sale devices, via Internet and through direct bank deposit.

The Debtor (Accounts Receivable) system must be able to manage multiple debtor types (including rates, services, sales, infringements and miscellaneous) in a central repository that enables the full debt relationship with the person or entity to be recorded and managed. The process of managing debts and their recovery must be fully tracked.

Limited debt recovery functionality should be available in the debtors system, however this should be supplemented by a full functionality, integrated debt recovery module.

The Corporate business functions are key systems that support all of council’s business activities and therefore must be available across the organisation.

The Land Information System should serve as the single, central source of all property based data. To ensure the validity of the data, it should not be replicated in other modules.

The ability to perform revenue and expenditure projections for all corporate business activities, based on actual data, is essential, as is the tracking of actual expenditure and revenue against these projections.

The business functions that support the corporate function and are required organisation wide are:

• Document Management;
• Customer Requests;
• Land Information System (Property Administration and Subdivisions);
• Facilities Booking; and
• Event Management.

In addition, the following corporate business functions are required for selected users;

• Property Management (Council Owned Properties/Valuation); and
• Legal Service, Insurance and Risk Management.

Increasingly information in organisations is being stored in electronic format. Files are stored in a wide variety of unstructured formats, such as word processing documents, spreadsheets, scanned images, graphics, slide presentations, CAD drawings, email messages, as well as audio and video. The document has become a live entity with an active responsibility to the organisation, in many ways equal to that of an employee. Documents are no longer viewed as peripheral to the business process, but have come to embody the process itself. Document-enabled applications are increasingly becoming the only way government authorities around the world can provide and measure the services demanded by regulatory bodies.

Document management technologies provide a way for organisations to manage their electronic documents as the important corporate assets that they are. Document management systems allow organisations to control, find, share and store documents. These systems facilitate the needs of multiple users who need to locate and work on a single document or group of documents, regardless of the document format. DM systems add business context to documents. Users can profile electronic files, associating them with indexes or profile information that describes the file and its content. By searching based on profile information, users can quickly locate documents that relate to a certain index field, without having to concern themselves about where particular documents are actually stored.

The commonly cited benefits of document management include:

• Control over the document creation and distribution process;
• Improved user productivity;
• Improved accessibility of information;
• Improved collaboration and information sharing;
• Business process automation;
• Faster customer response;
• Assurance of accessing the most current information available; and
• Compliance with legal requirements.

The five major challenges for government sector managers seeking to exploit integrated document management technologies include:

• Avoid the pitfall of merely using imaging and workflow technologies to generate electronic versions of existing paper-intensive practices;
• Identify how document management technologies can measure the level of service provided;
• Realise that the application sought is rarely unique;
• Avoid the "Big-Bang" approach and adopt a phased implementation; and
• Avoid the justification of document management technologies by removing clerical staff.

A key issue that was identified was the need for any document management system to fully interface with all other systems run by the Councils.

The Customer Request system is the major interface between the public and the Council. The system must be capable of managing requests that relate to a property or are independent of a property.

It is essential that the centralised customer request system by accessible to all council staff and be supported by an extensive knowledge base and work flow systems to ensure that the most effective and efficient interaction occurs between councils staff and customers of the council. There must be seamless integration between the Customer Requests system and relevant modules as applicable, for example if a request requires a work order to be generated then the Works Order input screen is displayed.

The Land Information System (LIS) is the core repository of textual information on property within the Council’s jurisdiction. The LIS should form the base system for all property related data collected and managed by the Council and thus the other modules (such as Rates Accounting and Waste Management) should draw on this common data avoiding duplication. There should exist the ability for the user to navigate easily from the property record to any related modules.

The LIS is supported by graphical format data in the Graphical Information System.

The Council has a large number and wide variety of facilities ranging from parks, halls to swimming pools that must be carefully managed to ensure that the maximum utilisation is obtained. The system should allow users to collate sufficient detail on a facility and it’s suitable use to maximise it’s utilisation whilst maintaining quick and easy data entry.

Ideally, the ability to create a facility booking should be available seamlessly from the Customer Request system. Facility bookings may be made on behalf of internal council or external clients.

The council has requirements across many business areas to organise and conduct events both in council venues and at other locations. The Event Management system must be flexible to accommodate the wide variety of events organised by the Council and able to maintain ease of use regardless of the complexity of the event. The system must be capable of recording events being held in the Local Government area, but not the responsibility of the Council, to enable creation of a comprehensive event calendar.

The Event Management system must be fully integrated with the Facilities Booking system, or they may inturn form part of the same system to ensure effective planning and utilisation of Council facilities.

Council must ensure that it tracks the investment made in property both capital and ongoing expenditure associated with ownership and maintenance.

The council must effectively manage property they own and have been given the responsibility for managing (such as Crown Land). A key part of this property management responsibility is to ensure that the properties are efficiently tenanted with commercially competitive rental returns. The system must provide adequate detail to enable income and expenditure projections. It is essential that the Property Management system be compliant with the NSW Residential Tenancies Act requirements.

The management of legal process, insurance and risk is an integral part of the management process for the Council. These are multi-faceted processes which produced a great deal of discussion and debate.

It was identified that some requirements for legal, insurance and risk management are common, and these have been captured below. Requirements that are specific to each function are then detailed individually.

Discussions held during the Risk Management workshop identified that all requirements had to be compliant with the Australian/New Zealand StandardÔ specified in AS/NZS 4360:1999. As detailed below.

However the participants were divided in opinion as to the needs of a Risk Management solution. The first being that Risk Management is a philosophy using the following methodology, and no specific "tool" is required. The second being that a "tool" is required to manage risk. This "tool" would collate information from both the Insurance and Financial systems, this information would then have various criteria applied to determine "what-if" simulations and costs related.

Management of risk is an integral part of the management process. Risk management is a multifaceted process, appropriate aspects of which are often best carried out by a multi-disciplinary team. It is an iterative process of continual improvement.

The main elements of the risk management process, as shown in figure below, are the following:

1. Establish the context

2. Identify risks

3. Analyse risks

4. Evaluate risks

5. Treat risks

6. Monitor and review

7. Communicate and consult

Risk management can be applied at many levels in an organisation. It can be applied at the strategic level and at operational levels. It may be applied to specific projects, to assist with specific decisions or to manage specific recognised areas.

Risk management is an iterative process that can contribute to organisational improvement. With each cycle, risk criteria can be strengthened to achieve progressively better levels of risk management.

For each stage of the process adequate records should be kept, sufficient to satisfy independent audit.

The Development and Environment area of Council provide and manage a wide range of services. Some common data exists across all areas and duplication should be avoided. It is essential that the central name and address system be the source of all contact details. It is also essential, that where possible duplication of data is avoided and that analysis can be performed over all service areas.

Application processing, development contributions, regulation and waste management are key sources of service based revenue for the Council and therefore the key performance measures in these areas must be carefully tracked to ensure service levels meet the users expectations. Strong workflow, scheduling and knowledge base functionality will support this objective.

The systems must be flexible to changing circumstances and be user friendly to all staff. The system must establish links for effective communication internally and externally.

The business functions that support development and environment are: