Jean-Yves Q/A Lightning Round Part 2

Gene: Another observation I’ve had when talking to other employees of D4M is that for an SAP rollout to be a success is to have proper communication – not only with your team, but between departments of an organization – such as business departments, legal, IT, etc. A few weeks ago, I interviewed Eric and one of the observations that he made was to make sure that you are articulating three things to the business team; one, that you are not going to undermine everyday operations; two, to stay as close to the plan as possible; and three, make the goals clear. Does this seem right to you? Anything that you would like to add to that comment?

JY: Oh, absolutely. I totally agree with the statement and I would even say this is an understatement because when you go to such a transition – bringing a new ERP or an upgrade to S4HANA for example – I think It’s fundamental that at all level of people in an organization truly understand what you’re trying to do.

JY: So, to begin, you must start asking crucial questions regarding the rollout: what is the objective? What is the timeline? What is what do you expect from your key user or your power user? And so on. And you’re talking about projects that sometime could have 20 to 30 team members across multiple departments; hell, sometime hundreds of people involved. So, it’s very easy to lose track of who’s doing what, why you’re completing certain tasks and so on.

JY: So, I think communication is extremely important. And even more when you refer to the business itself, because they will be going through some transition at the plant or distribution center or whoever else is impacted by the change with the rollout.

JY: So, all these various groups will feel the impact. But, the IT and operations teams will be the ones living with the new system on a daily basis and the business department are the ones initiating and funding the change. So, they need to be part of it. They need to understand why you’re doing certain things a certain way. And in some cases, the IT or business team might have been doing a function or a task the same way for the last 10 years and believing that this is the best way to do.

JY: But, at the end of the day, the task might have a different or a better way to do it. So, I think it has to be properly communicated; it has to be well explained by the IT side, and for the business side to accept the change. It’s all a matter of accepting the change. If people that you work with reject the change, it will be very hard when the day you go alive with a new system.

JY: If people just resist change, they’ll be frustrated, they won’t like the new system, or they just won’t understand why you’re asking them to work differently. So, it all comes down to good communication. It’s the timeline. It’s what you expect from the person in charge of the data migration, what you expect from the accountant as far as putting together changes in the chart of account, and so on.

JY: I think it’s absolutely right. Communication is a very important aspect of a successful project.

Gene: Okay. Let’s continue our lightning round here. So another piece of advise brought up by Eric gave me is to never undermine the GM. Not only will this backfire in the long run, but they understand more about the legislative process than you do any observations.

JY: I agree. When working with other companies, you are one of several third parties working for the client. Though you can generally go into a project with general expectations – legislation, business, etc – there are far too many specific factors that you neither understand or will be allowed to deal with during a project. So, as part of any ERP project there will obviously be many parties involved.

JY: To give you just a few examples, in some industries that you work through an EDI – process by which you communicate with your supplier or your provider or your distribution center and so on – for order processing, for example, but it could also be material shipping and receiving and all that.

JY: So, the EDI portion involves other parties. So there will be an EDI provider, potentially there will be the clients, your clients that you work using an EDI process. As you go through the process, they are an outside entity that you need to take into account in your planning.

JY: Once again, it points to having a good planning upfront where you can identify the stakeholders as well as any third party involved. I just gave you the EDI example. I could bring another one with your companies chosen banks. You might be changing the way you process payments through SAP; you may have to get involved with your bank provider to make sure that the payment transaction to pay your bills or to collect money from your clients it might be impacted.

JY: Then you may have to retest or you may have to, you will have to talk to your bank and coordinate some changes possibly. So these are third party. That obviously we need to take into account and not even counting on top of it the, what we would call the country specific. You could always have specific countries as specific rules.

JY: If you take Mexico and Latin America, they have a certain way to work for taxation. That are mandatory. So as you go through those projects you need to take into account the local country specific practice, whatever, if it’s legal or lo the local way to do business. So these are, again, involve will involve third party that you need, you will have to factor in your project.

JY: So, again, as a third party, there are too many factors when rolling out a plant to be on bad terms with the GM.

Gene: Okay. And the last bit of wisdom I want you to comment on with regards to the Eric interview is that “when you do an ERP rollout, you have templates for a reason, make this process as predictable as possible.” And this goes for SAP rollouts or any business implementation.

Gene: Come to think of it, this very much feels like it’s the mantra of D4M as a whole. What are your thoughts on cementing and sticking to a plan/formula in the ERP rollout process?

JY: This is 100% correct – and, it’s for simple reason; the “cookie cutter” model is so fundamental is because if you’re going to roll out SAP in dozens and dozens of location, It’s not only easy to do, it is necessary to complete such an intricate project.

JY: It is highly critical for efficiency, clarity, and execution. meaning, if you  come out with a very highly systematic approach where, for example, a rollout will take 26 weeks. As a matter of fact, it could go as far as having a plan that will clearly state over the course of 26 weeks breaking down every week in detail.

JY: It might sound extreme, but it’s extremely powerful in a sense that if you expect, for example, that your accounting department will step in, to clear data, migrate data for your financial records or your chart of account, and if you have it very well laid out that you are going need their involvement at week 16, it could save you a lot of headaches down the road.

JY: Having a systematic approach also helps you with projects in general. It’s almost like a military operation. It’s done in a military fashion, meaning if we took the cookie cutter approach and we lay it out on 26 weeks, everybody knows precisely what needs to happen. Week one, week two, all the week to week 26.

JY: Again, it may sound extreme, but, the flip side to this is it is extremely powerful and people not only know what to expect, but what we expect from them. It’s also very easy at the end of every week to measure progress is this is what we were supposed to do this week, was it done or it’s not done. So, it’s overall easier to make your processes systematic.

JY: It’s not only better organized, it’s simply easier to execute from location to location because you just reuse the approach time and time again as you go from project to project.