How to Build a Proof of Concept Approach to Improve Your GRC Programs

The GRC technology lead from American Family Insurance, John Aaholm spent time with Onspring to discuss the importance of a Proof of Concept (POC) and how it should be used to not only improve your governance, risk, and compliance (GRC) strategy, but predict ROI for other programs.

Here, we’ll walk through how an idea to improve efficiency goes from inception to implementation in a Proof of Concept process, and the next article in our series highlights examples of how Onspring has helped American Family Insurance deliver ROI to its GRC processes.

How ideas brew at American Family Insurance

At American Family Insurance, John leads the Information Risk Management (IRM) team and oversees GRC technology, which includes the company’s widespread use of Onspring. John is an evangelist internally, educating departments on how to best utilize automation in Onspring to improve projects, ongoing tasks, and get new initiatives off the ground.

While the American Family Insurance IRM team proactively creates new use cases in Onspring for GRC processes, it’s not uncommon for colleagues and other departments to propose a new idea to automate a process or address a problem to solve. John’s team is responsible for finding creative solutions to meet their needs and deliver business value.

Cost savings, time savings, and process improvements all contribute to the bottom line. 

“We often have departments coming to us saying, ‘We have this business need that we’re trying to solve. Would Onspring be a good fit for that?’” said Aaholm. “And we really have to dive deep into what their needs and current processes are to identify the underlying issues or problems. If Onspring can meet their business need—and do so with efficiency and automation—of course it makes sense to move to Onspring.”

But it doesn’t stop there. After understanding the department’s specific needs and pain points, John’s team analyzes the new use case to understand how it will improve current processes, or if it will replace or supplement current use cases, and identify potential cost savings. Without fully implementing a new use case in Onspring, the IRM team configures a lightweight application to understand whether or not those primary business objectives would be met with Onspring.

This evidence-based testing is called a proof of concept (POC).

What is a proof of concept (POC)?

What ideas should become proofs of concept?

While a proof of concept gives provides a testing ground for an idea without a full build, it still takes time and effort, which means you must establish a rubric for what ideas or requests qualify for a proof of concept.

“Early on, we had established a request prioritization methodology,” said Aaholm. “We wanted to keep it simple, and since we were standing up the process for managing Onspring, we built out a solution in Onspring to allow users and prospective users to be able to submit requests.”

Based on the methodology, requests are flagged for whether or not they require a proof of concept.

Common Request Types

After a new idea or request is submitted by another team at American Family Insurance, the IRM team evaluates to angles:

1. Development effort
2. Business value

Development Effort

The development effort is defined by the complexity of the request. If it’s something such as granting a new user access, modifying data, or deleting a few records that were incorrect, those are simple requests that can take as little as an hour to resolve. However, larger, more complex requests will likely require a full POC and dedicated time to analyze the business need.

Business Value

Business value measures the ROI of automating the process, specifically around identifying and quantifying efficiency gains. When a request or idea has high efficiencies, is integrated with multiple business processes, or is related to processes critical to the organization—such as reports for senior leadership—the ROI increases, as does the likelihood of proceeding with a proof of concept.

Development Effort Evaluation

Business Value Evaluation

Evaluating requests from an ROI perspective will identify and quantify efficiency gains. If the business value is high, it touches more business processes, or those processes are more critical to the organization—such as reports for senior leadership—the likelihood increases of the idea or request becoming a proof of concept.

A final element of the initial evaluation is risk. It’s important for the American Family Insurance IRM team to identify present and potential risks. If the team finds that Onspring is fit for the use case under evaluation, the team notes any risks mitigated by migrating processes and reporting to Onspring, and conversely, note any risks that might be introduced inside Onspring.

Proof of concept (POC) decision matrix

The volume of new requests and ideas coming to the American Family Insurance IRM team are plotted on a heat map diagram to identify which requests should be greenlit for a proof of concept.

“We’re charting development effort against business value. The key is to focus resources on the lower left quadrant area of the graph. We want to focus on the higher business value items that take less effort to complete,” said Aaholm.

Based on the American Family Insurance request prioritization and dimensions, two types of requests—change an existing solution and implement a new solution—are greenlit into proofs of concept.

Of the 622 requests our IRM team has received from the business, 6% have been new solution requests and 39% have been requests for changing an existing solution.

For all requests that involve a new solution or use case in Onspring, the IRM team first considers the full scope of the ask.

In most scenarios, using an out-of-box product from Onspring and making adjustments to fit the requesting team’s specific ask is often more efficient than building a completely new set of applications in Onspring.

If you are considering whether to build a new new use case in Onspring, or simply adjusting an out of the box product from Onspring, consider the following:

• Does the new use case request fit with an existing Onspring product?
• What is the process or data alignment to existing Onspring product?
• Will Onspring replace existing applications/other technologies?
• Does the new request fit our current processes/data?
• Will the use case in Onspring require data imports or integratiosn?
• Does Onspring satisfy workflow and reporting needs of the requested use case?
• What is the impact on the security model?
• What is the impact on implementation and change management?
• Will the POC answer the go/no-go question (ROI)?
• What are the license implications for new or existing users?
• What are the implications for future support?

“One thing I always remind my team: Ask whether data needs to be imported or integrated into Onspring in their request?” says Aaholm.

If the answer is yes to either, you probably want to include at least a portion of that in your proof of concept just to know how different or how much data normalization you’ll need to go through.

Aaholm continues with his advice on his experiences, “You certainly don’t want to spend a ton of time on completely analyzing the data, but if you can at least get a small subset of it, it might be worthwhile and will certainly help inform the results of the proof of concept.”

John Aaholm
GRC Technology Lead

Conclusion

At the end of the day, you need to be able to determine if the proof of concept will answer the go or no-go question: Will this deliver the ROI needed?

If the answer is no, go back and review the questions or criteria to make sure that you’re focusing on the right things during the proof of concept, measuring them back to the pre-defined KPIs, and assuring that the proof of concept is going to provide the information for the stakeholders to determine a move-forward decision.

For more examples of how to apply proofs of concept for business requests, continue reading the next article in American Family’s webinar series.