The Strategic Data Planning project team gathered information from over 500 administrators from central administrative units and schools and colleges to identify institutional goals, define process and data models, integrate and analyze the models to understand relationships between the various components, and inventory and evaluate current systems that support the future-oriented models.
Demands and Opportunities
A demand or opportunity is an external factor that impacts the University of Michigan by forcing it to respond or by providing an opportunity to further its mission. These demands or opportunities are the driving force behind the goals. UM is subject to many current and future demands and opportunities; those highlighted in the interview process are:
At the University of Michigan, with its decentralized nature and its many missions as defined by its various internal and external constituents, it is difficult to have a common set of goals and issues. Lacking that, and still requiring something to guide the subsequent steps of SDP, over 140 interviews involving over 300 individuals from all three campuses were conducted to create a set of guiding goals and issues.
Based on input from the various steering committees for each sub project, high level processes were identified. Meetings were held with process sponsors to clarify the scope of each process, to identify participants, and to select the appropriate approach to use for gathering the necessary information. A variety of techniques including facilitated process modeling sessions, interviews, and reviewing existing planning documentation were used to define the components of the models. Twenty process modeling sessions were held; Fourteen processes were modeled via interviews and reviewing existing documentation. Over 275 individuals representing central offices, schools and colleges, and other units were participated in these modeling efforts.
Each "system" was broken into two separate components: mechanisms (methods by which processes are executed, such as a computer program, manual procedure, or both) and data collections (collections of information, such as a database, file, fiche, or paper file). Basic information, such as name, definition, date created, date of last major update, was gathered about each component. Mechanisms were related to processes they support. Data Collections were related to the entities they support. Each component was evaluated from the user and technical perspective. Over 225 mechanisms and 200 data collections were documented.
Analysis: There are a number of techniques used to analyze the information that was gathered. Some results are used in the subsequent project scoping and sequencing steps. Others can be found in the Additional Findings section.
Goals: Processes were related to the goals they support in the modeling steps to determine if the process directly supported each goal and the degree of this support. Generally, participants were limited to identifying the top three goals for each process. This would ensure fairness in evaluating priorities later in the analysis process.
Data Life Cycle: Like any resource, data has a life cycle that can be identified. Each "entity" is created, retrieved, updated, and deleted over its life. The integrated process and data model (sometimes referred to as a CRUD matrix) was reviewed to determine if each entity met the life cycle criteria. For example, if data was being retrieved by one process but was never created, this could represent a problem with the definition of the data or process or that the entity is created by another process outside the scope of the SDP effort.
Process Value: This step focuses on ensuring that each process adds value. This analysis is conducted primarily on the integrated process and data model. Processes are deemed to add value if they create or update data or if they are providing analysis or reporting (though reporting is thought to have less value since data sharing is the ultimate goal).
Results: Results from the analysis steps included the identification of Data Infrastructure Projects, Common Process Profiles, Projects, and Sequencing and Prioritization of projects.
Data Infrastructure Projects: Data infrastructure projects are repositories for data that are widely used and should be shared across the University. These areas have been identified through analysis which showed that these data are used in a majority of major processes across the University. Managing a single logical repository of this information (not necessarily in one physical database--distributed databases could be used) will reduce redundant and inaccurate collections of data. This will allow integration of data from different functional areas, for instance, a person will be recognized as a person, with multiple roles within the University (and ties to the underlying systems managing those roles). Examples of the roles a person may have are: student, employee, financial aid recipient, housing occupant, and patient.
These data infrastructure areas identify the major areas making up the University's Institutional Database. Because the Institutional Database is a single, logical database, the principles of the Institutional Data Resource Management Policy must be applied uniformly and as part of a coordinated effort. For example, an appropriate starting point would be to review the current Data Steward and Data Manager roles to ensure that they align with these data infrastructure areas. These data infrastructure areas are to be used as part of the "road map" and should be used to guide discussion and implementation planning activities.
Common Process Profiles: The results of the Data Infrastructure analysis are used as a starting point for identifying common process areas, or clusters of processes that interact with common data. Processes that create common data are clustered together. Processes that provide major updates are included in these clusters. All processes fall within a common process area though some also cross common process areas.
Each common process area is profiled and defined. Information gathered to date (definition, purpose, goals, burning issues, processes, data, future technologies, and stakeholders) that is related to each common process area is consolidated and documented. Each grouping is also classified into suggested approaches, such as the need for process innovation, process improvement, and/or systems development. Results can be found in the Common Process Profile section. Individuals, who could be labeled Process Owners, should be identified to oversee the design and implementation of the processes and supporting information systems that fall into each of these areas.
Project Identification and Sequencing: Common Process Profiles are used as the primary basis to identify projects and recommended sequences for projects. Common process profiles may require a process innovation or quality improvement project to review the "aim of the system," major goals and problems, pertinent policies and procedures, and organizational structures. Many of these have evolved over time and most have not been engineered at all. Challenging these existing components up front and validating or changing them will allow resulting projects to be more effective in meeting their objectives.
Many common process profiles can be further broken down into multiple projects and processes from multiple common process areas may be integrated to identify projects (e.g., the processes involved in constructing facilities must be integrated with activities in the procurement and payables processes to be most effective). The Current Systems Inventory is factored in to determine the level of support it provides for the future. Technical and user evaluations are considered.
Resulting projects that create data will be sequenced before projects that update or retrieve data in most cases. Following this sequence will ensure the integration of databases and will streamline implementation of subsequent projects. In some cases, projects that provide access to data in existing systems may be identified and given a high priority. This would occur when the current system is deemed adequate but related processes that retrieve the information need better access.
Future technologies (information about future technologies were gathered and related to processes in the modeling step) information is used to identify infrastructure projects that will enable multiple processes. Those technologies that can be broadly applied will be identified and documented. In most cases, these projects should be initiated immediately.
Data Infrastructure projects will result in the identification of projects as well. Data projects identify data that must be modeled and must have a common database designed to enable multiple processes. In most cases, these projects should be initiated immediately.
A list of projects can be found in the Findings and Recommendations section. This project list should be used to support top-down planning or as the check from which to determine if project proposals fit within the "road map."
Final Priority Setting: Final priority setting is seen as an iterative process which involves many factors and ideally include input from multiple sources. Final decisions should be made by the Executive Computing Committee. These major factors to consider are listed below in no particular sequence: