商品销售合同关系是买卖东西，IT系统建设、尤其是软件开发项目合同，简直就是卖身契。做乙方变成了甲方的奴仆，做牛做马、任其蹂躏好像都是应该的。IT项目很多问题都是从这张纸开始的，以下是一些常见问题。

1、投标陷阱。土地招拍挂肥了财政、坑了百姓，IT项目竞价招标却往往是一损俱损。某企业年金系统开发、实施项目，根据中等人员能力、2万元/人月计算需要150万左右，投标结果出乎意料，厂商报价最高120万元、最低90多万，某知名公司竟然以最低价中标。项目开发工作是由一位5年工作经验的开发组长带着几个应届生、实习生组成的团队执行，原计划1年完成的项目做了2年基本上线应用。现在有很多项目是这样，不光是软件，有些系统软件、设备采购项目也几乎逼近价格底线。投标结果对乙方来说，不中标很郁闷，中了标更郁闷。纠其原因，标书技术部分评价差距太小（厂商同质化、专家不专家），最后只能在价格上血拼。解决合同问题第一步就是避免掉进入投标陷阱，最好还是展现自己专业技能，让用户改变一下评标规则。

2、总包与总集成，协议与合同。项目总包和总集成不是一个概念，总包肯定涵盖了总集成工作，但是总集成不是总包。某厂商与甲方在RFP阶段签订了某大项目的总集成协议，后来该项目招标时拆为软件开发、硬件采购、软件采购、网络工程等项目包，该厂商中标了软件开发项目、软件采购项目并签署了两个合同。项目开始实施后，甲方要求该厂商承担总集成商的角色，统筹管理项目各实施方、控制整个项目进度，然而各实施方并不好好配合，他们是和甲方签的合同，不是该厂商的分包商。很明显，该厂商不是总包商，和其他实施方是平等的。其次，该厂商虽然与甲方签署了总集成协议，但是协议不是法律责任文件。虽然公司有法务人员，但是很少审查协议文件，虽然乙方在项目实施过程中承担了超范围工作，法务人员也不知道。

3、工作说明书（SOW）。SOW重点写work package，不要写成软件Functional Scope，后者不能体现需要调研、系统设计、编码、测试、UAT、安装部署、系统支持、项目管理等工作内容。至于软件功能范围能写多少就写多少，说不清楚就直接写“以需求调研结束后确认的SRS为准”。加上甲方的不同阶段的责任、提供的资源、拟定的进度计划、变更流程等就完成了。最好在工作项后边加上完工标志，这是很好的自我保护条款。另外，如果有些地方说的不清楚可以用“不包括的工作”这样的排除方式限定范围。工作说明书是一项很重要的工作，要仔细编写、评审，很多公司花大量时间在合同主文件上抠字眼（其实主文件已经越来越标准化了），却很少关注SOW内容。关于SOW的反面教材实在太多了，不举例了。

4、赔偿、惩罚条款。有些条款简直是搞笑，竟然堂堂正正的出现在合同里。某合同约定“2006年12月1日正式上线，如果因为乙方原因不能如期上线，自规定系统上线之日起每天按合同总额的1%收取乙方滞纳金”。另外一个合同明确写着“如果验收时系统功能不满足用户需求，甲方按照相应比例扣除乙方合同金额，最高比例不超过50%”。第一种情况来说，表面上似乎合理，但是不能如期上线的原因会很多，乙方很难说与自己毫无关系。其次，滞纳金说法不对，其实就是赔偿或者罚金。第二种情况，验收不能作为对系统判定的唯一标尺，有时验收很复杂，只凭用户最终感受来判断对乙方非常不利。也有可以作为赔偿的条款，比如“乙方误操作造成甲方设备损坏的，乙方保管期间造成甲方设备丢失等，乙方必须如何…”，如有必要可以列入。总之，很难划清责任的条款不应该简单的惩罚乙方。

      5、系统运维。我们买东西也很关注售后服务，而且我们发现售后条款很细致。比如电脑售后服务：整机保修期3年，保修期内主板、CPU、硬盘等核心部件非人为损坏情况下免费维修或更换；其中键盘、鼠标保修期为6个月，非人为损坏进行免费更换；保修期内提供3次免费上门服务；提供产品终身有偿维修服务等等。为什么要写这么细，因为设备会产生维护成本，划清维护责任对厂商来说至关重要。其实我们做IT项目也一样，不能简单的承诺免费维护期18个月，一定要说明维护内容、维护范围等。回到前一节SOW，免费维护工作一定也写到工作说明书中，否则大家对系统维护含义理解不同，最终对乙方是很不利的。