(a) web viewca-09 workflow must be easily linked to the ... op1.2.1 vendor contract approval...

________________________________________________________________

The Electric Reliability Council of Texas, Inc. (ERCOT)Contract Administration and Procurement

Request for ProposalFor

Contract Lifecycle Management_4-13_JKR

Date of Release: April 5, 2013

1

________________________________________________________________

1 GENERAL INFORMATION 4

1.1 RFP Objective 4

1.2 ERCOT Background 4

1.3 Strategic Elements 4

1.4 Basic Philosophy: Contracting for Results 5

1.5 Legal and Regulatory Constraints 5

1.6 ERCOT Point of Contact 6

1.7 Procurement Timeline 6

1.8 Communications Regarding This Procurement 6

1.9 RFP Cancellation/Non-Award 7

1.10 Right to Reject Proposals 7

2 SCOPE AND REQUIREMENTS 8

2.1 Project Scope Overview 8

2.2 General Requirements 9

2.3 Scope and Functional Requirements 9

3 GENERAL INSTRUCTIONS AND RESPONSE REQUIREMENTS 22

3.1 Notice of Intent to Propose 22

3.2 Vendor Questions and Comments 22

3.3 Modification or Withdrawal of Proposal 22

3.4 News Releases 23

3.5 Incomplete Proposals 23

3.6 ERCOT Use of Vendor Ideas 23

3.7 Additional Information 23

3.8 Instructions for Submitting Proposals 23

3.9 Format and Content 24

3.10 Multiple Responses 27

3.11 Joint Proposals 27

4 Evaluation 29

4.1 Evaluation of Proposals 29

4.2 Evaluation Criteria 29

4.3 Oral Presentations and Site Visits 29

4.4 Discussions with Respondents 29

5 Attachments 30

5.1 Attachment A- ERCOT Standard Agreement 30

5.2 Attachment B – Non-Disclosure Agreement 30

5.3 Attachment C- Vendor Information Form and W-9 Form 30

2

________________________________________________________________5.4 Attachment D – Vendor Contract Approval Operating Procedure, OP 1.2.1. 30

5.5 Delegation of Authority 31

5.6 Attachment E - Naming Convention and File Structure 31

5.7 Attachment F – OP 6.2.1 Records Management Operating Procedure 32

5.8 Attachment G Sample Contract Administration e-mails 32

5.8.1 Vendor Qualification e-mail 32

5.8.2 Insurance expiration 33

5.8.3 SOW Expiration 33

5.9 Attachment H – Vendor Tiers and OP 2.1.1 34

5.10 Attachment I – Vendor Scorecard Sample 35

5.11 Attachment J – Sample Contract Administration e-mails 39

5.12 Attachment K - Sample Reports 40

5.13 Attachment L - Sample Data Entry Fields and Screenshots 49

3

Section 1 – General Information

________________________________________________________________

1 GENERAL INFORMATION

1.1 RFP Objective The objective of ERCOT in this procurement is to identify and contract with a qualified vendor to employ

a Contract Life-Cycle Management (CLM) solution, replacing multiple applications and tools currently in

use. The objective is to streamline and improve the contract development and management process, aid

compliance tracking, and improve overall contract administration efficiency.

1.2 ERCOT Background

1.2.1 Overview of the Electric Reliability Council of Texas, Inc.

The Electric Reliability Council of Texas (ERCOT) manages the flow of electric power to approximately

23 million Texas customers –representing 85 percent of the state’s electric load and 75 percent of the

Texas land area. As the Independent System Operator for the region, ERCOT schedules power on an

electric grid that connects 40,500 miles of transmission lines and more than 550 generation units.

ERCOT also manages financial settlement for the competitive wholesale bulk-power market and

administers customer switching for 6.6 million premises in competitive choice areas. ERCOT is a

membership-based 501(c)(4) nonprofit corporation, governed by a board of directors and subject to

oversight by the Public Utility Commission of Texas and the Texas Legislature. Additional information

about ERCOT can be found on its website at: http://www.ercot.com/ .

1.3 Strategic Elements

1.3.1 Contract Term

ERCOT intends to award a contract resulting from this solicitation for an initial term from date of award

through September 2013 or as necessary to fulfill the goals of this RFP.

Any contract issued as a result of this solicitation is subject to cancellation, without penalty, either in

whole or in part, for breach of contract. Such contract may also be canceled by ERCOT for convenience

upon a thirty (30) day written notice.

4

http://www.ercot.com/


________________________________________________________________

1.3.2 Contract Elements

The term “contract” means the contract awarded as a result of this RFP and all exhibits attached hereto.

At a minimum, the following documents will be incorporated into the contract: this RFP and all

attachments and exhibits; any modifications, addendum or amendments issued in conjunction with this

RFP; and the successful Respondent’s proposal. Respondent, if selected, must execute ERCOT’s

Master Agreement, attached hereto as Attachment A., The actual work to be performed and the

compensation for such work will be documented in a Statement of Work. If the Respondent already has

a Master Agreement with ERCOT, only a new Statement of Work will be required.

1.4 Basic Philosophy: Contracting for ResultsERCOT’S fundamental commitment is to contract for value and successful results. A successful result is

defined as the generation of defined, measurable, and beneficial outcomes that support ERCOT’s

Missions, Objectives, and Goals, and satisfies all defined contract requirements.

1.5 Legal and Regulatory Constraints

1.5.1 Conflicts of Interest

ERCOT seeks to ensure a level playing field in the award of the contract. ERCOT has implemented an

aggressive policy concerning actual or potential conflicts of interest to ensure fair and open competition,

and has included language concerning actual and potential conflicts of interest in Section 8 of the Master

Agreement (Attachment A). Respondents must carefully review and understand this language when

developing proposals.

1.5.2 Former Employees of ERCOT

The Respondent must disclose any past employment of its employees and agents, or its subcontractors’

employees and agents, by ERCOT, including the individual’s name and the date such individual’s

employment at ERCOT ended.

1.5.3 Interpretive Conventions

Whenever the terms “shall,” “must,” “or “is required” are used in this RFP in conjunction with a

specification or performance requirement, the specification or requirement is mandatory on the potential

vendor. ERCOT may, at its sole discretion, reject any proposal that fails to address or meet any

mandatory requirement set forth herein/.

5


________________________________________________________________

Whenever the terms “can,” “may,” or “should” are used in this RFP in conjunction with a specification or

performance requirement, the specification or performance requirement is a desirable, but not

mandatory, requirement.

1.6 ERCOT Point of ContactThe sole point of contact for inquiries concerning this RFP is:

Jana Richardson, CTPM, CPP, MBA

2705 West Lake Drive

Taylor, Texas 76574

(512) 248-4226

Fax: (512) 248-3118

[email protected]

All communications relating to this RFP must be directed to ERCOT contact person named above. All

other communications between a respondent and ERCOT staff concerning this RFP are prohibited. In

no instance is a respondent to discuss cost information contained in a proposal with the ERCOT point of

contact or any other staff prior to proposal evaluation. Failure to comply with this section may result in

ERCOT’s disqualification of the proposal.

1.7 Procurement Timeline

Procurement Timeline

RFP Release Date 4/5/2013

Notice of Intend to Propose Due 4/10/2013

Vendor Questions Due 4/15/2013

Response to Vendor Questions Posted 4/17/2013

Vendor Proposals Due 4/24/2013

Vendor Presentations TBD, around 5/1/13

Anticipated Contract Award 5/13/2013

Anticipated Contract Start Date 5/23/2013

1.8 Communications Regarding This ProcurementERCOT reserves the right to amend this RFP at any time prior to the proposal submission deadline. Any

changes, amendments, or clarifications will be made in the form of responses to vendor questions,

6


________________________________________________________________

amendments, or addendum issued by ERCOT and sent to the point of contact listed on the notice of

intent to propose. Vendors not submitting the Notice of Intent to Propose will not receive changes,

amendments or answers to questions regarding this Request For Proposal.

1.9 RFP Cancellation/Non-AwardERCOT reserves the right to cancel this RFP, or to make no award of a contract pursuant to this RFP.

1.10 Right to Reject Proposals ERCOT may, in its discretion, reject any and all proposals, submitted in response to this RFP.

1.11 No Reimbursement for Costs of ProposalsERCOT will not reimburse any respondent for costs of developing a proposal in response to this RFP.

7

Section 3 – General Instructions and Response Requirements

________________________________________________________________

2 SCOPE AND REQUIREMENTS

2.1 Project Scope Overview The primary functions of the Contract Administration and Procurement Department as they relate to this

project are: (1) supplier qualification and management, (2) contract drafting and execution, (3) contract

administration and archival (4) contract compliance and supplier performance management. Each of

these functions is currently supported by different tools and there is no integration or synergy between

the various tools and databases necessary to support these business needs.

ERCOT currently manages approximately 500 active vendors. On average, ERCOT processes 275

contracts per year (new contracts and amendments). The current contract management repository

houses over 18,000 contract related documents. ERCOT issues approximately 750 purchase orders per

year using Lawson the ERP system. Replacing the ERP system is out of scope for this project.

ERCOT’s Delegation of Authority Corporate Standard allows its Management staff to approve and

execute contracts based on monetary value as noted below:

Matrix of Signature Authority

Position Classification Signature Authority Limit

ERCOT Board of Directors >$1,000,000

Chief Executive Officer and President or Chief Operating Officer

and Senior Vice President=<$1,000,000

Vice President =<$500,000

Director =<$100,000

Manager =<$50,000

ERCOT anticipates the following number of users:

Core users – 12 Contract Approvers – 75 Administrators – 4 Viewers – 100

8


________________________________________________________________

ERCOT intends to implement a Contract Life Cycle Management system for the purpose of improving

necessary functionality, visibility, reporting, and corporate compliance necessary for efficient use of

resources and mitigating the risks associated with errors and non-compliance.

2.2 General Requirements2.2.1 Respondents must include a high level project schedule for completing each set of deliverables, key

milestones, or scope requirement described herein.

2.2.2 The awarded supplier must provide a Project Manager or lead who has decision-making authority and

will assume responsibility for coordination, control, and performance of this effort.

2.2.3 Any changes to key personnel associated with the subsequent contract must be submitted in writing

and approved in writing by ERCOT or the respective ISO/RTO prior to the change being made.

2.2.4 The awarded supplier must provide an organizational chart and list of the supplier’s corporate chain-

of-command, as well as any established procedures for contacting individuals within that chain-of-

command.

2.2.5 Respondents must describe their test plan or test methodology that authorizes ERCOT to test all

system functionality and grant its approval prior to final implementation of the CLM system.

2.2.6 Respondents must describe their implementation methodology and approach, including how existing

contracting data is imported into the CLM solution.

2.2.7 Respondents presenting a SaaS solution must identify and include their SLAs.

2.2.8 Respondents must include any relevant license agreements with their proposal response.

2.2.9 Respondents presenting a SaaS solution must identify the types of audits performed on their system

and the frequency (I.E. SAS70, SAE16, etc.). ERCOT may request such audits as necessary to

evaluation proposals.

2.2.10 Respondents must provide a standard software license agreement.

2.3 Scope and Functional Requirements 2.3.1 Supplier Management Process

The Supplier Management process assures uniformity of the ERCOT vendor qualification function. The

vendor qualification function is to ensure that ERCOT does business with reputable, qualified, and

financially stable vendors that are commercially and financially consistent with ERCOT’s corporate

policies and corporate standards and that do not have prohibited conflicts with ERCOT. The Supplier

Management process is managed using an excel spreadsheet. Functional requirements shall include:

Supplier Management Functional Requirements Functional Description of Functional Requirement

9


________________________________________________________________

Requirement #SM-01 The system must have the ability to capture, track, and store specific supplier

information. This includes but is not limited to: Supplier Legal Name and DBA if applicable Supplier Tax ID # Supplier Point of Contact Supplier Point of Contact email and phone number Supplier qualification date Supplier qualification term Supplier Qualification amount (the amount should be able to trigger

certain workflow approval requirements) Supplier Commodity Information Certification of Insurance requirements, compliance, and relevant dates Supplier Corporate Address Supplier Remittance Address Supplier Certificate of Good Standing

SM-03 The ability to identify suppliers as “currently active,” “not active,” and “active and engaged (master agreement vs. SOW)” (status fields).

SM-04 The system must have the ability to capture updates to status of actions, dates, and notes.

SM-05 The system must allow supplier self-service through a web-based portal for automatic population of supplier related data and documents.

SM-06 Data fields that are required and currently entered by the Contract Administrator are highlighted in the screenshots in Attachment L – Section 5.13 Vendor Contract Management (VCM) Tool. ERCOT currently uses a custom in-house developed tool referred to as the VCM to manage contracts and related information such as contract dates, statements of work (sow), amendments (amd), contractors, etc. The highlights in the attached screenshots demonstrate the information entered and managed by the Contract Administrator.

SM-07 Ability for solicited vendors to enter their information into the system. Vendors currently submit this information by submitting a Vendor Information Form (VIF) and W-9. See Section 5.3 Attachment C- Vendor Information Form and W-9 Form.

SM-08 Vendor access and privileges should be provided by the Contract Administrator to limit access to valid vendors.

2.3.2 Contract Drafting Process

The Contract Drafting process is the process of identifying a business unit’s need in terms of scope,

specification, milestones, deliverables, commercial terms, as well as ERCOT legal terms and conditions.

The process is generally a collaborative effort between Legal, Procurement, and an ERCOT Business

User. The process is governed by the Vendor Contract Approval Operating Procedure, OP 1.2.1. (see

Section 5.4) and is currently a manual process with the exception of Contract Request Form which is

SharePoint form with workflow and automated email notifications. Functional requirements include the

following:

10


________________________________________________________________

Contract Drafting Functional Requirements Functional Requirement #

Description of Functional Requirement

CD-01 The application must have the ability to capture, track, and archive ERCOT specific contract templates. This includes but is not limited to:

Professional Services Agreement Vendor Services Agreement Statement of Work

The contract templates support management of standard contract terms and conditions. The system should allow the master versions of all contract templates to be changed and refined by the ERCOT Legal department.

CD-02 The system must include functionality that allows users to capture, track, and store a library of acceptable provision changes to the contract templates.

CD-03 Administrative views and access control. The system must provide the ability to define the view (of data and functions) seen by users with different roles. By controlling the visible tab sets, the system administrator can turn on or off areas of data and functionality based on user role.

Functionality must include data fields that can be added or existing fields that can be edited in order to provide different field labels and buttons modifiable to our preferred description.

CD-04 Administrative view must allow for flexible configuration by an administrator, providing a simplified view for read-only users while giving direct and intuitive access to all system data and functions for regular users.

CD-05 Template library. System must allow for an unlimited number of contract templates to be captured and stored for use in the creation of multiple contract types. These templates need only be created once. They will be selected during the contract creation process to bring forward all of the language that has been vetted through the organization as well as a series of attributes that will help define the contract. Attributes include, but are not necessarily limited to, expiry and/or renewal notification periods, style sheets (the look and feel of the printed version of the contract), numbering schemas, and compliance items.

CD-06 Clause library. The system must support the ability to create individual clauses or sections in a library and associate them with a specific contract template. The clause or group of related clauses may be used in different circumstances across multiple contracting situations.

CD-07 Rule-based alternative clauses. Contract template functionality must include the ability to define rules in which certain clauses or clause groupings can be automatically selected or deselected in a contract, based on the unique attributes of the contract. Examples of rules sets include the following:

Time-based Alternatives: Clauses can be defined to appear in a contract based on the length or duration of the contract. In instances where the duration (e.g. number of months or years) requires specific provisions or wording, this type of alternative will bring forward the appropriate language.

Monetary Value Alternatives: Clauses can be defined to appear in a contract based on the monetary value of the contract. For example, you

11


________________________________________________________________

Contract Drafting Functional Requirements Functional Requirement #


may need to have different insurance clauses appear in the contract when the contract value exceeds a certain level.

User Defined Fields (UDF) based Alternatives: With the ability to define and attach custom fields to different contract types, users can configure certain clauses to appear in a contract when certain values are present. For example, this could be used where a risk level is identified for a contract and certain variations of a clause need to be included.

Optional Alternatives: In situations where alternative wording cannot be based on a defined element, the contract author can select the most appropriate option from a list of clauses.

CD-08 New fields and contract types. This function must allow the administrator to create new entities such as new contract types and UDF and configure them to suit our business needs.

CD-09 Version control. As templates evolve or change over time, the system must effectively manage these changes. The system must have the ability to create a new version of the template to ensure that all users are using the latest copy. When an approved update is made to an existing template, the system should automatically ‘obsolete’ the prior version so that any future contract created will use the latest version.

Within a specific contract, the history of each change must be retained for each user and viewable to show changes made.

CD-10 Template access. System must allow templates be created (by an administrator or Legal) and assigned to a specific segment or business unit within an organization. This allows for only those users authorized in that segment or business unit to use that template.

2.3.3 Contract Approval Process

The Contract Approval process is the process of obtaining contract approval in accordance with the

ERCOT Delegation of Authority Corporate Standard. This includes internal contract approval and

execution of a contract. In the event an approving manager is not available, the contract approval

process defines how such manager can delegate his/her authority to a peer. The Vendor Contract

Approval Operation Procedure, OP 1.2.1. (Section 5.4) provides additional guidance. This process is

currently managed using SharePoint, as well as manual process. Functional requirements shall include:

Contract Approval Functional Requirements Functional Requirement #


CA-01 The system must include a contract pre-approval workflow routing process that identifies certain contractual data elements for internal management approval. The data elements include but are not limited to:

12


________________________________________________________________

Anticipated Start Date Anticipated End Date Summary of Contract Need Type of Contract (T&M, Fixed Fee, etc.) Amendment or New Agreement Value of Contract Aggregate value of Contract (if amended)

CA-02 The system must include an automated workflow Contract approval and pre-approval process that is consistent with ERCOT’s delegation of authority process. See Section 5.5 Delegation of Authority.

CA-03 The automated workflow must be associated with specific ERCOT business units, and have the capability to route within the appropriate business unit’s chain of command.

CA-04 The system must allow for users to delegate their authority (via proxy) to users who possess the same delegated authority within their respective business unit.

CA-05 The system must include a controlled approval override process that is associated with Procurement Manager or Director.

CA-06 The system must maintain an audit trail for all transactions and approvals. Suppliers must define their audit trail capabilities.

CA-07 System must identify compliance items. These can be items like a checklist of items that must be completed before the contract can be effective. (i.e. ERCOT BoD approval, corporate competitive requirements, etc.).

CA-08 Dynamic workflow for contract creation and approval. Allow for workflow functionality that can be based on amounts, rule conditions, services, products, organization, department, commodities, programs, customers or customer types, vendors or vendor types, as well as other tracked information.

CA-09 Workflow must be easily linked to the organizational hierarchy from a role or a financial accountability perspective; or multiple approval levels.

2.3.4 Contract Management and Retention Process ERCOT currently uses OpenText LiveLink to store and manage contracts and related documentation.

Once the contracts are fully executed, the Contract Administrator uploads the documentation to Livelink

using the file structure defined in Section 5.6 Attachment E - Naming Convention and File Structure. The

primary users of LiveLink are Contract Administration, Procurement and Legal. Some groups use

Livelink for read-only purposes such as Audit, Facilities and Finance. Functional requirements shall

include:

Contract Management and Retention Functional Requirements Functional Requirement #


CM-01 Contract repository must be able to support different types of contracts (Internal Standard Templates and external supplier templates) and file types (.pdf, .doc, .ppt, .xls, etc.).

CM-02 Organization of contract database. Functionality must all allow contracts to be organized and security granted based on the organization hierarchy. Users can be

13


________________________________________________________________



granted access to a single org unit or multiple. In addition they can be granted access to a single org unit and all its children. Administrator must be allowed to grant access of a single instance of a contract to one or more org units. Within each contract, attachments (documents, emails) can be organized into a standard folder structure defined for each contract type or contract specific folders can be added.

CM-03 The system must allow for ERCOT’s contract naming convention relative to contract file names and folder structure. (Suppliers will be required to identify their capabilities). See Section 5.6 for ERCOT’s contract naming convention.

CM-04 Hierarchical relationships between contracts. System must allow for the creation and organization of hierarchical relationships between parent contracts, sub-contracts, amendments, and changes. The contract relationships must be shown in a tree format for visual identification. This functionality must offer users an interface to see relationships within contracts and provides a clear relationship snapshot.

CM-05 Advanced text searching. System must allow for text searches, enabling a user to search for a word or phrase in a specific group of contracts and/or templates. Must include a global search feature that enables searches to be performed across multiple objects in the application, documents attached to a contract, and key terms. Key terms must also display corresponding objects such as legal entity records, contracts and any other objects related to the search term.

CM-06 The tool must be able to support any number of meta data fields.CM-07 The metadata fields should have support for dropdowns, text fields, default values,

etc. (ie. SOW #, Supplier Name, Amd #, Purchase Order, etc.).CM-08 The contract repository must support upload of supporting documents (Email

exchanges, etc.) along with the main contract document.CM-09 Alerts, Tasks, and Events. The system must include alert, task, and event

management, enabling a tracking and notification of a data elements and activities and allow user definition of the following major elements, including but not limited to:

Time-based events such as contracts approaching renewal and/or expiration.

Compliance based alerts (insurance certificates, etc.) Recurring performance metrics (quarterly scorecard, etc.) User defined alerts (rebates, discount periods) Milestones and Deliverables Custom configured alerts

In addition, the task and event alerts in the system must allow the contract manager to monitor the ongoing performance of the contract to ensure terms, conditions, and/or deliverables are met according to original expectations.

CM-10 Must allow the creation of user defined or administrator defined preferences for notifications. Options include:

Immediate notifications as events occur. Summary notifications on a scheduled basis (e.g. every 2 hours, daily,

weekly).

14


________________________________________________________________



Different schedules for different event types (e.g. immediate notification of a required approval, daily summary of documents to review).

CM-11 System must include contract renewal management. This includes systematic advance notification of an expected renewal, ensuring both that a vendor and customer processes are taken into consideration before the expiry date. Functions include but are not limited to:

During contract creation, users or administrator can define the ‘lead days’ necessary to process renewals to ensure notifications are sent to stakeholders to alert them of a pending renewal.

Renewals generate a new contract but retain all of the historical information from the originating contract.

Contract details from the originating contract are rolled over into the new contract and allow the user to make changes if required, or leave them as they are.

CM-12 System must include contract amendment management. Amendments to the contract must be tracked and approved through the appropriate stakeholders (consistent with ERCOT’s Delegation of Authority Corporate Standard):

When an amendment is necessary, users or the administrator can create a draft Amendment and have it approved by utilizing the existing workflow that is attached to the contract. The approval process ensures all necessary stakeholders (internal) are notified and are involved in any change made to the contract once it has been issued.

The system must create an amendment document that shows only the items that have been added, changed or deleted from the last version of the contract. This document should be used to obtain approvals and capture necessary signatures.

Amendments must be tracked through the approval process to record the individuals involved and the associated dates of their involvement. This process must be transparent to all relevant users.

CM-13 Compliance monitoring functionality. The system must allow for establishing compliance Items for monitoring specific aspects of a contract:

Requirements (such as requiring the vendor to validate it has renewed its annual insurance) can be flagged as a Compliance Item. Once identified on the contract, a notification is sent to the contract administrator that documentation must be received by the vendor at certain points in time during the life of the contract.

Compliance items can take many forms. These can be items like a checklist of items that must be completed before the contract can be effective.

Compliance items can be used as approval conditions that must be met prior to the contract being approved and issued.

Functionality for compliance items includes reporting across the organization or for a particular subset of contracts in the organization.

CM-14 Contract merging functionality. The system must provide a function to merge two defined entities together. This is used to merge the data assigned to two separate entities into a single entity. This function is primarily used to combat the proliferation of redundant company entries in the vendor directory. This can also

15


________________________________________________________________



be used to handle mergers and acquisitions of Suppliers.CM-15 Contract milestone and deliverable tracking. The system must include functionality

and data elements that define a series of contract Milestones or Deliverables. Capture Milestone descriptions, due dates and actual completion dates. Record payment amounts and the percentage of the overall contract

amount. Track percentage completion, actual completion date, and indicate

whether partial payments may be made. Alerts to notify when a Milestone due date is reached. Create workflows to manage the update of Milestone information. Create reports to show status of Milestones across multiple contracts. Alerts to notify when a Deliverable due date is reached. Capture any Deliverable acceptance criteria that must be approved prior

to any payment being made. Create reports to show status of Deliverables across multiple contracts.

CM-16 System must include functionality that will allow administrator to logically partition contract information by business/organization unit. System must allow administrator to define the different departments/user groups - that should only be able to see contracts that are relevant to their departments.

CM-17 Ability for internal contract drafter or administrator to systematically send the contract for review to internal team members based on the changes suggested by the other party (supplier).

CM-18 ERCOT currently houses all contracts and related documentation in OpenText Livelink. Support for the tool will no longer exist after the new CLM tool is in place. The existing documents must be moved to another repository or deleted if eligible for destruction. The CLM repository would be preferable, but if that is not possible, then the documents could be moved to SharePoint. Due to the high volume of information, an import tool needs to be considered.

CM-19 Contracts and related documents are considered records and as such must be maintained according to ERCOT’s Records and Information Management Corporate Standard, Operating Procedures and Records Retention Schedule.

CM-20 The system should provide the ability to quickly assess which records are eligible for destruction and dispose of them in an efficient manner consistent with Section 5.7 Attachment F – OP 6.2.1 Records Management Operating. Master agreements should always be kept if there is an active SOW associated with it.

CM-21 Some software licenses are evergreen and should be preserved for the life of software. The system should allow users to flag agreements as evergreen.

2.3.5 Contract Reporting ProcessERCOT currently uses reports for day to day business as well as reporting for compliance purposes. It is

expected that the new system will provide standard canned reports as well as the ability to run ad-hoc

reports as needed. Reports should allow the user to enter parameters based on meta data and other

16


________________________________________________________________

criteria. For example, the contractor administrator should be able to run a report of all active agreements

between given dates. Functional requirements shall include:

Contract Reporting Functional Requirements Functional Requirement #


CR-01 All reporting functionality must be available via the Internet (in pure HTML format) for those users with customer defined security access. This should provide access to report data outside corporate offices if necessary.

CR-02 Suppliers must identify all pre-defined reports that are delivered as part of the implementation. Suppliers must describe all reporting functionality and how users can define and filter their search requirements according to their level of security.

CR-03 Contract visibility monitoring and reporting. System must include the capability for numerous pre-defined reports, company specific reports, and ad hoc query capabilities to query contract data based on user-defined parameters.

CR-04 System should include Data Cubes to allow for multi-dimensional viewing and analysis of data. Data Cubes should allow users to drill-down through the data and present findings as a graph or chart.

CR-05 Ability to download all reports in a variety of formats such as CSV, PDF, Excel, HTML and RTF.

CR-06 System must allow for ad hoc reporting, allowing the administrator or users to create dynamic reports on the fly from standard data elements in the system and include them in a query that can be printed.

CR-07 Standard Reports:

- Contractor Count - On-site Contractors - NERC/CIP Access Compliance

o 24-hour rights revocation after termination- Ethics Training and NERC/CIP Training Compliance

See section 5.8 (Attachment G Sample Contract Administration e-mails) and attachments for sample reports. Contract Administration and Legal currently run reports in VCM that have to be manually manipulated to produce the desired end result.

CR-08 The system must allow an administrator to produce contract expiration reports by various dates (90, 60, 30, 15 day, or on demand reporting) to monitor all upcoming contract expirations and the associated contract owner.

CR-09 The system must provide a systematic expiry notification to the contract owner at 90, 60, 30, and 15 days prior to expiration. Currently, Contract Administrator runs reports and sends emails to business owners.

CR-10 Administrative privileges to allow groups read-only access to reports and file/data download. Groups to be granted administrative privileges are Legal and Contract Administration.

CR-11 New system should import groups that are granted read-only access in the current system. Groups are Physical Security, Cyber Security, Facilities, Audit, and Compliance. This access must be limited to the user fields relevant to the appropriate group.

CR-12 Need the ability to subscribe to a report which contains information on changes made to contractor data and contract data on a weekly or monthly basis.

17


________________________________________________________________

CR-13 The system must include reporting capabilities by Supplier qualification dates and commodity information.

CR-14 Ability to create ad-hoc reports.CR-15 Ability to receive emails from CLM on daily status changes for SOWs and contracts.CR-16 Ability to flag upcoming Personnel Risk Assessments (PSAs) expirations

2.3.6 Contract Performance and Monitoring Process ERCOT’s Vendor Management Office (VMO) manages and coordinates performance management

activities for vendors classified as Tier 1, Tier 2 or Tier 3. This process involves collection of performance

scorecards from business owners and coordination and tracking of regularly scheduled performance

reviews. The contract performance and monitoring process is governed by the Vendor Qualification and

Performance Operating Procedure, OP 2.1.1 and currently managed using SharePoint. See Section 5.9

Attachment H – Vendor Tiers and OP 2.1.1for a copy of the OP and for more information on vendor tiers,

scorecard collection and performance review period frequency requirements. Functional requirements

shall include:

Contract Performance Management Functional Requirements Functional Requirement #


CPM-01 The system must provide the ability to collect performance management criteria from internal ERCOT business users either on monthly, quarterly, semi-annual or annual basis. Criteria and required frequency is shown in the scorecards sample in section 5.10 Attachment I – Vendor Scorecard Sample.

CPM-02Performance assessment scorecards are specifically created for vendors that are on the evaluation schedule. Some vendors may self-report and not require a performance scorecard.

CPM-03 Criteria will be evaluated on a numerical scale (e.g. 1-5 where 5 is the best).Evaluators must be able to supplement numerical ratings with comments. Supporting comments are required to justify a low or high score (e.g. 1, 2, 4 or 5).

CPM-04 Vendor Managers should have the ability to change the criteria as the VMO evolves.

CPM-05 Internal ERCOT business owners should be notified via email two weeks prior to the scorecards due date. Escalation and Reminders:

The business owner must be reminded one week prior to the deadline if the scorecard has not yet been submitted.

If the scorecard has not been completed by the deadline, the business owner must be reminded again and the manager must receive a copy of the notice.

If the scorecards have not been completed within three weeks, the Business User(s) are considered non-compliant with Operating Procedure 2.1.1 (See Section 5.9). The VP of the business unit and the VP of Finance and Treasury are advised of the non-compliance.

CPM-06 The system must track the following for each vendor:

18


________________________________________________________________

Vendor Name Vendor ID from Lawson (nice to have) Tier Level (Currently 1, 2, or 3) ERCOT evaluator(s) ERCOT evaluator role (IT manager, Business owner, Project manager,

other) Performance ratings by period (individually and consolidated)

CPM-07 The system must be able to track the following for each performance review:

Internal preparatory meeting o Meeting dates o Attendee listo Materials (e.g. ppt presentations, action items in word or excel,

financial analysis spreadsheets) Performance Review meeting

o Meeting dates o Attendee listo Materials (e.g. ppt presentations, action items in word or excel,

financial analysis spreadsheets)o Location (ERCOT or Vendor location)

CPM-08 Vendor Managers must have the ability to monitor when scorecard notifications are sent and when scorecards are completed to ensure compliance with operating procedures.

CPM-09 Vendor performance reviews may be postponed in the case where extensive communications or Contract negotiations are occurring over a period of time of one month or more. The system must be able to track these exceptions.

CPM-10 Vendors whose performance is deemed unsatisfactory are subject to feedback and corrective action. The system must be able to track correction action.

CPM-11 The system should be able to interface with Lawson to calculate the aggregate spend for the contract and spend by vendor. (Nice to have)

2.3.7 Contractor Onboarding and Offboarding

ERCOT has unique requirements related to contractor personnel and the CLM must be able to track

specific contractor personnel data when such contractor requires access to ERCOT facilities and and/or

data. ERCOT must comply with NERC CIP Personnel Risk Assessment requirements. Additional detail

can be found at the following URL:http://www.nerc.com/files/CIP-004-4.pdf

Functional requirements shall include:

Contractor Onboarding and Offboarding Functional Requirements Functional Requirement #


CO-01 The system must have the ability to store specific contractor information to be used by ERCOT’s Identify and Access Management tool referred to as IdM. This includes but is not limited to (data elements from VCM to IdM; needed from new system):

19

url:http://www.nerc.com/files/CIP-004-4.pdf


________________________________________________________________

Contractor Id First Name Last Name Vendor Id Vendor Name Last Authorize Date (date of last authorization event) Last Revoke Date (date of last revocation event) Last Suspend Date (date of last suspension event) Activation After Revocation (y/n) Engagement Start Date Engagement End Date Supervisor Employee Id (from ADP) Department Name Department Number Converted to FTE date Checksum Personnel Risk Assessment (date) Drug Screen (date) NERC CIP Training (date) Consultant Ethics Agreement (date) Contractor Status

Note: The contractor status that IdM needs would indicate that the contractor is eligible for IT systems access. If this status is made available, IdM does not need the following date fields.

Last Authorize Date (date of last authorization event)Last Revoke Date (date of last revocation event)Last Suspend Date (date of last suspension event)Engagement Start Date

CO-02 The contractor data must be made available to ERCOT to read and interface the data for use by IdM.

CO-03 The system must have the ability to allow for the on-screen selection of ERCOT specific information stored in ADP. The fields that would be interfaced from ADP to the new system includes but is not limited to:

1. Supervisor ListSupervisor Employee IDSupervisor First NameSupervisor Preferred NameSupervisor Last NameSupervisor Department

2. DepartmentDepartment NumberDepartment Name

CO-04 Checklist of NERC/CIP Onboarding requirement (Security/Legal)CO-05 Checklist of drug screening pass

Checklist of background screen passStatus options for contractor’s access authorization include:

Authorized

20


________________________________________________________________

Suspended Reinstated Revoked

CO-06 All scheduled jobs that pull data from various systems should be monitored to ensure data is current. If jobs fail to run, a system administrator should be notified in order to correct the job failure.

21


________________________________________________________________

3 GENERAL INSTRUCTIONS AND RESPONSE REQUIREMENTS

3.1 Notice of Intent to ProposeA prospective vendor may submit a Notice of Intent to Propose to the ERCOT Point of Contact identified

in Section 1.6 no later than 5:00PM Central Time on the date listed in Section 1.7 Procurement Timeline. The Notice of Intent should be delivered via email. Only vendors who submit a Notice of Intent

to Propose will receive the answers to questions from all vendors, and / or any clarifications,

amendments, and addenda to the Request For Proposal. Vendors who provide a notice of intent are not

required to submit proposals.

3.2 Vendor Questions and CommentsAll questions and comments regarding this RFP must be submitted electronically to the e-mail address

contained in Section 1.6 (ERCOT Point of Contact). All questions must reference the appropriate RFP

page and section number. In order to receive a response, vendor questions and comments must be

received no later than the deadline set forth in Section 1.7 (Procurement Timeline). Inquiries received

after the due date may be reviewed by ERCOT but will not receive a response. Answers to vendor

questions will be e-mailed to the point of contact listed on the Notice of Intent to Propose.

A respondent must inquire in writing as to any ambiguity, conflict, discrepancy, exclusionary

specification, omission or other error in this RFP prior to submitting a proposal. If a respondent fails to

notify ERCOT of any error, ambiguity, conflict, discrepancy, exclusionary specification or omission, the

respondent shall submit a proposal at its own risk and, if awarded the contract, shall have waived any

claim that the RFP and Master Agreement were ambiguous and shall not contest ERCOT’s

interpretation. If no error or ambiguity is reported by the deadline for submitting written questions, the

respondent shall not be entitled to additional compensation, relief or time by reason of the error or its

later correction.

ERCOT reserves the right to amend answers prior to the proposal submission deadline.

3.3 Modification or Withdrawal of ProposalProposals may be withdrawn from consideration at any time prior to the award of contract. A written

request for withdrawal must be made to the ERCOT Point of Contact (Section 1.6).

22


________________________________________________________________

A respondent has the right to amend its proposal at any time and to any degree by written amendment

delivered to the ERCOT Point of Contact prior to the proposal submission deadline. ERCOT reserves

the right to request an amendment to any part of the proposal during negotiations.

3.4 News ReleasesA respondent may not issue press releases or provide any information for public consumption regarding

its participation in this procurement without specific, prior written approval of ERCOT.

3.5 Incomplete ProposalsERCOT may reject without further consideration any proposal that is not completely responsive to this

RFP.

3.6 ERCOT Use of Vendor Ideas ERCOT reserves the right to use any and all ideas presented in any proposal that are not the

respondent’s proprietary information and so designated in the proposal. The respondent’s

proprietary materials do not include information that is already published or available to the public, or subsequently becomes available;

is received from a third party who, to ERCOT’s knowledge, is not in breach of any obligation of confidentiality; or

is independently developed by personnel or agents of ERCOT without reliance on the

respondent’s proprietary materials;

3.7 Additional InformationBy submitting a proposal, the respondent grants ERCOT the right to obtain information from any lawful

source regarding: (i) the past business history, practices, conduct and ability of a respondent to supply

goods, services and deliverables; and (ii) the past business history, practices, conduct and ability of the

respondent’s directors, officers and employees. ERCOT may take such information into consideration in

evaluating proposals.

3.8 Instructions for Submitting Proposals3.8.1 Number of Copies

Submit one (1) original copy of the proposal. The original must be signed in ink by an authorized

representative of the respondent. In addition, submit one electronic copy (soft copy) via email.

23


________________________________________________________________

3.8.2 Submission

Submit all copies of the proposal to the ERCOT Point of Contact no later than 2:00 p.m. Central Time on the submission deadline (See Section 1.6 & 1.7).

3.8.3 Additional Requirements

All proposals must be:

Clearly legible;

Sequentially page-numbered;

Organized in the sequence outlined in Section 3.9 and 3.9.1;

Bound in a notebook or cover;

Limited to 50 pages (excluding ERCOT required forms);

Responsive to the requirements of this RFP;

Proposals should include the respondent’s name at the top of each page, and should not include

unrequested materials or pamphlets.

3.9 Format and ContentThe proposal must consist of two parts:

Part 1 – Business Proposal; and

Part 2 – Cost Proposal.

3.9.1 Part 1 -- Business Proposal The Business Proposal, must include:

Section 1 – Transmittal Letter;

Section 2 – Executive Summary;

Section 3 – Corporate Background and Experience;

Section 4 – Methodology and Services Approach;

Section 5 – Assumptions;

Section 6 – Appendices;

Section 7 – Vendor Information and Other Required Forms.

Section 1 -- Transmittal LetterRespondents must include a transmittal letter printed on official company letterhead. The letter must be

signed in ink by an individual authorized to legally bind the respondent.

The transmittal letter must include: 24


________________________________________________________________

Disclosure of all pending, resolved, or completed litigation, mediation, arbitration, or other

alternate dispute resolution procedures involving the respondent (including subcontractors,) and

its client(s) within the past 24 months.

Disclosure of all affiliations with or ownership relationships with any ERCOT Market Participant or

its affiliates.

A description of any personal or business interest that may present an actual, potential or

apparent conflict of interest with the performance of the contract and an explanation of how the

respondent can assure ERCOT that these relationships will not create an actual conflict of

interest.

A list of key personnel previously employed by ERCOT in accordance with the requirements of

Section 1.5.2.

A complete list of all exceptions, reservations and limitations to the terms and conditions of the

RFP and the Master Agreement.

Section 2 -- Executive SummaryIn this section, the respondent should condense and highlight the content of the Business Proposal to

provide ERCOT with a broad understanding of the respondent’s approach to meeting ERCOT’s

objectives for this procurement.

Section 3 -- Corporate Background and Experience

Respondent Background and ExperienceThis section details the respondent’s corporate background and experience. If the respondent proposes

to use subcontractor(s), it must describe any existing on ongoing relationships with such

subcontractor(s), including project descriptions. The section should include the following information:

Respondent’s full organization, company or corporate name;

Headquarter address;

Type of ownership (e.g. partnership, corporation);

If respondent is a subsidiary or affiliate, the name of parent organization;

State where the respondent is incorporated or otherwise organized to do business;

Federal taxpayer identification;

Name and title of person who will sign the contract; and

Name and title of person responsible for responding to questions regarding the proposal, with telephone number, facsimile number and email address.

25


________________________________________________________________

Describe the respondent’s corporate background as it relates to projects similar in scope and

complexity to the project described in this RFP.

If the proposal includes the use of subcontractors, include a similar description of the subcontractor’s

corporate background.

Include at least three (3) references for projects performed within the last five (5) years that

demonstrate the respondent’s ability to perform the required RFP services. Include contract dates

and contact parties, with address, telephone number and e-mail, if available If the work was

performed as a subcontractor, the respondent, describe the scope of subcontracting activities.

Key PersonnelIdentify and describe the respondent’s proposed labor skill set and provide resumes of all proposed

Key Personnel (as defined by the respondent). Resumes must demonstrate experience germane to

the position proposed. Resumes must list any relevant professional designations for Key Personnel

identified by Respondent. Resumes should include work on projects cited under the respondent’s

corporate experience, and the specific functions performed on such projects.

Section 4 – Methodology and Services ApproachDescribe the respondent’s methodology for providing the deliverables identified in Section 2. Include

a proposed project schedule, including start and finish dates of the terminal and summary elements

identified in Section 2 or proposed by the vendor.

Section 5 -- AssumptionsState any business, economic, legal, or practical assumptions that underlie the respondent’s Business

Proposal.

Section 6 -- AppendicesInclude any appendices to the respondent’s Business Proposal.

Section 7 – Vendor Information and Other Required FormsRespondents must complete the following required forms:

Nondisclosure Statement (Attachment B)

Vendor information form (Attachment C)

26


________________________________________________________________

Except for current ERCOT suppliers who have an active Master Agreement with ERCOT or who

have completed the Vendor Information Form (VIF) within the last six months, all Respondents

must provide a completed Supplier Vendor Information Form, attached hereto as Attachment C

along with the proposal.

If the anticipated contract value with ERCOT is equal to or >$250,000.00, the respondent must

include the most recent two (2) years audited financial statements (include unaudited statements

if supplier is unaudited). Publically held companies must include or provide a link to the most

recent Forms 10-K and 10-Q filings.

3.9.2 Part 2 -- Cost Proposal The Cost Proposal must be based on the Scope of Work described in Section 2. This section should

include any business, economic, legal, or practical assumptions that underlie the Cost Proposal.

Respondents may separately identify cost-saving and cost-avoidance methods and measures and the

effect of such methods and measures on the Cost Proposal and Scope of Work.

Respondents must utilize the Cost Proposal in the attached spreadsheet listed below for submitting your

Cost Proposal.

However, respondents may propose optional cost proposals if such proposals are more cost effective

(IE. Time and Materials cost structure, etc.) for ERCOT.

3.10 Multiple ResponsesA respondent may submit more than one proposal, including a joint proposal with one or more

respondents.

3.11 Joint ProposalsTwo or more companies may join together and submit a joint proposal in response to this RFP. A joint

proposal must completely define the responsibilities each company proposes to undertake. Also, the

joint proposal must designate a primary respondent who will be responsible for the delivery of all goods,

services and requirements as specified in the RFP, and a single authorized official from the primary

respondent to serve as the sole point of contact between ERCOT and the joint proposers. Any contract

27


________________________________________________________________

resulting from a joint proposal must be signed by an authorized agent or officer of each company. Each

company included in the submission of a joint proposal will be jointly and severally liable during the term

of the contract.

28

Section 4 – Evaluation

________________________________________________________________

4 Evaluation

4.1 Evaluation of ProposalsERCOT will select the successful vendor through an internal evaluation process. ERCOT will consider

capabilities or advantages that are clearly described in the proposal, which may be confirmed by oral

presentations, site visits or demonstrations if required, and verified by information from reference sources

contacted by ERCOT. ERCOT reserves the right to contact individuals, entities, or organizations that

have had dealings with the respondent or staff proposed for this effort, whether or not identified in the

proposal.

4.2 Evaluation CriteriaThe primary criteria for evaluating the proposals as they relate to this RFP are as follows:

1. The vendor’s ability to meet the requirements set forth in Section 2.

2. The vendor’s fees or cost structure.

4.3 Oral Presentations and Site VisitsERCOT may, at its sole discretion, request oral presentations, site visits, and/or demonstrations from one

or more respondents. ERCOT will notify selected respondents of the time and location for these

activities, and may supply agendas or topics for discussion. ERCOT reserves the right to ask additional

questions during oral presentations, site visits, and/or demonstrations to clarify the scope and content of

the written proposal, oral presentation, site visit, or demonstration.

4.4 Discussions with RespondentsERCOT may, but is not required to, conduct discussions and negotiations with all, some, or none of the

respondents for the purpose of obtaining the best value for ERCOT.

29

Section 5 – Attachments

________________________________________________________________

5 Attachments

5.1 Attachment A- ERCOT Standard Agreement

ERCOT Master Agreement

Professional Service Agreement

5.2 Attachment B – Non-Disclosure Agreement

Non-disclosure Agreement

5.3 Attachment C- Vendor Information Form and W-9 Form

New Vendor Information and W-9 form

5.4 Attachment D – Vendor Contract Approval Operating Procedure, OP 1.2.1.

30


________________________________________________________________

5.5 Delegation of AuthorityDelegated Signature Authority by Position ClassificationERCOT’s Delegation of Authority establishes delegated signature authority by position classification for (1) signing Contracts, (2) authorizing purchases, (3) authorizing projects, and (4) approving disbursement of funds for goods and/or services.

Position Classification Signature Authority LimitERCOT Board of Directors >$1,000,000Chief Executive Officer and President or Chief Operating Officer and Senior Vice President

=<$1,000,000

Vice President =<$500,000Director =<$100,000Manager =<$50,000Project Manager =<$20,000

Application of delegated signature authority limits are applied to Cumulative Transactional Values.Temporary Delegation of Signature Authority The Chief Executive Officer and Chief Operating Officer may temporarily delegate their signature authority to one or more Officers. Each Vice President may temporarily delegate his signature authority to a Director who has a direct reporting relationship to him, or to another Vice President. Each Director and Manager may temporarily delegate his signature authority laterally to another Director or Manager. Project Managers may not delegate their signature authority.To ensure proper segregation of duties, employees shall not use temporary delegated signature authority to authorize transactions that they also have approved using their own, normal delegated signature authority. When the person temporarily delegates his signature authority to another person, notice of the temporary

delegation of signature authority should be e-mailed to [email protected] and to the

person to whom signature authority is being delegated, who then must confirm acceptance of the

delegation.

5.6 Attachment E - Naming Convention and File Structure

The information below represents the file structure and examples of documents currently established in Livelink for contracts and contract related information.

31


________________________________________________________________

5.7 Attachment F – OP 6.2.1 Records Management Operating Procedure

5.8 Attachment G Sample Contract Administration e-mails5.8.1 Vendor Qualification e-mail

32


________________________________________________________________

5.8.2 Insurance expiration

5.8.3 SOW Expiration

33


________________________________________________________________

5.9 Attachment H – Vendor Tiers and OP 2.1.1

Tier Level Scorecard Frequency Performance Reviews1 Monthly Quarterly2 Quarterly Semi-Annually3 Quarterly Annual

34


________________________________________________________________

5.10 Attachment I – Vendor Scorecard Sample

Tier 1 Example

35


________________________________________________________________

36


________________________________________________________________

Tier 2 & Tier 3 Example

37


________________________________________________________________

38


________________________________________________________________

5.11 Attachment J – Sample Contract Administration e-mails5.11.1 Vendor Qualification e-mail

Insurance expiration

SOW Expiration

39


________________________________________________________________

5.12 Attachment K - Sample Reports

5.12.1 Report Index

40


________________________________________________________________

5.12.2 Report Time Window Selection

41


________________________________________________________________

5.12.3 Daily Email on Contract Status Changes

42


________________________________________________________________

5.12.4 Daily Email on SOW Status Changes

43


________________________________________________________________

5.12.5 Current Engagement Reports

44


________________________________________________________________

5.12.6 Expiring Engagements Report

45


________________________________________________________________

46


________________________________________________________________

5.12.7 Expiring SOWs Report

Expiring SOWs

Vendor SOW Description Expires On ERCOT Contact Officer

5.12.8 Expiring Contracts Report

Expiring Contracts

Vendor SOW Description Expires On ERCOT Contact Officer

5.12.9 Expiring Insurance Report

Vendor Contact First

Contact Last

Email Insurance Expire Date

Insurance Description

Insurance Type

Comments

sent email requesting info received info from vendor or not needed

47


________________________________________________________________

5.13 Attachment L - Sample Data Entry Fields and Screenshots

5.13.1 Contractor Engagement

48


________________________________________________________________

49


________________________________________________________________

50


________________________________________________________________

5.13.2 Insurance Info

51


________________________________________________________________

5.13.3 Master Contracts Edits Info

5.13.4 Master Contracts Info

52


________________________________________________________________

53


________________________________________________________________

5.13.5 SOW Info

54


________________________________________________________________

5.13.6 Vendor Info

55


________________________________________________________________

5.13.7 Contractor Info

56


________________________________________________________________

5.13.8 SOW Extensions

57


________________________________________________________________

5.13.9 Engagement Edit

58


________________________________________________________________

5.13.10 New SOW

59


________________________________________________________________

60


________________________________________________________________

5.13.11 SOWS Edit

61


________________________________________________________________

62

(a) web viewca-09 workflow must be easily linked to the ... op1.2.1 vendor contract approval...

Documents