Integration Monitoring in action: Keeping critical SAP and SuccessFactors data in sync

Welcome, everyone. Thank you for joining, today's session. I'm, Daniel. I'm a solution architect with EPI-USE Labs. I'm gonna host today's session and my colleague Jessal is going to be presenting the content on integration monitoring. So a quick bit of house housekeeping. This session is being recorded. So you're all on mute with cameras off. We'll provide some follow-up after the session with information on what happened and a link to slides and recording and things like that if you want to do some follow-up. And if you have any questions during the session, we'll take some questions towards the end. So please just have a look for the little question box like it's up to the top right of your screen or for the go to meeting session and you can use that to just ask questions as we go along and we'll answer those at the end of the short Q and A now today's session or kick into it. We're going to be talking about integration monitoring in action. So how to keep critical data within SAP and SuccessFactors in sync. So if you jump forward, please, Jessalyn. Before we get underway though. I'll quickly introduce a few slabs for those of you that are not familiar with us. So we're a software development organization. We've quite a strong focus towards SAP and solutions that support people running and managing their SAP landscapes. So some of the product sets that Giselle is gonna talk about today have a like an over twenty year history of active development and use. And they report as they represent just some of the types of solutions that we can provide from EPI-USE Labs. We're a global organization. We're part of a bigger group that we call Group Elephant. So and we have operation centers in around fifty five countries, and we have delivery teams and support teams based out of Asia and Australia and New Zealand. So we've got good local coverage in this part of the world as well as a part of a greater organization supporting around the world. Let's continue on if you next slide, please. I'll just quickly introduce Jessa. So do left Jessa as part of our delivery team based in the Philippines and she's going to take us through today around integration monitoring and a couple of products sets that help in that space just was background within the company is around HR SuccessFactors type projects. She's done a lot of work implementing our products using the reporting solutions in the scenario. She'll talk about today as well as getting involved more recently in some large transformation projects, you know, helping move data between legacy and new SAP environments and transform and change payroll. So she's got good understanding and good wealth of experience around the structure and nature of SAP and the data model that she's going to be talking about today with the integration monitoring, but I'll hand over to Jess. Well to take forward and take us through the session. Thank you. Okay. Thanks for that, Dan. Hello, everyone, and welcome to today's webinar about integration monitoring in action, how to keep critical data within SAP and SAP SuccessFactors in sync. So my name is Gisela, and I'll be walking you through during this discussion. A pleasant day to all of you. So, in today's webinar, we'll be discussing several key topics surrounding SAP SuccessFactors integration in hybrid landscape, focusing on practical challenges, real world use cases, and how to proactively monitor and improve integration health. So we'll begin by looking, at the typical replication challenges that organizations face when integrating SAP SuccessFactors with on premise systems in hybrid environments. Next, we'll examine the most frequent integration scenarios or use cases we see across customers. After understanding the challenges and then and the use cases, we'll focus on monitor monitoring, utilizing Query Manager. So we'll then move into a live demonstration to see what this looks like in a real system. Finally, we'll explore how organizations can push integration monitoring one step further via analytics. So integration sounds simple at until it isn't. In a very simple description, integration is often associated, with corrections to systems, movements of data across systems, and the automation of that said process. So this allows the smooth data flow between platforms and an end to end visibility is achieved. However, for those who worked with integration or working with integration right now, we know the complexity behind it. Let's unpack why. So first, data replication is designed to be seamless, but complexity gets in the way. Replication works perfectly when data are aligned. So may it be your organizational structure, business rules, data definitions, custom fields, etcetera. However, we realize that companies evolve. So acquisitions happen, local payroll requirements differ, and custom info types or MDF objects are introduced. So the what starts as a tightly defined replication starts to add layers of exceptions. And these exceptions add conditional logics, which could be hard to validate. Next, hybrid SAP and SAP SuccessFactors landscapes add layers of risks. So there are only a few organizations out there which operate in a single system in reality. So a typical landscape might include employee master data in SuccessFactors, And then your payroll sitting in SAP ERP, HCM, finance, and, let's say, S4HANA, and third party benefits or time vendors. So every system introduces different data models, different timing expectations, and different validation rules. These layers then poses risk as different data models are stored on different, systems. Third, is that small mismatches often go unnoticed until payroll or audit are impacted. The most dangerous integration issues aren't actually dramatic failures, but those that are having or introducing subtle discrepancies. So a pay component, might replicate with a wrong frequency, a call center defaults overwrite a position assignment, a retro trigger fails to generate. So these are subtle changes that makes a huge payroll impact and often go unnoticed and even undetected for weeks and months. Fourth is that replication logs exist, but most teams don't have the time or clarity to act on them. So SAP provides logs and a very good detailed one to note. However, your HR IT and payroll teams don't often have the liberty to inspect deep log analysis. And most often than not, payroll teams are more focused on meeting payroll deadlines, supporting business challenges, handling regulatory updates, and more. So which in turn makes the team reactive to these changes, and logs are often read when the issue already created a fire. And, lastly, as SuccessFactors adapt, adoption accelerated, we consistently saw the same issues surface across clients, driving the need for a better way to validate and reconcile data. So as organizations rapidly adopt SuccessFactors, a pattern actually emerged across industries and geographies. So field mapping, slightly misaligned, incomplete regression testing after configuration changes, no systematic reconciliation between sources and targets. So the problems were rarely unique. In fact, these are often recurring and repeatable. So this highlights to us that rather than a configuration challenge, this is more of a validation, gap. Okay. I think I take a poll. Yeah. I just launched the poll there. So if you wouldn't mind having a look. So we're just looking here, obviously, at hybrid SAP environments. So we just got some options there around different styles of that. So HCM and SuccessFactors Employee Central, HCM with multiple SF modules, HCM, SF or other third party systems or just a h HCM only or maybe SuccessFactors only. So EC and ECP. So answer away. We'll just give it a moment to get a feel for what type of systems people are running. So the poll is pretty much coming through people with HCM with SuccessFactors, people with multiple modules implemented. So maybe EC and other components in SF. But everyone here is pretty much using SF apart from one person. Person. So there's good mix of people HCM with multiple SF modules, which is what we see fairly common and sort of a key part of what to sell is talking on today. So I will just end that poll, and we'll continue on. Thank you. Yeah. Thank you for that. So I see that this would be more relevant to those people who had actually hybrid setup for more than one system that they are using. Okay. Definitely. Yes. So now we will jump into more specific discussions about data replication challenges often faced by organizations. So let's do another poll just to see what your biggest challenges are in your hybrid environment. Okay. Yeah. So next poll has popped up. So being my fault in the last one, we've seen a lot of people running SuccessFactors and some kind of about stack ECP or so forth. So what are the issues around that? So data replication and syncing shoes. So just a very low level base area lack of confidence in data accuracy. So, you know, is moving, but you might not really be sure that the end result is correct lack of consolidated reporting. So you've got multiple systems in play, but you're not really sure how to see and visualize across all of them at once or just troubleshooting issues before payroll or key processes. So something's impacting a key time critical bau process. So thank you for those that are adding into the poll. We're seeing data replication issues and sync issues is quite high up there. And then it's sort of an even spread across lack of confidence consolidating reporting and just general troubleshooting around the BAU process. But it seems data replication and sync issues is the one that wins is the most key issue. I'll end the poll. We'll continue on. Thank you, everyone. Okay. Thank you for that. So the result of the poll in the two polls that you have, voted, so those are actually pretty common. So we have now more customers engaging into hybrid setups, TestFactors, And then, of course, the data replication between your SuccessFactors and non SuccessFactors system or a I SAP system happens to have this repetitive or often similar cases of data replication issues. So now this topic moving forward would be more relevant to those people who often engages these kinds of issue and actually encounters them day to day. So some of the most common challenges of data replication would be about the fact that complex data landscapes makes it hard to spot discrepancies quickly. So modern Azure landscapes are layered. Each layer introduces mapping logics, transformation rules, and timing discrepancy or dependencies. When something goes wrong, it's rarely obvious where the issue originated. What should take minute often turns into hours of cross team troubleshooting, and the complexity of the landscape makes it difficult to quickly pinpoint where a discrepancy occurred or whether it even exists until someone stumbles across it. So, hence, we need a solution that can automate the identification of data issues for faster, more accurate resolution. So that would effectively increase the team's efficiency. Next would be replication logs act is actually there, but they don't tell the whole story. So errors slip through because teams rely on system logs instead of checking the actual data. So oftentimes, if the status shows success, teams assume the data is correct. By focusing on log status instead of field level reconciliation, teams miss discrepancies that are technically valid but operationally incorrect. So we need a solution that can run through data checks, not just log reviews, so to minimize the replication errors across the system. Hence, this will improve data quality. Third, would be missed pay deadlines and failed audits. So team rarely see data mismatches until after they've affected payroll or compliance. So the consequences usually surface at critical moments. Payroll operates on fixed calendars as we know it. When mismatches are discovered late, teams scramble to investigate and adjust. Sometimes it might require an off cycle payments or manual override. So in this case, we need a solution that can schedule and automate reports that alert the right people to actionable discrepancies. Hence, this will give a streamlined communication across parties involved. And then lastly, in our most common data replication challenges would be, that data replication is limited visibility or has limited visibility across systems. So in hybrid SAP environments, visibility is fragmented. No single team sees the full end to end of a data record from origin to payroll results. So without centralized reconciliation or cross system comparison tools, identifying the root causes requires manual effort and business knowledge. So, hence, why we need a solution that can compare data across systems and see exactly where mismatches occur, so effectively giving us data transparency. So in an overview, this data, replication introduces or introduces to us issues that poses huge risk to the organization and often silently, it disrupts, business process. So the challenge we discussed are not fundamentally integration problems. They are monitoring problems. And the good news with monitoring problems is that it is an integration I mean, there is an integration monitoring process that can help mitigate these issues. So now we introduce the integration monitoring, process. Let's say that your organization is on a hybrid setup. You have your SAP SuccessFactors sitting in the cloud and your HCM system diagrammed here on the left hand side, where a tool or a solution is actually helping with the integration. So data then flows from SuccessFactors to SAP HCM through an integration. The integration monitoring process through the EPIU to the use of EPI-USE Labs solution, Query Manager, will then be able to read data between your hybrid systems and output in a clear format any discrepancy in your replicate replication, and that is at field level. So, what this means is that Query Manager integration, monitoring process effectively reports on data from SAP and SAP SuccessFactors at the same time using, OData API. So it can read real time on demand data minus the duplication, and SuccessFactors data is available as a source inquiry manager as shown in your screen in the left hand side. So, all entities present for data exposure in the OData API dictionary can be used as a data source in Query Manager. Security wise, the integration monitoring process of Query Manager uses OAuth two, with certificate based SAML authentication, which is actually SAP recommended. So it also adheres in, role based authorization in SuccessFactors, and only approved users who, have authorization to actually view data, can get data or source out data from your SuccessFactors system. Now, let's jump on the most common use cases, on when to use the integration monitoring process. So first and foremost is for HCM and payroll data validation during upgrades. So upgrading from your on premise SAP HCM or payroll to SAP SuccessFactors is not just a technical migration. So it's a business critical transformation wherein payroll, time management, benefits, and employee master data must remain accurate and compliant throughout the transition. So an integration monitoring tool becomes essential because of data integrity risks that increases during upgrades. So data model differences between systems can introduce silent discrepancies. Also, as we know, payroll is zero tolerance. So even minor inconsistencies in wage types, tax data, retro calculations can result in financial errors or compliance validations. So instead of discovering errors post upgrade, when remediation is costly and reputationally damaging, monitoring enables proactive issue detection. So in short, upgrades amplify risks, monitoring reduces it. Next would be SAP to SuccessFactors data replication auditing. So as you know, data replication is continuous and business critical. Employee records, organizational structures, job classifications, and compensation structures of the data must remain synchronized across systems. So integration monitoring tool, addresses these mismatches that can remain undetected for months. So it can highlight only discrepancies much like an exemption based reporting. It provides audit trails for compliance and governance. So rather than checking thousands of replicated records manually, the integration monitoring process isolates only what is broken, so accelerating resolution and improving trust in the integration, layer. Third, would be, unique cases scenarios. So no two SAP landscapes are identical. Some organizations operate fully cloud based HR. Others can run complex hybrids involving the flexibility of integration monitoring solution, which allows it to be tailored according to your data model, complexity, number of integrated systems, frequency of replication, let's say, regulatory requirements, and industry specific demands. So for example, one client may require daily reconciliation of employee master data across regions. Another may need payroll cluster validation before or every pay run. So a third may require real time alerts tied to organizational structures or changes to those structures. So a flexible integration monitoring process adapts to these realities. So it moves beyond static validation and becomes a governance mechanism that aligned to your business need. Now let's see in action how this integration monitoring process works. So I'll be showing you a demo right now in one of our demo systems. So here, I am I in the Query Manager solution of EPI-USE Labs. Here is the reports for the integration monitoring. We check first an example of job info. So job info is often one of the things that's critical, especially if you have SuccessFactors and it's replicating back into your SAP systems. So most often than not, few or a majority of the replication issues that I see are related to the job information. So what the integration monitoring, process is that it reports by getting the data out of your system's SAP HCM and, comparing it versus what's there on your SuccessFactors through an integration. In the example that we have here, you can see that the fields from SS and fields from SAP are side by side introduced with their data. So it gives us a clear identification of whether the data is actually matching between the two systems or not. You can also do highlights if you only are concerned about those that are, not in sync, And you can also add more fields and customize how you wanted the monitoring or the integration monitoring to check. So it's not just limited to the fields that you see on your screen, but also, can be customized. So if you have custom info types on your SAP system and then custom, entities on your SuccessFactors, so those can be sourced out from Query Manager Integration Monitoring. So let's see another example, biographical integration monitoring. So, before I jump into the actual result, in the additional selections, you can actually only choose those that have mismatches. So you'd if you don't really, are concerned about what in sync because we expect everything should be in sync and only concern those that are mismatches then. You can click or have the ability to only see those that are mismatches. So in the biographical info integration monitoring, it's the same case. It's checking data from SAP versus SuccessFactors. It highlights any differences. It gives you numbers of keys, so number of SuccessFactors users that were included on this, what has been mismatched, how many is actually passed or in the percentage they passed. Also, just an addition, if the replication is something that you validate daily, you can run this as a job daily and then send over the result of those mismatches into your email. So effectively, you don't need to enter your SuccessFactors or SAP systems anymore. It can land the list of mismatches into your inbox for your Teams, fix for them. So this is how, it looks like, the integration monitoring, process. Now let's go back. So, now that you've seen how integration monitoring simplifies your data replication validation, let's take it one step further by introducing it to analytics. So integration monitoring is often introduced as a control mechanism, a way to detect replication failures, mismatches, or missing records. But when structured correctly, it becomes far more powerful than an operational report. So it becomes an analytics asset. So here's how the extension happens. First, is that the integration monitoring reports from Query Manager is the source of the data. So as the foundation, the structured is still reporting, often built through Query Manager within SAP and SuccessFactors ecosystem. And then it integrates with your analytics solution through an add on and then apply any external program that can utilize the OData connection generated to Analytics Connector. Any external program capable of consuming OData can leverage the monitoring dataset. This could be Power BI, Tableau, SAP Analytics Cloud. So the real transformation occurs when an integration report was fed into the enterprise analytics platform, which then gives organizations the advantage of using it from static reporting to dynamic analysis. So let's see in action how this looks like. I have here. Yeah. So I have here a sample of how an analytics solution used the integration monitoring to power its dashboards and analytics for trend analysis, replication error rates over time, seasonal payroll patterns, and then integration performance during peak cycles. So with the use of Query Manager's integration monitoring report, it now has more of a use in terms of its analytics. So in the overview here, we can see a trend if this is going to be run on a periodic basis on when typically a replication fails, what or what processes are happening behind the ground, which makes this replication error, and then what are the typical mismatching values found. And then at a more granular level, we can see employee details on who actually got mismatched record. So this is now turning your typical static reporting of integration monitoring into one step further using analytics or dashboarding solutions. So that actually concludes today's discussion on integration, monitoring. I'll hand it over to the team again. If ever there would be any you, Jessica? Yeah. I'm just looking through questions now. We do have a few. If you do have questions, just a reminder again, there's the question box or we can raise questions. So pop them in there. We'll spend a, you know, four or five minutes now answering whatever questions come through. If we don't get through them all, we can respond via email afterwards. So please try and just raise them as needed. But I've got a first one here. So what advantage does this have compared to the built in analytics that other systems may already have like SuccessFactors, etcetera. Yeah. So maybe how does this compare to the standard monitoring or reporting around interface stuff that's in SAP? Yeah. So SAP already got their replication logs, their own sets of validations logs. But then these replication logs doesn't show the exact data mismatch. So logs tell you there is a potential problem. However, you have to still analyze where this problem occurred. So we need a solution out there that can actually pinpoint the data in the field level where the discrepancies in the sync happened. So that's the major differences between a replication log and the monitoring or integration monitoring tool. Okay. So it helps give you context about the business data or about what actually went wrong rather than just a technical reason. Okay. Excellent. I've got another one here. It's around what we might already what we might include with the solution. So what pre validated integration content or methodologies are available out of box? So you know, what kind of reports and things do we have prebuilt for integration monitoring, or what kind of things might people need help on to build? Yeah. So most of the time, the essentials data that is needed for payroll. That would be your master data, so biographical information, and then also for taxing purposes, and then also the jobs. So the job information that we saw earlier, that is one of the few entities that actually fails during replication. So all of these data sources can be applied to an integration monitoring report wherein we can check the consistency of your data. Well, of course, it does not only limit us to those lists that I've shown you earlier, but if you have custom entities that is going to be payroll impacting, that is also one of the things that you can add in the integration monitoring. Okay. Excellent. Oh, that was another question you just answered. So I had one on custom objects or custom fields or entities, so we can obviously include those into the monitoring as well. Okay. That's excellent. Yeah. I've got one last question, I think, and then we'll start to close out. There's just one here around what percentage of records are typically miss matched and what is the typical cause? Is it like timing of replication or is it something else? Do we have a feel for that or is every customer system different? Yeah. Actually, it's not something which is it's not an answer for all organization. There's no one answer for the organization in that aspect. Some organizations see the failures of replication more on the master data. Some sees it in the way the wage types has been configured on their system. So it's different, really. And, of course, if your payroll runs frequently, and you might see more replication issues than those that runs on a monthly basis. But, eventually, the message here is that whether it is one percent, ten percent, fifty percent, or ninety percent replication issue, it is still an issue. And we need to address these issues because in the long run, when payroll actually runs, these discrepancies will introduce more issues and harder issues to fix. Okay. Excellent. Yeah. So that must be where concepts like the dashboarding and seeing some trend analysis can be very helpful so you can see if you're trending down and improving over time. Yeah. Okay. Excellent. So I think we'll leave it there in terms of questions. Maybe if you just jump forward one slide, please, Jessa. I'll just talk about an event we've got coming soon. I'll maybe click the button again after and again the beautiful performance by Jessa and I forgot to test my slide to make sure everything came up. There we go. Okay. So just wanted to let you know about some coming events. We've got with EPI use. So there's a series we're going be running soon around de risking SAP transformations. So if you want to scan that QR code there, it'll take you through to our website where we've got a range of webinars and content that's going to be hosted on there that you can subscribe to. So this particular series is going to be around the problems and trials and tribulations of getting to s four or going through transformations in general. So whether that's early in the planning or through the post live and stabilization. So we're going to run up a series of events on different topic areas around that whole transformation space. So if that is of interest, please grab that link there and go to the website and sign up or register your interest. All right. So with that will bring things to a close. I've got one last poll. I will pop up and just leave on the screen as you as we close out and finish. So if you would like us to get back to you, please jump onto that last poll if you register interest in terms of someone talking to you specifically about a problem just getting further interest on this topic of further content on this topic in general or if you've got no follow-up need, please answer the poll. We'll know who's answered it and we can reach out and contact you as needed, but I'll leave that up as we close out I just yeah, I'd like to thank Tesla for her content and discussion today. That was excellent. And thank you to everyone who attended will finish up here and leave you to your day. Thank you, everyone. Have a good day. Thank you, everyone. Bye.