.~ The California State University.~ COMMON MANAGEMENT SYSTEMS

Transcription

1 .~ The California State University.~ COMMON MANAGEMENT SYSTEMS - California State University CMS Baseline Lessons learned There were several lessons learned during the initial roll-out of the original scope of the CMS Data Warehouse:.The immediate need for operational reporting from the transaction systems was confirmed during initial rollout..most campuses did not make use of the content delivered in the initial rollout due to the lack of CSU content..campus access to systemwide data (e.g. ERS; APDB) is desired..longitudinal analysis support is a primary, long-term goal. This need was identified as a secondary priority in the original scope..a long-term vision for the data warehouse is required to both communicate and facilitate the direction of the data warehouse development. Vision and Implementation Strategy The Data Warehouse Scope Committee has reviewed the vision and implementation strategy and recommends a revised vision and strategy. The vision of the CMS Data Warehouse is to provide both a renewable information repository for each campus and an effective reporting, query and analytical framework that addresses campus and systemwide information needs. The data warehouse will be delivered through an iterative and evolutionary process. The initial scope methodology delivered three "PeopleSoft vanilla" warehouse applications as a one-time effort with CSU content to be added iteratively over time. This change in the initial scope methodology emphasizes delivering content iteratively, but with more immediate value (i.e., with CSU content) included. The data warehouse project will deliver processes for campuses to extract data from source Oracle Enterprise applications into simplified reporting structures; teach campuses how to add additional content from any source; and provide query and report templates and toolsets that will facilitate reporting and analysis. The application will provide value to all campuses, but be flexible enough to support sophisticated uses of the data as well. The data warehouse implementation will be done as an iterative set of releases, projected at 3-4 per year, providing more expanded and mature data sets at each release as well as additional queries, reports, and tools. The evolutionary nature of a data warehouse is that it is always maturing, that is a more developed warehouse will encourage and allow more ~ophisticated uses of it. The data warehouse scope committee envisions convergence of processes for systemwide and campus reporting in the future. This goal should be explored and will be facilitated through ongoing development, but cannot be fully realized until all campuses are live on all core business modules including the data warehouse. Assumptions The recommendation of the DW Scope committee is based on the following assumptions..there are two distinct campus "data warehouse capable" groupings differentiated by the availability of experience data warehousing technical resources: Last Revised: 10/05/06 Page 1 of 7

2 0 GrOUp I are campuses that have experience with data warehousing and can devote moderate to significant resources to data warehousing development and support 0 Group 2 are campuses that have very limited resources to devote to data warehousing development and support and have very little data warehous experience. At least 50% of CSU campuses fall into this category that is primarily made up of the smaller campuses..the data warehouse will be implemented iteratively. There will be several "small" but significant releases of content each year. Additional content will be added over time. Iterative development and release is a data warehouse "best practice" and allows continuous improvement and validation..the CSU will use the EPM product. This requires a full PeopleTools implementation. There is too much overhead and potential future cost to creating dual solutions. The use of the product is consistent with overall CMS project requirements that a product provides a supported upgrade path. Summary Product Strategy recommendations.deliver the data warehouse using EPM only. Comments: The full EPM product has started and will continue to increase its dependence on and integration with Oracle technology..phase in the warehouse. Comments: Best practice; allows for adjustments in delivery.begin with a single data mart. Comments: Provides a proof of concept; allows adjustments before larger rollouts.start with Student; then Finance; then HR. Comments: Students are our core business and student data is most immediately in need of access, reporting and analytics. Finance is a frequently requeste deliverable. HR should be coordinated with the 21 sl Century Project..Include deliverables that would be useful to campuses that have not yet implemented Oracle Enterprise. For phase I, deliver ERSA, ERSD, ERSS and APDB data from the CO warehouses back to the originating campus. Comments: The most-frequently-asked-for content is to return the final CO transformed data to campuses. This will initially involve moving data from the CO databases to campuses but will eventually be a process generated from the warehouse. Core functionality.core functionality will be identified with each phased release of the warehouse..campuses will be required to implement all identified core functionality when they migrate to the 9.0 application release. Based on the current roadmap, all campuses would be on core functionality by 12/09..Campuses will be required to implement any subsequently released core functionality within 6 months of its release, or at the next major release level, whichever comes first..it is possible that some core data warehouse functionality, such as objects related to CIRS, may be required prior to version 9 releases. In the event this happens, campuses may be required to bring up data warehouse functionality at an earlier release level..to the extent possible, reports that are currently provided with the applications will be moved to the data warehouse. '-/ Last Revised: 00/00/00 Page 2 of 7

3 Reporting.Include report templates. Report templates would drive CSU content additions. Comments: Provide value, especially to smaller campuses; lesson learned from JumpStart pilots.use Discoverer for basic query reporting. Comments: Oracle delivers reports with Discoverer; we already own the tool..identify and purchase (RFP) an analytic and complex report delivery tool; obtain a systemwide license. Comments: Discoverer is not a high-end tool and does not support analytic content delivery or dashboards. Tools such as Hyperion (Brio), Business Objects or Microstrategy would be more appropriate in this area. Hardware.Develop in a single environment. Encourage campuses to use the same type of environment to avoid additional campus support issues and costs. For example: Oracle 109 running on Linux. Comments: This allows CMS Central Support to focus on content..allow campuses to select and support any Oracle certified environment Comments: Allows flexibility in campus architecture; campuses can contact GSC for support..offer a CMS-Central supported production instances that run the delivered warehouse baseline for interested campuses. This includes installing, running and upgrading EPM and the data marts as well as providing the reporting environment, and installing delivered reports. Campuses would define their own security roles and users (that would be maintained by the central support team). Campuses would be able to create additional reporting using the supported reporting environments, but would also be able to use other campus-supported SQL-based tools. Comments: Recognition of differing levels of readiness to assume the full technical support for data warehouse infrastructure..encourage campus consortiums for hosting data warehouse and reporting environments. Comments: An alternative support method for small campuses as well as a means to reduce costs for all campuses. Content.Require campuses to run the delivered baseline. CMS will support only the delivered baseline. Comments: Provides consistent content across campuses and facilitates systemwide information requests..encourage independent campus development. Comments: Any campus can download additional EPM content from Oracle. Campuses can file tickets with Oracle for support. Provides maximum flexibility..encourage consortiums for common development outside of the centrally-delivered project. Comments: Economies of scale around commonly used, non-centrally supported campus applications..issue an RFP to create a data warehouse consulting MEA. Comments: Provide assistance to campuses for business analysis, ETL development, reporting writing and training..provide a "drop-off' shared repository for sharing of campus developed content. Comments: Economies of scale. Value added.campuses should move reporting to the warehouse wherever possible. Comments: Improves productivity -upgrade costs and time reduced because reports will not need to be rebuilt. Ensures consistency of the data. Last Revised: 00/00/00 Page 3 of 7

4 Governance Cleanse data at the source. Comments: To ensure data integrity..replace the DW AG with a formal governing body that would have executive. systemwide. institutional research, functional/business and technical representation. Comments: Overall strategic direction for the data warehouse; each data mart would be developed with respective stakeholder input. Impacts Additional hardware and human resources will need to be directed to this project. At a minimum, campuses will need:.a server to run the data warehouse and reporting tool software.a workstation to run the client software for the data warehouse and the reporting tool software.system and database administration skill sets for the new software and upgrades (Oracle DBA, DataStage [data warehouse building tool], PeopleTools, Discoverer, etc.).development, test and quality assurance instances.a Web server for user access.training.consulting Optionally, campuses can form consortiums and share resources to host and perform these tasks. The scope committee also recommends that CMS provide a hosted solution. CMS Central will need:.a fully supported infrastructure for content and report development.additional staff.data warehouse staff for concurrent data mart and content development, upgrades, deployment, support and training.report writers who will also provide training To the extent that campuses can commit resources to the central project, the need for additional staff may be alleviated; but there will be a need for additional staff and/or consulting resources to develop, upgrade, and support this project. Last Revised: 00/00/00 Page 4 of 7

5 Data Warehouse Scope Committee Briefing EC Question DW ScopeCommittee Answer 1. Should we support only an EPM version of the warehouse, only a standalone version of the warehouse, or both? Answer: Support EPM only. Based on our belief that a vendor supported product is better than a consulting upgrade service and given our commitment to the Oracle application suite we should continue with the Oracle delivered data warehouse product which requires EPM. The costs to have Central Support staff create a standalone version are too substantial. Campuses can mitigate the impact of EPM by outsourcing this support to Unisys or another vendor. Campuses with existing warehouses will be able to participate in report template specification and prioritization. Campuses may continue to run their existing warehouses until they are fully able to migrate to the new model. The new model can be enhanced by the campus to include any of their "old" functionality that is not delivered in the CMS data warehouse baseline. 2. Should we support multiple hardware/operating system/database platforms and versions or limit our choices? The function of the data warehouse team is to provide structure and content for the warehouse. Supporting multiple environments is a costly and non-effective use of resources. At the same time, campuses may have expertise and business reasons for using alternate environments. Therefore, the CMS Central team will limit its environment generally to a single environment combination and will concentrate on developing content. (There may be two environments to support different release levels.) Campuses may choose to support a separate environment provided it is an Oracle-certified environment, but will be responsible for identifying the appropriate patches and changes required to run code. CMS Central will provide 90 days of overlapping support for changes in operating system levels, Oracle database levels, PeopleTools levels, etc. EPM is usually installed by Oracle; they will work with the campuses to ensure the initial installation is operational. The data warehouse team will work with the campus to identify further issues for their initial installation. There will not be an option to use any database other than an Oracle database. 3. What is the approach that will be taken to include CSU data from the Oracle/PeopleSoft baseline in the warehouse, and who will detentline the "right" data to include? Answer: Data warehouse content will be delivered in phases as separate data marts designed to meet specific reporting needs. CSU data will be incorporated as necessary to meet detailed needs based on requirements defined by individual data mart implementation groups. 4. What is core functionality? When will it be required? Can it be phased in? Core functionality will be phased in over additional data marts are implemented. In defined as "core" or "non-core." The initial HCM 8.9 and Finance 8.4. Campuses will levels. 5. Should reporting be delivered? Answer: Yes. time and will continue to grow as each phase, the deliverables will be data warehouse releases will be for not be required to implement these In line with our assumption that at least 50% of campuses have very little data warehouse experience and very little resource to devote to it, query and reporting templates should be delivered to meet basic reporting needs. An easy to use repository (drop off) for sharing campus developed content should be supported as well. See #6 for tool response. Last Revised: 00/00/00 Page 5 of 7

6 EC Question 6. Should reporting tools be delivered, and if so what tool(s)? 7. For which dimensions should we include historical values? How should this determined? 8. What meta data shall be delivered? What format? 9. What level of security support will be delivered with the warehouse? DW Scope Committee Answer Answer: Yes with a toolset to be determined. A systemwide licensed and supported toolset should be provided. A separate RFP should be issued to select this toolset which should include a query tool, a reporting and analytics tool and a dashboard tool. In addition the Discoverer tool, with reports and reporting GUls, is delivered with EPM and should be rolled out to campuses with CSU content. EPM as delivered has one dimension with historical values. The other dimensions are.current" only. Determining which dimensions should include historical values is a business decision that should be identified by functional user groups. Additional historical dimensions can be implemented over time. Answer: EPM is delivered with system metadata and record definitions. For new content that is created, business users will provide the definitions. These definitions will be published electronically in a manner to be determined by the Data Warehouse group with input from business users. Answer: The model used with the CMS application seems appropriate. CMS Central should provide basic templates and a basic approach. Campuses should flesh out the details as appropriate to that campus (e.g. centralized vs. decentralized). Campus Information Security Officers should be involved. 10. What other items are in scope for the warehouse? Answer: No other items are in scope at this time Last Revised: 00/00/00 Page 6 of 7

7 The start of the centrally supported data warehouse project occurred after several campuses had already initiated individual campus efforts. Many campuses have a rich body of knowledge and significant resources invested in these efforts. Campus business users rely on the delivered content. At the same time, these campuses are facing upgrade efforts to align those warehouses with application upgrades. The data warehouse can provide a solution for these campuses as well. The content and reports that users have developed can become the basis of the new warehouse content and reports, to the extent that those campuses are willing to participate in the design and fit/gap sessions that the data warehouse team will have. This will benefit the campuses who have invested in these efforts, because their users will have continuity. This will benefit other campuses that will reap the benefit of the analysis and identification of key reports already done by other campuses. This will benefit the project, in that much of the initial analysis and content identification can jumpstart the new data warehouse. The basic process will be:.developed reports will be collected and catalogued..fit/gap teams will review the report areas and prioritize them..systematically, the reports will be reviewed and final design documents will be produced..csu content needed for the report will be identified and added to the data warehouse..the report will be designed in one of the report toolsets (Discoverer or the new tool). The resulting code projects and reports will be packaged into the next releases cycle. Last Revised: 00/00/00 Page 7 of 7