LEAP I: Accessible Text

LEAP I: Accessible Text Version

3. Approaches to Data System and Reporting Changes

Section summary

One area affected as a result of WIOA implementation is the state data system. As mentioned previously, under the law there are changes to accountability requirements that will affect how data are collected and reported. This necessitates changes to both the data system reporting and tools as well as to the data system architecture. In this section, you will learn about a process for revising data reports by considering the inputs, outputs and functionality needs of your data system. You will then learn about additional challenges to changing the data system architecture as a result of WIOA and options for modifying your own system. This section also provides a tool for evaluating elements of your current data system.

By the end of this section you will be able to

  • determine the status of your current data system,
  • identify the elements needed to revise your own data system in order to impact the data reports, and
  • understand the different system architecture options and how they work.

Why change your data system?

With WIOA implementation upon us, it is obvious why we should focus on modifying data systems. But in addition to specific changes needed in response to new accountability measures, there are other reasons to take advantage of this time for data system revisions and development. Increased need for cross-agency data sharing may require more sophisticated system architectures. Where NRS data was mostly self-contained, states will need better access to external data, and will be required to share more seamlessly with others. In addition, evolving challenges in maintaining security and privacy may render existing systems less secure than ever before. Addressing these issues, and compliance with state and federal security standards, will require infrastructure and coding changes within data systems. Finally, quality and cost of analysis tools have improved substantially, and the amount of data available for analysis has never been greater. At the same time, increasing pressure to “do more with less” calls for much greater use of “data-driven” decision making. Organizations now have a great opportunity to do this by applying powerful dashboards and data intelligence tools.

Making changes to data systems can be overwhelming; however, a breakdown and consideration of elements needed for reporting help to clarify and simplify the process. (See Figure 6.)

Figure 6. Thought Process for Developing Reports and Data Tools

thought process

A data system’s basic operation includes inputs, the system functionality, and the outputs. However, you need to think about these things in a different order when planning a redesign or new development. Begin by considering the system outputs. What are the items the system must produce? These include things such as accountability reports, dashboards, and data exploration tools. You also may think about the more specific outputs, such as specific measures. After considering the outputs, consider the inputs. Determine what specific data collection and details are necessary to produce those outputs, such as those in the figure above. In this step, you also may consider whether you have the ability to collect those inputs and the reality of getting the information needed. Is the data easily accessible to your immediate staff or do you need to arrange with an outside department to collect the data? The extent to which you need to modify your data system depends on the inputs needed and how you are best able to collect them. Finally, determine appropriate functionality for entering, processing, sharing, and reporting on data. This connects and transforms your inputs into your outputs, so consider factors such as ease of use and modification, ability to error check, and the final outputs you want to product when considering the data system functionality. These three items will help you plan your to-do list and move forward with development of the data system.

System architectures

System architecture supports critical needs for the data systems. Under WIOA, states have an increased responsibility for data security and privacy of information, as well as an expectation of coordination of data across agencies. This sets up a potential for creating and dealing with complex systems. Determining the type of data system depends upon outputs, data interchange requirements, and security and privacy considerations. You may or may not have total control over the decision, but it would be useful to understand characteristics of each. The graphic from the GAO report (Figure 7) on WIOA requirements lays out four potential data system options.

We know that with WIOA, greater interagency collaboration and data sharing will be required. These come with a number of key challenges, apart from basic functionality.

Unified data system

Advantages:

  • Less worry about management and technology, as your needs are handled as part of a larger system
  • Easier integration and data sharing (at least from your perspective)

Disadvantage:

  • Less control over the system development and operations

Back-end integration

Advantage:

  • More control likely over your data system’s development and operations

Disadvantages:

  • Possibly greater challenge in integrating data for reporting
  • Challenge of maintaining consistency across interagency data

Front-end integration

Advantage:

  • Greater control over your own data—as in back-end integration system

Disadvantage:

  • Greater responsibility for integrating data from other sources, possibly

Interfacing

Advantage:

  • Greater emphasis on interagency collaboration making it easier to exchange data

Disadvantage:

  • Responsibility for integrating data from other sources

Figure 7: Models of Potential Data System Integration

data system integration

Data security and personal privacy involve considering data governance. Determine who owns the data, who is allowed access, and who can change the data. Maintaining consistent definitions, rules for sharing, retention, and other issues are more complex when multiple agencies are involved. These are important to get consensus and agreement on before beginning. In terms of data collaboration and sharing, you should also think through implications of sharing student data such as privacy, security and appropriate or allowable data use. As part of this you may decide to set up formal sharing agreements between agencies. Approaches for protecting data and privacy must be coordinated, and built-in to the system infrastructure while planning.

Activities

Evaluating your state data system

Inevitably, states will need to revise their state data systems in order to comply with WIOA regulations. This activity allows participants to begin thinking about what they currently have in place and what may need to be changed. This will be different for each state, depending on their starting point. Using the handout provided in the appendix, states will look at their current policies and process for collecting data and determine how prepared they are for addressing new changes to their data systems. They will also take a closer look at the possible data system architectures proposed and identify which most resembles their current system. This will be different for each state, depending on their starting point. This activity is used as a starting point to get states to determine whether they have the underlying information and supports needed to modify their systems in order to address WIOA changes and reporting.

Adaptations

For use with partner agencies: In some cases, states may have a cross-state data system. In this case, the partner agency can complete this to determine the information for which they are responsible. If they do not, this activity will be useful for each agency to complete for their own systems.

Data system planner

Modifying the state data system requires looking at various data elements, functions, features, and outputs to determine how the data system will be most useful.  State staff can use this planner to review various aspects of their data systems and determine functions and features they can keep, need to discard or change, and then plan next steps for what needs to be done to change the data system. The result can then be used to guide their discussions with the technology developer.  The results will be different for each state, depending on their starting point.

Adaptations

For use with partner agencies: As with the previous activity, this should be used in cases where there are multiple data systems or points of input. In addition, the planner can be revised to add a section to note overlap across systems, or points of data collaboration across agencies.

Additional resources