One of the requirements within this RFP is integration between the ERP and the Document Management System (DMS).
FEWA currently has an existing DMS “SAPERION” which is interfaced with the legacy ERP solution . The Bidder has the choice to offer FEWA one of the following options
Upgrade and re-interface/integrate the existing system with the proposed ERP solution
Offer new Document Management System and migrate all the existing documents into the new platform with full integration with the ERP
We are prposing the replacement of the existing DMS system by SAP DMS. We shall use the Existing DMS Content Server assuming that the same is compatible with SAP System. In case there is a Compatibility Issue, the same shall be replicated in another System.
If the bidder decides to go with option 2 as the methodology of implementing the Document Management System, then the following requirements should be fully maintained and complied TO:
Efficiency - No time lost filing & retrieving documents
Collaboration - Share documents with others among the network any time any where any media
Access - Access documents over the Intranet, Internet and/or extranet
Security - Provide controlled access to specific document based on TAG , and with access log
Savings - Reclaim space used to stored documents
Compliance - Comply with government regulations for Integrity, Availability, Security and Confidentiality
Disaster Recovery – Ability to ensure business continuity by protecting documents from natural and other disasters ( Locally and/or offsite )
Simplification - Single mechanism to manage both electronic and paper documents
Please provide a note describing the Document Management system, Clearly clarify compliance of the down below :
1.3 Document Management System Compliance Remarks
SUP MOD 3RD CST FUT NS
1.3.1 FEWA can create a single centralized repository of all their electronic &
paper documents. And ability to provide their staff with controlled access to this repository with Hierarchical Storage Management.
Yes Using
SAP core DMS System 1.3.2 The document management software provides fast, reliable and
security-controlled access to these documents throughout the company network
Yes Using
SAP core DMS System
1.3.3 Integrated Workflow which allows routing documents (based on preset Yes Using
rules), and support automatic escalation flow. SAP core
1.3.4 Easy-to-use interface. Yes Using
SAP core browser or SAP GUI or MS Explorer 1.3.5 Greatly improved the effectiveness and efficiency of the business operations Yes Using
SAP core DMS System 1.3.6 With a high security measure, the proposed solution should allow document
mark-ups (i.e notes and highlights) without altering the original document and also allows to print or email any document on the system.
Yes Using
1.3.7 Allows to locate document quickly and easily ( please explain ) Yes Using
SAP core 1.3.8 The DMS may extract metadata from the document automatically or prompt
the user to add metadata.
Yes Using
SAP core DMS System 1.3.9 The proposed solution should support Optical Character Recognition (OCR)
on scanned images.
Yes The
SAP in a Flat File.
1.3.9 Archived data migration from the current system Yes Using
SAP core DMS System utilizing SAP migration tool
1.3.10 Interfaces, Reports and Data that are supported in English/Arabic Yes Using
SAP core DMS System 1.3.11 DMS should support and integrate with the ERP and CRM/Billing to
achieve all the transactions that need archiving through OCR and OCX
Yes
1.3.12 Ability to archive Soft-documents as well as Hard-Documents Yes Using
SAP core DMS System
1.3.13 DMS should support Documents workflow. Yes Using
SAP core DMS System
1.3.14 Supporting the encryption of the URL in the browser for security wise. Yes Using
SAP core DMS System
1.3.15 Source Code Yes Using
SAP core DMS System 1.3.16 Develop a solution for Inbound/Outbound Letters and internal
announcements … etc.
Yes Using
SAP core DMS System 1.13.17 Security
1.3.17.1 Provides role-based security for individual authors Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.2 Provides role-based security for group of authors Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.3 Provides role-based security for organizational unit of groups Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.4 Provides role-based security for individual domains/sites Yes SAP
BASIS Roles &
Authorizat ion 1.3.17.5 Prevents "un-authorized viewing/access" after permanent deletion Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.6 Prevents viewing of expired content Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.7 Allows access to checked-out content from a secure location Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.8 Creates view-only format for content Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.9 Immediately revokes all access and view privileges Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.10 Restricts access based on profile Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.11 Restricts access based on document Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.12 Applies a security category to a file folder Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.13 Applies a security category to a document Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.14 Applies a security category to a user Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.15 Applies a security category to a group Yes SAP
BASIS Roles &
Authorizat ion
1.3.17.16 Provides lower or equal security level in file structure Yes SAP
BASIS Roles &
Authorizat ion
The appendix provides the key requirements from the proposed ERP and CRM/Billing application. The requirements are presented in the form of a matrix. Each Bidder is required to respond as follows
:•
Respond ‘Yes’ if the requirement is fully met, or if the question asked is fully answered. Please provide information in the Comments column to describe how your company/system meets the requirement.•
Respond ‘No’ if the requirement cannot be met. Comments should be included if there is an alternate solution. If the requirement will be met through a planned or future release, provide details in the Comments column.•
Respond ‘Partial’ if the requirement is partially met AND include details as to why in the Comments column. If a requirement contains multiple points and not all can be supplied then just a single 'Partial' indication is the appropriate response. Do not address each point, but use the Comments to provide details of which of the requirements cannot be met and why.•
Each last level requirement should be responded to as per the following fashionExample:
Sr. No. Requirement Description
Reference in Proposal
Remark
Yes Part. No
99.1 Bidder will implement full ERP System Page 26, Sec. 3 Financial Management will not be provided
1.4.1 Customer Relationship Management and Billing
Sr. No. Requirement Description Compliance Remark
SUP MOD 3RD CST FUT NS
1.0 Customer Relationship Management
1.1 System should enable setup of a single customer/person record in a single location, so this record is preserved when that person moves or wishes to purchase new services.
Yes CRM and
billing 1.2 System should support the tracking of complex customer ownerships
associated with that person or customer.
Yes CRM and
billing 1.3 System should enable the definition of user-defined fields to the person &
account records, and these user-defined fields are maintained during upgrades.
Yes CRM and
billing
1.4 System should allow multiple names (aliases) to be specified for the same
person. These names should all be available for searching. Yes CRM and
billing
1.5 System should enable multiple forms of identification to be linked to the person. E.g. Drivers license. These identifiers should be available for searching.
Yes CRM and
billing
1.6 System should enable the definition of an account that is linked to a
specific customer. Yes CRM and
billing 1.7 Account information should contain all critical data related to that account,
including contact persons, payment terms and methods. Yes CRM and
billing
1.8 Account should remain linked to the specific customer indefinitely, eliminating the need to setup a new account when the person moves or purchases new services.
Yes CRM and
billing 1.9 System should has the capabilities to add a priority tag for certain accounts
and route any related issues to specific FEWA staff for special handling.
Yes CRM and
billing 1.10 System should support the association of a single account with multiple
services.
Yes CRM and
billing
1.11 System should support hierarchical linking of services. Yes CRM and
billing
SUP MOD 3RD CST FUT NS
1.12 The system should support services consolidation for services that span
over multiple locations (e.g., add usage from several meters) Yes CRM and
billing
1.13 System should provide robust, easy-to-use capabilities for starting and
stopping customer service. Yes CRM and
billing 2.0 Customer Lifecycle Management
2.1 System should enable searches by name, address, account number, phone
number, person identifier, or any other configurable criteria. Yes CRM and
billing 2.2 When a customer is identified, all appropriate fields on the system screen
should be populated and contextual information be displayed where necessary (e.g., payment information should display on the payment screen).
Yes CRM and
billing
2.3 System should provide a contextual, user-centric portal that displays only
the account information that is most applicable to the needs of the user. Yes CRM and billing
2.4 The system should have an optional dashboard which allows the user to maintain focus of the customer & account in context, contact notes, and financial information. It should also be able to show work items.
Yes CRM and
billing
2.5 The portal should be fully configurable, allowing FEWA to configure specific portals around alerts, billing graphs, financial balances, other account details, etc.
Yes CRM and
billing 2.6 FEWA should be able to embed configured specific business processes to
be launched from any of the data displayed in the portals.
Yes CRM and
billing 2.7 System should maintain contact notes and other contact data as customer
contact records.
Yes CRM and
billing 2.8 System should provide robust integration capabilities with Contact Center
via CTI and to support IVR portal integration
Yes CRM and
billing 2.9 System should provide a “one-step” enrollment process for new customers
in a quick & efficient fashion and be able to validate the data.
Yes CRM and
billing 2.10 System should provide for the creation of “packaged” services that may
trigger a discount.
Yes CRM and
billing 3.0 Customer Billing - Bill Rating
3.1 System should provide a robust rating engine that defines the pricing for
products and services offered to the market. Yes CRM and
billing 3.2 The rating engine should be configurable without the need for
customization. Yes CRM and
billing 3.3 The rating engine should allow the definition of products that accept
charges calculated within external applications, optionally adding other calculations (e.g., VAT, taxes .. etc.) to facilitate bill consolidation.
Yes CRM and
billing
3.4 System should support complex regulated & unregulated rate calculations
without the need to modify the base system. Yes CRM and
billing 3.5 System should permit rates to have multiple components that produce the
actual charges on bills. Yes CRM and
billing 3.6 System should support plug-ins or other non-customized functionality that
support more complex rate calculations. Yes CRM and
billing 3.7 System should support short and long billing rates, as well as rate changes
during a period. (without any further development) Yes CRM and
billing
SUP MOD 3RD CST FUT NS
3.8 System can define multiple rules use to modify consumption values
before applying the rate. Yes CRM and
billing 3.9 System should also support consumption estimates where advanced
metering is not used. Please explain the methodology that the system does support.
Yes CRM and
billing
3.10 The system should enable the following specification of prices: CRM and
billing
3.10.1 Directly on the rate Yes CRM and
billing
3.10.2 Via a bill factor that can be referenced on multiple rates Yes CRM and
billing
3.10.3 As the result of another rate component Yes CRM and
billing
3.10.4 As the result of a set of configurable rules Yes CRM and
billing
3.10.5 As entered into the system via an interface to an external system Yes CRM and
billing 3.11 The system should allow the definition of “bill factors” that contain
frequently used amounts, and can be setup to define flat fees, per-unit fees, and percentage rates.
Yes CRM and
billing 3.12 The values of bill factors must be date effective to enable simple changes
over time.
Yes CRM and
billing 3.13 Proration should be supported when the bill factor value changes during
the billing period.
Yes CRM and
billing 3.14 The system should enable “what if” analysis to test the results of applying
a particular rate in various scenarios.
Yes CRM and
billing 3.15 The system should handle sophisticated cross-product discounting
scenarios.
Yes CRM and
billing 4.0 Customer Billing ( should support all the following )
4.1 Internally rated charges (rated by the system’s rating engine). Yes CRM and
billing
4.2 Externally rated charges (passed through from another system). Yes CRM and
billing
4.3 Complex billing charges (e.g. half-hourly electricity charges). Yes CRM and
billing
4.4 Advance billing with service provisioning Yes CRM and
billing
4.5 Billing of metered services Yes CRM and
billing
4.6 Billing of non-metered services Yes CRM and
billing 4.7 Fees, such as flat rate (for example, a connection charge). System should
also allow for the calculation of fees as a percentage of another charge (for instance, a late fee on an overdue balance).
Yes CRM and
billing
4.8 System should provide the following standard billing capabilities: Yes CRM and
billing
4.8.1 Automatic handling of meter exchanges Yes CRM and
billing
4.8.2 Proration of long or short bill periods Yes CRM and
billing
4.8.3 First and last bills Yes CRM and
billing
4.8.4 Optional estimation of meter reads when actual data is not available Yes CRM and
billing
SUP MOD 3RD CST FUT NS
4.8.5 Automatic normalization of consumption information for rate calculation for bills when billing period is longer/shorter than user-specified range
Yes CRM and
billing
4.8.6 Calculation and addition of taxes Yes CRM and
billing
4.8.7 Discounts Yes CRM and
billing
4.8.8 Margins Yes CRM and
billing
4.8.9 Customization of bill due dates Yes CRM and
billing
4.8.10 Definition of exact due dates Yes CRM and
billing
4.8.11 Overrides on due dates Yes CRM and
billing 4.9 System should generate a summary bill that can be associated with many
additional services.
Yes CRM and
billing 4.10 System should provide bill printing & rendering of online bill image
functionality.
Yes CRM and
billing 4.11 System should support cancel/re-bill functionality, to permit recalculation
of charges once source data is corrected.
Yes CRM and
billing
4.12 System should support online, real-time corrections of individual bills. Yes CRM and
billing 4.13 System should support automatic re-billing when earlier meter-read
estimates fall above or below pre-defined thresholds.
Yes CRM and
billing 4.14 System should support the specification of a date range during which bills
may be produced, which enables FEWA to immediately begin bill production as meter reads come in.
Yes CRM and
billing 4.15 System can automatically create statements that consolidate information
across multiple accounts and/or multiple billing periods.
Yes CRM and
billing 4.16 System should provide billable charge templates and other tools to support
one-off and 3rd party charges that fall outside normal business operations.
Yes CRM and
billing 4.17 System can bill customers a standard budget amount each period, based on
previous usage trends, customer history, or other factors.
Yes CRM and
billing 4.18 System should support convergent billing, i.e., the consolidation of billing
information created by other systems in a single bill to the customer.
Yes CRM and
billing 4.19 System can add permanent or one-time messages to bills, including meter
reading remarks and ad hoc CSR comments.
Yes CRM and
billing 5.0 Customer Billing - Multi Party Billing
5.1 System should maintain contract agreement information for services providers, including the following service provider types:
CRM and billing 5.1.1 Energy (energy supply companies, energy service providers, retailers, and
suppliers)
Yes CRM and
billing
5.1.2 Meter service (meter service providers and meter agents) Yes CRM and
billing 5.1.3 Meter reading (meter data management agencies & meter reading service
providers)
Yes CRM and
billing
5.1.4 Billing (billing agents) Yes CRM and
billing
5.2 System should maintain the following relationship types: Yes CRM and
SUP MOD 3RD CST FUT NS
billing
5.2.1 Billing relationships Yes CRM and
billing
5.2.2 Consumption relationships Yes CRM and
billing
5.2.3 Receivable (payment) relationships Yes CRM and
billing 5.3 System should support various types of billing calculations and
presentation, including the following:
Yes CRM and
billing 5.3.1 Rate-ready, when another service provider’s rates are loaded into the
system
Yes CRM and
billing 5.3.2 Bill-ready, when another service provider’s calculated charges are loaded
into the system
Yes CRM and
billing
5.3.3 Billing on behalf of a service provider Yes CRM and
billing 5.3.4 Consolidated service provider billing of charges. In this instance, charges
are interfaced to another service provider, which the system views as the customer.
Yes CRM and
billing 5.3.5 Split billing, where multiple providers were each of them has their own
billing charges
Yes CRM and
billing 5.4 Proposed solution should comply with local market transaction standards
in a deregulated market (e.g., system switches service providers as customers direct).
Yes CRM and
billing
5.5 Bidder should support updates to the market transaction functionality as
new market standards and rules are published by the governing bodies. Yes CRM and
billing
5.6 The system should support in flight messages when standards change. Yes CRM and
billing 5.7 The system should be able to display market transactions which are
directly linked to the relevant customer records and be able to see the automated processing and provide support for manual intervention when necessary.
Yes CRM and
billing
5.8 The system should be able to either integrate with a transaction hub or parse large incoming message files into individual transactions.
Yes CRM and
billing 5.9 List deregulated energy markets where the software has been
implemented.
Yes CRM and
billing 6.0 Receivables Management - Payment Processing
6.1 System can manage payments from many sources, including mailed-in or
walk-in payments, remittance processors, lock boxes, etc. Yes CRM and
billing
6.2 System should support batch processing of payments (i.e. through staging tables) to permit the creation of payments in the system from different source.
Yes CRM and
billing 6.3 For payment distribution, system should support either “balance forward”
(in which payments are applied to the oldest debt first) or “open item”
distribution (in which payments are applied to specific bills, charges, service agreements, or a combination of these).
Yes CRM and
billing
6.4 System should support automatic payments, including Electronic Funds Transfers (EFT), direct debits, and credit card payments.
Yes CRM and
billing 6.5 System should support payment alternatives (pay plans, etc.) under
automatic payment provisions.
Yes CRM and
billing 6.6 System should support prepayment in advance of service &be able to
calculate amount of allowable consumption. Yes CRM and
billing
SUP MOD 3RD CST FUT NS
6.7 System should support integration with prepaid metering devices. Yes CRM and
billing
6.8 System should support following cashiering functions: CRM and
billing
6.8.1 Adding and viewing payments online Yes CRM and
billing
6.8.2 Scanning bill stubs Yes CRM and
billing
6.8.3 Endorsing checks Yes CRM and
billing
6.8.4 Printing receipts Yes CRM and
billing
6.8.5 Managing and balancing individual cash drawers in a payment center Yes CRM and
billing
6.8.6 Single/multiple check(s) for multiple accounts Yes CRM and
billing
6.8.7 Popup messages alerting operators to excess cash in a drawer Yes CRM and
billing 6.8.8 Online, real-time transfer or payments between accounts (to facilitate error
correction) Yes CRM and
billing 6.9 System can halt ongoing collection activity if payment is received for a
delinquent account. Yes CRM and
billing 6.10 System should support online cancellation of payments and levying of
billing 6.10 System should support online cancellation of payments and levying of