It is almost a given that going the SaaS route for enterprise software is the best way to go. In the case of document management packages, whether you should or shouldn’t really depends on what you need. To assess that, there are a few things that need to be considered.
In a recent paper from Cabinet NG (news, site) on whether enterprises should consider SaaS or on-premise,Jon Clark outlined some of the things enterprises need to look at before committing to anything.
In the case of Cabinet NG, like quite a number of vendors in the space, it provides both SaaS and on-premise document management software, so whether Clark, who is VP of Sales at Cabinet NG, comes down on one side of the argument or the other, doesn’t matter.
Investing in Document Management
The traditional route for enterprises buying document management is to buy the software after looking at its IT infrastructure, its budget and business requirements, and install the software on the enterprise servers and desktops.
With SaaS, a new alternative is offered that,on the face of it, looks like it might be considerably cheaper, easier to manage, require less maintenance and less storage space than on-premise deployments.
There are five areas that need to be considered first, with subsidiary issues after. They include:
In much of the discussion that has gone on around SaaS, it is taken as a given that SaaS will necessarily be cheaper than an on-premise deployment.
The assumption that SaaS saves enterprises money is based on a short-term view of the issue based on the fact that the initial outlay for SaaS is considerably less than it is for on-premise. But there a number of things that need to be considered here.
For on-premise deployments you need to consider server requirements and whether existing servers will be able to cope with a new application.
While many DM packages will run on MS Windows Server, you still have to ensure that you have the required version to run the application, consider whether the new application requires a dedicated server, or whether it can be located alongside other applications, whether you need server updates or even new servers. You also need to check whether the OS on your workstations supports the new package.
Assuming that your servers can support the new application, there are still maintenance costs to consider, Clark says. There are costs associated with managing internal servers, backing up data and updating software.
Clark says that the cost of updating software runs at between 15% and 25% annually of the original purchase price of the software, while ongoing support -- although not essential -- is still considered desirable.
With SaaS, these issues are all covered by a monthly fee. Taking an example of a 10-user system over a five year period, Clark offers the following scenario:
- Initial consulting and set up for on-premise and SaaS is US$ 2,000.
- Purchase price for on-premise e is $1,000 per user including maintenance and support calculated at 20% starting year 2.
- If a new server is required, add another US $5,000 for this example.
- SaaS pricing for the example is US$ 90 per month per user.
- Internal IT personnel cost are not included in this example.
In this example, SaaS, as the chart below shows, works out more expensive. However, it is for illustration purposes only, and there may be other costs included in the on-premise version.
Document management: on-premise v SaaS
With SaaS, the vendor does everything, including server preparation, configuration and software initialization, with the enterprise only having to agree the terms.
Deployment on-premise usually requires help from the IT department, if your company has one, and, if not, you’ll have to pay to get someone in.
With on-premise deployments, it may be easier to integrate your document management software with existing applications as it is generally easier to integrate applications that are operating on the same network.
This is changing, though, and we have seen over the past number of months the release of connectors and bridges that enable enterprises to connect their on-premise applications with hosted applications.
The bottom line is that there should be no problems, even at this stage, with integration between SaaS and on-premise, but how integration between two or more applications on different SaaS platforms will work out has yet to be clarified.
In both internal and SaaS deployments, it is generally considered good practice to have a centralized repository where all documents can be located with all the security measures available.
With SaaS, this is an issue for the hosting company, but for on-premise, it is an issue for the enterprise. It is likely the hosting company has more resources to spend on security.
The result is that, for SaaS vendors, it is easier to apply several security policies to the repository.
However, there are compliance issues here, too, notably where data stored on a farm located outside the geographical boundaries the client enterprise is located in will be in compliance with local regulations.
This is still a battle that has to be fought and there are no real answers yet, but it is something that potential SaaS clients need to ask their vendor before investing.
A related issue is disaster recovery. By definition, having data backed up off site will increase chances of recovering from data loss. With on-premise, regular back-ups will have to be done and a recovery strategy needs to be put in place.
Finally, it may be obvious, but it needs to be considered. How easy will it be to get documents out of the system you are using? What happens if you wish to change systems, and will you be able to move your data from an old system to a new system? Is your data stored in native or proprietary format to enable that move?
5. Investment priorities
This relates not only to document management, but to just about every other kind of application too. For companies that are trying to save on upfront capital investment, the SaaS approach is clearly better -- keeping in mind the above example that shows it might be more costly in the long term.
More-established companies may have developed IT competency over time and they understand that deploying software internally helps them better leverage those resources.
So what can be concluded from this? Not a lot, except that the options to go one way or the other exist so that either option is equally valid. It basically comes back to needs assessment and planning.
The bottom line is that, before even starting to look at deployment, enterprises need to weigh both sides of the equation. Obvious as that may be, there is an underlying assumption that SaaS is cheaper and easier to deploy -- an assumption that is not necessarily borne out by the facts.
If anything can be drawn from this, it is that companies should not be bullied into investing in SaaS, just because the initial costs look good; what’s good today may be rotten by tomorrow and ultimately force a rethink of a strategy that should have been considered in the first place.