by Wayne Labs, Senior Technical Editor
January 12, 2010
Renting software may be a cost-effective approach compared to purchasing it, but performing due diligence is critical.
Some of us remember the days of the IBM 3090 or even earlier IBM 360 mainframe computers. Whether or not these computers or other mainframes existed on-premises, the software applications residing on them usually could not be purchased. Users rented the software for a monthly fee, and the computer and/or service company maintained the equipment, operating system and software.
Software as a service (SaaS) borrows on the concept of renting software; however, the delivery model has changed. Rather than having tons of equipment located on-premises or renting time on a shared computer system, users rent the software applications they need without having to invest in the infrastructure to run them. In most cases, all users need is an Internet connection and a Web browser on a standard computer and/or network.
With the SaaS model, food and beverage processors need not be concerned about supporting hardware, databases, operating systems, maintenance, upgrades, backups and so forth. This is provided off site, and most SaaS providers have more than one location to house the supporting infrastructure. If a disaster happens at one site, hot backed-up data will be available at another site. Several rental models exist depending on the SaaS supplier, but one theoretical aim of this delivery method is to allow small- and medium-sized businesses access to the same tools as the larger processors.
Sound too good to be true? Since this technology is relatively new, many suppliers are still feeling their way in developing SaaS versions of existing software applications. Pricing rental fees depend on many factors: How many users will be logged onto the system? How many applications will be needed? What kind of throughput is expected?
Processors no doubt will have questions about SaaS, and software suppliers in many cases are just as curious about investigating this model. Will it actually work? Is this technology still too far ahead of the curve to be practical? Who pays for what? Is it secure? Is it reliable? These are just some of the questions processors should consider before making any major changes.
This is not an easy question to answer. The fast answer, according to Deacom President Jay Deakins, is all applications can lend themselves to the SaaS format for food and beverage processors. Of all these applications, customer relationship management (CRM) has been the most widely accepted at this time. This can pose problems, however, because some processors are working with separate systems that aren’t integrated with their ERP software. Deakins says processors tend to develop workarounds, which reduce control over business processes like lot tracking and QA/QC. With non-integrated systems, duplicate or redundant data entry can affect overall data integrity. There is difficulty in maintaining multiple systems and their connection points, and there is more complexity in training users on multiple systems.
There are several reasons why processors have been reticent to accept ERP systems running on the SaaS model, says Deakins. First, not all like the idea that their data resides on someone else’s server, where there could be commingling of data. Second, the unique requirements of a food or beverage processor make ERP a much broader application than CRM, and so far the SaaS model seems to work well for very simple applications where customization isn’t needed. Third, processors need to ask if there is a fundamental cost savings to using the SaaS model.
According to Patrick Fetterman, vice president of marketing, at Plex Systems. “There is a common misconception that only department-specific software, such as CRM, is appropriate for the SaaS model. In fact, the more mission critical the application, the more companies should consider the SaaS model,” he adds.
Processors too often overspend on the software itself, only to skimp on maintenance and upgrades that SaaS suppliers provide automatically, Fetterman says. “Some recent news coverage has suggested that ERP systems will be the last to make the move to SaaS,” he says. If all the functions are in the SaaS ERP to support food and beverage processors, Fetterman says the SaaS model will be superior to on-premises software.
For processors with ancient software systems, SaaS-based ERP makes sense. “When I first joined the company, I found out all our US operations ran on a DOS-based version of an MRP system,” says Ron Zilkowski, Cuisine Solutions chief financial officer. “It would cost us a couple hundred thousand dollars to upgrade to the most recent version. And we were out of seat licenses, so we would need to buy more seats and invest another couple hundred thousand dollars in new equipment,” he added.
Zilkowski knew he couldn’t justify the upgrades for equipment, software and related items if it meant continuing business as usual. “We needed more than just an upgrade. We needed an integrated solution that allowed us to introduce technology into the plant,” he adds.
Cuisine Solutions began implementing Plex Online’s core modules of accounts receivable, finance, shipping, receiving, purchasing and HR in its Virginia operations. The modules were implemented within three months, and the finance module was simultaneously implemented in the processor’s facilities in France. Work then began on implementing an on-line production module, which was customized with recipe measurements that allow every work order to be measured out per recipe ahead of time. Following the customization, the production module was launched early in 2009.
With the SaaS-based system in place, Cuisine Solutions manages 400 different food products; has access to real-time production data; automates production, inventory and distribution, eliminating manual intervention once needed to meet USDA and FDA mandates; meets health and safety mandates by adding unique product identifiers to raw materials containing food allergens; and meets Sarbanes/Oxley compliance, tracking production costs and productivity with nearly 100% accuracy.
While SaaS is catching on in CRM, HRM (human relationship management), ERP and compliance areas, it’s been a little slow gaining acceptance in supply chain management (SCM), says David Cahn, CDC Software vice president of product strategy. “In the SCM arena, we see the SaaS offerings growing mainly in the planning aspects, while the supply chain execution arenas (warehouse and transportation management systems) are still either hosted or on-premise deployments,” says Cahn. However, many organizations would like to use a SaaS-based customer order management or procurement solution to drive the execution process or integrate to the back end-fulfillment and replenishment solutions. At the MES level, however, Cahn still sees primarily on-premise solutions.
How close to the process?
With the MES function closer to the controls level comes the question: just how close to the controls will SaaS provide useful solutions? According to Johann Heydenrych, itelligence Group director of industry solutions, “Ultimately, I believe that any application will be able to run in the SaaS environment. It comes down to needs and application. How close to process controls? That will take a while.” The problem with a SaaS-based MES is the software will have to talk to PLCs and equipment on the shop floor, which leads to performance and integration issues.
Although there has been a significant increase in bandwidth of the Internet, insufficient bandwidth to support the amount of data and throughput that’s required at the controls level remains an issue in many locations.
“We believe the challenge is that the closer one gets to the process control integration, the further one moves from a SaaS solution being adopted,” says Cahn. He believes this for a couple of reasons. One is that processors are not yet comfortable with moving secure plant data outside their own internal firewalls. The other, more perplexing issue for software developers is the amount of customization required to integrate software and systems closer to the controls adds to the cost of developing an effective system, and someone has to pay for this integration.
Nevertheless, Staffan Akerstrom, EPS Corp. chief operations officer, says SaaS systems become more valuable the closer they are tied to these control systems. “If the SaaS vendor writes an application to tie into a specific process control system, then existing customers of that system will have a very compelling reason to purchase from that SaaS vendor,” adds Akerstrom.
Suppliers such as EPS and Vigilistics have actually added hardware to the fray to accomplish real-time data collection for specific purposes. The hardware also acts as a buffer in case the Internet connection is lost between the SaaS supplier and the processor. EPS provides an energy management solution that places energy monitors throughout a plant on critical devices to provide the plant with an ongoing picture of energy usage, and ways to shift loads in real time, to conserve energy and costs.
Vigilistics, according to Craig Nelson, founder and chief operating officer, uses a ControLogix PLC as a data collector and buffer to retrieve data from plant floor processes and systems. The data helps processors gain manufacturing intelligence about their processes. His system can connect with CIP systems to determine water usage, verify process parameters and supply proof to regulatory agencies that CIP was performed properly. The system can also be used in dairies to calculate loss of milk and dairy products, thereby calculating process efficiencies.
Manufacturing intelligence and monitoring performance capabilities using collected data as illustrated above are two good applications that make sense in a SaaS system, says Cahn.
Rob McGreevy, Wonderware vice president, platforms and applications, believes that any application that is data-management-centric is well-suited to the SaaS model. Since most plant data today resides in SQL historians, redirecting some of this data to a multi-tenant cloud space or a shared memory repository is not that big of a stretch. With a server (historian) acting as a buffer between plant and the SaaS, even if the SaaS is disconnected for a while, the plant goes on and the SaaS is updated when the connection is reinstated—much the same way hosted ERP systems work with plant floor systems today.
What about track-and-trace and Sarbanes?
While Cahn doesn’t see SaaS being better suited for track-and-trace or staying compliant with Sarbanes-Oxley than on-premise systems, he does think the decision could be based on the processor and the complexity of its environment.
Both track-and-trace and Sarbanes-Oxley put an enormous record-keeping burden on processors, says Fetterman. The amount of data recorded on a daily basis—with full audit trails and accompanying records—can quickly grow out of control, far beyond the capacity for many processors to handle. SaaS applications remove the burden of keeping up with storage requirements, offering practically unlimited capacity to manufacturers. Additionally, emergencies that require urgent use of track-and-trace rarely happen in the middle of a working day, when all appropriate personnel are onsite at the processing facility; a SaaS application brings essential data to the fingertips of any employee. If the employee can get to the Internet, he or she can initiate a track-and-trace, and if necessary, quarantine shipments or issue recalls, says Fetterman.
That same employee can also make use of FDA’s Reportable Food Registry, which is in essence a real-time SaaS that allows food processors to report a potentially contaminated product. With this information, the FDA portal allows quick dissemination of knowledge of where that product has been distributed, making it possible to stop bad product before it gets to the end user.
What about integration and security?
Much has already been said about integration, but for small processors who began their operations with basic business applications but soon grow out of them, SaaS might provide the solution. The Home Baked Cookie Company near Melbourne, Australia, operated on two incompatible systems—a financial application and a CRM system. Data had to be continually entered into both, creating errors and losing valuable intelligence. After considering several options, the bakery settled on NetSuite, a Web-based SaaS that integrated both the CRM and financials and eliminated double entries. Since it’s Web-based, company personnel have access to the data anywhere in the world at any time.
But not everyone has a warm, fuzzy feeling about security when it comes to Internet-based applications. Heydenrych says the current tools—encryption, firewalls and VPNs—have established SaaS as a secure technology, and it will only get better as large banks and corporations keep pushing the envelope for even tighter security. Today, he says, if a hacker passes through a firewall at a bank, it’s not a technology issue as much as it’s business-specific issue. And if there’s concern for corporate spying by grabbing someone else’s data, it’s not likely to happen with the way systems are partitioned today.
But, could sharing certain data be a good thing? Nelson contends that SaaS technology can be used to help processors compare themselves with others on certain key performance indicators. For example, Nelson’s company makes basic wash times and amounts of water used available to several competing dairies that have signed onto his SaaS. Of four participating dairies, Nelson said water usage to clean the same size vessel varied from the worst case at 3,500 gallons for one dairy, and the best used only 728 gallons with the other dairies falling in between. When the laggard dairy can see that it used more than four times the water as the best-in-class, it knows that it has some homework to do. At this point, however, the dairy is on its own to learn how to stop wasting water. Company-confidential information is not disclosed.
What about reliability?
Engineers involved in communications for emergency services expect 99.999% (5.25 minutes downtime per year) reliability from communication channels. While standard SaaS offerings may promise less reliability, say 99.5% (43.8 hours downtime) to 99.9% (8.76 hours downtime), suppliers will offer better reliability if processors want to pay for it. While the plant will go on running, processors will need to decide on how many hours of outage a year they can bear.
More than one factor affects reliability. The uptime quoted will usually be that of the SaaS provider. NetSuite makes their uptime history readily available for everyone to see on the Web.
Just like cable TV and electricity, a processor’s connection to a SaaS depends on the reliability of an Internet connection. Deakins warns, “The Internet can be as reliable as you make it. [Processors] can guarantee reliability through redundancy, redundancy, redundancy. An appropriate level of cost depends on your definition of appropriate level of reliability.”
To ensure reliable connection to the Internet, many processors have used two different providers where possible. Heydenrych suggests backing up either with satellite communications.What about Chapter 11?
When tech companies were riding high, processors never expected their software or a SaaS supplier to go belly-up. But it can happen, and it has happened in the past. Processors must have contingency plans. Cahn suggests that the contract (called a service level agreement or SLA) cover escrow, business continuity and disaster recovery issues. In addition, it’s imperative that processors determine the viability of the vendor they’re selecting.
Deakins says processors should question the provider on backup plans should it go out of business. There should be an article in the SLA that discusses alternative solutions in case the worst happens.
A well-run SaaS vendor should have a way for customers to retrieve data in a common format so they can successfully import it into an alternative system, says Akerstrom. “When selecting a SaaS vendor,” he says, “find out if there is a method to periodically get a local copy of your data.”
Even with a SaaS vendor who’s doing the right things, a processor could create some of the same issues it’s trying to avoid by backing up data locally: redundant systems and files, duplicate or redundant data entry, workarounds, and maintenance difficulties. For example, relates Deakins, users can keep key data, but where and how? Does that mean keeping Excel files of all recipes and batch tickets?
Fetterman says users always own their data, and this should be spelled out in the SLA. It’s extremely rare for a software company to go out of business over night. He doesn’t recommend that his users back up their data locally because Plex Systems has two data centers located hundreds of miles apart, and they use a redundant infrastructure with replicated data off-site. This allows the company to achieve a recovery point objective and recovery time objective of two hours.
SaaS is a delivery method for software—not software itself. So it behooves processors to make sure they follow the same directives for signing onto a SaaS as they would any software supplier. The old axiom still applies: Let the buyer beware.
For more information:
Rob McGreevy, Wonderware, 949-727-3200, email@example.com
Jay Deakins, Deacom, 610-971-2278
Patrick Fetterman, Plex Systems, Inc, 248-391-8001, firstname.lastname@example.org
David Cahn, CDC Software, 678-259-8620
Craig Nelson, Vigilistics, 949-900-8380, email@example.com
Staffan Akerstrom, EPS Corp, 866-377-7834, firstname.lastname@example.org
Johann Heydenrych, itelligence, 513-956-2000, email@example.com
What does SaaS cost?
According to Staffan Akerstrom of EPS Corp., one of the most obvious advantages is the elimination of costs normally associated with installing and maintaining a system onsite. With a SaaS application, the customer saves by eliminating the up-front costs of hardware in the way of servers, additional IT staff to manage the software, and ongoing resources for maintenance and upgrades.
Cost comparisons between on-premise systems and SaaS can be somewhat complicated by unplanned costs. According to David Cahn of COC Software, the costs not typically encountered are the integration to the back-end systems and/or modifying a manufacturer’s business processes to conform to off-the-shelf SaaS solutions when they can’t be customized beyond their basic configuration.
Plex System’s Patrick Fetterman doesn’t make one-to-one cost comparisons between SaaS and on-premise systems because systems vary so widely among processors. Although, a SaaS solution is usually cheaper in year one and two and probably comparable in year three and beyond that, it depends on the depreciation schedule for hardware, planned upgrade cycles, etc. Additionally, Fetterman says the lower TCO (total cost of ownership) numbers promulgated by many SaaS vendors assume that customers will eliminate IT jobs. “We have found that to be the case only in rare instances,” he says. Instead, it is the reallocation of resources away from low-value functions, such as infrastructure maintenance and upgrades, toward high-value functions such as business process analysis that is a hidden benefit of the SaaS model.
In general, the greater the usage, the greater the cost, and some processors may especially benefit. According to Rob McGreevy of Wonderware, contract manufacturers who typically have busy and not-so-busy periods will use the software less in the slack times, so while there still may be a monthly fee, the usage fee will be very low—just like an electric meter. In the busy times with more usage, the fees pick up. Another advantage to the SaaS model, he says, is that it’s a different budget; that is, SaaS falls under recurring operations expenses and is not a capital expenditure.