~ the california state university. educational effectiveness report/1... · california state...

7
.~ The California State University .~ COMMON MANAGEMENT SYSTEMS Last Revised: 10/05/06 Page 1 of 7 - 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 warehouseis required to both communicate and facilitate the direction of the data warehouse development. Vision and Implementation Strategy The DataWarehouse Scope Committee hasreviewed the vision and implementation strategy and recommends a revisedvision and strategy. The vision of the CMS DataWarehouse is to providebotha renewable informationrepository for each campus andan effectivereporting,query and analyticalframework thataddresses campus and systemwide information needs. The data warehouse will be delivered through an iterative andevolutionary process. The initial scope methodology delivered three "PeopleSoft vanilla" warehouse applications asa one-time effort with CSU content to be added iterativelyover time. This change in the initial scope methodology emphasizes delivering content iteratively, but with moreimmediate value(i.e., with CSU content) included. The datawarehouse projectwill deliverprocesses for campuses to extract datafrom source Oracle Enterprise applications into simplified reporting structures; teach campuses how to add additional content from anysource; andprovidequeryand report templates andtoolsets that will facilitate reporting and analysis. The application will providevalueto all campuses, but be flexible enough to support sophisticated uses of the data aswell. The data warehouse implementation will be done asan iterative setof releases, projected at 3-4 peryear, providing moreexpanded andmature data sets at each release as well as additional queries, reports, and tools. The evolutionary natureof a data warehouse is that it is always maturing,thatis a moredeveloped warehouse will encourage and allow more~ophisticated uses of it. The data warehouse scope committee envisions convergence of processes for systemwide andcampus reportingin the future.This goalshould be explored and will be facilitated through ongoing development, but cannot be fully realizeduntil all campuses arelive on all corebusiness modules includingthe data warehouse. Assumptions The recommendation of the DW Scope committee is based on the following assumptions. .There aretwo distinctcampus "datawarehouse capable" groupings differentiated by the availabilityof experienced datawarehousing technical resources:

Upload: nguyennhi

Post on 20-Aug-2018

212 views

Category:

Documents


0 download

TRANSCRIPT

.~ The California State University

.~ COMMON MANAGEMENT SYSTEMS

Last Revised: 10/05/06 Page 1 of 7

-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 ofCSU 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 andrecommends a revised vision and strategy.The vision of the CMS Data Warehouse is to provide both a renewable information repository for eachcampus and an effective reporting, query and analytical framework that addresses campus andsystemwide information needs.The data warehouse will be delivered through an iterative and evolutionary process. The initial scopemethodology delivered three "PeopleSoft vanilla" warehouse applications as a one-time effort with CSUcontent to be added iteratively over time. This change in the initial scope methodology emphasizesdelivering 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 OracleEnterprise applications into simplified reporting structures; teach campuses how to add additional contentfrom any source; and provide query and report templates and toolsets that will facilitate reporting andanalysis. The application will provide value to all campuses, but be flexible enough to supportsophisticated 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, andtools. The evolutionary nature of a data warehouse is that it is always maturing, that is a more developedwarehouse will encourage and allow more ~ophisticated uses of it.The data warehouse scope committee envisions convergence of processes for systemwide and campusreporting 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 datawarehouse.

AssumptionsThe recommendation of the DW Scope committee is based on the following assumptions.

.There are two distinct campus "data warehouse capable" groupings differentiated by theavailability of experienced data warehousing technical resources:

Data Warehouse Scope Committee Briefing DRAFT

0 GrOUp I are campuses that have experience with data warehousing and can devotemoderate to significant resources to data warehousing development and support

0 Group 2 are campuses that have very limited resources to devote to data warehousingdevelopment and support and have very little data warehouse experience. At least 50% ofCSU 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 significantreleases of content each year. Additional content will be added over time. Iterative developmentand release is a data warehouse "best practice" and allows continuous improvement andvalidation.

.The CSU will use the EPM product. This requires a full PeopleTools implementation. There istoo much overhead and potential future cost to creating dual solutions. The use of the product isconsistent with overall CMS project requirements that a product provides a supported upgradepath.

Summary recommendations

Product

.Deliver the data warehouse using EPM only.Comments: The full EPM product has started and will continue to increase its dependence on andintegration with Oracle technology.

Strategy '-/

.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 requested deliverable. HR should be coordinatedwith the 21 sl Century Project.

.Include deliverables that would be useful to campuses that have not yet implemented OracleEnterprise. For phase I, deliver ERSA, ERSD, ERSS and APDB data from the CO warehousesback to the originating campus.Comments: The most-frequently-asked-for content is to return the final CO transformed data tocampuses. This will initially involve moving data from the CO databases to campuses but willeventually 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 corefunctionality by 12/09.

.Campuses will be required to implement any subsequently released core functionality within 6months 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, maybe required prior to version 9 releases. In the event this happens, campuses may be required tobring up data warehouse functionality at an earlier release level.

.To the extent possible, reports that are currently provided with the applications will be moved tothe data warehouse.

Page 2 of 7Last Revised: 00/00/00

Data Warehouse Scope Committee BriefingDRAFT

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 ordashboards. Tools such as Hyperion (Brio), Business Objects or Microstrategy would be moreappropriate in this area.

Hardware

.Develop in a single environment. Encourage campuses to use the same type of environment toavoid 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 environmentComments: Allows flexibility in campus architecture; campuses can contact GSC for support.

.Offer a CMS-Central supported production instances that run the delivered warehouse baselinefor interested campuses. This includes installing, running and upgrading EPM and the data martsas well as providing the reporting environment, and installing delivered reports. Campuses woulddefine 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 reportingenvironments, 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 fordata 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 costsfor 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 filetickets 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, reportingwriting 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 needto be rebuilt. Ensures consistency of the data.

Last Revised: 00/00/00 Page 3 of 7

Data Warehouse Scope Committee BriefingDRAFT

Cleanse data at the source.Comments: To ensure data integrity.

Governance

.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 developedwith respective stakeholder input.

ImpactsAdditional 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

.ConsultingOptionally, campuses can form consortiums and share resources to host and perform these tasks. Thescope 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 maybe 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

Data Warehouse Scope Committee Briefing DRAFT

EC Question DW Scope Committee Answer

1. Should we support only an EPMversion of the warehouse, only astandalone version of thewarehouse, or both?

Answer: Support EPM only.

Based on our belief that a vendor supported product is better than a consultingupgrade service and given our commitment to the Oracle application suite weshould continue with the Oracle delivered data warehouse product whichrequires EPM. The costs to have Central Support staff create a standaloneversion are too substantial.

Campuses can mitigate the impact of EPM by outsourcing this support toUnisys or another vendor.

Campuses with existing warehouses will be able to participate in reporttemplate specification and prioritization. Campuses may continue to run theirexisting warehouses until they are fully able to migrate to the new model. Thenew 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 multiplehardware/operatingsystem/database platforms andversions or limit our choices?

The function of the data warehouse team is to provide structure and content forthe warehouse. Supporting multiple environments is a costly and non-effectiveuse of resources. At the same time, campuses may have expertise andbusiness reasons for using alternate environments.

Therefore, the CMS Central team will limit its environment generally to a singleenvironment combination and will concentrate on developing content. (Theremay be two environments to support different release levels.) Campuses maychoose to support a separate environment provided it is an Oracle-certifiedenvironment, but will be responsible for identifying the appropriate patches andchanges required to run code. CMS Central will provide 90 days of overlappingsupport 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 ensurethe initial installation is operational. The data warehouse team will work with thecampus 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 willbe taken to include CSU data fromthe Oracle/PeopleSoft baseline inthe warehouse, and who willdetenTline the "right" data toinclude?

Answer: Data warehouse content will be delivered in phases as separate datamarts designed to meet specific reporting needs. CSU data will be incorporatedas necessary to meet detailed needs based on requirements defined byindividual data mart implementation groups.

4. What is core functionality?When will it be required? Can it bephased in?

Core functionality will be phased in over time and will continue to grow asadditional data marts are implemented. In each phase, the deliverables will bedefined as "core" or "non-core." The initial data warehouse releases will be forHCM 8.9 and Finance 8.4. Campuses will not be required to implement theselevels.

5. Should reporting be delivered? Answer: Yes.

In line with our assumption that at least 50% of campuses have very little datawarehouse experience and very little resource to devote to it, query andreporting templates should be delivered to meet basic reporting needs. An easyto use repository (drop off) for sharing campus developed content should besupported as well. See #6 for tool response.

Page 5 of 7Last Revised: 00/00/00

Data Warehouse Scope Committee Briefing DRAFT

EC Question DW Scope Committee Answer

6. Should reporting tools bedelivered, and if so what tool(s)?

Answer: Yes with a toolset to be determined.

A systemwide licensed and supported toolset should be provided. A separateRFP should be issued to select this toolset which should include a query tool, areporting and analytiCs tool and a dashboard tool. In addition the Discoverertool, with reports and reporting GUls, is delivered with EPM and should berolled out to campuses with CSU content.

7. For which dimensions shouldwe include historical values? Howshould this determined?

EPM as delivered has one dimension with historical values. The otherdimensions are .current" only. Determining which dimensions should includehistorical values is a business decision that should be identified by functionaluser groups. Additional historical dimensions can be implemented over time.

Answer: EPM is delivered with system metadata and record definitions. Fornew content that is created, business users will provide the definitions. Thesedefinitions will be published electronically in a manner to be determined by theData Warehouse group with input from business users.

8. What meta data shall bedelivered? What format?

Answer: The model used with the CMS application seems appropriate. CMSCentral should provide basic templates and a basic approach. Campusesshould flesh out the details as appropriate to that campus (e.g. centralized vs.decentralized). Campus Information Security Officers should be involved.

9. What level of security supportwill be delivered with thewarehouse?

Answer: No other items are in scope at this time10. What other items are in scopefor the warehouse?

Page 6 of 7Last Revised: 00/00/00

Data Warehouse Scope Committee Briefing DRAFT

The start of the centrally supported data warehouse project occurred after several campuses had alreadyinitiated individual campus efforts. Many campuses have a rich body of knowledge and significantresources 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 datawarehouse 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 contentand reports, to the extent that those campuses are willing to participate in the design and fit/gap sessionsthat 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 theanalysis and identification of key reports already done by other campuses. This will benefit the project, inthat 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.

Page 7 of 7Last Revised: 00/00/00