I recently discussed the critical success factors of Source to Pay implementations with Thierry Jaffry on episode #2 of the Pure Procurement Podcast. Thierry is Vice-President for the North-American market and Global Chief Marketing Officer (CMO) of Fluxym, a global leader in Source to Pay consulting services.
During the episode, Thierry and I discussed the top 10 critical success factors to consider before starting your S2P software implementation. Here they are in the order we discussed them.
- System selection
- Choice of partner
- Clear project objectives
- Team selection
- Deployment plan
- Supplier Enablement (SE)
- Data quality
- System customization
- Change management
- Governance
This post is the transcript of the episode. If you prefer listening to audio, you can listen to the episode on the podcast page.
—————————-
*The transcript from this interview has been edited for brevity and clarity.
Introduction
J: Thanks for joining me Thierry . I Appreciate it.
T: Thanks a lot, Joël. It’s a pleasure to share this session with you.
J: Absolutely. So, for our audience out there I thought it would be interesting to discuss the critical success factors of Source to Pay implementations. I know you’re seeing a lot of organizations who are going through [these types of implementations] or have just gone through them and are trying to figure out lessons learned to see how they could approach their next deployments in a better fashion. [With that in mind], I thought it would be interesting to get your thoughts on S2P implementation critical success factors and how people that are embarking on this Source to Pay journey can do so in the best way possible. With that being said, I prepared a list of factors I see as being important and thought we could go from there.
Critical Success Factor #1 – System Selection
J: The first one is system selection. How important is fit with your back-end and making sure you’re choosing the right tool? There’s a whole swath of out tools out there whether it be SAP Ariba, Ivalua, Coupa, or the other leading brands, or even a smaller pure play / newer solution. There are cloud models, on-premise models, etc. What are your thoughts on choosing the solution? Are they all the same or are there big differences between the providers today?
T: That’s a really good question. I would say that the fit with the backend system is no longer an issue. I think when you select one of the top providers that you mentioned like Ariba, Coupa, Ivalua, Basware, Zycus, etc., they’ve all got integration points that are easy to plug with the main ERPs that you have on the market right now (SAP, Oracle, JDE, Peoplesoft). We’ve seen that it’s pretty easy to integrate them. If you have an exotic ERP system, and I’ve seen that on a couple of projects, then you should probably have a deeper look at the integration capability of the solution. However, if you are using one of the major ERPs, all of the leading market solutions will fit with your backend systems.
J: So, when you say exotic, you mean more a niche system?
T: Yeah, nice systems for some specific verticals like manufacturing or mining where you can have more specific ERPs. Definitely, there might be issues here for [out of the box] connectivity so you want to look for the more flexible capabilities in terms of integration toolboxes.
And on the functionality side, when considering system selection today, I feel like all the market leaders are strong for sure. They wouldn’t be there if they weren’t. There are a lot of sources of information now on the web now that you can use like the Gartner Magic Quadrant, Forrester Wave, the Solution Map from Spend Matters as well [to evaluate functionality]. So, I would definitely advise not to waste time on consulting +/- 20 vendors on the market, doing and RFI and an RFP with everybody. Just focus on the ones that are the strongest on the part of the Source to Pay process that you want to cover.
But, also think about the next step in terms of deployment of the solution. You may want to start with a [Procure to Pay module implementation] to automate the transactional part but afterward you will have appetite for contract management and then spend analytics so considering your end-to-end solution should be a criteria for selection.
J: Okay – And from a functionality perspective, do you feel all vendors have the same velocity when you consider product roadmaps and things that are, to me, still in proof of concept mode like integrating artificial intelligence or Robotic Process Automation (RPA) into procurement processes?
T: From what I’ve seen today, everybody is just now at the turning point. Everyone is trying to find where artificial intelligence could bring real value – not just be a buzzword on their product roadmap slides – but bringing real value for the buyers. [All vendors are exploring concepts such as] guided buying, virtual assistants, predictive analytics but I don’t feel there is one solution that is really ahead of the others today when it comes to the use of these emerging technologies. However, there are definitely some niche players that could be add-ons to those big Source to Pay systems but I really feel we are at the beginning of a new era for these solutions.
And just to finish on this point, I think one of the important things to look at when doing solution selection is the flexibility you want to have in your solution. [Depending on] if you want an out-of-the-box solution that comes with best practices embedded or you want something very flexible that you can tailor because you have a lot of exceptions in your processes, that could be a big difference between the providers I know of.
J: But that means you believe those exceptions are “value-add” to your business, right? Because you could also say: “We’re taking out all those exceptions”.
T: I would love that (laughs). That’s always the discussion we have with clients at the very beginning of the project. “We want out-of-the-box. We want best practices. We won’t manage exceptions.” However, then you go into the design sessions and you realize that the exceptions, in real life, are sometimes more important than expected.
J: Yeah, and more difficult to get rid of [than you expected].
T: Yeah.
Critical Success Factor #2 – Choice of Partner
J: Alright. That leads me to the next success factor [on my list] which is the choice of partner. We just mentioned starting a project with clients. Different consulting firms will have different approaches to projects. How would you suggest going about the selection of a partner [for implementation]? Is it even important at all? Could I implement these solutions without a partner?
T: So, the first thing is that the best choice would be to select Fluxym as a partner. (laughs)
J: (laughs) Ok fair enough…
T: No but the selection of the partner is critical for sure. You must select a partner that is able to be a bridge between the business and the solution – the business requirements and the capabilities of the solution. On the market you can find many different kinds of system integrators; you can find the pure, technical implementation partners who can do deep configuration, integration, interfaces with your back-end and everything, but also the business consulting side of things, and both shouldn’t be disconnected. It should actually be the same partner doing both, just to avoid…
J: “games”?
T: Yeah, let’s call it games and politics.
J: And complexity, right? Added complexity, added management…
T: Exactly, so having someone who can really extract the requirement from the business, transform it into a solution first, and then transform that solution into a configuration is really the key for me. Each client should really look carefully at the system integrators to identify those that have the full set of skills for complete implementation, and that includes also all the professional services around technical integration like change management, deployment of strategy and training.
J: Should people consider going ahead and implementing this in-house, directly with the software vendor?
T: I’ve seen that a couple of times. The thing is, it’s probably the first and the last time in their life that they will implement a source to pay system. Or maybe they will do it twice, right? But we, the systems integrators, we’ve done that a thousand times. We know exactly the pitfalls, we know exactly where to go, where not to go, how to drive the project, faster and with more efficiency. So, definitely, it will be more cost effective to use an external system integrator than to do it entirely with a software provider. If you look at the market right now, software providers are getting rid of their professional services. They’re focusing on partner channels to implement, because they want to focus on the principal source of revenue, which is their SaaS [Software as a Service] fees. I would definitely recommend to use a certified service integrator and not to do it internally.
J: I ask the question because I wanted your opinion, but I’m completely on the same page for that. Just because of the conversation we’re having today on critical success factors and of different things that we’ve seen in the past. I’ve often heard that an expert is someone who’s made all the mistakes you can make in a narrow field. Gaining that experience and that velocity because you’re working with someone whose core business is implementing these systems is probably for the best way to go. Especially if you want to go in eyes wide open with regards to what it will actually cost you because otherwise, it could be very different than what you had initially planned.
T: And you cannot discover the solution while you are implementing it. You cannot just try some configuration and realize that there is an impact on another module that you are currently deploying as well. You need to have all this architecture in mind. A client can’t learn that in 3 months or even 6 months. You need an expert behind you that can do that knowledge transfer with you. What we like to do, as a system integrator, is to make the client completely autonomous at the end of the project and then give him all the knowledge that he needs to be completely autonomous on the configuration, upgrades, and the full life cycle of the product. However, the implementation project is too critical and too costly to be done internally, I think.
J: Fair enough.
Critical Success Factor #3 – Clear Project Objectives
J: That leads us to our next point which is clear project objectives. I think we touched on that a little bit, but how important is this point for you? Who should be aware of those objectives going in to make sure that you have a successful project?
T: I think that everybody agrees on the importance of that, but nobody does it, really. Because when you define an objective, it means that you also define the KPIs to measure the success. I don’t know any of the last 15 clients that we’ve deployed that has clearly defined the KPIs to measure the success of the project at the end of the implementation to say “OK, this is exactly our business case, this is the objective we want to reach, and this is how we will measure it at the end to define if it’s a success or not.” So, I definitely think this is underestimated, because usually people have the objective of deploying the solution, right?
J: Yeah.
T: “OK, we have a project, we want to deploy that solution, it’s like, (claps hands) congratulations.” But there’s a returning investment that’s expected and sometimes, there is a kind of a disappointment a couple of months, or years after the go-live because clients feel they don’t have the full power that they expected from that solution. Perhaps, because they didn’t define what they were expecting at the very beginning. Sometimes, that takes another mini project or other adjustments like “Let’s do it this way,” to finally get the full ROI of the implementation of such a solution.
About the scope, I would say – and that will come to another thing that you mentioned in your agenda about the business process definition – but usually, one of the major issues that I see in the preparation of a S2P project is that people try to replicate the paper processes that they have in the future solution. There’s a major step in between that: to define the target processes before even starting the implementation project. And even if you don’t know the solution you’re going to select, you should have defined your target processes, even if you need to fine tune them once you know the capabilities of a solution that you’ve selected. But, most definitely, trying to do exactly what you do today in an automated solution won’t get you the results you expect.
J: It’s funny you touch on both processes and the objectives. I find the focus will be on those two things during an implementation with a partner, but as soon as we go live, everybody acts like: “the project’s done! Let’s pack up our bags and go!” But in reality, that’s the first day, the real first day of your project. Even if it’s been really hard to get to that first day… That’s when you start measuring those KPIs from a process perspective. Even though you might have KPIs and objectives for the project like the cost and whatnot. But if you have cost overruns or it costs you less to do the project, what is the project payback time? How are we operationalizing the monitoring of the success of that solution in our strategy?
T: Yeah, and that comes back to a conversation that we had offline. Some solutions today could be complementary to such an implementation like Celonis or Signavio. These solutions allow you to really have a clear vision of your process execution in real life with the solution you have implemented. Sometimes, you have big surprises when you see all the exceptions for cases that you never planned during your implementation process. Maybe you focused a lot of energy and time on things that are not really happening in real life. These tools give you really good feedback on how you drove project.
Critical Success Factor #4 – Team Selection
J: I think that leads us to a really good point that we also discussed offline – and it’s not on my list but I’ll bring it up now since we’re touching on it – which is team selection, selecting the members of your project team. If you don’t have those right members, then that’s exactly what you’ll be doing… You’ll be creating a little bubble where your project team has defined a reality of what they think goes on in the business. This is how you define your processes in the new tool and it may very well work 100%. However, when the system hits the road on day 1 of your go-live and maintenance technicians start using the system, you will definitely have scenarios that come out of left field if you didn’t have any maintenance technicians consulted in the design of the tool.
T: I’ve seen everything related to this point in projects that we’ve deployed. I’ve seen IT-lead projects –I think that’s a common mistake. This is not an IT project, this is a business transformation project and should be led by the business. The project team is mostly composed of business stakeholders that should represent all the different processes, organization and business units that you have in your organization. That really can be different if you’re talking to a very decentralized organization we worked recently with a real-estate company, which was really decentralized. Each property has its own support functions, management and everything. So that means they also have their own procurement for things like janitors, or services, or snow removal…
J: And office supplies, probably.
T: And office supplies… So when you’re implementing a source to pay solution for that kind of company, that means you need to have a lot of representatives from the property management on the field that should be involved, because everybody has good ideas to share with the others. But that will also lead to some change management for the others. Also, if procurement is centralized, building a team gets much easier.
But I had the issue recently, I can tell you a story about it. [There was a] project that we designed with the whole procurement team and everybody was aligned on the project. But, when we came to the UAT phase, some folks from another country were brought and they realized their contract management process was completely different from what we had designed. However, we’re at the UAT phase, so no time to reopen the design doc, right? We need to move forward, but these people were left on the side, so what should we do now? Selecting the right people as part of the design sessions is the key. As you mentioned, having the right technical skills all around the table for the integration part is also very important.
J: And I’d be curious to hear if you’ve had any experience – and I know it’s kinda going off track – in a decentralized context, with a big business where you might have 20, 30, 100 different business units that have variations in their process for very good reasons, what kind of approach can I take with that mass of people to come to a standardized process without using a traditional business design where I have those 100 people sitting in a room? Because then you’re not getting anything done, right?
T: So, in that case, and we did that actually for a client in the past, you first need a preparation phase before the design session. You take your backpack, go see people internally – this is the role of a business analyst – for all the different business units. You need and sit with them. Talk to them, interview them and collect their actual requirements, processes, their pain points and do an analysis to propose a common approach that will be discussed during the design session. That could probably satisfy 80% of the requirements that they have on the field. There is preparation work to do to centralize requirements, to listen to the people on the field, because they actually have the right vision of what is happening in procurement. You should definitely start by listening to them and collecting that, because I’ve seen some people doing that the other way.
J: Fit to standard type design?
T: Yeah, “we’re going to select a solution; we could impose centralized process through that solution and people will have to enforce that,” and that doesn’t work.
J: I find that can only work if there are 0 tasks that are value-add for that industry, for that specific business unit or geography that are being executed in that process, right? But that’s never the case.
T: No, never. So in that case, what you get at the very end is that the adoption rate for the solution is very low, and you don’t get the benefits you were expecting because nobody uses it. Or they use it in a way you don’t want them to use it.
Critical Success Factor #5 – Deployment Plan
J: OK, cool. The next point we had, critical success factor, is taking a look at the deployment plan. How we approach the roll out of the solution? To name a few different approaches – not all of which I agree with but – Big Bang versus having parallel systems in place for folks, doing a pilot with a scaled deployments… What are your thoughts on deployment planning when it comes to source to pay solutions, of course?
T: First of all, [the] deployment plan shouldn’t be discussed during the implementation. It should be discussed before the implementation. This also conditions who you’re going to have around the table during the design phases, who’s going to be part of the UAT, and some of the strategic decisions you’re going to take during the project will be defined by your deployment strategy. That’s part of the preparation work that you have to do before even the kickoff of the implementation project.
In terms of deployment strategy, I’m not a big fan of Big Bangs, and I’m not a fan at all of parallel implementation for sure. The pilot implementation is usually the one that works the best, because it really allows you to do a great crawl, walk, run deployment strategy. Start small, with quick wins. Let’s implement, for example, the sourcing module for indirect procurement. That’s pretty easy, it’s a small group of people that could fit in any company, start with sourcing for indirect procurement and then deploy it sequentially will all other categories, then implement contracts – use [the] legal department for that, involve them in the project.
Don’t try to cover all your processes at once, because the chunk is going to be too big. Don’t forget that the teams also have their daily job, they’re not a 100% dedicated to the project, so the implementation would be a lot smoother if you go by phases using your pilot; fine tuning it, then deploying [it] on a larger base and so on.
J: I completely agree with you. The analogy I often use is the snowball versus a big rock. If I [make] a snowball – which is my small pilot – and then I gain steam and it gains weight, it’s going to be bigger and heavier than my big rock quite quickly, although it might not seem that way at the start. Whereas if I have a huge boulder that I need to push, then I’m going to need a lot more effort to do it upfront. It’s not going to carry its own weight, and it might not even get bigger, to your change management concerns at the end, because I’m going to have put in so much effort and I might not have the right requirements.
T: And by doing that, you can also identify champions in the organization that are more likely to adopt the solution quickly and then to spread the word toward the others who can be more reluctant at the very beginning for the adoption of certain solutions. You deployment strategy is definitely a big part of your change management strategy as well.
J: So how do you see that working – and I’m kind of going off on a tangent here as well – in a business climate, which I perceive to be a prisoner’s dilemma among consulting firms? For example, I have a big client that puts out an RFP for an S2P solution and he’s looking for the lowest cost bidder. Many times, that comes with having a deployment plan where I’m doing things [faster] and I’m not necessarily burning steps, but I’m trying to get to the end of my deployment for 100% of the scope in the quickest way possible. Is it just the [responsibility of] clients to be smarter in how they approach the market? Because I feel like it’s a race to the bottom sometimes, right [in terms of quality]?
T: Yeah, but usually the price constraint you mention in the early steps of a project is a budget constraint. They have a budget they can invest in the deployment of the solution, they have the implementation fees plus the SaaS fees. It can sometimes be a huge investment for some organizations. That’s procurement, and it’s still a problem since the beginning of times… Procurement is not Sales in organizations. Even if procurement is not a cost center and now we can imagine that procurement has become a profit center for innovation – [by] increasing margins and everything – but it’s still procurement.
J: Yeah, much like IT right?
T: Exactly. It’s a support function. So, we can’t invest 2 million in a solution that’s going to automate procurement tasks. Even if you feel there’s a business case, even if you feel the ROI is on the table… I think a lot of organizations are still not be ready to invest that money. So if it’s a budget constraint, that comes back to the sequential implementation: start small, but don’t try to do 100% too quickly.
J: Don’t try to make it fit if it doesn’t fit.
T: Yeah, just start small. Do quick wins. Prove the concept. I mean, that’s exactly the case we had with a client in Montreal. The CPO wants to prove to the CFO – who is actually his boss – that the solution is going to bring savings, visibility, transparency, process harmonization, etc. We started with one module on half of the categories. We deployed that in two months. The result is demonstrated and we can move forward with another module. We can probably unlock more budget and go sequentially to the next fiscal year and get a bit more budget. The implementation will take 18 months instead of 3, but you will get a much higher ROI at the very end.
J: Yeah, fair enough. I like that. Instead of going and applying for the big budget up front to transform the whole company, do it step-by-step. Play that game internally. Although it might be more heavy from a budgetary application process perspective, I think you’re probably right in terms of getting the best ROI at the end.
T: Yeah. but that also allows you to get the benefits first before reinvesting money in deploying the other modules, the other business units and everything. We could do a full podcast on that and how to measure the success. For example, if we talk about one specific module called Reverse Auctions. We could do an hour just on that.
J: You mean the functionality in sourcing modules?
T: Yes. Implementing, in the correct way, reverse auction for any organization in Canada or in the US, could finance 10x the price of the implementation of the software with the savings that will be generated. But you have to read very carefully: choose the category, evaluate the readiness of the market and everything, so it’s not something you can just do [easily].
J: And you have to have your base in place already? You’re making a simple solution a bit more complex and not doing it from the start.
T: Exactly, but that could give you the full part of the solution and pay like 10x the price you’ve invested.
J: I’ve seen it! I’ve seen that once where we ran reverse auctions and suppliers were going crazy. They wanted to win the event and bid much lower than in any other competitive scenario like an RFP or anything like that. It was pretty impressive – it becomes a game!
T: I have deployed that in Europe for a transportation company. They wanted to do a reverse auction each week, each Monday, on their fuel purchases. They use a big amount of fuel because they have many hundreds of trucks in different countries in Europe. Each Monday, they were negotiating a new contract for a week with a specific fuel providers. It was a couple of cents, like 1 or 2 cents in a 30-minute e-auction every Monday. At the very end of the year, the savings realized by this auction was about 15 million.
J: It’s crazy.
T: For a tool that they paid like 100K.
Critical Success Factor #6 – Supplier Enablement
J: Yeah, fair enough (laughs.) Alright, I’ll try to bring us back to our discussion here, we’re getting side-tracked but I’m sure we can have more discussions later. OK, this is a big one for me: supplier enablement. I think it needs to be similar to how you deploy a system and the modules. [In your opinion], how do you deploy supplier enablement, or rather, how do you approach supplier enablement? What are your thoughts on how to do that correctly if I’m starting the S2P journey?
T: In most of the projects I’ve seen, the supply’s side is usually not really considered. We just focus on the procurement internal side… “For suppliers, we’ll send them an email”… Definitely, supplier development or supply activation should be considered as one of the change management aspects of the project. Suppliers are probably the biggest population that is going to use this solution. If you consider that, you’re probably going to have, let’s say on average 40 buyers, and 10,000 suppliers using the solution. And we only focus on the 40 buyers. We should definitely put the light on the suppliers, on how to communicate this solution, what benefits is this going to bring to suppliers, and how do we onboard them smoothly with this solution? Most of these solutions have supplier portals that allow a lot of things, but we definitely need to [try to segment suppliers in different categories.]
J: Yeah, in different tiers.
T: Yeah, exactly: A, B, C. You take the strategic ones, the medium and less strategic ones, and then add a specific enablement strategy for each one. So for the strategic ones – and I’ve seen that with a big telecom company here in Canada recently – they had a really good strategy. That included connections with supplier’s back-end systems directly connected with SAP or Oracle on the supplier side to generate the catalog on the source to pay system.
J: Yeah, full integration.
T: Full integration. That really strengthens a relationship with the suppliers as well and that brings a lot of value from the platform that you’re implementing.
J: Yeah especially if you have benefits tied to automation or reduction of FTEs, that sort of thing.
T: Exactly.
J: And so, what I’ve seen a lot is clients or customers will know the importance of supplier enablement, but they won’t consider it – and I think you put your finger on it – as the change management aspect. It will be really important to get the suppliers on the platform as quickly as possible to get those benefits, but we’re not considering that they’re now part of the ecosystem of our systems. Even if it’s a cloud system, they’re now going to be using our processes because I have them logging into “my” network. I have to consider their experience in my process, whereas before, as soon as I sent the PO, I washed my hands of it: “I’m going to get what I get and they can figure out how to enter my data on their system.” Now, I have to figure that out up front.
T: And that will bring you the maximum value, because if your strategy for supplier enablement is strong enough to make them use, for example, PO flip – I mean, everybody dreams off PO flip, right – if you do that, then the suppliers log in, take the PO, acknowledge it and then convert it into an invoice. That means your three way matching is 100% accurate, so it’s a touchless process for the invoice. Imagine the ROI of that, in terms of energy, time, FTEs, whatever. Focusing on that will probably bring you new sources of benefit from the implementation of the solution.
J: And not to toot our own horn here, but I find that’s something that having a partner will allow you to do. They’ve done it with other customers, whereas internally you’re using that old method where you send the PO out, then you receive an invoice and you figure out how to make a square peg fit into a round hole, in your system…
T: Absolutely.
Critical Success Factor #7 – Data Quality
J: So, data quality [is the next critical success factor on my list]. It touches a bit on the preparation aspect that you were mentioning earlier.
T: Actually, Fluxym has just issued a 50-page white paper on supplier data quality, to help for preparation of source to pay implementation projects. I will also send you the link. Honestly, it’s one of my favorite topics. It’s really underestimated; you’ve worked for years with an ERP, you look at the supplier data – and I’m only talking supplier data – because you have all the other master data, and all the garbage that you can imagine in an ERP.
J: It’s funny you say that because I think that you can get around with so-so data for most things, but not suppliers.
T: If you look at supplier data, honestly, don’t implement a S2P system without doing supplier data cleansing before. Never do that. I’ve seen that with a client who gave me a 60,000 supplier database that was completely obsolete, not up-to-date and missing data… We heard ‘’Oh yeah, in the phone number, we just put a specific code to say that this supplier is an internal company, intra-group or whatever’’ and all these rules that you’ve implemented for years in your ERP and don’t even remember why. They are just thrown in your face when you implement that S2P system. Work on your data, cleanse your data, and that takes a lot of time. Because cleansing the data is one thing, but you have historical data, ongoing POs, invoices, you have transactions. You need to close these transactions before you can change your suppliers. Quality in, quality out. Before you put garbage in your new system, just make sure that your data is the highest quality that you can get. And then implement your system.
J: And would you say that includes as well getting your hierarchies OK? Having your main vendor, your ordering addresses, your returning addresses sorted so you don’t have 15 instances of “IBM” in your system?
T: Yeah, the hierarchy and the duplicates, because even if you build your IBM hierarchy in your system, you’re probably going to have like 25 different “I.B.M”, “I B Ms”, “International Business Machines” and whatever, so you should definitely build your hierarchy. That also could be applicable for all other kinds of data. Clean your units of measure. [There was] a project where we’ve received an interface with 120 units of measure. I asked the client “How many are you really using in RFPs?” and they said “Probably 5.” “So why am I receiving 120?”, “Because that’s an ERP.” “Oh okay, thank you.” (laughs)
J: Let’s put a filter on that. (laughs)
T: So, yeah. Does that mean that when the buyer is going to think about tomorrow – day 2 – when the buyer is going to create an RFP, he’s going to have to select within a drop down list of 120 units of measure?
J: And everybody is going to choose something different, right?
T: Exactly.
J: And you can do this even with payment terms, etc. There are different pieces of data that are a bit easier, but the big one is definitely suppliers, right?
T: And that will also definitely help you to raise some business process issues that you couldn’t identify before. Maybe you’re going to realize that someone is using that specific unit of measure but shouldn’t, you know? So maybe it’s also a good opportunity to make some good business decisions, to simplify and streamline things.
J: OK, so as we go through the list, I feel like that’s the one that’s gotten the biggest reaction so far.
T: Yeah! (laughs
J: We’ll see. I’ll get your take on it at the end.
Critical Success Factor #8 – System Customization
J: I’ve got a few more [critical success factors], so: system customization.
T: The answer is easy there.
J: Yeah, I think we touched a little bit on that, but…
T: No system customization. Never.
J: Even if I am convinced that “X” functionality gives me a competitive advantage in my purchasing process versus my competitors? Should I make an exception in that case?
T: (Laughs) That’s a really good point. If you look at the vendors you were mentioning at the very beginning, Coupa, Ariba; they build their solution and improve their solution like twice a year with releases based on their experience and their knowledge of their best practices within all the different verticals. So if you look at it now, most of the providers have solutions packaged for verticals like manufacturing the pharma or the mining sector. If you don’t find a capability out of the box in the solutions that have equipped the biggest companies in the world, then maybe you should have a deeper look at your process and find out “why you’re so exceptional”. Sometimes, the answer is a change in management issue or a process improvement issue more than a system customization issue. Because [it] will cost you a lot in terms of implementation, in terms of maintenance, [as well as being] a risk for the future of the solution maintenance. Please avoid system customization. Zero, zero.
J: In one instance what I saw with a client – and I found this to be pretty sharp – is that they took whatever the cost of the customization was and they multiplied it by 12. If you still had a positive ROI then they took a look at it.
T: Yeah, that’s great.
J: So with that type of rule it will allow an exception but it really needs to be highly justified. And with cloud systems, we’re getting to a point where those companies don’t even allow it anymore because they want to be able to provide you upgrades every quarter, every month or whenever. Their ability to do that is based on the fact that you haven’t customized the system.
T: And honestly, the capability of the leading solutions today in terms of configuration, like out-of-the-box customization systems, gives you really enough possibilities of having something adapted to your processes.
Critical Success Factor #9 – Change Management
J: Change management: we touched on that a little bit throughout, but how do you feel we should approach change management from the start to be successful in Source to Pay implementation?
T: As a services company we usually help are clients on the change management part, but we only support something that should be driven internally. We can give our best tools and practices for change management tailored for different populations, including suppliers, buyers and users if we’re talking about a S2P system. But that should definitely come from the client, the company itself, because it requires a strong knowledge of the company’s culture and context, different people’s history, relationships with the implementation of new systems and the type of population that could be impacted. That should really be led internally by the client with the dedicated resources and supported by the external [partners], like an implementation partner.
J: I think you touched on something I agree with very much as well, which is identifying your user groups. Depending on the module, these are going to be different and [you might want to adjust depending on] which ones are going to be your champions, which you referred to earlier as well. When you identify those groups and take that into consideration in your deployment strategy, it helps you determine who’s going to be your pilot. Who’s going to help you get that snowball growing the fastest?
T: One thing is that change management has always been a big deal in information system implementation, but in 2019, I feel that the relationship with the technology is now a bit different than it was 10 years ago. People will consume their technology very differently – with smartphones, tablets, at home. Maybe change management – and I’m not talking about process change – but really the [tool] change. “I was doing it with my Excel and my tablet, and I was happy with that but now, today, and tomorrow you’re asking me to do that through a system by just giving me a training.” I think people now are more comfortable, and if you look at millennials, for example, they have a strong appetite for using technology, so maybe change management is a bit easier today for technology implementation than it was 5 years or 10 years ago. And you know, with the usage of video today, a change management tool is something that you should really consider.
J: Yeah, basically, using leading PR practices in your implementation. Your point on millennials is interesting as well because I find it’s almost an expectation now. “I expect my corporate buying systems to be iPhone friendly just as any other app I’m downloading personally,” right? I think it sets the bar for what type of content you need to have in your system at go-live and the type of things you need to be doing [as change activities during your implementation]. That should all be taken into consideration in your strategy.
T: Yeah. Once, a CPO of a famous restaurant company in Quebec told me that he was struggling hiring young buyers, because [some] of the questions they asked during the interview [were] “What technology are you using to manage procurement? Are you using Ariba, Ivalua? Is there an emerging technology that you’re using to find suppliers?”, and they didn’t have anything.
J: Yeah, they were on Excel! (laughs)
T: Yeah, “we have Excel and Outlook. Is that enough?”
J: Maybe an access database sometimes…
T: Yeah, “thanks but no thanks.”
J: That’s a really interesting point, because it signals the importance your company puts on procurement. It’s a recruiting tool as well. Yeah, that’s interesting, I never thought of it that way before.
Critical Success Factor #10 – Governance
J: Alright, last point and then I’ll let you go and thank you for your time, Thierry. Governance. For me, it’s a big one as well. I can have the best teams in the world, I can have the best change management strategy, I can have the best deployment plan, but for me if I don’t have the proper executive support or the proper governance for the project, I’m going to get into trouble. I won’t be be able to do what we’ve been tasked to do. How do you see governance playing into source to pay projects and how a company should approach that?
T: That’s really a keypoint as well, you’re totally right. You need to have the right sponsorship at the executive level in the company, and you need to define the good governance architecture of your project. That means, what instance is in charge of what decision? You know, I’ve seen too many times in projects “OK let’s have a steering committee every Thursday.” That doesn’t work. The steering committee is not there to look at the UAT logs and see who’s doing what, and where we are in the planning. The steering committee should be there for major milestones of the project and to take strategic decisions in the orientation of the project. They should analyze the major risks that have been identified by the project managers.
On the other hand, I’ve also seen projects where people are getting nervous and blocked on a project because they feel they have a big list of issues, “Ok, the business is asking for that and the solution provider can’t meet the requirements,” so everybody is deadlocked, pointing at each other. And then you come to a steering committee and you have the strategic vision of a CPO who says “we don’t care about that, let’s forget that, let’s move forward with that,” and that can really unlock the situation of an implementation that could be blocked.
Finding the right pace and calling the right people at the right moment is really important in terms of governance. That means having a core project team that is responsible for the good progress of the project on a daily basis with a project manager leading it, and then being able to call a steering committee for each major milestone of the project with an executive sponsor able to take decisions. And in those instances, they should be decision points, not just meeting to report information. You can see that even in design sessions, or in steering committees, or in weekly status meetings, we share information and that’s it. Those meetings should be decision points. Always.
J: You mention the decision points of the steering committee level, but when you touched on the project team, one thing I’m sure you agree with is empowerment. Empowerment of that project team as well. For those big decisions, yes you have your steering committee, but your project team, those people that are there that you’ve selected, they need to feel like they can take decisions on all those small things, right?
T: Exactly.
J: Or else, they’re going to always want to go back to the business, and you’re going to be [stuck] in this endless cycle of feedback.
T: Yeah, and that happens on every project. That’s what I was referring to the design sessions. Each time, at the end of a design session, you a parking lot with 20-25 topics on which “we couldn’t make a decision because we’re not important,” and that shouldn’t be the case. People in the project team should have the power to take a decision on behalf of the company and the procurement department.
J: I’ve often found this to be an 80-20 type thing, right? Where you come in, take 100% of the decisions, and then go back to your constituents and revise the decisions. You’ll probably have that 20% there, where you need to revise things or tweak things a little bit. But that 80% allows everybody else to keep going on the project. You’re not taking the reverse approach where you say “we’re going to start at 0%, and I’m going to go and talk to everybody and then I’ll come back and we can start.”
T: And then we can change everything. (laughs)
J: Yeah, exactly. (laughs) Are there any other topics or critical success factors that we haven’t touched on today that you see as being super important?
T: I would just mention two things, and I think we covered them really well during our conversation, but preparation is the key. Prepare yourself BEFORE the kick-off. Don’t wait for the system integrator to come in and bring you all the magic through the implementation. There are some things you need to do by yourself. Prepare your data, your process, your people. Think about your deployment strategy, and don’t wait until the kick-off because it will already be too late, and your planning will be delayed for sure. That’s my first takeaway.
The second one would be – as you mentioned, and I really like this approach – implementation is day 1, but then there is day 2, and 3 and 15. Always think in advance, always think 2 or 3 steps ahead, because you can’t just have the go-live and then think everything is going to work. For example, it means your future system administrators – the people that are going to manage the users, the profiles, the updates of the workflow and everything in your system – should be involved since the very beginning of the project. They have to be present in the design sessions because they need to hear what’s going on, why this decision has been made, so prepare for day 2 since day 1.
J: Fair enough. While you’re saying that, it lights a bulb in my head on one point that we didn’t touch on, which is documentation. Making sure that you have the right level of documentation. You’re not documenting every single thing, but at the same time, it’s deep enough that you’ve got your decisions and your rationale and “why we did certain things and why we went in certain directions,” so that you’re not questioning that and trying to reverse-engineer all of your decisions after the core project team, whether it is external SIs or folks from the business go back from whence they came, right?
T: You’re totally right on that, and I will finish with that because we could go on for two hours, but that’s a key part of the methodology at Fluxym. When we do documentation, we have three different parts. We call it the RSC (requirement solution configuration) methodology. So usually you have a business requirement document and you have a specification. On one hand, you have a technical document with an how the tool is configured and on the other hand, a business requirement document that gives you a vision of the process. But how do you match these two documents? How do you know that this configuration choice answers exactly to the business requirement that has been expressed? That’s why we group everything in one single document where we detail the requirement, we [suggest] a system solution to cover it and then the last part of it is “How should we do that technically-speaking? What’s the configuration going to look like?” Create a field, give an authorization to some profile, but there’s that missing part in the middle that shouldn’t be underestimated.
J: Fair enough. Alright – thanks for your time Thierry, I really appreciate it. We talked about critical success factors today, but is there anywhere people can get in touch with you or see what you’re working on, that sort of thing? Is there anything you want to leave with the audience?
T: Yeah, definitely follow Fluxym on LinkedIn, there’s some pretty good activity on [the site].
J: Yeah I saw you giveaway some prizes there a couple of months ago, for your 10,000th thousand follower I think?
T: Only a thousand followers! Thank you for [that though.] (laughs)
J: I feel you presence! (laughs)
T: We actually are pretty interactive with our community of followers on LinkedIn. So you can follow Fluxym [there] and there’s also our website with a lot of content where we have a blog. We try to issue and release some white papers on a quarterly basis.
J: Awesome, thanks again for your time and I’m sure we’ll speak again soon.
T: Thanks a lot Joël.
———————————
Do you see any other critical success factors that were missed? Which one do you think is the most important? How would you ensure it is appropriately covered during a project? Let me know in the comments.
If you liked this post, why not Subscribe
Transcription credit: Jade Lamarre
Last Updated on January 6, 2021 by Joël Collin-Demers
