对项目的当前状态有一个了解。 因此,新组员就不能很容易地从存储的 e-mail 中了解到历史信息或当前项目
的状态了。
员工很难找到与其工作相关的信息。Microsoft 共有 26000 个 SharePoint Team Services 项目组网站,
这些站点中的很多个彼此之间都没有明确的关系。要将这些站点合并到一个综合门户中去
需要相当大的人力。最常出现的情况是这样的,用户没有别的办法,他们要利用自己的设
备从数千个站点(以及数以千计的文件共享和公共文件夹)中找到与其项目有关的前十个
或前十二个。利用内联网 Web 搜索可以找到许多这样的站点,不过这些站点会与很多不相
干的搜索结果列在一起。员工们需要知道:
•
到哪里去找最相关的项目组网站(例如,其他项目组的站点)。
•
企业搜索结果中包含了相关和最新的内容。
项目组需要将重点放在业务上而不是 IT 问题上。走遍整个公司,你会发现许多项目组都在独立工作视图解决类
似的问题,例如如何在站点内或跨站点进行搜索,如何识别到相关项目组和单位站点的链接。 这些工作都是重
复劳动,而且与项目目标没有直接关系。 事实上,这些额外的工作还常常会妨碍项目组达到项目目标。
产品和技术的名字关键码
这种技术最初发布的时候称为 SharePoint Team Services,现在发布改为 Windows SharePoint
Services.
这种产品最初发布的时候称为 SharePoint Portal Server 2001,现在发布改为 Oce SharePoint
Portal Server 2003。
在更早的平台上企业管理工作是很复杂的。
尽管这种由 SharePoint Team Services 托管的解决方案在支持项目组解决方案的时候工作良好,但它并不是
用来管理多达数千站点的。 随着 Microsoft 在采用着越来越多的项目组网站,围绕着如何在企业规模上维护这
种解决方案出现了难题。还有几种可以选择的存储平台,不过它们的某些功能是互相重叠的。
高成本的存储。由于磁盘空间是在很多平台之间分配的,因此对于其他平台来讲是无法访问每个存储装置的剩
余空间的。 最终结果就是,整个企业内到处都存在着大量未使用的磁盘空间。而且,这么大的内容量,总有一
定百分比的内容是不再相关的。 不过,OTG 手里也没有相应的数据,以便判断哪些站点仍然相关,仍然处于活
动状态。 由于不能简单地删除或归档任意比例的内容以为新站点释放容量,因此它就要增加存储器,从而需要
为补充的硬件和支持工作支付成本。
脱节的支持过程。由于 OTG 的各个存储平台是为各种各样的项目组所共有的,因此就不存在针对存储技术的一
致支持过程。 例如,消息操作是支持交换服务器的,而另一个独立的项目组却是支持 SharePoint 产品和技术
的。 因此,用户们就不得不求助于各种各样的专家,以便拿出针对自己问题的解决方案。 并非是只很好地支持
少数平台并将重点放在了一体化改进上,OTG 将重点铺得很宽,维护了很多系统,而每个系统都有其重要但并
评论0
最新资源