从客户的角度看看节约成本

这个是给我们领导提交的文档，希望同在小公司挣扎的朋友能够一起交流。

-------------------------正文------------------------------------


目前我们的客户主要分为两种：

1、NEC之类的 这种大客户。

2、许许多多的日本和国内的小客户。

    对于第一种客户，我们只能遵从对方的标准，按照对方的规则。而且这种大客户有自己的流程和规则，所以我们只要遵循好他们的标准就足够了。

    对于第二种客户，才是这次分析的重点。姑且称他们为小客户。

    这种小客户的特点就是：自己没有一个规范的流程，而且给出的价钱低，对系统的功能也无法给出十分明确的需求描述，对于工期的要求也不尽相同，有的是非常紧迫，有的则毫不在乎。

    从这种小客户身上得到的利润虽然低，但目前也是我们值得重视的一部分。也正因为利润低，所以我们才需要想想办法，如何避免让一个小项目的周期延长，如何降低小项目中投入的资源。

    从管理方面我们自然要想尽办法去降低成本，但是，从目前的项目来看，有另一个因素正在极大的消耗成本---这就是客户方面的因素。

    几个小项目拖了几个月，假设一个项目的金额是 50万日元，按照目前的汇率，折合成人民币就是 30000 元。如果一个开发人员的每个月的薪水是 5000元，那么如果一个小项目在一个月内完成的话，盈利会是 25000 元。如果在两个月内完成呢，那么盈利就是 20000 元。

    可见，对于一个小项目来说，即使是“几天”这样短的时间，也是会极大的影响成本。

    抛开项目管理方面的因素，分析我们目前的一些小项目，会发现客户方面的因素也产生了很大的影响。

    例如，客户总是认为系统没有完成，或者间隔一段时间提出新的需求。客户可以延迟一个月，可是我们却不能延迟一个月。

    为什么客户会这样呢？如果客户不再延迟接受产品，我们的利润是不是就提高了？如果客户能够不随意增加功能，我们的利润是不是就提高了？

    那为什么IBM,NEC,这种大公司就不怕遇到这种麻烦？多半会听到这样的回答：“他们是大公司，和客户制定的合同都是很严格而且规范的”。

    所以，问题的源头找到了，关键在于客户怎么看我们。在客户看来：“他们就是一个小公司，小的不能再小了，甚至 50 万日元都可以做。所以，他们也肯定没有什么标准，也没什么规则，这个系统什么时候完成，怎么完成，都是我说了算。功能嘛我也可以随便加，只要别太过分就行。实在不行我不要这个系统了，我也不赔钱。”。

    是的，像我们这样的小公司，根本不能对客户要求什么，我们只能博取客户的满意。我们很难对客户说：“请不要再提新的需求了，否则要加钱的。”当然更不能说：“月底就是期限了，请尽快验收，而且请尽快给钱。”

    怎么办，客户仍然是上帝，即使是50万日元也是上帝！

    我想我们需要“装饰”自己。如果连自己都不拿自己当回事，那客户就更不拿你当回事了。

    按照我们目前的营业方式，能争取到一个客户已经不容易，就更无法再和客户谈更多的条件了。虽然没有办法，但是我们还是做，即使有 1% 的作用，也要做一下。

    一、要让客户认识到，我们虽然是一个小公司，但却是一个正规的公司

        这里我建议使用 SOW 文档。所谓 sow，就是 Statement Of Work，就是工作说明书，一些公司将这个东西作为正式合同的一部分。模板我简单写了一个，参考“SOW.doc”。写这个 sow，并不是让客户遵守某些规则，而是让客户知道某些规则。例如一个项目已经谈下来，那么我们可以写好一份 sow 文档，然后发给客户，让客户确认这些信息。sow 文档中包含了功能列表，交付时间，交付物列表，以及钱。
        我们当然不会告诉客户：“请确认这个文档，然后我们就按照这个文档执行。谁破坏了规矩，谁就算违约。”我们仅仅是想告诉客户：“文档中的内容是我们互相商谈一致的结果，而且我们用标准的方式总结了下来，希望你确认一下。”
        这个文档至少告诉客户：我们并非小得一塌糊涂，而是具有某种规范的。这样，当客户因为各种理由延期或者增加功能的时候，至少会因为这个文档而有 1% 的几率有这样的想法：对方也是规范的公司，我是不是应该按照合同来呢？

        此外，如果时间允许，在项目临近交付的时候，送给客户一个测试式样书也是必要的事情。

        甚至可以说，规范化的文档，给客户提供的越多越好，但是考虑到目前我们的人力和客户的级别，以上的两个文档就足够了。而所作的这些，仅仅是给客户一个印象：我们是一个规范化的公司。而要达到的目标，就是：从客户的角度节约成本。

    二、动态调整项目状态

          上面所说的规范化的文档，有一定的成功率，所以我们还得想想，如果客户就认为你是一个小公司，好欺负，项目无故延期，功能不断追加，怎么办？我们的成本已经付出了，能收回来一点钱就少赔一点，所以不做是不可能的。

         一般来说，小项目我们是不写周报的。但是对于这样的情况，建议 周报+更新的sow一起上，如果觉得一周时间太长，就三天一次。这么做也仅仅是用我们的诚意去感动客户，希望客户能够手下留情，尽快结束项目。

         如果仍然无效怎么办？建议将这个项目的状态转入维护状态，高成本的人退出，换低成本的人接手。既然期限总是拖长，功能总是追加，那说明这个东西在客户看来并不是特别着急，所以，换一个低成本的人跟进就可以了。如果人不够了呢？那么做这个项目的人就分配30%的时间，剩下70%的时间做别的项目。

         这种时候我们也只能动态调整项目的状态，随机应变了。


以上是根据目前公司的几个项目的状态而总结的内容，希望能有所帮助。