- User permissions and document libraries
- Basic CMS capabilities with user-based permissions
- Ability to tie into other products to extend and scale the platform
We use SharePoint largely as an internal intranet; users are organized through AD and into their respective teams. Each team is responsible for their own websites and areas (including document repositories). Through this form of user organization, we can share resources with one another and in other areas, we can also set up public access so that everybody has access to everything.
On top of that, we can set up applications such as Power BI and web parts to handle data processing, telemetry/analytics, and even document processing. We have web forms that collect all manner of data, with workflows, to help with internal processes.
For the most part, the tool is useable, but there are many end users who still find it difficult overall. As a developer, I am able to find my way through the interfaces with time, but it takes too much time to learn these things and remember where they are. As an end user, I can understand why some people altogether give up in frustration.
I have used it for 10 years, through various versions.
I have not encountered any stability issues. SharePoint is a very stable platform, provided that it's installed on an equally stable server environment.
Occasionally, we come across strange server-level errors, but they are few and far between. Normal users almost never have problems, except for permission-based incidents.
I have not encountered any scalability issues. SharePoint is very scalable, provided that you have the resources to ensure its smooth operation.
For example, enabling Power BI is almost as easy as subscribing to the SaaS and flicking a switch. Similarly, other third-party vendor plugins are as easy as installing them and making the webpages and web parts available to the users. However, making sure that the platform itself is configured correctly and deploying the plugins correctly, is often where some things can fail. SharePoint itself scales well, it's just ensuring that all the additional resources are working cohesively.
N/A. I am not a system admin for our SharePoint instances, so I don't contact MS support for SharePoint issues.
To my knowledge, we have always used SharePoint. We have not switched away from SharePoint because of its AD integration; it makes automatic permissions that much easier.
N/A. I am not a system admin for SharePoint and was not involved in the deployment.
While a business owner of the platform, I can only comment on that the upgrade/migration from SharePoint 2010 to SharePoint 2013 was relatively smooth, albeit very slow.
The migration process took an entire weekend, and our instance is shy of 150GB total stored contents.
Pricing and licensing is a very subjective topic. Some companies have more resources than others, and some vendors are more flexible than others.This is very much a "your mileage may vary" type of discussion. The only two things I can offer are:
We are an academic institution, and so we have a EDU partnership for volume licensing and other enterprise purchasing agreements.
For this particular product (MS SharePoint), we are using the SharePoint Enterprise CAL license, for our on-premise solution. There are other departments that do the same thing with enterprise CAL, but our overarching relationship with Microsoft is through our central department.
N/A. This was a pre-existing solution that's been upgraded many times since its first roll out (2003 > 2007 > 2010 > 2013).
Make sure that you have the proper resources to ensure that the product is well maintained. This includes both technical resources and if necessary a governance group.
There is a steep learning curve for those not familiar with the way Microsoft works. They have a specific, albeit predictable, way of doing things. Ensure that your developers and system administrators are familiar with this "way". It seems arrogant and militant to state, but if your resources aren't willing to do things the Microsoft way, they should be taken off this project, else they will slow things down or outright make things worse.
The product itself is very robust and capable, but the success of the tool is largely dependent upon the team that deploys and maintains the product, as well as resources available to it.
Without proper resources, the product can flounder and fail.