在这份合同的案例中，双方都非常明确需要客户化，但客户化什么？客户化需要多少乙方的技术人员？需要多长时间？这些内容都不清楚。读者可以相信，在实施计划的附件中可能包含客户化的几个主要内容和所需要的时间，但是这些内容和时间，实际上都是主观上的臆断，在实际操作中没有多少参考价值。

    我们都知道，国内信息化的二十年间，几乎没有几个项目是在预期的时间内、在预期的资金内完成的。为何会产生这样的现象呢，问题的实质是什么？相信我们每个人已经做出了答案——“一切都是在不确定性下”。

    客户化本身是存在“需求的不确定性、客户化项目的管理”两大风险。一旦需求明确，这个风险消失时，另一个风险——客户化项目的管理、就会出现在双方的面前。

    软件商的信息化人员都认为，软件的客户化本身就是一个项目，这个客户化项目的成败直接关系到整个项目实施的好坏，它是软件实施项目过程中的一个子项目。而这个客户化过程与实施过程本身有本质的不同，不但涉及的人员不同，它所运用的方法也不同，而在这个客户化过程中，软件商的客户化过程几乎对企业客户是不透明的。

    从客户化项目的运作特征来看，它本身就是一个“黑箱”，企业的CIO面对这个“黑箱”如何管理，如何把握质量、把握进度就成为一个难题。如果解决不好，非旦客户化项目无法按时完成，还会造成双方无休止的扯皮。

    因此，通过何种方式管理这个“黑箱”，不但是CIO必须了解的内容，也是在合同中必须明确的内容。为了解决这一问题，在某一项目中，甲乙双方经过协商围绕客户化的组织、计划、监督、测试四个方面，提出了具有借鉴性的条款。

    在组织形式上提出。“乙方为保证项目的成功，需要组成客户化小组，并明确人员名单，这一小组由项目组直接负责，参与项目组的人员在客户化工作结束之前不得被调离，如有特殊情况必须经过甲方同意”。

    在工作计划上提出。“为保证项目正常实施，客户化小组的工作计划需由乙方提出，并经过甲乙双方的共同确认。为确保计划落实和可操作，本计划应以天计算工作进度，以及进度的衡量标准”。

    在监督内容上提出。“甲方有权随时了解客户化进度的执行情况，并针对执行中的问题要求乙方做出解释并提出解决方法”。

    在客户化内容的测试上提出。“乙方必须根据客户化需求内容，提出测试大纲和测试标准，并负责开展乙方自测和协助甲方的测试。测试数据建立、测试大纲、测试标准需要甲乙双方协商后得到甲方确认方才作为依据”。