From Local to Hosted: The Story of One Company’s Migration to On-demand ERP




Welcome to TEC radio. I’m your host, Wayne Thompson

Here’s a story to get you thinking if your organization has a traditional, local, ERP [enterprise resource planning] system running the business. It tells why Asahi Kasei Spandex America, a subsidiary of Asahi Kasei Group of Japan, made the transition from a locally hosted ERP solution to a remotely hosted, on-demand ERP system.

The company was searching for a solution that offered lower cost, simplicity, and greater transparency and flexibility. They looked at Sage, Microsoft, and SAP—whose system they were actually replacing—along with NetSuite. Find out how NetSuite offered them the functionality they needed, as well as the ability to speed up their decision-making process while reducing the costs of IT personnel and infrastructure at the same time.

In this podcast, I sit down with David Stover, chief financial officer of Asahi Kasei Spandex America, about the requirements, decision-making, and implementation considerations that went into the company’s unexpected move to an on-demand ERP system.

Wayne Thompson: So, David, what solutions did you consider in your evaluation?

David Stover: We looked at the Sage solution … Microsoft had just started talking about or coming out with a small to medium business solution, and we actually again considered SAP for a little bit. NetSuite really took the lead very quickly, so much so that the others dropped out probably within the first two months, although the Sage solution did hang on. It was really NetSuite's desire to work and to understand what we were trying to drive to, their desire to make the solution for us.

WT: What do you think were some of the key determining factors in the process of going through this evaluation, and what potentially may have caused some of these vendors to drop out because they could or could not meet those factors?

DS: Since we are a manufacturing [company], we prefer to operate on a standard basis. We were looking for a solution that would have standard costing, and again, SAP, that's their bread and butter, but they also have a fairly complicated standard costing system, something that we weren't in need of. And as well as it's fully back-integrated into production. Again, we have our own type of warehouse management production system. We didn't need to create another system to do that. The SAP solution we had was an integrated system into that, and a lot of people were having to manage that integration.

One of the things that we allowed for our driving point was that our system, which we were very happy with, drove and fed any other system, fed the data. Now, NetSuite understood that from the get-go, and they devised a type of an integration process that allowed our warehouse and our production system, which we call MHCS, to feed NetSuite, as opposed to trying to dictate exactly how I want that fed. Our integration flows—the data that passed—dropped tenfold. We essentially have about 30 fields that encompass all the data we need—obviously different flows—but that's all we did; and the SAP side had many more times that number of fields required to feed the system.

WT: Were there any vertical extensions that played a factor in your decision process, or was there something that you were looking [for] that was unique to your industry in terms of functionality that you required?

DS: The larger thing for us was to be able to integrate easily with our warehouse and production system. We didn't want a system that would step on it, which was our experience before, and NetSuite essentially had a way to plug right in. They don't have a very hungry type of inventory system, so it allowed our main inventory system to feed their inventory system easily, and we didn't want two hungry inventory systems like we had currently; there was no need for it. All we wanted to feed was one monster, not two.

WT: Switching over to the implementation side: who led the implementation project, and who all was on the implementation project team?

DS: The members were myself, who led that, I had my comptroller, and at that point what we decided was to break the system really down into four parts. Essentially we had the process of sales. So I have a head of treasury, a collections credit-type individual who ran that process in conjunction with the manager of customer service. Then I have the procurement process, which I brought the accounts payable supervisor in [for] that, as well as the manager of procurement, and those two shared in that pillar. We looked at, then, the inventory pillar, which the comptroller actually ran with an inventory control specialist, a production analyst, and a consultant who actually runs the MHCS system. Then we had an IT type pillar, an integration pillar, run by my IT manager.

WT: How long did the implementation take, both calendar time as well as man-hours?

DS: Two sides to that. Just the simple NetSuite implementation, to get the system up was, I would say, around three months. It was significant man-hours. I would say probably four people dedicating at least 50 percent of their time to it, and then calling in others as well, but not to the degree. Then the integration with the current inventory system—that was a little longer process. That's why we would have gone up on January 1st—[which] was our initial plan—but the integration process took a little longer. There was myself and the comptroller [who] were the main ones doing that, as well as the consultant from MHCS system. But we also had some customer service people, so that was probably another four people for three months, probably about 40 percent of our time.

WT: How did this implementation time frame meet your expectations, from both a time perspective and a budget perspective?

DS: Essentially the NetSuite, the ERP side, was actually very pleasant. It went very quickly. I would say it matched a great deal of my expectations. The integration standpoint was a little different. I think that was probably something that could have maybe been done better. [In] NetSuite's defense, I don't think they've ever done—or they told me they've never done—anything this complex. The understanding of the different type of flows or integrations was probably the main issue here, and I believe they grasped the motivation, or the need for each type of document flow or info flow, very quickly. It just took a little refining. There were little bugs beginning with it, and unfortunately in the amount of data that we pass, a little bug becomes a major one. So I'd rank that as somewhere about around a B.

And again, it was a fairly complex thing for us. We had very similar problems with our SAP side, but we had much more dedicated resources to accomplish that.

WT: Let's dig into those integration challenges. What types of integration challenges did you see that presented the greatest problems for you, and how did you overcome them?

DS: Well, we had one main integration. We produce a carton of goods, which is our sale unit, probably upwards of a thousand a day. We must maintain all the specifications for the goods in those cartons, and also their lab tests, [and] any quality information as well. So that all resides from our various production systems and quality testing systems. All of that information must feed into the NetSuite custom database that represents our cartons. The end result is that when we get an order from customer “x,” we know customer “x” has these types of parameters he's requiring that allow us to go in and use the search engine that NetSuite designed to say these are the parameters we want, or the range of parameters we want, and go find the cartons that would fill that need.

So it's a little bit of a complication as far as making sure again that our certain parameter that's important to the customer—he needs this within this range—that this customer gets this product exactly as he wants it. And from a warehouse of thousands of cartons, to find the ones that meet that were the challenge. Now, those characteristics change over time, and they're constantly tested, so it's a dynamic process. It's not just “OK, well, the good's produced and that's it.” There may be some effect of aging. In fact, ... our product—an aged product in some respects—has some more desirable characteristics. So those are retested, and the information is put back into the system. So, you have a dynamic data record that constantly changes, but those changes must be reflected quickly, accurately, so that it can then be placed in the right customer's hands.

WT: So, how did you overcome this challenge, of making sure that you had all the parameters and the right information?

DS: Well, the first thing was really design of the initial database, the carton database, which is a special record in NetSuite, which is actually fantastic in itself. We've used this a couple times. It's an ability to put a special, customized record that can be utilized in any other point, and [for] that design, we met with the production or warehouse people to make sure that was initially done.

We looked at all the potential goods movements, and essentially we took some of the work we had done with SAP and identified the goods transactions—not only the production, the retesting, inter-warehouse moves, things [of] that nature—and devised that scheme of “well, these are all the potential goods movements, these are the impacts of these,” and then turn that over to the NetSuite people to look at programming how that went.

It went back through a testing phase, usually had ... tweaks to be done, [was] retested, and then went into a live phase, where the quantity passed. We had a little bit of [an] issue with that because the throughput was much higher than I think was originally anticipated, and that was quickly adjusted.

WT: So, David, what benefits did you achieve by switching to NetSuite?

DS: Main thing is transparency; that was the most obvious, right off the bat. In the management side especially, the amount of data and the way to organize it was much easier. You saw everything right in front of you—no need to drill down, and drill down, and drill down. It was a way to also do very customized presentations [for] the management teams, and essentially give them their own menu path to accomplish these reports.

Also, NetSuite's very e-friendly, where you can e-mail reports out daily. And we do that quite a lot now, where the head of production—vice president of operations, [who] sits next to me—every morning, he gets his standard suite of five or six reports. He doesn't need to go into the system at all. They're there; he sees them—this is the activity of yesterday—and he can take its impact on him.

WT: Were there any unexpected benefits that you achieved?

DS: Another thing for us also was employee friendliness. Because this is an Internet-based system, if someone actually has to be out today, people feel much more comfortable because if there's an absolute pending issue they have to take care of, most people can take care of it from home. They don't have to run in [to the office] just to access the system at a workstation.

WT: If you had to do it all over again, what would you do differently?

DS: I think the good thing we had was the design of the implementation team. We did understand it was a financial solution, not an IT solution. What I would change is the sequencing of events during the implementation.

What typically happens is you go through a redesign process as the first thing. That, I believe, was a flaw. I think what should have happened is a training process: what can the system do, and then do a gap analysis, and let that gap analysis be your redesign process, rather than doing a redesign process, then see what the system can do, try to put it in place, and then “Oh, by the way, it can't do this” or “It does it this way,” and then go back into the redesign process.

A small issue, for instance, was a sales tax issue. Sales tax is a fairly common or easy process, but for us, we utilize a direct-pay permit in this state. So NetSuite had a traditional way of doing sales tax. You know, this is something we didn't think of in the design process, [so] when we actually saw this is how it operates, it was something we needed to go back to and address. So if I would do it different—up-front training, to really get the system, then the design process to match gaps or to fill gaps.

WT: David, thank you so much for sharing your insights and experiences with NetSuite.

DS: No problem.

Thanks for listening to TEC radio. If you would like more information on evaluating and selecting on premises or hosted ERP solutions, check out www.technologyevaluation.com. If you would like more information on Netsuite, check out www.netsuite.com

Thanks again for joining us.

 
comments powered by Disqus