Raw Transcript: Video M9rl_ev78lA

saps fora implementations can provide a lot of value to organizations but they can also be very challenging and there's a lot to know a lot of moving parts to understand as part of an sap S4 Hana implementation so what I want to do today is talk about everything you need to know about sap s4a in today's training course my name is Eric Kimberly the CEO of third stage Consulting we're an independent consulting firm that helps clients throughout the world with their digital transformation Journeys we help clients through their saps for Han implementations as well as implementing other systems as well and I started my career as an sap consultant back in the 90s and over time sap as a product and as a company has evolved tremendously as foran is the most recent offering from sap and a lot of organizations are migrating to as foran here especially in the larger Enterprise markets so much so in fact that there is a shortage of resources and a shortage of skills within the S4 Hana space especially as organizations try to migrate from their old Legacy ECC product which is the old product that sap used to provide which has now been replaced by s4a so what I want to do today is provide a detailed Deep dive into sap S4 Hana as a product as well as s4a implementations and the things you need to know to make an sap as foran implementation successful and this video is designed for anyone ranging from Project team members that are going through a project for the first time Consultants that might be trying to learn more about saps fora and for executives that might be trying to gain a deeper understanding of what s4a is and how to become more successful in their transformation so I highly encourage you to share this training video with your team members and other colleagues that you think might benefit from this content now for more information to augment this training I encourage you to check out two resources I provided for you in the links below one is our guide to s4a implement ation it's a detailed Deep dive into some of the best practices we'll talk about here today but there's some additional content in that white paper that I think you'll find beneficial you can read that paper for free by scanning the QR code in front of you or going to the links below I also encourage you to check out our new podcast series called journey to S4 Hana it's a podcast series that we recently launched to help organizations through their transformation Journeys involving saps for Hana and you can learn more about that podcast by going to journey to s4h han.com so the way we've broken up today's training content is first of all we're going to provide an overview of s4a as a product just understand what it is what its strengths and weaknesses are and how it might fit into your organization then we're going to get into some implementation best practices we'll talk about the things you need to know to plan for and to actually execute the implementation of your S4 Hana transformation and then we'll get into some case studies at the end so be sure to stick around for that part at the end of the training we'll get into some failure case studies as well as as a deep dive case study involving one of our clients we'll play you a clip of an interview that I recently conducted with that client related to their s4a implementation some of the lessons learned from that so we'll start off with some very conceptual things to begin with but then we're going to shift gears and get into case studies including one specific case study at the end of this training so be sure to stick around for that first it helps to understand what exactly s4a is what the is what the architecture looks like how it compares to other systems in the marketplace and just some of the general strengths and weaknesses of the product as well this provides a good base level understanding of the product so that you can be well prepared for what you're about to go through in your S4 implementation back when I first started my career sap was R2 and then it became called R3 and then there was ECC more recently and now s4a which was released a few years ago now a couple things that are different about S4 Hana when compared to some of those Legacy products that I mentioned before one is that S4 Hana is built for the cloud it can also be deployed on premise but it's also able to be deployed in the cloud either as a single cloud or as a multi-tenant software as a service type of offering the second thing that's different about sap and S4 Hana is that S4 Hana is built on the Hana platform and Hana is a database that sap built and in the past sap used to rely on Oracle databases for the for the back end of their software now they've got their own Hana database that has been designed to really take away that dependency on their competitor's database and it's not just that they built a database to lessen the dependency on Oracle it's also a database that's pretty groundbreaking it's something that is designed in a unique way that it can track information and data and transactions without consuming as much database capacity as traditional databases so it has helped speed up the real-time performance and visibility that a lot of organizations are looking for in their Erp software where S4 Hana does fit best is for organizations that are large that are complex that are diverse multinational have very complex needs those are the type of organizations that tend to Faire best when implementing S4 Hana another common type of customer that S4 Hana tends to experience is going to be Legacy sap customers so a lot of customers that are using R3 or ECC or maybe even business one those are some of those Legacy products that a lot of companies are migrating from to get to S4 Hana and sap has outlined a deadline of 2030 to get their legacy customers on to sorana so you see a lot of legacy sap customers that are more likely to move over to S4 Huna and that's not to say that if you're on sap now that you need to stick with S4 Hana it may be that it makes more sense to look at Oracle or Microsoft Dynamics or some other sort of Erp system so it's really important to recognize what your needs are look at your options compare the different systems and options that are out there now one thing I will say is that S4 Hana is not nearly as robust or mature or as developed as some of its Legacy counterparts so in other words you look at ECC which has been around for over a decade and a lot of big companies are using ECC and have for quite some time and many many millions of dollars have gone into the R&D to develop that product and improve that product over the years as for Hana on the other hand is a complete rewrite of the software built for the cloud and it's on a new architecture with Hana as I mentioned and so it doesn't have the robust and complete development as some of the Legacy sap products now this is changing over time and every month and year that goes by this comment becomes more obsolete but at the time I'm recording this video when we compare S4 Hana to other sap products and other Legacy systems in the marketplace it's still a work in progress so when evaluating the system it's really important to make sure you identify where those gaps are understand where the gaps are so you recognize what they are and what the risks are and you also use that as a way to determine whether or not it's the right fit for you now despite the fact that S4 Hana has these new groundbreaking Technologies and some major enhancements and there's even some additional enhancements I haven't talked about things like artificial intelligence and machine learning those are examples of some advancements and enhancements that sap is making with S4 hun but despite these technological advancements there's still a lot of challenges with sap implementations and they tend to be fairly risky Endeavors even though there's a lot of upside potential getting there is a lot more difficult than a lot of organizations realize so some of the challenges with implementing sorana are first of all that as I mentioned in the last segment a lot of the capabilities are still being developed or incomplete at the time I'm recording this video so it's important to recognize what those gaps and corresponding risks are now another difficulty and risk and challenge of implementing s4a is something that doesn't have so much to do with the technology itself but more with the nature of the types of organization that are generally implementing these types of products and that is that these are complex implementations they're complex Transformations when you're talking about s4a it's a very broad robust diverse set of capabilities it's a system that can do a lot of different things even though there are limitations it can do a lot of different things within an organization and if you're a big Global multinational company or a diverse complex organization and you're trying to implement sf4 or any Erp system system for that matter it's going to be a very complex transformation it's going to be very difficult to go through the changes because you're a larger organization you're more diversed you're more complex and chances are you've been around for a bit longer than most organizations so you have a lot of business processes that are pretty well baked into the way you operate and changing that is going to be a lot more difficult so S4 Hana implementations tend to be fairly painful and it involves a lot of change and there's a lot of risk that goes along with that so making sure that you have the right set of risk mitigation and project management in place is going to be very important there are a number of ways and a number of things you can do to be successful and the first is to understand whether or not s4a is the best fit for you if it's the best fit for you then great let's move forward and figure out how to be successful but you want to make sure that you're clear on what those weaknesses of the software are and you're want to be clear that it is indeed the right system for you and the best way to do that that is to objectively and independently evaluate S4 Hana against your needs when compared to other Erp systems in the marketplace the second thing you can do to be successful is to make sure that your team is aligned starting at the executive level and working our way down to the project team and all the rest of the stakeholders and employees within your organization you want to make sure you're all aligned rowing in the same direction headed in the same direction and what I mean by that is not just being aligned on whether or not we're going to implement S4 Hana or if we're going to implement it in the cloud or on premise or whatever the case may be but more importantly what do our business processes need to look like in the future how are we going to leverage the technology to enable those business processes and where do we need to customize to perhaps Shore up or address any of the deficiencies that we see in the system so those are some of the examples of things that you need to do to make sure you're aligned and if you're aligned as an organization that's going to get you a lot further than your counterparts that may not be well aligned a third thing that you can do to be successful is to really focus on change management and S4 Hana with all its bells and whistles can be very enticing and it can be easy to go down a bunch of rabbit holes of technological capabilities and new features and enhancements that stuff's all great but at the end of the day what's more important and what's even greater is looking at your people and your operations and how you're going to change those people and operations and the more time and money you invest in that the non-technical aspect of your S4 Hana implementation the more likely it is that you're going to be successful and then finally a fourth thing you can do to be successful in your s4a transformation is to have realistic expectations going into it a lot of times you will hear from either sap Andor the system integrator or your value added reseller that this Project's going to be easy they might give you a boilerplate proposed project plan and timeline and budget but the reality is most organizations and an overwhelming majority of organizations tend to take more time and money than they expect expect during their sap projects so be sure you add a dose of reality and objectively look at whether or not a plan makes sense for you and pivot where necessary and adapt to the plan to your needs and also adapt the budget to fit reality and what your needs are now that we understand what S4 Hana is let's shift gears and talk about how to plan for the implementation as fora implementation are very complex the product itself is very complex because it's so robust it has so many different integration points so many different modules and in some cases multiple systems in the case of arba and Concur and success factors and some of the thirdparty systems that sap has acquired over the years so implementation planning is critical and this is one of the steps that a lot of organizations skip over or gloss over so it's very important to make sure that you take the time to plan the implementation upfront partially so you have realistic expectations so you can actually achieve the goals that you've set in terms of your implementation plan and budget but also so that you can make sure that the sap implementation aligns with what it is you're trying to accomplish as an organization so let's jump into S4 implementation planning and the things you need to know about that so to start then it's important to look at digital transformation initiatives and what are some of those transformation enablers certainly the technology itself the sap s4a technology is something that is a key enabler for your transformation but in addition to that you also have your implementation Partners your system integrator other outside consulting firms you might be working with as well as your company and your internal internal resources and when you look at the layers of transformation on the right side of your screen there's four primary layers here you've got the process side of things you have the technology side of things you have the people or organizational change side of things and then you also have your business operations so those are the four primary areas that we help our clients prepare within as they get ready for their their S4 Hana implementations and one of the key takeaways from this slide is that project success is heavily dependent on your company and the things you do prior to implementation when we look at sap failures and some of the expert witness cases that we've been involved with over the years A lot of times it's the decisions that weren't made appropriately during the implementation Readiness stage that lead to problems later on and so success and failure can largely be traced back to what you do and how well you handle the implementation Readiness component of your your sap project so beyond that in terms of looking at why implementation Readiness is so important first of all it saves you time and money if you think about it you're going to have a system integrator most likely or a reseller a VAR that's going to come in with their sap functional Technical Resources they're probably going to send a small army of people to help deploy the software and once they land on site the meters is running and every hour and day that goes by that you're spending making decisions or trying to get alignment within your organization that's costing you time and money so the more time and money you spend upfront during the implementation Readiness stage this more smoothly your project is going to go and the better use of your external and internal resources you're going to make it also mitigates risk so one of the big risks of sap projects is not having the right level of involvement from your internal people and not having the business process and organizational change sides of things figured out so it does mitigate risk of failure and it also ensures alignment so looking at making sure that from the executive team all the way down to the project execution and some of the detailed technological decisions that are made during the project you want to make sure that you have alignment throughout the organization so when we look at sap transformation Readiness there's five major components and we talked about four of them already and we added a fifth one here on this slide which is strategic and executive alignment so we look at how well aligned and ensuring that your your executive team is aligned strategically we look at operational Readiness we look at technology Readiness as well as people Readiness and then project governance so those are kind of the main components of a uh implementation Readiness engagement and some of the major work streams that we typically look at and we're going to talk here in a second about what that what those work streams look like and some of the objectives that we see coming out of an implementation Readiness engagement or the implementation Readiness phase is going to be to prepare the company to optimally engage with the system integrator prepare your interal team for Change and ensure that your team is engaging early making forward progress and learning um so that you ultimately have ownership for for the project early on and so really what we're trying to do here is create awareness and education mobilize the team gain alignment and prepare for the system integrator activities that are required to happen during the implementation stage so typically when we're working with clients during the implementation Readiness phase of a project there's three different parties involved here first of all and more most importantly is your organization and owning the project ensuring that your internal resources are provided to the project making key dis business decisions that need to be made and really just driving the overall transformation from a business perspective you also have your system integrator or your VAR or your reseller who specializes presumably in sap who has the functional technical expertise of of sap is able to transfer some of that knowledge to you and help mobilize the external technology and functional team members and then when we're working with clients in these types of engagements within third stage we're providing somewhat of an extension of our client's resources in terms of capacity and capabilities so ensuring that some of the Preparatory activities are happening um and we're taking some of that off their plate and also providing implementation Readiness co-responsibility with the company so we we work side by side with the company and oftentimes a system integrator as well early on to ensure that we are preparing for the implementation and we have um the things laid out that need to be laid out and those things are are going to be covered here in just a second and it also enables us to provide an independent project quality assurance and organizational change management role beginning early on before the implementation ever starts and it also allows us to address some of the nonsp project roles that the system integrator isn't able to provide and we'll talk about that in more detail here in a second so when we look at a sample implementation Readiness Plan this for this particular client that we put this together for they happen to require a six-month Readiness phase leading into their implementation this is a multi-billion dollar company a global organization largest transformation that the company has ever done so we really wanted to make sure that the organization had everything in place they needed to have in place so that when the system integrator showed up at the end of month six and the small army of Consultants showed up that we were making the best use of their time key operational decisions had been made we we've secured the executive alignment that we uh required we have a pmo established we have some project governance set up um and also having an organizational change management uh plan in place as well so when we look at the implementation Readiness review too um you you see that some of the outputs coming out of the process are are uh things that will feed into the the implementation so outputs that come out of this implementation Readiness phase will ensure that we have a strong linkage to the actual uh implementation activities so these outputs and deliverables that come out of the implementation read a stage are intended to augment not replace things that happen during implementation so it's meant to provide the first iterations some of the key foundational decisions that are going to happen within each of these work streams uh leading into the implementation activities that that are required uh coming into that so the first area the first work stream that we look at within executive alignment is to uh is is strategic and executive alignment that's the first work stream within implementation Readiness so that's where we look at uh ensuring that the executives are aligned in terms of their overall project strategy and uh that we have this the stakeholder assessment defined as well as the executive uh and management Communications as well and making sure that Communications plan is in place and that the the executives are starting to get on board with the overall project we also have the stage gay review at the end of the implementation Readiness where we make that go no-o decision of are we ready to start implementation do we have the right decisions in place are we ready for the system integrator to arrive and to start working with us so those are some of the the key things that happen there and when when I look at what causes failure or problems during sap projects often times it's because we haven't articulated what's going through the executives heads in terms of what they want to accomplish as an organization and with the overall project we haven't translated those into specific project goals and and objectives so that's really the purpose of what we want to do here in this work stream of implementation Readiness is to ensure that we have that that sort of clarity and we've translated the goals and objectives into things that are specific to the project project we also look at operational Readiness so a lot of times companies find that when they begin their sap implementation there's a bunch of decisions that need to be made around how they're going to run their business and they haven't made those decisions yet and it's a some of these are very difficult decisions to make so we want to bring forward as many of these decisions pre-implementation as we can because these are strategic decisions not they're not decisions necessarily that are going to be driven by how sap is configured out of the the Box these are key business decisions that we need to make as an organization that are independent of of sap now having said that there are certainly are certain business functions or processes that are going to be dependent on sap those you set aside and say we'll deal deal with those during implementation we'll also do the same with lower priority business processes things that are not competitive advantages of ours or their commodity based business processes let's set those aside we'll deal with those during implementation but for the things that are strategic to the company their competitive advantage strategic differentiators and things where sap provides a certain amount of flexibility in terms of how it can handle the functionality we want to make sure we Define those decisions early on in the process and while we're doing that we're also defining things that can change potentially from our for our business processes and so we start to look at things that we can start um rolling out now process and procedure types of changes that we can roll out in Phase zero or things that we can start changing now even before sap is implemented we often find that somewhere between 30 and 50% of process improvements we identify during an sap project you can actually start rolling out ahead of time which makes things easier from an operational or organizational perspective so you're not forcing all the changes all at once within uh within the organization and then we also look at people Readiness so during this this pre-implementation or this implementation Readiness stage we're looking at the skills and competencies that you have on your staff now and what you're going to need going forward and then we also start building the organizational change uh plan and team so that by the time the project starts we have our entire organizational PL change plan our entire organizational change team and uh we've actually begun some of the organizational change management activities at the more strategic level one of the important things that oftentimes gets over overlooked from an organizational change management perspective is typically system integrators treat organizational change management as more of a tactical software BAS based change management whereas during implementation Readiness you want to be looking at more strategic change management things like organizational design how are jobs going to be impacted do we need to change roles and responsibilities do we have to rewrite job descriptions um are we redefining how people are reporting to one another are we consolidating business processes those are pretty major decisions that if you try to make and do during the sap project during the formal implementation one of two things will happen one is you're going to rush through those decisions and probably settle on the way things are now because it's easier and the times time's ticking and the meter running or um you end up not implementing the changes well because you're rushed to get through the project so the sooner we can pull these activities forward the more effective your organizational change management is going to be when you get to the more tactical change management which is typically what the system integrators focus on things like training and Communications related to the usage of S4 Hana versus the more strategic types of things that we're talking about here and then there's also technical Readiness this is the uh the fourth of five work streams within implementation Readiness this is where we look at your current infrastructure and put together a migration plan of how are we going to move from decommissioning all your legacy systems and all the old data and uh Integrations how are we going to migrate that over to sip What's the timing going to look like uh what's what is the interim in between phases of the roll out presuming you're doing a phase roll out what are the interim integration points and things that we need to have in place we also look at data cleansing and mapping so data is typically on the critical path to completion and a timely uh implementation so we start some of that data cleansing and mapping early on during implementation Readiness and then finally we also look at uh the the uh it organization itself ensuring that we look at the competencies and skills that it organization has now internally and looking at the training and skills development that will be required for your internal it organization to support sa going forward so we really start to mobilize that sap Center of Excellence concept during implementation Readiness to ensure that you take more ownership and control of the project and that you're not relying too much on outside consultants and that so your it Department can be more educated and more um more educated more sophisticated and and being able to be more of a true partner with your system integrator rather than deferring uh to your system integrator too much because they have all the knowledge and you don't so this really gives your it Department a leg up on getting the uh 2B it skill sets that they need to support the deployment of this nature and then finally we have project governance and planning so this is where we start to get the project Charter the project team in place we develop the overall implementation plan make sure that we have think of it as your your program management plan that includes not just your system integrator but activities for your internal resource verus in any other third parties that you're going to pull in for example if you have third party organizational change Consultants or third party data Consultants uh whatever you may have that you're going to use to augment your team you want to make sure you have an overall program management structure in place your system integrator is typically only providing the plan for their activities but you need to put together more of a a program management plan and along with that we're also identifying risks and uh risk management risk mitigation plan as well as we're going through the process now that we have an understanding of how to plan for an N4 implementation it helps to understand what are some of the best practices and lessons and tips and takeaways that we can apply to our implementations themselves so as we get into execution mode what are the things that we can prepare for and put ourselves in a position to succeed in our S4 implementations so in this module of the training we'll dive into some sap s4a implementation best practices that will help you through the process one of the first things you can do to be successful in your S4 Hana transformation is to go in with eyes wide open these projects are not easy and I think most people understand that sap projects or any sort of transformation project is not easy but there's some things unique to us4 Hana that we need to understand before embarking on a project and these are things that are often hidden by the software vendor and by system integrators because it doesn't help them sell software and some of the things and probably the biggest thing to keep in mind when implementing S4 Hana especially in today's day and age is that S4 Hana is not a complete product it still is not fully mature it's not fully baked it's not nearly as robust and mature and sophisticated as its Legacy predecessors in R3 and ECC so if you're a legacy sap customer that's something to be particularly mindful of or if you're implementing sap for the first time you may find that there's functionality or capabilities that you may have expected to see in one of their legacy products but you're not seeing in S4 Hana so one of the biggest things you can do is even once you've decided on S4 Hana is really poke holes in it and do a gap analysis and figure out where those weaknesses are where those failure points might be not because it might change your decision but because it's going to inform a better transformation plan it's going to help you identify the risks and it's going to make sure that you don't gloss over the risks or worse yet be blind to the risk because the sales reps don't necessarily want you to see that so identifying those risks and poking holes in the system and going in with eyes wide open overall is one of the most important things you can do to start a project many organizations we work with are implementing as for Han because they have to either because they're using an old version of sap and they know they've only gotten until 2030 to get off the old version of the system or perhaps they're on some other system that's no longer supported or outdated or just no longer meeting the needs of the organization and often times those are the number one reasons why companies implement the product and when implementing s4a or any other technology want to have a much clearer vision than just we're implementing it because we have to we need to understand what exactly we want to accomplish what end State we're looking for at the end of the transformation what exactly we want as fora to help the business do how we want to improve the processes and how we want our organization to look going forward so those are just some of the things we need to look at when defining our clear strategy and vision for what it is we want to accomplish and this is a really important way to drive alignment within the organization by taking just a little bit of time upfront to further articulate what your overall strategy and vision is you're going to create a certain amount of alignment in education and understanding within the organization that's going to help the project be more successful when choosing a system integrator it can be easy to think that we're just going to go with one of the big names one of the proven Commodities one of the big Deo accent cap Geminis ER and Youngs of the world but the reality is there's a lot of good options out there there's a lot of really robust very effective system integrators in the marketplace and there's a lot to choose from every organization is different it has different cultural and functional and skill set types of needs from their system integrator so it's important to find the system integrator that's the best fit for you and this comes down to a number of different criteria that you may prioritize differently based on who you are but a lot of times you want to look at not just cost and not just technical capability and knowledge of the software but you also want to look at cultural fit how good of a fit are the individual team members with your team how good of a fit is the organ organization itself the system integrator themselves how well would that fit potentially with you as an organization you also want to look at the methodologies being used by the system integrator and there may be other factors that you want to consider as well but those are some of the main criteria you want to use and if you're looking for ideas on who some of the best system integrators are in the market we work with them all on a regular basis feel free to reach out I'd be happy to share some examples and notes with you on that topic so one of the biggest mistakes that organizations make when beginning an implementation is they've decided that they want to implement S4 Hana they pick a system integrator and they jump blindly into the implementation the system integrator and the software vendor encourage you to bring on the army of resources the army of Consultants to start billing by the hour right away and in the meantime we haven't figured out what we want to be when we grow up a lot of these organizations still have yet to Define what they want their processes to look like how they want the organization to look and their overall vision and strategy for the transformation and when you don't have that stuff in place you're kind of Flying Blind you end up with the system integrator that comes in and one of two things happens either they start making the decisions for you because you're taking too long or since you haven't figured it out yet they'll decide for you what your implementation is going to look like or they afford you the opportunity to make those decisions but the meter is running and you're racking up billable hours and billable time while you're trying to make decisions around what you want to be when you grow up so one of the biggest things we can recommend as it relates to this is make sure that you've got your ducks in a row and you've got everything in place that you need to have before you bring on your system integrator now a word of warning here is your system integrator will put immense pressure on you to start right away because they have a lot to gain by starting the billing right away and if they're going to put 10 or 20 or 50 or 100 or however many resources on your project they're going to want that to kick in as soon as possible but that's not in your best interest what is in your best interest is to make sure you recognize and Define what it is you want your organization to look like at least at a high level in terms of your business processes and how you want to create common business processes or improve some of the high level processes and also how you want your organization to be defined because the better Vision you have for that the more ownership and control you can take of the project unless you're going to have to defer to the system integrator and overpay for the system integrator services so don't jump blindly into project make sure you have everything you need in place pre-implementation most system integrators in the S4 Hana space and ecosystem use the activate methodology which is sap P's implementation methodology and it's a way for companies to have a repeatable process to deploy Des fora technology now it's a great starting point it is a useful starting point it's better than starting from scratch but two things need to happen when you're looking at these methodologies one is you want to make sure that the methodology is appropriate for you there might be things you want to tweak or adjust for your organization for example agile is something that's baked into the activate methodology and it's becoming used more and more by more system integrators and organizations deploying and for many organizations an agile approach is very appropriate but for some organizations a more traditional waterfall approach is more important and I have a separate video out there that unpacks the difference in the pros and cons of agile versus waterfall that's a whole separate topic that I encourage you to check my YouTube channel for but the key here is make sure that you define the methodology that makes sense for you and the activate methodology may need to be modified to fit your needs the second thing you want to keep in mind as it relates to the methodology is that the activate methodology is not meant to be a complete end to end transformation methodology and what I mean by that is it's focused on deploying S4 it's not focused on how to redesign your organization and how to change your business processes how to get internal alignment and executive alignment how to build your internal competencies that you need to support the product going forward all those are examples of things that are very necess and critical to an S warana deployment but are not necessarily part of the activate methodology so when you're planning for your project getting ready to move into the S4 Hana transformation be sure you look at the methodology adjust it as needed and augment it as needed as well another common shortcoming of esor Transformations is the implementing organizations commonly don't build the internal competencies they need to be on equal footing with the system integrator and what I mean by that is if you don't know much about sorana or you don't know much about how a transformation should work it's going to be really easy to just defer to the system integrator Outsource to the system integrator and allow the system integrator to essentially take over the project and that's a recipe for disaster because you need to have ownership of the project you need it to reflect who you are and who you're trying to become and while you want to leverage best practices and the expertise of the system integrator there's a fine line and a balance you need to find so what we typically encourage clients to do is figure out how we can wrestle some of that control and knowledge from the system integrator and start to build it inhouse so that we have an IT department for example that knows sorana at least at a basic level it doesn't need to be to the degree of knowledge of a system integrator but you can take training courses you can get your hands dirty learn the technology and the more your team knows about the technology and understands how these Transformations can work the more that they can be an equal partner in this whole transformation rather than an imbalanced situation where the system integrator is taking control so that's one of the biggest things you can do to be successful is to build those internal competencies now one of the secrets of S4 Hana Transformations is that organizational change management is probably going to be the number one factor that determines how successful you are or that determines whether or not you succeed or fail and organizational change management goes well beyond training Communications user adoption it it also includes things like change impact assessments organizational Readiness stakeholder analysis overall organizational design benefits realization there's a whole host of things that it includes and I've actually included a link to a video below that talks about change management in a lot more detail and all the things that should go into your change plan so those are some of the things to keep in mind as you think about your overall implementation plan is to make sure that you're investing heavily in organizational change management because s4a entails a lot of really disruptive technology and capabilities that can be very difficult for an organization to adapt to even though it has a lot of potential to improve the business longer term it's important to get through the short term though to where you get your people to really fully Embrace and understand how these new processes will work so organizational change management is a huge key to your success and last but not least we want to make sure we have a strong project governance quality assurance and risk management framework in place this is going to be what allows us to identify what the guard rails are to make sure we stay on track it's going to identify when we start drifting off the rails or off the tracks and it's going to help us proactively mitigate risk before they become a problem that we really start to feel that's something that we can't necessarily fix by the time we feel that pain so we need to proactively identify those risks make sure we ensure quality assurance and really keep the project on track and getting back to the point about finding the best system integrator one of the flaws or deficiencies of system integrators in general is that they aren't usually very good at identifying risks as it relates to their own activity and their own resources so if you think about it if you have a team of 50 or 100 people on a project and you as an organization are making a lot of money as a system integrator you're not necessarily incentivized to start pointing out all the things you're doing wrong and all the things that are creating problems on the project so it can be very important and very effective to have a thirdparty quality assurance function that helps make sure that the project stays on track allows you to have sort of an extension of your own project management team representing your interest not the software vendors or the system integrators best interest and really use that as a way to ensure that you have somewhat of an insurance policy to keep your project on track ensure you don't spend more time and money and resources than you need to so for example third stage is one such example of a company that can provide that sort of third party quality assurance so these are a few of the biggest lessons learned that we have from working with clients across the world with their S4 Honda Transformations and they're not all the examples of things that you should do but they'll really increase your odds of success if you focus on these handful of things I've provided here today [Music] now one recurring theme we've talked about so far when we've talked about planning for your S4 implementation and some of the general s4a implementation best practices is this concept of organizational change management in other words the human aspect of change sorana is a very complex robust sophisticated product and with that come some challenges from a people and user adoption perspective so what I want to do here in this next module is dive a little deeper into change management itself as it relates to S4 implementation so that you can make sure to address one of the biggest risks in any S4 implementation which is the organizational change side of the transformation so when embarking on an S4 Hana transformation many of us recognize the change management is going to be one of the most important things that'll determine whether or not the project is successful or if it's a failure now the activate methodology includes some basic core change management type stuff but in my opinion it really just scratches the surface of what's required to make a transformation successful and when we think about change management for S4 Hana deployments it's important to think about it not just in the context of user adoption in other words how do we use the system but to really think more strategically around how can s4a and how will s4a more strategically change our organization and how can we leverage change management to enable some of those more strategic changes the other thing to recognize is that even if you're an sap shop that's already using ECC or R3 or one of the Legacy sap products in you're moving gu for Hana s4a is a big deal it's a big change from those old SAP systems so this is going to be a lot more disruptive and a lot more of a change than you might think and so change management is especially critical in that sort of transformation these larger organizations oftentimes have trouble getting their Executives aligned on what exactly this project is and how exactly they want to change their organization to work within the context of an s4a roll out so for example s4a provides an opportunity to consolidate operations to create a common operating model to tie together disparate operations throughout the globe if you've gone through mergers and Acquisitions it's an opportunity to act like one company instead of multiple companies so with that comes the need to make sure that Executives and other key stakeholders within your organization are all aligned on what exactly this transformation means to your organization now it's a lot more than just saying we're going to implement new technology we're going to replace our old sap system or old Legacy system there's a lot more to it than that there's decisions and Alignment that need to be achieved around what do we want to be when we grow up how much do we want to standardize our business operations how independent do we want to allow different parts of the organization to remain or not those types of decisions need to be made quickly and early in the project before you start building testing and rolling out new S4 technology and when Executives and stakeholders are not aligned on some of those answers that's what creates the head winds that often times leads to challenges and ultimately failure for a lot of s4a Transformations so one of the first steps in in effective change management strategy and plan is to make sure that you facilitate a process to ensure that your executives are aligned you're all headed in the same direction marching to the same beat of a drum and all have a clear vision of what it is you want to be when you grow up a second very important component of organizational change management as it relates to es Morana Transformations is the whole concept of organizational design what do we want this organization to look like as we move forward I mentioned before that s4a Transformations provide the opportunity to move to a shared services model for example where you might consolidate your accounting or your it or HR or procurement functions into a centralized common business operating model that's one opportunity you have other opportunities to move to a common operating model or common set of operating business processes throughout the globe or throughout multiple locations and and that sort of change will typically require organizational design and definition of what people's roles and responsibilities are going to be especially in the case of moving to a shared services model or a common business process model those require pretty significant changes to people's jobs and significant changes to the human component of ns4a transformation there's also the Gap analysis component here that we've got to consider as part of our organizational design activities we have the Gap analysis between where we are today and how people are operating today and what their jobs look like today and what they're going to look like in the future you also have the Gap analysis between the system and its capabilities and what your needs are as an organization and sometimes there's a gap there S4 Hana isn't the perfect solution nor is any other solution out there in the marketplace so we need to figure out what are those gaps and how are we going to shore up some of those gaps from a change management perspective and then another thing to think about as it relates to organizational design is a conversation that most of us probably don't want to have and that is what about jobs that might get automated or lost in this whole process with S4 Hana comes pretty significant automation opportunities with robotic process Automation and machine learning artificial intelligence and it's just accelerating sap is investing heavily in those areas so over time the capabilities for s4a to automate your business is going to increase which is a good thing from a profit and loss and efficiency perspective but what does that mean to people's jobs how would they be impacted will people be displaced if they are going to be displaced do we need to retrain them do we need to move them somewhere else that is a really important part of organizational design and also benefits realization and realizing the business value of your s4a investment is going to come from so these are all things we need to think about as it relates to organizational design which is an important part of your organizational change strategy as part of your s4a transformation anytime you introduce new technology into an organization you're introducing some sort of cultural change whether you intend to or not you're not going to change who you are overnight your culture has been developed over years and decades potentially over 100 years depending on how old your organization is so introducing a new technology isn't going to change things overnight but you want to be deliberate about how you might bend your culture to fit where it is your headache in the future so for example I use the example earlier about the organization that goes out and acquires companies through mergers and Acquisitions if you're an organization that has grown through merger and acquisition or even if you've achieved organic growth chances are you've probably organically grown and your culture has organically evolved over time and now you may be looking at this as an opportunity to act more like one company to act like a unified company to have common business processes and that requires a cultural mindset change to employees and the way they do their jobs so you want to have a clear cultural change plan and a cultural change strategy that puts you in the driver's seat of how do we want our culture to look and how are we going to use this S4 Hana transformation to shape our culture and to bend our culture to become who we want to become in the future and if we don't spend time focusing on that the culture is going to evolve or maybe even devolve into something that we don't necessarily want so having a Clear Vision for that culture and the cultural change that we're aspiring for is something that's critical to consider and include as part of your change strategy training is probably the most commonly understood aspect of change management when we think about organizational change we think we need to train people how to use S4 Hunter how to use our new system how to conduct their new processes that certainly is true but training needs to entail more than just how to conduct transactions within a system we have to train people in a way that's customized to our organization how their business processes are going to flow what their job looks like in the context of this new S4 Hana transformation and even what our business processes and decision- making processes are outside of the system so we've got to Define all that stuff and train people in all that stuff as part of the end user training so we have to go well beyond just teaching someone how to create a purchase order or teaching someone how to close the books in the s4a technology we need to talk about how you specifically are going to conduct your job both inside and outside the s4a system and we also need to educate you on how that is different than the way you're doing things today and why you're doing things differently so this all requires a great deal of customization to ensure that we have a training approach that's tailored to your organization the other thing to consider is that most training materials that come with an S4 Honda deployment are going to be very generic they're going to be not tailored to your industry or your business processes or the way you've configured or customized the S4 Hana technology so you want to make sure that you're tailoring those materials for your organization now sap has a product called sap enable now I believe it's a product that they Acquired and it's a way to tailor some of the training materials for your specific organization so they do have a tool set available to help you do that there's also a thirdparty systems out there and some of them are better and more cost- effective than enabl now and they're also technology agnostic and independent which I'm happy to share with you information about those Technologies but the point here is you have options out there there's tools that will allow you to tailor your training materials for your organization for your industry for your business processes and for individual people and work groups within the organization so be sure you're investing the right amount of time and money in your project plan and overall budget to tailor your training materials for your organization this is an area that most change programs that we see that we're not involved with they tend to overlook that area so we want to make sure we inv heavily in the customization of training materials for your s4a transformation now even if you're an existing sap customer moving to S4 Hana chances are an esor deployment is going to have a massive impact on the types of it skills and capabilities you need to have in- housee it's not a matter of whether or not your people are capable of learning it but it's a matter of making sure they've got the right skills make sure you bring in the right people that have the right skills to support this future state for example many S4 Hana deployments are cloud-based and that's a lot different than the old on premise R3 or E implementations so the point here is when you look at all the impacts that this is going to have to your organization and the types of skills that are required the types of upskill and potentially going out and bringing in new people we have to think about what is our it organization going to look like in the future are we going to have the same size it organization are we going to grow our it organization are we going to scale it back are we going to swap people in and out are we going to retrain them we need to have a very solid plan for how it is going to not only support the implementation but also they're going to support sorana in the longer term post implementation so one of the most important points or components of a change strategy for S4 Hana Transformations is making sure we've looked at our it organization and redefined as appropriate what that it organization is going to look like and put together a plan to help us transition to that future state of our it organization now one thing I'll note is the longer you wait to do this and the more behind you get on this particular aspect of change management the more likely it is your Sy system integrator is going to come in and run the program for you and it's going to be harder for them to leave it's going to be harder for you to wean yourself off that system integrator when you haven't built an IT organization that's able to keep up and able to have the right level of skill set and competency to support the implementation so my recommendation here would be not to wait until you're getting close to go live to then think about how's it going to support this longer term but instead think about that upfront what does the organization need to look like and how can we build out a more robust more appropri at right-sized it organization to support RS4 environment early in the process so we're not overly dependent on system integrators or outside consultants and we can actually be more of an equal partner now we've talked a lot about how to plan for an implementation how to execute the implementation how to address the people side of the implementation but let's talk about a specific methodology that sap recommends for its implementations and that methodology is called the activate methodology and this method ology has gone through some branding and nomenclature changes over the years but has largely remained the same in terms of Sap's definition of how the product should be implemented so what we want to do here is dive into the activate methodology not just what it includes but the things that it does not include because an activate methodology is going to be good at helping Define how to deploy the technology within sap but it isn't necessarily going to address some of the business and human components of the transformation so in this next module I'm going to talk about not only the activate methodology what's included in it but what is not included in it the things that you need to augment to make sure that you are enhancing and connecting the dots between Sap's activate methodology and what you might need for your organization the problem that we often see with clients is once the technology has been selected and we decided we're moving forward with S4 Hana maybe we've got part of the company that's already using S4 Hana perhaps we've decided to consolidate uh all the entities onto one instance or one platform whatever the case may be we've decided we're moving forward to S4 Hana a lot of the challenges that we see though is that companies don't know what to do next they assume that the right thing to do is just to adopt the S4 Hana activate methodology bring in the system integrator who's going to adopt that for them and start implementing stuff and what ends up happening is you end up rushing into the implementation without a Clear Vision or plan you end up delegating too much of the responsibility to your system integrator and you end up setting unrealistic expectations for the deployment so what we want to talk about today is what are the things we need to do and be aware of as we head into the s4a deployment particularly as it relates to the activate methodology and things that we need to do to augment that so this is a phenomena that we often refer to as cliff diving when when companies select sap they decide it's time just to go and start doing stuff they don't have a Clear Vision they don't have clear Direction system integrator takes control of the project the meter starts running on the Consultants while you're trying to figure out what you want to be when you grow up the technology ends up driving the business rather than the business driving the technology and you end up spending too much time and money on the project causes a lot of frustration it's a lot to absorb and it and it dismisses or defers a lot of the ownership of the project to your system integrator so there's a lot of different risks that come along with this phenomena known as cliff diving from the time we select the software and just jumping straight into implementation what we'll suggest here is what are the things that we need to do in addition to that activate methodology that you might your Tendencies your instincts might be telling you just to jump straight in but we're going to talk about what are those things that we need to augment that activate methodology that your system integrator or your implementor might be bringing to the table so to set some further context when we look at what causes an s4a transformation to be complex there's a number of different layers things that contribute to the complexity the time the cost the effort that it's going to take to make your s4a project successful and the three things that have the biggest impact on that are process change the degree of process change that your organization will exper experience as a result of the S400 transformation the amount of people change so how much people's jobs will change and how open to change they are or not that whole where you fall in the spectrum is going to determine how much time and effort it's going to take and then how big of a technology shift this is for you if you're going from an as400 Legacy green screen system over to s4a that's a pretty big jump if you're using a you know Y2K or post Y2K semi-modern Erp system maybe a tier 2 system but now you want to jump over to sap that's that's a little less complex and certainly if you're using ECC or R3 or one of the Legacy sap products that's less of a a jump still a jump but not as much of a jump as as some of the other scenarios so really just understanding where you are on the journey how big of a jump it's going to be what are the things that are going contribute to the complexity of the transformation is a key step here and one thing that the activate methodology assumes is that we're all starting from the same place but we're not we're starting from very different places and we've got to adjust that activate methodology and Aug aug M that activating methodology for who we are where we are where we're headed what we've been through what we're trying to accomplish with this project there's a lot of customization even though that's a bad word in this industry customization of the methodology not the software but customization of the methodology that we need to do to make this relevant to us and make our S4 hun project more successful so we have to think about are we ready for the activate methodology there's there's a lot of things we should be doing before we even start unpacking this activate methodology and on the right side of the screen you see the the general structure the general framework for the Sap's activate methodology and this is the similar approach that a lot of the system integrators uh will follow this is Sap's prescribed approach topl playing s fora some really good stuff in here some definite improvements over ASAP and some of the other older methodologies that sap and others had used to deploy the old products but there's still a lot missing it's still very Centric on technology it's it's helping us figure out how to configure and build and test and move the data into S4 Hana but it's not giving us a clear road map for how to transform our entire organization and that piece that last part is arguably the most important part and that's the stuff we need to start on and get a clear Direction on before we start moving over to the activate methodology so on the left side of the screen you see some key things that are missing from an implementation Readiness perspective some of the things that should be done before you start deploying the activate methodology before you start designing building testing the software we need to figure out where we're going to be when we grow up we need to figure out what our business blueprint is what this overall transformation means to us what it needs to look like and then we figure out how Now activate will help enable that so the left side of the screen includes some things that are missing from activate things around organizational design defining what people's roles and responsibilities are are we going to standardize those business processes it activate methodology assumes we've figured some of that out and we've defined our general processes now we just need to translate that into S4 H well most companies haven't figured that out yet they're trying to figure that out on the meter while the meters running with the system integrator and the consultants and they end up rushing into a decision or they end up taking their time making the right decision but they end up spending way too much time and money on the implementation because they were letting the meter run while they were making those decisions so the more of that upfront work we can do the more time and money we'll save as we get into activate the change impact analysis is a very important organizational change component we want to figure out how we want to build skills and competencies those non-technical skills and competencies to support the s4a transformation and then also how we want to build the S4 Hana competencies itself so that we're not overly dependent on our system integrator or outside Consultants we actually have people internally that can start to stand toe-to-toe with the system integrator and be a true partner rather than having to defer to the partner defer to the system integrator to a fault U because they just don't know any better they don't know the techn techology so so the more we can do to get a leg up on the stuff the better that implementation is going to go and the more effectively we're going to be able to leverage that activate methodology when we get to that point in the journey but the key is when do we get to that point in the journey um like I said you don't want to jump straight into activate you want to make sure you're ready you've got a clear blueprint road map then start to deploy the activate methodology along with your system integrator Consultants your your Technical and functional Consultants so this is a road map for the implementation Readiness that we typically advise our clients through we have a we have probably six or seven clients right now as a recording this video that we're helping them through their implementation Readiness for their s S4 Hana transformation so these are the five major buckets or work streams a lot of detail behind this that I won't get into we have other videos on my YouTube channel that you can check out that unpacks this one slide and breaks it up into multiple slides and more detail and templates and stuff like that but this will at least give you a vision or a high Lev sense of what should be included so first is your strategic and executive alignment that's a very important part of making sure we've got that figured out because activate is not going to help us figure that out activate will not solve that problem for us so we've got to make sure we've got strategic and executive alignment and direction for this project so that we can better use that activate methodology the operational Readiness that's more consider that the business blueprint not the sap s4a blueprint and and using Sap's nomenclature but more the business blueprint that overarching map of who we are much like a general contractor is going to have a blueprint for how to build a house before we start building in the the before we start bringing in the drywall uh people the the plumbers the electricians uh the roofers all that stuff we need to First have that blueprint understand what it is we're trying to accomplish and what the general road map is then we start bringing in the system integrator or the plumbers in this case using that analogy to figure out how s4hana and the activate methodology can enable some of those business processes defined in that operational Readiness workstream now we also have people Readiness so there's a people Readiness component that's uh think of that as organizational change management not training Communications but the organizational design the more strategic organizational change components that activate methodology does not address but yet it's critical to your overall transformation you do that part right activate methodology becomes that much more effective so we start to figure out how what is our organizational change team what's the or design what's our communication plan how are we going to start to implement some of those organizational design changes even before we start building and deploying the software and then there's the technical Readiness making sure we've got a Clear Vision and road map for what the architecture is going to be how we're going to move data over um how we can start to build that internal Center of Excellence or internal competency around s fora so that Our IT staff can be on equal footing or at least an equal partner with our system integrator and and provide some of that functional technical knowledge inhouse rather than out sourcing the entire thing and it makes knowledge transfer that much easier later on if we can do that up front and then finally the project governance and planning that's that's one thing that uh I don't believe in my experience that activate the activate methodology nor the system integrators in the sap ecosystem are generally very good at some are but most are not and so we need to figure out how what what is our overall project governance what is how we going to identify mitigate risks and what's our overall transformation plan our overall road map what what is in and out of scope for sap for s4a where are we going to plug in third party systems all that stuff we we need to have a clear vision and and uh governance around so when we're working with our clients generally we end up acting as an extension of our client's pmo we end up providing the project management capabilities the um the risk management mitigation arm of the project and we also end up being the ones that'll help plug some of these gaps that we're talking about plug the gaps that your system integrators don't provide the activate methodology doesn't provide and those are typically things that we just talked about on the previous slide things around organizational change at a strategic level process reengineering the overall program management risk management that sort of stuff so you'll notice though that we're you see us off on the bottom left you'll see your system integrator off on the bottom right notice who's at the top it's it's you it's the implementing organization that ultimately owns this and it's important that you end up qu squarely in the driver seat of this project and and we're always there to help our clients do that we want to enable them to be empowered to drive the project the way that they feel as best and leverage outside experience in a very targeted and deliberate way rather than doing the the traditional let's just Outsource this to system integrator X and spend x amount of money and let them handle it that that is a recipe for a disaster so let's figure out a way to own this so we can control this project take accountability and ultimately have some sustainability for this longer term for ourselves and this is a highle project QA framework we use with our clients throughout n S4 Huna transformation beginning in that early stage of implementation Readiness and certainly throughout the activate methodology as well we're applying these different lenses that we analyze and assess a project and identify risk and mitigate risk um in ways that the activate methodology typically does not address so I won't go into this in detail again there's another video out on my YouTube channel that covers just this framework and dives into this framework in more deta detail if you just search my YouTube channel for sap QA you should you should be able to find it there but this hopefully gives you a high Lev sense of what is some of that QA quality insurance type of stuff that I need to do to ensure that the project is [Music] successful now that we've covered a high level overview of how to implement s4hana it helps to talk about what are the things that commonly go wrong what are some of the risks in s4a implementations so what I want to do here in this next module is describe and discuss some of the biggest risks we see with our clients that are implementing Asana to ensure that you can be aware of these risks so that you can ultimately mitigate them along the way now the first risk you should be aware of when you're going through an S4 Hana deployment is that the product itself is incomplete it's not a complete comprehensive solution in the same way that R3 or ECC was and what I mean by that is S4 Hana is a rewrite of the Legacy sap technology which is a good thing but it's very much a work in progress and you need to be aware of what some of those gaps and deficiencies are as you deploy as foran largely so you can figure out how you're going to address those gaps are you going to put in some sort of besta breed Point solution to address the gap or you going to customize s4hana to address the need are you're just going to have a manual processor workaround you just need to have a deliberate strategy for how you're going to deal with some of those shortcomings for example we have a few clients that are actively implementing S4 Hana that are in the manufacturing space and they're finding that there's some deficiency icies and things missing when it comes to more advanced manufacturing capabilities things like production planning and demand forecasting things of that nature some of those Edge capabilities so to mitigate that risk it's important to do a fit Gap analysis to really understand what the capabilities are of the product today versus the needs you have as an organization today as well another risk to be aware of with S4 Hana deployments is the fact that the systems are relatively siloed in the past sap had created most of its technology from the ground up fully integrated its own Technologies but in more recent years sip has taken more of a sort of a best of breed approach where they've gone out and acquired different systems to augment the capabilities of S4 Hana for example sap has in recent years acquired a Reba concur success factors products to help with HCM and procurement and time and expense reporting for example so what that has done is it's expanded the capabilities of sap and its product Suite but it's also created integration issues that can be challenging for organizations going through a transformation so it's very important to recognize that this is not a fully integrated system or Suite of products and you want to make sure that you've allocated enough time and resources to ensure that you address those integration issues another risk with s4a implementations is the activate methodology now the activate methodology is Sap's methodology for deploying s4a which is a great starting point IT addresses a lot of the needs for a deployment but it doesn't address all of the needs and it leaves some key critical success factor s out of the methodology first of all activate is very much focused on an agile approach to implementation and while agile can be a good way to speed things up in an implementation s for Han implementations are so integrated and complex throughout an entire organization that it's critical that you take the time UPF front to plan out your end to end business processes and your business requirements and perhaps take on more of a waterfall type of approach and I'm not going to get into the details of the pros and cons or the merits of agile versus waterfall but just know that within the activate methodology it's very much focused on agile which can create challenges and risks in the implementation in addition you want to look for other deficiencies within the activate methodology and augment the activate methodology with other activities they're going to be critical to your success things like solution architecture integration data migration organizational change management those are examples of areas they're relatively weak within the activate methodology but if you want to be successful UC F you're going to have to beef up those areas outside of the methodology so just be aware that the activated methodology may be a great starting point but you're going to need to build a more complete and comprehensive methodology in order to be successful as fora and its sister Suite of products are so integrated and so comprehensive which is a strength of the product Suite it also creates a lot of complexity and so there's a lot of complexity you need to be aware of as you go through a transformation like this so if you think about your organization and all the different functions and end processes and workflows and the systems and Technologies you have in place now now you're moving to a suite of products that are going to replace those systems and that's going to affect your entire operations your entire business and so there's a lot of complexity and risk that goes along with that and so you want to make sure that you have solid risk mitigation and change management in place and both of those are things that I'm going to build on and get to later in this discussion because organizations implementing S4 H are more likely to be larger more complex and perhaps even Global organizations they are more likely to experience change management issues in other words the magnitude of change and the volume of change that the organizations implementing s4a are going to go through is very big so it's important to recognize that one of the biggest risks is not just with the technology itself which in and of itself is very complex and complicated and risky but perhaps even more importantly the fact that your people are going to be impacted very significantly by S4 Hana now even if you're a legacy sap user that's using either say ECC or R3 some of the older sap products it's still a massive change for organizations it's a complete rewrite of the product it's a reimplementation it is not an upgrade it is not a lift and shift despite what sap or their system integrators may tell you so it's very important that you recognize it as such you plan as such and you put together a strategy and road map that reflects those realities and a key component of addressing those realities is to have a very solid and very effective and very comprehensive Oran organizational change management plan back to my point earlier about the activate methodology being pretty light in change management you need to do a lot more than just training and Communications you need to get into change impact you need to get into organizational Readiness you need to get into cultural change organizational design a lot of different components of change management that need to be addressed to make your s4a implementation successful one of the trickiest part of s4a implementations isn't necessarily just in the product itself but in the organizations that that help you implement the product so in other words system integrators or implementation partners that specialize in implementing s4a chances are they're more likely to be large Consulting organizations like the big four system integrators deoe Accenture eron young PWC whoever it may be very large Consulting organizations that often times have a conflict of interest in your implementation what I mean by that is their loyalty is usually first and foremost to sap because they're a partner of sap and also to their army of Consultants that they need to keep gainfully employed and those two things more often than not are in Conflict at times with your goals and objectives and so there's a material conflict of interest often times in these sorts of implementations that you need to be aware of because your system integrator has a conflict of interest and this is where it's really important that you take control and take charge of your project and don't defer to your system integrator and the biggest risk of this being a problem is if the system integrator is larger than you as an organization with which often times they are because some of these system integrators have hundreds of thousands of employees and just have a lot of bandwidth and scale that can overwhelm a smaller organization even if you're not a small organization so just be aware of the fact that system integrators more often than not have a conflict of interest and it's up to you to manage and mitigate those system integrators and make sure that your project stays on track just to build on the previous point a bit more and elaborate on the concept of armies of Consultants it's important to recognize that the big system integrators are going to put large teams of Consultants on your project in some cases the resources allocated are relevant and appropriate for a project like yours but oftentimes there's too many resources on a project it's too consultant heavy you don't need as many consultants as are often put on these projects and I remember dating back to the early days of my Consulting career when I would be on projects as a newbie when I had absolutely nothing to do but yet I was billing full-time on the project because I was expected to so I would be staffed on a a project with 40 or 50 other consultants and it would be up to me to find work to do and to keep billing the entire time I was trying to find work to do and it's something I've seen repeated throughout my career not just for me personally when I was working for an sap system integrator but even with our clients nowadays and looking at what the system integrators do with our clients we're constantly battling that Dynamic of that self-interest I talked about before which is the need or the want to put a bunch of Consultants on your project because it maximizes revenue for the Consulting organizm ations so this is a very real risk and it's a very real reason why so many implementations go way over budget is because there's too many consultants on the project in the first place and there's a lack of transparency into what those Consultants are doing and a lack of accountability on behalf of the system integrators so stay tuned because in the next few recommendations or risks I'm going to talk about I'm going to talk about how to mitigate this and some of the other risks we've already talked about another challenge related to sap implementations is a lack of realistic planning more often than not sap and their system integrators will provide an overly optimistic plan of what it's going to take to implement the product and I don't recall the last time that I've seen a realistic implementation plan that was something that was actually achievable more often than not it looks something like an 18-month duration regardless of how big or how complex an organization is and the actual cost of an implementation is typically multiple times what's initially proposed by the system integrator or BP and in some ways you think this might be deliberate it could be the fact that they're trying to lowball the number just to get the deal or it could be they just don't understand your business well enough so the key is to make sure that you have a realistic plan and that you've objectively looked at what the strategy is what the plan is what the resource requirements are what the budget is all that good stuff and you want to make sure that you do that not just by taking sap or the system integrators proposal at face value but by augmenting it with other activities and things that need to happen to make the project successful and the best way to do that is to leverage independent technology agnostic third parties that don't have a vested interest in making sure that you deploy as much sap technology as possible but rather are more focused on making sure that you as a client are successful in the implementation so that realistic planning phase is one of the most important things you can do to mitigate the risk of unrealistic plans next is a lack of risk mitigation sap projects are notorious for taking too much time too much money going completely off the rails and part of the reason for that is because there's a lack of effective and agnostic and objective risk mitigation so what I mean by agnostic mitigation and effective mitigation is to really look at and proactively anticipate what the potential risks are and start to mitigate those risks before they become a problem and the problem with sap implementations getting back to one of the earlier points is that the system integrators oftentimes are protecting their own self-interest so their self-interest prevents them from necessarily pointing out to you where all the risks are their job is to make themselves look good and to reinforce the fact that you made the right decision by hiring them as a system integrator and more than anything they need to protect their revenue Stream So if they're the ones identifying potential risks and problems on a project that's not in their best interest however it is in your best interest and you need to make sure that you identify what those risks are and so you can mitigate them accordingly so independent and Technology agnostic consulting firms like third stage Consulting are good examples of ways that you can independently and objectively identify and mitigate those risks along the way number 10 on our list is a lack of value realization in other words organizations that are implementing S4 Hana are notorious for not focusing on the business value and focusing too much on the technology itself and what they're going to do with the technology and that's a big mess because what it does is it creates a two-fold problem one is it causes you to invest so much in the technology that it becomes a big blow loaded project with budgetary overruns which hits you on the cost side and on the benefit side you're not realizing the business value that you expect to get because you've spent so much time and money and focus on just implementing the technology so one of the ways to really maximize business value is first of all to make sure you have a business case a realistic business case of what your cost and potential benefits are going to be not only to justify the project but more importantly to ensure that you track benefits and you actually realize business benefits and the business value of the implementation the other thing is to make sure you really get a handle on the cost side and the scope side of your transformation more often than not organizations just bite off more than they can chew they decide that they're going to implement every module Under the Sun within s4a they're going to implement arba they're going to implement success factors they're going to implement concur ibp or integrated business process planning and every other product that sap has to offer some or all of them may be relevant to you but chances are pretty slim that your organization is able to consume that entire Tech stack so one of the most important things you can do to mitigate risk on that front on the business value front and the ROI front is to ensure you've got the right scope it may make more sense for you for example to narrow the scope and to cut back the scope and really focused on the high value areas and maybe invest a little bit more in change management or invest more in integration to your other systems things are going to deliver more business value but at the end of the day regardless of what the decision is that you make you want to make sure that you're doing it in the context of a business case and the overall business value that you expect to get so what is it you do about it I know I've alluded in passing to some of the things you can do to mitigate the risk but I also want to leave you with three key things that you can do to mitigate the 10 risks that I've talked about here today first and foremost you want to make sure you take the time upfront to invest in an implementation Readiness phase or a phase zero of your implementation this is where you make sure that you've defined your future State End to End Business processes your business requirements and and created really that overarching business blueprint for your organization that includes things like what your organizational structure is going to look like in the future what the jobs are going to look like how you're going to integrate systems what the architecture is going to look like your business process improvements and how you're going to roll out those business process improvements so that whole piece of implementation Readiness is critical and keep in mind that this phase that I'm advocating is a lot different than what system integrators typically do what they typically do is what they call a business blueprint but what they're focused on is designing software and what I'm talking about is designing what your future State business and organization and overall technology stack is going to look like and one piece of that is in fact as for Han and your system integrator should be involved in that but there's a lot more to it than just that one piece of the overall puzzle so that's one step is to make sure you have an implementation Readiness phase up front to ensure that you can be effective in the actual implementation later on the next thing is to ensure that you have a very solid and effective programing management office or pmo established this could be an internal pmo if you do have an internal pmo group it could also be outside Consultants independent third party Consultants like third stage consulting or it could be a hybrid or combination of both but regardless you want to make sure that you have people that are experienced in complex digital Transformations but also are not affiliated with the system integrator or sap software vendor reason for that is because you need someone that's objective and detached from the self-interest that I talked about earlier in this discussion and then finally last but not least you want to make sure that you have a very solid and effective quality assurance and risk mitigation framework in place I talked a little bit about that earlier in this discussion but that's something that should also be conducted by an independent objective agnostic third party that isn't affiliated with sap or with the system integrator just as you typically don't want the fox guarding the hen housee you also don't want the system integrator or sap telling you where the risks are because they're going to tell you that everything's fine and so you want to really have that objective quality assurance and risk mitigation framework to ensure that you can uncover those risks objectively throughout the transformation now that we've talked about some of the general risks with saps 4 implementations let's talk about why some of these projects fail and there's a fairly High failure rate of sap implementations and Erp implementations in general not just S4 Han but any Erp implementation is high risk there's a lot of failures in the marketplace that we can point to for any software vendor but sap in particular has some unique implementation risks and reasons why the projects fail so what we want to do in this module is talk about what are some of the common reasons why s4a implementations fail one of the primary root causes of why S4 Hana implementations so commonly fail is the fact that S4 Hana is a complex product I don't necessarily mean that in a bad way it's not a bad thing on the surface but what the complexity does it creates implementation challenges but first let's talk about what I mean by complexity when I say say S4 Hana is a complex product what I mean is it's a very Broad and expansive product a lot of organizations pick S4 Hana because it can do so much a lot of larger organizations Diversified Global organizations pick s4a because the software can handle their diverse and scalable business needs so it's generally a good thing that sap as for Han is so complex but when it comes to implementation it escalates the risk and the reason for this is because so much of sap is integrated with other parts of the business so for example if you make one change to one part of the business or one part of the software it's going to affect other parts of the configuration and the design and deployment of the software as well so the complexity of the software is something that is just hard for a lot of organizations to get their heads around even in situations where the organization is migrating from a legacy sap product it's still a big jump and it's still in many cases more complex than they're used to so it's important to rec recognize that sap is a complex product it takes a lot of time to Define how these different end to- End Business processes are going to tie together how the modules will be configured how the integration is going to work how we're going to make sure we test the system to ensure that that integration and that complexity is being dealt with so you just want to make sure that during your implementation you account for that complexity and you ensure that you have the right project governance and resource allocations to ensure that you can mitigate the risk of that complexity another root cause of why s4hana implementation so commonly fail is the relative rigidity of the product and again this isn't necessarily A Bad Thing even though the word rigidity oftentimes has a negative connotation often times or more often than not organizations that are deploying as fora are doing it because they want to deploy a standard set of operating tools and business processes so that's what they're buying is that rigidity they want a software that can standardize business processes and drive a common operating model and drive consistency throughout the organization but the problem during implementation is that it ends up being a shock to the system it ends up creating a lot of culture shock creates operational shock in many cases because you can't simply replicate necessarily what you've been doing in your legacy system within S4 Hana S4 Hana has a set of common business processes and workflows and either it works for your business or it doesn't so often times what that does is that relative rigidity creates a painful trade-off that needs to be made either we're going to customize the software which creates a whole another set of risks and complexities in our implementation or we can just force the business to adapt to the way that the software was built and neither one is a perfect answer neither one is easy they're both painful in different ways but the problem is many organizations don't plan for that and they don't plan for the implications of that and I'm going to come back to the point of change management here later in this video so be sure to stick around because that is one way you can mitigate some of the risks of the rigidity of S4 Hana another reason why S4 Hana projects so commonly fail is because organizations don't have a good handle on what the real total cost of ownership is going to be for their implementation and for their ongoing support of the product so in other words often times organizations sign a contract to license a certain amount of s4a and either they don't realize what they're getting themselves into on the surface with that contract Andor they realize later in the implementation that they didn't buy enough modules or there's additional modules that they're going to need because they didn't do enough vetting of the core product to understand what the strength weaknesses of the product are I mentioned before the rigidity of the product as well so the fact that S4 Hana is relatively rigid and standard means that there's cost associated with that so that trade-off I described in terms of choosing between changing the business to fit the software or changing the software to fit the business that takes additional time and money and oftentimes organizations don't account for that additional time in money which is why so many projects go over budget and take more time than expected so one of the most important things you can do to overcome and mitigate this Challenge and this risk is during the implementation planning phase or the phase zero the pre-implementation of s4a you really want to take the time to really vet out and fully understand where the gaps are in the product what the decisions that need to be made around are we going to change the software or change the business to fit each other's needs make sure that we understand what exactly we're buying what exactly are we Contracting for and make sure we negotiate a deal that doesn't lock us into higher cost structures later on those are just a few of things things you can do to ensure that you're avoiding this issue of higher total cost of ownership than you might expect one other hidden cost to be aware of with S4 Hana implementations is the ongoing internal it support so when you think about the skill sets and the competencies and the roles you're going to need to support the S4 Hana product you want to make sure you have a Clear Vision for that as well and that's something else you can do during this pre-implementation phase of your sa s4a implementation another reason why S4 Hana implementations so commonly fail is because the organizations implementing the product don't have effective program management in place to ensure they've got the right project governance and controls to avoid some of the problems we've talked about what they do instead is they hire a system integrator or an implementation partner or maybe sap Professional Services to come in and do the implementation for them but you have to remember they have a conflicting self-interest that would suggest that the longer the project takes and the more billable hours it takes for them to deploy technology within your organization they're going to be more profitable but that hurts you as an organization add to the fact that the technical work stream that sap and their implementation Partners typically provide are just one workstream within a broader program they're not the right party to be managing the overall program management they can manage the technical workstream but you still need program management to manage that overarching overall program that would include things like process Improvement and organizational change management architecture data migration integration all that stuff that falls outside the realm of S4 Hana Tech technical implementations so making sure that you have your own internal pmo or program management or at least some sort of thirdparty program management support is something that can help mitigate that risk and by the way our team of third stage Consulting oftentimes provides s4a project teams with that program management expertise and capability so that you can have ownership and control of the project and you can put some of these guard rails in place via project governance and controls finally and perhaps most importantly organizations often fail in their S4 implementations because they don't manage organizational change well we talked about how S4 Hana as a product is relatively rigid It's relatively complex and that leads to a lot of organizational change management issues especially if you haven't used an sap product in the past implementing s4a can be somewhat of a culture shock to the organization it creates a whole new set of Technologies and tools you need to use but it also impacts your culture it impacts your operations the way you've done business in the past is now being disrup disrupted For Better or For Worse so you need to make sure that you have effective organizational change management in place to be successful in an s4a implementation and the problem is is that sap as a software vendor and Sap's implementation partners and system integrators typically don't do change management they say they do but what they really do is basic training and and user training for using the product that's not change management that's a small component of change management but there's a lot more to it now that we've talked about how to implement sorana and what some of the biggest risks are and some of the failure points are let's talk about some specific case studies and we're going to start off by talking about some of the top sap failures of all time in fact we'll do a top 10 countdown of the top failures of all time we're going to go through some high-profile sap implementations and the things they did wrong we're not doing this to scare you or to make you think you should not implement s4a but again it's a way to underscore the risks of implementing s4a and also to underscore the common mistakes that organizations make when they're trying to deploy a technology like sap so let's walk through in this next module the top 10 sap failures of all time in 2013 the large retailer Target decided that they were going to expand into Canada and as a new entity a new organization within this new country the idea was that they would stand up new systems to support the supply chain and the overall retail operations for Target in Canada in this new market so the understandable assumption was that this would be an easy implementation because there was no Legacy system to replace they were starting from scratch they could Define their new processes in a way that fit their business but that's not how things went it didn't go well at all what ended up happening is that even though they had no data to convert they still had to create some master data and other data elements to stand up the system and as part of that implementation only 30% of the data and that's 30 30% of the data was entered accurately so they were starting from the beginning with bad data from a fresh implementation now this data inaccuracy wasn't just an inconvenience it also caused the supply chain to collapse they had the wrong information about the wrong inventory levels about the wrong materials and products that they needed to buy and that created a number of issues throughout the supply chain and their supply chain was highly ineffective at its launch and so the sap implementation did not go well it wasn't stood up in a way that supported the business and ultimately it failed and it had to be cleaned up and that cost the company a lot of time and money in the long run anytime you get sued by your shareholders for a failed sap implementation you know you're doing something wrong and that's exactly what happened with Revlon when they tried to implement sap now at the time Revlon tried to implement sap in around 2016 they had just acquired a company called Elizabeth Arden which was a competitor and was a product that got rolled into the portfolio of Revlon products and and business units at the time Revlon was using a legacy system from Microsoft Dynamics AX and Elizabeth Arden was using Oracle financials and the idea was that they were going to replace both those systems with sap as part of the sap implementation and so at the same time they were trying to integrate the operations of these two businesses they were also trying to implement a new technology long story short it didn't go well they started with a pilot at a manufacturing plant in North Carolina in the United States and that implementation and that roll out failed miserably to the extent that they couldn't ship product from that manufacturing plant and they lost millions of dollars of sales as a result of that outage and that disruption to their manufacturing operations and this was just the first location of many that was meant to go live at some point throughout the sap implementation but they pulled the plug on the project and regrouped after that failure in North Carolina now this resulted not only in Lost customer orders but it also resulted in extremely high cost from Expediting shipments because they didn't have the right inventory at the right place when the customers needed it so their cost structure went up considerably and at the end of the day shareholders ued Revlon as a result of this failed implementation and that's enough to land Revlon at number nine on our list of top 10 sap failures Woolworth Australia is number eight on our list of top 10 failures and the reason for that is that they tried to upgrade their legacy product that they had been using for about 30 years was a homegrown system they tried to upgrade it to sap and it didn't go well during the six years the Woolworths attempted to implement sap at their Australian business unit they experienced a high amount of turnover among executive staff and project team members and that resulted in a lot of lost tribal knowledge along the way and that contributed to a lot of the challenges that the organization faced in addition at the time that the organization went live they weren't able to create a p&l or profit and loss reports for the individual stores throughout the country that created a lot of visibility and management issues because they had no idea how much money they were making or what their profitability of the organization was which is risky for any organization and one of the root causes that the company identified in addition to the loss of knowledge and talent during the implementation was the fact that they didn't properly document and understand what their business processes were going to be in that future state so that was one of the lessons they took away is they didn't Define their future State ahead of time so they ended up spending the actual implementation itself trying to figure out what they wanted to be when they grow up and that is what created a lot of the challenges along the way so all this is enough to land wol worse at number eight on our list of sap failures coming in at number seven on our list is a us-based utility called National Grid National Grid is a large utility based in the northeastern United States they went through a three-year implementation they went tens of millions of dollars over budget but that's not the biggest of the problems first of all when they went live with sap they weren't able to pay their employees the proper amounts they overpaid thousands of employees they underpaid another a few thousand employees and it created a lot of disruption and Chaos as you can imagine within the organization so they couldn't do something basic like run payroll successfully in the new sap environment in addition they had over 15,000 vendor invoices that they couldn't pay creating some credit credit issues and credibility issues with their suppliers and they also couldn't do the financial reporting they needed just to keep their line of credit and their financial instruments in place with their Banks so they ended up losing some of the liquidity that they were relying on as a result of the fact that they couldn't provide accurate Financial reports to the banks now to add insult injury or maybe you could consider this a self-inflicted wound National Grid decided to go live a week after Hurricane Sandy hit a large portion of their customer base in the northeastern United States and for those of us that live in the United States we remember that that was a massive storm that created a lot of collateral damage a lot of people were without power for a long time not at all an ideal time to go live with a new Erp system now the key thing is that National Grid knew that the hurricane had happened and they still decided to go forward with their implementation just several days after the hurricane hit so not only were they dealing with a failed thatp implementation but they were also dealing with outages and sort of once in a century sort of issues and maintenance and repair and outage issues that utilities sometimes face at the end of all this National Grid sued their system integrator for $75 million and they were awarded a large share of that as a result so all of this is enough to land National grd at number seven on our list of top 10 sap failures in 2014 Miller Kors was running seven different instances of different sap products throughout the organization and they decided that they were going to move to a single instance of sap as part of their sap rollout that same year they hired the system integrator HCL to manage the implementation and it did not go well what ended up happening during the implementation was they had thousands of open items that they had to address at the time of GoLive and throughout hyperare post Gove hyperare of the implementation and many of those defects were critical there were things were absolutely critical to ensure that the operations could continue to run but yet they still went live anyway as a result of this failure Miller quers sued HCL for $100 million big sum of money but that's not the end of it HCL also counters sued Miller K saying that there was management dysfunction and that was the real reason why the project failed a lot of finger pointing to go around I don't know who was really at fault it was probably a combination of both parties but the fact of the matter is is that there were bad decisions made as part of this project both in terms of the way the project was planned the way risks were mitigated the way issues were worked through and ultimately if what HCL is saying is true some of that management dysfunction may have undermined the overall transformation as well so this is a good reminder of the many things that can go wrong during an implementation and the things you need to be prepared to plan for mitigate as part of the transformation so all of this is enough to land Miller cor is number six on our list of top 10 sap failures coming to number five on our list is a European company called lease plan and that's a vehicle rental company based in Europe and they actually had just rolled out sap at their Australian business unit and decided to roll out sap to the rest of the organiz ation and that didn't go well the product from sap was called a core Leasing system which is an industry specific variation of the sap product they try to roll it out to the rest of the organization and they experienced a number of challenges along the way despite investing 92 million EUR in their implementation the project ended up delivering what they considered a product that was not fit for purpose in the environment that they were operating in what they also stated was that the monolithic nature of sap didn't support their business model and the need for flexibility and the changing world and the competitive environment that they were operating in and they ended up scrapping the product of that 92 million euro investment only1 million EUR was ever fully salvaged and that 14 million was related to some of the custom development and custom applications that were developed as part of this overall transformation the company lost millions of dollars in restructuring and Consulting fees to try and clean up the mess and ultimately they ended up opting for for a best of breed solution to replace that attempted sap implementation Sol of this is enough to land least planed number five on our list of top 10 failures now you may have heard of the Hershey failure that happened over 20 years ago back in 1999 in that year the company tried to implement sap and they decided to go live right in the middle of Halloween season which is a peak time to be selling chocolate and not at all an ideal time to go live with the new Erp system now part of the transformation involved implementing sap as well as a CRM system called seil which is now owned by Oracle and also a supply chain system called manugistics so it wasn't just sap there were trying to roll out to be fair they were also implementing other solutions to augment sap but at the end of the day the implementation did not go well and they lost over 100 million in Lost sales as a result of the implementation hardly the ROI that most organizations are looking for when they invest in sap or any other sort of Technology as a result of this hundred million hit they took in their sales their stock d dropped by 8% and this implementation is actually often studied and often considered one of the biggest Erp failures in general of all time not just sap failures but Erp failures in general so all of this is enough to land Hershey's at number four on our list of top 10 sap failures in the early 2000s hulet Packard the technology giant tried to implement sap to consolidate its many Erp systems throughout North America and what they found was that this sap implementation was not nearly as easy as they thought and they certainly weren't Expecting The Perfect Storm of problems to hit their project as it did in this case what ended up happening as a result of their botched implementation is that they lost $160 million in law sales and contract backlog as a result of not having the visibility and the processes in the workflows to support that backlog and again that's a very costly hit to an already struggling implementation and when management talked about the failure and what caused the failure what contributed to it they alluded to the fact that it was a perfect storm of events it was wasn't any one thing that went wrong it was a lot of different things that went wrong and that's typically what we see in sap implementations is that it's usually not one thing that causes the failure it's usually a lot of bad decisions a lot of risks that aren't properly mitigated that ultimately lead up to a failure in the longer term so that's one of the lessons from HP is to make sure that you're addressing this perfect storm of stuff which every organization faces during its implementation some more than others but every organization faces a number of risks so you need to be able to navigate that storm admitt at those risks and that's something that HP did not do well and for that reason HP landed at number three on our top 10 list coming in number two is the German retailer Leal and Leal is a supermarket that has over 10,000 locations throughout Germany Europe and North America as well and in 2011 littele tried to start implementing sap or they did start implementing sap but by 2018 they had spent over half a million euros on the implementation and ultimately pulled the plug one of the biggest challenges that leadle faced during the implementation is that they couldn't reconcile the way sap worked with the way they did business and one example they gave was the fact that sap values inventory at the time sap would value inventory based on the cost of the inventory whereas leadle wanted to Value the inventory based on the retail price of the inventory and so that reconciliation wasn't able to happen Leal wasn't able to change their way of operating they weren't able to change sap to fit their way of operating and that created a number of challenges and this is just one example that they cited as why the product failed there was also quite a bit of turnover at the executive ranks and a lot of finger pointing with their consultancy that contributed to the challenges as well so this highly customized environment for a very complex organization trying to deploy a rigid software that couldn't be accommodating to the way Leal needed to operate and the fact that littal couldn't change their business to fit the software created a number of challenges that really snowballed out of control and that's enough to land leadle at number two on our list of top 10 sap failures coming in number one is waste management and waste management is a garbage disposal company based in North America they have dozens of locations billions of dollars in Revenue they try to implement sap over the course of 18 months it didn't go well long story short they tried to implement the product at a number of different locations beginning with pilot location it took them years just to get to that pilot go live and that pilot go live did not go well they pulled the ended up suing sap as a result now there's two sides to every story in this case Waste Management says that they were part of a fraudulent sales scheme on the side of sap whereas sap turned the tables and pointed the finger at Waste Management saying that they didn't make key business decisions and Define requirements in a timely manner and they also didn't provide the right knowledgeable resources to support the project so clearly blame being assessed on both sides but enough to create challenges with the implementation and ultimately Waste Management sued sap for over $1 billion in Damages and from their financial records they they showed that they had realized gains of $77 million as a result of their settlement with sap so the good news is they were able to recover some money the bad news is they spent a lot more money than they were able to recover it disrupted their operations it gave them a black eye in terms of their overall sap implementation and all of that is enough to land waste management and number one on our list of top 10 sap failures of all time there's also a number of failures we did not include here there's companies such as harabo and Shane Company and a bunch of other large high-profile organizations that were not included in our top 10 list but arguably could have been included now the good news is sap failures are not inevitable there are some common patterns you see with these failures and other failures that we haven't talked about here today that you can take some lessons from and ensure that your sap implementation is ultimately more successful first of all you can start with realistic expectations a lot of these organizations that failed began with unrealistic expectations which led to a lot of bad decisions because they never had a realistic time or budget or resource plan and therefore they ended up cutting scope or cutting critical activities such as change management to ensure they were successful next you want to make sure you do your due diligence make sure that if you're implementing sap or any other product for that matter that sap can do what you need it to do don't just assume because it's sap it's going to be able to do everything you could possibly need it to do every Erp system has gaps in in its capabilities and some systems have more significant gaps in their capability so make sure that you do a robust and agnostic assessment of the potential Technologies whether it's sap or any other product thirdly you want to really mitigate the risk of operational disruption when you listen to this top 10 list you heard me talk about a lot of the operational disruption loss sales employee turnover a lot of the impacts that these implementations had in a negative way on the overall operation so make sure that you're mitigating risk that you assess and quantify the cost of those potential risks and that you're planning to not just minimize cost for the implementation but you're considering the cost of operational disruption and finding that right balance to ensure that you're successful and then finally know what you are and what you're not getting with new technology understand what you need to do to augment that technology to make it successful what are the operational improvements you need to make what kind of organizational change strategies will affect it what other thirdparty bolt-ons might you need to fill in some of the gaps or fill in some of the voids that any Erp system like sapb has those are all critical things you can do to avoid failure now that we've covered all this academic stuff we've talked about s4a as a product we've talked about how to plan for your implementation how to execute the implementation how to manage change throughout the implementation we've talked about some of the risks and reasons for implementation failures now let's talk about a case study of a real life example from one of our clients and this is a client that didn't fail in their sap implementation but just like nes4 Honda implementation they had some challenges along the way they successfully work through those challenges and the implementation was ultimately successful so there's a lot we can learn here in terms of what they did well and where they struggled so what I'd like to do in this next module is play you a deep dive interview that I did with the CIO of one of our larger clients that recently implemented s4a so that you can learn some of the takeaways from someone who's actually been through this on the client side of an implementation as well so you've recently been involved in a large transformation of sorts one of the more complex ones I would say uh in the world but maybe just to start out tell a little bit about your company uh what what you guys do how many employees you have that sort of thing yeah sure so we are a compan based in Alco space we make alcohol and beverage products roughly about 5,000 plus employees uh one of the bigger one out there in the market from uh from an Alco perspective uh company's very well positioned for growth and was the case when we started the journey uh however when you think about the process in technology landscape it's fairly was fairly aged no longer the case but when we started the journey right think of it as 15 to 20 year old technology and process landscape uh that was implemented you know when company operated with less than 200 skes right and uh in this day and age we were operating it with uh you know thousands of SKS uh had a very strong ambition to double the size of the company or or grow the revenue uh aggressively uh and it was becoming very clear at the time that the only way to do that is to sell something we don't sell or sell somewhere or to someone that we don't sell right so the company has a very high market share in us so was very was very evident that the growth was going to come through uh you know topics like m&a Global expansions which in which in sense requires tremendous amount of flexibility scale and Agility in your operating model you need to be able to sell things that you don't sell to locations you don't sell into you need to buy anything from anywhere you need to make anything anywhere and sell anything anywhere right and that type of growth trajectory was really hindered uh from speed and cost perspective had we continued to operate on the old technology and process landscape sure okay and was there any sort of Tipping Point that that you reached in your journey there that that you know I'm sure it didn't just happen overnight but was there anything that that triggered you to say hey it's time for us to go revisit our landscape and really build in that agility and update our technology and all the stuff you just mentioned yeah well said right so there were really two tipping points from what I can see right the one was very evident technology was a Tipping Point we used to operate on JD Edwards that was implemented in early 90s still on as400 landscape and uh you know if I I use this a lot in my analogy but that system had two million lines of custom codes that was built over time right it was very customized and it became evident that at one point in time if we needed to switch a hardware we were looking for it on eBay so it was really difficult to maintain not just difficult very high risk to maintain the size of the business on that type of a platform let alone put another layer of ambition to scale and and grow that business right so that was a big factor and as I said the second Factor was just the fact that you know business would go through a transition of co-manufacturing model or a tolling model and people would operate that on pen and paper it will take six to nine months for processing systems to catch up right so we were really in a place where business was moving at a much faster Pace than the whole process in technology landscape can uh keep up with right right yeah it sounds like a a good problem to have as an organization but still still a problem it's an opportunity yeah absolutely right I I say this a lot that uh for us we did this at the time of growth right which is a good time for companies to really look into this we didn't do this at the time of hardship we did this transformation at the time of growth uh and it's kind of like you know some of the East Coast folks will use this phrase right we changed the roof while Sun was shining right so right it's definitely a good time to do that from my perspective I think it's better time to do these types of transformation uh when the business is doing well uh uh than to do that when you know you're in a bit of a hardship from a financial perspective right right couldn't agree more so what about the uh the transformation itself tell us a little bit about the scope of what it is you ended up doing you talked a little bit about where you're at where you started from but what was the uh kind of lead us down the path of how you you started down that path of the of the the transformation yeah so we are very vertically integrated company right uh and that means you know think of it as majority of the product that goes into your finished goods are on grown we also have a fairly strong arm of logistics operations uh so when you look at that us as a vertically integrated company we really attacked all aspect of that vertical integration and the value chain except for sales and marketing so we really went after you know start from from sourcing Finance planning M you know good chunk of manufacturing uh and customer service your ordert taking and Logistics so we really took on now I often say that we replace the backbone of the company we didn't touch anything of sales and marketing uh be IT director consumer type of initiatives be it CRM initiatives we had things running in parallel but we didn't bring that into the scope of this transformation right got it so what what tell us a little bit about the the specific technology you deployed and and sort of how you got to that or arrived at that decision yeah and I think this would be a great uh point for those that are in the market thinking about this right so when we took on this type of a journey there were many in the marketplace from a technology perspective that we can really anchor to right there's not just one company and we we did couple of things so one thing we did really well was we brought in an outside perspective completely technology gastic uh not having married to a specific technology and really use them to help us understand what is the market space like what are some of the pros and cons what are the best suited vendors from a technology perspective that that really matches us from an industry complexity as well as our growth uh ambition and our our natural ambition to do this once for the next two three through three decades right so it was very important that we partner with someone that has strategic trajectory to where we want to be but at the same time has a very good fit to our complexity and our basic needs of today right and we went through a very deep exercise we spent about one year preparing ourself in selecting technology selecting implementation partner and really preparing that internal team be it from the sea level board executive all the way to individual contributor not just identifying them but really shaping them and getting them ready for this transformation uh in the end you know we selected sap uh and with it we also changed our fundamental strategy uh in terms of being you know uh a best of Suite rather than best of breed uh and we selected sap is our technology but we had many others that we looked at we looked at JD edwords we looked at in we looked at Microsoft various right and what was it that led you to sap was was there anything in particular that really stood out or that was particularly well aligned with what you were trying to accomplish with this transformation and just overall as an organization yeah I would say a few things right so first and foremost it's there and this goes back uh about 40 years right so this is the phase where we were in about 40 years ago so 40 years ago there were very very much uh you know very heavily invested in taking their core Erp from EC into S4 space so we saw a lot of strategic alignment to really transform Erp for the future and continuously transform that Erp for the future in that space uh so again we saw sap as a company that has a high investment from an R&D and from a product perspective for continuous Evolution we also saw them as more Centric when it comes to product portfolio was a company that had less product than Oracle when it comes to Erp so we found bit more Focus uh as a company outside of the Strategic pillar I would say scale played a big role so given that we are very vertically integrated and we have a high G growth potential right and Ambitions the scale played a big role in terms of uh selecting someone that has proven to be operating in very diverse marketplace right I joke around and say sap is used to build Rockets and tissue paper right so go find your space in between right uh so we found that diversity to be very appealing right and the last but not least we've we've had a tremendous work done leading up to this transformation in the identifying you know how to connect that vertically integrated company from a process perspective so we really have a different process when you're blending the product versus when you're making the product uh versus when you're sourcing some of the raw material and we found that was it was possible to lift that type of a process work we did into the technology that sap was bringing to the table and what about the some of the complexities of being a beverage manufacturer was there anything uh along those lines that you know you're a high volume um beverage manufacturer a lot of different brands you mentioned Acquisitions you've grown through so I imagine you had some maybe some disparity in terms of how the operations worked was there anything that that really stood out or or that was sort of a either a sticking point in your evaluation of potential options or LED you to sap yeah for for sure right so when I think about the agility with acquisition that was a big component how quickly can we integrate the acquired company and its processes uh so we found that agility to be available with components like Central finances and and whatnot and sap though we are a company that really operates with a philosophy of integrating first rather than acquiring and then you know lifting and shifting and keeping them on as it is so we found that to be fairly uh a strong component from appeal perspective and then I think the most important though it's not true today after two years we've learned a lot more but at the time uh we were very confident that the the blend management component of our industry and our business was very well represented there is a a system out there that does this and we found that sap had the the basic principle to create that type of uh process manufacturing component using that their tool sets right yeah we actually had a another client a couple years ago that made a comment that they're in a similar situation in that they were growing very aggressively through acquisition and I remember them saying which it was the first time I had heard this or heard a client say this was that at the of the Acquisitions they did some of them were using sap and some of them weren't but the ones that were using sap actually were more flexible and they felt like they had more flexibility to change their operations than the ones that weren't using sap and a lot of times sap has this uh people have a perception of it being extremely rigid and hard to change and that sort of thing so it's it's interesting to hear that sounds like that may have been a similar experience for you in that you you got that agility you got the flexibility you were looking for uh with the product yeah and it's it's a double Ed sword right uh so from a if you look through the lens of the sea level if you look through the lens of the business as a whole right it it is definitely a platform that opens up doors for flexibility when it comes to operating model change when it comes to integration of m& right you can stand up a company very fast from an integration perspective you can stand up a new operating model fairly quickly uh and we are one of of those company that probably had every every variation of operating model you can imagine right when it comes to tolling or co- manufacturing and things like that and we found that to be very uh very easy to configure and operate in at the same time you know it's not something you can deploy overnight or deploy you know over over a week right it is a system that has know if I want to add a new plant or if I want to add a new manufacturing location it's not a click of a button that uh that drives that type of speed right so like I said it's a double it swore you definitely get the flexibility of operating model agility of integration but the people that have to actually do the work uh they do spend time right it takes weeks to configure the system such that it operates right for you right so if you had to summarize uh in this I'll ask you sort of a summary question and then we'll take a break and I'll come back and ask you more deta detail around this but just at a summary level how would you how would you summarize the the results of your transformation I mean how did it how did it impact your business uh you know where are you at today yeah I do it in two ways right if I compare us to the industry I think uh from a just the execution of transformation and what we accomplished I would put us in the top 5% right we were you know you often hear majority of the erps and transformation fail so I'm happy to say that we were in the top 5% of the success from that perspective when I look back and look at the business goals that we had in mind we've definitely hit the macro gos which was reposition the company to scale make it easy to scale make it easy to operate globally all of that we've hit we had a big Miss in my opinion in two areas right one is user experience right we went in with a very strong ambition especially with things like theor and the innovations that sap had lined up uh to really Elevate that user experience to be more modern mobile type user experience uh and I think we've missed the mark on that and it has large to largely to do with the way the product is maturing and evolving and then we've missed the mark in certain area of our of our business case right so we expected tremendous amount of efficiency in in areas like sourcing uh and we've not achieved that yet and again has to do a lot with the way that the maturity of the tools are and as well as in planning right so those two areas were behind we haven't fully gotten there uh but outside of that like I said if you look at a macro picture achieved the projects in time well under budget really good success from go life perspective overall companies being able to scale fairly aggressively post go life as well the two shortcomings you had in this project on one hand you said it was top 5% went really well overall but two things you could out better were the user experience and and the business case or the benefits realization within that business case but if we back up even more and look at the actual Journey itself not so much the end state but just how you got there what were some of the the biggest challenges you face what were some of the road B uh Road Road Blocks or pitfalls along the way yeah I would say you know as any transformation would face this uh uh you know for us the the number one challenge at the start was to unify and unite the company right I think it's utmost important and one of my early coaches used to say aligning your sponsors and then setting the right ex expectations not just at the top but across the company is very important and uh for us that uniting that voice in the company was perhaps the number one challenge we faced in the beginning uh after that just like any transformation you know we Face challenges for uh from various aspect right so one is you you know when you get into these types of transformation you're working with multiple vendors be your software providers be your Implement implementation partner the next challenge was really to make sure that you keep them in sync uh and you create a a culture of one team where all of them are working for your benefit and and not pointing out individuals uh you know risks or flaws so that was a second challenge I would say we faced and a third which I kind of talked about in my results was just the the Gap right throughout the journey you're going to learn things that you didn't know and you're going to find things that you didn't expect right so we definitely found plenty of those gaps where our expectations were not meeting and adjusting to those gaps and continuously keeping your you know company your Executives uh and your teams aligned was probably my third biggest challenge that we faced so let's go to that alignment concept you know with your Executives your stakeholders but also your your software vendor and the system integrator how did you how did you achieve that alignment what did you do to overcome that yeah so I'll speak in both aspects right so when you think about unifying the company uh for me it's very important that you have a strong why right uh people need to know why you're doing it and there has to be a very strong uh you know alignment on that why right so we spent quite a lot of time in shaping why are we doing this in making sure that every executive that was lined up to this type of transformation understood why we're doing it and we were getting you know what they expected out of that transformation Vision right so we spent tremendous amount of time aligning that and I was very fortunate uh uh to have a CFO at the time who was a very strong sponsor and I would uh I would really advise people that are out there to look for such executive sponsorship our CFO really took this upon himself in so many ways right and really didn't just you know sponsor the project from distance but really sponsored the project by being in the weeds and being with us uh as we were shaping that so that played a big role the company also made some very interesting changes where it unified the leadership under one responsible uh for the step of transformation right so that was also important uh that that the executives were reporting under one sponsor right so that was very important the owners of the company took a very active interest in making sure that world all L were aligned on why so to me that played a big role and as I mentioned in the beginning having a a softw and Si agnostic party that helped us bring you know that brought us together at a Next Level uh was very important so for me that's that goes a long way I think that sets you up for 70 80% of your success right uh the second aspect we were really strategic you know you would be surprised how much leverage you have over your si and over your software company when you're buying and when you're in your negotiation phase so we were very strategic to request very high Executives from each of those companies to be part of our steering committee right so we went as far as asking for board level members to be in our steering committee and we were successful and that opens up doors for driving that strong partnership between various parties that are engaged and involved and the last piece which is very important for me was you know we never treated this transformation as something that a partner is going to execute on our behalf we had a very clear Mantra that we are accountable for it and we lived it in a day-to-day basis right so anytime we suspected a risk or we suspected an issue we would really take an active approach to work that through multiple parties that were involved bring them to the table all at once and really treat it as this is a company problem and we all need you to you know roll up your sleeves and solve it for us right you know you're hitting on a a couple really interesting points that uh I think a lot of companies miss a lot of organizations Miss during these Transformations I think a lot of times companies make two faulty assumptions one is that my system integrator is going to leave need this for me and I'm going to Outsource this project to them and the other is that you know this is a a project management sort of uh a project team sort of project that needs to be executed at the project Team level without thinking about what what do we need from our executive team up top you know what what sort of top down sort of Direction and and uh alignment and un unification as you call it um what what is it we need from them and I think a lot of organizations are almost afraid to do that because being a top down command and control type ofan company isn't you know isn't what people necessarily want day-to-day but you sort of need that even though the the trendy thing is to be more of a flat organization and more you know collaborative and you can still maintain that but but still having that clear Direction at the executive level uh is very important so I think those are both really good points yeah and I would say you know you you hit a key point it's involvement and ownership at that level is equally important as well right we are we were really fortunate where we have a culture of inclusivity I mean I've had you know c-level Executives sit in a process uh uh I wouldn't say process design but process uh you know process uh overview session right and they would ask for it they would ask to say hey show us how the new order to cach process is going to be different and it's important for executives to have that level of passion engagement in these types of program as well and have to I often joke around and say you have to bring the gods down to the Earth if you want this to be successful uh whatever works for you whether it's monthly weekly but they have to stay engaged and at least take full interest both from uh you know both from how the future is shaping as well as how people and morale of the people is doing right that's that's great that's great advice sounds like you've had some good some good mentors and help along the way too absolutely it was a great team yeah so so um what about uh organizational change management when you think about the changes and the impact that this transformation had on the business what what sort of challenges did you face along those lines and how did you how did you address them yeah again I would say uh you know it's an of it's often an area that's underestimated or under overlooked right uh I would again say a lot to do with just the the fact that I mentioned you know we we had sponsorship that really recognized the the challenges that come with Erp and business transformation and from the very beginning we were you know we were very clear that this needs to play a good and important role and to many people's surpris you know my counterpart typically the erps are set up where you will have a you know a program director from ID and a program director from business and then you'll create a two in the Box concept we from day one structured where my counterpart was from HR uh the individual had a lot of experience in operational excellence and also manufacturing space prior but was very keen on creating the right culture for the program driving the organizational change management of the program so we we you know we put money where our mouth is and we created that two inthe boox leadership with someone that came from HR and had a tremendous amount of manufacturing transformation experience but had a huge focus on making sure that we create the right team we create the right culture and we keep this from communication training perspective and Forefront of the organization so that played a big role we also were very strategic in hiring an ocm leader you know we were lucky to hire someone that had 13 Erp under their 12 Erp under their belt uh so that played a big role right and we were very clear that change management is is is in my opinion equally important as any other tenant of that program uh so that played a big role after that right we we simply followed What uh you know what many methodologies exist out there in the marketplace but we followed a very strong change management methodology you know we were uh like you mentioned we were in front of every executive you can imagine in the company whether you were part of the program or not at least once a month once a quarter keeping them appraise on what's happening what's not happening we operated with a very strong culture of transparency uh you know we used to say early good early bad news is a good news uh and we would you know post all of our progress good bad or ugly on on all of our walls made it very transparent both inside that epicenter where the program was operating and outside in terms of how things were going right so those were I think the key tenants for what made our ocm successful in the program right that's great and and you're right a lot of organizations do Overlook that but it sounds like you had a a clear strategy you tool set methodology and support to to address that yeah and this is another good area of ownership right we encountered uh fairly strong challenges early on our SI methodology for change management their approach and and the way they were integrating their change management with the culture of our company was not very well aligned right and very early on in the program we made an active decision to say we will own it and the partner that I had was so strong right we were able to say look we will own that change management with the Staffing that we have the philosophy we have we have in a company and the leadership we have and we took that in house and we ran that ourselves so again very important to have a good strategy good people that can really back up that strategy from an execution perspective is sound method methodology in a clear focus on every day every hour of your program right now what about the overall uh implementation time in budget how did that compare to the actual implementation results as far as on time you know were you on time on budget or did you have any sort of discrepancy or adjustments you had to make along the way yeah on a on a big picture you know we hit our targets we used to and this is also an important factor in your success I would advise every company out there to reevaluate your incentive structure and make it specific for this program right so we did that you know we went through a complete change of how the people every single person in the program from top to bottom are incentivized uh and you know in summary we we deliver you know above Target both from time and budget perspective uh from a program point of view yes we were on time and on budget but as Executives we knew that these programs don't go on time and on budget so we had at least given some latitude for our people to hit their target right so we were on time we were on budget we executed this top to bottom in 18 months uh you know I can't share the number but sure it was very expensive program just like any other company would encounter uh but overall in time in budget our business case it took us about a year to realize and like I mentioned in all areas except for I would say sourcing we're realizing our business skills right so it sounds like you you you did despite the pitfalls and the challenges and things you had to work through just like any transformation it sounds like you guys ended up in in a good spot um you had said that uh you you feel like this project was in the top 5% of of projects out there if if I'm a CIO or a project manager an executive or business owner that's about to go through a similar transformation what what sort of parting words of advice would you give to them to to help them achieve that same goal of being not being a failure not being an underwhelming success but more of a you know one of the top performing Transformations what what's the advice you would give yeah I would summarize some of the points that we discussed early right spend your time preparing yourself planning yourself well it pays off right jumping in it too fast is not the right way to do it so spend your time planning and it's really about aligning your executives making sure you're going with a realistic business case right benchmarking yourself with an outside world is not my VI but know what's possible of course Benchmark to know what what is uh what is out there but know your own success right so Define your own success align your executive uh prepare prepare prepare in terms of you know making sure you have done your due diligence from the products that you're going to select uh from an expectations that you're aligning and then most important right invest in your people make sure you line up the best talent the right Talent uh and then last thing I would say is be ready for surprises right there's not a day in this transformation that that will not give you a new surprise and be ready for that level of flexibility agility create a culture for your team uh that can you know go through that type of uh challenges and surprises right founded on teamwork commitment transparency see it's very important to create that type of culture the last thing I would leave for the people that are looking into doing this is if you are in that leadership role of that transformation whether you are a sponsor whether you are a director executing it create proximity to your team and to this project right uh uh it's important to know people that are working on it work that people are doing on a day-to-day basis I think that goes a long way to stay close to that project at all levels that's well put and that's it's really sound advice especially because so much of what you're suggesting and recommending is focused on people you know people culture you haven't talked a lot about the technology itself which I think is is interesting and fascinating and I and I agree with by the way you're focused on the right things and that's probably why you were one of the the rare breeds of of successful Transformations out there yeah Eric I I you know I've heard this so many times and even though we've had some pitfalls I it's proven again the tech technology is the least of your complexity in this Transformations right uh you you have so many other facets that uh that are much more complex than technology in our case uh you you you kind of said it well right or in our case if I look back my biggest challenges were technology because we did the other things so well right and when I look at that Challenge from a technology perspective it was really around setting our expectations right right we we know we had an product from sap and we internally marketed that as an Amazon like experience it is not Amazon like experience it is different so it's important to you know calibrate what you're going to get and align your expectations and then we were also very early adapter of some of the emerging technology like ibp of sap we expected a lot more out of it than what we what we should have right so that's also important to make sure that you assess that well after that the implementation to me is is is not the real Challenge from a technology perspective so this training course has provided you some understanding at a deeper level of understanding of S4 Hana as a product what it takes to make an implementation successful what some of the risks and failure points are as well as case studies that will help you become more successful in your S4 Hana implementation for more information and best practices to learn more and to go deeper into s4a training I encourage you to read our guide to s4a implementations this is a deep dive paper that we publish that talks about some of the best practices and lessons that we've learned from our clients including some of the things we've talked about here today but there's additional content in there that I think you'll find very helpful so be sure to download that you can do that via the QR code in front of you I also encourage you to subscribe to our new podcast series called journey to S4 Hana this is a podcast that has different guests and case studies every week that talks about some of the things that make s4a implementation successful and that's something you can follow along as we put out new episodes and continue to sharpen your knowledge of s4a implementation so be sure to check that out at Journey tos4 h.com so I hope you found this training course useful and I hope you have a great day