SP for the front-end yes, but underneath other ECM vendors should be preferred; they offer more capabilities as IWR says.
see IWR Blog:
http://blog.iwr.co.uk/2008/09/sharepoint-pros.html
and from another UK blog: tfpl
Some quirks ...
If you want to introduce a records management fileplan / business classification scheme into SharePoint you need to decide for each heading of your fileplan whether to set the heading up as a site, or as a document library within a site, or a folder within a document library.
Here are the quirks that Marc identified:
* Folders within document libraries don't have as much power as any of the other entities in the hierarchy: they were put in as an afterthought by Microsoft who had thought they wouldn't need them.
* There is no support for hierarchical pick lists/taxonomy: you can only present the user with flat lists.
* The metadata columns you define for documents do not link in with the advanced search facility. You can define a 'subject' field for documents, and you can provide a pick list to act as a controlled vocabulary for that field. But (out of the box) you can't present that same pick list to a searcher, even though there is an advanced search facility which shows the 'subject' field.
* Site-Collections work in a counter-intuitive way. Every site must be nested within a site-collection. But site-collections are invisible to users, who can only spot their existence through the url adress of the particular site or resource that they are looking at.
* Site-Collections function like boundaries within the system. When you set up a content type, or a web part, or define metadata columns, these types, parts and columns only work within the boundaries of a site collection. If you want them to apply across the whole system you have to set them up afresh for each site collection. This would naturally push you towards having as few site collections as possible, but the catch is that there is a limit on the capacity of each site collection. Site Collections should not exceed 100Gb (the reasons why are explained here).
* Document libraries normally inherit access permissions/restrictions from the next level up in the hierarchy (the site). But access permissions can also be set by content types which cut across different areas of the hierarchy. This leaves open the possibility of access permissions inherited from a site conflicting with access permission assigned from a content type. Out of the box MOSS 2007 does not have any way of managing this conflict, and where the conflict occurs access permissions are broken for that area of the hierarchy.
James Lappin
http://tfpl.typepad.com/tfpl/sharepoint/index.htmljhagmann - 28. Sep, 22:00
