ATTACHMENT II - WRITTEN PROPOSAL RESPONSE AND GUIDELINES RFP#CON2014-18 Attachments I through VI from the Response Teams will be evaluated and scored (1000 points total) in accordance with the criteria below (refer to RFP, Section 3.3.2): Response Team Experience (150 points): A weighted score of the total experience provided in the three (3) prior project references submitted in Attachment I Experience Workbook. Quality of Written Proposal (25 points): 1. Conformance with and applicability of information to RFP requirements; 2. Clarity of organization and exposition; and 3. Overall quality and consistency of presentation, including completeness and accuracy of information. Content of Written Proposal (825 points): 1. Executive Summary (50 points) Write a brief narrative that provides a high-level summary of the Proposal. Include a general discussion of the Response Team's understanding of the overall project, the timetable, the scope of work proposed, a summary of the Proposal's major assumptions, and a summary of the features of the proposed software product. The summary shall contain as little technical jargon as possible and shall be oriented toward non-technical personnel. The Response Team shall provide a business case describing the increased value the City will receive from selecting the proposed integrated system. The business case should provide: Qualitative and quantitative reasons for implementing the integrated solution; Potential cost saving areas; Efficiencies gained/increased productivity; Service delivery improvement areas; Added value not currently available; and Missed opportunities of not implementing an integrated solution. The City is seeking Proposals that will clearly outline the advantages and disadvantages of the scope of the project. The Response Team should include an explanation of the risks associated with the project scope and detail their abilities to mitigate or minimize this risk. 2. Functional and Technical Requirements (200 points) Complete Attachment III Functional Requirements and Attachment IV Technical Requirements of this RFP by selecting a Requirement Description for each functional and technical requirement. The Response Team shall use the format provided and add explanatory details as necessary in a separate Page 1 of 11
spreadsheet, using the requirement number as a reference. The following answer key shall be used when responding to the requirements: Requirement Description FP = Fully Provided through the proposed ERP software TP = Third Party Software Required CU = Custom Development required NA = Not available Points 3 Points 2 Points 1 Point 0 Points A weighted score will automatically be calculated based on the Requirement Description selected for each requirement. If a Software Vendor is proposed in multiple Proposals, their Proposals to functional and technical requirements shall be standardized in each. 3. Project Plan (100 points) Provide a concise narrative for each of the implementation areas detailed below (Sections A through I). Unless stated otherwise, it is expected that the System Integrator will lead the efforts in each of these areas. A. Implementation Approach Explain how the System Integrator will implement the proposed software on-time, within the cost structure, and with the ability to meet the City s current and future needs. Include a discussion on any proprietary implementation methodology proposed for this engagement that will increase the likelihood of success and improve the speed of implementation. As part of the Project Plan scoring, define the expected roles and responsibilities of the City and the Response Team by completing Attachment V Implementation Services Requirements. B. Implementation Plan Provide a detailed plan for implementing the proposed system within the recommended timetable. This information SHALL include: Project organization chart (i.e., show the City and System Integrator staff); Overview of project management methodology; and Summary Work-plan, including a time frame for implementation by module and an estimate of work effort for the City and System Integrator (e.g., 50% City effort; 50% System Integrator effort). Note: The City s proposed organization structure is detailed in Appendix C Organization Chart. Provide the strengths and weaknesses of implementation methods (e.g., multiple rollout of modules versus Big Bang versus departmental, etc.) that the Response Team recommends for the City. Highlight methods that rollout the ERP software in the shortest amount of time. Additionally, based on the Response Team s knowledge of the City s needs, propose additional options/scenarios that may be of benefit to the City. Cover the following topics for each method and identify which method is the System Integrator s standard approach: Describe how this approach will allow the City to have early successes to enhance executive sponsorship. Page 2 of 11
List any other applications (e.g., middleware) that the Response Team believes would provide significant benefits and early successes for this approach. Provide a proposed project team structure and skill profile for the System Integrator s staff. The proposed project personnel should correspond to the project personnel detailed by the Response Team in Attachment VI Cost Workbook. Provide a proposed project team structure and skill profile for the City s staff. Provide a work plan with tasks and approximate start and end dates. These tasks should correspond to the Implementation tasks detailed by the Response Team in Attachment VI Cost Workbook. Provide a staff-loading chart for the work-plan by month, indicating anticipated staffing levels for the City and the System Integrator. Describe what has been successful using this method with other similar sized Public Sector organizations and why. Provide an estimated time for the implementation for this method. Provide any additional information that the Response Team feels would distinguish itself in its service to the City. C. Data Conversion Plan It is anticipated that data conversion will occur when migrating to the new application. The City would expect the System Integrator to take a lead role in managing data conversion activities, but will provide staffing to help identify and extract source data. Describe the general approach towards data conversion and how the System Integrator would work with the City to agree on what should be converted. Include information about database analysis and data mapping, conversion programs, data integrity checking/quality assurance, post-conversion clean up, and any methodologies used to keep data in sync between the new and legacy systems during implementation. Currently known data the City expects to convert includes but is not limited to: Beginning balances for GL accounts; Detailed financials for one year; Vendor information; Commodity detail; Open projects, grants and job orders; and Active procurement documents. D. Customizations/Modifications The City intends to customize as little as possible, but its research has shown that it can expect at least some changes and it may have less flexibility with adapting business process to software for some local, State, or Federal requirements. Identify the Response Team s approach to changes to out-of-the-box functionality in order to achieve the City s desired functionality. How will this be maintained for product release upgrades? What is the Response Team s recommended approach? What documentation is required for City staff to support updated business process changes after go-live? Page 3 of 11
E. Training Describe the proposed approach to training for the specific solution the Response Team is proposing and the requirements related to implementation of the solution. The overall strategy should include the nature, level and amount of training to be provided, by role. In addition: Provide detail related to the approach towards training of City IT staff on the application and tools. Provide detail related to the approach towards training of City project team staff on the solution. Detail the foundational skills that will be required to support the Response Team s solution. Include any required or suggested outside training that may be required. Provide a general schedule which defines when training is typically delivered in context to the overall implementation schedule (distinguished by role). Describe the training types and documentation provided: Detail the types of training to be provided (e.g., classroom, webinar, online, etc.). Detail the types of documentation that will be developed and provided to the City. Provide, by role, standard training information such as outlines, description of content, format, guaranteed outcomes or any other information that would assist the City evaluators in understanding the depth of the training provided. Describe the tools that will be used in developing the training material and any technical requirements needed to support the training materials by the City. Describe ongoing training opportunities post implementation. Provide detail on the training logistics: Define the physical and technical training requirements, by role, needed to effectively deliver the Response Team s proposed training approach. Describe any training that cannot be easily accommodated or is not practical to be performed onsite. Alternatively, the City is open to the Response Team conducting remote training via the Internet, but must understand the pros and cons of such an approach. F. Change Management Plan Provide a plan for detailing and communicating the business process redesign strategy and its impacts to the City s end-users, management and elected officials. The plan shall include the System Integrator s understanding of the current business processes and their anticipated partnership role with the City. The System Integrator shall also describe their overall change management plan (e.g., communication of process change, help/desk support strategy, etc.). Be sure to describe what aspects of change management are included in the Proposal. Describe the areas of the City ERP project that will generate changes to critical City business processes. How will the System Integrator assess the City and department readiness and what methodology will be utilized? Explain the process to resolve any shortcomings. Page 4 of 11
Describe what has been successful and not successful in using this method with other similar sized Public Sector organizations. Describe what aspects of using change management methodology that facilitates executive sponsorship. Given the number of parties involved in the implementation (both centrally and within the departments), describe the project governance structure for this approach. Estimate the level of change management support anticipated for this approach from a City and a Response Team perspective. G. Testing Describe the methodology for the following types of tests that are anticipated to be performed, including but not limited to: System Testing; Data Conversion Validation; Integration Testing; Stress/Performance Testing; and User Acceptance Testing (UAT). H. Fit-Gap Analysis and Process Reengineering Provide the process for documenting where the system can be configured to meet the City s current business processes, but where modification of the City process may be more efficient and cost-effective. Describe who (by role) from the Response Team facilitates the process, and who (by role) will help the City maximize the value of the system, assist in identifying areas for improvement, and has the skills to apply industry-best-practices business analysis. Include a description of deliverables that will be developed as part of operational redesign. Describe what aspects of using business process re-engineering methodology that facilitates executive sponsorship. Given the number of parties involved in the implementation (both centrally and within the departments), describe the project governance structure for this approach. I. Risk Mitigation Strategy Identify the risks associated with the Response Team s implementation plan (for the recommended timetable and any alternatives proposed) and detail its plans for mitigating or minimizing such risks associated with the implementation of the proposed system as detailed in the project scope. 4. Proposed Software (50 points) A. Proposed System Overview Describe at a high-level the key benefits of the proposed system, and how it differs from competitors systems. All software identified in the written proposal should correspond to the software items identified by the Response Team in Attachment VI Cost Workbook. As part of its Proposal to this RFP, the Response Team shall provide information related to the technical platform, system architectural information, security, documentation, training, and future technical direction of product, including but not limited to: a) Licensing Define the type of license and provide definitions for each type of license being proposed. Page 5 of 11
b) Technologies Employed Provide a summary of technologies used by the proposed systems as it relates to this RFP. Include the application software, database, and hardware components needed for System. c) Architecture Provide in a high-level diagram and accompanying description of the architecture of the System, which should include, but need not be limited to: user administration, firewall, data transport security (e.g., VPN, SSL, etc.), backup, secure access, auditing, log files, and remote access. d) Release Versions Provide a comprehensive description of the proposed System including: release and version, a list and description of the subsystems or modules, batch processes, and Business Intelligence included in the system. Provide a description of future technical directions, improvements, and features intended for the next release. e) Additional items Describe any other material items not specified in the above requests which are required to install, customize, maintain, and run the proposed System. f) Hardware Specifications Although it is not required that Response Team include acquisition or installation of hardware and network changes in their Proposal, it is required that Response Team provide a detailed description of all necessary and recommended hardware, software, and network changes that will be necessary to effectively operate the proposed solution in an optimal manner. g) System Performance The City desires the system to be available 24 hours per day, 7 days per week with an expected uptime of 99.9%. Indicate if there are periods when the system is unavailable, and/or if performance/response will be severely degraded due to other concurrent processes. What additional hardware resources or architecture may be necessary to eliminate or reduce periods of system unavailability, if any? B. Third-Party Products/Software Provide the name of any third-party products that are part of the proposed solution to the City s list of requirements. For each third-party product, provide a statement about whether the Response Team s contract will encompass the third-party product and/or whether the City will have to contract directly with the third-party for the product. Describe any software products that are being proposed to provide required functionality. Include a description and the cost of any products, features, level of integration, upgrade process, or other value added components available for use with the proposed financial system that have not been specifically requested in this RFP. Provide proof that the Response Team will have access to the third-party software source code (own or in escrow) and that the Response Team has the ability to provide long-term support for the third-party software components of their system. Page 6 of 11
5. Business Intelligence (50 points) The City has developed a star schema data warehouse with sources from multiple systems, notably FAMIS for financial information (Operating, General Ledger and Transaction Data), PeopleSoft HCM for labor information, and IBM/Cognos Planning for budget preparation and performance measurement information. The City s data warehouse contains ten datamarts with data as far back as 1998 and uses IBM/Cognos as the reporting interface with an Oracle database loaded using Informatica ETL processes. The City has two IBM/Cognos Transformer OLAP cubes used for balance sheets, income statements, and other purposes. About 700 employees run approximately one dozen reports with extensive prompting. About 25 users have OLAP report authoring capability; The City has not decentralized report development beyond this. Proposers shall describe how they would implement data warehousing or other approaches to support the diverse information, analysis and reporting needs of an organization of the City. 1) Describe the proposed software, architecture, data model, end-user reporting capabilities, and training and support. 2) Discuss what technologies and approaches the Response Team would recommend to the City in addition to or instead of the traditional star-schema data warehouse, and how would the differences between operational and analytical data and reporting be addressed? Explain why, and address the relative importance of the technologies and approaches recommended. 3) Include in the response the Response Team s experience with business intelligence development and working with business intelligence capabilities. 4) Detail how the proposed system will convert the data currently in our warehouse to the new solution. 5) Detail the approach to use the proposed software to replace our public facing reporting system available at this link: http://openbook.sfgov.org/, for Spending and Revenue, Budget, and Vendor Payments. 6. Business Process Scenarios (75 points) This section describes several scenarios that have necessitated the creation of workaround practices, side-systems, extensive spread-sheeting or manual processing. For each scenario, please provide a detailed narrative as to how the proposed software as implemented will resolve these issues. A. General Ledger 1) How does the proposed software package handle year-end close? Please respond to the question using the subcomponents listed below: Describe the proposed system s accounting year-end close process from beginning to end, including how the proposed system handles GASB63 reporting requirements. The City often has many open purchase orders at year-end which need to be closed. For example, a City department has 30 open purchase orders for less than $250. Please explain how the Response Team would recommend canceling open purchase orders in groups or mass quantities at year-end depending on user-specified criteria, ensuring that the proper accounting is recorded as well. What impact does previous year rolled-encumbrances have on budget and fund balance accounts? Include Page 7 of 11
within the response the accounting events generated throughout the rollover process. 2) Map the following elements to the chart of account fields within the proposed system. If anyone of these elements cannot be mapped, then please state as such. Definitions of these fields are in Appendix A - Glossary of Terms. Fund Department Activity Organization Program Project User Code Grant Job Order Object Sub-object Index Code Appropriation (Budgeted Revenue and Expenditure) 3) How does the proposed system handle organizational changes from the perspective of historical data, current transactions, and un-posted data? For example, in the next fiscal year, assume a department and its functions move from the general fund to an enterprise fund. B. Purchasing Most City purchases are done using a competitive process (e.g., Invitation to Bid (ITB), Request for Proposals (RFP)). During evaluation there are several preferences that may be applied to the bids/scores of the respondents. Please describe how the proposed system can be used to evaluate the following type of solicitation, and include details of any processing that would be necessary outside of the proposed system: 1) An ITB where some items are subject to sales tax and some are not. Apply a 1.25% bid preference to the taxable items for bidders with a San Francisco address in their tax registration. Apply a 10% bid preference to bidders on the City s Local Business Enterprise (LBE list). Apply a prompt payment preference based on the terms supplied by the bidder with a 2% cap and the condition that the discount period must be at least 30 days (2%30N31 = 2% preference, 2%10N30 = no preference, 5%30N31 = 2% preference). 2) Assume that at least one bidder qualifies for all three preferences for the above scenario. Discuss the system s ability to pull the information into the evaluation (LBE file, tax file, bid response) and suggest default preference values. Explain any configuration that is possible (apply line level preferences first or last, apply sequentially or summarily, etc.). C. Technical 1) Upgrade Process - Describe the upgrade process for the software. What happens to userdefined fields and tables during the upgrade process? What happens to any of the customizations to the software (e.g., personalized menus)? What support does the Page 8 of 11
software vendor provide during the upgrade process? What support does the integrator provide if the upgrade occurs during the implementation? Does the City always have to upgrade? What is the support cycle for the software, i.e. what is the time from release to end of life? 2) Third-party applications - If a third-party application is being proposed for any solution within the Proposal, describe what occurs if either the ERP software is upgraded or the third-party application is upgraded. Who is responsible for providing support - the ERP software vendor or the third-party software provider? 3) Help Desk - Describe the process for determining whether operational problems are software or configuration issues after the system is in production. What is the recommended procedure for help desk notification during implementation and after the system enters production? D. Labor Integration with PeopleSoft HCM The City uses PeopleSoft HCM, for payroll and benefits administration. Currently, the City sends payroll information via an interface from PeopleSoft to the FAMIS Labor Distribution System (LDS). This process creates the standard journal entries to record the payroll expenditure and liability transactions. The City also uses LDS to allow departments to post overhead and other methods of cost allocation. Please describe how the proposed system would integrate payroll information from PeopleSoft HCM v9.0 or higher. Include in the response how payroll transactions would initially post, how the City would process adjustments to payroll entries, and how overhead and cost allocations be provided. Also include in the response how project costing is achieved from payroll to the general ledger. 7. Project Resources (50 points) The Response Team must demonstrate the ability to complete the project as planned, on schedule and within budget. The City will have a dedicated project staff of approximately forty (40) full-time equivalents (FTE). Please refer to Appendix C - Organization Chart. The City s project team will be made up of project managers, subject matter experts, and technical and administrative staff. The Response Team is to identify all necessary resources (by function), both System Integrator-provided and Cityprovided, to successfully implement the System within the timeline proposed as follows: A. System Integrator s Project Staffing Information Detail the type and amount of implementation support to be provided by the System Integrator. Provide a roster of key roles that will work with the City to deliver each service functional component of the RFP. The roster should include the role, approximate level of education, technical training, and experience. The System Integrator shall also provide the percentage of time each individual will be allocated for this project. Identify the degree to which System Integrator staff will be onsite versus off-site during the project. Each Proposal, at a minimum, shall specify a dedicated Software Vendor account manager, System Integrator s engagement manager, project manager, financials lead, and technical architecture lead (Please include resumes for the project manager, functional leads, and technical leads). If using a subcontractor(s), include the same information for subcontracting staff and their specific role within the project. Page 9 of 11
B. Required City Resources to be provided Identify the number of City staff expected to be committed to the project, by role, and their estimated time commitment in terms of FTE time during the implementation, including technical and business staff. Include: Skill sets required for each position. Any specialized training required and whether the Response Team provides this training. 8. Post Go-Live Requirements (50 points) A. Post Go-Live Support Describe the following support services proposed after implementation is completed: Immediate (within 30-90 days) post go-live support to monitor and assist in resolving post go-live issue. Transition support services as the City migrates from implementation to an on-going operational environment. Ongoing technical support and software maintenance options, including but not limited to; phone, onsite, web-based, and user groups. B. City Resources Required to Maintain Application Describe the Response Team s expectations for technical and functional City staff to provide ongoing support of the System. Include role, responsibility, and estimated time commitment in terms of FTE. 9. Cost (200 points) Complete Attachment VI Cost Workbook of the RFP by listing the total cost of ownership of the System and implementation services being proposed to the City. It is important that the Response Team use the cost format presented in Attachment VI Cost Workbook and NOT their own format. Do NOT use TBD (to be determined) or similar annotations in the cells for costs. The City requires the Response Team to state costs for all categories with the understanding that they may have to make assumptions. All such assumptions shall be documented in the Proposal. Failure to fully provide cost and work effort information is likely to lead to elimination prior to Stage 2 Response Team Selection Process (please refer to RFP Section 3.3, Evaluation). A. Software Vendor Fees Define the pricing structure for the associated software costs, including license fees, maintenance and support. Include costing detail on: Perpetual Software Licensing 3rd Party Licensing (not included in above) Other Software Licensing All Other Licensing Costs Recurring Maintenance & Support Costs (Years 1-5) Other Services Note: In responding to the RFP, the Response Team is not required to price database licensing as the City will provide these licenses. Page 10 of 11
B. System Integrator Fees The City intends to enter into a not-to-exceed contract for professional services that will include a fully-defined payment schedule per deliverable. In this section, the System Integrator shall submit calculations for project costs to justify the basis for the not to exceed amount that is being proposed. Use a single blended rate to calculate all professional services costs (e.g., travel and expenses must be included in the blended rate). All Proposals should include a twenty percent (20%) contingency. List any assumptions made in preparing the Response Team s cost estimate, and any obstacles foreseen that may affect the cost and schedule. Proposed costs must include all services required to implement and support the solution as described in the RFP, the roles and deliverables identified in Attachment V - Implementation Services Requirements, and the functionality described in Attachment III - Functional Requirements. Page 11 of 11