REQUIRED SUBMISSION FORMS.doc.doc

VENDOR RESPONSE DOCUMENT

for

ICN RFP 08-130

Operations Support System / Business Support System

(OSS/BSS)

Brian ClaytonIowa Communications NetworkGrimes State Office Building400 East 14th StreetDes Moines, IA 50319Telephone 515-725-4616FAX 515-725-4774

[email protected]

Vendors must comply with all affirmative action/equal employment opportunity provisions of State and Federal laws.

1 REQUIRED SUBMISSION FORMS

BID PROPOSAL SUBMITTAL FORM

RFP 08-130Vendor providing a bid proposal must complete each section of this Response and submit as part of its bid proposal. Vendor may bid any or all services. Issuance of a Contract does not guarantee any minimum usage requirements to the successful Vendor but is being awarded as a convenience to the State for potential future needs.

Vendor Name:

(including all d/b/a or assumed names or other operating names of the Vendor)

Address:

Phone: Fax:

Local office address (if different from above):

Address:

Phone: Fax:

Accounting firm:

Form of business entity, i.e., corporation, partnership, proprietorship, limited liability company:

State of incorporation (if a corporation) or state of formation: (if a limited liability company or a limited partnership)

Number of employees:

If awarded a Contract, Vendor will be required to register to do business in Iowa. If already registered, provide the date of the Vendor’s registration to do business in Iowa:

Name(s) and qualifications of any subcontractors who may be involved:

Person to Contact Regarding This Bid Proposal:

Address:

Phone: Fax: E-Mail:

2

BID PROPOSAL COMPLIANCE FORM

RFP 08-130

Vendor affirms that the information contained in the bid proposal is true and accurately portrays all aspects of the goods or services or both contemplated by this RFP. The Vendor is aware that any substantive misinformation or misrepresentation may disqualify the bid proposal from further consideration.

Vendor hereby certifies total compliance with all other terms, conditions and specifications of this RFP except as expressly stated below:

Chapter 1, Administrative Issues

Chapter 2, Contractual Terms & Conditions (includes Attachment 1)

Chapter 3, Technical Specifications

Chapter 4, Evaluation Criteria

I certify that I have the authority to bind the Vendor indicated below to the specific terms and conditions imposed in this RFP and offered in this bid proposal, and that by my signature on this document I specifically agree to all of the waivers, restrictions and requirements of this RFP as conditions precedent to submitting this proposal. I further state that in making this bid proposal that the Vendor has not consulted with others for the purpose of restricting competition or violating State or Federal anti-trust laws and has not knowingly made any false statements in this proposal.

Authorized Signature:

Printed Name:

Title:

Telephone:

Fax Number:

E-Mail:

Business Name:

Address:

Federal ID Number:

3

AUTHORIZATION TO RELEASE INFORMATION

RFP 08-130

(Name of Vendor) hereby authorizes any person or entity, public or private, having any information concerning the Vendor’s background, including but not limited to its performance history regarding its prior rendering of services similar to those detailed in this RFP, to release such information to the State.

The Vendor acknowledges that it may not agree with the information and opinions given by such person or entity in response to a reference request. The Vendor acknowledges that the information and opinions given by such person or entity may hurt its chances to receive contract awards from the State or may otherwise hurt its reputation or operations. The Vendor is willing to take that risk. The Vendor agrees to release all persons, entities, and the State of Iowa from any liability whatsoever that may be incurred in releasing this information or using this information.

Printed Name of Vendor Organization

Signature of Authorized Representative Date

4

MANDATORY REQUIREMENTS CHECKLIST

To have its bid proposal evaluated, Vendor must acknowledge that it can and will comply with each of the “MUST” (mandatory) requirements listed below, if awarded a Contract. To fulfill this requirement, Vendors providing bid proposals will respond using this ICN-provided response template, in addition to any vendor-specific proposal documents. Additional consideration will be given to vendors who also indicate compliance with the “SHOULD” (value-added) requirements in later sections.

ID Requirement TextRequirement Met

(Y/N)

CUST.010 The system MUST store the following information about each Customer:1. Customer Name should be agency name with sub name or descriptor name.2. Status (predefined list: Active/Inactive/etc.)3. Description / Notes

CUST.020 The system MUST allow ICN to identify parent and child relationships between Customer records allowing for more than 2 levels of hierarchy/relationships between the customers.

CUST.030 The system MUST allow ICN to identify an ICN-defined set of attributes for Customer records, including but not limited to:

1. Class (predefined drop down list, e.g. State Agency, Education, etc.)2. Category (predefined drop down list, e.g. College, Judicial, Executive, etc.)3. Federal, County, Local indicator4. Billing Account (format is 12 alpha-numeric with 3 digit subaccount, e.g. ABC000000001-001)

CUST.040 The system MUST record the following information after a Customer record is added, updated or removed:

1. User ID2. Date/time3. Action (add, edit, delete, etc.)

CONT.010 The system MUST store the following information about each Contact:1. First Name2. Last Name3. What responsibility does contact have (billing, auth sign, etc.)?4. Status (from predefined list: Active/Inactive/etc.) 5. Work Phone Number6. Mobile Phone Number7. Fax Phone Number8. E-Mail Address

CONT.050 The system MUST allow association of one or more Contact records to one or more Customer/Vendor record(s). (from CUST.010 or VEND.010)

CONT.055 The system MUST allow association of one or more Locations to a Contact record. (from LOC.010)

CONT.056 The system MUST specify the type of association (via predefined list: mailing, billing, ship-to, etc.) between the Contact and the Location.

CONT.060 Each association between a Contact and Customer/Vendor in CONT.050, above, MUST include the following association-specific information:

1. Contact Type (Billing, Customer, Other/Explain, Location, Circuit, Support, Sales, etc.)

CONT.070 The system MUST record the following audit information after a Contact record is added, updated or removed:


LOC.010 The system MUST store the following information about each Location:1. Location Name2. CLLI Code (Telecordia standard)3. Physical Address: StreetLine1, StreetLine2, City, County, State, Zip, Zip+44. Latitude/Longitude coordinates5. Vertical/Horizontal coordinates6. Fiber entrance location(s)7. Power Feed Information (Amperage and Voltage)8. HVAC Capacity information9. Description/Notes10. Access/Entry Notes11. Lock Box Location (Site access keys)12. Type of location (from predefined list, e.g. vendor, Part 1, Part 3, Node, link splice location, etc)13. Phone Number (NPA-NXX-XXXX)14. LATA (Local Access and Transport Area)15. Status (Active, Inactive, etc.)

5


(Y/N)

LOC.011 The system MUST allow definition of multiple suite numbers (e.g. multiple deliverable addresses) within a location (CLLI).

LOC.030 The system MUST allow occasional load and/or update LERG data including:Location Name

1. CLLI Code (Telcordia standard)2. Physical Address: StreetLine1, StreetLine2, City, State, Zip, Zip+43. Latitude/Longitude coordinates4. Vertical/Horizontal coordinates5. Description/Notes6. Type of location (from predefined list, (vendor, Part 1, etc)7. LATA (Local Access and Transport Area)8. Phone Number (NPA-NXX-XXXX)

LOC.040 Vendor MUST describe the method(s) to load LERG data referenced in LOC.030.

LOC.050 The system MUST allow ICN to associate zero or more Location records to a given Customer or Vendor.

LOC.060 The system MUST allow ICN to associate one or more Customers/Vendors to a given Location.

LOC.070 The system MUST allow ICN to classify each Location that is associated to a Customer, including at least the following categories:

1. Primary2. Alternate3. Bill-to4. Ship-to5. Equipment-only6. Emergency Contact

LOC.080 The system MUST record the following information for a Location record upon each addition, update or removal:

1. User ID2. Date/time3. Action (add, edit, delete, etc.)4. Order Number5. Previous field/value (if applicable)6. New field/value (if applicable)

EQUIP.005 The system MUST generate a Unique ICN ID for each Equipment/Asset instance.

EQUIP.010 The system MUST store the following information about each Equipment Chassis:1. Part Number(s)2. Associate with CLLI (Location) See LOC.0103. Manufacturer 4. Model5. Slot and Port Counts6. Type of Power Required7. Power Input/Output Required8. Relay Rack assignments (rack within a line up)9. Relay Rack Position assignments (within a rack)10. Serial Number11. Management IP Address / netmask12. Unique ICN ID (from EQUIP.005)13. State ID/Tag14. Install Date15. Related Purchase Order Number (PRO.015)16. Owner17. Administrator18. Work Order/Request History (See REQ.010)19. Category (i.e. Grouping of Equip - Switch, Transport, etc.)20. Subcategory (i.e. Ethernet Switch, ATM Switch, etc. for the selected Category)21. Status (Inactive, active, defective, etc.) (Drop-down List)22. Date Last Inspected (See MISC.020)23. Description/Notes24. Common name (alias)25. Maintenance Contract(s) (CONTR.010)26. End of life date27. End of Support date28. GAAP depreciation timeframe for the asset29. ICN/Vendor recommended timeframe for disposal of the asset30. General ledger code for the expense31. Specify if Capital asset32. Effective date of transfer33. If it was identified as being billable to the customer in the original order34. Effective date of status35. Acquisition price

6


(Y/N)

EQUIP.020 The system MUST associate the Equipment/Asset to a CLEI code.

EQUIP.040 The system MUST store the following information about each Equipment Card:1. Card Type2. Part Number(s)3. Associated Equipment CLEI4. Manufacturer 5. Model6. Slot assignment7. Port Density (# of ports)8. Power Input/Output Required9. Dimensions10. Serial Number11. Unique ICN ID12. State ID/Tag13. Install Date14. Acquisition Date15. Owner16. Status (Inactive, active/installed, defective, etc.) (Drop-down List)17. Description18. GAAP depreciation timeframe for the asset19. ICN/Vendor recommended timeframe for disposal of the asset20. General ledger code for the expense21. Specify if Capital asset22. Effective date of transfer23. If it was identified as being billable to the customer in the original order24. Effective date of status25. Acquisition price

EQUIP.050 The system MUST associate Equipment Cards with Equipment Chassis in Slot assignments.

EQUIP.060 The system MUST store the following information about each Equipment Port:1. Port Type2. Associated Equipment CLEI3. Make4. Model5. Brand6. Vendor7. Card Assigned8. Port Speed9. IP Address10. Status (Inactive, active, defective, etc.) (Drop-down List)11. Assigned circuit (See CIR.010)12. Description/Notes13. Ethernet MAC Address

EQUIP.062 The system MUST store the following information about each Logical Equipment Port:1. Speed2. DLCI3. VLAN ID4. VLAN Name5. Tagging6. VPI7. VCI8. IP Address9. Time Slot10. Status (Inactive, active, defective, etc.) (Drop-down List)11. Assigned circuit (See CIR.010)12. Description/Notes

7


(Y/N)

EQUIP.065 The system MUST store the following information about each Relay Rack:1. Rack Dimensions (drop down list)2. Install Date3. Maximum weight allowed4. Number of mounting positions (rack units)5. Manufacturer6. Part Number(s)7. Rack Name8. Unique ICN ID9. Status (Inactive, active, defective, etc.) (Drop-down List)10. GAAP depreciation timeframe for the asset11. ICN/Vendor recommended timeframe for disposal of the asset12. General ledger code for the expense13. Specify if Capital asset14. Effective date of transfer15. If it was identified as being billable to the customer in the original order16. Effective date of status17. Acquisition price

EQUIP.080 The system MUST allow reservation of the following items for future assignment, and track the user, Project/Order, and date of reservation. This will remove the items from auto-provisioning (e.g. to reserve ports during project planning of currently unknown circuits):

1. Rack Assignments2. Rack Units3. Chassis slots4. Cards5. Ports6. Other Equipment/Assets

EQUIP.090 The system MUST record the following historical audit information after any Equipment/Asset record is added, updated or removed:

1. User ID2. Date/time3. Action (add, edit, delete, etc.)4. Order Number (the Request which caused the record to be added, updated, or removed)

EQUIP.100 The system MUST provide the ability to easily duplicate existing Equipment, Power Equipment, Card, and Port records. The resulting records MUST be editable.

EQUIP.105 The system MUST allow a templated list of required and optional fields for each piece of Equipment/Asset. The fields shown MUST be variable based on Equipment type.

8


(Y/N)

EQUIP.110 The system MUST store the following information about Power Equipment:1. Associate with CLLI (Location)2. Manufacturer3. Model4. Vendor Slot Count5. Vendor Port Count6. Type of Power Required (AC, DC)7. Power Input/Output Required (Voltage, Amp Draw)8. BTU/hr9. Dimensions10. Weight11. Relay Rack assignments12. Relay Rack Position assignments13. Serial Number14. Unique ICN ID15. State ID/Tag16. Install Date17. Acquisition Date18. Related Purchase Order Number19. Category20. Subcategory21. Owner22. Alarm History 23. Inspection date24. Impedance (Batteries)25. Voltage Readings (Batteries)26. Conditions (e.g. for Batteries: Good, Cracked, Fair, etc.)27. Hours (Generator)28. Status (Inactive, active, defective, etc.) (Drop-down List)29. Description/Notes30. GAAP depreciation timeframe for the asset31. ICN/Vendor recommended timeframe for disposal of the asset32. General ledger code for the expense33. Specify if Capital asset34. Effective date of transfer35. If it was identified as being billable to the customer in the original order36. Effective date of status37. Acquisition price

EQUIP.116 The system MUST store the following information about each Other Equipment/Asset:1. Location Name (from LOC.010)2. GAAP depreciation timeframe for the asset3. ICN/Vendor recommended timeframe for disposal of the asset4. ICN Part number/serial number5. State IP Tag number6. Acquisition date7. General ledger code for the expense8. Specify if Capital asset9. Owner10. Specify if Asset is transferred to Vendor/customer warehouse11. Effective date of transfer12. Corresponding Order(s)13. If it was identified as being billable to the customer in the original order14. Status (from list - pending, active, pending disposal, disposed)15. Effective date of status16. Description/Notes17. Acquisition price

EQUIP.120 The system MUST allow ICN to relate Equipment/Assets to Contracts. (CONTR.010)

EQUIP.130 The system MUST allow for the tracking of configuration information of the Equipment/Asset.

EQUIP.140 The system MUST allow ICN to relate Equipment/Assets to other equipment and define the relationship type. (Parent, Child, License, etc.)

CAB.020 The system MUST have a notepad for each cable bundle that documents any activity, and includes a date/time/person stamp for each entry.

9


(Y/N)

CAB.030 The system MUST be able to store the following information about each cable bundle: 1. Loc A CLLI ( the CLLI should be selectable from a list pulled from LOC.010) 2. Loc Z CLLI ( the CLLI should be selectable from a list pulled from LOC.010) 3. Style of cable (SM, MM, coax, utp, stp etc.) 4. Type of cable (cat 3, cat 5, RG-6, core diameter etc.) 5. Length of cable (in km and or feet) 6. Number of pairs (or number of strands) 7. Cable name 8. Cable description (direct bury, aerial, duct required, etc.) 9. Ownership Type (owned, leased, abandoned, etc.) 10. Plenum rating (plenum, non-plenum) 11. Administrator (ICN, ITE, City, etc.) 12. Splice point detail (Link Splice) - there may be zero or more of these 13. Cross reference (Vendor to Cable) - there may be zero or more of these 14. Color

CAB.035 The system MUST be able to store the following information about each individual cable in a cable bundle

1. Bundle to which the cable belongs 2. Type of connector 3. Length of cable 4. Plenum rating (plenum, non-plenum) 5. Type of cable (category rating; ie CAT V, CAT VI, Fiber) 6. Color 7. Owner 8. Status (Active, Reserved, Assigned, bad, etc.) 9. Splice point detail (Link Splice/Cross Connect Block, etc.) - there may be zero or more of

these 10. Notes - Date/Time/User Stamp permanent comments 11. Related Termination Detail (FDP, Jack Position Number, Connector Type, etc.), if connected

CAB.040 The system MUST be able to perform the following functions on each cable: 1. Assign or remove ports to each cable for future assignment (assigning a circuit to the port or

the cable should bring both elements into the circuit design) 2. Assign or remove ports to each cable individually (from equipment listed in EQUIP.040 or

EQUIP.060) 3. Assign or remove ports to the cable bundle as a whole

CAB.045 The system MUST be able to handle division of a single cable bundle into two or more bundles and modify existing endpoints as appropriate (e.g., adding a splice point to insert a new location)

CAB.050 The system MUST record the following information after a Cable record is added, updated or removed: 1. User ID 2. Date/time 3. Action (add, edit, delete, etc.)

VEN.010 The system MUST store the following information about each Vendor: 1. Vendor Name 2. Time Zone 3. Status (Active/Inactive/Other?) 4. Vendor Tax ID 5. Microsoft Dynamics SL Vendor ID 6. Billing Account(s) 7. Vendor terms (net 30, etc.) 8. Category (i.e. company, division, department)

VEN.020 The system MUST allow ICN to identify parent and child relationships between Vendor records allowing for more than 2 levels of hierarchy/relationships between the vendors.

VEN.030 The system MUST allow ICN to associate an ICN Part number to a Vendor-specific Part number for each Vendor that provides the part.

VEN.040 The system MUST allow ICN to associate Vendors with multiple Contacts (see CONT.050).

VEN.050 The system MUST allow ICN to associate multiple Contracts to a Vendor (see CONTR.016.)

VEN.060 The system MUST allow ICN to combine and split Vendor records (e.g., mergers, acquisitions, spin-offs).

VEN.070 The system MUST record the following information after a Vendor record is added, updated or removed: 1. User ID 2. Date/time 3. Action (add, edit, delete, etc.)

SVC.010 The system MUST identify all Services, to include internal requests and all variations of service provided to the customer base.

10


(Y/N)

SVC.020 The system MUST be able to store and access the following Service information: 1. Service Name 2. Service Description 3. Service Category 4. Service Subcategory (allows for hierarchial) 5. Current status (e.g. Active (In Service Catalog), discontinued, being developed etc.) 6. Service Type: Business Service (visible to the customer) or Infrastructure Service (invisible to

the customer, used as a building block for Business Services) 7. Internal / external: Internally provided service or a service sourced from an external service

supplier (Service provider field) 8. Service Owner (Group(s) responsible for service provisioning) 9. Contacts and procedures for signing up to the service 10. Infrastructure Services on which this service depends (Supporting Services) 11. Services that depend on this service (Supported Services) 12. Components (Dependant Configuration Items and Services) (Parent CIs and Services which

this service references) 13. Description/Notes - Date/TIme/User Stamp with comments, all become permanent.

SVC.050 The system MUST record the following information after a Service record is added, updated or removed: 1. User ID 2. Date/time 3. Action (add, edit, delete, etc.)

CIR.010 The system MUST store the following information about each Circuit Header: 1. Order Number (request that initiates the Circuit or any change to the Circuit from REQ.010) 2. "A" Location Name 3. "A" CLLI 4. "A" CLEI (predefined from drop down list based on "A" CLLI or new) 5. "Z" Location Name 6. "Z" CLLI 7. "Z" CLEI (predefined from drop down list based on "Z" CLLI or new) 8. Circuit type 9. Service Category / Subcategory (See SVC.010) 10. Physical hand-off/termination requested (e.g. RJ-45, SM, MM, BNC, ST, LC, SC, FC, etc.) 11. Line Coding (e.g. B8ZS/AMI/ESF, etc.) 12. Duplex Settings (Half, Full) 13. Requested Bandwidth (Peak, Burst, Sustained) 14. Unique Circuit ID (system assigned and/or managed) 15. Associated Circuit ID aliases (i.e. LEC circuit ID) 16. Associated Customer(s)/Billing Account 17. Associated Vendor(s) (from VEND.010) 18. Associated BAN(s) (billing account number(s)) 19. Customer/Vendor associated contract number (from CONT.010) 20. Description/Notes 21. Circuit version number

CIR.015 The system MUST allow for an on-going record of notes for each circuit. Any comments added would be permanent, with a date and person stamp.

CIR.017 The system MUST allow relating of the circuit to to equipment(s) (from EQUIP.010)

CIR.020 The system MUST allow for presentation of the circuit design: tying different circuits together to show as a link so that you can query, report, export for the items that make up a connection in its entirety from A to Z. (See DES.010)

CIR.030 The system MUST allow ICN to associate zero or more Contact records to a given Circuit.

CIR.040 The system MUST record the following information after a Circuit record is added, updated or removed: 1. User ID 2. Date/time 3. Action (add, edit, delete, etc.) 4. Previous field/value (if applicable) 5. New field/value (if applicable)

11


(Y/N)

REQ.010 The system MUST store the following information about each Order/Request: 1. Customer Name 2. Authorized signatory 3. Billing Account information for install and monthly if different - field REQUIRED before moving

order on through workflow for completion. 4. All Services (SVC.010) and corresponding Locations (LOC.010) associated with each order

item. 5. Install Contact Name, phone number and email address 6. Description 7. Notes (with date/time stamp and user id for each entry) 8. Date customer would like work completed 9. If sooner than ICN standard intervals is an expedite fee applicable? 10. Does contracting need to be involved? 11. Breakdown of how estimate is calculated for billing. 12. Breakdown of the monthly/one time for each circuit 13. Priority setting so tasks due on the same day can be prioritized. 14. Documentation of what service was agreed upon.

REQ.020 The system MUST allow a Request to be generated which allows workflow to add tasks for a new CLLI or CLEI code to be generated for an "A" or "Z" location.

REQ.030 The system MUST allow ICN to associate zero or more Request records to a given Customer.

REQ.031 The system MUST allow ICN to associate multiple Orders by multiple Customers within a parent Order (Project) at any point in the Order's life cycle prior to completion.

REQ.033 The system MUST allow ICN to add a jeopardy status to orders. (Jeopardy status allows ICN personnel to convey obstacles to completing orders timely - e.g. LEC delayed, Customer site access delay, etc.)

REQ.034 The system MUST allow existing service records (phones, circuits, etc.) to be added to an Order for MACD activity.

REQ.035 The system MUST allow for attachments of documents to Orders with initial request and throughout the workflow & task items completed.

REQ.036 The system MUST be capable of providing customized templates for Order entry and workflow, based on any of the following:

1. Service Ordered 2. Workflow Step 3. Person/role/group involved

REQ.037 The system MUST be able to create one or more AFEs based on and related to a specific Order.

REQ.040 The system MUST allow ICN to identify items, tasks, etc. as billable to the customer at a defined markup percentage (i.e. technician time, materials used, items ordered or in stock, trip charge, etc.)

REQ.050 The system MUST allow ICN to define the type of each Request that is associated to a Customer, such as:

1. Install 2. Change 3. Move 4. Disconnect 5. Estimate

REQ.055 The system MUST allow Orders to reference other Orders

REQ.058 The system MUST allow ICN to associate multiple items to an Order, with different values for the following:

1. Customer 2. Service(s) 3. Location 4. Completion Date

CONTR.010 The system MUST store the following information about each Contract: 1. Vendor/Customer contract number 2. ICN contract number 3. Vendor/Customer name (from VEND.010/CUST.010) 4. Vendor/Customer contact information (address, phone, email, etc.) (from CONT.010) 5. Type (modifiable drop down list - maintenance, service, circuit, equipment, etc) 6. Contract dates - start/expire/renewal/early termination 7. Renewal notes (number of renewals and renewal time frames) 8. Associated costs for the period (may be multiple and variable periods) 9. Associated General Ledger code(s) and subaccount(s) (for, e.g., maintenance costs). 10. Equipment/Circuit/Items associated with this contract (from EQUIP.010 and CIR.010) 11. Description 12. Notes (date/time/user for each entry) 13. Associated Customer(s) whose services depend on the (Vendor) Contract (from CUST.010) 14. ICN Staff associated to Contract

12


(Y/N)

CONTR.011 The system MUST allow for equipment, circuits or other items to be associated with multiple contracts.

CONTR.012 The system MUST allow for 2 or more hierarchical levels in order to tie addendums/amendments to the original contract.

CONTR.015 The system MUST allow for association of multiple Contacts to each Contract. (from CONT.010)

CONTR.016 The system MUST allow for association of multiple Contracts to each Vendor/Customer. (from VEND.010 / CUST.010)

CONTR.020 The system MUST provide reporting on expiring contracts with a variable timeframe allowed in the report parameters.

CONTR.030 The system MUST allow ICN to attach multiple documents to each Contract record (allow for marking attachments as confidential for limited viewing or release).

CONTR.040 The system MUST allow for SLA/Warranty information on each Contract, including the following: 1. Termination Liability 2. Portability 3. Time to repair, e.g., returned parts, etc. 4. Outage credits and how to calculate 5. Identify Specific service provided 6. Service vendor (if maintenance is provided by a third party) 7. Vendor help desk & customer support 8. Escalation procedures & response times

Note: This information may be sizable.

CONTR.050 The system MUST record the following information after a Contract record is added, updated or removed:

1. User ID 2. Date/time 3. Action (add, edit, delete, review, etc.)

AFE.010 The system MUST store the following data for an Authorization for Expenditure (AFE): 1. AFE # 2. Revision # 3. Indicate budgeted/unbudgeted 4. Sponsoring division 5. Funding source (A = Appropriation funded AFE, C = Capital Equipment Plan AFE, NC = Non

Capital Equipment Plan AFE, R = Revenue producing AFE, etc.) 6. Total approved 7. 10% or $5000 overage amount (whichever is less) 8. Year(s) savings or expenses for the project (i.e. year 0, 1, 2, 3, etc.) 9. Total of Revenue breakdown (i.e. pass-through, recurring, cost savings, etc.) 10. Total of Expense breakdown (i.e. capital costs, other costs, outside labor, internal labor,

recurring, etc.) 11. Indicate if there are inventory items to be used, or transfers from other sites 12. Net Gain/Loss for project 13. Purpose memo field 14. Background memo field 15. Alternative memo field 16. Financial memo field 17. Project risks memo field

AFE.020 The system MUST be able create an AFE (authorization for expenditures) if the Sales Order/Purchase Order amounts are above a specified limit (currently $5000).

AFE.030 The system MUST be able to associate an AFE to one or more of each of the following order types: 1. Sales Order 2. Purchase Order 3. Customer Request / Project 4. Network Order (build-out)

AFE.040 The system MUST allow for multiple (archive) versions of an AFE to be kept and viewed. Only the most recent version of an AFE will be considered active for editing, workflow and approval purposes.

AFE.050 The Revenue breakdown detail MUST include the items to be used for billing (from BILB.040).

AFE.060 The Expense breakdown detail MUST include the equipment (from EQUIP.010) or inventory items (INV.010) that will be used for the project whether purchased or from inventory.

AFE.070 The Expense breakdown detail MUST be able to be categorized and calculate totals into the following categories but not limited to:

1. Fixed Asset purchase detail by vendor/product 2. Fixed Asset product installation analysis 3. Additions or subtractions from vendor maintenance contracts 4. Existing warehouse inventory resources required 5. Existing network fixed asset resources required

13


(Y/N)

AFE.080 The Expense breakdown detail MUST include up to the following but not limited to: 1. Product 2. Part # 3. Quoted price 4. List price 5. ICN price 6. Quantity 7. Applicable markup % (from order detail) 8. Continuing expenses for the specified equipment (i.e. maintenance in year 0, 1, 2, 3, etc.)

AFE.090 The Revenue breakdown detail MUST be able to be categorized and calculate totals into the following categories but not limited to:

1. Initial pass through revenue from customer 2. New service offered to customer detail 3. Cost savings from project

AFE.100 The Revenue breakdown detail MUST include up to the following but not limited to: 1. Service offered to customer 2. Customer of record 3. Customer End point locations 4. Billable item 5. Quantity 6. Continuing revenues for the project (i.e. year 0, 1, 2, 3, etc.)

AFE.120 The system MUST record the following information after a AFE record is added, updated or removed: 1. User ID 2. Date/time 3. Action (add, edit, delete, etc.)

TEL.010 The system MUST store the following information for a Telephone Number record from PBX switches:1. Switch/System data loaded from 2. Status (Spare, in-use or disconnected) 3. Phone types or Device combination 4. Station number 5. Pad/Pen address 6. IP Address if VoIP Phone 7. MAC Address if VoIP Phone 8. Class of Service (local, LD, international, idle, etc.) 9. Display name 10. Public Number 11. Call forwarding destination 12. 911 location information (including county-either fill in or auto-populate) 13. Cable pairs (ie House pairs - Riser Pairs)

TEL.020 The system MUST store the following information about each Telephone in Telephone number record: 1. Billing Account 2. Status (spare, disconnect, in-use)

TEL.030 The system MUST store the following information about Calling Cards in Telephone number record: 1. Card Number 2. Calling Card Type (e.g. MCI Calling card, Capitol Complex Calling card, etc.) 3. Name of Contact 4. Status (spare, disconnect, in-use)

TEL.040 The system MUST store the following information about telephony groups in Telephone number record: 1. Pick group 2. ACD group 3. ICM group 4. Hunt group

TEL.050 The system MUST allow for reporting of PBX data Generate reports based on switch

TEL.060 The system MUST allow for reporting of voice mail data in Telephone number record: 1. Call Processing data 2. Call Processing Pathname 3. Call Processing Name 4. Call Processing Type 5. Switch Call Processing data loaded from 6. Number of times Call Processing box accessed 7. Call Processing User transfers 8. Call Processing Default Transfers 9. Auto-generate email to customer with Call Processing data 10. Class of service 11. Contact 12. Voice mail number 13. Voice mail node

14


(Y/N)

TEL.070 The system MUST allow for two way provisioning between the compatible PBX switch(s) and the OSS (see BILA.103). The ICN would determine which changes are made from the OSS to the PBX, from the PBX to the OSS, and which are done by personnel.

TEL.080 The system MUST store the applicable Authorization codes for a phone number and encrypt or mask the Authorization codes so they do not print on the invoice to the customer in the Telephone number record.

TEL.090 The system MUST store the applicable Client/Access codes for a phone number in the Telephone number record.

TEL.115 The system MUST store toll free numbers and the local number (DNIS) or the trunk to which it points.

TEL.130 The system MUST record the following information for a Telephone record upon each addition, update or removal:

1. User ID 2. Date/time 3. Action (add, edit, delete, etc.) 4. Order Number 5. Previous field/value (if applicable) 6. New field/value (if applicable)

PRO.010 The system MUST store the following information for a Sales order: 1. Corresponding Order number 2. Corresponding Purchase Order number 3. Associated items to be used from inventory or purchased from vendors (from INV.010) 4. Status of each item (e.g., On Order, Reserved, Shipped, etc.) 5. ICN part numbers to the Sales Order (i.e., from EQUIP.010 for chassis) 6. Associate Corresponding vendor part number and pricing 7. Associate Location as final destination for parts (from LOC.010) 8. Asset # 9. ICN part # 10. Part serial # 11. State IP tag # 12. Vendor part # 13. If AFE process is required 14. If AFE process approval has been completed and associated AFE number 15. If original estimated items vary from what is being ordered 16. Approver 17. Shipper and shipper's tracking number (provided by ICN)

PRO.011 The system MUST allow the user to add tasks (or a group of tasks) to accommodate the AFE process.

PRO.012 The system MUST allow for notifications to individual(s) for various actions or changes to the sales order or purchase order (Hold, Rejection, Cancel, etc.)

PRO.015 The system MUST store the following information for a Purchase order: 1. Corresponding Sales Order number(s) 2. Vendor name and info (phone, fax, contact, etc) (from VEND.010) 3. Vendor tax ID (from VEND.010) 4. Corresponding contract number and terms (net 30) 5. Associated items to be used from inventory or purchased from vendors (from INV.010) 6. Associate Corresponding vendor part number and pricing 7. Specify if purchased with appropriation funds 8. Approver 9. Expected ship date/delivery date for purchase by part number 10. Shipper and shipper's tracking number (from the vendor) 11. General ledger code for expense 12. Notes - Date/Time/User Stamp permanent comments 13. Shipping FOB

PRO.017 The system MUST allow for items to have more than one part number assigned to it with one as the main part number.

PRO.020 The system MUST require a corresponding Order number before a purchase can be made.

PRO.026 The system MUST allow for ICN to reject Sales/Purchase Orders and note the reason for the rejection.

PRO.030 The system MUST allow items to be audited and marked as to whether they are accurate part numbers, in inventory, etc.

PRO.040 The system MUST allow for consolidation or separation of purchase orders based on the vendor, project, etc.

PRO.060 The system MUST allow select ICN personnel to override fields in order to correct for accuracy.

PRO.081 The system MUST allow for the PO to be printed.

15


(Y/N)

PRO.090 The system MUST allow ICN to reserve and associate an Asset to a specific project or Order and allow for a reorder if this is overridden and transferred to another project or customer order.

PRO.100 The system MUST allow for automatic reorder of minimum levels of inventory as those levels are passed. (see INV.063 and INV.110)

PRO.105 The system MUST allow for multiple shippers to be printed for shipping Assets on a Sales Order and maintain a history of items already shipped.

PRO.110 The system MUST record the following information after a Procurement record is added, updated or removed:

1. User ID 2. Date/time 3. Action (add, edit, delete, etc.)

DES.005 Vendor MUST acknowledge that Vendor understands the ICN operates a telecommunications network that includes telephones (VoIP, digital, and analog), Frame Relay, ATM, IP, Ethernet, Private Line, etc., and that circuit designs must be able to represent physical and logical connections across the various technologies.

DES.006 Vendor MUST acknowledge that Vendor understands a main consideration for providing a circuit design is to provide implementation instructions to technicians for physical deployment and logical configuration.

DES.010 The system MUST store the following information about each Circuit Design: 1. Unique Circuit ID 2. Related Order 3. Designer/Engineer 4. Description/Notes - date/time/person stamp on the permanent update

DES.020 The system MUST be able to store and display multiple versions of designs; including historical (archived) designs, current designs, and pending designs, and designate them as such for the viewer.

DES.030 The system MUST allow ICN to associate any kind of network element to the circuit: 1. Cables 2. Ports/Slots 3. Channels (logical channels within a carrier Circuit) 4. Representation of Vendor network segments (e.g. Leased circuit) 5. Relay Rack

DES.031 The system MUST represent cross-references to Vendor circuits within the circuit design.

DES.040 The system MUST allow ICN to define various settings for ports and circuits, as determined by Equipment/Port/Slot settings. These will vary by segment, and include, but not be limited to:

1. VLAN id 2. VLAN name 3. VPI 4. VCI 5. DLCI 6. tagging 7. SONET DS-0, DS-1, DS-3, etc. 8. QoS (if specified) 9. IP Address 10. Policing (UPC)

DES.045 The system MUST provide a separate field/screen for the install specifications ("Work Order Detail") and implementation notes to be entered. This is to be date/time/user stamped.

DES.060 The system MUST record the following information after a Circuit Design record is added, updated or removed:


ORD.001 The system MUST assign a unique identifier to the order for tracking.

ORD.020 The system MUST allow ICN to track Customer inquiries related to an Order (e.g., phone calls/emails about the status of the order).

ORD.030 The system MUST allow access to appropriate orders and task assignments for external personnel as defined by ICN.

ORD.031 The system MUST provide the ability to identify/flag orders that are to be expedited. (requested to be completed in less time than the standard set for the requested service)

ORD.060 The system MUST allow for a notification when an order is initiated for an item on a existing current contract.

ORD.061 The system MUST track timing of orders through workflow and allow each section to add to the order (documents, notes, additional items, etc.) and allow for notifications if defined timeframes are overdue to both the section assigned as a reminder/escalate mechanism and supervisors for reporting, etc.

16


(Y/N)

ORD.070 The system MUST record the following information after an Order record is added, updated or removed: 1. User ID 2. Date/time 3. Action (add, edit, delete, etc.) 4. Previous field/value (if applicable) 5. New field/value (if applicable)

ORD.075 The system MUST allow for the creation and tracking of a list of Tasks associated with the Order, including but not limited to:

1. Field/Design work 2. Permit applications 3. Dependencies on other activities (e.g., Contracting, Procurement) 4. Documentation of as-builts

ORD.076 The system MUST allow an area for notes to be place in the order, which are permanently a part of the record and are date/time/user stamped.

ORD.077 The system MUST provide templated workflow that can be customized for each Service: 1. Standard Tasks and Task Durations 2. Overall Standard Duration (for each Order Item) 3. Task Owners

INV.040 The system MUST allow tracking of the following in auditing of Equipment/Assets: 1. Date of audit 2. Status of the audit process 3. Person conducting the audit 4. Adjustments for physical count reconciliations

INV.050 The system MUST allow ICN to transfer an Asset(s) from one location to another including Vendor/Customer warehouse(s) (from LOC.010).

INV.051 The system MUST allow for cancellation of a pending transfer.

INV.061 The system MUST allow for manual or automatic initiation of workflow for replacement of an instance of Equipment/Asset reserved per EQUIP.080 that has been reassigned to another Project or Order.

INV.062 The system MUST allow for Equipment/Assets to be reserved for spares, i.e. for repair use only.

INV.063 Assets that are reserved MUST not be considered available for the auto-reorder threshold for that Equipment/Asset. (see PRO.100)

INV.100 The system MUST allow a view or link to all current and historical orders associated to the Asset including the original purchase of the Equipment/Asset.

INV.110 The system MUST provide for tracking and reporting on the following for each type of Equipment/Asset: 1. Count on hand 2. Count in reserve, by type of reservation (e.g. Project, spares, etc.) 3. Auto-reorder threshold (see PRO.100) 4. List of Assets by site/location

INV.120 The system MUST allow ICN to calculate and store accumulated depreciation for an Equipment/Asset, period dates of accumulated depreciation and the history of prior accumulated depreciation calculations.

INV.130 The system MUST allow ICN to calculate and store the current book value of an Equipment/Asset and the history of prior book value calculations.

INV.150 The system MUST record the following information after an Equipment/Asset record is added, updated or removed:

1. User ID 2. Date/time 3. Action (add, edit, delete, etc.) 4. Previous field/value (if applicable) 5. New field/value (if applicable)

ITIL.010 The system MUST be able to store and access the following SLA/OLA/UC information:1. Related Service(s) (SVC.030) 2. Service Level Manager (CONT.010) 3. Customer contact for SLA (CONT.010) 4. Vendor contact for SLA (CONT.010) 5. Customers covered by SLA (CUST.010) 6. Vendor(s) providing service under the SLA (VEN.010) 7. Start and end dates 8. Renewal date 9. Hours when the service is available 10. Time within which a defined level of service must be re-established 11. Metrics for reports 12. Status of SLA/OLA/UC 13. Name of SLA/OLA/UC

17


(Y/N)

ITIL.020 The System MUST be able to store and access the following information about Releases: 1. Unique identifier 2. Status 3. Manager of the Release (CONT.010) 4. Description 5. Notes or information about the Release as it is worked. 6. Target date 7. Completion date that can auto fill in based on the status 8. Related Change/RFC(s)

ITIL.030 The System MUST be able to store and access the following RFC/Change information. 1. Unique identifier 2. Status 3. Requestor (CONT.010) 4. Coordinator (CONT.010) 5. Related Service (SVC.030) 6. Description 7. a running notes or information field for the Change 8. Category 9. Target date 10. Planned start date 11. Actual start date 12. Planned finish date 13. Actual finish date 14. Organization performing the change (CUST.010) 15. Related Order(s) that need to happen for the Change to be completed (ORD.001) 16. Voting-based approval process for the Change 17. Expected impact of the Change 18. Reason for the Change

ITIL.040 The System MUST be able to store and access the following Incident information 1. Unique identifier 2. User and Equipment-initiated Incidents 3. Related CI(s) (INV.010) 4. Status 5. Description 6. Running notes or information about the Incident as it is worked. 7. Related Service (SVC.010) 8. Related Customer/Contact (CONT.010) 9. Target date for resolution that can be auto set via relation Customer, Service and SLA

(CONT.010, SVC.010 and ITIL.010) 10. Completion date 11. Assigned Workgroup 12. Assigned Contact (CONT.010) within the Assigned Workgroup above 13. Vendor (VEN.010) that is supplying the service, if any 14. External (vendor) ticket number, if any 15. Solution/resolution 16. Related Incident(s), if any 17. Source of the Incident (equipment signal/SNMP, phone call, email, etc..) 18. Categorization for searchable knowledge base, if any 19. Incident category (change, resolution, improvement, etc.) 20. Severity (from a configurable list of options) 21. Email integration for opening or updating Incidents 22. Automatically send email to Customer/Contact, Vendor(s) and staff as status of the Incident

changes 23. Related Problem(s) (see ITIL.050). 24. Related Change/RFC(s) (see ITIL.030).

18


(Y/N)

ITIL.050 The System MUST be able to store and access the following Problem information: 1. Unique identifier 2. Related CI(s) (INV.010, EQUIP.010) 3. Status 4. Description 5. Notes or information about the Release as it is worked. 6. Related Service (SVC.010) 7. Assigned Workgroup 8. Assigned Contact (CONT.010) within the Assigned Workgroup above 9. Category (proactive, reactive, etc.) 10. Severity/Impact 11. Target date 12. Actual completion date 13. Vendor (VEN.010) that is supplying the service, if any 14. External (vendor) ticket number, if any 15. Solution 16. Related Incident(s) (see ITIL.040) 17. Related Change/RFC(s) (see ITIL.030)

ITIL.090 The Vendor MUST describe how the System will allow ICN to automate and enforce the integrity of its processes.

ITIL.100 The system MUST record the following information each time a modification is made to any ITIL-related information:


ITIL.110 The Vendor MUST state what ITIL version(s) and levels of compliance the system provides.

SYS.020 The proposed solution MUST allow for the encryption of all sensitive traffic between the client and server. Consistent with the State's operating environment, vendors MUST indicate if the proposed solution is compatible with SSL provided by a reverse proxy, and not by the HTTP or application server. Systems SHOULD NOT rely on the “Host:” header passed to them, as translation of this value can occur at the reverse proxy layer. Systems SHOULD be able to function in a NAT environment, where physical IP addresses are not provided.

SYS.040 The system MUST provide a variety of standard reports and the ability to create ad hoc reports.

SYS.044 The set of information available to each user via reporting in SYS.040, above, MUST be limited by access controls for each user as defined in SEC.010, SEC.020 and SEC.021.

SYS.045 Vendor MUST provide field definitions for reporting in SYS.040 or cover this in SYS.066.

SYS.050 Vendor MUST describe the extent to which existing ICN data sources can be migrated to the System, the process involved, and how data migration costs are estimated.

SYS.060 Vendors MUST indicate which of the following server environments (and specific versions) the proposed solution will run on:

1. Windows Server 2. Linux 3. Solaris 4. HPUX 5. Other (please specify)

SYS.061 The proposed solution will need to be capable of running in a virtualized environment. Vendors MUST indicate which components of the proposed solutions CAN and CANNOT be virtualized.

SYS.062 The system will need to support a wide variety of governmental, organizational and private users. Vendors MUST indicate which of the following platforms/browsers the proposed solution supports:

1. Internet Explorer 6, 7, 8 2. Firefox 2, 3 3. Safari 2, 3 4. RIM Blackberry 5. Apple iPhone 6. Windows Mobile 7. Windows XP 8. Windows Vista 9. Windows 7 10. Fat client 11. Other (please specify)

19


(Y/N)

SYS.063 Vendors MUST indicate how quickly they support new versions/patches/security updates to software needed to run their solution. (Including but not limited to major/minor):

1. Browser versions 2. Workstation OS versions 3. Server OS versions 4. Database versions 5. Workstation/Server security patches

SYS.065 Vendors MUST indicate which of the following databases (and specific versions) can be used to store the system's data:

1. Oracle 2. IBM DB2 3. MS SQL Server 4. MySQL 5. PostgreSQL 6. Other (please specify)

SYS.070 Vendors MUST provide information on the architecture of the proposed solution. Such information should include, but not be limited to, the third-party vendors and components to be used; as well as any proprietary or customized components, and the roles fulfilled by each component. Vendors MUST indicate the networking configuration required (ports, protocols, etc.) between any components that require or allow for distributed computing.

SYS.075 Vendors MUST provide detailed workstation and browser hardware and software requirements for the proposed solution.

SYS.080 Vendors MUST identify a minimum hardware set and (optionally) a preferred hardware set for deploying and operating the proposed solution. The proposed hardware will be used as a baseline for comparison with existing ICN infrastructure (including virtual servers) and may or may not be accepted as part of the solution. Vendors SHOULD indicate any component(s) of the recommended hardware that may not be substituted for existing ICN infrastructure. The proposed hardware MUST allow the system to meet or exceed the minimum peak performance and scalability goals defined in SYS.030, above. The estimated costs for hardware MUST be separate and itemized in the Cost Proposal.

SYS.090 Vendors MUST identify all software associated with the operation of the system, including all third-party software that the State must acquire to deploy and operate the proposed solution. This SHOULD include, but not be limited to, operating system, DBMS or application server licenses, client software, drivers, adapters and converters, copyrighted media, logos or images, client access licenses, etc. Software costs MUST be separate and itemized in the Cost Proposal.

SYS.100 Vendors MUST identify supported methods of integrating with the proposed solution including, but not limited to the following:

1. SOAP/POX/REST 2. Direct database access (shared tables, through ODBC, JDBC, other) 3. File Transfer (Upload/Download), including specified format(s) (XML, CSV, etc.) 4. Message-Oriented, e.g., JMS, MSMQ 5. CORBA/RMI/DCOM, etc. 6. Other (please specify)

SYS.130 The system MUST use one or more specific TCP/UDP ports for IP communications with the software to aid in easily passing the traffic across firewalls.

SYS.140 The system MUST be capable of providing availability per Vendors MUST provide detailed information on existing implementation(s) that meet or exceed this goal in production.

SYS.145 The system MUST be capable of a Disaster Recovery interval of Vendors MUST provide detailed information on existing implementation(s) that meet or exceed this goal in production.

SYS.190 The Vendor MUST list out of the box integrations that the system will support with other products.

SEC.010 The system MUST utilize role-based security requiring each user to register and log into the system using a unique user name and password.

SEC.015 The system MUST allow for the association of a user account (from SYS.010) to a Contact record in the system (see CONT.010)

SEC.020 The system MUST provide access controls based on Organization and/or Role memberships of a given account (Contact record) from SEC.010.

SEC.022 The system MUST allow for access control to be applied at the page, area, or field level, providing certain accounts or groups with read only, read/write, or no access to information.

SEC.066 Vendors MUST identify types of data that cannot be searched using methods in SEC.060 and SEC.065.

SEC.070 The proposed solution is intended to be compliant with Section 508 of the U.S. Rehabilitation Act of 1973, as amended (29 U.S.C. 794d) to remove barriers for persons with disabilities. Vendors MUST identify if and how the proposed solution complies with or goes further than Section 508 in making the application accessible to persons with disabilities.

20

http://www.access-board.gov/sec508/guide/index.htm



(Y/N)

SEC.085 Vendors MUST list areas of the system that cannot be modified by ICN administrators.

PROJ.010 Vendors MUST include a detailed project plan for delivery of all required elements of the proposed solution. The plan should address, at a minimum, the following elements:

1. Project management, quality assurance (process audit), peer review, and management oversight

2. Development of requirements, designs, reports, and screen definitions, 3. Customization or development of the database, web services or integration points 4. Solution development, including coding and unit testing 5. Configuration management and build activities 6. Data Mapping, Migration and Integration activities 7. Deployment planning, execution and validation activities 8. Knowledge transfer, including operations and support documentation development and training

of ICN staff 9. Test planning and test script development 10. Test execution and review of results 11. Proposed customer approval points / milestones for signoff and payments12. Estimated effort, resource allocation and time line for completion. 13. Dependencies and priorities between planned tasks

In addition, vendors may provide an estimated contingency timeline and costs for any change requests, based on previous project experience (if applicable). This estimate should be separate and itemized in the Cost Proposal.

PROJ.015 Vendors MUST provide a proposed organizational structure for the combined Vendor and ICN project team including (but not limited to) reporting responsibilities, communication paths, escalation procedures and roles/responsibilities for execution of the project plan in PROJ.010, above.

PROJ.020 Vendors MUST include project plan elements in PROJ.010, above, for planning of the pre-production and production environments in conjunction with ICN, and for time to be spent executing the Vendor's parts of any resulting plans with ICN staff.

PROJ.030 Vendors MUST describe the steps and documents that will be provided for deployment and support of the test/pre-production and production systems by ICN staff. If direct access to the servers is required for vendor staff, the vendor shall provide justification for the requirement and an alternative process for upgrades and other ongoing maintenance work.

PROJ.035 Vendors MUST provide a suggested set of roles and recurring tasks for ongoing operation and maintenance of the system, including estimated resource allocations and skill(s) required.

PROJ.040 Vendors MUST describe at least one scenario (including roles and responsibilities, lead times, service levels, technical requirements) for providing technical support, along with estimated costs for each of these elements. For each scenario, the vendor shall indicate if any current customers use the specified process. This cost should be itemized separately in the Cost Proposal.

PROJ.050 Vendors MUST identify any components of the proposed solution that require per-client or per-server license costs, or any other licensing cost not included in the Cost Proposal. Cost proposals should reflect all costs required to deploy and operate the proposed system.

PROJ.060 Vendors MUST identify all software associated with the operation of the system, including all third-party software that the State must acquire to deploy and operate the proposed solution. This should include, but not be limited to, operating system, DBMS or application server licenses, client software, drivers, adapters and converters, copyrighted media, logos or images, client access licenses, etc. Software costs must be separate and itemized in the Cost Proposal.

PROJ.070 Vendors MUST identify any areas that they expect to customize for the proposed solution, based on the requirements in this Section of the RFP. Such customizations should have corresponding assumptions and tasks in the proposed project plan, and MUST be part of the Cost Proposal.

PROJ.080 Vendors MUST identify and estimate recurring costs such as (but not limited to) ongoing license fees to the vendor and/or any third parties, upgrade or maintenance fees (including those for customized features), expected technology refresh cycles for operating systems, application servers or other components of the solution. Vendors should indicate whether these estimates are based on existing customer experiences or are projected without a prior basis.

PROJ.090 Vendor MUST specify if an assessment will be done of the ICN's existing data and processes as the first step of the project. If any additional costs are associated with having the assessment done they must be listed as well.

PROJ.100 Vendor MUST give an example of the steps the Vendor has used to implement a system like this before.

PROJ.110 Vendor MUST identify what types and levels of integration can be performed by the Vendor to help align the new OSS system with ICN and its processes and other software products.

PROJ.120 Vendor MUST identify training requirements, lead times, and costs for rollout of the System to ICN staff.

PROJ.140 Vendor MUST include project plan elements to scope, design and implement a customer web portal that meets the specified customer self-service requirements elsewhere in this RFP (e.g., REQ.056, MISC.160, AR.060, AR.131, BILL.013, BILL.014, BILL.038, BILL.040, BILL.107, BILL.108)

21


(Y/N)

PROJ.150 Vendor MUST include any applicable examples for similar portal functionality that was implemented, indicating:

1. What platform was used (vendor product, programming language) 2. Integration approach(es) (SOA/WS, Database access, file xfer, other) 3. Approximate incremental cost (beyond internal OSS functionality) 4. Approximate lead time 5. Approximate resource loading for vendor and customer staff 6. Levels of usage for various ICN requirements, if available (How many requests per month?

How many orders vs. billing inquiries vs. billing data updates, etc.)

PERF.010 Vendors MUST provide the following general background information:1. Name, address, telephone number, fax number and e-mail address of the bidder including all

doing business as or assumed names or other operating names of the bidder.2. Form of business entity, i.e., corporation, partnership, proprietorship, Limited Liability

Company.3. State of incorporation, state of formation, or state of organization.4. Identify and specify the location(s) and telephone numbers of the major offices and other

facilities that relate to the bidder’s performance under the terms of this RFP.5. Local office address and telephone number (if any).6. Number of employees.7. Name, address and telephone number of the bidder’s representative to contact regarding all

contractual and technical matters concerning this proposal.8. Name, address and telephone number of the bidder’s representative to contact regarding

scheduling and other arrangements.9. Identify the bidder’s accounting firm.

PERF.020 Vendors MUST provide the following information about company experience & qualifications:1. Business background, number of clients, number of years in business, and other information

as necessary to provide assurance of your financial stability2. The number of years of experience providing the types of services sought by the RFP3. The level of technical experience in providing the types of services sought by the RFP4. All services similar to those sought by this RFP that the bidder has provided to other

businesses or governmental entities5. A list of similar projects that are currently in process by the bidder

PERF.030 Vendors MUST provide letters of reference from three (3) clients knowledgeable of the bidder’s performance in providing services similar to the services described in this RFP. Include full contact information including name, title, telephone and fax numbers plus email addresses for each reference.

PERF.040 Vendors MUST provide the following information regarding personnel and capabilities:1. A table of organization. Illustrate the lines of authority. Include the names and credentials of

the owners and executives of your organization and, if applicable, their roles on this project. Also include key personnel who will be involved in providing services contemplated by this RFP.

2. Resumes for all personnel, including any subcontractors, who will be involved in providing the services contemplated by this RFP. The resumes must include: name, education, and years of experience and employment history, particularly as it relates to the scope of services specified herein. It is expected that the key personnel presented in the vendor response to the RFP will be the team members involved in providing the services for transition to the new software system. The ICN reserves the right to approve any staff changes.

3. The name and qualifications of any subcontractor/vendor who will be involved with this project. Describe the work and estimate the percent of total work the subcontractor will be performing.

4. Other contracts and projects currently undertaken by the Vendor.

PERF.050 Vendors MUST provide the following financial information to demonstrate long term viability to carry out the requirements of any contract with the State:

1. Audited financial statements (annual reports) for the last three (3) years and/or bank statements, credit reports etc. These may be via a web address or as part of the documentation.

2. A minimum of three (3) financial references.3. Certification that vendor is bondable and provide bond rating.

22


(Y/N)

PERF.060 Vendors MUST provide the following information about Termination, Litigation, and Investigation:1. During the last five (5) years, has the Vendor had a contract for services similar to those

contemplated terminated for any reason? If so, provide full details related to each termination.2. During the last five (5) years, describe any damages or penalties or anything of value traded or

given up by the Vendor under any of its existing or past contracts as it relates to services performed that are similar to the services contemplated by this RFP and the resulting Contract. If so, indicate the reason and the estimated cost of each incident to the bidder.

3. During the last five (5) years, list and summarize pending or threatened litigation, administrative or regulatory proceedings, or similar matters that could affect the ability of the Vendor to perform the required services. The Vendor must also state whether it or any owners, officers, or primary partners have ever been convicted of a felony. Failure to disclose these matters may result in rejection of the Bid Proposal or in termination of any subsequent contract. This is a continuing disclosure requirement. Any such matter commencing after submission of a Bid Proposal, and with respect to the successful bidder after the execution of a contract, must be disclosed in a timely manner in a written statement to the ICN.

4. During the last five (5) years, have any irregularities been discovered in any of the accounts maintained by the Vendor on behalf of others? If so, describe the circumstances of irregularities or variances and disposition of resolving the irregularities or variances.

PRICE.010 Vendors MUST include the following itemized elements in pricing proposals:1. Prices for each module referenced in the proposal2. Estimated costs for the recommended hardware identified in SYS.0803. VAR or market-price estimates for associated software identified in SYS.090

PRICE.030 Vendors submitting SaaS/hosted licensing options MUST provide the following options:1. Month-to-month pricing (no ongoing commitment)2. Three-year commitment (if different from the monthly price)3. Six-year commitment (if different from the three-year price)

PRICE.040 Vendors MUST include the following itemized elements for professional services / consulting time identified in PROJ.010:

1. Estimated hours, hourly rates and cost for meeting all Mandatory Requirements2. Estimated hours, hourly rates and cost for implementation of any combinations of modules

offered in PRICE.0203. Estimated hours, hourly rates and cost for implementation of SaaS/hosted options offered in

PRICE.030

PRICE.050 Vendors MUST provide itemized service levels and costs for ongoing maintenance and technical support of each module (PRICE.010), bundle (PRICE.020) or service (PRICE.030) that is proposed. Service level definitions MUST include:

1. Contact channels (phone, email, etc.)1. Coverage hours/days (e.g., 24x7, 12x5, etc.)2. Committed service levels (response times, 3. Escalation path / procedure

Vendor MUST provide the list of the modules necessary to meet the Mandatory Requirements above.

23

Full Requirements Checklist

Each requirement requires a response whether the Vendor meets the requirement (“Requirement Met” column), and the applicable page(s) in the Vendor's proposal document where the response can be found (“Proposal Ref (Page#)” column).VENDORS MUST RESPOND TO THIS SECTION AND ALL SUB-SECTIONS.

3.6.1 Customers


(Y/N)Proposal Ref

(Page #)

CUST.010 The system MUST store the following information about each Customer:1. Customer Name should be agency name with sub name or descriptor name.2. Status (predefined list: Active/Inactive/etc.)3. Description / Notes

CUST.020 The system MUST allow ICN to identify parent and child relationships between Customer records allowing for more than 2 levels of hierarchy/relationships between the customers.

CUST.025 Parent child relationships SHOULD be able to be viewed in a hierarchy.

CUST.030 The system MUST allow ICN to identify an ICN-defined set of attributes for Customer records, including but not limited to:

1. Class (predefined drop down list, e.g. State Agency, Education, etc.)2. Category (predefined drop down list, e.g. College, Judicial, Executive, etc.)3. Federal, County, Local indicator4. Billing Account (format is 12 alpha-numeric with 3 digit subaccount, e.g.

ABC000000001-001)

CUST.040 The system MUST record the following information after a Customer record is added, updated or removed:


CUST.041 The system SHOULD record the following information after a Customer record is added, updated or removed (if applicable):

1. Previous field/value2. New field/value

CUST.050 The system SHOULD allow ICN to store custom account information for each customer, including but not limited to:

1. I/3 accounting string (e.g., fund-dept-org-sub)2. I/3 vendor type and number3. Credit card type/number4. ABA routing and account number5. Banking information for specified Customers. (We should be able to do auto debit

to customer accounts, similar to IFAS transfers with state agencies).

Vendor SHOULD provide the list of the modules necessary to meet the Requirements above.

3.6.2 Contacts


(Y/N)Proposal Ref

(Page #)

CONT.010 The system MUST store the following information about each Contact:1. First Name2. Last Name3. What responsibility does contact have (billing, auth sign, etc.)?4. Status (from predefined list: Active/Inactive/etc.) 5. Work Phone Number6. Mobile Phone Number7. Fax Phone Number8. E-Mail Address

CONT.020 The system SHOULD store the following extended Contact information:1. Other Phone Number(s) (with description)2. Other E-Mail Addresses (with description)3. Preferred Name (nickname)4. Job Title5. Contact Notes

24


(Y/N)Proposal Ref

(Page #)

CONT.030 The system SHOULD allow for on-demand import / update of a selected Contact record from the State's Active Directory

CONT.040 The system SHOULD allow for Contact records imported from the State's Active Directory to be updated and maintained independently.

CONT.050 The system MUST allow association of one or more Contact records to one or more Customer/Vendor record(s). (from CUST.010 or VEND.010)

CONT.055 The system MUST allow association of one or more Locations to a Contact record. (from LOC.010)

CONT.056 The system MUST specify the type of association (via predefined list: mailing, billing, ship-to, etc.) between the Contact and the Location.

CONT.060 Each association between a Contact and Customer/Vendor in CONT.050, above, MUST include the following association-specific information:

1. Contact Type (Billing, Customer, Other/Explain, Location, Circuit, Support, Sales, etc.)

CONT.070 The system MUST record the following audit information after a Contact record is added, updated or removed:


CONT.071 The system SHOULD record the following audit information after a Contact record is added, updated or removed:

1. Previous field/value (if applicable)2. New field/value (if applicable)


3.6.3 Locations


(Y/N)Proposal Ref

(Page #)

LOC.010 The system MUST store the following information about each Location:1. Location Name2. CLLI Code (Telecordia standard)3. Physical Address: StreetLine1, StreetLine2, City, County, State, Zip, Zip+44. Latitude/Longitude coordinates5. Vertical/Horizontal coordinates6. Fiber entrance location(s)7. Power Feed Information (Amperage and Voltage)8. HVAC Capacity information9. Description/Notes10. Access/Entry Notes11. Lock Box Location (Site access keys)12. Type of location (from predefined list, e.g. vendor, Part 1, Part 3, Node, link splice

location, etc)13. Phone Number (NPA-NXX-XXXX)14. LATA (Local Access and Transport Area)15. Status (Active, Inactive, etc.)

LOC.011 The system MUST allow definition of multiple suite numbers (e.g. multiple deliverable addresses) within a location (CLLI).

LOC.015 The system SHOULD store the following information about each Location:1. Cable management (from predefined list, overhead, raceway)2. Type of floor (from a predefined list, raised, concrete) 3. Generator on Site (yes/no)4. Power Ground type (from predefined list, earth)5. Power Ground Notes

LOC.030 The system MUST allow occasional load and/or update LERG data including:Location Name

1. CLLI Code (Telcordia standard)2. Physical Address: StreetLine1, StreetLine2, City, State, Zip, Zip+43. Latitude/Longitude coordinates4. Vertical/Horizontal coordinates5. Description/Notes6. Type of location (from predefined list, (vendor, Part 1, etc)7. LATA (Local Access and Transport Area)8. Phone Number (NPA-NXX-XXXX)

25


(Y/N)Proposal Ref

(Page #)

LOC.040 Vendor MUST describe the method(s) to load LERG data referenced in LOC.030.

LOC.050 The system MUST allow ICN to associate zero or more Location records to a given Customer or Vendor.

LOC.060 The system MUST allow ICN to associate one or more Customers/Vendors to a given Location.

LOC.070 The system MUST allow ICN to classify each Location that is associated to a Customer, including at least the following categories:

1. Primary2. Alternate3. Bill-to4. Ship-to5. Equipment-only6. Emergency Contact

LOC.075 The system SHOULD have the ability to attach files to Locations (For site photos and site drawings)

LOC.076 The system SHOULD allow a Location to be the subject of a request/order. (for adding a site and disconnecting a site)

LOC.077 The system SHOULD allow for Locations to be mapped.

LOC.080 The system MUST record the following information for a Location record upon each addition, update or removal:

1. User ID2. Date/time3. Action (add, edit, delete, etc.)4. Order Number5. Previous field/value (if applicable)6. New field/value (if applicable)


3.6.4 Equipment


(Y/N)Proposal Ref

(Page #)

EQUIP.005 The system MUST generate a Unique ICN ID for each Equipment/Asset instance.

26


(Y/N)Proposal Ref

(Page #)

EQUIP.010 The system MUST store the following information about each Equipment Chassis:1. Part Number(s)2. Associate with CLLI (Location) See LOC.0103. Manufacturer 4. Model5. Slot and Port Counts6. Type of Power Required7. Power Input/Output Required8. Relay Rack assignments (rack within a line up)9. Relay Rack Position assignments (within a rack)10. Serial Number11. Management IP Address / netmask12. Unique ICN ID (from EQUIP.005)13. State ID/Tag14. Install Date15. Related Purchase Order Number (PRO.015)16. Owner17. Administrator18. Work Order/Request History (See REQ.010)19. Category (i.e. Grouping of Equip - Switch, Transport, etc.)20. Subcategory (i.e. Ethernet Switch, ATM Switch, etc. for the selected Category)21. Status (Inactive, active, defective, etc.) (Drop-down List)22. Date Last Inspected (See MISC.020)23. Description/Notes24. Common name (alias)25. Maintenance Contract(s) (CONTR.010)26. End of life date27. End of Support date28. GAAP depreciation timeframe for the asset29. ICN/Vendor recommended timeframe for disposal of the asset30. General ledger code for the expense31. Specify if Capital asset32. Effective date of transfer33. If it was identified as being billable to the customer in the original order34. Effective date of status35. Acquisition price

EQUIP.015 The system SHOULD store the following information about each Equipment Chassis:1. Version/Revision2. BTU/hr3. Dimensions4. Weight 5. Acquisition Date 6. Service(s) (from SVC.030)7. Alarm History8. Work Order/Request History (See REQ.010)9. Historical transfer(s) of an Asset and the date of the transfer(s).

EQUIP.020 The system MUST associate the Equipment/Asset to a CLEI code.

EQUIP.025 The system SHOULD allow for tracking and monthly trending data on equipment (for example voltage use & amperage use, use of CPU, use of memory, use of disk, use of bandwidth, etc...)

EQUIP.030 The system SHOULD allow ICN to associate zero or more (customer-owned) Equipment/Asset records to a given Customer. (CUST.010)

27


(Y/N)Proposal Ref

(Page #)

EQUIP.040 The system MUST store the following information about each Equipment Card:1. Card Type2. Part Number(s)3. Associated Equipment CLEI4. Manufacturer 5. Model6. Slot assignment7. Port Density (# of ports)8. Power Input/Output Required9. Dimensions10. Serial Number11. Unique ICN ID12. State ID/Tag13. Install Date14. Acquisition Date15. Owner16. Status (Inactive, active/installed, defective, etc.) (Drop-down List)17. Description18. GAAP depreciation timeframe for the asset19. ICN/Vendor recommended timeframe for disposal of the asset20. General ledger code for the expense21. Specify if Capital asset22. Effective date of transfer23. If it was identified as being billable to the customer in the original order24. Effective date of status25. Acquisition price

EQUIP.045 The system SHOULD store the following information about each Equipment Card:1. Version/Revision2. Options for Slot assignment within an Equipment Chassis 3. Type of Power Required (if card equals power supply) 4. BTU/hr 5. Related Purchase Order Number 6. Alarm History7. Work Order/Request History (See REQ.010)

EQUIP.050 The system MUST associate Equipment Cards with Equipment Chassis in Slot assignments.

EQUIP.060 The system MUST store the following information about each Equipment Port:1. Port Type2. Associated Equipment CLEI3. Make4. Model5. Brand6. Vendor7. Card Assigned8. Port Speed9. IP Address10. Status (Inactive, active, defective, etc.) (Drop-down List)11. Assigned circuit (See CIR.010)12. Description/Notes13. Ethernet MAC Address

EQUIP.062 The system MUST store the following information about each Logical Equipment Port:1. Speed2. DLCI3. VLAN ID4. VLAN Name5. Tagging6. VPI7. VCI8. IP Address9. Time Slot10. Status (Inactive, active, defective, etc.) (Drop-down List)11. Assigned circuit (See CIR.010)12. Description/Notes

EQUIP.063 The system SHOULD store the following information about each Equipment Port:1. Version / Revision 2. Type of Connectivity Required (i.e. RJ45, CAT5, BNC, Fiber MM, SM, LC, ST,

etc.) 3. Line Coding4. Tagging (VLAN)5. Time Slot 6. Work Order/Request History (See REQ.010) (for both Logical and Physical Ports)

28


(Y/N)Proposal Ref

(Page #)

EQUIP.065 The system MUST store the following information about each Relay Rack:1. Rack Dimensions (drop down list)2. Install Date3. Maximum weight allowed4. Number of mounting positions (rack units)5. Manufacturer6. Part Number(s)7. Rack Name8. Unique ICN ID9. Status (Inactive, active, defective, etc.) (Drop-down List)10. GAAP depreciation timeframe for the asset11. ICN/Vendor recommended timeframe for disposal of the asset12. General ledger code for the expense13. Specify if Capital asset14. Effective date of transfer15. If it was identified as being billable to the customer in the original order16. Effective date of status17. Acquisition price

EQUIP.066 The system SHOULD store the following information about each Relay Rack:1. Model 2. State ID/Tag3. Notes

EQUIP.070 The system SHOULD restrict assignment of the following:1. Equipment Cards to Equipment Chassis within the permitted slot assignment.2. Equipment Chassis to Relay Racks with sufficient available rack positions

EQUIP.080 The system MUST allow reservation of the following items for future assignment, and track the user, Project/Order, and date of reservation. This will remove the items from auto-provisioning (e.g. to reserve ports during project planning of currently unknown circuits):

1. Rack Assignments2. Rack Units3. Chassis slots4. Cards5. Ports6. Other Equipment/Assets

EQUIP.090 The system MUST record the following historical audit information after any Equipment/Asset record is added, updated or removed:

1. User ID2. Date/time3. Action (add, edit, delete, etc.)4. Order Number (the Request which caused the record to be added, updated, or

removed)

EQUIP.091 The system SHOULD record the following historical audit information after any Equipment/Asset record is added, updated or removed:

1. Previous field/value (if applicable)2. New field/value (if applicable)

EQUIP.100 The system MUST provide the ability to easily duplicate existing Equipment, Power Equipment, Card, and Port records. The resulting records MUST be editable.

EQUIP.105 The system MUST allow a templated list of required and optional fields for each piece of Equipment/Asset. The fields shown MUST be variable based on Equipment type.

EQUIP.106 The system SHOULD allow ICN to add/modify/delete templates for Equipment/Asset.

EQUIP.107 The system SHOULD record the following Preventative Maintenance information:1. Schedule PM Intervals2. Track when site visit has been made3. Track site asset pictures, including workflow to verify they meet Operations,

Engineering, Financial and State auditors requirements4. Access forms from the field to complete each new PM cycle5. Able to review past PM information from the site when working trouble tickets or

new installs6. Update real time data from the field

29


(Y/N)Proposal Ref

(Page #)

EQUIP.110 The system MUST store the following information about Power Equipment:1. Associate with CLLI (Location)2. Manufacturer3. Model4. Vendor Slot Count5. Vendor Port Count6. Type of Power Required (AC, DC)7. Power Input/Output Required (Voltage, Amp Draw)8. BTU/hr9. Dimensions10. Weight11. Relay Rack assignments12. Relay Rack Position assignments13. Serial Number14. Unique ICN ID15. State ID/Tag16. Install Date17. Acquisition Date18. Related Purchase Order Number19. Category20. Subcategory21. Owner22. Alarm History 23. Inspection date24. Impedance (Batteries)25. Voltage Readings (Batteries)26. Conditions (e.g. for Batteries: Good, Cracked, Fair, etc.)27. Hours (Generator)28. Status (Inactive, active, defective, etc.) (Drop-down List)29. Description/Notes30. GAAP depreciation timeframe for the asset31. ICN/Vendor recommended timeframe for disposal of the asset32. General ledger code for the expense33. Specify if Capital asset34. Effective date of transfer35. If it was identified as being billable to the customer in the original order36. Effective date of status37. Acquisition price

EQUIP.115 The system SHOULD store the following information about Power Equipment:1. Version/Revision/Model2. Work Order/Request History (See REQ.010)

EQUIP.116 The system MUST store the following information about each Other Equipment/Asset:1. Location Name (from LOC.010)2. GAAP depreciation timeframe for the asset3. ICN/Vendor recommended timeframe for disposal of the asset4. ICN Part number/serial number5. State IP Tag number6. Acquisition date7. General ledger code for the expense8. Specify if Capital asset9. Owner10. Specify if Asset is transferred to Vendor/customer warehouse11. Effective date of transfer12. Corresponding Order(s)13. If it was identified as being billable to the customer in the original order14. Status (from list - pending, active, pending disposal, disposed)15. Effective date of status16. Description/Notes17. Acquisition price

EQUIP.120 The system MUST allow ICN to relate Equipment/Assets to Contracts. (CONTR.010)

EQUIP.130 The system MUST allow for the tracking of configuration information of the Equipment/Asset.

EQUIP.140 The system MUST allow ICN to relate Equipment/Assets to other equipment and define the relationship type. (Parent, Child, License, etc.)


30

3.6.5 Cable/ Outside Plant


(Y/N)Proposal Ref

(Page #)

CAB.010 The system SHOULD allow the attachment of documents per fiber strand. (e.g. OTDR readings)

CAB.020 The system MUST have a notepad for each cable bundle that documents any activity, and includes a date/time/person stamp for each entry.

CAB.030 The system MUST be able to store the following information about each cable bundle: 1. Loc A CLLI ( the CLLI should be selectable from a list pulled from LOC.010) 2. Loc Z CLLI ( the CLLI should be selectable from a list pulled from LOC.010) 3. Style of cable (SM, MM, coax, utp, stp etc.) 4. Type of cable (cat 3, cat 5, RG-6, core diameter etc.) 5. Length of cable (in km and or feet) 6. Number of pairs (or number of strands) 7. Cable name 8. Cable description (direct bury, aerial, duct required, etc.) 9. Ownership Type (owned, leased, abandoned, etc.) 10. Plenum rating (plenum, non-plenum) 11. Administrator (ICN, ITE, City, etc.) 12. Splice point detail (Link Splice) - there may be zero or more of these 13. Cross reference (Vendor to Cable) - there may be zero or more of these 14. Color

CAB.035 The system MUST be able to store the following information about each individual cable in a cable bundle

1. Bundle to which the cable belongs 2. Type of connector 3. Length of cable 4. Plenum rating (plenum, non-plenum) 5. Type of cable (category rating; ie CAT V, CAT VI, Fiber) 6. Color 7. Owner 8. Status (Active, Reserved, Assigned, bad, etc.) 9. Splice point detail (Link Splice/Cross Connect Block, etc.) - there may be zero or

more of these 10. Notes - Date/Time/User Stamp permanent comments 11. Related Termination Detail (FDP, Jack Position Number, Connector Type, etc.), if

connected

CAB.036 The system SHOULD be able to store the following information for each individual cable regarding OTDR (Optical Time Domain Reflectometer) scan results

1. Attenuation 2. Splice losses 3. Mated-connector losses 4. Total loss 5. OTDR results viewer (software) 6. This data should be able to be trended and graphed

CAB.037 The system SHOULD be able to store the following information about each Cable bundle 1. Part Number(s) 2. Manufacturer 3. Unique ICN ID 4. State ID/Tag 5. Install Date 6. Related Purchase Order Number (PRO.010) 7. Work Order/Request History (See REQ.010) 8. Description/Notes 9. Cable manufacturing standard (i.e. SMF28)

CAB.040 The system MUST be able to perform the following functions on each cable: 1. Assign or remove ports to each cable for future assignment (assigning a circuit to

the port or the cable should bring both elements into the circuit design) 2. Assign or remove ports to each cable individually (from equipment listed in

EQUIP.040 or EQUIP.060) 3. Assign or remove ports to the cable bundle as a whole

CAB.045 The system MUST be able to handle division of a single cable bundle into two or more bundles and modify existing endpoints as appropriate (e.g., adding a splice point to insert a new location)

CAB.046 The system SHOULD store GPS information for accurately tracking and analyzing data such as fiber cuts or outage related occurrences. This would help detect patterns and better maintain the network and avoid potential problems in the future.

31


(Y/N)Proposal Ref

(Page #)

CAB.050 The system MUST record the following information after a Cable record is added, updated or removed:


CAB.051 The system SHOULD record the following information after a Cable record is added, updated or removed:

1. Previous field/value (if applicable) 2. New field/value (if applicable)


3.6.6 Vendors


(Y/N)Proposal Ref

(Page #)

VEN.010 The system MUST store the following information about each Vendor: 1. Vendor Name 2. Time Zone 3. Status (Active/Inactive/Other?) 4. Vendor Tax ID 5. Microsoft Dynamics SL Vendor ID 6. Billing Account(s) 7. Vendor terms (net 30, etc.) 8. Category (ie. company, division, department)

VEN.015 The system SHOULD store the following information about each Vendor: 1. Website (URL) 2. Description / Notes 3. Default General ledger expense account 4. Default general ledger expense subaccount 5. I/3 Vendor ID

VEN.020 The system MUST allow ICN to identify parent and child relationships between Vendor records allowing for more than 2 levels of hierarchy/relationships between the vendors.

VEN.025 The system SHOULD allow the parent child relationships to be viewed in a hierarchy.

VEN.030 The system MUST allow ICN to associate an ICN Part number to a Vendor-specific Part number for each Vendor that provides the part.

VEN.040 The system MUST allow ICN to associate Vendors with multiple Contacts (see CONT.050).

VEN.050 The system MUST allow ICN to associate multiple Contracts to a Vendor (see CONTR.016.)

VEN.060 The system MUST allow ICN to combine and split Vendor records (e.g., mergers, acquisitions, spin-offs).

VEN.070 The system MUST record the following information after a Vendor record is added, updated or removed:


VEN.080 The system SHOULD record the following information after a Vendor record is added, updated or removed:



3.6.7 Services

ID Requirement Text Requirement Met (Y/N)

Proposal Ref (Page #)

SVC.010 The system MUST identify all Services, to include internal requests and all variations of service provided to the customer base.

32



SVC.020 The system MUST be able to store and access the following Service information: 1. Service Name 2. Service Description 3. Service Category 4. Service Subcategory (allows for hierarchial) 5. Current status (e.g. Active (In Service Catalog), discontinued, being developed

etc.) 6. Service Type: Business Service (visible to the customer) or Infrastructure Service

(invisible to the customer, used as a building block for Business Services) 7. Internal / external: Internally provided service or a service sourced from an

external service supplier (Service provider field) 8. Service Owner (Group(s) responsible for service provisioning) 9. Contacts and procedures for signing up to the service 10. Infrastructure Services on which this service depends (Supporting Services) 11. Services that depend on this service (Supported Services) 12. Components (Dependant Configuration Items and Services) (Parent CIs and

Services which this service references) 13. Description/Notes - Date/TIme/User Stamp with comments, all become

permanent.

SVC.030 The Service record(s) SHOULD allow ICN to group services in hierarchical level(s) if needed.

SVC.040 The system SHOULD be able to store and access the following Financial Service information:

1. Costs for the provisioning of each service, itemized by cost types (e.g. licenses, material, labor) Including Direct costs (clearly attributable to a specific service) and Indirect costs (shared among multiple services)

2. Billable items of each service, itemized by billable types (e.g. licenses, material, labor) Including Direct billables (clearly attributable to a specific service) and Indirect billables (shared among multiple services)

3. Actual revenues from each service 4. Profit margins percentage for each service (markup) 5. Values of tangible service assets (infrastructure components) (from INV.010) 6. Estimates of the values of intangible service assets (e.g. technical expertise,

knowledge of the customers’ business processes) Above items #1 & #2 SHOULD be able to be overridden if necessary.

SVC.050 The system MUST record the following information after a Service record is added, updated or removed:


SVC.051 The system SHOULD record the following information after a Service record is added, updated or removed:



33

3.6.8 Circuits


(Y/N)Proposal Ref

(Page #)

CIR.010 The system MUST store the following information about each Circuit Header: 1. Order Number (request that initiates the Circuit or any change to the Circuit from

REQ.010) 2. "A" Location Name 3. "A" CLLI 4. "A" CLEI (predefinded from drop down list based on "A" CLLI or new) 5. "Z" Location Name 6. "Z" CLLI 7. "Z" CLEI (predefinded from drop down list based on "Z" CLLI or new) 8. Circuit type 9. Service Category / Subcategory (See SVC.010) 10. Physical hand-off/termination requested (e.g. RJ-45, SM, MM, BNC, ST, LC, SC,

FC, etc.) 11. Line Coding (e.g. B8ZS/AMI/ESF, etc.) 12. Duplex Settings (Half, Full) 13. Requested Bandwidth (Peak, Burst, Sustained) 14. Unique Circuit ID (system assigned and/or managed) 15. Associated Circuit ID aliases (i.e. LEC circuit ID) 16. Associated Customer(s)/Billing Account 17. Associated Vendor(s) (from VEND.010) 18. Associated BAN(s) (billing account number(s)) 19. Customer/Vendor associated contract number (from CONT.010) 20. Description/Notes 21. Circuit version number

CIR.015 The system MUST allow for an on-going record of notes for each circuit. Any comments added would be permanent, with a date and person stamp.

CIR.016 The system SHOULD allow ICN to show fields based on Service Category / Subcategory.

CIR.017 The system Must allow relating of the circuit to to equipment(s) (from EQUIP.010)

CIR.020 The system MUST allow for presentation of the circuit design: tying different circuits together to show as a link so that you can query, report, export for the items that make up a connection in its entirety from A to Z. (See DES.010)

CIR.030 The system MUST allow ICN to associate zero or more Contact records to a given Circuit.

CIR.040 The system MUST record the following information after a Circuit record is added, updated or removed:



3.6.9 Orders and Requests



REQ.010 The system MUST store the following information about each Order/Request: 1. Customer Name 2. Authorized signatory 3. Billing Account information for install and monthly if different - field

REQUIRED before moving order on through workflow for completion. 4. All Services (SVC.010) and corresponding Locations (LOC.010) associated with

each order item. 5. Install Contact Name, phone number and email address 6. Description 7. Notes (with date/time stamp and user id for each entry) 8. Date customer would like work completed 9. If sooner than ICN standard intervals is an expedite fee applicable? 10. Does contracting need to be involved? 11. Breakdown of how estimate is calculated for billing. 12. Breakdown of the monthly/one time for each circuit 13. Priority setting so tasks due on the same day can be prioritized. 14. Documentation of what service was agreed upon.

REQ.011 The system SHOULD provide a link/view to the associated AFEs.

34



REQ.020 The system MUST allow a Request to be generated which allows workflow to add tasks for a new CLLI or CLEI code to be generated for an "A" or "Z" location.

REQ.030 The system MUST allow ICN to associate zero or more Request records to a given Customer.

REQ.031 The system MUST allow ICN to associate multiple Orders by multiple Customers within a parent Order (Project) at any point in the Order's life cycle prior to completion.

REQ.032 The system SHOULD allow ICN to associate multiple Orders as in REQ.031, above, even after one or more Orders have been completed.

REQ.033 The system MUST allow ICN to add a jeopardy status to orders. (Jeopardy status allows ICN personnel to convey obstacles to completing orders timely - e.g. LEC delayed, Customer site access delay, etc.)

REQ.034 The system MUST allow existing service records (phones, circuits, etc.) to be added to an Order for MACD activity.

REQ.035 The system MUST allow for attachments of documents to Orders with initial request and throughout the workflow & task items completed.

REQ.036 The system MUST be capable of providing customized templates for Order entry and workflow, based on any of the following:

1. Service Ordered 2. Workflow Step 3. Person/role/group involved

REQ.037 The system MUST be able to create one or more AFEs based on and related to a specific Order.

REQ.038 The system SHOULD be able to relate AFEs to one or more Order(s).

REQ.039 The system SHOULD be capable of splitting an Order and dividing the items as needed.

REQ.040 The system MUST allow ICN to identify items, tasks, etc. as billable to the customer at a defined markup percentage (i.e. technician time, materials used, items ordered or in stock, trip charge, etc.)

REQ.050 The system MUST allow ICN to define the type of each Request that is associated to a Customer, such as:

1. Install 2. Change 3. Move 4. Disconnect 5. Estimate

REQ.055 The system MUST allow Orders to reference other Orders

REQ.056 The system SHOULD provide a web portal to allow customers to submit requests (Move/Add/Change, trouble tickets, etc.) and to see the status of submitted requests.

REQ.057 The system SHOULD allow ICN to provide limited access of order information to vendors, etc. working an order.

REQ.058 The system MUST allow ICN to associate multiple items to an Order, with different values for the following:

1. Customer 2. Service(s) 3. Location 4. Completion Date


35

3.6.10 Contracts



CONTR.010 The system MUST store the following information about each Contract: 1. Vendor/Customer contract number 2. ICN contract number 3. Vendor/Customer name (from VEND.010/CUST.010) 4. Vendor/Customer contact information (address, phone, email, etc.) (from

CONT.010) 5. Type (modifiable drop down list - maintenance, service, circuit, equipment, etc) 6. Contract dates - start/expire/renewal/early termination 7. Renewal notes (number of renewals and renewal time frames) 8. Associated costs for the period (may be multiple and variable periods) 9. Associated General Ledger code(s) and sub account(s) (for, e.g., maintenance

costs). 10. Equipment/Circuit/Items associated with this contract (from EQUIP.010 and

CIR.010) 11. Description 12. Notes (date/time/user for each entry) 13. Associated Customer(s) whose services depend on the (Vendor) Contract (from

CUST.010) 14. ICN Staff associated to Contract

CONTR.011 The system MUST allow for equipment, circuits or other items to be associated with multiple contracts.

CONTR.012 The system MUST allow for 2 or more hierarchical levels in order to tie addenda/amendments to the original contract.

CONTR.015 The system MUST allow for association of multiple Contacts to each Contract. (from CONT.010)

CONTR.016 The system MUST allow for association of multiple Contracts to each Vendor/Customer. (from VEND.010 / CUST.010)

CONTR.020 The system MUST provide reporting on expiring contracts with a variable time frame allowed in the report parameters.

CONTR.021 The system SHOULD allow the report defined in CONTR.020 to be distributed to appropriate ICN staff automatically.

CONTR.030 The system MUST allow ICN to attach multiple documents to each Contract record (allow for marking attachments as confidential for limited viewing or release).

CONTR.040 The system MUST allow for SLA/Warranty information on each Contract, including the following:

1. Termination Liability 2. Portability 3. Time to repair, e.g., returned parts, etc. 4. Outage credits and how to calculate 5. Identify Specific service provided 6. Service vendor (if maintenance is provided by a third party) 7. Vendor help desk & customer support 8. Escalation procedures & response times

Note: This information may be sizable.

CONTR.050 The system MUST record the following information after a Contract record is added, updated or removed:

1. User ID 2. Date/time 3. Action (add, edit, delete, review, etc.)

CONTR.051 The system SHOULD record the following information after a Contract record is added, updated or removed:



3.6.11 Finance



EXP.010 The system SHOULD allow ICN to mark expense items (e.g., hours billed by contractors, equipment purchased, leased circuits, etc.) as overhead or billable to a customer. This SHOULD be allowed to be overridden by select personnel.

36



EXP.011 The system SHOULD require that all expense items in EXP.010, above be associated to an order.

EXP.020 For expenses defined as billable to a customer in EXP.010, above, the system SHOULD allow for a markup percentage to be added to the item before it is billed. The system SHOULD calculate the billable amount based on this markup.

EXP.021 For expenses that are marked up in EXP.020, above, the system SHOULD keep the original expense amount and the marked-up billable amount separate for reporting purposes. The system SHOULD NOT overwrite the expense item with the marked-up value.

EXP.030 The system SHOULD allow for invoice items marked as billable to a customer to flow through to the invoice to the customer.

EXP.040 The system MUST allow ICN to reconcile vendor invoice item(s) to those invoiced to customers (i.e. either by uploading info from other systems or within the system). Note: This process should allow for notes to be made, overriding previous items not marked billable, etc.

EXP.050 The system SHOULD record the following information after a Revenue/Expense record is added, updated or removed:


AFE.010 The system MUST store the following data for an Authorization for Expenditure (AFE): 1. AFE # 2. Revision # 3. Indicate budgeted/unbudgeted 4. Sponsoring division 5. Funding source (A = Appropriation funded AFE, C = Capital Equipment Plan

AFE, NC = Non Capital Equipment Plan AFE, R = Revenue producing AFE, etc.) 6. Total approved 7. 10% or $5000 overage amount (whichever is less) 8. Year(s) savings or expenses for the project (i.e. year 0, 1, 2, 3, etc.) 9. Total of Revenue breakdown (i.e. pass-through, recurring, cost savings, etc.) 10. Total of Expense breakdown (i.e. capital costs, other costs, outside labor,

internal labor, recurring, etc.) 11. Indicate if there are inventory items to be used, or transfers from other sites 12. Net Gain/Loss for project 13. Purpose memo field 14. Background memo field 15. Alternative memo field 16. Financial memo field 17. Project risks memo field

AFE.020 The system MUST be able create an AFE (authorization for expenditures) if the Sales Order/Purchase Order amounts are above a specified limit (currently $5000).

AFE.030 The system MUST be able to associate an AFE to one or more of each of the following order types:

1. Sales Order 2. Purchase Order 3. Customer Request / Project 4. Network Order (build-out)

AFE.040 The system MUST allow for multiple (archive) versions of an AFE to be kept and viewed. Only the most recent version of an AFE will be considered active for editing, work flow and approval purposes.

AFE.050 The Revenue breakdown detail MUST include the items to be used for billing (from BILB.040).

AFE.060 The Expense breakdown detail MUST include the equipment (from EQUIP.010) or inventory items (INV.010) that will be used for the project whether purchased or from inventory.

AFE.070 The Expense breakdown detail MUST be able to be categorized and calculate totals into the following categories but not limited to:

1. Fixed Asset purchase detail by vendor/product 2. Fixed Asset product installation analysis 3. Additions or subtractions from vendor maintenance contracts 4. Existing warehouse inventory resources required 5. Existing network fixed asset resources required

37



AFE.080 The Expense breakdown detail MUST include up to the following but not limited to: 1. Product 2. Part # 3. Quoted price 4. List price 5. ICN price 6. Quantity 7. Applicable markup % (from order detail) 8. Continuing expenses for the specified equipment (i.e. maintenance in year 0, 1,

2, 3, etc.)

AFE.090 The Revenue breakdown detail MUST be able to be categorized and calculate totals into the following categories but not limited to:

1. Initial pass through revenue from customer 2. New service offered to customer detail 3. Cost savings from project

AFE.100 The Revenue breakdown detail MUST include up to the following but not limited to: 1. Service offered to customer 2. Customer of record 3. Customer End point locations 4. Billable item 5. Quantity 6. Continuing revenues for the project (i.e. year 0, 1, 2, 3, etc.)

AFE.110 The system SHOULD allow for documents to be attached to the AFE record (i.e. maps, OSP estimates, etc.)

AFE.120 The system MUST record the following information after a AFE record is added, updated or removed:


AFE.130 The system SHOULD record the following information after a AFE record is added, updated or removed:



3.6.12 Telephones



TEL.010 The system MUST store the following information for a Telephone Number record from PBX switches:

1. Switch/System data loaded from 2. Status (Spare, in-use or disconnected) 3. Phone types or Device combination 4. Station number 5. Pad/Pen address 6. IP Address if VoIP Phone 7. MAC Address if VoIP Phone 8. Class of Service (local, LD, international, idle, etc.) 9. Display name 10. Public Number 11. Call forwarding destination 12. 911 location information (including county-either fill in or auto-populate) 13. Cable pairs (i.e. House pairs - Riser Pairs)

TEL.020 The system MUST store the following information about each Telephone in Telephone number record:

1. Billing Account 2. Status (spare, disconnect, in-use)

TEL.030 The system MUST store the following information about Calling Cards in Telephone number record:

1. Card Number 2. Calling Card Type (e.g. MCI Calling card, Capitol Complex Calling card, etc.) 3. Name of Contact 4. Status (spare, disconnect, in-use)

38



TEL.040 The system MUST store the following information about telephony groups in Telephone number record:

1. Pick group 2. ACD group 3. ICM group 4. Hunt group

TEL.050 The system MUST allow for reporting of PBX data 1. Generate reports based on switch

TEL.060 The system MUST allow for reporting of voice mail data in Telephone number record: 1. Call Processing data 2. Call Processing Pathname 3. Call Processing Name 4. Call Processing Type 5. Switch Call Processing data loaded from 6. Number of times Call Processing box accessed 7. Call Processing User transfers 8. Call Processing Default Transfers 9. Auto-generate email to customer with Call Processing data 10. Class of service 11. Contact 12. Voice mail number 13. Voice mail node

TEL.061 The system SHOULD provide notification for outages of voice mail nodes.

TEL.070 The system MUST allow for two way provisioning between the compatible PBX switch(s) and the OSS (see BILA.103). The ICN would determine which changes are made from the OSS to the PBX, from the PBX to the OSS, and which are done by personnel.

TEL.080 The system MUST store the applicable Authorization codes for a phone number and encrypt or mask the Authorization codes so they do not print on the invoice to the customer in the Telephone number record.

TEL.090 The system MUST store the applicable Client/Access codes for a phone number in the Telephone number record.

TEL.100 The system SHOULD link to the Call Detail Records (CDR) history for each phone number to the Telephone record for viewing. These records may or may not be located within the OSS.

TEL.110 The system SHOULD allow for documents to be attached to the Telephone record (i.e. customer LOA, etc.).

TEL.115 The system MUST store toll free numbers and the local number (DNIS) or the trunk to which it points.

TEL.120 The system SHOULD be able to recognize the following from the ICN LD switch (currently a Nortel DMS):

1. Answer Supervision (indicates a connect call) 2. Completion Codes (busy, hang up, disconnected, etc).

TEL.130 The system MUST record the following information for a Telephone record upon each addition, update or removal:

1. User ID 2. Date/time 3. Action (add, edit, delete, etc.) 4. Order Number 5. Previous field/value (if applicable) 6. New field/value (if applicable)


39

3.6.13 Procurement



PRO.010 The system MUST store the following information for a Sales order: 1. Corresponding Order number 2. Corresponding Purchase Order number 3. Associated items to be used from inventory or purchased from vendors (from

INV.010) 4. Status of each item (e.g., On Order, Reserved, Shipped, etc.) 5. ICN part numbers to the Sales Order (i.e., from EQUIP.010 for chassis) 6. Associate Corresponding vendor part number and pricing 7. Associate Location as final destination for parts (from LOC.010) 8. Asset # 9. ICN part # 10. Part serial # 11. State IP tag # 12. Vendor part # 13. If AFE process is required 14. If AFE process approval has been completed and associated AFE number 15. If original estimated items vary from what is being ordered 16. Approver 17. Shipper and shipper's tracking number (provided by ICN)

PRO.011 The system MUST allow the user to add tasks (or a group of tasks) to accommodate the AFE process.

PRO.012 The system MUST allow for notifications to individual(s) for various actions or changes to the sales order or purchase order (Hold, Rejection, Cancel, etc.)

PRO.015 The system MUST store the following information for a Purchase order: 1. Corresponding Sales Order number(s) 2. Vendor name and info (phone, fax, contact, etc) (from VEND.010) 3. Vendor tax ID (from VEND.010) 4. Corresponding contract number and terms (net 30) 5. Associated items to be used from inventory or purchased from vendors (from

INV.010) 6. Associate Corresponding vendor part number and pricing 7. Specify if purchased with appropriation funds 8. Approver 9. Expected ship date/delivery date for purchase by part number 10. Shipper and shipper's tracking number (from the vendor) 11. General ledger code for expense 12. Notes - Date/Time/User Stamp permanent comments 13. Shipping FOB

PRO.017 The system MUST allow for items to have more than one part number assigned to it with one as the main part number.

PRO.020 The system MUST require a corresponding Order number before a purchase can be made.

PRO.025 The system SHOULD allow for ICN to place Sales/Purchase Orders on hold and to remove the hold.

PRO.026 The system MUST allow for ICN to reject Sales/Purchase Orders and note the reason for the rejection.

PRO.030 The system MUST allow items to be audited and marked as to whether they are accurate part numbers, in inventory, etc.

PRO.040 The system MUST allow for consolidation or separation of purchase orders based on the vendor, project, etc.

PRO.060 The system MUST allow select ICN personnel to override fields in order to correct for accuracy.

PRO.070 The system SHOULD allow for files to be attached to the SO/PO.

PRO.080 The system SHOULD allow for the PO to be sent electronically by email/fax to the vendor and track the date sent.

PRO.081 The system MUST allow for the PO to be printed.

PRO.090 The system MUST allow ICN to reserve and associate an Asset to a specific project or Order and allow for a reorder if this is overridden and transferred to another project or customer order.

PRO.100 The system MUST allow for automatic reorder of minimum levels of inventory as those levels are passed. (see INV.063 and INV.110)

40



PRO.105 The system MUST allow for multiple shippers to be printed for shipping Assets on a Sales Order and maintain a history of items already shipped.

PRO.110 The system MUST record the following information after a Procurement record is added, updated or removed:


PRO.120 The system SHOULD record the following information after a Procurement record is added, updated or removed:



3.6.14 Circuit Design



DES.005 Vendor MUST acknowledge that Vendor understands the ICN operates a telecommunications network that includes telephones (VoIP, digital, and analog), Frame Relay, ATM, IP, Ethernet, Private Line, etc., and that circuit designs must be able to represent physical and logical connections across the various technologies.

DES.006 Vendor MUST acknowledge that Vendor understands a main consideration for providing a circuit design is to provide implementation instructions to technicians for physical deployment and logical configuration.

DES.010 The system MUST store the following information about each Circuit Design: 1. Unique Circuit ID 2. Related Order 3. Designer/Engineer 4. Description/Notes - date/time/person stamp on the permanent update

DES.020 The system MUST be able to store and display multiple versions of designs; including historical (archived) designs, current designs, and pending designs, and designate them as such for the viewer.

DES.030 The system MUST allow ICN to associate any kind of network element to the circuit: 1. Cables 2. Ports/Slots 3. Channels (logical channels within a carrier Circuit) 4. Representation of Vendor network segments (e.g. Leased circuit) 5. Relay Rack

DES.031 The system MUST represent cross-references to Vendor circuits within the circuit design.

DES.040 The system MUST allow ICN to define various settings for ports and circuits, as determined by Equipment/Port/Slot settings. These will vary by segment, and include, but not be limited to:

1. VLAN id 2. VLAN name 3. VPI 4. VCI 5. DLCI 6. tagging 7. SONET DS-0, DS-1, DS-3, etc. 8. QoS (if specified) 9. IP Address 10. Policing (UPC)

DES.042 The system SHOULD flag the design if the A and Z locations do not match those of the associated Circuit.

DES.044 The system SHOULD automatically sequence an existing design, and flag the design if the design is incomplete.

DES.045 The system MUST provide a separate field/screen for the install specifications ("Work Order Detail") and implementation notes to be entered. This is to be date/time/user stamped.

DES.046 The system SHOULD maintain historical versions of the install specifications ("Work Order Detail").

41



DES.047 The system SHOULD automatically provide options and default selections for settings in DES.040, above, based on predefined rules for circuit types, equipment, and locations.

DES.048 The system SHOULD limit assignment to network elements, based on predefined rules on circuit types and equipment. (e.g. DS-0 cannot be directly provisioned to fiber.)

DES.049 The system SHOULD allow users to flag a circuit for follow-up with one or more reason(s) from a list including (but not limited to) the following:

1. Misrouted 2. Requires electrical diversity (e.g. dual power supplies, dual electrical feeds) 3. Requires equipment diversity (different transport/switching) 4. Requires geographical diversity 5. Outage

DES.050 The system SHOULD allow users to identify and relate circuits that provide diversity for a customer. This allows users to keep the circuits diverse as changes are made over time.

DES.055 The system SHOULD provide a graphical representation of a designed, or partially designed, circuit.

DES.060 The system MUST record the following information after a Circuit Design record is added, updated or removed:


DES.061 The system SHOULD record the following information after a Circuit Design record is added, updated or removed:



3.6.15 Order Management



ORD.001 The system MUST assign a unique identifier to the order for tracking.

ORD.005 The system SHOULD allow for a form to be displayed depending on the Service that is ordered to be used as a checklist for information needed to move the order forward. Each form may include and/or require specific fields of data for that Service.

ORD.006 Order SHOULD associate to the Customer that is placing the order (from CUST.010).

ORD.010 The system SHOULD allow ICN to put in an order as an Estimate and then be able to convert it into an actual Order to be worked and completed.

ORD.011 Order SHOULD associate to the Service(s) being requested (from SVC.010).

ORD.020 The system MUST allow ICN to track Customer inquiries related to an Order (e.g., phone calls/emails about the status of the order).

ORD.030 The system MUST allow access to appropriate orders and task assignments for external personnel as defined by ICN.

ORD.031 The system MUST provide the ability to identify/flag orders that are to be expedited. (requested to be completed in less time than the standard set for the requested service)

ORD.032 The system SHOULD allow authorized personnel (i.e., management, team leaders) to view the set of tasks and adjust priority settings within a defined scope of control.

ORD.040 The system SHOULD allow ICN to put in an Order/Project for planning purposes and then convert it into an actual Order to be worked and completed.

ORD.050 The system SHOULD allow additional documentation to be attached to the order as it progresses through the work flow process.

ORD.060 The system MUST allow for a notification when an order is initiated for an item on a existing current contract.

ORD.061 The system MUST track timing of orders through work flow and allow each section to add to the order (documents, notes, additional items, etc.) and allow for notifications if defined time frames are overdue to both the section assigned as a reminder/escalate mechanism and supervisors for reporting, etc.

42



ORD.062 The system SHOULD be able to access the associated billable items linked to a Service when picking that Service in the order/request. (See SVC.041)

ORD.070 The system MUST record the following information after an Order record is added, updated or removed:


ORD.075 The system MUST allow for the creation and tracking of a list of Tasks associated with the Order, including but not limited to:

1. Field/Design work 2. Permit applications 3. Dependencies on other activities (e.g., Contracting, Procurement) 4. Documentation of “as-builts”

ORD.076 The system MUST allow an area for notes to be place in the order, that are permanently a part of the record and are date/time/user stamped.

ORD.077 The system MUST provide templated work flow that can be customized for each Service: 1. Standard Tasks and Task Durations 2. Overall Standard Duration (for each Order Item) 3. Task Owners

ORD.080 The system SHOULD allow for modification of standard turn up intervals for a specific Order.

ORD.090 The system SHOULD store the following information about each Task: 1. Status (e.g., Not Started, In Progress, Completed, etc.) 2. Assignee (Workgroup, User) 3. Priority 4. Planned Start/Finish (dates) 5. Planned Work (hours) 6. Actual Start/Finish (dates) 7. Actual Work (hours)

ORD.095 The system SHOULD recalculate the projected completion date for an Order based on updates made to associated Task(s).


3.6.16 Inventory and Asset Management



INV.040 The system MUST allow tracking of the following in auditing of Equipment/Assets: 1. Date of audit 2. Status of the audit process 3. Person conducting the audit 4. Adjustments for physical count reconciliations

INV.050 The system MUST allow ICN to transfer an Asset(s) from one location to another including Vendor/Customer warehouse(s) (from LOC.010).

INV.051 The system MUST allow for cancellation of a pending transfer.

INV.061 The system MUST allow for manual or automatic initiation of workflow for replacement of an instance of Equipment/Asset reserved per EQUIP.080 that has been reassigned to another Project or Order.

INV.062 The system MUST allow for Equipment/Assets to be reserved for spares, i.e. for repair use only.

INV.063 Assets that are reserved MUST not be considered available for the auto-reorder threshold for that Equipment/Asset. (see PRO.100)

INV.100 The system MUST allow a view or link to all current and historical orders associated to the Asset including the original purchase of the Equipment/Asset.

43



INV.110 The system MUST provide for tracking and reporting on the following for each type of Equipment/Asset:

1. Count on hand 2. Count in reserve, by type of reservation (e.g. Project, spares, etc.) 3. Auto-reorder threshold (see PRO.100) 4. List of Assets by site/location

INV.120 The system MUST allow ICN to calculate and store accumulated depreciation for an Equipment/Asset, period dates of accumulated depreciation and the history of prior accumulated depreciation calculations.

INV.130 The system MUST allow ICN to calculate and store the current book value of an Equipment/Asset and the history of prior book value calculations.

INV.140 The system SHOULD identify changes made to an individual Equipment/Asset which would change the individual Asset's book value for accounting, and notify users when such changes are made.

INV.150 The system MUST record the following information after an Equipment/Asset record is added, updated or removed:



3.6.17 ITIL Processes



ITIL.010 The system MUST be able to store and access the following SLA/OLA/UC information:1. Related Service(s) (SVC.030) 2. Service Level Manager (CONT.010) 3. Customer contact for SLA (CONT.010) 4. Vendor contact for SLA (CONT.010) 5. Customers covered by SLA (CUST.010) 6. Vendor(s) providing service under the SLA (VEN.010) 7. Start and end dates 8. Renewal date 9. Hours when the service is available 10. Time within which a defined level of service must be re-established 11. Metrics for reports 12. Status of SLA/OLA/UC 13. Name of SLA/OLA/UC

Notes and definitions:Service Level Agreement (SLA) - an agreement between an IT service provider and a customer.

Operational Level Agreement (OLA) - an agreement between an IT service provider and another part of the same organization, governing the delivery of a infrastructure service.

Underpinning Contract (UC) – a contract between an IT service provider and an external provider of an infrastructure service.

As UCs are formal contracts with external suppliers they may contain references to general terms and conditions or an additional first section specifying commercial and legal details.

The following statements on Service Level Agreements are therefore equally applicable to OLAs and UCs, with one important point to consider: When agreeing an SLA the Service Level Manager acts as a provider of services to the business; he is in the role of a customer in the case of an OLA/ UC.

The Service Level Agreement extends the service definition from the Service Catalog, defining detailed service level targets, mutual responsibilities, and other requirements specific to a service provided for a certain (group of) customer(s). It focuses on the definition of requirements from a customer viewpoint. Reference: wiki.en.it-processmaps.com/index.php/ITIL_Processes

44

http://wiki.en.it-processmaps.com/index.php/ITIL_Processes

http://wiki.en.it-processmaps.com/index.php/ITIL_Processes



ITIL.015 The system SHOULD be able to store and report the following SLA/OLA/UC information: 1. SLA/OLA/UC violations per Customer (CUST.010), Vendor (VEN.010) and/or

Service (SVC.010) 2. Defined SLAs per Service 3. Services that are not covered by SLA's

ITIL.020 The System MUST be able to store and access the following information about Releases: 1. Unique identifier 2. Status 3. Manager of the Release (CONT.010) 4. Description 5. Notes or information about the Release as it is worked. 6. Target date 7. Completion date that can auto fill in based on the status 8. Related Change/RFC(s)

ITIL.025 The System SHOULD be able to store and report the following information about Releases:

1. Total number of Releases per time frame 2. Percent of Releases that are not completed by target date

ITIL.030 The System MUST be able to store and access the following RFC/Change information. 1. Unique identifier 2. Status 3. Requestor (CONT.010) 4. Coordinator (CONT.010) 5. Related Service (SVC.030) 6. Description 7. a running notes or information field for the Change 8. Category 9. Target date 10. Planned start date 11. Actual start date 12. Planned finish date 13. Actual finish date 14. Organization performing the change (CUST.010) 15. Related Order(s) that need to happen for the Change to be completed

(ORD.001) 16. Voting-based approval process for the Change 17. Expected impact of the Change 18. Reason for the Change

ITIL.035 The System SHOULD be able to store and access the following RFC/Change information 1. Automated updating of records upon successful completion of the Change. 2. Resource scheduling to check for potential conflicts and suggest next available

dates if a conflict exists. 3. Report on percent of Changes implemented on schedule 4. Report on percent of Changes that are backed out 5. Report on number of Incidents caused by an implemented Change 6. Report on total number of Changes by status over a period of time 7. Report on the number of Changes implemented by a workgroup 8. Report on the number of Changes requested by a CUST.010 9. Report on amount of time Change approval takes 10. Report on number of Changes not approved per time frame

45



ITIL.040 The System MUST be able to store and access the following Incident information 1. Unique identifier 2. User and Equipment-initiated Incidents 3. Related CI(s) (INV.010) 4. Status 5. Description 6. Running notes or information about the Incident as it is worked. 7. Related Service (SVC.010) 8. Related Customer/Contact (CONT.010) 9. Target date for resolution that can be auto set via relation Customer, Service and

SLA (CONT.010, SVC.010 and ITIL.010) 10. Completion date 11. Assigned Workgroup 12. Assigned Contact (CONT.010) within the Assigned Workgroup above 13. Vendor (VEN.010) that is supplying the service, if any 14. External (vendor) ticket number, if any 15. Solution/resolution 16. Related Incident(s), if any 17. Source of the Incident (equipment signal/SNMP, phone call, email, etc..) 18. Categorization for searchable knowledge base, if any 19. Incident category (change, resolution, improvement, etc.) 20. Severity (from a configurable list of options) 21. Email integration for opening or updating Incidents 22. Automatically send email to Customer/Contact, Vendor(s) and staff as status of

the Incident changes 23. Related Problem(s) (see ITIL.050). 24. Related Change/RFC(s) (see ITIL.030).

ITIL.041 The System SHOULD provide the ability to open or update Incidents via web interface.

ITIL.045 The System SHOULD be able to provide the following reports on Incident information for various time frames:

1. Average resolution time 2. Percent of Incidents per Customer/Contact (CONT.010) 3. Percent of Incidents per Workgroup 4. Percent of calls not resolved by target date 5. Total number of Incidents 6. Average duration of Incidents 7. Number of Incidents re-opened

ITIL.050 The System MUST be able to store and access the following Problem information: 1. Unique identifier 2. Related CI(s) (INV.010, EQUIP.010) 3. Status 4. Description 5. Notes or information about the Release as it is worked. 6. Related Service (SVC.010) 7. Assigned Workgroup 8. Assigned Contact (CONT.010) within the Assigned Workgroup above 9. Category (proactive, reactive, etc.) 10. Severity/Impact 11. Target date 12. Actual completion date 13. Vendor (VEN.010) that is supplying the service, if any 14. External (vendor) ticket number, if any 15. Solution 16. Related Incident(s) (see ITIL.040) 17. Related Change/RFC(s) (see ITIL.030)

ITIL.055 The System SHOULD be able to provide the following reports on Problem information for various time frames:

1. Number of Problems solved and unsolved 2. Number of Problems per Service (SVC.010) 3. Number of Problems per Customer/Contact (CUST.010) that supplies a Service 4. Average number of Incidents per Problem

ITIL.090 The Vendor MUST describe how the System will allow ICN to automate and enforce the integrity of its processes.

ITIL.100 The system MUST record the following information each time a modification is made to any ITIL-related information:


46



ITIL.110 The Vendor MUST state what ITIL version(s) and levels of compliance the system provides.


3.6.18 Accounts Receivable



AR.010 The system SHOULD display the following information for each Customer in a subsidiary ledger format (see BILL.109):

1. Customer name (from CUST.010) 2. Billing Contact & info (from CONT.010) 3. Mailing address (from LOC.010 if not brought in with CONT.010) 4. Associated billing account 5. Current outstanding balance total 6. A/R transactions for the Customer (see AR.020)

AR.011 The system SHOULD be able to allow ICN to decide at which hierarchical level the customer will be invoiced and an Accounts Receivable record is created.

AR.020 The system SHOULD store the following information for each A/R transaction: 1. A/R Transaction type (billing, payment, adjustment-with ability to modify this list) 2. Invoice number 3. Check/Payment tracking number 4. Date of transaction 5. Amount (must have the ability for credits) 6. Service dates 7. Notes/Memo

AR.021 The system SHOULD allow for historical A/R transactions to be stored.

AR.030 The system SHOULD allow the Notes/Memo field in AR.020 #7 to be permanent and ongoing with date stamp, user id of person adding the notes.

AR.040 The system SHOULD be able to drill down or show the details of the invoice (See BILI.033). An invoice A/R transaction is associated to zero or more billing items (see BILL.033)

AR.050 The system SHOULD validate the following information before posting a payment, and provide an alert or error if any validations fail:

1. Invoice number is active for payment 2. Invoice belongs to the specified customer

AR.060 The system SHOULD be able to post payments, adjustments, etc directly to a specified invoice number.

AR.080 The system SHOULD provide a mechanism for uploading a batch of A/R transactions into the system (including multiple transaction types and customers).

AR.090 The system SHOULD provide a mechanism for reconciling the batch of A/R transactions uploaded for errors, totals, verification, etc.

AR.100 The system SHOULD allow ICN to scan in payment remittances/checks and populate A/R transaction data fields from the scanned document. Note: This would NOT create an EFT transaction. The physical check would still be processed normally.

AR.110 The system SHOULD allow ICN to attach documents to an A/R transaction.

AR.120 The system SHOULD allow for other tracking/posting of cash received that does not correspond to an A/R Transaction (i.e. refunds from vendors, sale of disposed assets, employee reimbursements, etc.).

AR.130 The system SHOULD allow carrying a credit balance forward and applying it to the next invoice generated. Note: Currently, ICN must manually move the credit to the next invoice. This does not provide a good mechanism to show the credit and net total due for the customer.

AR.131 The system SHOULD send a customizable notification to customers when a credit balance is carried forward in AR.130, above.

AR.132 The system SHOULD allow the customer to view their account history via a web portal (i.e. history of payments, adjustments & invoices).

47



AR.140 The system SHOULD record the following information after an A/R record is added, updated or removed:



3.6.19 Billing



BILL.010 The system SHOULD allow ICN to invoice customers by billing account on a monthly cycle for the previous month's services.

BILL.011 The system SHOULD allow ICN to invoice a 13th period billing cycle by billing account for fiscal year end. The 13th period billing cycle is a billing cycle in addition to the regular 12 period billing cycles and allows ICN to bill any items that did not make it into the 12 regular billing cycles in order to finish up work, receive costs, pay vendors, etc. for fiscal year end. This would include the following but not limited to:

1. Calculate prorated billing charges/credits based on previous monthly recurring charges

2. Allow for various one time charges 3. Be similar in process to the other 12 monthly billing cycles

BILL.012 The system SHOULD allow ICN to invoice customers by billing account on a monthly cycle for the next month's services (ahead billing).

BILL.013 The system SHOULD allow the invoices and other reports (canned or special) to be available to customers via a web portal (pre-generated or on-demand), subject to access controls defined in SEC.020.

BILL.014 The system SHOULD allow the customer to make changes to billing information via a web portal including but not limited to:

1. Billing account I/3 coding 2. Billing account where a service is billed

BILL.015 The system SHOULD use ICN current billing account numbers as a base.(alphanumeric 12 digits with dash and 3 digit subaccount hierarchy ABC000000001-001). Note: ICN currently uses 2 levels of hierarchy.

BILL.016 The system SHOULD allow the following for customer invoices: Flexible reports to make up the invoice based on a service (from SVC.020) with different criteria for each service

1. Grouping and sub-totaling by each hierarchy level and each service object code 2. Flexible reports to make up the invoice based on different customer criteria (i.e.

I/3 invoice) 3. Suppression of blank pages or pages for services that do not apply to a given

customer. 4. Report layouts that can be customized by ICN staff

BILL.017 The system SHOULD allow email notifications of invoice availability with modifiable message.

BILL.018 The system SHOULD allow customer invoices to be related to services. (from SVC.020)

BILL.019 The system SHOULD record the following information after a Billing record is added, updated or removed:


48



BILL.020 The system SHOULD be able to collect Call Detail Records (CDR) directly from at least the following types of Switches/Pollcats, and rate the record based on specified criteria for billing to the customer (dialing plans) - see BILL.029:

1. Rolm 102. Rolm 303. Rolm 504. Rolm 705. Siemens 806. Siemens 30007. Siemens 4000 8. DMS 500 9. PollCat III10. NetLink II

BILL.021 The system SHOULD be able to accommodate for translations for each switch if necessary to convert CDR extension digits (3-6 digits) to a 10 digit format.

BILL.022 The system SHOULD allow a view or link of rated CDRs via the Telephone number record.

BILL.023 The system SHOULD allow for an error/mismatch process for Call Detail Records that cannot be rated (i.e. inactive phone, no dialing plan, etc.).

BILL.025 The system SHOULD allow ICN to resolve mismatches/errors identified in BILL.023, preferably before the call is rated.

BILL.026 The system SHOULD allow rated CDRs to bill to the appropriate billing account and allow for changes to the account the Telephone number record is billed to and not lose the rated CDRs (i.e. calls either stay on old account or move to new account when changed).

BILL.027 The system SHOULD provide error/logging reports/notifications of problems with CDRs from switches being collected, rated, changes, etc.

BILL.028 The system SHOULD allow a cutoff of CDR rating for billing cycle closes and the 13th billing period.

BILL.029 The system SHOULD allow for segregation of different call types from the CDR for different rates and descriptions for invoicing, up to the following but not limited to (see BILL.020):

1. International 2. Interstate 3. Intrastate 4. Pass-through 5. Pass-through plus markup 6. Payphone 800 7. Interstate 800 (based on the location of the from #) 8. International 800 (based on the location of the from #) 9. Interstate directory assistance (based on the location of the from #) 10. International directory assistance (based on the location of the from #) 11. Conference call (ip, voice, web, etc) 12. 911 county location 13. Authorization code 14. Client/access code

BILL.030 The system SHOULD allow ICN to run trial billing cycles at anytime between final billing cycles.

BILL.031 The system SHOULD allow ICN to run trial invoices for customers from trial billing cycle close information.

BILL.032 The system SHOULD allow ICN to run final billing cycle close at any time during the month to accommodate for timing of closes for fiscal year end and the 13th period close (see BILL.038).

BILL.035 The system SHOULD allow reports to be run on invoiced data (see BILL.013).

BILL.037 The system SHOULD allow invoices to be recreated or reprinted if necessary.

BILL.038 The system SHOULD be able to provide a process for a final billing cycle close (BILL.032), invoice/report creation (BILL.013) and availability to the customer through the web portal within a maximum of 5 business days.

BILL.039 The system SHOULD be able to provide for special calculations for invoicing, including but not limited to:

1. Discounts by Service 2. Discounts by Billing Account (each hierarchical level) 3. USF contribution fees by Service 4. Late payment/overdue balance fees based on balance due by Billing Account

(each hierarchical level) 5. 911 county location fees by phone number

49



BILL.040 The system SHOULD provide for the following but not limited to when invoicing the customer (see AR.011):

1. Set up billable items tied back to a service (see SVC.041) 2. Ability to designate I3 coding for each hierarchical level of billing accounts 3. Different invoice views for the customer to pick via the web portal 4. Define the hierarchical level the customer is invoiced (may want to have an level

that ties the sub accounts together but calculates invoices, mailing address, AR record at sub account level)

BILL.041 The system SHOULD be able to store and provide up to the following but not limited to for billable items:

1. Assign I/3 Object Code (4 digit) 2. Assign General Ledger Code (5 digit) 3. More than one hierarchical level (to tie old pricing structures to new ones) 4. Group billable items to multiple services (i.e. Port charges for different services) 5. Group multiple services to one billable item (i.e. Bundled pricing)

BILL.042 The system SHOULD allow billable items to be associated to Service records for invoicing.

BILL.043 The system SHOULD allow for billable items to be associated to a Circuit record for invoicing.

BILL.044 The system SHOULD allow for billable items to be associated to a Telephone number record for invoicing.

BILL.045 The system SHOULD allow ICN to choose when adding billable items and services to an Order to bill the items or Service on an annual, quarterly, or (by default) a monthly basis. The system SHOULD flag all annual and quarterly billable items or Service for follow-up at the end of the billable time frame.

BILL.046 The system SHOULD allow for a expiration/alert to be set on service records or the billable items attached to them for discounts or special pricing that is only good for a certain time frame, or as part of a Contract.

BILL.047 The system SHOULD be able to split the billable items on a service record between 2 or more accounts at a set percentage.

BILL.048 The system SHOULD allow for an import of a .txt file of video usage from VOSS system (ICN's proprietary video scheduling system) which includes the fields detailed in BILL.049.

BILL.049 The system SHOULD be able to store at least the following fields from the .txt video usage file (for preliminary invoicing processes and for historical reference):

1. Class Number1 2. Class Number2 3. Authorization Code 4. Expected Start Time 5. Expected End Time 6. Reservation Number 7. Class Name 8. Class Day 9. Actual Start Time 10. Actual End Time 11. Scheduler Region 12. Scheduler Name 13. Site Number 14. Site City 15. Site Name 16. Site Originator

BILL.050 The system SHOULD be able to store and associate video authorization codes to a billing account.

BILL.051 The system SHOULD be able to calculate and invoice video usage on the following criteria (from BILL.049):

1. Per session (i.e. Class #) 2. Per session type (i.e. Training, k12) -hourly billing rate based on session type 3. Per hour 4. Per site (i.e. Originator billed for all participating sites) 5. Per video authorization code 6. Per billing account 7. Per entity number

50



BILL.052 The system SHOULD be able to provide the following but not limited to for video billing: 1. Choose different invoice views/reports based on services 2. Choose different invoice views/reports based on customer type 3. Group and total video usage by each hierarchial level of billing account (included

in invoicing to customer) 4. Group and total video usage by each session (class #) (included in invoicing to

customer) 5. Calculate and apply discounts or subsidies by each session type (included in

invoicing to customer)

BILL.053 The system SHOULD provide the details from BILL.051 and BILL.052 in a report to be included in the invoicing to the customer.

BILL.054 The system SHOULD provide a listing of sites for each session from BILL.051 and BILL.052 in a report to be included in the invoicing to the customer.

BILL.055 The system SHOULD provide a means to flag and correct items prior to billing cycle close when the items are missing various billing elements (i.e.. I/3 code, auth code, session type, entity number, etc.) when comparing the data stored in OSS and data imported from the .txt file (from BILL.049). ICN personnel should be able to correct fields in the OSS to resolve issues for the pending invoice in the current billing cycle.

BILL.056 The system SHOULD include a summary report that groups video hours by regional scheduler (from BILL.049).

BILL.057 The system SHOULD include reports to easily be run for billed video usage history by different criteria (from BILL.049)

BILL.058 The system SHOULD allow billing of a session to be split between session types based on eligibility of the site in the session (i.e. a hi-ed site cannot be billed at a k12 session rate-site ineligible for rate but rest of sites are eligible.).

BILL.090 The system SHOULD be able to take CDRs from certain call trunks (dialable wide band video) and rate those calls based on the following but not limited to:

1. Per session 2. Per channel 3. Per minute 4. Per dialed digits (on-net/off-net, origination/destination/psuedo #) 5. Flat one time fee per conference (mcu conference fee) 6. Per site 7. Per originator

BILL.091 The system SHOULD be able to bill a per minute per channel rate based on whether the call is to an on-net or off-net site. The system SHOULD be able to group these charges on a per site or per originator basis.

BILL.092 The system SHOULD be able to import and store at least the following fields from the IP billing .txt file (for preliminary invoicing processes and for historical reference):

1. Conference name 2. Participant name 3. Io type 4. Transport 5. Destination address ip 6. Source address ip 7. Connect date 8. Connect time 9. Disconnect date 10. Disconnect time

BILL.093 The system SHOULD be able to calculate and invoice IP billing from a .txt file (from Zyross, the ICN's IP video/audio call collection software) based on, but not limited to, the following:

1. Duration in minutes (i.e. Current rates bill in 1/2 hour increments) 2. Per conference 3. Per participant

BILL.094 The system SHOULD be able to include detail from the IP billing .txt file, see BILL.092 & BILL.093, on the invoicing to the customer (i.e. conference name, participant name, destination and source IP addresses, etc.).

BILL.100 The system SHOULD allow ICN to store and delay rating of calls for at least 30 days of CDRs and at least 20 Mb per day. These are current levels, which may be expanded by the ICN in the future. This allows for ICN to address switch issues and to bill for Period 13.

BILL.101 The system SHOULD have the ability for more than 2 hierarchical levels of billing accounts. (see CUST.020)

51



BILL.102 The system SHOULD be able to accommodate upload and rating of CDRs from an outside source (i.e. calling cards, conferencing services, LD vendors, etc).

BILL.104 The system SHOULD be able to accommodate upload of data, fields and billing of services either by being able to modify the file to conform to current billable items (CDRs) or by using billable items for the rates and descriptions and attaching to service records or by using the file detail to insert into the invoice to the customer from an outside source.It SHOULD include, but not be limited to, the following types of files:

1. ASCII 2. Excel 3. .txt 4. Verizon BillManager software

BILL.105 The system SHOULD allow billing accounts to merged and globally changed throughout the system to a new account or an existing billing account.

BILL.106 The system SHOULD be able to create an .xml file for the I/3 upload for payment of I/3 invoices and reports related to this process (i.e. summary, documents, etc.).

BILL.107 The system SHOULD be able to store various billing rates associated to billable items and services for the purpose calculations of services invoiced to customers. The billing rates SHOULD be modifiable by select ICN personnel.

BILL.108 The system SHOULD provide notification of invoice availability, payment schedule, and I/3 payment errors to appropriate users.

BILL.109 The system SHOULD provide reporting/tracking/balancing of trial billing cycles and final billing cycles.

BILL.110 The system SHOULD provide reporting/tracking/balancing of the CDRs and the rated CDRs.

BILL.111 The system SHOULD provide a detailed report of all charges by billable item, account, general ledger codes, object code, etc.

BILL.112 The system SHOULD allow reports for certain checks on required items prior to a final close being able to be completed (i.e. object codes, general ledger codes, other errors, etc.)

BILL.113 The system SHOULD provide reporting/tracking/balancing of the video usage text file to the billing result for each trial close.

BILL.114 The system SHOULD provide various reports on video usage, including but not limited to: 1. Site detail stats 2. Usage by customer category


3.6.20 Accounts Payable (A/P)



AP.010 The system SHOULD allow for the entry and storing of vendor invoices including the following data:

1. Vendor Name & info (from CUST.010 & CONT.010) 2. Vendor billing account number 3. Vendor invoice number 4. Invoice date 5. Service dates for the invoice

52



AP.020 The system SHOULD allow for the entry and storing of the following data for each invoice: 1. Item or circuit being billed (has to be active circuit) 2. Account type for each item 3. Expense/GL account, sub-account and object code for each item (5 digits, 15

digits, and 4 digits) - ties to #2 4. Amount(s) charged/credited for each item - SHOULD allow for multiple amounts

to one item 5. Comment for each item 6. True up Start and End dates for prorated charges for each item (if proration

chosen, dates are required) 7. Date invoice received 8. Date verified/released for payment 9. Person who verified/released for payment 10. Associated ICN order number(s) when applicable (i.e. purchase order, sales

order, customer/network order) 11. vendor contract number 12. ICN contract number

AP.021 The system SHOULD allow ICN to choose the invoices to be batched for transfer to GL (Microsoft Dynamics SL).

AP.022 The system SHOULD auto generate a batch number for each group of invoices defined in AP.021.

AP.023 The system SHOULD be able to link and transfer data from OSS to Microsoft Dynamics SL and from Microsoft Dynamics SL to OSS at various junctions in the AP process with reportable, trackable and unique identifiers that tie the data from one system to the other and vice versa.

AP.030 The system SHOULD keep and store the following data for each invoice paid: 1. Date transferred to Microsoft Dynamics SL 2. Transfer batch number

AP.031 The system SHOULD keep the history of vendor transfers to Microsoft Dynamics SL (see AP.021) and invoice details and allow access to previous invoice payment information (i.e. by item, BAN, invoice number, vendor, etc.).

AP.040 The system SHOULD not allow invoices to be modified or deleted after they are marked as verified/released for payment, except by select personnel. Note: Many people will be able to modify invoices before this point.

AP.041 The system SHOULD allow ICN to carry forward data from one month's invoice to the next month's invoice. The data carried forward SHOULD be able to be modified.

AP.042 The system SHOULD allow ICN to scan in invoices and populate/update invoice data fields from the scanned document (i.e., OCR).

AP.043 The system SHOULD allow ICN to attach multiple documents to an invoice record (i.e. the invoice, technician sheet, trouble tickets, CSR, etc.).

AP.044 The system MUST allow Vendor Customer Service Record (CSR) to be stored with each item:

1. USOC (Uniform Service Order Code) 2. Charge 3. Service established date 4. Service disconnected date 5. Service "a" location address 6. Service "z" location address 7. Vendor contract number

Note: CSR is by billing account number broken out into each phone, circuit or service. So info needs to be by item but can be entered/updated by BAN.

AP.045 The system SHOULD allow ICN to import multiple Vendor's tariff information including USOC(s).

AP.046 The system SHOULD allow ICN to scan in the Vendor tariff information and populate/update information fields from scanned document (i.e., OCR).

AP.047 The system MUST allow for a comparison between the Vendor CSR info and the Vendor invoiced info and denote discrepancies to be resolved prior to verification/release for payment (i.e. errors created with a difference in amount, disconnect date, USOC code, etc.).

AP.048 The system SHOULD allow for tracking, clearing and storing the resolution of discrepancies noted in AP.047, above.

AP.050 The system SHOULD allow ICN to scan in the Vendor CSR information and populate/update information fields from scanned document.

53



AP.060 The system SHOULD allow for a comparison between the Vendor tariff/contract info and the Vendor invoiced info and denote discrepancies to be resolved prior to verification/release for payment (i.e. errors created with a difference in amount, disconnect date, USOC code, etc.).

AP.065 The system SHOULD allow for tracking, clearing and storing the resolution of discrepancies noted in AP.060, above.

AP.070 The system SHOULD allow for the import of Vender Call Detail Record (CDR) information for billing to the customer.

AP.080 The system MUST be able to provide a report of payment history of each circuit by vendor invoice.

AP.090 The system MUST be able to allow a link between active circuit records and payments to prevent payment on inactive circuits (see DES.020).

AP.100 The system MUST be able to import invoiced items for circuits on the revenues and expenses for reconciliation (i.e. reports to be dumped or actually reconciled in system).


3.6.21 USAC Administration



USAC.010 The system SHOULD be able to store the following data for a USAC record from the upload/import of the pipe delimited RSP (RAL-471) file:

1. SPIN (service provider identification number) 2. Fund year start date 3. Fund year end date 4. FRN (funding request number) 5. 471 Application # 6. 470 Application # 7. Applicant name 8. Applicant address 9. Applicant phone # 10. Contact name 11. Contact address 12. Contact phone number 13. Service ordered 14. Fund Commitment pre-discount annual cost 15. Discount percentage 16. Entity # 17. Contract # 18. Billing acct # 19. Allowable contract date 20. Contract award date 21. Service start date 22. Contract expiration date 23. Funding commitment request amount

54



USAC.011 The system SHOULD be able to store the following data new or changed for a USAC record from the upload/import of the pipe delimited FSP (FCDL) file:

1. SPIN (service provider identification number) 2. Funding year 3. Fund year start date 4. Fund year end date 5. 471 Application # 6. Applicant name 7. Applicant address 8. Contact name 9. Contact preferred mode 10. Contact address 11. Contact fax # 12. Contact phone number 13. Contact email address 14. FRN (funding request number) 15. 470 Application # 16. FRN Funding Commitment status 17. Contract # 18. Service description 19. Service shared 20. Billed Entity # 21. NCES code 22. Earliest possible effective date of discount 23. Contract expiration date 24. Estimated total annual prediscount cost 25. Discount percentage approved by SLD 26. FRN actual committed amount 27. FRN reason description 28. Technology plan status 29. Report date 30. Wave # 31. Applicant's entity # 32. FRN's billing acct # 33. Associated 470's allowable contract date 34. Contract award date 35. Total estimated monthly recurring charges 36. Ineligible portion of total estimated monthly recurring charges 37. Number of month recurring service provided in a program year 38. Annual prediscount amount for eligible recurring services 39. Annual non-recurring charges 40. Ineligible portion of annual nonrecurring charges 41. Annual eligible prediscount amount for nonrecurring charges 42. Funding commitment decision explanation 43. Applicant letter date 44. Applicant address 45. Contract address

55



USAC.012 The system SHOULD be able to store the following data for a USAC record from the upload/import of the pipe delimited RFC (revised FCDL) file: Service provider name

1. SPIN 2. Funding year 3. Name of Billed entity 4. Billed entity address 5. Billed entity # 6. Name of contact person 7. Preferred mode of contact 8. Contact address 9. Contact fax # 10. Contact phone # 11. Contact email address 12. 471 Application # 13. FRN 14. Funding status 15. Category of Service 16. 470 Application # 17. Contract # 18. Billing acct # 19. Service start date 20. Contract expiration date 21. Number of months recurring service provided in funding year 22. Annual prediscount amount for eligible recurring charges 23. Annual prediscount amount for eligible nonrecurring charges 24. Prediscount amount 25. Applicant's discount percentage approved by SLD 26. Funding commitment decision 27. FRN reason description 28. Funding commitment decision explanation 29. Applicant revised FCDL letter date 30. Appeal Wave # 31. Last allowable date for delivery and installation for nonrecurring services

USAC.013 The system SHOULD be able to store the following data for a USAC record from the upload/import of the pipe delimited 486 file:

1. SPIN 2. FRN 3. 471 Application # 4. 470 Application # 5. Applicant name 6. Contact name 7. Contact preferred mode 8. Contact address 9. Contact fax # 10. Contact phone # 11. Contact email address 12. FRN Funding commitment status 13. Contract # 14. Service description 15. Service shared 16. Billed entity # 17. Entity name 18. Service actual start date 19. Contract expiration date 20. Fund commitment extended cost amount 21. Discount percentage approved by SLD 22. FRN actual committed amount 23. Retro payment indicator 24. FRN cancel indicator 25. Report date 26. Billing account number 27. Fund year 28. Fund year start date 29. Fund year end date 30. Service start date change indicator 31. Service start date change explanation 32. Funding commitment change indicator

56



USAC.014 The system SHOULD be able to store the following data for a USAC record from the upload/import of the pipe delimited ISR file:

1. SPIN 2. Invoice number 3. SLD Invoice number 4. SLD line item 5. Applicant 471 # 6. FRN 7. Requested amount 8. Status 9. Reason 10. Invoice report date 11. Invoice type

USAC.020 The system SHOULD be able to calculate and apply USAC discounts on the customer invoice by one or any combination of the following:

1. Service type 2. Billable item 3. Hierarchical billing account level

Note: Ideally, we would like it on the billable item level so that it appears on the invoice as [service record]-[applicable USAC discount]=[net service record amount billed] Currently we use tax tables to compute this.

USAC.021 The system SHOULD be able to apply the discount amounts against the FRN and funding commitment amount each month with a running balance of remaining funds for each FRN.

USAC.022 The system SHOULD be able to recognize when a discount starts and ends by the approval (486 file) date, remaining funds, end of funding year, etc.

USAC.023 The system SHOULD be able to track, balance and mark reimbursements from USAC (ISR file) as received by ICN for each discount invoiced to USAC by FRN number.

USAC.024 The system SHOULD alert and track any discrepancies, remaining balances or funds not received by ICN from USAC (ISR file) for discounts invoiced to USAC by FRN number.

USAC.025 The system SHOULD be able to pull out discounted amounts for invoicing to USAC for reimbursement.

USAC.026 The system SHOULD be able to provide a mechanism for reconciliation of the discounts invoiced (to the Customer), the invoice to USAC, USAC funds received, etc.

USAC.027 The system SHOULD be able to provide a mechanism to alert ICN to funding commitment amounts nearing a designated threshold.

USAC.028 The system SHOULD allow ICN to assign different GL codes to discounted amounts based on Service discounted for tracking.

USAC.029 The system SHOULD allow multiple FRNs for a Customer to be grouped into hierarchy levels (i.e. multiple FRNs for same Customer & same Service-one used up then use the next FRN).

USAC.030 The system SHOULD allow FRNs to be put on hold until needed (i.e. multiple FRNs may be approved for the same Customer and Service - one should be used at a time).

USAC.031 The system SHOULD allow a mechanism for ICN to set different percentage amounts based on the discount percentage approved by SLD (see USAC.013, USAC.029) to be applied to each eligible Service billed for each FRN.

USAC.032 The system SHOULD be able to track the relationships of the FRN, discount percentage, Service type and billing account numbers.

USAC.033 The system SHOULD be able to apply discounts to one time charges if the FRN allows for one time charges and track, balance and calculate remaining one time approved amounts per FRN.

USAC.034 The system SHOULD show the corresponding Customer name for each billing account, FRN, and entity number on the USAC record.

USAC.035 The system SHOULD be able to recognize the remaining balance on an FRN and limit any discounts given to that balance (i.e., only give what is left & not allow system to discount over the remaining balance).

USAC.036 The system SHOULD be able to assign multiple billing accounts to an FRN.

USAC.037 The system SHOULD be able to assign multiple FRNs to a billing account.

USAC.038 The system SHOULD provide a mechanism for ICN to designate an FRN as discounts received on invoice or through a BEAR form.

57



USAC.039 The system SHOULD provide tracking, alerts, and comments to Customers and ICN staff on USAC records marked as receiving discounts by a BEAR form.

USAC.040 The system SHOULD be able to provide invoicing by entity number for discounted services (see BILL.109).

USAC.041 The system SHOULD be able to invoice video by entity number (see BILL.051).

USAC.042 The system SHOULD be able to show the history of discounts, USAC records, etc.

USAC.050 The system SHOULD record the following information after a USAC record is added, updated or removed:



3.6.22 System, Platform and Network



SYS.010 The proposed solution SHOULD integrate with any or all of the following for account management:

1. Enterprise A&A Web Service2. Active Directory 3. Active Directory Application Mode (ADAM) aka LDS 4. LDAP v3 with/without SSL

SYS.020 The proposed solution MUST allow for the encryption of all sensitive traffic between the client and server. Consistent with the State's operating environment, vendors MUST indicate if the proposed solution is compatible with SSL provided by a reverse proxy, and not by the HTTP or application server. Systems SHOULD NOT rely on the “Host:” header passed to them, as translation of this value can occur at the reverse proxy layer. Systems SHOULD be able to function in a NAT environment, where physical IP addresses are not provided.

SYS.030 The proposed system SHOULD support a peak load of no fewer than 100 concurrent user sessions and 25 requests per second. At the peak load specified above, the system will complete 95 percent of all requests within 5 seconds and 100 percent of all requests within 15 seconds. The Vendor MUST identify any specific transactions that will not adhere to these performance goals and indicate why.

SYS.040 The system MUST provide a variety of standard reports and the ability to create ad hoc reports.

SYS.041 The proposed solution SHOULD be capable of providing data for third-party reporting tools such as (but not limited to):

1. Microsoft SQL Server Reporting Services 2. Business Objects 3. Cognos 4. Actuate 5. Oracle Reports 6. Other (please specify)

SYS.042 Vendors SHOULD provide brief descriptions of one or two previous implementations of reporting tools identified in SYS.041, above.

SYS.044 The set of information available to each user via reporting in SYS.040, above, MUST be limited by access controls for each user as defined in SEC.010, SEC.020 and SEC.021.

SYS.045 Vendor MUST provide field definitions for reporting in SYS.040 or cover this in SYS.066.

SYS.050 Vendor MUST describe the extent to which existing ICN data sources can be migrated to the System, the process involved, and how data migration costs are estimated.

SYS.060 Vendors MUST indicate which of the following server environments (and specific versions) the proposed solution will run on:

1. Windows Server 2. Linux 3. Solaris 4. HPUX 5. Other (please specify)

58



SYS.061 The proposed solution will need to be capable of running in a virtualized environment. Vendors MUST indicate which components of the proposed solutions CAN and CANNOT be virtualized.

SYS.062 The system will need to support a wide variety of governmental, organizational and private users. Vendors MUST indicate which of the following platforms/browsers the proposed solution supports:

1. Internet Explorer 6, 7, 8 2. Firefox 2, 3 3. Safari 2, 3 4. RIM Blackberry 5. Apple iPhone 6. Windows Mobile 7. Windows XP 8. Windows Vista 9. Windows 7 10. Fat client 11. Other (please specify)

SYS.063 Vendors MUST indicate how quickly they support new versions/patches/security updates to software needed to run their solution. (Including but not limited to major/minor):

1. Browser versions 2. Workstation OS versions 3. Server OS versions 4. Database versions 5. Workstation/Server security patches

SYS.065 Vendors MUST indicate which of the following databases (and specific versions) can be used to store the system's data:

1. Oracle 2. IBM DB2 3. MS SQL Server 4. MySQL 5. PostgreSQL 6. Other (please specify)

SYS.066 Vendors SHOULD provide detailed database schema/dictionary information, including tables, relationships, columns, data types and lengths.

SYS.070 Vendors MUST provide information on the architecture of the proposed solution. Such information should include, but not be limited to, the third-party vendors and components to be used; as well as any proprietary or customized components, and the roles fulfilled by each component. Vendors MUST indicate the networking configuration required (ports, protocols, etc.) between any components that require or allow for distributed computing.

SYS.075 Vendors MUST provide detailed workstation and browser hardware and software requirements for the proposed solution.

SYS.080 Vendors MUST identify a minimum hardware set and (optionally) a preferred hardware set for deploying and operating the proposed solution. The proposed hardware will be used as a baseline for comparison with existing ICN infrastructure (including virtual servers) and may or may not be accepted as part of the solution. Vendors SHOULD indicate any component(s) of the recommended hardware that may not be substituted for existing ICN infrastructure. The proposed hardware MUST allow the system to meet or exceed the minimum peak performance and scalability goals defined in SYS.030, above. The estimated costs for hardware MUST be separate and itemized in the Cost Proposal.

SYS.090 Vendors MUST identify all software associated with the operation of the system, including all third-party software that the State must acquire to deploy and operate the proposed solution. This SHOULD include, but not be limited to, operating system, DBMS or application server licenses, client software, drivers, adapters and converters, copyrighted media, logos or images, client access licenses, etc. Software costs MUST be separate and itemized in the Cost Proposal.

SYS.100 Vendors MUST identify supported methods of integrating with the proposed solution including, but not limited to the following:

1. SOAP/POX/REST 2. Direct database access (shared tables, through ODBC, JDBC, other) 3. File Transfer (Upload/Download), including specified format(s) (XML, CSV, etc.) 4. Message-Oriented, e.g., JMS, MSMQ 5. CORBA/RMI/DCOM, etc. 6. Other (please specify)

SYS.110 For each functional area of the proposed solution, vendors SHOULD indicate which interface methods (identified in SYS.100, above) are available, which have been used by other customers, and which have supporting documentation, examples, or runtime components are available to aid integration efforts.

59



SYS.120 For each functional area of the proposed solution, vendors SHOULD indicate which interface methods (identified in SYS.100, above) can be scheduled to run, providing automated data import and/export.

SYS.130 The system MUST use one or more specific TCP/UDP ports for IP communications with the software to aid in easily passing the traffic across firewalls.

SYS.140 The system MUST be capable of providing 99.9% availability per month, measured 24x7, not including scheduled maintenance windows. Vendors MUST provide detailed information on existing implementation(s) that meet or exceed this goal in production.

SYS.145 The system MUST be capable of a Disaster Recovery interval of <interval>. Vendors MUST provide detailed information on existing implementation(s) that meet or exceed this goal in production.

SYS.150 The system SHOULD support live backups of all data that is required to restore the system in case of failure.

SYS.160 The system SHOULD allow for remote monitoring of all vital system components.

SYS.170 The system SHOULD be able to run from multiple physical locations, either concurrently or as part of disaster recovery.

SYS.180 The system SHOULD provide online operating documents and help.

SYS.190 The Vendor MUST list out of the box integrations that the system will support with other products.

SYS.200 The system SHOULD allow users to report time spent on various assigned tasks related to Orders/Task, Incidents, Problems, Service Requests, Change/RFC(s), Vacation/Sick, Holiday, etc.


3.6.23 Security and Usability



SEC.010 The system MUST utilize role-based security requiring each user to register and log into the system using a unique user name and password.

SEC.015 The system MUST allow for the association of a user account (from SYS.010) to a Contact record in the system (see CONT.010)

SEC.020 The system MUST provide access controls based on Organization and/or Role memberships of a given account (Contact record) from SEC.010.

SEC.021 The system SHOULD allow for "working hours" restrictions in the access controls identified in SEC.020, above.

SEC.022 The system MUST allow for access control to be applied at the page, area, or field level, providing certain accounts or groups with read only, read/write, or no access to information.

SEC.030 The system SHOULD be able to automatically synchronize Microsoft Outlook calendars per user account for items such as scheduled Changes, out of office time, holidays, etc.

SEC.035 The system SHOULD be able to manage resource availability and loading.

SEC.040 The system SHOULD propagate all data updates immediately to related entities in the database (e.g., an old phone number for a contact should not be used for display and reporting after an update has been made). Vendors MUST indicate any areas of the system where such delays will occur.

SEC.050 The system SHOULD treat all text fields, query and report names, etc. as case-insensitive. The vendor MUST identify any functional areas where the system will impose case-sensitive handling of text.

SEC.055 The System SHOULD provide spell checking functionality in areas where text can be manually entered by a user.

SEC.060 The System SHOULD provide for pattern-matching in search functions (e.g., name, address, notes fields)

SEC.065 The System SHOULD allow for multiple search criteria to be used in search functions.

SEC.066 Vendors MUST identify types of data that cannot be searched using methods in SEC.060 and SEC.065.

60



SEC.070 The proposed solution is intended be compliant with Section 508 of the U.S. Rehabilitation Act of 1973, as amended (29 U.S.C. 794d) to remove barriers for persons with disabilities. Vendors MUST identify if and how the proposed solution complies with or goes further than Section 508 in making the application accessible to persons with disabilities.

SEC.075 The System SHOULD allow for export of displayed data to common spreadsheet, word processing, and database formats. Vendors SHOULD indicate which functional areas support which types of export.

SEC.080 The System SHOULD allow users and administrators to customize the set of information that is available on various pages. This includes the layout of data as well as standard or automatic filtering and sorting to be applied.

SEC.085 Vendors MUST list areas of the system that cannot be modified by ICN administrators.

SEC.090 The System SHOULD provide each user with a "dashboard" or "work basket" of items that are assigned to or need that user's attention.

SEC.100 The System SHOULD allow authorized customers to access real-time or snapshot usage data (Long Distance, Circuit Status, etc.)


3.6.24 Project Planning, Management, Change Control



PROJ.010 Vendors MUST include a detailed project plan for delivery of all required elements of the proposed solution. The plan should address, at a minimum, the following elements:

1. Project management, quality assurance (process audit), peer review, and management oversight

2. Development of requirements, designs, reports, and screen definitions, 3. Customization or development of the database, web services or integration

points 4. Solution development, including coding and unit testing 5. Configuration management and build activities 6. Data Mapping, Migration and Integration activities 7. Deployment planning, execution and validation activities 8. Knowledge transfer, including operations and support documentation

development and training of ICN staff 9. Test planning and test script development 10. Test execution and review of results 11. Proposed customer approval points / milestones for signoff and payments12. Estimated effort, resource allocation and time line for completion. 13. Dependencies and priorities between planned tasks

In addition, vendors may provide an estimated contingency time line and costs for any change requests, based on previous project experience (if applicable). This estimate should be separate and itemized in the Cost Proposal.

PROJ.020 Vendors MUST include project plan elements in PROJ.010, above, for planning of the pre-production and production environments in conjunction with ICN, and for time to be spent executing the Vendor's parts of any resulting plans with ICN staff.

PROJ.030 Vendors MUST describe the steps and documents that will be provided for deployment and support of the test/pre-production and production systems by ICN staff. If direct access to the servers is required for vendor staff, the vendor shall provide justification for the requirement and an alternative process for upgrades and other ongoing maintenance work.

PROJ.035 Vendors MUST provide a suggested set of roles and recurring tasks for ongoing operation and maintenance of the system, including estimated resource allocations and skill(s) required.

PROJ.040 Vendors MUST describe at least one scenario (including roles and responsibilities, lead times, service levels, technical requirements) for providing technical support, along with estimated costs for each of these elements. For each scenario, the vendor shall indicate if any current customers use the specified process. This cost should be itemized separately in the Cost Proposal.

PROJ.050 Vendors MUST identify any components of the proposed solution that require per-client or per-server license costs, or any other licensing cost not included in the Cost Proposal. Cost proposals should reflect all costs required to deploy and operate the proposed system.

61





PROJ.060 Vendors MUST identify all software associated with the operation of the system, including all third-party software that the State must acquire to deploy and operate the proposed solution. This should include, but not be limited to, operating system, DBMS or application server licenses, client software, drivers, adapters and converters, copyrighted media, logos or images, client access licenses, etc. Software costs must be separate and itemized in the Cost Proposal.

PROJ.070 Vendors MUST identify any areas that they expect to customize for the proposed solution, based on the requirements in this Section of the RFP. Such customizations should have corresponding assumptions and tasks in the proposed project plan, and MUST be part of the Cost Proposal.

PROJ.080 Vendors MUST identify and estimate recurring costs such as (but not limited to) ongoing license fees to the vendor and/or any third parties, upgrade or maintenance fees (including those for customized features), expected technology refresh cycles for operating systems, application servers or other components of the solution. Vendors should indicate whether these estimates are based on existing customer experiences or are projected without a prior basis.

PROJ.090 Vendor MUST specify if an assessment will be done of the ICN's existing data and processes as the first step of the project. If any additional costs are associated with having the assessment done they must be listed as well.

PROJ.100 Vendor MUST give an example of the steps the Vendor has used to implement a system like this before.

PROJ.110 Vendor MUST identify what types and levels of integration can be performed by the Vendor to help align the new OSS system with ICN and its processes and other software products.

PROJ.120 Vendor MUST identify training requirements, lead times, and costs for rollout of the System to ICN staff.

PROJ.130 Vendor SHOULD provide a recommended on-line or in-person training course for customers to use any web portal that is implemented.

PROJ.140 Vendor MUST include project plan elements to scope, design and implement a customer web portal that meets the specified customer self-service requirements elsewhere in this RFP (e.g., REQ.056, MISC.160, AR.060, AR.131, BILL.013, BILL.014, BILL.038, BILL.040, BILL.107, BILL.108)

PROJ.150 Vendor MUST include any applicable examples for similar portal functionality that was implemented, indicating:

1. What platform was used (vendor product, programming language) 2. Integration approach(es) (SOA/WS, Database access, file xfer, other) 3. Approximate incremental cost (beyond internal OSS functionality) 4. Approximate lead time 5. Approximate resource loading for vendor and customer staff 6. Levels of usage for various ICN requirements, if available (How many requests

per month? How many orders vs. billing inquiries vs. billing data updates, etc.)

3.6.25 Vendor Performance



PERF.010 Vendors MUST provide the following general background information:1. Name, address, telephone number, fax number and e-mail address of the bidder

including all doing business as or assumed names or other operating names of the bidder.

2. Form of business entity, i.e., corporation, partnership, proprietorship, Limited Liability Company.

3. State of incorporation, state of formation, or state of organization.4. Identify and specify the location(s) and telephone numbers of the major offices

and other facilities that relate to the bidder’s performance under the terms of this RFP.

5. Local office address and telephone number (if any).6. Number of employees.7. Name, address and telephone number of the bidder’s representative to contact

regarding all contractual and technical matters concerning this proposal.8. Name, address and telephone number of the bidder’s representative to contact

regarding scheduling and other arrangements.9. Identify the bidder’s accounting firm.10. State bidder's Federal Employer Identification Number (FEIN). The successful

bidder will be required to register to do business in Iowa. See DAS Procurement - Vendor Registration for more information.

62

http://das.gse.iowa.gov/procurement/vendor_reg.html

http://das.gse.iowa.gov/procurement/vendor_reg.html



PERF.020 Vendors MUST provide the following information about company experience & qualifications:

1. Business background, number of clients, number of years in business, and other information as necessary to provide assurance of your financial stability

2. The number of years of experience providing the types of services sought by the RFP

3. The level of technical experience in providing the types of services sought by the RFP

4. All services similar to those sought by this RFP that the bidder has provided to other businesses or governmental entities

5. A list of similar projects that are currently in process by the bidder

PERF.030 Vendors MUST provide letters of reference from three (3) clients knowledgeable of the bidder’s performance in providing services similar to the services described in this RFP. Include full contact information including name, title, telephone and fax numbers plus email addresses for each reference.

PERF.040 Vendors MUST provide the following information regarding personnel and capabilities:1. A table of organization. Illustrate the lines of authority. Include the names and

credentials of the owners and executives of your organization and, if applicable, their roles on this project. Also include key personnel who will be involved in providing services contemplated by this RFP.

2. Resumes for all personnel, including any subcontractors, who will be involved in providing the services contemplated by this RFP. The resumes must include: name, education, and years of experience and employment history, particularly as it relates to the scope of services specified herein. It is expected that the key personnel presented in the vendor response to the RFP will be the team members involved in providing the services for transition to the new software system. The ICN reserves the right to approve any staff changes.

3. The name and qualifications of any subcontractor/vendor who will be involved with this project. Describe the work and estimate the percent of total work the subcontractor will be performing.

4. Other contracts and projects currently undertaken by the Vendor.

PERF.050 Vendors MUST provide the following financial information to demonstrate long term viability to carry out the requirements of any contract with the State:

1. Audited financial statements (annual reports) for the last three (3) years and/or bank statements, credit reports etc. These may be via a web address or as part of the documentation.

2. A minimum of three (3) financial references.3. Certification that vendor is bondable and provide bond rating.

PERF.060 Vendors MUST provide the following information about Termination, Litigation, and Investigation:

1. During the last five (5) years, has the Vendor had a contract for services similar to those contemplated terminated for any reason? If so, provide full details related to each termination.

2. During the last five (5) years, describe any damages or penalties or anything of value traded or given up by the Vendor under any of its existing or past contracts as it relates to services performed that are similar to the services contemplated by this RFP and the resulting Contract. If so, indicate the reason and the estimated cost of each incident to the bidder.

3. During the last five (5) years, list and summarize pending or threatened litigation, administrative or regulatory proceedings, or similar matters that could affect the ability of the Vendor to perform the required services. The Vendor must also state whether it or any owners, officers, or primary partners have ever been convicted of a felony. Failure to disclose these matters may result in rejection of the Bid Proposal or in termination of any subsequent contract. This is a continuing disclosure requirement. Any such matter commencing after submission of a Bid Proposal, and with respect to the successful bidder after the execution of a contract, must be disclosed in a timely manner in a written statement to the ICN.

4. During the last five (5) years, have any irregularities been discovered in any of the accounts maintained by the Vendor on behalf of others? If so, describe the circumstances of irregularities or variances and disposition of resolving the irregularities or variances.

3.6.26 Pricing Proposals



PRICE.010 Vendors MUST include the following itemized elements in pricing proposals:1. Prices for each module referenced in the proposal2. Estimated costs for the recommended hardware identified in SYS.0803. VAR or market-price estimates for associated software identified in SYS.090

63



PRICE.020 Vendors SHOULD include the following elements in pricing proposals:1. Special pricing that is available for specific combinations of modules2. Alternative software costs that take advantage of existing State resources such as

MS Reporting Services, Business Objects, etc.3. Alternative hardware costs that take advantage of existing State resources, such

as virtual servers, SAN storage, etc.

PRICE.030 Vendors submitting SaaS/hosted licensing options MUST provide the following options:1. Month-to-month pricing (no ongoing commitment)2. Three-year commitment (if different from the monthly price)3. Six-year commitment (if different from the three-year price)

PRICE.040 Vendors MUST include the following itemized elements for professional services / consulting time identified in PROJ.010:

1. Estimated hours, hourly rates and cost for meeting all Mandatory Requirements, including customizations

2. Estimated hours, hourly rates and cost for implementation of any combinations of modules offered in PRICE.020, including customizations

3. Estimated hours, hourly rates and cost for implementation of SaaS/hosted options offered in PRICE.030, including customizations

PRICE.050 Vendors MUST provide itemized service levels and costs for ongoing maintenance and technical support of each module (PRICE.010), bundle (PRICE.020) or service (PRICE.030) that is proposed. Service level definitions MUST include:

1. Contact channels (phone, email, etc.)2. Coverage hours/days offered (e.g., 24x7, 12x5, etc.)3. Price per incident or term (monthly, yearly, etc.)4. Committed service levels (response times, metrics)5. Escalation path / procedure6. Policy and pricing for migrating customizations from one version to the next

PRICE.060 If multiple levels of maintenance and technical support are available, Vendors SHOULD provide descriptions and pricing for each in PRICE.050.

64