Jon Reed Interviews Dan Lubin: Podcast Transcription

The Human Side of SAP Implementation: Podcast Transcription
Jon Reed with Dan Lubin, Director of IT for Abiomed
Hosted by Jon Franke, News Editor,
Podcast Interview Date: July 20, 2007
Download Podcast (Must Be Registered and Logged In!)

Jon Franke:  Hi, I'm Jon Franke for Today we're speaking with career expert Jon Reed of, and Dan Lubin, Director of IT for Abiomed, a medical devices manufacturer. Thank you both for joining us. Jon, Dan, and I are going to be talking about SAP implementations from a slightly different angle. And with that, I'll turn it over to Jon Reed to explain a little more.

Jon Reed: Welcome to this podcast interview with our special guest Daniel Lubin, who is the Director of Information Technology at Abiomed. We're going to talk with Dan about the human side of SAP implementations at Abiomed, and how they address those challenges. This podcast is hosted by, and was made possible by a joint collaboration between, my site,, and B to B Workforce, an SAP Premier partner.

Daniel, thanks for joining us today. Why don't we kick off with a broader view, and tell us a bit about your company and how SAP supports your corporate services.

Dan Lubin: Abiomed is based in Danvers, MA, and we're a leading developer, manufacturer, and marketer of medical products designed to assist or replace the pumping function of the failing heart. We currently manufacture and sell the AB5000, circulatory support system, and the BBS5000, ventricular support system, for the temporary support of all patients with failing but potentially recoverable hearts.

We also developed the Abiocore implantable, replaceable heart, and in Europe we offer the minimally invasive Impella, circulatory support system under CE Mark approval. The Impella 5.0 and 2.5 are investigational devices, not sold in the U.S. currently. We have other Impella devices that aren't yet available for sale in the U.S. either. Obviously, as you can imagine, a big focus of our efforts this year is bringing those devices around the globe.

Reed: And how does SAP fit into your efforts promoting those products?

Lubin: As a manufacturer we have the same requirements that any manufacturing company does, with the added areas of compliance and, obviously, quality being the thing that we all hold dear, especially in medical devices. So, SAP supports our finance and manufacturing functions, it supports our supply chain, it helps us manage our people with the human resources module, it ensures that we have the highest quality, through the quality management system in SAP. In addition to allowing us to analyze and measure key performance indicators for our business, using SAP's business warehouse and business intelligence tools.

Reed: So now we're going to get into the nitty-gritty a little bit. I understand that you guys implemented SAP's all-in-one package in 26 weeks. So, how the heck did you pull that off?

Lubin: Well, it was 26 long weeks, and certainly, as you can imagine, Jon, they weren't 8-hour days. But we implemented with - again in 26 weeks - with no full-time resources from an Abiomed perspective. So, my team was comprised of folks from every function that was impacted by SAP.  But all of those folks had full-time jobs and we gave them another full-time job, which was the conversion from our 30+, 20-year-old legacy environment to the all-in-one system. Helping us, obviously, was a team of consultants aligned with the different functional areas, and I think a whole lot of luck as well.

Reed: I first met you on a CIO panel that you appeared on at SAPPHIRE, and what struck a cord with me - and I think what will interest a lot of our listeners today - was how your company, which is a midsized company implementing SAP, was able to pursue all of the latest SAP technologies that you needed on your project, and yet you found a way to staff those new technical areas where often there aren't a lot of experienced consultants. So, how did you make that happen?

Lubin: We were lucky in terms of the partner that we worked with. I think that a big part of the selection process when you're looking to implement ERP isn't just selecting the software, but also selecting the right implementation provider, and making sure they bring their best and brightest to bear on your project.

At the same time, as we looked at managing what clearly was a larger environment than we had prior to SAP (and any system would have  been larger because we were moving from a number of stove-piper, individual applications, to one integrated system), we realized that we had two choices. We could either bring in a large technical team - in other words, we could create the empire of IT, so to speak - or we could look at strategically how we could partner with other companies that were experts at different areas of the SAP environment, to ensure that we had our risk, obviously, mitigated properly, but at the same time still retain the flexibility within the business that you tend to lose if you try and hire 20 people overnight to run your environment.

So, it was a combination of, from an implementation standpoint, great consultants with a good process as dictated by SAP, their ASAP process; and then, from an operational standpoint, leveraging some of the experts that are out there in areas of basis administration. So, managing the application landscape, SAP security, and then both on- and offshore development, to ensure that when we had something that needed to change, we had the experts out there to do it for us, without having to worry about the bandwidth issues that any company has when they try and use their internal team for everything.

Reed: I'm glad you brought up the offshore piece. How did you find a way to work the offshore model into your implementation, and did you find that it really did reduce your costs to provide the value that you were looking for?

Lubin: Yes. We use offshore resources really in two areas. We use them for some of our validation and compliance testing. In other words, as a company that produces products regulated by the FDA, we have to not only - as every company would - get SAP, or get their ERP to work. But, we also have to ensure that it's fully validated. And as a public company, we have to make sure that we're compliant with Sarbanes-Oxley.  One of the ways that we've outsourced is, on a project basis, by using a firm with a U.S. presence, but with offshore resources to do some of that testing.

The other way is for ad hoc development, that complex report; that area of the human resources module where we don't have expertise, we use teams offshore as well in different parts of the world. What's worked for us is working with U.S. companies that have that offshore capability. I think that coming from a larger company background in a big company environment you can manage offshore teams directly, and, I think, have great success.

But in a smaller company environment - which, obviously, Abiomed is firmly in the midmarket - we really need to have that local presence, or that U.S. presence, and let them be the experts of managing their resources offshore. So we didn't really look to offshore, Jon. What we looked for was to bring the blended rate for services down. In our opinion, in a way we're really not offshoring, we're just getting a lower rate because the companies we work with here in the U.S. are leveraging resources offshore.
Reed: That makes sense. Another thing that you mentioned at SAPPHIRE that I thought was interesting was you talked about how many functional consultants had too narrow a skill set for what your team was looking for. Can you explain what went into that remark?

Lubin: Yeah. The analogy I used - and it's a little hokey - is that pipes don't leak. It's the joints that leak in plumbing. And I think in the SAP landscape, or in any ERP, the challenge is that each module or area of SAP is so functional and so big that it's a career path. If you're an expert in human resources, for example, you may be the best human resources person in the world, but you may not understand the interactions with finance or workflow. 

And, similarly throughout the system, you might have an expert in materials who doesn't really know what happens when someone tries to build something with those materials on the manufacturing floor. The challenge that you have, working with an integrated system, is managing the interactions between the different functional areas that work inside of the business cycle.

So it's not production; it's not materials. It's not those things. It's plan to procure. It's procure to pay. It's within those cycles where you have multiple disciplines involved. We had the same issue from a business standpoint as well. The folks in our customer service area don't know everything that happens in the materials area, even though the customer service folks are selling those materials. They don't know all about materials and logistics and whatnot.  The challenge you have in the consulting world is finding and managing that gray area between those disciplines to ensure that you get a cohesive business process articulated into the software.

Reed: That's really good feedback. We often advise consultants to make sure they have a narrow enough focus where they can achieve some mastery. But, I think sometimes we lose the message that if we don't understand how that area of mastery ties into other aspects of SAP, they're not going to bring the kind of value that a lot of customers are expecting right now.

Lubin: Yeah. We have a million analogies, Jon. But we made a change in one area to our work orders and our production floor to make life easier on our operators, which was a terrific change to make. It made sense on the floor, not realizing that that would kick off spurious planned purchase orders to our purchasing group, by the bushel. A great change in manufacturing became a clean-up effort in the procurement organization.

Again, everybody made the right decisions; it's just a matter of no one can know the whole system. The level of collaboration around what you do with the system has to go up markedly compared to what you might have done before in a less integrated environment.

Reed: As part of your staffing model, did you look at bringing in full-time employees that had SAP backgrounds to contribute?

Lubin: Absolutley. And we have done that. We've brought in one very senior reporting analyst who helps us with some of the programming around some of the reports and forms and labels and so on that we need.  Over the course of the next year, I think that we will look to bring on a couple of additional resources to make sure that we're leveraging things like business intelligence to - as I've kind of put it to my team - address those issues that are big enough to be addressed, but too small to be packaged and outsourced comfortably or cost-efficiently. 

Will we ever have a 20-person SAP team? No. We have one dedicated person now. Will we grow that to 2 or 3 as we bring our operations in Europe online? Yeah, we probably will. But that's really more to do with the natural growth of our utilization of SAP and the growth of the business, not so much the need to add a lot of head count to support SAP.

Reed: Now, we know you definitely achieved some benefits through your SAP implementation, including all the compliance aspects you're able to fulfill. But your users did go through a lot during the implementation, and how do they feel about their daily jobs using SAP and such? Are they onboard with what's happening, or do they kind of ever tell you, "Hey, I wish it was the way it was before SAP came along"?

Lubin: It's a great question. Do we have people - and I'll make the joke, even though this is a podcast - do I have anybody with an SAP tattoo? Probably not.  At the same time, we did introduce a lot of change to the business, and we had the benefit of a set of legacy systems that no one liked. So in a world of, "There's nowhere to go but up," SAP was definitely a step up.

In terms of how people feel today, whether they'd go back: no, they wouldn't go back. In terms of the frustrations, where they exist; one, I think they exist in any environment in any company; but two, as we brought our business processes into SAP, we brought a level of rigidity to those processes that people, I don't think, necessarily anticipated in every area. The way I explain it internally is, "Where process and practice didn't meet, people have felt more pain."  It's a good thing because we've taken variability out of the execution of processes, which means that we're executing consistently.

But, at the same time, that can be interpreted negatively to mean that we've reduced our flexibility.  I think that's an area where people continue to get more and more comfortable. But we've seen, as you mentioned, tremendous benefits in terms of the visibility to data; the visibility into our web; into our supply chain; the 90+ percent improvement we've had in terms of our travel and expense reimbursement process, which has been a particular benefit for our field clinical and sales people.

And we're going to see even bigger benefits once we bring our operations in Europe online, and bring our global consolidations into SAP, which is going to be a huge leap forward for us, a project we kicked off just two weeks ago.

Reed: You were very clear at SAPPHIRE that your staff did struggle a little bit with burnout during the implementation cycle, and I admire that you said that because when we talk about the human side of the SAP implementations we often think about people almost fulfilling these robot-like functions on the implementation team. How did you deal with situations where you thought your team was a little spent and you were trying to tell them, "Hey, just 20 more yards to go, we're almost there." How did you get through those times?

Lubin: You have to put a lot of effort into the human side of the implementation. The fact is - and everyone knows it - that the clock is ticking. The dollars are being spent, in terms of consulting and distraction from our daily jobs. The only salvation is to take the system live, to get to the finish line, which is really just another starting line.

We spent a lot of time over-communicating. We bought a lot of lunches. You spend a lot of time trying to communicate with folks one-on-one. You do everything that you can - just like you would in any project, whether it's ERP, or you're building a house - making sure that people understand: one, that they're appreciated; two, that their efforts are important and valuable; and three, that everyone is working towards a goal.

And what you have to do is continue to raise the visibility of that goal. The further into the project, the more people started to get that level of exhaustion, and it's just something that you have to manage. And, again, you manage it through communication. You manage it through lending a kind ear. And you manage it through highlighting people's successes, giving them an extra hand when they need it, and ultimately rewarding them for their successes as we get the project completed.
Franke: You guys both brought up some points that I think were interesting. Dan, you had said during this fast implementation [that] it was almost like people were working two jobs. And Jon, you made the point - and I also know very few employees who are actual robots - because it's a topic that tends to get a little bit lost in the technology and other aspects of a project, could you maybe just talk a little bit more about keeping morale up and keeping people motivated?

Lubin: Well, ultimately what I'll say is [that] you have to put a lot of effort into not only being that extra shoulder when someone needs to push the door open, but also to keep people motivated. And certainly we did make sure that we recognized the efforts of the employees that worked on the implementation.

I'm glad you brought the question up, because I think that this is a mistake that companies tend to make. I've seen it in other companies, where people think about something like ERP as just another part of the job, and don't realize that, as I had said earlier,  it's a second full-time job during the course of the implementation and beyond.

It's critically important that senior management recognize that this is a huge effort and it's a huge set of responsibilities you're putting on to your team, and that people are going to have to go above and beyond the call for the project to be successful.  And, in turn, the company's got to make sure that they reward and recognize them. And I think we did a good job of that here.

Reed: Absolutely. SAP talks a lot about SOA functionality and the new enterprise services architecture, and how it can help companies add functionality with less ripping out the code from the interior and doing custom work. Have you guys looked at SOA functionality as part of your implementation either now, or going forward?

Lubin: By the nature of what we implemented, we have SOA. Because we implemented the NetWeaver platform, we implemented the landscape that is designed around the SOA concept. At the same time, our commitment as a company in terms of our strategy is to leverage SAP out of the box as much as we possibly can. Where we have a system that isn't SAP, we have to really challenge whether it needs to exist. If it does need to exist, can we do whatever it does inside of SAP? And if we can't, then what level of integration can we achieve?

What we're not looking to do is develop applications in the NetWeaver platform that are unique. So that again, in the midmarket, I think that's probably common, maybe not. You would certainly know better than I would. But our goal at this point is to continue to leverage the immense functionality out of the box as much as we can for as many areas of the business as we can.

Reed: One of the things that intrigued me about your implementation is [that] you mentioned you estimated up to 35% of the work involving implementation was directly related to compliance. Can you say more about how you integrated the compliance initiatives into your SAP install?

Lubin: Sure. So again, we take compliance very seriously at Abiomed, as you would hope that we would. And so, whether it's Sarbanes-Oxley, or whether it's FDA and the validation process, those are incredibly important to us.

We have resources, external resources, who are experts in both of those fields that helped us with areas like the design of our roles: the design of who can do what in SAP to ensure that they can do their jobs, but, so that we don't have any issues with segregation of duties with other areas, to ensure that we're monitoring the right things so that spurious or inappropriate transactions aren't being conducted in the system - and if they are, that they're being caught.

Luckily, a year later, that hasn't been a problem for us. To ensure that from an FDA standpoint - and this is most important - the system does what it's supposed to do, that the expiration date on a component, that the raw material that we received, is properly reflected on the finished good that we ship.

Going back to some of the outsourcing that we talked about earlier, we leverage a firm who are experts at SAP security. We leverage a firm who are experts at Sarbanes-Oxley in an IT or in a technology world. And we leverage experts at validations and testing in SAP to ensure that we were compliant in that way, as well as keeping our external auditors in the loop throughout the project, so that everyone knew. Internal audit, external audit, the project team, the consulting team: everyone knew that these tracks (we had tracks on the implementation, but also tracks on infrastructure, security, compliance, and so on) all had equal weight in the success of the implementation.

Reed: It's interesting how you mentioned earlier that your users have given you a bit of push back on how heavily structured things have become. But, I also have to wonder if they might feel a little bit easier going to sleep at night knowing that the compliance structure is so built-in now, where they know that everything they're doing relates to whatever the FDA and other regulatory bodies expect of your company.

Lubin: Yeah, I would tend to agree. The kind of data we can get from the system now, with every passing day, becomes more useful. And that feeling that the system will do what you tell it to do flawlessly, I think, does add a level of comfort. It certainly added a level of comfort for me as I work with the audit teams, to know that the system - if it's designed correctly - that the logic is going to execute flawlessly the first time you go through a process, and the millionth time you go through a process.

I think the other thing, too, is that people are gaining comfort in knowing that. And this is typical in midmarket companies, in smaller companies, where you have process dominance between the ears of an individual. Meaning that, Jon, if you worked here, you'd be the expert at this area, and there'd be certain things that only you would know how to do, no matter how well documented your business process was. And people are gaining comfort from the fact that SAP gives us a standard way of doing a lot of things. They know that you could be sick today, and those processes could continue to flow.

Reed: So, are there any other lessons learned from going through this rapid install that we haven't covered that you want other small-medium sized companies to know going in?
Lubin: Sure. I think that every implementation certainly is different.  Every company is different. But, I think there's some common lessons learned for us that are probably worth covering. One of the things that we learned is we tried to - as I mentioned it being a podcast - go with a completely part-time team from an Abiomed perspective. Meaning none of our folks were full-time on the project. And that worked in almost every area.

But the one area it did not work in was project management. The one role that I didn't fund, that I absolutely would have funded given the opportunity to do it all over again, was that key project management's role. So that's the first thing.

The second thing is there were areas - as you know in the SAP space, SAP gives you not one, not two, but five or ten best practices that you can adopt in your implementation. And where we decided that we had to be special, where we were so unique that we couldn't use any of those best practices, where we did something completely different: we now realize we've taken on a management burden, or a maintenance burden for those proprietary processes.  And that's something that, again, if we could do it all over again, we would have pushed harder to align with SAP best practices.

I think the last piece, and probably, again, the one that you've probably heard a million times, is we could have done more training. We could have done more knowledge transfer. We could have done more to take possession of the system at the point that we went live with it than we did. And that, I think, also goes back to the amount of attention that we could put into the implementation.

And just to give you a fourth one: the areas that put a lot of effort into documenting the business processes - the areas that put the most time into the most boring part of the implementation, which is writing everything down - are the areas that a year later are having the most success with SAP today.

Franke:  Great, great. And one other thing I was just kind of interested in also: you hear a lot - or at least I've heard a lot - about knowledge transfer and training in these projects being so important. But, also I feel like a lot of small and midsized businesses have a very limited budget for their project as a whole. Where would you take away in order to bolster this knowledge transfer and training component?

Lubin: It's a good question. I think that knowledge transfer, in a well-run implementation, knowledge transfer is a bi-product of the implementation. I think the training is a little bit different story, where you tend to have to allocate a budget line to it. But, I think where I would do things to ensure that we had knowledge transfer is, if necessary, I'd reduce the scope of functionality. I would assign more resources to the project.

The only thing I wouldn't do (and this may seem counterintuitive) is stretch out the timeline, because there's a natural progression to an implementation, and there's a point of diminishing returns, where you, at some point, realize you just have to take the system live for the project to proceed. So, again, I would do less.

And I would try and put more people at the initiative, internal resources at the initiative, before I would do something with the timeline. The other logic behind that is you learn so much by doing, and no matter how much testing and configuring you do, you don't start doing until you go live.

Reed: Well, that's an excellent point. One of the funny things you said at SAPPHIRE that I'm going to wrap with here, I'm going to put your words back on you and see what you have to say today. You talked about the great benefits you receive from SAP, but you also joked you would never implement SAP again. So as we wrap today, how would you reconcile those two perspectives for us?

Lubin: Jon, the one thing I do have is a pretty good memory. The comment was: I've done ERP a number of times in a few different industries, and the joke that I always tell is that every time I complete an ERP implementation, I say I'm never going to do this again. If you've ever built a house, if you've ever moved cross country, or any of those things, I'm sure you would probably say the same thing: "It was a great experience and I hope I never do it again."

Reed: Sure.

Lubin: In terms of SAP, specifically, the fact is - and I've done other sort of second- or third-tier packages - you get a whole different level of consulting resource. They're fantastic compared to the folks you get with some of the lower-end packages. You get a methodology that was a huge differentiator for us when we were looking at selecting a new ERP system. You get a tried and true methodology. You get an incredible library of best practices that, as I mentioned earlier, that if you choose to adopt, you'll get huge benefit from.

And you get - not to sound like a salesperson or a magazine writer - an ecosystem in the SAP world of consulting resources, support resources, off shoring and outsourcing services, that doesn't exist in any other ERP environment. And that's not because SAP needs it. It's because so many people use it. I mean, it's just fantastic to be able to go out there and ask a question and know that there are a million people who could answer the question. And what I found in the SAP world is people are pretty friendly. If they know the answer, they're happy to help you out.

So those are the things that coming from a proprietary system, or a system that less than 30 companies in the world still used, going into this broad world of SAP where there's so many people using it, it's just been fantastic. If I had to do it all over again, meaning if I had to do ERP all over again, I certainly would do SAP again. The proof to that is that we kicked off our implementation in Europe a week before last, and I'm headed back over there to really what has turned out to be a very excited team, who can't wait to start to use it.

Reed: Great. Well, best of luck with the European implementation. And we hear your message loud and clear that the gain was definitely worth any pain you might have encountered. And I think a lot of listeners will appreciate the fact that you didn't spin that too much, but were honest about what you went through. So, thank you so much for joining us today and sharing those insights.

Lubin: Oh, it was fantastic. Thanks for having the conversation.

Reed: Great. Well, with that I'd like to thank our listeners for joining us today for this podcast interview on SAP staffing trends. This podcast was a joint venture between and my website,, bringing you career answers for SAP professionals. And with that, I'd like to turn this back to our host, Jon Franke, of

Franke: Thanks so much for joining us, Jon and Dan. And that about does it for this edition of's podcast series. Until next time, I'm Jon Franke. Thanks for joining us.

Editor's Note: This interview is not a verbatim conversation from the podcast; it was edited for clarity and readability. However, no content from the original conversation was removed.

Download Now (Must be Registered and Logged In!)