RFP: Records Document Imaging & Management System:€¦ · Web viewWeekly Master File Update –...

SC Law No. 04-CC-ConsultRFP Request for Proposals for ConsultantAdvertised: May 27, 2004 Services, Software and Hardware and Issued: Installation

Request for Proposals (RFP) for Consultant Services, Software and Hardware and Installation for

an Upgrade or Replacement of Existing Student Administration and Other Systemsfor Suffolk County Community College

Mandatory Proposer’s Conference: June 17, 2004

Technical Questions Due: July 1, 2004

Proposals Due: No Later than 4:00 p.m. on Thursday, July 15, 2004Late Proposals Will Be Rejected

For additional information, contact:Craig M. HarrisAdministrative Director of Business OperationsPhone: 631-451-4435Fax: 631-451-4444E-mail: [email protected]

All proposals must be signed in ink and accompanied by a signed transmittal letter, County Disclosure SCEX Form 22, Bid Certification SCPD-7, and Agreement on Terms of Discussion

of 73


Table of Contents

Section IAdministrative Information Page No.

1. Purpose of RFP 42. Background Information 43. Coordinating Departments 44. Evaluation Committee 55. Administrative and Technical Questions 56. Mandatory Proposer’s Conference 67. Due Date for Proposals 68. Number of Copies 69. Proposal Format 610. Award Criteria 811. RFP Policies and Procedures 8

Section IIConsultant Profile

1. General Information/Consultant Profile 102. Expertise of Consultant, Including

Qualifications and Experience of Personnel 103. Quality Control 124. Financial Viability 125. Cybersecurity 126. Client History 13

Section IIITechnical Proposal Requirements

1. Project Scope 142. Project Principles 163. Configuration of the College Implementation Team 174. The Implementation Environment 175. College History 186. Specialized Functionality 197. The Project Management Office and the Project Manager 238. Assurance of Disaster Recover 289. Detailed Technical Specifications – Functionality 28*

*(Document accessible at: http://www.sunysuffolk.edu/RFP)

of 73

http://www.sunysuffolk.edu/RFP


10. Timetable 29 11. Operational Plan 2912. Administrative Systems Integration Points 3013. Description of the Current Operational Environment 32

Section IVCost Proposal 66

Section VModel Agreements


Section VISuffolk County Request for Proposals (RFP) Legal Appendices/Forms Revised as of 10/22/02


of 73




Section IAdministrative Information

1. Purpose of RFP

a. Suffolk County Community College (College) invites proposals from Independent Consultant(s) to recommend a software and hardware solution for the college.

b. Each of the following can be awarded as a separate or unified engagement:

i. Recommend and/or install software and hardware at the college to upgrade or replace the existing student administration system and other systems;

ii. Provide consulting services to direct and effect the College’s and/or consultant’s installation of the recommended solution; and

iii. Serve, on the College’s behalf, as the project manager and work with the firm providing the software and installation services to assure the effective, efficient and timely completion of the process.

b. The College anticipates and reserves the right to award one or more contracts for the above services.

c. Respondents can respond to a(i) and/or a(ii) and/or a(iii) or any combination thereof.

2. Background Information

a. The College is a non-resident, public, two-year college. It has three campuses located in Riverhead, Brentwood and Selden, and extension centers located throughout Suffolk County.

b. The College annually enrolls approximately 25,000 students (head count).

c. The College has determined it needs to replace or upgrade its existing student administration system.

3. Coordinating Departments

a. Prior to Award of Contract

The College’s Office of Business and Financial Services (contact listed below) is responsible for coordinating the issuance of the RFP.

Contact: Craig M. Harris, Administrative Director of Business AffairsSuffolk County Community College

of 73


533 College Road, Rm. 32, NFL BuildingSelden, New York 11784-2899

Tel: (631) 451-4435Fax: (631) 451-4444E-mail: [email protected]

b. After Award of Contract/Prior to Execution of Contract

The College’s Legal Affairs and Compliance Office will be responsible for coordinating with the Suffolk County Attorney’s Office and Consultant regarding the negotiation and execution of the contract.

c. After Execution of Contract

The Office of Business and Financial Services is responsible for administration of Consultant’s contract, including payments.

Office of the Vice President for Academic and Student Affairs is the contact for all questions concerning implementation of the project.

4. Evaluation Committee

A College Evaluation Committee will make the final selection of Company. The Evaluation Committee may include, but not be limited to, the Executive Director of Computer Information Systems, the Associate Dean of Academic Administrative Services, the Executive Director of Admissions and Enrollment Management, the College Registrar, the College Director of Financial Aid, the Director of Administrative Computing, the Administrative Director of Human Resources and the Associate Dean of Business and Financial Services.

5. Administrative and Technical Questions

a. Administrative Questions

Administrative questions may be submitted in telephone or in writing to the contact listed in paragraph 3 above. E-mail and fax are acceptable; e-mail is preferred.

b. Technical Questions

Technical questions must be submitted on or before July 1, 2004 to the contact listed in paragraph 3 above. E-mail and fax are acceptable; e-mail is preferred.

Respondents are encouraged to submit questions before the Proposer’s Conference, to enable full discussion there.

of 73

mailto:[email protected]


The College Evaluation Committee will issue an Addendum to this RFP after the proposer’s conference.

c. Office of Business and Financial Services is Sole Contact during RFP Process

During the RFP process, all communications should be directed to the Office of Business and Financial Services or, as appropriate, the College’s Legal Affairs and Compliance Office.

Respondents may be disqualified from the RFP process if they communicate with any other College or County employee or any member of the College Evaluation Committee.

6. Mandatory Proposer’s Conference

a. The Proposer’s Conference will be held at 9:00 AM, Thursday, June 17, 2004 in the Montauk Room, Second Floor, Babylon Student Center, Ammerman campus, 533 College Road, Selden, New York, 11784.

b. The Proposer’s Conference will be coordinated with a walk through of various offices of the college that work with applicants, students, the general public and corporate and private firms who do business with the college, and deal with matters such as admissions, financial aid, human resources administration, registration and cashiering and payment and contract administration.

7. Due Date for Proposals

Responses must be submitted NO LATER THAN 4:00 PM, July 15, 2004 to:

Administrative Director of Business OperationsRoom 232 NFL Building, SCCC533 College RoadSelden, NY 11784

8. Number of Copies

Respondents must submit one original and eight (8) copies of their proposal, plus one copy on a diskette using an MSWord or ASCII format or as an e-mail attachment in similar format.

9. Proposal Format

Proposals must include the following:

of 73


a. Transmittal Letter on Consultant Letterhead

This letter must be signed by a corporate officer or authorized agent of the company.

b. Consultant Profile: Response to Questions set forth in Section II

This section is used to evaluate the respondent’s general qualifications. Respondents must follow the format set forth in Section II, entitled “Consultant Profile.”

c. Consultant’s Proposed Services: Responses to items set forth in Section III

This section is to used evaluate the respondent’s substantive proposal. Respondents must use the format set forth in Section III, entitled “Technical Proposal Requirements.”

d. Consultant’s Cost Proposal: Responses to items set forth in Section IV

This section is used to evaluate respondents proposed fees and charges. Respondents must use the format set forth in section IV, entitled “Cost Proposal.”

The Cost Proposal must be submitted in the same package as other required items, but it must be in a separate sealed envelope labeled “Cost Proposal.”

e. List (if applicable) of Subcontractors

Respondents must identify all subcontractors they plan to use and describe what those subcontractors will do in their proposals. Failure to provide this information may result in the proposer’s disqualification.

f. Requested Changes to Model Agreement

Respondents must identify any and all items not set forth in the Model Agreement (Section V) which they want to negotiate as part of the final contract.

g. County Disclosure SCEX Form 22

Respondents must provide three originals copies of form SCEX Form 22, signed by a corporate officer or an authorized agent of the company.

h. County Bid Certification Form SCPD-7

Respondents must provide one original copy of SCPD-7, signed by a corporate officer of the company.

i. Living Wage Forms

of 73


Respondents must comply with the provisions of the Suffolk County Living Wage Law.

10. Award CriteriaPoints

a. Evaluation Criteria

i. General Qualifications 30Consultant’s history, expertise, experience,reliability, financial viability and references.See Section II, entitled “Consultant Profile,”for specific requirements.

ii. Proposed Services: 30Strategies, methodologies, services, functionality of software offered by Consultant.See Section III entitled“Technical Proposal Requirements” forspecific requirements.

iii. Cost Proposal 40Separate sealed envelope.See Section IV, entitled “Cost Proposal,”for specific requirements.

Total: 100

b. The College will only entertain proposals where the recommended solution and/or project implementation managed by the firm has been in ‘live’ production for at least three (3) years. Proposals that do not meet this minimum benchmark will be deemed non-responsive and will NOT be considered.

11. RFP Policies and Procedures

a. Respondents must register with the College’s Office of Business and Financial Services, which maintains a control list of eligible respondents.

b. The College intends to contract with the respondent(s) who provide the solutions that best meet the College’s needs.

c. The College has provided, as part of this issuance, a Model Agreement (attached, in Section V) which sets forth the terms and conditions of the agreement(s) to be entered into, including

of 73


indemnification and insurance. The Model Agreement is subject to revision arising out of requests made by proposers in their submittals, discussions with the college before going to contract, the terms and conditions imposed by law or deemed appropriate by the College’s Legal Affairs and Compliance Office or the County Attorney’s office.

d. Respondent’s proposals to this RFP, as may be subsequently modified in negotiations with the College, may be included as exhibits in any contract(s) that result.

e. The College reserves the right to amend this RFP, to reject any or all of the proposals, or any part thereof, to waive formalities, if it deems such actions to be in its best interest, to request additional information from any respondent, and to negotiate contracts with one or more Consultants. Respondents must provide a statement in their proposals that indicate they are willing to provide services to the College if one or more other respondents provide similar services.

f. This RFP does not commit and should not be construed to commit the College to pay any costs respondents incur in connection with any proposal or their efforts to procure or contract for any services.

g. The decision to award a contract shall be based on Consultant’s ability to provide quality services and products and to comply with all applicable laws, rules and regulations, including without limitation the local preference and other Suffolk County local laws set forth in Section VI, entitled “Suffolk County Request for Proposals (RFP) Legal Appendices/ Forms Revised as of 10/22/02.”

h. The award of any contract will be made as judged to be in the best interest of the College. The final selection of the Consultant(s) will be made by the College Evaluation Committee, including but not limited to, the representatives set forth in paragraph 4, entitled “Evaluation Committee” of Section I of this RFP.

i. The Legal Affairs and Compliance Office acts as counsel to the Evaluation Committee, but does not vote in the selection process.

j. Each proposal received is examined to determine whether it responds to the requirements of this RFP. All responsive proposals are evaluated in accordance with the criteria set forth herein.

k. The College is under no obligation to contact Consultants for clarifications, but it reserves the right to do so. At its sole discretion, the College Evaluation Committee may interview all or some respondents during the selection process and may request presentations, including demonstrations of products and services.

End of Text for Section I

of 73


Section IIConsultant Profile

1. General Information/Consultant History

a. Consultant Name and address.

b. Describe the nature of your organization (e.g. business corporation, not-for-profit corporation, proprietorship, etc.).

c. Year Consultant was founded and brief history.

d. Total number of employees.

e. Location(s) from which services will be performed.

2. Expertise of Consultant, including Qualifications and Experience of Personnel

a. Respondents must respond specifically to the following questions:

i. What in its organization’s operating environment will contribute to the project’s success?

ii. What resources does the organization have to support the project?

iii. What collaborative arrangements, if any, will the respondent bring to the project that will enhance the quality or chances for success of the project?

b. Respondents must submit an organizational chart, which indicates where in its structure the project team resides, including all reporting relationships.

c. Respondents must identify any relationships with hardware or software vendors that could be construed to conflict with the objectivity of the assignment.

d. Respondents must provide resumes of the project director and other key staff who will be assigned to this project.

e. Respondents must describe the qualifications and background of each staff member, insofar as they are presented as a participant in the project.

of 73


f. Respondents must provide staff member-specific references for those so indicated, so the College can determine the effectiveness of their performance in the ascribed roles in other, similar assignments.

g. Project staff must have experience in a variety of enterprise environments including IBM mainframe, Client / Server and web delivered services, and these experiences must be so indicated.

h. The College reserves and will exercise the right to interview and reject the project manager proposed by the Consultant, and respondent will indicate their approval of this reservation of authority.

i. Respondents will indicate if they will be assigning temporary staff to this project. If so, they will include details of their supervision and training.

j. Respondents will provide a list of the contracts entered into in similar engagements, including therein the solution offered, initial contract amount, contract changes (including the rationale for such changes) and total contract receipts.

k. Respondents will describe the role and experience of key personnel assigned to other similar

projects who will be assigned to this project.

l. Respondents must describe where their professional management assignments have been successful in mitigating the issues described by the College, to include but not be limited to each of the following:

i. Difficulties clients have had in making decisions, ii. Problems in executing change management strategies,

iii. Strategies to overcome personnel reluctant to modify workflow, iv. Approaches used to accommodate users who saw the project as taking away

functionality existing under the legacy system as a ‘vanilla’ package is installed.

m. Respondents must indicate in their proposal that their firm has a large enough staffing footprint to provide easy access to consultation services for implementation and maintenance in technical programming and functional management of the system (i.e., consultants are available and need not be flown in from outside the New York metropolitan area), and if not, respondents must indicate how they would propose to manage the functions noted.

n. Respondents must identify all employees of the college with whom they had contact in the twelve months prior to the submittal of their response RFP, to include the date and location of such meeting(s) and topics discussed.

of 73


o. Respondents must identify all contractual arrangements and partnerships they have, as commonly understood in the industry,

p. Respondents must indicate any and all partnerships and contractual arrangements they have with firms that provide software and/or hardware that supports their recommended solution.

3. Quality Control

a. Operational Plan: Describe how Consultant will ensure performance through adequate management, supervision, review and control.

b. Record and Reporting Systems: Describe Consultant’s system for self-monitoring and to ensure maintenance of complete and accurate records.

c. Operating Problems: Discuss any operating problems, other than litigation, which you have experienced within the past five years, and their resolution.

4. Financial Viability

a. Financial Statements

For nongovernmental agencies, submit current financial statements prepared and certified by an independent CPA or internal statements if certified statements are not available or have not been issued within the past twelve (12) months.

b. Indebtedness to County, Liens and Litigation

Respondents must submit the following:

i. A statement as to indebtedness, if any, to the County; and

ii. A listing of all outstanding liens, if any, against the Proposer; and

iii. A summary of litigation, if any, against the Proposer and its disposition.

5. Cyber-Security

a. Respondents must:

of 73


i. Demonstrate that their staff is trained in appropriate security procedures and hold appropriate security credentials;

ii. Identify their Information Security Officer;

iii. Certify all code in their baseline produce, including any third party code, has been audited for security weaknesses;

iv. Describe procedures used (internal department or outside hire) to test the solution to assure it is safe from unauthorized use; and

v. Indicate if the proposed solution has been evaluated on ISO-15408 (Common Criteria).

Client History

a. Respondents must provide a detailed list of representative higher education clients, defined as the following:

i. A project involving a similar implementation or project management services provided in the last three years at a large community college or college system, with a headcount of 20,000-30,000 or more, which need not be a multi-campus college; and

ii. All installations in community colleges in New York, including State University (SUNY) and City University (CUNY).

b. For each of the institutions in (a), provide no fewer than three references. The references must include the Project Manager and the Financial Administrator who were responsible for the functional and financial administration of the project. In addition:

c. For all references, provide the following:

i. Institution name;ii. Contact name, address, phone number and e-mail address;iii. Version and modules licenses;iv. How long each of these modules has been ‘live’ at the institution;v. Operating system, andvi. Hardware.

d. Provide a list of all contracts with the College or the County of Suffolk within the last five years (regardless of type of service) and the time period for those services.

End of Text for Section II

of 73


Section IIITechnical Proposal Requirements

1. Project Scope

a. Suffolk County Community College (College) invites proposals from Independent Consultant(s) to recommend a software and hardware solution for the college.

b. Each of the following can be awarded as a separate or unified engagement:

i. Recommend and/or install software and hardware at the college to upgrade or replace the existing student administration system and other systems;

ii. Provide consulting services to direct and effect the College’s and/or consultant’s installation of the recommended solution; and

iii. Serve, on the College’s behalf, as the project manager and work with the firm providing the software and installation services to assure the effective, efficient and timely completion of the process.

c. The College anticipates and reserves the right to award one or more contracts for the above services.

d. Respondents can respond to a(i) and/or a(ii) and/or a(iii) or any combination thereof.

e. The College seeks to replace or upgrade its legacy systems with a solution that will integrate and interface to its administrative systems (Human Resources, Finance, Student).

f. Proposers will fully respond to each of the requirements of the College, as set forth below:

Note: Firms responding solely to the project management portion of this RFP are also required to consider the college’s needs as outlined here and to include a recommendation of a solution to the college’s software and implementation needs. These proposals must equally address the items listed below.

i. The College will consider options including the purchase of an ERP system, a best of breed solution, a proposal to re-write existing systems or a combination of the aforementioned..

Respondents will indicate which solution they are proposing and why, demonstrating an understanding of the current system and its strengths and weaknesses.

ii. Currently, a multitude of internally developed mainframe and shadow systems exist at

of 73


the College and in Suffolk County to support these functions.

Respondents will indicate which of these systems it recommends be rewritten to the College’s defined requirements.

iii. The College is constrained in this enterprise by the existence of a contractual and legal relationship by which Suffolk County provides and controls certain administrative systems of the College.

Respondents will indicate their ability to meet the integration requirements of the College to County systems.

iv. In this context, the College has divided its request into components which reflect those systems and components of broader, county-controlled systems that it can replace internally, and those for which the consultant will be requested to recommend, provide and direct the installation of durable interfaces to existing, legacy County systems. This division is described more fully in Section III (8), Detailed Technical Specifications and Section III(10), Administrative System Integration Points.

v. In this framework, the acquired solution will replace legacy Student Administration systems and legacy components of the College’s human resources system that support personnel administration required by the College, as distinct from county supported needs, and required interfaces to County systems (financial, human resources and payroll). In this situation, the acquired solution must provide a durable interface to the County’s legacy systems.

Respondents must submit a cost proposal to support this base-line systems replacement and the design and implementation of durable interfaces to the County’s legacy systems.

vi. Except as otherwise provided by the enterprise recommendation, respondents will be required to recommend modules to support Document Imaging as an add-alternative, provided the base system does not acceptably integrate to the Feith Data Imaging Solution (Section IV(4)(3)).

vii. Except as otherwise provided by the enterprise recommendation, respondents will be required to recommend modules to support point of sale/cashiering (section IV(4)(3)).

viii. In completing the Functional Specifications, respondents must indicate their baseline solution meets the special functional requirements (Section III(8)). They must indicate this in the Functional Specifications Table, in the column labeled, “Respondents Description of Service.” If it does not, they must provide a plan of

of 73


action for each, with a proposed cost, as part of the proposal.

ix. In completing the Functional Specifications for components of the baseline system in the Functional Specifications Table, respondents must provide references to where the system provides the capability in terms of (a) training manual name and page number, (b) screen name or number; and/or (c) report name and or number, and must indicate whether the support is fully available or partially available.

x. Assurance Statement

(a) Respondents must provide a statement affirming and assuring that the Consultant’s recommended system can and will meet each of the College's requirements, as listed in this section and in the Functional Specifications.

(b) Each exception to the Assurance Statement must be detailed.

2. Project Principles

The College seeks to select a consultant and products that will enable it to implement the solution under these principles. For each of the following the Consultant must indicate that it will adhere to the principle:

a. To the extent possible, there will be a centralized system approach to implementation.

b. System maintenance will be managed centrally.

c. There will be no desk top clients to be maintained.

d. Primary systems will be run against a single data base.

e. The software design will incorporate best business practices. In addition, respondents must provide illustrations of best business practices for each of the following:

i. Financial aid determination;

ii. Refund processing;

iii. Admissions processing; and

iv. Systems administration.

f. The expectation is that the installation will be a “vanilla” system, with minimal customizations. The goal is to work within the configuration of the software proposed with

of 73


no source code changes. Respondents will indicate all areas where customizations are required (to the exclusion of interfaces to county systems, which will be addressed separately).

g. Systems will be phased in and implemented in a time frame that minimizes the impact of interfacing and bridging to legacy systems.

h. The implementation must minimize the disruption to college operations. Respondents must indicate how they plan to minimize disruption that can result from the impact of interfacing and bridging to legacy systems.

i. Standardized business processes will be developed college-wide.

j. The system will support all degree, non-degree, non-credit, specialized and certificate programs.

Respondents will indicate, unless the contrary is the case, that their proposed solution can be applied to administer and manage the above.

3. Configuration of the College Implementation Team

Given the assumption the College will issue more than one contract, the College envisions an implementation environment consisting of members of the College’s implementation team, software/hardware consultant(s)/vendor(s) and the project manager contracted by the College to facilitate the implementation.

a. Software/hardware consultant(s)/vendor(s) will indicate their experience in working with such an arrangement and identify any problems with such an arrangement.

b. Software/hardware consultant(s)/vendor(s) will indicate if they do not agree to the above.

4. The Implementation Environment

The College is committed to establishing an implementation environment that will facilitate project success. In this context, respondents must know the following:

a. The College will suspend modifications to its legacy systems, during the implementation process, unless they involve mandatory state or federal regulatory changes.

b. Cost is a major constraint, and the contracted amount cannot be exceeded.

c. Timeframes will be established and must be met.

d. Project implementation will be a priority, and all conflicts must be discussed and resolved in

of 73


a timely manner.

e. Concerns must be raised and resolved quickly; otherwise, the assumption will be that there are no concerns.

f. All interface requirements will be a priority with the functionality of each considered as important as that of the system modules

g. Implementation of the new system is not the time for the initiation and implementation of other new requests, unless specifically delineated within and accepted among the priorities of the project and unless provided within the framework and capabilities of the proposed solution, since the College’s goal is to maximize the use of capabilities inherent in the recommended solution.

h. The College will not entertain changes in source code.

i. The College will adopt best business practices.

5. College History

a. The College has been actively considering alternatives to its existing administrative systems since 2000.

b. Senior College executives and administrators have participated on the broad review and office personnel and staff have participated in vendor demonstration.

c. The College has done the following:

i. Identified deficiencies in current applications;

ii. Continued to maintain and upgrade its existing systems, to maintain or improve communications management, document imaging and web-based transactions for registration, advisement, bill payment and roster management through the college’s portals;

iii. Made significant investment in a few core applications in terms of effective workflow and direct services to students and faculty;

iv. Recognized its existing software is limited because of constraints on its breadth, weakness in some modules lack of a client-based reporting capability and the continued reliance on old back-end architecture;

v. Evaluated solutions including the packages provided by Banner and PeopleSoft, a rebuild of the home-grown system and a best-of-breed mixture;

of 73


vi. Participated in demonstrations and evaluations, assessed the successes and failures of other colleges, and visited other sites to see proposed solutions in action;

vii. Assessed the fits/gaps in its existing programs provided by vendors; and

viii. Concluded that despite the value of the business logic inherent in its existing system, weakness in other areas and the age of its architecture reduces the attractiveness of the rebuild option.

d. The College has included, in this RFP, information on requirements, vision and gaps.

e. After completing this thorough review, no obvious choice emerged for the following reasons:

i. Commercial packages apparently lack the depth of support of the College’s home-grown system (Section III(6)(a) and Section III(6)(b).

ii. Existing commercial packages also apparently lack the depth of support to key faculty management requirements (Section III(6)(c)).

iii. Volatility in the commercial marketplace, inconsistencies between what is sold as available and is actually available and installed, and caution advised by others who have purchased vendor solutions has created an atmosphere urging caution.

f. The College has issued this RFP so respondents can propose a solution that resolves the College’s dilemma and addresses its concerns.

6. Specialized Functionality

This section describes three specialized functionalities that respondents must provide, either as part of their baseline package or as a customized add-alternative. If respondents indicate their baseline system cannot support each area of specialized functionality, they must provide a cost-proposal to build such functionality.

a. Student Advisement Information Notice (SAIN)

i. The Student Advisement Information Notice (SAIN) has the following characteristics:

(a) It is accessed by students via the College’s student portal;

(b) It identifies courses that are required for a degree;

(c) It compares the completed courses to the degree requirements, including the

of 73


capacity to provide “what-if” scenarios for students who were interested in changing their majors or using a program from a more current college catalog;

(d) It runs on-line on terminals at staff desks, and

(e) It maintains historic catalog information that allows the college to analyze courses taken and their relationships to programs offered to determine degree eligibility.

ii. SAIN is deeply integrated into much of the College's student information system.

(a) SAIN supports students through the advisement, registration, financial aid, bill payment and graduation processes.

(b) There remain few core systems at the College today that do not use SAIN in some way to add value to the presentation of their data.

iii. SAIN supports the College’s financial aid system.

(a) It warns students—at the time of registration—that certain courses may not qualify for financial aid.

(b) It alerts students that they will be personally liable for a portion of their bill.

(c) It enables financial aid counselors to do the following:

(i) See a real-time comparison of the number of credits a student was enrolled in versus how many were “aid-able” (i.e., contributed toward graduation and therefore could be credited for aid purposes).

(ii) Generates reporting capability that allows financial aid counselors to proactively resolve conflicts in student scheduling and maximize aid received at the institution.

iv. SAIN supports the Registration process.

(a) As a student is registering, SAIN advises the student (via a status code) if each class qualifies for graduation.

(b) SAIN flags each course that does not meet program requirements on the student schedule and bill, which tells the student to check with their advisor, the Financial Aid office or to register for another class.

of 73


iv. SAIN supports Degree Audit (Eligibity for Graduation).

(a) SAIN determines degree eligibility and courses that need to be taken (if any).

(b) Real-time and on-line, SAIN displays the following:

(i) Cumulative average;

(ii) Major;

(iii) Transfer credits;

(iv) Waivers;

(v) Substitutions;

(vi) In-progress courses;

(vii) Catalog version;

(viii) Year of matriculation; and

(ix) Advisor’s name.

vi. SAIN provides the following additional functionality:

(a) It is intuitive in that it provides a prescription of what the student needs;

(b) It shows the full student profile;

(c) It assesses how the catalog year, curriculum and/or option within curriculum should be manipulated to work in the student's best interests;

(d) It is used to generate reports; and

(e) It provides data that supports enrollment reporting.

vii. Student access to and use of the SAIN:

(a) Students access SAIN via the College’s student portal, where they can register and pay.

(b) Students use SAIN to assess their progress toward their degree.

of 73


(c) Students make decisions on changes in major based on their own “what-if” scenario research.

(d) Students query for and select needed courses from the SAIN system, including by specific days and times in an attempt to build an ideal schedule.

b. Communications Plan

Based on CARS (Jenzabar) software, the specialized Communcations Plan functionality allows the College to do the following:

i. Maintain contact with students from the inquiry stage through class registration;

ii. Create numerous flexible mailing series, which contain multiple automatically scheduled contacts based upon profile data entered targeting various age and interest groups;

iii. Determine and automatically schedule mailings a prospect or applicant will receive within an individual series, based upon the number of days remaining before the start of that individual’s planned enrollment semester. Specific mailings have automatically generated start and expiration dates relative to the start of the enrollment semester. This determines what acknowledgement or follow-up letter would be sent for inquiries received at various times of the year and whether subsequent contacts would be skipped as the time available for applying decreases.

iv. Automatically adjust the time between scheduled mailing, using a rules-based minimum and maximum value, so that individual active contacts are compressed as the time leading up to a planned enrollment semester shortens.

v. Automatically add and/or skip mailings based upon information updated in a prospect’s or applicant’s record.

vi. Produces data files that merge with MS Word documents for the production of correspondence

c. Seniority Tracking

i. Suffolk requires specialized functionality in its seniority tracking.

ii. Under the College’s collective bargaining agreement with its Faculty Assocation, seniority is the prime consideration in the following:

(a) The assignment of courses;

of 73


(b) The determination of eligibility for adjunct promotion; and

(c) The determination, during times of retrenchment, of seniority and status.

iii. According to the rules defined in the College’s collective bargaining agreement with its Faculty Association, the following five populations must be tracked:

(a) Part-time faculty seniority by the number of semesters taught and number of hours taught. Data elements that must be captured for adjunct faculty include the following:

NameSocial Security #/ID #AddressPhone #Courses Eligible to TeachCollege Start DateCollege Rank DateSemesters in RankTotal SemestersHours in RankTotal HoursRankLast Adjunct Semester TaughtThis Years Total Hours Taught

(b) Full-time professional assistants and guild members who also teach overload by number of semesters and hours taught in each discipline.

(c) Part-time faculty who teach in more than one department/area by the number of semesters and hours taught in each discipline.

(d) Full-time faculty who teach overload in more than one department/discipline by the number of semesters and hours taught in each discipline

(e) Seniority by date of full-time faculty college-wide and by campus for each department/area; but for this cohort, seniority is not strictly done by start date, there are other factors involved such as guild members, exempt employees, leaves of absence, etc.

7. The Project Management Office and the Project Manager

a. The Project Manager will serve as the College’s representative, work with the consultant(s) selected throughout the engagement and must:

of 73


i. Possess PMP certification;

ii. Adhere to PMBOK (Project Management Body of Knowledge); and

iii. Have experience in a project of similar scope and complexity.

b. The College anticipates the following Project Management Office staff, with their defined responsibilities, and the overall Project Management Office structure will be in place during the engagement:

1. The project sponsor is the President.

2. The project owner is assigned by the President and is responsible for the overall management of the project.

3. The Project Management Office (PMO) defines, plans, directs, monitors and controls the project and assures the project stays on time and within budget.

4. PMO Staff and Structure include:

a. The Consulting Firm Project Manager, who has final management authority over all consultant staff and is the primary contact with College management on issues pertaining to consultation services and ERP vendor communication.

b. The College Functional Manager, who is the “user’ community manager, with final management authority over all college functional staff assigned to the project; and

c. The College IT Manager, who is the key information technology manner on the project, with final authority over all college IT staff assigned to the project.

d. The PMO Staff Person, who is responsible for scheduling meetings, consolidating agendas, keeping and issuing minutes, assembling project’s plan, budget and status reports and providing other support services to the PMO.

e. A Functional Module Structure will be used to implement the project:

1. A set of functional groups consisting of college personnel who will interpret college business rules, set up tables, decide how to covert and/or upload legacy system data, assign security, determine best practices, test the system and train staff on its use.

of 73


2. Each team will include three lead staff, representing, in parallel to the PMO structure, the Project Manager, Functional Manager and IT Manager, and others assigned to work on the module.

3. Module team members will be assigned via a matrix management methodology.

4. Matrix Management:

a. Assignments will be made to assure the best fit of talent to task.b. Groups will be supervised by managers with experience overseeing

those tasks.c. Functional modules will require staffing to perform skilled tasks.d. Staff from a given skill set will be assigned to work on specific

tasks for a functional module while continuing to report to their skilled pool manager.

e. Organizationally, staff will report within their skill set to a manager on the horizontal axis while they perform tasks as part of another team on the vertical axis.

HORIZONTAL AXIS (Functional Sets)VER AT XI C SAL

SKILLS

Enrollment Management

Finance Human Resources

Business AnalysisSystems AnalysisScreen ProgrammingReport ProgrammingQuality Assurance

of 73


of 73

Project Management Office

Consulting Firm Project Manager, SCCC IT Manager, SCCC Functionall Manager

Project SponsorProject Owner

ProjectManager

Functional Module 1Enrollment

ContentManager

SCCCIT Lead

Team

Communication & Facilitation Staff Person

TeamTeam

ITManager

* Depicts typical project modules. Actual modules will be deter mined by ERP selection

ProjectManager

Functional Module 2Finance

ContentManager

SCCCIT Lead

Team TeamTeam

ITManager

ProjectManager

Functional Module 3Human Resources

ContentManager

SCCCIT Lead

Team TeamTeam

ITManager


c. The Project Manager will do the following:

i. Direct implementation of the project on the college’s behalf.

ii. In coordination with the PMO, oversee the entire project, including the following:

(a) Assure the project scope is maintained;(b) Manage implementation to meet the timeframes on or ahead of

schedule;(c) Direct the project so it is completed within the contractually defined

budget;(d) Develop alternative approaches to achieving goals within budget;(e) Develop a detailed project cost analysis and timeline for

expenditures;(f) Provide on-going communication, status updates, support and

feedback;(g) Amend, modify and update the project schedule;(h) Maintain issue tacking and resolution procedure log;(i) Prepare for, attend meetings and act as advisors to the various

oversight committees;(j) Clearly identify expectations to the various college constituencies.

iii. Coordinate and manage all activities and consultants throughout the period of engagement;

iv. Possess the demonstrated ability to function effectively in an enterprise whose complexity is similar to that of the College;

v. Provide an experienced integrator who can direct implementation of the project on the College’s behalf;

vi. Manage the implementation to meet the timeframes on or ahead of schedule;

vii. Supervise all personnel assigned by the College to work on the project for the purposes intended, in coordination with the project management office;

viii. Mediate all issues or concerns that arise regarding any phase of the project, in coordination with the project management office;

ix. Review the timeliness and adequacy of consultants’ work on the project;

of 73


x. Advise on the consequences and sign-off on all proposals that constitute changes in the work to be provided by the consultant, in coordination with the project management office;

xi. Review and make recommendation on all disbursements to consultants, after approving quality of work;

xii. Develop and manage the training plan;

xiii. Direct the parallel installation, testing and replacement of legacy systems to assure a smooth transition to new systems without disrupting on-going processing activities in the College;

xiv. Review the need and identify the requirements for the conversion of legacy data to the new system, which includes the development of alternatives to doing a full load of all historical data into the new system;

viii. Direct the project so it is completed within the contractually defined budget;

xvi. Provide the documented business processes to enable the College to use the solution to manage its business (electronically, hard copy, etc.), at the end of the project;

8. Assurance of Disaster Recovery

a. Disaster Recovery – Respondents must propose a solution that can:

i. Run on a primary location and also to be configured to run at a live, redundant site;ii. Run existing campus infrastructure from a remote host location;iii. Run web/portal services to students/faculty from a remote host location;iv. Be restored from backup tape;v. Demonstrably be shown to have been successfully moved to a backup location for

emergency reasons.

9. Detailed Technical Specifications – Functionality

a. The College has detailed its functional requirements (Section III(9)) .

b. Within the body of the document, respondents must respond in detail, as outlined, by inserting appropriate references to manual page, table, report, or feature that fulfills the requirement.

of 73


c. Respondents must specifically delineate all recommended solutions, and provide a separate price for each customization beyond the “plain vanilla” installation.

10. Timetable

Respondents will propose a phased implementation that delivers full functionality for the Fall 2006 semester.

11. Operational Plan

The college is aware of the complexity of this asking, as it is aware of the magnitude of the project requested and the associated financial commitments.

Consultant shall prepare an Operational Plan which does the following:

a. Respondents must respond to the RFP in the indexed order of the document, particularly to all “shall”, “must”, “will” and other such directive statements regarding the requirements of the college, as detailed in Section II and Section III, including Section III(9).

b. Consider the existing College systems, architecture, hardware, platforms, software, personnel and networks.

c. Evaluate the existing operational environment of the computer center and make recommendations to assure the environment is capable to support the long-term administrative needs of the college in an appropriate manner.

d. For its recommended approach, the Consultant will provide the following:

i. A comprehensive implementation plan, to include the following:

(a) Task level project plan;

(b) Cost estimates; and

(c) Projected staffing for the technology and functional departments required to support both the implementation solution and the maintenance of on-going business-as-usual activities in campus and college administrative offices, operational implications and a realistic timetable.

ii. An assessment of the strengths and weakness of its approach, from alternatives available;

of 73


iii. The hardware, software, personnel and training that will be necessary;

iv. A transition plan that will minimize the disruption of mission critical systems; and

v. Any recommendations for changes in technology resources, expenditures, organization and services.

e. Consultant will describe the specific procedures it will use in the course of its engagement.

f. Consultant will recommend and provide the rationale for the organizational and reporting relationships they proposed for the project team.

g. Consultant will recommend the staffing resources and configuration to be provided by the College throughout the course of the engagement.

h. Consultant will recommend the detailed timetable, and provide a backup timetable, for the phased installation of all systems to be installed.

i. Consultant will delineate fully their proposed rules of engagement, to include proposals for the resolution of disputes.

12. Administrative System Integration Points

The following is a list of the major points of integration for external systems that it is anticipated an ERP will need to begin or continue to support.

Respondents must integrate to these systems or provide a recommended alternative on a cost-neutral basis as part of their deliverable.

For each, respondents must indicate if their proposed solution already includes the functionality, will provide functionality through an existing business partner’s product, or will be customized de novo.

Detail specifications for each API will be given to the recipient of the award:

a. Integration of JPoint (SalePoint) Point of Sale (POS) System, on a real time basis for the acceptance and posting of all charges due the College or have like integrated functionality from another vendor on a cost neutral basis to the College.

b. Posting of Accounts Receivable to American Management Systems, Inc. (AMS) Integrated Financial Management System (IFMS.) as a nightly batch process to feed summarized receivable data by campus and revenue code into the college financial system.

of 73


c. Feith Systems and Software Document (FDD) Imaging System , for the management of electronic images or have like integrated functionality from another vendor on a cost neutral basis to the College.

d. Posting of College Payroll Transactions to the Suffolk County Payroll System (proprietary product.) The college processes in excess of 2.5K manual payroll transactions each semester. Workflow is desired to automate the generation of this data and then integrate via a nightly batch process to the homegrown Suffolk County Payroll System.

e. Single Point of Entry for Human Resource and Payroll Data. Presently the college maintains a pseudo-HR system that requires data entry of a subset of information redundant to the County Payroll System. It is desired to be able to enter data in the County system and receive a feed back via nightly batch to the ERP for display purposes only.

f. Internal Revenue Service (IRS) 1098-T Filing. A batch process presently generates a flat file that is sent via FTP to the IRS for processing each March.

g. Student and Exchange Visitor Information System (SEVIS.) While not presently interfaced to the Immigration and Naturalization Service (INS) SEVIS systems, a system that directly reports the application, acceptance and status change of foreign students to SEVIS is desirable.

h. Financial Aid. The college participates electronically in the TAP and APTS programs through batch processing of files received via FTP.

i. New York State (NYS) Department of Motor Vehicles (DMV. ) The college parking violations system creates a flat file bearing NYS plate numbers on a monthly basis. A file is returned that ties the plate number to the registrant to allow for processing of fines vs. student accounts.

j. Dunning and Collections. The college supplies an outside collection agency with information to allow for dunning and collection of outstanding balances due. The agency will return a file to the college that will be applied against student accounts.

k. Positive Pay. The college is presently programming a batch interface to transmit positive pay information to banks for the purpose of fraud protection.

l. ALEPH. A coalition of library services within the State University of New York (SUNY.) The college generates a file of all registered individuals with an ID number compliant with the SUNY library systems.

m. ID Works. The college maintains a real-time connection between an ID card generation system and the main student (employee) record on file on the mainframe.

of 73


n. Suffolk County Community College Health Club. The college is presently building an interface to allow Health Club employees verify the status of a student or faculty member via a real time query on PDA versus the primary student (employee) record on file on the mainframe.

o. ALIES. Interface to a Windows-based database system developed in Microsoft Access 2000 to track data for the Literary Assistance Center.

p. Welfare to Work . Interface to SUNY Central Administration hosted database that presents information on the internet.

13. Description of the Current Operating Environment of the College: SCCC Student Administration and Other Systems

The following is a general outline of the student administrative systems and peripheral applications in place at the College.

Included are descriptions of various mainframe applications and processes. The information is confidential and provided solely for the purpose of assisting vendors in the understanding of the College’s present environment. The College requires that this information not be shared beyond those participating in the RFP process. The document is not to be distributed.

The acceptance of this document by participating vendors assumes acceptance of these conditions.

of 73

Subsystem Block Diagrams, Functionality & Computer Center System Runs

Mainframe Systems:1. Primary Mainframe Systems Diagram2. Student Records

a. System Functionalityb. List of Applicationsc. List of Computer Center Batch Runsd. System Block Diagrame. CARS Admissions Module Applications and Batch Runsf. CARS Admissions Module System Block

2. Academic Affairsa. System Functionalityb. List of Applicationsc. List of Computer Center Batch Runsd. System Block Diagram

3. Advisementa. An assessment of Applicationsb. List the strengths and weakness of Computer Center Batch Runs, its

approach, from alternatives available.c. System Block Diagram

4. Business Office Systema. Functionalityb. List of Applicationsc. List of Computer Center Batch Runsd. System Block Diagram

5. Financial Aida. List of Applicationsb. List of Computer Center Batch Runsc. System Block Diagram

6. Personnela. List of Applicationsb. List of Computer Center Batch Runsc. System Block Diagram

7. Registrationa. Functionalityb. List of Applicationsc. List of Computer Center Batch Runsd. System Block Diagram

8. Mainframe System Interconnects

of 73

Primary Mainframe Systems

of 73

Student RecordsAdmissionsAcademic StatusMatric StatusOne-Time FeesBlocksID Cards

RegistrationScheduleRostersGradesCourse History File

AdvisementTestingSAINAdvisor AssignmentCurriculum Info

Financial AidFederalStateFA TranscriptSAINSUBCheck Distribution

Academic AffairsCourse CatalogPreReq/ WaiverMaster ScheduleInstructorsSched D

Business SystemSemester BillTuition Pay PlanRoll Over BillsTraffic ViolationsStu Accounts

PersonnelTime AccrualsPersonnel InfoID Works Link

Student Records System Functionality:

Prospects Development and Admissions: Through CARS (now Jenzabar), the system provides prospect and admissions management, including a customized communication/tickler package based upon an individual’s interest and the timeframe of first contact. A student prospect record is created when a student first inquires to the College. Prospect records may also be created from various other sources, including tapes of Suffolk County’s juniors and graduating seniors. Students’ interests and applications are monitored from inquiry through enrollment. The CARS system includes prospect and admission records. Admission and history records are created and maintained on the mainframe via the CARS system in batch. Students can apply via the web or using a paper application. See CARS section for additional information.

Maintenance of Student Status: All students require a history record, which functions as the main depository of financial and academic profile information from application through graduation. Student History records are created as noted above for matriculated students and created using the applications listed below for non-matriculated students. A student’s history record contains many fields identifying a student’s current and previous status maintained by on-line and batch applications. See the applications below for the types of information kept in the history record.

Upon record creation, a student is assigned an identification (ID) number which functions as a non-social security number identifier for access to system information and for use with ancillary applications such as the SUNY Library System, computer lab access and access to student records via the web (MySCCC). ID number assignment is based upon the rules established by SUNY for the library project. While the numbers are system generated, they must integrate with the existing database kept within the SUNY Library System. The ID Number File is integrated with the ID Works card production system.

Many systems use and update information in the History record. Transfer course equivalents, encumbrances and blocks, and matriculation status (through the grade posting process) are maintained in bulk by batch processes. Individual statuses are maintained interactively by the applications listed below, including the processing of individual transaction records using the Master File Edit and Update procedure.

A student’s course history is kept in the course file within the Registration system.

Student Records Applications:

CSHR, USHR, USH2 – Creates or updates an Historical Record. All individuals within the Administrative System need historical records. Historical Records keep profile information, financial information (i.e. one time fee status like grad fee, testing fee and application fee), current academic information (SAIN waiver substitution,

of 73

current cum and curriculum, original and current matriculation code with dates), current PIN, current block status and encumbrance status, high school information and scores, immunization status, etc.

ADMA/ADMU – Creates an Admissions record. The functionality of this application has been superceded by the CARS Admissions Module. Admissions Records are now created and updated on the CARS system and uploaded to the Admissions file and History file. This is a batch process that is to be updated to an on-line interface.

HEAL – Updates student’s immunization information.

MATR Updates a Student’s current matriculation code/status.

BLOC/ENCU – Updates block and encumbrance status. The College has various types of encumbrances, each managed by specific areas. These include Security, Student Affairs (Deans), Business Offices and Library. Registration blocks are managed by the Deans of Faculty, Financial Affairs or the College Nurse (for lack of immunization compliance).

WAIV – Modify Automatic Judgments for Financial Aid “Lack of Progress,” Waive fees (placement testing, vehicle registration).

GRAD SAIN – provides information for evaluation of progress toward graduation and prints reports of graduation status. Graduation procedure: “Eligible” student list is generated for Central Records to review, students are evaluated individually using GRAD SAIN, those that look good receive a letter notifying them they may be eligible for graduation, students apply and are added to Grad file (XPIN). After grades are posted, Central Records reviews students applications, posts graduation and a file is produced to be used for the printed brochure.

DENT - Utility that creates transaction records for various applications. These will update either the history, course or student accounts files during the master file edit/update batch run. Transactions include change of grades, change of social security number, etc.

IDSS - Application that cross references ID number and social security number. It is used as an end-user CICS screen and a subroutine accessed by other main frame programs.

Computer Center Mainframe System Runs:

CARS to Admissions Batch – Creates and updates Mainframe information from CARS records.

of 73

Date Entry Error Reports – (1) Lists problems with CARS to Admissions Batch update resulting from data mismatches. (2) Lists data entry errors within CARS system.

Zip+4 Address Corrections Batch Weekly Master File Update – Updates historical record information (Name, social

security number, Transaction Updates) from transaction records created in DENT. Transfer Course Equivalents Download to Web – Updates list of transfer courses from

various institutions and their equivalent course at the College; available to students and prospective students via the web.

Admissions Status Cards and Labels – Generates folder, standard mailing labels and tracking cards for use by Admissions.

Transcripts – Produces official transcripts to be mailed to various colleges and employers as requested by students.

Email/Active Directory Download – periodic download of current students for the automatic generation of network access accounts.

Lab Sign-in Course Download – periodic download of MS SQL table used in MS Access application that tracks student use of academic computing labs for FTE reimbursement.

LAIP ID Number Download – Periodic download of active patron information to be uploaded into the SUNY Library System.

INS/SEVIS Report – New report on status of foreign students’ status. Weekly Admissions Report (to XPIN) – Status report of admissions numbers. Cumulative Admission Report – Status report of admissions numbers. Batch Block - Application of various blocks to a student’s records from processes such

as grade posting. Library Encumbrance Run – Application of library encumbrances to student’s records. Heal Batch Block – Application of immunization block from HEAL information.

of 73

Student Records System

Subsystems: Admissions, History, Registrar, Blocks, ID

of 73

History ProfileMatricGrad

Sem CumPINS

ID Works

AdmissADMA/ADMU

CARS

Batch

CSHRUSHRUSH2

MATRT

BLOCENCU

WAIV

GRAD

Feith

Deans Security Business Off Library

Registrar

Business Office

ID#s

Grad List

WebApp

E-mail Manual Entry

PaperApplication

Manual Entry

Grad SAIN

DENT

Dent

XPIN Batch

TransCourse Equal

XPIN Batch

Web

Transcript Evaluation

Evaluate & Post Graduation

Master File Edit/

Update

Registrar

HEAL

IDSS

Grade Posting

Reports

Course Student Acc’ts

Change Lists from Offices

Manual Entry

Batch Block/Enc

u

PC based Index

CARS Admissions Module

Applications:

Inquiry: Creates and updates an inquiry record for individuals who have requested information from the College or who have been identified as prospects from various electronic sources. Keeps tracking information of contacts and material sent as a result of inquiry

Admissions: Creates and maintains an admissions record from a paper application (manual entry) or Web Application (automatic entry) after review for accuracy by admissions staff. Keeps tracking information on contacts and material sent to applicant and any missing material and stores various admissions statuses through the evaluation stage.

Contact Management: Prospects and applicants progress through the system via a series of contacts. These represent items sent to students, received from students and evaluations performed either manually or automatically. The process essentially generates a transaction file. These records are evaluated, resulting in changes to an individual’s record, such as an update of an applicant’s admissions status for applied to accepted.

Communications Management: Manages contacts sent to individuals who inquire or apply to the College. Plans are customized by curriculum, high school/post-high school status and available time between initial inquiry/application and the start of the semester. The application generates files of data to merge with various MS Word letters to produce material sent to prospects and applicants. The creation of merge files is done by the Admissions offices. Letters and mailings are originated in the Admissions office. Any additional items, such as curriculum brochures, are listed for inclusion in the mailing.

Reporting: Runs various on-line reports available within the Inquiry and Admissions populations from menu selections. Reports are available within admissions offices and allow the entry of various parameters. Reports are designed by the Computer Center.

Cognos Ad-hoc Reporting Tool – Periodic and Ad-hoc reports created and run by Central Admissions.

MS Query Reporting – Periodic and ad-hoc data extractions imported into MS Excel for data analysis and report generation.

CARS Computer Center Support Activity: Semester Registration Status Batch – Back feed of registration status into CARS status

field.

of 73

File Updates – Manual updates of tables of available curriculums, semesters, academic calendar dates, CEEB files, etc. done by System Administrator

System Backups and Database Maintenance Error Reports of Data Entry Problems – Daily Cognos reports run by the computer data

control area against the database, listing possible data entry problems such as birthdates that are out of specific ranges, contacts that have not updated properly, etc.

of 73

CARS Admissions Module Diagram

Functionality: CARS Admissions Module Diagram

Subsystems: Prospect management, Admissions evaluation, Communications Management

of 73

AdmissionsContains Various

Tables

InquiryContains Various

Tables

InquiryVarious Screens

AdmissionsVarious Screens

Communications ManagementTickler Plans

Automatic Contacts

LettersBrochuresPhone Calls

Contact Management

Academic Affairs

Functionality:

Master Schedule Production: The main function of the Academic System is the creation of the Master Schedule for upcoming semesters. Several months before registration begins, schedules are rolled over from the previous semester. Departments work from this file, verifying course offerings, adding new or deleting prior offerings as needed; and updating instructor, dates, times and rooms for each section. Information is downloaded from this file and added to course, program and boiler-plate descriptions to produce various registration publications. Non-credit course information for brochures are not derived from the Master Schedule as non-credit courses are not entered early in the process. Non-credit course information for publications is provided directly by the department.

Master Schedule Information contains course credits, ancillary fees, seat limits, and prerequisite information. It is used within the Registration System to produce registration records for students, which are stored within the schedule and roster files.

Files contributing to the Academic System include PERS (personal records), Catalog table (list of the course catalog for a particular year) and the legal rooms table. The latter references locations by room number, building and campus. The combination of each provides a unique location; however, the room numbers themselves (which are the main location designator within the master schedule) are not unique. For example there are buildings with the “H” designation on both the Ammerman and Grant Campuses. As a result, there may be may two classes scheduled for room H100 at a particular time - one on the Ammerman Campus and one on the Grant Campus.

Academic Affairs Applications:

MSOL - Maintains class schedule. Verifies previous sections after roll-over, adds new sections and deletes sections. Assigns instructors and rooms. Creates MSCHED for the particular semester which procudes the semester room book. Does not show conflicts in room use. Conflicts show up when Room Book batch report is run. Some conflicts are not errors (i.e. combined sections).

INST – Inquiry program to show instructor schedule, both overload and normal.

ROOMS – Inquiry of Available Rooms by Semester , Day and Times.

of 73

Academic Affairs System Runs:

Roll Over – Advances semester schedule from one semester to the next (i.e. previous spring to next spring, previous fall to next fall, etc.).

Assignment Letters – Batch printing of letters to faculty of courses they are assigned to teach.

Room Books – List of room utilization for academic classes. Also used to identify where scheduling conflicts may exist.

Class Schedule Downloads – Extractions used to produce printed schedules for various publications.

Custom DE Letters – Letters sent to Distance Education students providing orientation information

Update of Course Catalog Prerequisite Table – Annual update of prerequisite table to coincide with the new catalog.

Schedule D payroll Information for Adjuncts and Overloads – Download that goes to the county to pay adjuncts and full time staff working overloads.

Updates for Seniority List - Current class assignments. Seat Limit Adjustments - System wide changes done in batch to the maximum

allowable number of students in a section. Ad-Hoc Reports

of 73

Academic Affairs

Subsystems: Master Schedule, Prerequisites, Instructors

of 73

MSched

PERS

INST

XPIN

Edit &

Batch

update

MSOL

Since ’89 by Semester

InstXRef

LegalRooms

Catalog>1989

CatalogXRef

ScheduleD

PreReqTable

Since ’89 by Semester

Batch

Room book &Error report

BatchSeat Limit Adjustme

nt

RoomsBatc

hBatc

h

AssignmentLetters

Batch

Class Schedules

Catalog Yearly Update

Available Rooms by Semester , Day, Times

Seniority

Roll Ove

r

Advisement System

Functionality:

The advisement system is made up of two main components, evaluation of initial remedial requirements and course progress evaluation toward completion of a student’s course of study.

Remedial Evaluation: The College tests students during the admissions phase to determine placement in Reading, English and Mathematics courses. Students are evaluated using standardized placement tests along with an essay. Scores of these are posted manually by advising staff in the application, UNIT. Based upon test and essay scores, advising staff will assign remedial course requirement or no requirement to individual students. This information is stored in UNIT and History, and determines the courses a student may register for.

Progress in a Curriculum: Degree audit is accomplished in the application SAIN. SAIN lists courses completed, in progress and remaining based upon the catalog a student has matriculated under. The application contains academic rules and program and course equivalents that go back to 1980. Maintenance of these tables is done by the Computer Center based upon rule changes established by the Office of the Vice President of Academic Affairs. At the current time, academic rules allow a student to use any catalog beginning with their first date of matriculation in their curriculum and moving forward to the current catalog. Program and course equivalents for each catalog year are stored in the CURRIC file. The creation of new catalog years is done through a roll over and edit of the previous year catalog by the Computer Center from data provided by Academic Affairs. The new entries are then updated to the file using a batch application.

Various versions of SAIN are available that provide information based upon the semester selected for the evaluation. GRAD SAIN is a version of the program used in Central Records for graduation evaluation. SAINSUM is used in Billing/Financial Aid to determine whether the courses for which a student is registering are eligible for financial aid based upon a student’s curriculum. Bills are adjusted to reflect Financial Aid status against SAIN.

A web interface to SAIN is available to students so they may review their progress and also determine how courses would meet degree requirements should they change their major.

Advisor Maintenance: The advisor assignment system is also part of the Advising System. ADVI is the application that identifies advisor availability from semester to semester. Students’ assignment of advisors is a batch process that requires several iterations to assure a balanced ratio of students to advisors. The system currently assigns

of 73

students appointments with their advisor prior to registration. Previously, appointment letters were generated by the system. An upgrade generates form letters that inform students where advisor / appointment information is available to them on the web. Advisor assignments are stored in students’ historical records.

Advisement System Applications:

UNIT – Posts placement test scores and class placement (EG10, EG11).

ADVI – Updates advisor availability for semesters.

SAIN - Student advisement and degree audit system. Provides lists of course progress by major and catalog year.

SAIN SUB – Utility application that provides SAIN data to other applications, such as Financial Aid and billing.

Advisement System Runs:Catalog year update of CURRIC file – XPIN-based creation and edit of new catalog from a roll-over of the previous catalog year file.SAIN Updates - Catalog year update of course equivalents and curriculum rules for use inside the SAIN applications.Advisor assignment lists - List of the previous spring’s advisor assignments for review and return of current available advisors for Computer Center entry. Advisor assignment run/review/rerun process continued until final assignments are set.Batch update of advisor assignments to History.Notification of a student’s advisor via letter and MySCCC.

of 73

Business Office System Functionality:Billing: The core component of this system is Student Accounts, which is a table of transactions that adds account debits or credits. For semester items, students are assessed a semester bill based upon the registration record of credits and course based fees. Semester bills are currently paid using the application CFUP. Semester bills can be paid in person or using one of the College’s automated payment systems (telephone, Web, or mail-in lockbox.) In-person payment is integrated to student accounts by a point-of-sales cashiering system (the SalePoint J-Point application). Non-semester items also appear as transactions within Student Accounts. These include traffic fines, outstanding charges from prior semesters, one time fees (application fees, CLEP fees, etc.), late fees, tuition payment fees and bounced check fees. These use the applications SAUP and TVUP listed below and may only be paid in person. Assessment of a student bill includes an interactive connection to Financial Aid and the application of an assortment of rules based upon things such as in/out of county status, course insurance requirements, Full or Part-time status, senior citizen status, etc.

Applications:

CFUP – Inquiry and Pay Semesters bill. This is based on an existing invoice created via Sched/Bill.

SAUP – Inquiry and Payment of roll-over charges from previous semesters and one-time fines/charges.

TVUP – Inquiry and payment of traffic violations.

PLAT - Inquiry and update of license plate for individual students.

Sched/Bill – On-line list of a student’s current classes and current semester bill. Calculates the bill and generates an invoice from credits taken, lab and other fees and any exceptions to the standard rules. The invoice is what a student pays against in CFUP. Also will recalculate bill based on a request to use the TPP. The on-line version is also called as a subroutine in the Web payment applications to allow payment and invoice generation. Batch version is used to print sched/bills for mailing.

Business Office System Runs:

Tuition and Fee Update Verification of Tuition and Fee update to Financial Affairs (New) – Report back to

Financial Affairs showing tuition and fees data within the system for validation. ESL Dart - List of ESL fee by section for the upcoming schedule. Tuition Payment Plan (TPP) Update of rules and dates for the upcoming year.

of 73

Batch Schedule Bill – Batch hard copy print of combined schedule and bill that goes to students who have schedules as of the bill print date.

Interim Schedule Bill – Combined schedule and bill sent to students when they add or drop a course. In use after the batch process has been completed.

Schedule – Interim schedule sent to students after they have added or dropped a course but prior to the issuing of schedule bills. Shows an estimated bill.

Lock Box (Payment update from bank, Web) Batch processing of payments files received from lock box vendor (bank) and also files of automated payments made through the Web or the phone.

Mismatch and Mismatch Auto Post – Batch run that identifies the differences between a student’s payments and what they owe. This produces bills and, at roll-over, posts the debit in student accounts for any money still owed.

Automated Refunds – A version of mismatch that produces refunds for students who have over payments.

Cash Flow Report - Summary of Charges and payments for manual update. Grand Master - Transaction level detail of charges and payments. DMV Match - Search through the DMV records to match traffic violations from cars

without college stickers to students at the College. TPP Warning Letters and Overdue Notices Cash Check – Routine that reviews a student’s semester payment status. This is used

during the descheduling process to identify students who have no cash flow (any payments against their current schedule).

Charge Runs – Overdue and dunning notices timed to coincide with the arrival of aid and various other due dates.

Check Runs – Production of Financial Aid checks to be sent to students and the College from the Feds and HESC.

Check Voids – Processing of returned checks.

of 73

Business Office System

Subsystems: CFUP, SAUP, TVUP, Check Runs, Charge Runs, Miss match, Auto Refund

of 73

Invoice

BatchUpdat

e

CFUPw/TPP Update

Plate

DMV

Look up

Student Accounts Traffic

Hist

ShadowPost

DMV(ext)

POS

ADMUSAUP

MySCCC

Lockbox

TVUP/TVIQ

Sched

PLAT

MSchedFAIDHIST

SAINSUB

Add/Drop

Tuit & Fees 2

CreditCardTrans

OfficeSemester Bill

BatchSemester Bill

Class list w/minimal bill info

WarningDunning

Charge Run

Cash Flow Report

TPPNotic

e

Warning

Fin BlockDesched

MySCCC

CASH

Check

Miss Match

&Auto

Refund

For no sticker, ID

Student from Car owner

CheckRuns

IFMS

Manual Entry

UpdateManual Entry

Batch

Tuit & Fees 1

Sched/Bill

ZSA Void

Check Void

Dent

Financial Aid System

Functionality:

Financial Aid Packaging:

Through the mainframe system, a batch process provides data received from the U.S. Department of Education to the FAST file for all students who indicated any of the three campuses in their college plan. It also batches data to the CARS system for all students who have indicated one of the campuses and have not applied for admission. This batch file is treated as an inquiry in the CARS system. The FAST file then moves student data (all students who have a History File with College) to the FAID system where a student record is created for Financial Aid packaging. The FAID file is the hub of the financial aid process. It contains data not only from U. S. Department of Education but data from various college department application files on the mainframe system. (i.e. Admissions, Registrar and Student Accounts). It also retrieves and accepts data from outside agencies such as the National Student Clearinghouse and New York State Higher Education Service.

Applications:

FAST – Student data is received twice weekly from the U.S. Department of Education central processor. All data is uploaded to the college mainframe into the FAST file. Those students who have a history file are then fed into the FAID system. All students who do not have a history are batched and moved into the CARS system and treated as inquiry. All FAST records are checked for history with each upload to the FAID system.

FAID – The FAID file is the main packaging feature for awarding financial aid. It has the ability with the use of hot keys to manually package student financial aid. It is also the area the auto-packaging program looks to for electronic packaging student financial aid and or the creation of missing information letters to individual students. The FAID file gather information from Admissions and Registrar (enrollment status (SCHED), Matric code, High School Diploma, GED, Ability to Benefit Test, Eligible Courses, Title IV/TAP academic blocks etc.).

FAIQ – This is a mirror image of the FAID file with viewing rights only for various departments within the College (i.e. Business Office, Counseling, Admissions).

of 73

FATR – This is a student financial aid history file. Notes financial aid received for both Grants and Loan information. Also, collects information from Admissions as to previous college attended.

TAPA – Student status rosters are received weekly from Higher Education Service Corporation (HESC) and uploaded to the TAPA file. This information is then moved into both the FAID file and to SAIQ (student accounts) as a tentative TAP award and creates a deferral item on the bill.

TAPI – At the point of TAP certification, all state data elements (Student TAP history, points etc.) are checked and a batch file is created for electronic transmission to HESC. TAPI provides information for financial aid staff and allows for certification or changes to a student’s status.

Financial Aid System Runs:

SARA – uploads Auto-packaging/Missing Information Letter – Batch Process Origination File – Sent to U. S. Department of Education Disbursement File – Sent to U. S. Department of Education Commonline Application Send File – Sent to HESC Commonline Application Response File – Sent to HESC Grant Transmittal (Reason Denied Aid) – Report of students paid and exception list Missing Roster – Batch file Label Program – Mailing of students not eligible for aid Label Program – Mailing of students requesting Entrance Interview Posting of actual for EFT funds Bookstore Roster (download) TAP Student Status Roster (upload) TAP Payment Certification/ Error Report ZTAP11 TAP Actual Posting via Remittance Advice received from HESC/TAP Run WSR – Waiver Screening Report (Sets Financial Aid Status for future semesters) R2T4 - Return of Title IV Funds – Captures information on student withdrawal National Student Clearinghouse Report – Federal Regulation - Student Enrollment

Status FISAP – Fiscal Operations Report and Application to Participate for Campus Based

Aid Ongoing Request – various reports statistical and or student mailings (i.e. mailing to

students prior to new academic year)

of 73

Financial Aid

Subsystems: Federal Awards, State Awards, Transmittals, Auto Packaging

of 73

FAID/FAIQ/FATR/FAST

FAID

From Fed

SAINSUB

SchedMissRostersOrigSAINSUB

Batch

of 73

TAPI(ext)

Batch

Tap Hist

TAPI/TAPA

T3ADM

ZTAP14

From HESC

EFT(ext)

Origination(ext)

Batch

Batch

WSR

SARA(ext)

FAID103Updates Actuals

FAD102D

FASTStudent Profile

Student Funds

Hist

On-linePackage

Student Accounts

AutoPackage

Confirm Attendance

Book-store list

Book-store

PELL

Disbursement file - Fed

Personnel System

Personnel Applications:

PERS – Create and updates employee personnel profile.

PNAME – Inquiry of PERS by name.

TAMS/FGAC – Inquiry/update of time earned and used (available time is computed in batch based upon Time Accrual rules).

CWSP – Create and update College Work Study and some overload records (Counselors). Updates time card information to produce bi-weekly check.

Personnel System Runs:

Time Card Labels Time Accruals Letters County Upload from PPS of what has been paid out to employees TRS retirement system data reformat and return to county NORA Eligibility Lists NORA Upload Faculty Seniority Lists Biweekly Positive Payroll Register (CWSP) Ad-hoc lists, labels of directory information

of 73

Personnel

Subsystems: PERS, Time Accruals, Seniority, NORA

of 73

PERS

PERS

CountyDownload

(ext)

CWSP

PName

Batch

ID Cards Subsystem

CWSP

TAMS

TAMS

FGAC

FGAC

Time Cards

CountyPayroll(ext)

BatchRe-Format

TRSFile(ext)

NORAINST

Since ‘70

TRS file Prep

temp

BatchSeniority

Msched

Report

BatchPayroll

Payroll

FAID

AME FacultyGuild / Exempt

Work StudyCounselors

Adjunct Requests

FT & PTSeniority Lists

Bi-WeeklyPayouts

Batch Create

Update time by

rules

Update time by

rules

Registration System

Functionality:

Academic Affairs coordinates the production of a master class schedule. Students register for classes using the Web, the phone or in-person using Add/Drop. A registration for a class produces two records, one in a Roster file and one in a schedule file. These records are essentially the same; the only difference is the use of the files. Roster is arranged by sections. Schedule is arranged by student.

Students begin registering for classes during priority registration. Access is linked to dates entered in Add/Drop and the file of student eligibility. This file is produced prior to priority registration and is based upon the number of credits a student has completed toward a degree and the first letter of their last name, with the earlier days being opened to students with the most progress. The file also produces notices that go out to students.

Add/Drop is linked to prerequisite requirements and waivers, registration status/blocks, matriculation status, course history etc. During the registration process, it will also provide alternate sections should a student attempt to register for a course that is closed. There is also a web display of seat availability that a student may access prior to registering.

Students keep their schedule until walk-in payment due date. At that time a student will loose their schedule if they have not made a payment against the current semester. Descheduling is rules based, and excludes certain populations at certain times, in particular, those that have specific financial aid statuses. There is also a way for administrators to exempt students from descheduling by adding them to the hold list. This is done using the HOLD application.

Student’s attendance is recorded through attendance rosters primarily submitted over the web. Grades are submitted via grade rosters also primarily submitted by faculty over the web. Various Computer Center batch runs are done to process roster files, post and report on enrollment status, post grades, screen for prerequisite progress/status and remove students from upcoming courses should prerequisite progress requirements not be met.

Registration System Applications:

Add/Drop – Updates student registration and roster status in individual sections. Evaluates registration rules (pre-requisites, blocks, matriculation status, and priority registration status) to allow registration access. Provides alternate sections when requested section is closed. Lists general semester bill, including total charges, amount previously paid, amount previously refunded and amount remaining.

of 73

ROST – Inquiry of student in particular sections.

SCHED – Inquiry of sections for which a student is registered.

TRAN – Transcript by student, including courses taken or transferred and courses in-progress.

HOLD – Creation and maintenance of the list of students who will not be descheduled during the next descheduling event.

Registration System Runs:

Identification of Student Progress for Priority Registration - Batch run done prior to priority registration that establishes a student’s degree progress and assigns access to the registration system.

Daily Descheduling – Descheduling run in batch each evening after the walk-in payment due date, removing from the schedule students who have not made a payment against their semester schedule and who are not by-passed based upon exception rules of a hold list.

Financial Descheduling - Run after the due date of the final Tuition Payment, removes from the schedule students for an upcoming semester who have failed to make final payment on their current TPP obligation.

Grades Prep Run – From grade rosters files (received from web or bubble sheet), checks for valid grades and formats grade file for uploading to the course file.

Grade Posting - Post Grades to course file and upgrades the matriculation status of students on probation or with developmental status, based upon course performance.

Prerequisite Screening – Check for completion of prerequisites after grades have been posted. Identifies courses registered for in the upcoming semester that do not have the needed prerequisite because an in-progress course was not satisfactorily completed. Sends notice to students of problems.

Prerequisite Descheduling – Removal of students from upcoming courses because an in-progress course was not satisfactorily completed.

Missing Rosters list – Report on missing rosters also integrated into the Financial Aid process to exclude students from progress evaluation if their instructor failed to submit a roster.

Print Grade Reports – Hard copy sent to students. Waiver Screening Report Headcount Extractions – regularly scheduled data file transferred to the Institutional

Research server for enrollment reporting. Faculty Workloads Reports Class Utilization Reports

of 73

Ad-Hoc enrollment reports from Roster/Sched

of 73

Registration

Subsystems: Add/Drop, Schedule/Roosters, Prerequisites, Deschedule, Hold, Grades

of 73

Rost

ADD/Drop

Contains all courses, Students and grades since ‘60

Sched Course>1960

Pre-ReqWaivers

1 set for each Active Semester

HistMschedApptPreReq TableStu Acc’ts

MySCCC

Hold

Hold

BatchDeschedules

FAID

FacultyWeb

Enrollment Verification Grades

BatchBubble Sheets

PrepFile

Batch Rost Grades

Failed Prerequisite

Paid?

MYSCCC

Schedule of available classes

Student’s schedule Add & Drop classes Alternative sections

RemindersPost CardsLetters

HeadCountExtractions

IR Database

Cash Check

Missing Rosters

List

Missing Rosters

FAID ProgressExclusion &Check Run

PreReq Screen Grades

Inc Roster

ListRost

Sched

TRAN

History (Matric status update)

Priority Reg Run

RegistrationAccess List

Establishes when a Student may register

Mainframe System Interconnects

Applications/Batch Data Exchanges:

CARS – Admissions and Recruitment Relational database system with communication management and tickler. Manages prospects and applicants through acceptance. Applicants are transferred and updated to the mainframe ADMU/A and History fines in batch.

Sign-in database –Extraction to MS SQL of Sched file, used with MS Access program in the computer labs to track a student’s use of these facilities for State FTE aid.

SUNY Library System Patron Update – Batch extraction of Sched file and PERS to patron file for upload to SUNY Library system patron database.

SUNY Learning Network and SUNY Course Space - Course management systems hosted by SUNY to provide distance education offerings to SUNY and SCCC respectively.

Institutional Research Data Warehouse – Extractions of registration information used for enrollment reporting and IPEDS reports.

IFMS GL – Data report showing Grand Master spread for manual keying into IFMS relational database application.

Payroll Download – (Schedule D) Extraction of adjunct and overload information to go to county for payroll update.

External Systems Interconnected:

SNA Server - PC based terminal emulation system used to provide PC access to mainframe applications. Extra is used as the PC based client.

Feith - Relational database Document Imaging system. Links to mainframe information is provided by a PC application (using a type of screen scraping) running through Extra/SNA server. This is used both to index images stored in Feith and to retrieve images for a particular student while in the a mainframe application on the PC.

POS – Jpoint point-of-sales system using IP-based terminal emulation thorough IBM websphere server. Access and updates mainframe data using a version of the mainframe application CFUP. Implemented in the cashier’s offices for live payment of semester bills by students.

of 73

MySCCC – Web-based TCP/IP interface into Mainframe. Uses custom written connectors to allow Web access to mainframe applications for registration, bill payment, transcripts, available sections, student schedule and grades.

Faculty Web WAF/Faculty Portal – Web-based TCP/IP interfaces into the Mainframe. Uses custom written connectors to allow Web access to mainframe applications for roster and grade reporting.

ID Works – ID card production system that uses Web-based TCP/IP connection to mainframe PERS and History application to retreive profile information for role assigment and card printing.

Active Directory – College-wide authentication and directory services system that uses TCP/IP connection to the mainframe for PIN and ID number link.

of 73

Mainframe System Interconnects

of 73

Mainframe

3270Emula-tion

TCP/IPNewPOS

Starrs(Web)

IDWorks

Batch

CARS

Batch

Sign-in Db

ActiveDirectory

AdminAuthentication Services / Email

StudentAuthenticationPortal/E-mail

Batch

SUNY

Lib Sys

Batch

Black-board

Batch

Inst,Research

Batch

IFMSG/L

ProspectsAdmissions

RegistrationInfo

RegistrationInfo

Bill Pay

Registration& ScheduleInfo

Bill PayInfo

RegistrationBill PayAdvisementClass- Schedule

RegistrationPersonnel

SNAServer

PC Terminal Services

Feith

ProspectsAdmissionsStudent Records Index/Link

PC ExtraScreen Capture

Batch

CountyPayrollTIAA

PersonnelRetirement Info

Faculty(Web)

RostersGradesNORA

SCCC’s Network Infrastructure

The College’s network system consists of individual campus data networks connected via a College-wide WAN. The campus networks include external connections to county and state entities, the Internet, dial-in services for faculty, administrators and staff, and a number of POTS lines carrying modem traffic.

College-Wide WAN:

TLS Service: The College's main WAN connection among its campuses is provided through Verizon’s 100M TLS service. The connection is organized in a “logical triangle” topology with each campus accessing the TLS cloud through a 100M fiber optic feed. The connections are the primary data/video intercampus links and allow for peer-to-peer communication from any campus to any campus.

Additional Connectivity: Modem circuits, backup data and connectivity to external entities occur over separate links by campus as follows:

The Riverhead campus maintains additional connections to the Selden campus via two T1s (one is dedicated for data backup and the other is for voice) and has a 56kbps leased line for mainframe access. There is a dedicated T1 circuit with AT&T which provides campus-wide Internet access. There are also POTS lines for credit card devices and 16 lines available for faculty and administrative data dial-in services.

The Brentwood campus maintains additional connections to the Selden campus via two T1s (one is dedicated for data backup and the other for voice) and has a 56kbps leased line for mainframe communications. The Brentwood campus has two dedicated T1 circuits for Internet access. There are also POTS lines for credit card devices and a separate T1 circuit to provide Internet access to the Event/Convention Center.

The Selden campus has the mating end of the data and voice circuits from the Brentwood and Riverhead campuses. Thus, Selden has a total of four point-to-point T1 circuits and two 56kbps leased lines. External data network connectivity includes a 384kbps link to the Suffolk County Network, one T1 to SUNYNet (the State University of New York’s Intranet), three T1s to AT&T for host Internet servers and general campus-based Internet access, one T1 for faculty and administrative dial-in services (24 ports @ 33kbps), and POTS lines for credit card devices.

College Data Network

of 73

The College Data Network is made up of three WAN nodes (one per campus). Each node is comprised of a Cisco 37xx router and a Cisco 6509 core switch. The switches connect to each other by the 100Mbps Verizon TLS fiber optic lines, and the routers are interconnected by the point-to-point backup data T1s (see WAN Network). The routers are connected to the core switches by two 100 MBPS feeds.

The switches are attached to the surrounding buildings on the campus via 100Mpbs copper or fiber optic lines. The topology varies by campus: Riverhead is a ring with three buildings, Brentwood has a core node and two sub-nodes (e.g. each node acts as star for several buildings (5/7/3 buildings respectively), and the Selden campus is a giant star with 17 buildings.

The Computer Center is on the Selden campus and houses the main college router and the attached routers for SUNYNet, AT&T and Suffolk County. It also houses the server farm and mainframe. As a result, the main campus switch is located in the Computer Center. The core switch is a Cisco 6509 with 16 ports of 1000 MPBS fiber, 24 ports of 100 MPBS fiber connections and 72 ports at 10/100 MBPS. Subnet switches provide connections to the server farm and IT support staff.

Each building on a campus is connected to the campus core switch by either a 1000 MPBS fiber or a 100 MBPS fiber connection that terminates in the building's basement or primary wire closet. On the Brentwood and Riverhead campuses, the campus core switches all use 1000 MBPS fiber trunks. The Selden campus has multiple 100/1000 MBPS feeds for several buildings that have very large user counts or have high-priority traffic.

The building switch will connect directly to all users in the building (small structures), connect to wire closets on each floor (medium structures), or connect to individual server/wire closets (large buildings and academic labs). Currently, the user data ports are connected to Nortel 450-24tx switches. Academic and administrative labs are connected to the network via small routers (Cisco 800 series) that provide bandwidth limitations, simple firewall services, and IP management services (DHCP & NAT). Academic labs vary from small labs with 8 devices (computers & printers) through large multi-room centers with over 150 devices. There are three large centers on the Selden campus (ACC, Comp. Sci, & Elect. Tech.), three on the Brentwood campus (ACC, LSC, Comp. Sci.), and two on the Riverhead campus (ACC & LSC).

Wireless: The College currently maintains several dedicated wireless access points for specific labs and uses. It is in the process of adding a general purpose system for students and faculty with personal laptop computers. For each campus, multiple access nodes (AC) will interconnect to a campus-based wireless network switch. The wireless switch will provide DHCP, user authentication, and access point management for browser-based

of 73

services. The ACs are currently located in the Library and Student Centers with additional spaces to be added over the next few years.

On the Brentwood campus, there is a separate wireless network in the Field House connected to the Internet directly via a dedicated T1. The wireless network provides connectivity for events and conventions.

Dial-in Access: As listed in the WAN section, faculty and staff have dial-in access to the internet and College servers. The Selden campus has a T1 connected to a Shiva server. The Shiva has 24 ports supporting V.90 modems. The Riverhead campus has two 8 port Shiva servers with the same modem support..

End of Text of Section III

of 73

Section IVCost Proposal

The Cost Proposal should not be submitted in the same package as other items required by this RFP, but should be in a separate sealed envelope labeled “Cost Proposal.”

Note: The College reserves the right to select all or portions of a Vendor’s Proposal.

Based on the evaluation criteria please note that the College will not necessarily choose the Vendor with the lowest rates for Products/Services.

System implementation may require multi-year-phased installation of application modules based on available funding, College resources, and the Vendor’s recommended approach.

Alternative approaches are welcomed and will be evaluated provided that:

(i) they are submitted in the same format as outlined in this RFP; and

(ii) Alternative Cost proposals for such solutions are also submitted.

Provide separate estimates for each item that you are providing assistance plus a summary.

of 73

Section IV: Cost ProposalSub-Section 1: Implementation/Installation Support Costs:

Note: The cost of each phase should include all costs associated with that phase including travel, meals, lodging, etc.


Implementation/Installation Support costs are defined to include costs for the following:

1. Hardware/Software Installation and Testing

2. System Design/Modification – Each area of the College’s requirements identified in Section III(6)(a), Specialized Functionality, must be included in this section.

a. an item number (identifying the requirement),b. the number of hours required to implement the modification,c. the cost associated with the modification.

3. System Table Design and Implementation

4. Data Conversion (Variable years of historical data)

5. Interfaces

6. Pre-Production Testing

7. Post Implementation Support


of 73

Section IV: Cost ProposalSub-Section 2: Project Management

Note: The cost of each phase should include all costs associated with that phase including travel, meals, lodging, etc.


Project Management costs are defined to include costs for the following:

1. Project Management $ _____________

2. Project Planning $ _____________

3. Procedure/Re-engineering Definition $ _____________

4. Training (User and Technical) $ _____________

5. Post Implementation Services $ _____________

TOTAL $ _____________


of 73

Section IV: Cost ProposalSub-Section 3: System Software Costs

Provide detailed acquisition cost estimates for System Software, including license fees as applicable:

Provide separate estimates for each item plus a summary.

System Software costs is defined to include costs for the following:

1. Operating System(s) Software

2. Database Management System(s) Software

3. Compilers

4. Utility Software

5. Ad hoc query and reporting tools

6. Frequency and cost for software updates, if not included in Support/Maintenance set forth in Sub-Section 6

7. Other – describe in detail

8. Summary of all System Software Costs

Note: License fees are deemed to include all associated technical documentation and support. Indicate any restrictions. Indicate pricing per year for the first five years.


of 73

Section IV: Cost ProposalSub-Section 4: Application Software Costs, Including License

Costs

Provide detailed acquisition cost estimates for Application Software (which includes cost for the source code).

Provide separate estimates for each module plus a summary.

Application Software is defined as the Vendor supplied software for the functional requirement set forth in Section X, entitled “Application/Functional Requirements.”

Application Software costs are defined to include costs for the following:

1. Application Modules

2. Frequency and Cost for software updates, if not included in support/maintenance costs set forth in Sub-section 6.

3. Other – provide detail (e.g., Document Imaging, Cashier/Point-of-Sale, and/or other requisite third party software.

4. Summary of all Application Software

Note: License fees are deemed to include all associated technical documentation and support. Indicate any restrictions. Indicate pricing for the first five years.


of 73

Section IV: Cost ProposalSub-Section 5: Hardware Costs

Provide cost estimates for all Hardware configurations needed for the installation of the proposed System.

Estimates should include the Summary Costs for all items identified in Section IV

1. Server Configuration

2. On-line Storage Solutions

3. Off-line Storage Solutions

4. Printers for Mass Print Solutions

5. Other Hardware Costs

6. Installation

7. Shipping

8. Summary of Hardware Costs

Vendors must include hardware recommendations (and should include associated estimated costs for same) as the System will not be installed on the Department’s current hardware.

If the Vendor can arrange for acquisition of the hardware, the Vendor should so indicate. The Department, however, reserves the right to procure hardware via New York State purchasing contracts or from such other sources as the Department deems appropriate pursuant to competitive procurement policies.


of 73

Section IV: Cost ProposalSub-Section 6: Support/Maintenance Costs

Provide detailed cost estimates for Support/Maintenance costs, including:

6. Hardware

7. System Software

8. Application Software

Indicate for each category the following:

1. Year

2. Item

3. Number of Units

4. Annual Maintenance Fee per Unit

5. Total Annual Maintenance Fees

6. Indicate for each whether costs are fixed or estimated.

Project the Support/Maintenance Fees for each item, from the end of the warranty period until the fifth year, broken down by year.

of 73

Section IV: Cost ProposalSub-Section 7: Summary of All Costs

7(a): Summary of Costs by Cost Category

Provide a summary of the costs associated with the entire project. The total cost identified with each of the sub-sections included in Section IV should be represented in this sub-section.


1. Implementation/Installation Cost $ ____________

2. Project Management $ ____________

3. System Software Costa. Project Planning $ ____________b. System Design/Mod $ ____________c. System Table Design &

Implementation $ ____________d. Procedure/Re-Engineering $ ____________e. Training $ ____________f. Data Conversion $ ____________g. Interfaces $ ____________h. Pre-Production Test $ ____________i. Post Implementation $ ____________

4. Application Software/Source/Code/License Cost $ ____________

5. Hardware Cost $ ____________

6. Support/Maintenance Cost $ ____________

7(A) Total $ ____________

7(b): Summary of Costs: By Category by Year for Five Years

(Insert Table Here)

End of Text for Section IV

of 73

RFP: Records Document Imaging & Management System:€¦ · Web viewWeekly Master File Update –...

Documents

Transcript of RFP: Records Document Imaging & Management System:€¦ · Web viewWeekly Master File Update –...