Wednesday Sep 07, 2022
Inside Insights: Data Modeling & Visualization in SAP Analytics Cloud (SAC) with Hau Ngo
In this next episode of Tech-Driven Business, Mustansir Saifuddin continues the conversation with Hau Ngo of Summerlin Analytics to discuss how to approach data modeling and visualization when using SAP Analytics Cloud (SAC). Hau first joined us for a 6-part series in 2021 to talk about SAC and what it means to enterprises as they move to the cloud. Hau and Mustansir share real-life tips on how to approach this depending on your team and company. Listen in for quick takeaways that you can put in to place today. As the tech industry moves to simpler tools, data modeling plays an even more important role.
Hau is an SAP Analytics Architect and an early adopter of SAP Analytics Cloud. In 2017, he helped a technology company in California consolidate global sales reporting across 7 different ERP systems. This effort culminated in one executive dashboard that displayed real-time information, eliminating weeks of manual coordination and data wrangling. Subsequently, Hau has presented his work at conferences such as SAPPHIRE 2019 in Orlando Florida, and has gone onward to help additional customers streamline their reporting processes and visualize the key company metrics. His experience with SAP Analytics Cloud extends to customers with various systems such as SAP Data Warehouse Cloud, BW/4HANA, and S/4HANA.
Connect with Us:
LinkedIn:
Twitter: @Mmsaifuddin
or learn more about our sponsor Innovative Solution Partners to schedule a free consultation.
Episode Transcript
[00:00:06.010] - Mustansir Saifuddin
Welcome to Tech-Driven Business. Brought to you by Innovative Solution Partners. In this episode, I welcome back Hau Ngo of Summerlin Analytics listen in as he talks about the importance of balancing data modeling with visualization to get the most out of your investment in SAP analytics Cloud or SAC.
[00:00:34.110] - Mustansir Saifuddin
Hello Hau, how are you?
[00:00:37.110] - Hau Ngo
I'm doing well, Mustansir, how are you?
[00:00:39.570] - Mustansir Saifuddin
Hey, doing great, man. Welcome to Tech-Driven Business. Again, today we will talk about the balancing act they call it, especially when you talk about SAC. And you have so many different variables in terms of the data modeling part, the data visualization, and what is the right balance. That's what I want to talk about today.
[00:01:06.070] - Hau Ngo
Oh, sure, yeah. I think it gets a little bit tricky, I think now with this newer tool because you can do so much with it. Before we used to just do everything in either ABAP or BW and you just have like a table dump either in Excel or an LB grid. But now with SAC, you can still do a little bit of data modeling. You can define calculations so the lines are blurred, like where do you do which things? Right? And I think in terms of what I would suggest for a good data model in this new paradigm, I would try to have all your work done on the back end, meaning you would have all your calculations done in either S/4 or BW or Data Warehouse Cloud, and treat SAC as a read-only layer. So SAC as a reporting layer, just read what you've written and leave that. Now of course there's some give and take, some things are easier in SAC, but I think for the most part, make sure everything is done on the source system and you should be off to a good start.
[00:02:13.930] - Mustansir Saifuddin
Interesting. So what seems like a good data model in your example that you just shared? It's almost like do more of the heavy lifting on the back end, which can be either S/4 or Data Warehouse Cloud or any other system for that matter, as long as you can connect to SAC and then use SAC as almost like your reporting layer. But create your stories, but avoid more detailed calculations and modeling in SAC.
[00:02:47.170] - Hau Ngo
Yeah, exactly. Because if you start reading into the technical documentation, SAC explains the technology in this way. Each widget, each table that you see in your dashboard is a separate report or query call to the back end. So if you're doing a lot of heavy lifting on the front end, inside Analytics Cloud, it has to do that X times per widget. So we have nine or twelve there's nine or twelve separate calls. It's going to fetch a lot of data and then you're going to do a lot of calculations in your browser and that may slow it down.
[00:03:27.770] - Mustansir Saifuddin
Yeah, that's for sure. I mean, the number of widgets does impact your so, I mean, when we talk about widgets, especially, I've seen some dashboards or stories that can go from a single pager to multiple pages. Is there a good definition of exactly how many visuals you can have or you should have just to make your dashboards more robust?
[00:03:56.110] - Hau Ngo
Oh, sure, yeah. If you're looking for like a really responsive, quick rendering type dashboard, something that the user can open and see the data right away. The approach I've been taking is if you can break up your stories into multiple pages, I think SAP still recommends having only six at most charts per page, which is kind of sparse, to be honest. I typically run between nine and twelve per page, but if you can render all of your stuff on different pages, you only have to load those widgets per navigation. So typically I build for directors and executives, and they almost always want to see an overview page, which is like one chart type from one page, another chart type for another page, and they want to see specific things on the overview, and as they go from page to page, they go into a more specific look or drill down into their data. But if you can break it up, it renders much faster. If you can stick with the simpler chart types, like bar charts, numeric, pie, anything that's not a table, you should be in good shape.
[00:05:13.230] - Mustansir Saifuddin
That makes sense. Yeah, especially those cards are very useful. As you mentioned, when you're working with the C-levels, the information can be readily available. It's easy to grasp what's being presented on the initial overview page.
[00:05:27.230] - Hau Ngo
Exactly.
[00:05:28.290] - Mustansir Saifuddin
So that kind of leads me to my next question. This is good because we always get this inquiry, especially when you're dealing with a source, especially when you have multiple source systems feeding into your SAC model. Right. What constitutes like, a model, especially when you're dealing with data warehouse and S/4, what would you prefer?Usually you see from your experience, do you see a blend of those data sources or do you see a single data source and then working with that on the SAC side?
[00:06:16.520] - Hau Ngo
Yeah, I would say typically when we first start off on a project, I see a blend and then it moves into a centralized data warehouse. And I say that because with SAC, you can get things up and running pretty quickly. So we can leverage this trick called in browser blending where you can say, I have data coming from multiple things. I want to them all mashed together on a dashboard. And if I were to select something like company code, that selection applies to all of the chart types regardless of the source of data. So to get those types of dashboards up and running quickly, to make sure that the information you're presenting is clear, understandable is what the user is looking for. That is a great starting point, but almost always you run into the data integration issue and that's almost always better done in a data warehouse because the tools are made for that.
[00:07:13.310] - Mustansir Saifuddin
Yeah, that makes sense. Well, especially I'm just thinking of a scenario where you have a need to quickly bring something up, especially when you're dealing with executives and they want information on their fingertips, and you try to kind of get information directly from the source system versus a model based on a data warehouse, things can get a little tricky.
[00:07:42.260] - Hau Ngo
Yes. And with this tool, also, you get around that trick or that tricky scenario by showing these executives what you can do with the tool before committing three to six months into a lengthy implementation. They want to see what's possible upfront, and if they want to invest that fund towards that effort.
[00:08:04.380] - Mustansir Saifuddin
It's a great advice, actually. I like that. So what I'm hearing is you can do a quick show and tell and then see what the capabilities are and how the tool can interact with a transactional system versus a data warehouse. And then once things are the way it's supposed to be from a business standpoint, you can create a model behind the scenes. Right. To make it more the reusability seems to go up, correct? Is that my understanding?
[00:08:37.110] - Hau Ngo
Yeah, exactly. I consider this more like a high fidelity mock up where you're using production data. They're familiar with the figures, and you can get them most of the way there with business content. So regardless of which system that you have, the tools are there for you to kind of take apart and blend together in your browser with this tool.
[00:09:00.410] - Mustansir Saifuddin
For sure. Yeah. So let me ask you this. Based on your experience, I know you talked about you've done multiple SAC implementations in your experience. Anything that stuck out for you, like, any example that you would like to share with our listeners?
[00:09:14.760] - Hau Ngo
Yeah. So this is going to be, I would say, a tricky one to answer because I work with large teams where the project budget is $400 million, and then I work with small teams where it's just me plus the client, because newer companies are being formed now through divestiture where there's a larger firm, they spin off a smaller subdivision or subsidiary. And those folks, they know what they want. They're used to having information in a certain way, but they no longer have the staff or the team to deliver that. So I would say if you don't have a data warehouse, don't worry, you can use this tool. You can use other cloud based dashboard tool with your source data, whether it's ECC or S/4. But as you get more mature and as you consider purchasing a data warehouse, maybe you don't even need a large team for that either, because now SAP has another tool called Data Warehouse Cloud, which is a cloud based data warehousing tool that doesn't require the large upfront cost and the team to implement.
[00:10:25.400] - Mustansir Saifuddin
That interesting. Yeah. I think the way the industry is going depending on the size of the implementation and the requirements. Right. You can take multiple approaches and there's no right or wrong answer. It depends on what your requirements are at that point in time, right?
[00:10:54.870] - Hau Ngo
Yes, exactly. And it seems like now the tools are advancing that in a way that we can do more with less and we can get things done quicker than before. So it's pretty exciting.
[00:11:08.430] - Mustansir Saifuddin
Yeah, for sure, I think. And that's the key piece, right? I mean, you can spin up a dashboard in a matter of days and hours versus weeks and months. That used to be the case in the past.
[00:11:19.540] - Hau Ngo
Yeah, exactly.
[00:11:23.050] - Mustansir Saifuddin
That's an interesting segue into this idea of like, folks talk about getting things quickly and that means that a lot of times a lot of projects want to bypass our data warehouse. Right. What are your thoughts on that? What would be your advice to them or the right way to do it?
[00:11:47.290] - Hau Ngo
Oh, sure. So if they're, I would say relatively small and nimble in terms of company size, you can create beautiful dashboards with S/4 data. You don't need a data warehouse if you happen to run S/4, so that there's a lot of business content there that you can leverage and extend. But if you are looking at a data warehouse, like I mentioned, data warehouse cloud is an option. But a lot of these cloud based tools, they seem to work better and they seem to work across different data sources as well. I would say just go ahead and give it a try. The takeaway here isn't so much the tool, it's trying to get the user buy in from your business. So I would focus more on that before really focusing on how do we do it, making sure if this is something that the users want to get done.
[00:12:44.470] - Mustansir Saifuddin
Yeah, for sure. I think that is probably one of the key takeaways. I always ask this question because my listeners like to hear, especially when you're talking about these kind of insights. What is the one takeaway when you talk about the balancing act between data modeling and data visualization when it comes to SAC?
[00:13:07.510] - Hau Ngo
Oh, sure. I think in the past we used to have, I would call them clunkier tools like business objects or Lumira, where you need a dedicated resource or team of resources to maintain the server to do the development. What I've seen now is the transition to simpler tools, both the front end and the back end, the SAC visualization tool and the data warehousing tool that's coming out because they're so much easier to use. I would focus less on the reporting visualization need in SAC because you can get a dashboard out and running in an hour if everything is really clearly defined, so the effort is much less. Right. But the classic problem exists if you happen to be doing a lot of data transformation or merging data from different places, the data modeling efforts still remains, even though you can get it done quicker. The effort between visualization reporting versus back end modeling, the ratio is now leaning more on the back end. So before, if it's three to six months on the back end, maybe a month on the front end. Now it's more like a day at most on the front end, depending on how many revisions you want to go to.
[00:14:38.760] - Hau Ngo
But the data validation is still there on the back end. So I would focus more on hiring developers for the back end who knows what they're doing and are familiar with the process. More so on the back end than the front end.
[00:14:52.450] - Mustansir Saifuddin
Yeah. So I think it kind of leads up to that question about how do you architect your data? Right. In your source system? And what is that? The possibility of pulling the information in a way that it makes sense from whatever the business KPI that you're working on, correct?
[00:15:09.250] - Hau Ngo
Yes, absolutely. And you'll find, as you know, the time sync is validation and there's really nothing that you can do to get around that, depending on how many sources of data you're combining, transforming, and the complexity that is still there.
[00:15:25.570] - Mustansir Saifuddin
Yeah, for sure. And that's probably not going to go away until you have all these different definitions of the key indicators and how you measure it. And every company, every organization has their own way of doing it. So as long as that is well defined and well published, the front end work seems like it's become a lot more easier and better in terms of the visualization with Sac.
[00:15:56.170] - Hau Ngo
Yeah, absolutely.
[00:15:58.450] - Mustansir Saifuddin
Great. Hey, it's been great talking to you. How really good insights in today's session. Look forward to our next coming up soon. Thank you so much.
[00:16:09.200] - Hau Ngo
Yeah, thank you, Mr. Have a good one.
[00:16:11.760] - Mustansir Saifuddin
You too.
[00:16:15.530] - Mustansir Saifuddin
Thanks for listening to Tech-Driven Business brought to you by Innovative Solution Partners. Hau shared some key pointers as you think about where to focus your efforts in SAC. His main takeaway, as we transition to simpler tools focus on data modeling. We would love to hear from you. Continue the conversation by connecting with me on LinkedIn or Twitter. Learn more about Innovative Solution Partners and schedule a free consultation consultation by visiting Isolutionpartners.com. Never miss a podcast by subscribing to our YouTube channel. Information is in the show notes.
Comments (0)
To leave or reply to comments, please download free Podbean or
No Comments
To leave or reply to comments,
please download free Podbean App.