Let’s talk semantic models for community financial institutions. There’s a lot of misconceptions about them. In this video, we discuss the basics of semantic models, break down myths, and share the facts on what you need to know to make an informed analytics decision for your team without getting persuaded by chatter. Exploring Common Semantic Model Questions Fielded from Credit Unions and Community Banks Gemineye’s COO Matt Jefferson and Director of Business Development Maggie Chopp answer: Whether centralized analytics teams are better than departmental analysts Why unified semantic models ensure consistency If there should ever be a cap on how many fields your semantic model should have Why the misconception of limiting number of fields is holding back your analytics potential How credit unions are successfully integrating data from multiple sources without complexity Full Transcript Alicia Disantis: Are centralized analytics teams better than departmental analysts? And Matt I will ask you that question. Matt Jefferson: I think centralized analytics teams there, they’re great for consistency and governance. Department analysts are great for kind of speed and the business contacts. I think the real win, no matter what you do in an organization, is when you really have them working with the same semantic model, the same governance principles. You know, I think at some level, you always end up with some level of decentralized, analytics. Maggie Chopp: We’ve seen a couple kind of creative configurations this year, and there’s nothing saying that they can’t work. Well, again, given the, the base semantic model like Matt mentioned, that’s kind of the key to making it all flow. But we have a number of credit unions we’ve talked to this year who have very interesting designs that work for their teams, depending on who rolls up to who. But it works nicely again, with the base model. We have a credit union that as an example that brought in data from their collections platform. A lot of that would never, ever hit the core. But it brought them a lot of value when it came to their repossessions. They ended up making a lot more money knowing which of their resellers were getting them the most margin. And again, that’s not something you’re going to find in a core provider. You’d really need a data warehouse to assess something like that. Alicia Disantis: Should there ever be a cap on how many fields your semantic model should have? Matt Jefferson: No, there should be an artificial cap. Right? Business questions evolve. You know, I always say that every financial institution is like a fingerprint, right? You know, it’s a financial institution, but it is a little bit different. Right? And the right solution, the technology solution, everything makes it very easy to adapt to your your business needs, right, to add the things you need. Do you really want to wait for someone to say like, hey, all of our clients need that particular data field before you can access it? Maggie Chopp: I’m gonna add a little caveat, which is it’s not always good to bring everything. And we want to, you know, optimize for efficiency. We want it to run quickly. Run well. But just from speaking from experience, the credit you and I worked at and all the credit runs we talked to, everybody needs something else. Like every single day. The models are great. We just need to add one more thing. And one thing that we’ve observed is that, some providers will make it really difficult to do that. You’ll have to go way back in time. There’s, a statement of work to draw up. There’s all this kind of finagling just to get one additional data field, which really, it shouldn’t be that complicated. We have a bring it all approach. And so bringing something like a single data field in is it is easy and it should be easy. And if it’s ever not, you should reassess how you’re doing it. And on top of that you know, the concept of even having placeholder fields is somewhat meaningful. We found pretty regularly talking to credit unions. They might all have a different definition of something. But if we keep placeholders in the code for different persona types or different segmentations that are credit unions already use, we don’t even have to go about adding a field, so to speak. We’re just using that credit unions logic. So no, we should never be limiting how many fields should be in a semantic model. Want More Data Analytics best practices? Check out our Data Teams page.
