Dave Hannon recently conducted an interview with Yosh Eisbart a featured speaker at our upcoming Managing your SAP Projects event. The transcript is below. Enjoy!
Dave Hannon: Hello, this is Dave Hannon with the SAPinsider. I'm speaking today with Yosh Eisbart, a cofounder and principal at NIMBL, and today we're going to be asking Yosh for some tips on managing your SAP implementation partners. Welcome, Yosh.
Yosh Eisbart: Thanks so much, Dave.
Dave: I want to start off with some information about interviewing a potential implementation partner. I think a lot of folks would like to know how you ensure you get the right partner for your implementation, not just a qualified provider in a general sense. Are there certain questions you should ask when you're interviewing a potential implementation partner?
Yosh: Wow. I think that's a great question. I think, as a customer, I think that you really want to tackle it from two different points.
One is from a reference perspective, it is tremendously important that the provider has the track record within your respective area that you're looking to service, that they've been proven, time and time again, with other customers. Clearly, you don't want to reinvent the wheel and you don't want to cut your teeth as a client with an organ
ization that hasn't done it before. So, references -- definitely number one.
Number two, it's equally as important to ensure that the provider that you're working with has those specific specialized skill sets -- meaning that there are plenty of SAP professional services out there that are generalists. They do great things across a wide range of skill sets. However, if you're dealing with a very niche type of technology, it is imperative that the partner that you're working with has that specialized focus.
So as an example, doing any type of full SAP implementation, core ECC functionality, there are a lot of providers out there that do it well, are proven, and can tackle it from a generalist perspective. But if you're embarking upon, let's say, a BPC initiative, there are key vendors there that specialize only in BPC. So I would recommend then to work with one of those providers, again, that focuses exclusively on a given niche.
Dave: I was talking to a SAP user recently who brought up an interesting point, and I wanted to ask you about it: Is it common to interview the individual consultant or project folks that might be working on implementation? Or do customers typically interview the firm and let the firm decide which people are going to work on the project?
Yosh: You know, it really depends. The driver behind whether or not you interview the given individual depends upon, in a lot of respects, the type of relationship that you have with your vendor. So at a 500,000 feet level, one of the messages that we preach - and granted, NIMBL is a vendor - is the whole value of partnership. It's tremendously important that whenever you engage with any SAP services provider that that partnership relationship, where both of the organizations sink or swim together, is truly embraced.
The slave/master type relationship is so 1990; trying to embark upon that type of old-school mentality is one
which is fraught with issues and ultimately, I think, failure.
So putting that behind us, assuming that you have a certain type of relationship -- a trusted relationship -- with your given provider, it's not necessarily required that you go through the interview of a given individual.
Now if, however, it is a new relationship and you're also looking for a very, very specialized skill set, or you're trying to ensure some more of the softer skills -- like communication or corporate culture fit, etc. -- then maybe it's important.
Dave: I know implementation projects can vary in size, scope, and scale. Do you have any thoughts on the pros and cons of using multiple implementation partners? Some companies, in a large implementation, may use different partners for certain aspects or certain applications of the implementation. Do you have any thoughts on that? Pros and cons?
Yosh: Obviously it depends upon the initiative; it depends upon the size and scope because there are obviously advantages and disadvantages in going either way. A small implementation perspective -- putting in too many cooks in the kitchen if you will -- has a lot of potential for challenge. If you're dealing with a small project, it probably makes sense to choose a single provider. Have them resource the entire initiative.
However, if it's a larger implementation, then there may be some benefits in a divide-and-conquer mentality. Maybe you carve up different components of project, maybe by functional area, technical skill set, geographic location, etc. That may be one way to successfully leverage multiple providers.
Obviously, if you have multiple providers, unfortunately when things go wrong there is the potential of finger pointing, which clearly doesn't benefit anybody. So that's something you also need to keep in mind.
And a common trend that w
e're actually finding within the marketplace is third-party bulldog oversight. Meaning that for some larger implementations, organizations have chosen to actually bring in an objective third-party professional services firm to play bulldog, with oversight services to kind of keep their main implementation partner "honest."
If, as an organization, you the customer do not possess actual SAP skill sets, and in this market, especially within the SME market space, that is actually very common. It really helps you as an organization to bring in inside SAP knowledge, even though it's a third-party provider, to help ensure, again, that the delivery is being done, the technology being used is the right technology. If someone says that it takes 40 hours to do a ABAP RICEF object, they know it really takes 40 hours as opposed to 20 hours, etc.
Dave: That's interesting that you mention the third-party outside provider. On the projects you've been involved with that have included that aspect, what are your feelings from the partner side?
Yosh: It's a great question. There clearly is the potential for challenge and friction if the third-party provider comes in from a taskmaster perspective. NIMBL, because of our size and the relationships that we have, we typically play the bulldog as opposed to the main SI. So our perspective is one which is more, in some perspectives, kind of inside looking out.
However, no one benefits in any type of adversarial relationship. So again, continuing with the whole partnership scene, an SAP project only succeeds if everyone is on board, feels like they're part of the solution, and are working in concert.
Having a bulldog type of oversight mechanism - which is all about finger pointing and trying to poke holes - is not a beneficial model. Obviously the bulldog needs to be sensitive to everyone's needs and also needs to be fair, and when things are
going sideways needs to call it out.
But politically, these kinds of the interpersonal components are equally as important as SAP knowledge and skill set.
Dave: In your experience, are there any other tips you have for keeping projects on track? Are there any sort of common mistakes customers make or things they tend to overlook that send things off track or off schedule?
Yosh: Yeah, absolutely. I think so much of it has to do with setting expectations, setting service level agreements, better understanding roles and responsibilities, clearly defining deliverables. These are all things that if you, as a customer, put the time and energy into and ensure that there is a true understanding and buy in from your vendor, then there is less potential for disconnect and miscommunications.
Everyone has a different perspective, even though something may be "clearly documented" or agreed upon within some type of SOW. Spending the time to ensure that there's a clear and common understanding between customer and your SAP partner is imperative for successful delivery.
The other piece is constant communication. While this is maybe a little bit of motherhood and apple pie, if there is a working-in-silos type of mentality where you, as a customer, have a series of requirements and you throw it over the wall to your SAP partner to deliver it -- whether they're on site or off site or wherever -- that type of model is one that there's a higher probability for disconnect.
So, clearly defined deliverables, understanding and buy-in from your SAP partner, and constant check pointing and communication all help in the successful delivery and mitigating any type of potential sideways runoff.
Dave: Great. I want to thank Yosh Eisbart for speaking with us today. He is the cofounder and principle at NIMBL Thank you again, Yosh.
Yosh: Absolutely. Thanks so much for your time.