Even though SharePoint has been available as a product for over ten years, I still see consternation among its existing and potential customers about what it is and how it should be used. I think that a lot of this is because its customers view it as a product that they can either use as-is or tweak through varying levels of customizations to get to a point solution that meets a specific need. But – which product? A document management system? An enterprise search solution? Web content management? Form/Workflow? BI front-ends?
Although SharePoint is purchased like a product, in reality it is a platform for a broad variety of business applications. For companies that are already committed to using Microsoft technologies and products, SharePoint is a logical and very cost-effective option. There is a rapidly emerging ecosystem of vendors providing a broad variety of products from administrative and management tools to full-fledged business applications that run on SharePoint - like learning management systems and contract lifecycle management systems. This ecosystem is proof of SharePoint’s validity as an enterprise platform; many businesses are staking their livelihood on SharePoint. As such, its implementation in an enterprise should not be viewed within the confines of its first intended use. This has serious ramifications for how SharePoint should be positioned and how it can be best leveraged, and may limit your implementation options down the road or may price SharePoint out of a particular need, when really its overall cost as a platform would be very compelling.
If you view SharePoint as a product for a specific need, its payback is tied into that need – i.e. if an organization views SharePoint as a lightweight, self-service document management system – then the payback for the implementation is tied to that usage. However, SharePoint is much more than that. So, how should organizations view SharePoint as a platform?
The answer is to break the platform into components that fit into the organization’s expected usage needs over an expected lifetime. Let’s take an example:
To meet a variety of needs, XYZ Corp decided to evaluate Sharepoint as an enterprise platform. The company is currently using SAP for financials and MRP, SalesForce.com for CRM, and Cognos for BI. Initially, it needs an ECM and WCM tool and is looking at SharePoint and a couple of other products. However, to really understand how SharePoint’s value should be determined, more than the intended uses should be considered when identifying the benefits that would be tied with its implementation coosts. To get a better handle on the costs, complementary third party products and tools, and, especially, services costs – both internal and external - should be considered. This can be daunting, and can start to paint a picture that it is really expensive.
For XYZ Corp, that means that they need to look at the other core functionality areas of SharePoint and identify other uses that fit in with larger needs. Specifically, they could consider using SharePoint for an upcoming business process management need, either just using out-of-the-box form and workflow capabilities, or with a third party product like K2 Blackpearl or Global360. Specialized content uses like contract lifecycle management and document scanning/acquisition and records management/archiving are a couple of others possibilities. Using Excel Services and PerformancePoint Services, along with SQL Server Reporting Services, adds potential for assembling self-service BI portals that augment the work the XYZ Corp already has in Cognos, and XYZ Corp knows they need to meet a need for Enterprise Search in the relatively near future
Even if those implementations aren’t planned in the near future, the potential of using SharePoint as an enterprise platform for these efforts, as long as they occur in the expected lifetime of SharePoint at XYZ Corp, needs to be considered when evaluating SharePoint. When looking at implementation costs around procuring licensing and setting up the core platform, if XYZ Corp could justify the costs of SharePoint for just ECM and WCM needs, imagine the improved payback they can experience when also using SharePoint for self-service BI, BPM, and some point solutions that are on deck
Naturally, doing this kind of planning requires a good understanding of the needs of the business as well as a solid grounding in what is provided by SharePoint natively, how it can be installed to take advantage of all of these features in a reliable and secure manner, and what complementary products and tools make sense to include in its implementation. Future blog posts will dive deeper into establishing a taxonomy for SharePoint solutions as well as providing some tools, hints, and lessons learned from Rightpoint’s experiences in helping customers plan out their SharePoint enterprise platform implementations.