It was one of those interesting cases of implementations. Unknowingly or led by circumstances the client had embarked on a implementation project where they had chosen a product that they thought meets their needs only to realize there were gaping holes in the implementation strategy. I cannot seriously blame the client for taking the route they took. They had two or maybe three products within the same product suite all which could fit the bill to varying degrees. And I am not talking about Oracle E-Business Suite, PeopleSoft, JD Edwards. These are products all within Oracle E-Business Suite. So naturally it was easy to get misled. Going with the product they did, they were confronted with the proverbial “this product does not meet our needs so we will need to customize” dilemma. And that is when I got involved with this project.

With the goal of least customization and identifying the best fit product, I started analyzing their need. As I understood their need better and started mapping it to the products that were available, one thing became very apparent. The documentation that came with the product was not in any way guiding the customers in making the best choice. To be fair they do not claim to purport that. TheUsers Guide and Implementation Guide never got into the scenarios customers typically have. Instead they are designed to give information on what the product does and leave the customers to their own wits to figure out how to adapt it to their businesses. I  have never been a believer in the usefulness of software product documentation. In my opinion it(the product documentation) is something product companies do because they have to, for every product every release. There is scant attention paid to their utility and neither is there any feedback loop to adjust it to meet the requirements. Considering the flux in product footprint thanks to all the patches, updates, the manuals released by product companies quickly get outdated. More importantly, despite the edict of RTFM, I don’t know of many who actually read the manuals or have the time to read those large documents.

Now having said that, what could a software product company do better cater to the needs of their customers?

Here are 5 strategies to adopt to provide useful product usage and implementation information – coming from real life cases.

1. The software companies should voluntarily create knowledge based communities around the product and use that to share the product information and foster knowledge sharing amongst customers to share their experiences. Collectively all the contributors stand to benefit from this crowd-sourced effort.
2. These communities should have focused knowledge bases for areas like Product Training, implementation strategies, industry specific best practices, Day-in-a-life of a user narrations. Most companies consider their job done by just throwing a Q&A forum with absolutely no involvement from Product teams.
3. Conduct periodic web-based Open Houses for Products where new customers can listen and discuss things with the product teams. This will help customers get to hear from horse’s mouth and not just from some over-zealous me-too system integrator claiming expertise.
4. Provide opportunities for  “Review-with-the-Product Team” sessions with the product where clients can review their would-be implementation strategies with the product team to ensure they are not pursuing a wrong path.
5. Maintain and Manage a product specific wiki for product documentation and have customers, System Integrators, consultants update it and keep it up to date with the product usage and administration information.

Would love to hear other ideas in this area that has worked for your product companies.

All in all I was happy that I ended up helping customer from realizing all the benefits of a product we thought it would provide and did it while not needing elaborate customization or taking a work around.

The first mention of SaaS application, as a possible technology choice, is sure to make your IT and the CFO/Risk officer perky. A single breach and the consequential data loss can cost companies millions of dollars in penalties/damages. This does not include the unquantifiable damage to the company’s reputation. Regulatory mandates like Sarbanes Oxley (SOX)-404, HIPAA and PCI-DSS have strict requirements on how customer, financial, employee, partner data should be governed and protected. Moving to a SaaS application does not preclude you, the company, from those responsibilities.

Given that, how does a company considering a SaaS application conduct a good assessment of the risks involved before jumping in ?

Let us start with the premise.

Companies store data in servers and databases each kept from unauthorized users under strict access control. Additionally, the data itself is regulated by who can see what and what, if any, operations can they perform on the data. The operations could be manual or via an application that manages it.

In SaaS, your data will reside in the databases and servers owned by the service provider. If your SaaS vendor happens to use third party cloud based infrastructure services then your data might reside in the data center of the Cloud Infrastructure provider. As a customer, you get to add, update, delete data from within the SaaS application, subject to the business rules and security policies implemented in the application. Unlike in the case of an on-premise application, your IT organization will not retain access to the servers, databases, storage, backups and the network. That responsibility would now rest with the service provider.

So, then is my data safe?

In order to safeguard your data that would reside in the service provider’s database, here are somethings, you must ask the software vendor as part of the RFP/evaluation process.

1. Keep the bad guys away: Given that the vendor’s data center is where all your critical data resides, it is imperative that you understand the physical perimeter security they have in place for their data center. Reviewing the process in place to govern who gets access them and how is the trail of access managed is also critical.
2. Can they come in through the internet?: Knowledge of existence of a particular service and its location is not a secret. Everyone knows how to access Salesforce.com or Netsuite. You go to the vendor’s site and look for the Customer Login or Client Login button/tab. Given that what are some of the processes vendor has in place for preventing Denial of Service Attacks, Spoofing (remember the Salesforce.com incident!).
3. Authentication/Sign-On: Most SaaS vendors these days support and delegate Sign-On using SAML(Security Assertion Markup Language) or  OAuth standards. This will allow you to configure the entry point to the application/data for your company through a trusted site – like your enterprise portal which is accessed through VPN. With such a configuration you are now essentially shutting off public access to your share of the application and in-charge of  provisioning and revocation of access from your corporate  Single Sign-On identity management.
4. Encryption Policies: Making data secure in the data center is the first step. Another challenge is to make sure data is safe in-transit. As you access data from the application, data is traveling over the wire back and forth. Having strong encryption of data on the wire is paramount. 128bit SSL encryption is common these days, but some vendors are now starting to provide stronger encryption. Check what your vendor supports. In fact, while you are at it also check what they support for the on-disk encryption so your data in storage and backups are encrypted.
5. Test the Tester:Verify the quality process being used to conduct security tests. Specifically check for tests conducted to identify vulnerabilities due to Cross-site Scripting, Cross-site Request Forgery, Cookie Management, Mass Update of Access Control, iFrame embedding, URL manipulation, Overzealous Logging.
6. Multi-tenancy/Data Slicing: Multi-tenancy provides the economies of scale that SaaS vendors seek, to provide low subscription costs. But this also means your data will be co-mingled with other customers in a single database. With all the rapid product development cycles, if the tenancy data separation architecture is not robust, this might expose your data to your competitors or fellow tenants. So it is important to understand the way data separation is implemented.  Have your architects verify the  architecture to understand the multi-tenancy architecture better. Specifically check for the quality tests conducted to prevent SQL Injection. Code flaws that allow SQL Injection would end up allowing access to wrong slice of data.
7. Audit Trail: Discuss the audit trail functionality in the application. Given that you will be doing a trial of the application prior to making a decision, verify the same. While excessive audit logging could hinder the functioning of the application, you as a customer, should have the ability to enable and disable logging for specific activities/events in the application. Specifically, I would look for audit trail capabilities around – user login/logouts, access control changes, password changes, data export/import features, running reports, access of critical areas like Credit Card information, employee details, SSN etc.
8. Network Security: Network weakness is one of common ways for malicious users to get access to information. Typical issues found in networks would be improper SSL configuration, lack of robust session management and open ports. Once the hacker gets access, they can hijack active sessions and gain access to user credentials and critical information.
9. Backup/Recovery: In the quest for 99.99% availability, it is conceivable that vendors build redundancy and replicate data just in case of a crash. This means copies of your data could be residing in multiple data centers, in some case in multiple geographies. So if you are in a regulated industry and comply to data security guidelines that prevent your data being hosted outside the country or a certain geography, you should get that clarified upfront.
10. Certification: First of, ask for a SAS-70 Type II audit certificate, preferably conducted in the last 6 months and ensure it is an ongoing practice, every 6-12 months. Don’t think of this as insurance policy. SAS-70 is a generalist guideline and it is not a mandate. The certification, by itself, does not guarantee that everything is perfect. You will still need to go through the controls that were evaluated to provide that certification. The web is littered with instances where companies, supposedly certified, having data breaches. If the application you are using include managing Credit Cards or Health Care data then you should also ask for the specific certification like PCI-DSS and HIPAA.
11. Preventive Measures: As part of your evaluation process, request for the documented architecture and policies for Intrusion Detection System (IDS) and Intrusion Prevention Systems (IPS). In addition, also ask for a recent run report of the IDS system – it might be difficult to get this but would not hurt asking. Review this with your corporate security team and ensure they meet your corporate mandate. If you are a small business and do not have a corporate IT security team, hire a CISA certified consultant and review the report with them. Even better, insist on a penetration test to be conducted by your team. You can hire third party services or a third party software to conduct a round of penetration testing.
12. Governance: Request for a change management and access management report of who in the vendor’s organization has access to the data. The idea here is not to check the specific individuals but how rigorous the process is. If the vendor has SAS-70 Type II certification, this is something they would have documented already. With the dynamic environment, in which most SaaS vendors operate, there will be a lot of churn in the people. It is important to make sure the vendor has process in place to ensure their past employees, contractors do not retain access after leaving the organization.
13. Understand the data management: To provide 99.9%, almost interrupted, high performance service levels, SaaS vendors will end up replicating your data (or backing up) to multiple data centers. It is important to understand that process and access control around the replicated data.

This should give you a good set of upfront checks before you decide on a SaaS vendor. Remember, Security is not a one time thing. It is a ongoing process. You keep at it regularly – Measure, Monitor and Adapt, and only then can you be sure you data is secure.

Portability/Switching Cost

With SaaS you have the ability to switch to another vendor if your SaaS vendor measure up  to their commitments in SLA or is at risk of becoming defunct, you have the opportunity to switch. No infrastructure, resource investment overhangs. But don’t expect for switching to be as easy as switching your cellphone service. You still have the all important data residing with the vendor. With a little bit of smarts during initial contract negotiation, might get you your data free or for a nominal cost, you still have to ensure that your data is deleted clean from the vendor’s database and servers after you leave. A breach at your previous vendor and learning that your old data was part of the data loss is not something you would want to hear.

Bake it into the Contract

To make this a IT priority and a scheduled activity, here are terms you should incorporate into your Contract.

1. Have your vendor furnish a SAS-70 Type II certificate every 6 months or a year (depending on your comfort level)
2. Conduct a penetration testing exercise every 4-6 months from your end. If you are happy with the third party agency employed by the vendor to conduct a penetration test then save yourself some money and ask for that report to be made available to you. Vendors like Qualys provide you with a service that you can avail for conducting these tests.
3. Have your vendor furnish IDS/IPS logs to be available upon request or through the Self-Service Administration portal.

Parting Shot

You know I am big SaaS fan, so now for you SaaS naysayers out there – chew on this.

If it makes you feel any better, these are the very same checks and processes that your internal IT has to follow. So not going with SaaS does not preclude you from this process. With SaaS, since this is asked of the vendor and goes through the scrutiny of many customers like you, the chances are their process would be much more hardened resulting in your data being more safer. As un-comforting as it is the last I checked, the majority of data thefts happened from the inside of an enterprise as this survey done by a UK firm states – 33% of employees would steal data .

In the several years that I have worked in the on-premise enterprise software world, I have seen many software implementations go awry with thousands of dollars in ballooning cost spent on implementations. Customers never see the elusive ROI until many years into the implementation. By then they are so deep into upgrades, manpower turnover, shrinking IT budgets, IT organizational fiefdom, you get the picture. ROI is the last thing on their mind – keeping the lights on becomes their focus.

Clearly, as this unfolds the software vendor is bearing very little risk, since they have pocketed the license dollars and completed the press release on the customer acquisition. Customer is taking on the additional burden of the incremental implementation costs with the system integrator milking them.

With SaaS, the tables are effectively turned on the software vendor. The SaaS software vendors (to their own detriment) have perpetuated this notion that, with SaaS, the implementation would be easy 1-2-3 and there you go.  In some cases, it is but we all know, enterprise software implementation is much more than just the software.

To really get to that state of customers doing their own implementations and onward to use the application, the vendor has to invest a lot in creating guided implementation tools, migration tools, WYSIWIG integration tools.  If you look at the current stable of SaaS vendors, very few have that kind of maturity.

Most smaller SaaS companies operate more in the Software+Services model than pure Software model. Me, I think this is a flawed strategy. As a startup you are much better off building a product that is simple to implement by the customer themselves with guided implementation wizards etc and focus all your energies on building a great product. Selling a product is tough enough, then to add a service fee on top of that for implementation will only result in additional approvals and prolong the sales cycle. Nevertheless, the reasons behind companies going with this strategy is usually bi-fold.

• Firstly, the technology they are building is still evolving so there are only few people beyond the employees of the company who can implement and guide customers through this process. That way, working closely with customers the companies can understand the gaps better and manage the bumps on the road much better.
• Second and more important reason is, being small, the companies can ill afford to lose the revenue that comes via the services arm. The services revenue helps in augmenting the minuscule subscription revenue when the product footprint is small.

Back to the topic at hand – Cost of Implementation…

In the eagerness to close the deals,  companies try to sign customers to deals where they underestimate the effort involved in implementation. Unlike in a license deal, the subscription fees that make up the MRR, includes all cost of sales and cost of operations. As a SaaS vendor, while you can charge customer for actuals in implementation, if you overshoot the implementation cycle, you are doing it on your own dime, as most of the implementations are typically fixed price. (Would love to hear if other companies are doing it differently)

So given this dichotomy here are five things a SaaS vendor can do to acquire customers without giving a sticker shock (of the initial implementation costs) while maintaining your margins.

1. Map-Gap Analysis: As anyone who has done software implementations will attest, the most challenging part of implementation is  the part where you need to define the business process. You can spend a lot of time just capturing all the information about the business process from the numerous pockets in a company. If you have a implementation deal which is a fixed price – 1 week – $10,000 dollars, you might spend a lot of time in honing in on the business process.  So to mitigate this you should define business process blue prints and have the customer map their current process to it even before you quote a implementation price. This way you will be much closer to the actual implementation scenario than uncovering the facts as part of a pre-costed implementation.
2. Best Practice Templates: Unless you are one of those companies that does not clearly know where you fit in, you should exactly know your customer demographics across target industry segments. Based on that you should go ahead and create best practice configuration templates. Here are things I would include as part of the templates
   • standard business process
   • workflows
   • setup data
   • roles and responsibilities
   • meta data
   • labels, instructions and error messages

While it is a one-time thing for you, you can reap the rewards over and over across multiple implementations. This will allow you great latitude to aggressively price the implementations. As you tailor specific customer  needs over and above the best practice templates, you can keep dovetailing those needs back into the blueprints and revving them up. This will also be a significant competitive advantage in terms of TCO and creating mind share.

3. Crowd Source: One of the great things of the times we are in is companies and individuals in those companies are opening up to concept of sharing and reaping the benefits of collaboration. Collaboration, when done properly, can create value for all the parties involved. When you are a SaaS startup, you want to keep the operations lean and optimize all the activities. One such way is to leverage your existing customer base to help you get better. As you incorporate your learning from one customer implementation to another, it makes for a more compelling story if it is actually being told by the customer impacted by it. Not to mention that your next customer coming from the same industry can relate to them much better than you portraying the scenario.

Most companies invariably sell to customers who amongst themselves might be die-hard rivals in their own industry. So it is easy for a technology vendor to wonder, if it would be wise to get connect two such customers and if they would open up to such propositions. Also factors into it, is the fear that the two customers might end up discussing the parameters of the deal for the software and the sweat-heart deal you gave to one might become the standard deal for all. But I am here to tell you, that no matter what you do, that information will end up getting shared, if it has to.

So instead of worrying about those things, think of all the value it generates when two leaders in a industry collaborate on your software platform. They might just end up helping you define your future product strategy. I think that is a great problem to have.  I will expand on this in a separate post, but for now suffice to say, that getting customers into a collaborative self-help community might go a long way in reducing the bumps along the implementation path and reduce your cost of implementation.

4. Implement in Phases: It is always tempting and some time seems easy to do a big bang implementation than to do it in phases. To me if you are not being able to identify logical phases of implementation it indicates a software vendor trying to make it easy for themselves. As with any software, implementing the entire product invariably involves multiple stakeholders, teams at customer site and some time multiple locations. This is where the implementation can end up ballooning. So as a software vendor(and a trusted adviser as I would like to think of myself), it is incumbent upon me to define the logical phases and impress upon the customer the value of doing so. I like to call it “peeling the onion”. Always keep at the forefront and highlight the ROI that can be achieved in each phase and it will be a easy thing to explain. It also allows you do a soft landing when it comes to the implementation costs.
5. Smell the Roses: In the initial stages it is a difficult thing to do things for free but you will have to bite the bullet. Customer pays for something which is fully-functional but your solution might be far from it. They don’t understand the intricacies of software implementation. So at times, be benevolent and let some of the costs go as it is in your interest to make those early or critical customers happy. Also look at it this way, the customer is ready to take a chance on your incomplete product and let you bake it on their stove (and dime). So all along the way enjoy the experience and don’t make the fact that you are incurring a small loss spoil the experience.

Hope this is useful for a start. I am sure other companies in similar situation have done other creative things to keep the costs down. Would love to hear from others.