In principle, there is no real reason why not. Having an application in the cloud raises different issues in terms of data integration, security, in addition to what might be considered more 'usual' implementation issues around business processes and training.

In some senses, one would need to understand the motivation behind the question to get to the bottom of particular concerns. Both the applications mentioned have strong reputations in this field. Contact me for a short discussion prior to paid consultation to work out whether I can help

Regards, Noel

I think the industry your customer operates in and the nature of their ERP requirements will have a big impact on this answer. One of the least appreciated—and often most strategic—considerations is multi-tenancy. The "Cloud" has already been unsuccessfully tried for ERP (and other apps) in the dot.com era. Companies like Corio, USinternetworking and others touted great benefits to companies willing to host their enterprise software. However, without multi-tenancy (the ability to run multiple customers--and segment the data--on a single code line) hosting ERP often ends up being more expensive than on-premise. In that sense, only the largest companies seeking to outsource their entire IT function would justify a largely equivalent spend. (Often for reasons other than cost!) Without a compelling economic justification, hosting never became the rage many thought it would and many of the ASP companies went quietly into the night. At least as far as widespread “hosting” was concerned.

However, if you can standardize an application in a way that multiple companies can use the same instance/code line, you can have a durable SaaS model. Durable in that customers will be incented to buy it and vendors can make enough money to keep the lights on. That's why HR makes so much sense to run in the cloud (processing a W-9 is the same for everyone). CRM works because it is basically a standardized contact manager with a bunch of configurations attached to it. Financials should work if the market overcomes the security concerns (see previous responder's issues). However, when it comes to applications where there are no standard practices—and I’m not talking about ”marketing” best practices; I’m talking about legitimate standard processes like applying for a social security card—multi-tenancy doesn’t usually work. Especially in complex, multi-“flavor” areas like manufacturing, distribution, supply chain, maintenance et al.

I suspect a Cloud fan will chime in and say “But there are Cloud companies successfully doing financials and manufacturing!” True, but a $1B slice of a $20B business does not constitute a fait accompli. I still haven’t seen a manufacturing product that can support discrete, flow, process, lean, ETO, CTO and the countless iterations that are reflected in customer’s actually processes in single instance. Until that happens—and the objections in the previous email are overcome—the cloud will not be how most ERP systems are deployed. While customers may not care about this at first glance, it becomes critical over the product lifecycle because it determines vendor investment, the size of the partner community, support infrastructure and many other things that will impact your customer’s satisfaction with their ERP solution.

Another thing you should consider is the suite vs. best-of-breed discussion. Enterprise application software essentially was established around specialist applications. Companies built financials, manufacturing (even sub-iterations like job shops, process, CTO et al), supply chain, CRM, warehouse management, HR etc. Ultimately, buyers got tired of knitting all these applications together and the trend moved in favor of integrated suites. (At least in areas that ERP vendors could provide equivalent functionality.) Today, the idea of pulling out HR or CRM and running it in the cloud while the ERP system runs on premise merely replicates a history we’ve already experienced. As soon as the individual departments get their application areas sorted out, the COMPANY will want to get it integrated. So, does your customer really want to implement a couple of cloud apps that will have to be converted down the road? Or, if you believe that the more complex apps will ultimately be “figured out”, do you want to convert your ERP? (Before you answer that make sure to check peers and ask about converting historical data from one ERP application to another. Especially in areas where there are lots of transactions and costs involved.)

I believe application software has largely delivered the majority of available benefits—how many times can we implement software to reduce invoice processing labor?—and from now on it will be about maximizing availability, lowering cost and accessing information. None of which can easily be achieved if each department “does its own thing”. (Of course, the Holy Grail of “application interface standards” promises to overcome that, but, that’s another experience history we’ve all lived through too many times to know better…)

You may think I believe this because I work for an ERP vendor. Actually, I spent about 3/4s of my 25+ years in tech in “best of breed” and got into ERP because it became clear that application software was becoming a commodity. Once a customer finishes implementing its first generation of just about any application, it’s going to be less about features and functions and more about cost, information sharing, partner ecosystems etc. And, the suites win hands down over point vendors on all of those fronts.

Disclaimer
The opinions reflected in this post are mine alone and do not reflect the views or intentions of Oracle Corp.

1) Rather than look at it as an all-or-nothing situaition, consider the customer profile and what it's business requires. SaaS (or Cloud) or on-premise differs only by the location of the software. If you think of how BPOs, Regional Service Centres, etc work, interfaces between software being located in different locations has been tried and tested.
2) Even with ERP, most customers do not use every single product available in an ERP suite.
3) There are many more vendors out there besides SAP and Netsuite. Oracle, Sage, Invor, are namely a few. Some of these are proper suites (ie built to work as a suite) whereas others came about through acquiring different modules. It doesn't mean one is better than other but depends on how tightly woven your customer processes are.

These are but a few considerations. Let me know if you have further questions.

ERP in a SaaS set-up is something that will pick up over the next few years and become mainstream in my opinion. All the major players in the market are either working on or have some SaaS product in the running.

Will this work for your client well I do not know this will in essence depend on the client itself. Typically small and medium sized companies are somewhat better suited for a SaaS model however this is not a guarantee of success by a long shot. In my experience if the client is willing to be flexible on their side and willing to make the necessary compromises they can be successful. There are a few questions that need to be answered to really make an educated guess - 1 - what do they want to achieve - 2 - are they flexible on their processes - 3 - how standardized is the client - 4 - how mature is the company, the industry and their clients.

Having worked for a leading ERP company myself I know how things are on the vendor side promises are made quickly and easily but when the poor guys form the consulting arm start working they are faced with open questions which have been avoided in order to make the sale happen. At the end of the day I would conclude that if your client can manage an compromise on its processes it is doable.