Case Study: SAP SuccessFactors Recruiting Implementation at FinBO

Yeah. So if you go to the hackathon of recruiter experience and inside that and you have to follow not this track, okay. Because these are independent track. Okay. And if you have to go directly to the this one. Okay. Track number three, operations. And here I have uploaded the last one, the interview central which talked about, right. How to select an interview candidate and how to give rating to that candidates as an recruiter or a hiring manager or a interview panel. Right. So that is up to this. It is there. Okay. And yesterday's video I will be uploading here in this track only. But from today's onwards whatever will be here, okay. I will be uploading here track number four. So there are certain things I will be removing and I'll be cleansing up this activity. Okay. So this is the path actually you have to follow. Understood. Okay. So sure. So from today we are starting with the implementation and before that it will be coming in the operations. Operation. Yes, yes. So actually track three was an operation, okay. And track two was a kind of a strategy architecture. All the principles, okay. And track one was a process. Track zero was a product point of view and it was just orientation. The first day. Day is the day zero was an orientation. Okay. So your more focus will be on the implementation side of it which you are going to start. Okay. So let's then get started with a story. Okay. So the story goes like this, okay. It's a kind of a case study. Okay. Because whenever I do an implementation actually just to give you a real time scenario where you have to go through this, understand the cons means the implementation. What is the scenario? So let's say this is a scenario and is a hypo mysterious. There is no company name like this. Just a miss. I just created a no mystery project or you can dummy, you can say mystery. Okay, whatever. Right? There is no person like this. There is no company like this. Okay. But the hypothetical you can say case study. Okay. The case studies. If you see this is basically I will be sharing this case study also when in the implementation track. Okay. So the idea is here say we have a Mr. Siddiqui Satsadiki and who is a recruiting process lead for a is IT based banking and finance measure. And the company name is the finbo. Right. And they are having headquartered in Cairo and They've had count of 75000 employees. They have both actually employees as well as the contractors across Egypt, uae, major Arabic, European and Asian countries including India. Okay. So so this is a coverage of their banking major company and they are Having an implementation of success factor recruiting which is going live in April 2024. Okay. Feel like it's a real time. It's happening and it will be a big bang. So do you understand what is a big bang? Go live. You must be knowing it. What is the difference between a big bang and what is the other one we do? Anyone would like to explain? No idea. Would you like to try what is a big bang? It's a science concept. But we use in the when you go live, right? People say you might have heard, okay, we are now going Big Bang go live. Are you relating into Big Bang theory? Yes, it is related to that only. But in this context, what is the meaning? You must have whatever you must have heard about it. Also in our SAP Ham also same term was there I never this. Okay, you never heard it. Okay. No worries. Then I will explain you. Okay. Big bang. No worries. So there are two approaches whenever you're implementing any project. Right? So let me then explain explain that concept. While otherwise it will difficult for you to understand. Once let me stop sharing and I will be going to the mind map and I will show you something. Okay. So. Huh. So let me share my mind map. Okay. Is the mind map visible? Yes. Okay. So in this implementation track when you go for a project, right? Okay. So when you go project go live happens. Go live. It will be kind of one. We follow two different types of approach. One is a big bang. Okay. Another is a. You can say hedged approach. Okay. So this is approach actually. Okay. So big bank and phase. So big bang. What happens? That means you will be going live with all the location, all the modules in one go. Okay. So let's say you're planning for SAP Success factor employee central recruiting, your lms, pm, GM succession, cdp, all the modules you are having. And also in this scenario we are having 31 countries. Okay. That means all the modules, all the countries are going live in 1st of April 2024. Okay. But in case if you are going live with a phased approach, what will happen? So let's say your headquarters is ET as per this case study. Let's say. Okay. Cairo. Okay. And you will be going live with E first. Okay. Then you can go phase wise. Okay. Let's say you'll be implementing maybe success factor recruiting and employee central. Even the module wise also you may decide. Okay. All the modules were not going to live. Okay. We will be going phase wise. Initially we'll be implementing let's say employee central recruiting onboarding. In the phase two, you will be implementing success Factor LMS compensation, variable pay. In the third phase you will be implementing let's say PMGM and the rest of the modules. And fourth phase, once everything is done, people generally I have seen if they are going for phase wise approach analytics module people analytics at the end they will implement it because all the data if it is not there and there's no point in doing analytics, okay? Generally reporting and analytics, workforce analytics, they keep it at the end if they are going for pace wise approach. Okay. So you might be thinking what is the advantages and disadvantages. So both has pros and cons, right? If you're having a good amount of resources, budget big bang go live is a better and also you can go everything will be but once you implement it again, continuous support is also required. Heavy resource required, right? But in case of page wise you will be. It is a more disciplined way actually you will be understanding from one page what are the key learnings. That mistake will not be doing either phase two. Okay? So that's the way you go step by step. Okay? But that takes again a more resource means more time it will take from the budget point of view. That is also the are pros and cons in both the approaches, right? So that is the just briefly I have just mentioned. But you can have a lot of literature regarding the project method approaches and all Big bang and phage wise, okay. Both has their pros and cons. Okay. So is it clear now? So I've just tried to explain in a very short way, right? Okay. Okay. So now let's regarding this case study I will be introducing. Then we will go to the implementation track. So I will be ask you to read this, okay. Because it's a little lengthy 18 page document. Okay. I have a prepared especially for this track. Okay. So there is a business requirement will be there. I'm just summarizing what is the written here, okay. And what what exactly you are expecting. You think of now like it is a being a recruiting product owner for this project. So let's say you are taking the ownership of this product, okay. And what are the things you have to do? Okay, so that has been mentioned here and he has been asked. So here you can see as the case study says, okay, so what are the things he will be doing? He will be doing because the project will require at a high level the project requirements have been kept here, okay. There will be recruitment integration with a different product. You also need accuracy and effectiveness of your recruiting system, right? And also Mr. Sadiqi has been asked by the Senior leadership that document every requirements in a user story format. What is a user story? Anyone would like to comment? The process will be kind of the story like a story like drafting, like uhhuh. It is like a story like kind of case. You have to prepare for the understanding. Have you ever done, have you ever done any projects scripting those or drafting those requirements in form of a user story format? No. No. Then it will be very good learning for all of you today. Right? So this is again not enforced by SAP because whenever you are taking the requirement from the clients, you can take in a different format. Sometimes people in the WhatsApp or meeting whatever the client will be telling, they will be taking meeting notes and they will be capturing those notes in a. They call it business requirement document. Okay. In some projects they use a term called brd. You might have heard or not brd, that means business requirement document. They prepare. Okay. But again that's a very generic one. People do it, okay. But sometimes people take meeting notes and they make an Excel sheet spreadsheet. And sometimes during your pre sales, whenever you are pitching to the client to take Success factor product, right There will be having a sometimes, every time, whenever your client is actually during the vendor selection, right? That process definitely clients must have given a list of requirements. It can be 100, 200, 400 requirements. I have seen up to thousand requirements, right? So then Excel sheet and they use the Excel sheet for vendor selection. So let's say in the market top three products are Success Factor, Workday and Oracle, right? So what they will do, so they will be floating the their advertisement this company. So in this case the Finbo company might have done one six months back. They floated their tender, okay. Or there is a posted in the public domain that okay, they are looking for a product to manage their recruiting system. Put an advertisement rather, okay. And what they're looking for they must have uploaded and accordingly different companies, product based company or consulting companies, they would like to participate in that bid and all and they will be analyzing those requirements, what can be doable, what cannot be doable. And they will be coming up then finally this company, the Finvo might have decided that okay, out of these three products, success factor is meeting my 90% of the requirement. Okay, let's say war is meeting 85, Oracle is meeting let's say 75% requirement. So then they have decided to go ahead with a this success factor. This is actually happens in every project. You might have seen if you talk to any pre sales guy in your company, okay. Or anyone who has worked the business. Actually they will be telling the entire background story. Okay? It it this entire process again takes somewhere around six month through one year. Okay? So this is a pre implementation because I have worked on that side as well. Okay? Understanding those requirement and analyzing those requirements, that's again a different kind of exercise. Okay? Generally presales guide do it. Okay? And with the business, right? And that is how. So let's say if. But when it comes to requirement gathering, right? If you are working as a business analyst and all. So Mr. So here in this scenario. So what he has done, you have been. Suppose you are a business analyst. Mostly this is job of a business analyst. But as a consultant in your project, okay? If you do not have a business analyst, you have to wear the hat of a business analyst. That's the how I have done in my project. I have learned also. So that's the way. But in a bigger project and all people will be having dedicated business analyst who will be creating those user stories and all, okay? Ideally it will be the Excel sheet, okay? Or it will be a Jira. There is a tool called Jira. Have you heard about or have you any used JIRA tool, by the way? Yes, I used it. Jira, right? You heard heard about it. Okay. So this is actually Kanban. Yes, exactly. They take the philosophy of a Kanban and they use those kind of a tool to capture those okay. Requirements or capture this so that you can track. Actually that's why. Okay. Either way you could use Excel. But there a smart way of doing. There so many tools in the market. But Zera is one of the most mostly used in the bigger companies or small companies. Okay? Mostly I have seen Jira in my last project also we have used Z, right? So what will happen? So what I will do here? So there are again different, different Personas, okay? So whenever you're talking about recruiting module, right? So you will be having a Persona from a recruiter. You will be having a hiring manager, okay? You will be having your agencies third party agency who will be providing you resumes and all. There will be also candidate, okay? So you can think of who are the stakeholder or who are the key Personas in this entire module. Whenever you're implementing, okay? So that is where you have to decide, okay? For every Persona, okay? Suppose you are a recruiter, right? So as a recruiter you have to reach out the real recruiter. What exactly day to day he has to do or she is doing it, right? So you will be finding the user story has a syntax. It Is actually following this. If you have gone through any kind of a scrum Agile course or or methodology, they follow a typical template there which is a industry standard template. Although SAP doesn't say you have to do it in this way. But big companies and target whenever you are going for or many startup also, right? It is always better to take a requirement in this format. Okay, so if you see in this format, the format goes like this. It starts with every user story starts with a format called as a. As a. Then there will be a role name. So here it is a recruiter, right? Role name. What I want. Suppose you have to put yourself as a recruiter. You can think of yourself a recruiter what he or she wants he or she wants to be able to create and manage job posting. So that again, if you see every sentences which I have formulated here, right? Everywhere we have a edge a there is a role what is the want? And there will be a so what so that so that is very important. Whenever if you traditionally, if you have seen any any kind of business requirement, generally what happens Clients will be giving the requirement, but they do not know what is the benefit. Actually. Okay, so you have to actually go next level saying that okay, so this is the requirement. What is the benefit I will be getting? Okay, if there is this would be a value also. Okay, so whenever you are taking any requirements, it should not take it blindly. There should be an outcome which must be some beneficial in terms of you're saving some money or you're saving some time or you are increasing your productivity. This would be some value. So that is how so this requirement gathering. I always prefer this is the best way so far. There can be something may come in the future, but this is the way we have to take the requirement. And these are again nothing special to any industry. Mostly every company they require it. But again you have to go through this. Okay, so my idea, my expectation is for you to see each and every every I will give you Excel format as well. But what you have to do so to think actually so but thinking is very important. Whenever you will be going to any clients they'll be asking some requirement. You should be able to understand whether it is doable or not doable. If it is not doable, there should be some workaround for that and all. Okay, so that's the way this user stories. I have created some sample user stories regarding so from different RFP from a real time project which I have worked earlier. Okay, so from there I have captured a lot of requirements. Okay, so for Recruiter I have allow almost 35 requirement for a hiring manager. Right? What he wants to do here. Okay, so there is some requirements again 21 requirement. Then the candidate people who are actually applying. Okay, so you think of yourself as a candidate, what are the possibility? Okay, so all those require user stories I have given. So the the task for you will be like you go through all the user stories. Okay. You may have to think about it whether it can be done in the success factor recruiting or not. Okay, so by. Because already you have covered those operational track, right? So now you are in a position to understand whether it is doable or not. Then the next level is how to do it, who you will be covering in the implementation track. Okay, but this is a kind of a parallel assignment because I will be focusing more on the system now onwards. You parallelly keep your this user stories thinking format so that after two weeks what I will do I will be checking with you. I having a check in. So whether you are able to see or whether you're able to do or whether you're able to think about it, whether it can be done, if it can be done, how it can be done. So how part actually I will be asking you. Okay, so maybe in the form of an assignment you have to submit it, right? So this is something I usually do and there is a actually Google Se so you don't have to document everything in the word file. I have a Google set format like this. Okay. Which I will be sharing after the session. Okay. And that will be basically you can do it. Okay, so you can. You will be writing the rules here and there will be format whether it can be done or not. Then if you're doing how it can be done. Okay, so that is the overall quick introduction of the user. So I will take a pause now. Is there any questions or whether you understood or not this what is the ask? Okay, understood, right. Okay. Because I want more realistic thing to happen in this session so that you can relate to it each other. Okay, so that's the plan. Okay, so now let me go to the system and we will start with the our implementation tag. So this is a background story or you can say from implementation point of view. Just motivate to you to work in this way. You are having a project going live in April 2024 and you have to think about it, how it can be done, in which configuration you have to do it, whether it can be. So I have done it independently. Don't think that everything is possible in success factor. Okay, There can be also possibility. I have given as a requirement. Okay. It may not be doable. So that is also fine. But you have to find find a way how to achieve that. Okay. That kind of a Q A. We will be doing up to two weeks. Okay. By the time we will be almost covering almost measure implementation side of it. Okay. So let's see. And we will start from there. Okay. So.