Company Z – U.S. (ZUS) is a $1.3 billion maker and distributor of over-the-counter pharmaceuticals based on the East Coast. ZUS is a subsidiary of Company Z – Global (ZGLO) based in Western Europe. In 2011 ZUS acquired northern California-based Company M, a $100 million pharmaceutical company with a plant and two warehouses in northern California and another in Spokane, as well as a cross-docking facility in Texas. Company M had been growing in recent years at more than 35% a year and ZUS, by acquiring Company M, sought to gain market share, product diversification and expanded distribution.
Company M grew out of a family business and relative to ZUS, its systems, controls and processes were rudimentary. Company M had added software applications where needed, yet still performed a lot of work manually. It had packaged software applications for financials, raw materials, production planning, warehouse management and finished goods inventory.
ZUS, however, had been managing its business for over 10 years with SAP. It used SAP for order processing and shipping, demand planning, product deployment and production planning, raw materials management, financials, master data, and finished goods inventory management. It used a configuration of SAP largely defined by its parent company ZGLO, and reported financial results to ZGLO in accordance with standardized SAP cost centers, general ledger and chart of accounts.
As ZUS began to integrate Company M into its management processes, it realized that financial reporting from Company M was limited and manual. Having managed its operations using revenue and expense measures defined in a certain way in SAP, ZUS could not accurately interpret Company M’s financials in the same way and could not easily compare Company M’s business performance with that of ZUS. ZUS concluded that it had to institute within Company M the same financial definitions, controls and methods of reporting that it used already, and that meant converting Company M from its current systems to SAP.
While the primary ROI of the project – converting Company M to SAP would cost about $1 million – was the ability to financially manage the $100 million company, ZUS went further and defined specific “value realization” targets that would result from the conversion. Included in this were hard savings from staff reduction because SAP would automate certain manual processes.
A strong mandate by ZUS’s CEO mobilized a small team in the fall of 2011 that would determine how to quickly bring Company M onto an SAP platform. One of the first and most important decisions was project scope – what absolutely must be converted to SAP and what can wait? The team chose a scope sufficient to manage all core transactions in SAP while leaving to legacy systems or manual work those things that weren’t essential to “managing” the business in SAP.
Nonetheless, the team had to convert to SAP hundreds of products, customers, raw materials and vendors, and the purchasing, material requirements planning, order processing, manufacturing, shipping, invoicing, cash management, payroll and financial functions. The team decided to use as much of ZUS’s SAP footprint as possible, and to try matching business processes of Company M with those of ZUS.
The team had a project manager with 10 years of SAP experience and six to 10 full-time or nearly full- time business process and IT experts. Getting adequate time from Company M’s business process owners was extremely difficult because the organization was so thin, with Company M being a much smaller company than ZUS.
The cutover was completed on March 4, 2012, exactly on time and approximately $300,000 under budget. It had taken 90 business days from start to finish.
A limited scope made a quick implementation easier. The team matched the scope to the time allotted for the project, without losing the integrity of having all core functions running on SAP. For example, not all customers were converted to EDI for order receipt, and not all of Company M’s third-party distribution warehouses were integrated with advanced ship notifications (ASNs). These weren’t needed to get a complete picture of the business in SAP.
Lengthy configuration debates were kept to a minimum by using ZUS’s SAP footprint. Questions like “what storage locations should be defined in the manufacturing plant?” and “how should we define product, brand, packaging format, and UPC in the system?” were largely already answered by using definitions and parameters (collectively called set-up) that ZUS already used to run its business on SAP. For example, at ZUS, the product “hierarchy” went like this: “brand” is at the highest level and can include many “pack groups,” and pack groups can include many “formats” or packaging configurations, and finally, the product itself, the UPC (or SKU) fell underneath the pack group. This sounds like a tedious point, but it’s these kinds of decisions which can take a long time for enterprises to make. The longer a project takes, the more expensive it will be.
Overall, success was made possible by a small, strong, experienced and focused team with a CEO mandate. Most of the team members had SAP experience. Some had led previous implementations and many had deep functional knowledge of a particular area or areas within SAP. The project manager on several occasions threatened to move out the launch date — and invoke the wrath of ZUS senior management — if Company M’s business experts did not adequately engage in the project.
Nearly all of the project work was done on-site at Company M California headquarters. This allowed easy access to Company M subject matter and process experts, and made it possible for them to experience the software during testing. More importantly, the on-site work – usually in one large room – made for instantaneous communication and sometimes instantaneous problem-solving. There is nothing more powerful in an enterprise software project than knowledgeable humans being in the same room all focused on the task at hand.
ZUS drew on its experience with SAP to provide go-live support. SAP users at ZUS were brought in for the first three weeks of the cutover to help Company M learn the application and at the same time keep the business going. This included a “buddy” system, or pairing of one ZUS user with one or more Company M users, especially for critical functions like production, order processing and shipping.