One key person at WSECU who is tasked with the organization’s data strategy is Data Architect Joe Horton. His team of seven focuses on data and reporting, with a few team members also working on data science projects. The team has differing levels of expertise and varied skill sets, from dashboarding with Tableau to deep programming knowledge and expertise in Snowflake.
One of the team’s biggest challenges was that its data was stored in many different locations, which made it difficult to get a holistic view for reporting purposes. When someone in the organization would ask the data team a seemingly simple question such as “Can you give me mortgage information?”, Horton would have to collect and compile data from several different databases: commercial mortgages, standard mortgages, and more.
The data also came in from many different sources. For example, Horton explains, there could be five different ways an application—such as an application for a credit card, car loan, or house mortgage—could come into the credit union. “We would spend a lot of time managing it all,” he says. “It felt like we kept redoing and rebuilding the same things over and over.”
This siloed data led to inaccuracies in reporting, with different team members pulling data from various sources and interpreting it in different ways, or making common errors that would skew the results. “One person would, for example, count the credit union members one way and another would count them a different way, so we were getting different counts at times,” he explains. “Or maybe someone would forget to look at a flag that might be expired—they would pull in information but forget to say, ‘expired date must be null or blank,’ and they would get the wrong results.”
This problem was compounded by the fact that their banking core processing platform is account-centric rather than people-centric, so everything is at the account level. As Horton says, “This makes it hard for us to say, ‘Here’s a member and here are all the products and services this member has at our credit union,’ because they’re all in disparate systems.”
Another challenge the team had was the cost just to maintain the system, and Horton recalls that it was a lot of work to get Microsoft SQL Server stabilized. In addition, Horton and team were always tasked with running reports for other teams, which ate up a considerable amount of time. “Everyone came to us because we were the subject matter experts who knew the data well, but we wanted to enable our customers to do it themselves,” he says.
The previous system affected the credit union’s customer service as well. When members applied for a loan, the lag time between the application and the decision was sometimes longer than the applicant expected, and the data team struggled to determine why. “When you apply for an RV loan, you probably want an answer within hours or a day. To help the member, we needed an easy way to see the complete picture: When was the application submitted? When did an underwriter look at it? What was their decision? When will the money be approved? Because so much of this information was in different systems, it was hard to do this quickly,” he explains.