一提内容管理系统,准让钱包抖三抖。为啥? 因为它太费钱了,十几万起步,几百万司空见惯。

这么奢华的东西,谁买都得费费神。产品样数多,价格弹性大,买完还得要维护。头疼!

不久前,美国内容策略咨询公司 CEO 莎姐 (Sarah O’Keefe) 和 Ellucian 公司资深信息架构师帕姐 (Pam Noreault) 一起在 BrightTALK 上开了一场网络研讨会 (Managing Content With Tools Beyond Your Control)。

在研讨会上,她们深入探讨了内容管理系统的主要部署方式、每一种部署方式的优缺点和潜在风险,还在采购决策、软件定制和沟通管理等方面碰撞出了很多实用又独到的见解。

本文是一篇精心整理的笔记,借花献佛。如果你正在挑选内容管理系统,希望它能雪中送炭。如果你已经入手内容管理系统了,希望能引发你的共鸣和分享欲。如果你的日程表上还没有采购内容管理系统这件事,收藏一下,说不定以后有大用处。

部署方式

内容管理系统的部署方式分为两种:私有化部署和云服务模式。

私有化部署 (on-premise),也叫做本地部署或独立部署,是指将内容管理系统部署在自己可以控制的独立服务器、虚拟主机或云服务器上。

私有化部署的优点是,企业对内容管理系统拥有较高的自主权,可以根据自身需要对系统进行定制开发或二次开发。它的缺点是,系统上线后,企业得自己负责软件维护工作,成本较高。

云服务模式,也叫 SaaS (Software as a Service) 或云部署,是指订阅第三方供应商(即云服务供应商)提供的互联网软件。第三方供应商负责内容管理系统的部署、升级和维护。

云服务模式的优点是,功能丰富,扩展性好,安全可靠,免费更新,无需维护。它的缺点是,企业缺少自主权(比如无法控制软件要不要升级、什么时候升级),故障修复周期长,定制开发的费用高等。

更新和维护

如果采用私有化部署,内容管理系统的更新和维护一般由企业的 IT 部门负责。

按常理来说,内部部门之间沟通起来会比较方便,协同解决问题的效率会比较高。但如果 IT 部门的能力有限,或者企业中的“部门墙”现象比较严重,当你遇到问题或故障时,他们可能不会帮你及时解决。

在研讨会上,莎姐和帕姐让听众投票评价自己公司的 IT 部门。投票结果显示,约 2/3 的人对 IT 部门不太满意。

选项 票数占比
IT 部门很棒,总是能及时解决问题。 28%
对IT部门来说,内容管理系统方面的问题不属于优先事项。 49%
根据律师的建议,我拒绝回答这个问题。 21%
慎言!我就在 IT 部门工作。 0

有些软件公司使用文档注释的方法编写文档,即在源代码中使用特殊的注释格式描述代码的功能、使用方法、参数和返回值等信息。文档注释可以由相应的工具从源代码中自动提取,经编译后自动生成文档。

在这种情况下,文档编写和发布的工具往往由研发团队负责更新和维护。帕姐认为,文档注释作为源代码的一部分,使文档成为了公司的显性资产,有助于提升文档的价值。

如果采用云服务模式,内容管理系统的更新和维护由第三方供应商负责。

更新和维护内容管理系统时,第三方供应商需要按照服务等级协议 (Service Level Agreement, SLA) 中的规定进行。服务等级协议是客户与第三方供应商协商签定的一个具有法律效力的服务合同。

有正式的合同作保障,当你遇到问题或故障时,一般都能及时解决。万一解决不了,你的问题也会按照上报流程向上级反映。

不过,如果你遇到的问题或故障只是个例,并非大多数用户都会遇到共性问题,可能会花很长时间才能解决,甚至可能永远解决不了。

研讨会的听众还参与了一个关于“谁负责管理 (control) 你的内容管理系统”的投票。投票结果很有趣,40% 的听众说他们的文档团队亲自管理他们的内容管理系统。帕姐认为,这些文档团队可能有内容管理系统的管理员权限或某些配置的管理权限。不过,这个话题不在今天的议题范围内,希望今后有机会深入探讨一下。

选项 票数占比
文档团队 40%
IT 部门 35%
第三方供应商 10%
啥是“管理 (control)”? 13%

定制开发

如果是私有化部署,企业可以更放心地对内容管理系统进行定制开发。

因为公司的 IT 部门都是自己的员工,既熟悉自家的软硬件设施和定制需求,又拥有内容管理系统的管理权限,比如要不要升级、何时升级等。

如果是云服务模式,对内容管理系统进行定制开发需要格外谨慎。

定制开发有可能产生高额费用。定制开发属于一次性服务。如果定制开发完成后,第三方供应商对内容管理系统进行了升级,定制的功能可能就不能正常工作了。如果要修复它,你需要额外付费。

在云服务模式下,企业没有内容管理系统的管理权限,不能自己决定升不升级、什么时候升级这些事情。这就恐怖了,不知道哪天一觉醒来,又升级了,又不工作了,又要厚着脸皮去跟老板申请预算了…

无论采用哪种部署方式,定制开发前都要做一下成本收益分析。只有一项功能带来的便利和高效大于它的定制开发成本和长期维护成本时,这项功能才值得去定制。

定制开发时,尽量不要动内容管理系统的核心软件或核心代码。否则,定制开发的功能越多,长期维护成本越高。

选购流程

首先,确定核心需求。想清楚你需要内容管理系统必须具备哪些特性,哪些特性是有了更好、没有也能凑合的。然后,将这些特性整理成需求清单。需求清单要遵循最小化原则,力求简洁。

然后,评估现有资源。比如评估文档团队、IT 部门、研发团队和第三方供应商的团队规模、技术能力、优势和劣势等,并将这些评估数据做成一张评估表。

最后,筛选最佳方案。将选购内容管理系统当做员工招聘,IT 部门、研发团队和第三方供应商就像是应聘者,你可以通过评估他们在各方面的能力和经验筛选出最合适的“人选”。

一般而言,公司越小或者文档团队的规模越小,越适合云服务模式。公司越大或者内容管理系统需要对接的系统越多,越适合私有化部署。需要对接的系统中,常见的有翻译系统、客服系统、测试系统和搜索引擎等。

当然,这还和公司内部 IT 部门的能力有关。很多公司一开始压根儿不考虑云服务模式,但由于 IT 部门一直不给力,或者 IT 部门经常忙得顾不上解决内容管理系统的事儿,只好转向了云服务模式。

风险防范

如果需要对内容管理系统进行定制开发,一定要先搞清楚定制需求背后的真正原因。

作为一名资深顾问,莎姐在回答听众的问题时,道出了一个非常戳心的事实:很多公司的定制开发,实际上只是在想方设法地维持原来的工作方式罢了。

花那么多钱买了内容管理系统,为什么还要花更多的钱把它变没了(和没有它时一样)?

有了新的内容管理系统,员工就需要重新学习、重新适应、重做很多工作。但他们心里很清楚,公司往往希望员工在原有的工作节奏上无缝切换,还不提供相关的培训,不预留学习和适应的时间,更没有任何奖励和回报。

于是,员工本能地将新工具带来的干扰和压力变成了“定制需求”。

如果对内容管理系统进行了定制开发,一定要将功能描述、安装方法和开发人员信息等关键内容写成文档。

无论采用哪种部署方式,定制开发都需要持续地更新或维护。如果最初负责定制开发的员工调岗了或离职了,文档可以确保其他人可以顺利接手,不会造成“失传”现象。

对云服务模式下的定制开发,帕姐分享了一条特别实用的经验:让第三方供应商将你的定制需求做成软件的标准功能 —— 让所有用户都可以用的定制选项。

既然是标准功能,第三方供应商自然就会将这个定制选项的功能和使用方法写进官方文档里,软件升级时也不会导致功能失效。

与负责更新和维护内容管理系统的团队(比如 IT 部门、第三方供应商)沟通时,做好预期管理,注意方式方法。

如果是公司内部的 IT 部门,一定地清楚地告诉对方你需要他做什么,你希望做成什么样的,什么时间做好,等等。

你还可以制定一个问题上报流程。当问题得不到及时解决时,按照上报流程向上级反映。

如果是云服务模式,你和第三方供应商会签定一个服务等级协议。签定协议前,一定要认真审核协议条款,最大限度地保障自己的权益。