SaaS - Disruption does not warrant Craziness

So, I have started to use the Cloud Compass on the left to give immediate context to these posts, more about that here.

Anyway, this post is about SaaS craziness. SaaS is firmly in the technology mainstream now in various guises, and there is no argument it has been disruptive. From Facebook to Google Apps to Salesforce.com, this kind of easy access to constantly maturing applications has resulted in a burst of popularity in accessing powerful applications online, superseding the hassle of locally hosting them. I doubt Facebook would be as popular if it came on a CD.

I agree with Google that all apps will eventually move to the Cloud, but while we are in this transition period I am seeing a bit of craziness from end-users and system integrators as they get to grips with the SaaS model. I will give 3 examples:

• Google Apps 
• Background: There are a few companies moving to Google Apps and certainly the technology is now hitting the point where it is mature enough for enterprise use. Certainly the 'single version to share' concept for docs, spreadsheets, diagrams etc is a step change from emailing attachments around.
• The craziness: I have seen companies go live with this, and get into an awful muddle. Links to drawings and documents flying around, completely unmanaged. People creating google sites with links all over the place when they should just be creating a single document. Chaos. It's like any kind of document management best practice is hurled out the window because 'we are now collaborative'. "Poppycock". As my Gran would probably say. 
• The way forward: Now, I think Google docs, spreadsheets, drawings and sites are now great tools, but I am in no doubt that 'best practice' in how to use and properly manage them is something companies will be crying out for as this area grows. My opinion is to 'begin with the end in mind'. If you need to create a point in time document which is going to be referenced by others at that point, the 'doc' tool is the way. If you are wanting to build up a knowledge-base or project management repository over time with no defined end, use the 'site' tool. The 'spreadsheet' tool is great for capturing and maintaining table based data such as 'Action Logs' etc, and the 'drawing' tool is not bad for collaborative diagrams but still a bit to go on that one. Maintaining links to all of this in a google site in a similar organized way you used to in file directories - yes yes yes. Again, evolve but don't leave best practice behind.
• Salesforce.com
• Background: This is bursting in popularity and is a great SaaS CRM app which is evolving at a rapid rate. Certainly leading in it's field and an easily accessible solution for companies of all sizes, or even departments within companies that have turned their back on the IT dept.
• The Craziness: There is a misconception that because it is easy to set up, it requires less management than a traditional CRM app. Certainly in the case of departmental deployments outside of the IT side of the business. The business feel 'empowered', they have their own CRM app and can manage it how they wish, no more shackles of IT! Even IT may just think they can be left to get on with it because it is 'SaaS'. But this means that the best practice of Change Management, Release Management, Design etc, which IT tend to be skilled in, is not present. So the nice SaaS app, quick to change, 'agile' even :-), turns into a hulking great Frankenstein of a thing because it is not managed correctly. Oh, and the instance that has been set up in the 'other' department gets itself in the same mess. And the one over in Germany which they set up etc etc. It effectively becomes the 'multiple excel sheet problem' all over again. And somewhere down the line there will be a transformation project to consolidate the instances I guess. Really needs to be a strategic company move rather than departmental tactical.
• The way forward: IT need to be involved, but not to the same extent as they traditionally have been. 'Seeding' an IT resource into the business is a good idea to provide the processes for Release Management, best practice design etc, and having them work with whatever system integrator may be in the picture. Certainly these instances need to be managed as part of the wider company portfolio and the business and IT need to work in the middle ground. And the vendor needs to recommend this, not just salesforce.com, but any SaaS vendor. Alternatively a tier 1 or tier 2 system integrator could perform this function.
• The 'SaaS Consultant' or 'SaaS Team' within a System Integrator
• Background: Most of the big system integrators are now forming 'SaaS' teams to deliver 'SaaS' solutions. These tend to cover the most popular SaaS products and just concentrate on these. Many of the big boys in this area have been aggressively recruiting SaaS Consultants in line with the growth of the SaaS solutions.
• The Craziness: The thing about this, is that there have never been 'On-Premise Solution' teams, or adverts for an 'On-Premise Consultant'. SaaS is just a software model, albeit the forward-thinking one. My guess is that internal politics stop the less lucrative SaaS solutions (ie faster to implement, less resource needed) being part of the 'CRM' or 'Supply Chain' technology offerings in many instances, where sales guys want to concentrate on the big bucks (Oracle, SAP etc). Therefore the forward thinkers within the company need to branch out and have their own 'SaaS' identity. Just a guess. However, I would think that as this crazy scenario becomes unsustainable when SaaS is the default option, the SaaS solutions will replace the traditional solutions in the context of big SI offerings. And so the cash cow dies...
• The way forward: An SI should combine SaaS and non-SaaS offerings under each functional area, be it CRM, or HR or whatever. Then, based on requirements, the appropriate solution is chosen for the customer. There are areas where SaaS is strong (CRM), and areas where on-premise is strong (ERP). But what you would not want is for a sale to be bias towards a certain technology because the technology options matching a certain functional area are silo-ed in different teams within the SI. ie if the 'CRM Team' of an SI engages with a client for a sale, you would not want the technology options to be based on a subset of those available within the domain because some are covered by the 'CRM Team' and some by the 'SaaS (!!?) Team'. All CRM options should be covered under a CRM team, simple.

So, just 3 areas where I have seen strange things connected with the 'SaaS' disruption. Regarding the google apps and salesforce.com ones I am working on the best models based on what I believe to be effective in my experience. It's all about balance and adapting best practice, but not leaving it eating dust in the rush to SaaS.