Secrets of an (Almost) Pain-Free ERP Implementation
C-level Support Key to TNG Worldwide's ERP Implementation
Secrets of an (Almost) Pain-Free ERP Implementation
Ann All, IT Business Edge
Jan 24, 2011
Ann All spoke with Craig Zampa, VP of Technology Solutions for TNG Worldwide, about his company's deployment of an SAP ERP system. Ann met Zampa at November's Midmarket CIO Forum. Having heard her share of ERP horror stories (some at the same event), she vowed to interview him when she learned TNG, a supplier of products to salons and spas, had implemented an ERP system in eight months with the help of partners EntryPoint Consulting. In this, the first of two parts, Zampa shares some of the challenges of the project and some of the factors that helped make it a success. In part two, to be published later this week, EntryPoint CEO Pete Martin will discuss his company's role in the project.
All: What kind of an ERP did you have before you got your SAP system?
Zampa: We first introduced ERP to our company in 1994, with what is called a tier 2 system, more of an entry-level ERP. We ran it from 1994 to 2008. The good news was, we were used to an ERP and some of the benefits of having an integrated solution. But of course we found there are many different levels and types of ERP available.
All: Right. What were some of the factors that prompted you to switch? Had you just outgrown the tier 2 system?
Zampa: The application we were running was a proprietary application and the vendor protected things with intellectual property clauses. That really limited the amount of people who could develop in that application. So when it came to Web commerce or warehouse management, credit card management or shipping and manifesting, we had one option. That doesn't necessarily work for everything, as every business has some variations to how it does business.
The limitation had two parts. There was the proprietary nature, but the number of people available to do development wasn't very large because the solution wasn't big or relevant enough. We had one partner we could work with. There were a couple across the U.S. who understood the application, but we were license-bound to the one partner. They had one individual in the company doing all of our development. She knew what was going on in our company. When she left the organization, that intelligence left with her. We knew we wanted to avert that risk in the new world.
All: With the SAP partner ecosystem, I guess that's not a problem.
Zampa: Exactly. They don't lack partners or talent.
All: So that was one factor in selecting SAP. What else did you consider?
Zampa: Everything that was unique in our processes had to be done through customization [with the tier 2 system]. We knew that wouldn't be a good long-term model. Over 14 years of using that software, we had created thousands of custom modules. In 2004 when we did a patch application to come up to the newest and latest version, it took us a year to stop the bleeding that occurred when we found problems downstream. I swore off any future upgrades to that application after that.
We went on a search to find an application we could introduce that would accomplish the business goals we knew we weren't accomplishing because of the problems I identified. One of the things I liked about SAP was the open architecture. SAP is the core, but they make it easy to integrate third-party solutions. In some cases I'd see three to five partners with solutions appropriate for our business challenges, for small package distribution or for credit card verification. In other cases, I've seen as many as 10 partners with solutions addressing issues relevant to us. Think about what that does for me as a business. It gives me the ability to have a competitive bidding and selection process. In our first three years, I think we've gotten about $650,000 in negotiated savings. That's the power of competition.
All: You mentioned the customization that happened with your previous system. But I've heard that's an issue with SAP as well, or just about any ERP for that matter.
Zampa: When it comes to changes because of the uniqueness of our processes or just the differences between manufacturers and wholesalers and retailers, SAP has pretty much figured it out. When I run into challenges and say, "This is how it flows for our company," more than 90 percent of the time they've already figured it out and all we need to do is add a configuration. You change the switches in the configuration and your business flow works. What you haven't done was customize code or break your enhancement capabilities.
In April of 2010 when we did our first patch applications of five revisions, we ran into less than 10 items that caused any challenges, and we had them resolved in a couple days. It was a huge difference from a year of frustration and yelling [with the old system]. Because of how SAP is engineered, we can do these things through configuration. We can try them in our development world, then do our integrated testing, and then roll it out to production. It gives us the ability to be as effective as we want to be.
Sitting with the CEO of our company we determined we'd built a lot of processes over time to deal with how we do business. A lot of those weren't necessarily best practice, but just things we'd adopted. One of the goals for deployment was realigning our business and our processes into a best practices model. Using that idea, for wholesale distribution, moving small packages and other processes, we wanted to look at a best practice workflow and figuring out how closely we could mirror it, determining whether some of our processes were actually creating competitive advantage or just built as conveniences over the years. That was another piece I wanted in an ERP.
All: Interesting. I assume examining your processes in that way was helpful. It seems as if some organizations install an ERP and assume it will somehow solve all of their process issues. How important was that review?
Zampa: We knew we needed to blueprint the best practices model and figure out if it accomplished most of our goals. If not, what did we need to do to address that? It's a key thing to do in the beginning, rather than downstream when things have already started to get out of control.
All: How long did your implementation take?
Zampa: About eight months. In that time, we deployed the SAP ERP and also business intelligence and CRM at the same time.
All: Wow. That's really impressive. Why did you decide to do all of that? It seems like an awful lot to take on during an already complicated process.
Zampa: We were very reporting-intensive, because we had been using an ERP. Our reporting demands were high. So business intelligence made sense. And in regard to our staff, customer service is so important. We need to know what's happening in interactions with our customers. We wanted to create additional business value there, so that's where the CRM came in.
We knew it had to be a big bang deployment because we wouldn't be able to integrate to our old solution. So we knew we'd be dealing with a cutover, not a transition. You're making a lot of decisions for the future. It's like buying a house. You don't want to be in the position, "I'm out on the street and I need a place to live." That's no way to buy a house. It's the same thing with an application.
We also needed to have a solution for credit card verification. We are used to instant verification, getting approval codes and verification within two to three seconds. So that was an important aspect for us. Small package handling was important because we ship so many cartons. We needed a point-of-sale solution for 21 stores. We already had an advanced warehouse management system in our primary shipping facility, and we wanted to save that investment which we'd made in 2005. It was integrated with carousels and a conveyor system. Rather than forklift that, we decided to integrate it into SAP.
Considering all that had to be done, the eight months was a huge success.
All: In addition to complexity, you hear a lot of horror stories about high cost of ERP. Can you give me an idea of how much your project cost?
Zampa: We try not to focus on cost but focus on why it was the right financial decision. My ROI on this, I'm not too far off what I was spending on maintenance and upkeep of the old solution. I'm getting all my money back within a few years, and then I'm ahead of the game.
All: What were some of your challenges?
Zampa: Our adoption of SAP is a little unique compared to a lot of them, I believe. More than 80 percent of our employees touch SAP in some way, shape or form on a daily basis. We have 30 locations, and 100 percent of them touch SAP on a daily basis. So it's a major, major footprint. That created some initial growing pains.
The beginning is always a challenge. It's a lot of people taking on new stuff. It's a major change across the organization, not just with one group. In defining the scope of the project, we wanted to start with basics. We wanted to get used to a new application suite, and then in later phases enhance it and bring it to the next level. Remember, we put 14 years into the last application. I didn't expect to fix 14 years in one initial phase.
Unfortunately, that vision didn't stand all the way through. So we had scope creep. When we started talking about how we were deploying it, we started getting some pushback. But when it was all wrapped up and the project went live, we ran over by just four weeks.
All: I imagine scope creep was pretty hard to avoid with such an ambitious implementation plan. Do you think you could have avoided it?
Zampa: I think we would have been fine with initial plan. But I think it would have created more turmoil downstream. A fair amount of it could have been averted, but not all of it. It ended up working out that we addressed so many things in Phase One, that we don't even have a Phase Two planned now that we're two-and-a-half years down the road. Some of the additions we made took care of things that were planned for Phase Two.
Another challenge, the big bang nature of the deployment made it important to be very serious in the development and testing phases. It couldn't be "Let's just give this a try, and we'll pull it off the stove if we need to." Integration wasn't an option. So there was additional pressure there.
All: What are some important lessons learned you can share?
Zampa: Use the absolute best individuals in the organization to develop and deploy this. You need to create a close bond and partnership between the SAP experts on the outside and the people on the inside who know your business. You want those two to come together and create the best configuration for you. Using the best and brightest is key. They can own the process for their group and take ownership of things like documentation, testing and training. It's a full-time commitment, so you've got to take the other things off their plate to the best of your ability so they can create the best solution for their area.
With our partner [EntryPoint Consulting], we wanted almost a personal connection. We're a smaller size organization, without a lot of implementation experience for such a large deployment. There was going to be a lot of learning. We needed to have someone who could help us through that. It's easy to have a big company come in. But we were concerned about turnover. We wanted consistent faces to help us through the entire process.
All: So it's important to get a partner that is a good fit for your company and also to get the best internal resources working on the project. Anything else?
Zampa: Create a plan, commit to it at all levels and see it through. You want to limit changes as much as reasonable.
C-level Support Key to TNG Worldwide's ERP Implementation
Ann All, IT Business Edge
Feb 2, 2011
Ann All spoke with Pete Martin, CEO of EntryPoint Consulting, the firm that guided TNG Worldwide through its implementation of an SAP ERP system, plus CRM and BI, all in just eight months. Earlier Ann interviewed Craig Zampa, VP of Technology Solutions for TNG Worldwide, to find out why TNG selected SAP and why it opted for a "big bang" approach, among other topics. In this interview, she asks Martin about the key success factors that made TNG's project a success.
All: I was impressed when I heard TNG Worldwide implemented an SAP ERP in eight months, and then even more impressed when I found out it also implemented CRM and BI in the same time frame. How on earth did TNG do it?
Martin: Most of the success factors are software independent. They apply to any large, complex project that involves a lot of people and a lot of risk. TNG really nailed a couple of the key ones.
The CEO of the company, who also happened to be the owner of the company, was actively involved in the project. We get involved in a lot of projects where the CEO attends the kick-off meeting and then doesn't come back until the go-live. Those are projects that don't go well. It doesn't have to be the CEO, but you need active and engaged executive leadership. He actively participated in steering committee meetings. He wrote about the project on his well-read internal blog.
TNG does a lot of group activities as a company. Even before the project started, we did some soft kick-offs where we discussed the transformational nature of the project. There was communication the whole way about what was happening, what was about to happen, and what the results were afterward.
It ultimately comes down to people. We made sure both sides had the right people on the team to get the job done. Consultants always come in and ask for the best people. But the reality is, very few small- and medium-size companies can afford to do that. And everyone has a different opinion of what constitutes the best people. TNG filled the team with visionaries, people who weren't stuck in the way they were doing things and who wanted to take the company forward. They had a vision that they could make things better, and they'd make a huge contribution toward that.
There was a shared mutual feeling about success. They worked their butts off for eight months. We had some tears and stress, but nobody said, "Get me off this project." In fact, just the opposite. I talked to other people in the company who wanted to get on the project team. Everybody was totally committed to making it a success, in the time frame and in the budget. The internal project team got financial rewards. They took the budget we gave them and added a percentage on top of it to provide bonuses if the project was delivered on time, in budget and in scope. That goes back to the commitment of the CEO to make the project a success.
All: Was TNG's implementation more typical than not? We read a lot about ERP projects that go off the rails. But I have to think for every unsuccessful project we read about, there are multiple successful ones.
Martin: I don't want to say they are unique. There are thousands of successful ERP projects. The atypical part was the level of commitment from the CEO. And also, very few companies can afford to take people out of their jobs. They didn't relieve people of all of their duties. But they did do some backfilling and figured out a way to get more efficient on the job so they were able to make time for this project.
All: Craig described how TNG took a big bang approach to the project. Is that advisable for most companies?
Martin: It's another one of those notions that if you ask 50 people what it means, you'll get 50 different answers. It's not unique for us as a consulting firm. A company's ability to do that, or not, has everything to do with the other systems they are using, the processes they have and how easily or not you can integrate. Integration just wasn't an option for TNG, as Craig mentioned.
I think the phased approach for most companies is really a 90s legacy thing. Projects were so big they had to be broken down into phases. You couldn't afford to do anything else. In the middle market, you typically don't have as many unique systems or processes, so you can capture 80 percent or 90 percent of what a business does in a single phase. I think the reason most companies didn't do it is the level of risk. But there are more checkpoints now, so the risk is less now than what it was 10 years ago.
All: Failed SAP implementations, in particular, seem to get a fair amount of press. Do you think there are misconceptions about SAP implementations?
Martin: The biggest competitor to SAP is the myths and the legends. The big four misconceptions are: It's too big for a small- or medium-size business, it's too expensive, it takes too long to implement and it's too complex. SAP has invested billions of dollars in all four of those areas over the last 10 years. It'll take probably another five or 10 years to overcome those misconceptions.
ASAP methodology and preconfigured solutions address the too long to implement misconception. Fixed price, middle market pricing address the too expensive misconception. There's a methodology post-go live to make it significantly less expensive than it was 10 years ago. Regarding the too complex misconception, a combination of pre-configured solutions and a complete rework of the interface, to make individual role levels more productive, address that. All of those things make SAP appropriate for small- or medium-size businesses.