ANYTOWN, USA -- The ERP requirements for MegaCorp's production of Mobius-Lhapsa loops for the United States Armed...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Forces has driven the company to extensively redesign their storage architecture. After seeking RFQ's from many network-attached storage (NAS) and storage area network (SAN) vendors, MegaCorp selected EZAP's 3825 based on the salesman's promises of simplicity of installation, reliable operation and future expansion capabilities. This last was key for us as our company has experienced a huge growth phase.
In addition to providing timely, mission-critical product to our Armed Forces, regulations require MegaCorp to maintain copious manufacturing records on each item produced under contract. This data comes from a variety of sources and departments, each of which has its own operational procedures and network. As a result, we must gather and store information from data stores that do not necessarily share operating systems, applications or compatible hardware connectivity. In our vendor's terminology, the EZAP system would provide the "glue" to consolidate our storage effectively.
MegaCorp Purchasing placed the order at the end of the vendor's quarter to extract the best deal possible from EZAP's sales force, saving us more than 15%. This tactic kept us easily under budget. Of course, this delay also forced the storage administrators to scramble to meet the mandated deadline for installation. Plus no one had foreseen that migrating the data from direct-attach storage arrays to the new solution would required the Oracle DBA's to change their programming logic slightly. This led to higher than expected programming costs for the project and delays in the manufacturing line due to lost data not getting into the purchasing queue. This slight programming mismatch caused product not to ship to the Department of Defense (DoD). We have been assured that this only contributed to slight delays in our troops actions on the front lines of the war. Additionally, it turns out that we needed the OA2-Patch ($25,000) to ensure continued reliability of our Oracle data store.
There was one other small snag. Upon delivery of the EZAP 3825, we discovered that the equipment did not work with our company standard switches. The EZAP installation engineers would be unable to install the equipment until after we ordered and received the proper (their recommended) switches. Coincidentally, three months before, our CIO who authorized the purchase of the EZAP solution took a position with EZAP. It was he who subsequently decided that the new to market JumboTronic 7448 was ideal for EZAP's switching platform. Given their new instruction, our purchasing department followed procedure and waited until the end of JumboTronic's quarter to extract the best possible deal on the switches and then ordered them on a rush basis because our deadline was imminent.
Upon the arrival of the 7448 switches we rescheduled the EZAP installation. They said they would arrive within 30 days and that it should only take a day or two for the installation. We explained very carefully that we had been out of production for nearly 90 days already and it was important to our troops that we get things up quickly. The EZAP engineers understood our quandary and in an Act of Patriotism they arrived two days later for a weekend installation.
Unfortunately, the EZAP engineers had never used JumboTronic switches and were not able to get JumboTronic engineers on the phone over the weekend. However, on Monday morning JumboTronic and EZAP were able to get the system up and running. Over the next few days, we were able to replicate and store certain types of data. Write performance was not as expected, but by the following weekend we learned from EZAP that the write performance problem was directly related to our software, not the EZAP system. EZAP and JumboTronic declared the problem solved and left.
The following Monday, DoD cancelled our contract for non-performance and most of our production staff received their pink slips. Since our write requirements were, as a result, much smaller after the layoff and loss of contract, our EZAP solution is working just fine for our current requirements. We would recommend an EZAP solution for any company that is shrinking its workforce while needing a large store of historical data.About the author
Mike Linett is President of Zerowait Corporation