昨儿跟大象两口子一起去万象城吃釜山烧烤，等号的空挡在旁边书店转悠了一下，就十几分钟的功夫，火速购置了一本书 关于商业模式的。通常很少在书店直接买书，因为书店没有折扣没有评论没有其他参照。除非特别有眼缘或者就是头脑发热 这本应该属于头脑发热，因为作者里有一个我特别不喜欢的张维迎老师——在买完以后才发现的 下午勉强看了半本，因为太多术语和背景知识欠缺，有仨感悟，趁着没睡记录一下 1. 公司价值还是客户价值 『客户第一』几乎是所有企业挂在嘴上的概念，但执行上很难缺乏系统化。很多制度、绩效考核标准和战略，都带着强烈的公司立场。前些日子看了去玩网CEO周品的一段访谈，有段话很精彩—— “这里讲到转化率，二跳率或者是用户的注册率、平均单价等，这是电子商务网站所讲到的常规数据。从内部而言，这些数据并没有什么可操作性，它是经过对各种有效KPI操作的一个结果，我们更关注的是缺货率，物流的妥投率，包装的破损率以及准时的到达率，这些跟客户更密切相关的数据，因为这些指标会直接影响他购买这个商品的体验。” 我们喊着客户第一，却仍然从公司层面去考量很多东西，“单个客户成本”、“边际效益”、“网站PV”等等指标成为公司的绩效考核重点项。这些指标与客户没有直接的关系。客户更关注的或许是自己的体验、问题的处理效率这些范畴的概念。 这些错位的产生，我认为主要起源于客户关注的那些重点指标的量化难度，而当我们无法真正站在客户角度去量化目的时，就只能从公司角度去量化过程。 举个简单的例子，大部分的邮件营销，都会以发送数量、送达效率、发通率、打开率或反应率等数字进行效果量化。那就是一种公司立场，认为邮件营销本身的目的是挖掘或激活更多的潜在客户——以获取更多的利润，降低单个客户成本。但从客户的角度来看，收到、打开、反应（点击）都不产生任何价值，只有当邮件内容带来的信息或服务可以为自己赢利时，才存在价值——但这些都难以进行量化。 当对过程的量化成为行业标准时，人们就会习以为常地接受，不再去考虑是否合理。其实就想周品一样，试着换换立场和思路，一定会有新的游戏规则出现，客户第一也才真的落到了公司的灵魂里。 2. 更多客户还是为客户创造更多价值 我一直认为这俩概念肯定是矛盾的，当然可以说什么在发展更多客户的同时为客户创造更多价值，我是不喜欢这样的说法，如果公司只有一块钱，这一块钱该干嘛呢？5毛发展新客户，5毛为客户创造更多价值？ 虽然书里说调研CEO的结果都觉得应该先抓更多客户，但我觉得这个没法有个定论，不好说。发展更多客户，会带来的副作用是客户多样性增加；为客户创造更多价值，我认为总脱离不了满足客户个性化需求。这两个过程应该是交替进行的，先要能为客户创造更多价值——出类拔萃的产品、品牌、口碑，而后尽量抓取同质的客户——享受边际效益，在此基础上进行细分——可能会增加边际成本，而后再拉更多客户。 一味地开辟新客户（除非是亘古不变的刚性需求），或一味地闭门造车（你丫又不是绿坝），可能都不是长久之记。 3. 产品、服务和解决方案 这个应该算是老生长谈了，从项目，到产品，再到服务，直到现在特火的“解决方案”，所有公司的目的，都是最大限度地整合能整合的资源，为客户创造价值。 又困了，不说了，晚安。

供职的部门做过一次大规模的重构，其实也不叫重构，基本就是重做，对业务做了概念模型分析，一套泥巴堆砌起来的系统被重构成了条理清晰的很多很多套子系统。概念是超前的，各个系统加一条“总线”，实践了平台化，也实践了SOA。 但随着时间推移，事态逐渐起了变化。系统之间的连接越来越多，越来越复杂，又由于数据是随着系统部署的，为了效率，字段又被到处冗余。系统架构与组织架构的尴尬契合也增加了大量的沟通成本。 “服务”的粒度也差别甚大，缺乏统一的规划和持续的维护。原本产品级的业务服务逐渐就蜕化成了系统间各种各样复杂的接口，接口之间互相交并，掰扯不清。从而恶性循环，每每有业务需求，由于现有接口已经乱七八糟，所以干脆再开发新的接口，“恰好”满足业务需求。此时，系统分离带来的弊端反倒凸显，一个简单的需求，由于涉及众多系统，就需要涉及众多人，开发成本增加不说，沟通成本更是噌噌地长啊。 这下惨了，拉着SOA的大旗，却好似只是把原来的类简单的改了个名字叫“系统”，分开部署。概念中的“服务”，也就成了public方法，只不过不能直接调用，要通过总线，数据更麻烦了。—嘿，求您了，能帮忙做个接口取个数据吗？—我们系统压力很大了，数据太多，走接口也不行，要不你冗余过去吧 我觉得，这样其实不靠谱 首先应该做的是去规范平台，或者叫系统的级别，不能简单的将业务概念模型简单地套到系统模型上——比如概念模型中，有支付，就做一个支付平台，有物流，就做一个物流平台。业务概念模型重要，但将业务的概念模型落到实现上也同样重要。 其次是规范子系统的范围，比如作为一个客户系统，应该有哪些责任，哪些义务。然后把它们包装成“服务”，他不会因为具体的需求而变化，更不需要因为具体的需求不断地新发展出更多的“服务”——或者叫“接口”。 最后，应该是考虑数据的处理，不过这儿我总是想不明白。。。那就不说了。。。 对于一个从无到有的新系统，虽然做起来很难，但这样说起来好像还容易一些，对付一个历史遗留系统，该咋做呢？ 我觉得，需要有两个条件 一是投入、持续的投入资源。因为要维护服务，持续更新改进，都是需要比开发一个简单的恰好满足业务的接口花费更多资源的。最初，当出现一个“接口”需求时，就需要对其做分析和抽象，搞一个人模狗样的“服务”出来。然后，去把原来已经存在的杂七杂八的接口掏出来，挑它一两个概念相似的，争取并到那个人模狗样的“服务”里面，而这个过程可能是极花时间的，要看舍不舍得投啦。 还有持续优化。刚才说的，那个人模狗样的服务，需要持续地被优化，并且在优化中一步步拿掉陈旧并且细碎的接口，不断的扩充和完善服务。最终，就会相对稳定的将子系统的“责任”以若干个“服务”描画出来。 不多说了，困了。。。

有一句名言叫做“complain with suggestion”，在很多场合见到各种人理直气壮地表示，抱怨一定要伴随着建议，否则抱怨没意义。那些抱怨的人倒也没脾气，听到这句纷纷都偃旗息鼓，感叹自己『没有好建议』 准备好建议，真的是抱怨的前提吗？我倒觉得未必。 在饭店吃饭，抱怨某道菜不好吃，一定要告诉厨师，应该放多少盐，应该用多少度油温吗？我想除非你是一厨子，否则很难真正给出建设性的suggestion。如此推论，厨子想要提高，恐怕只能自己摸索或寄希望于某天突然有食神到访，并且complain with suggestion了。 反观理直气壮的要求建议的人们，他们不接受没有建议的抱怨有可能是什么原因？ 1. 觉得没有建议的抱怨，很可能是一个没经过深思熟虑的想法。 2. 自己懒得找解决方案，所以要求抱怨者提出个解决方案，大不了直接换这个方案。 3. 因为驳斥一个“方案”，比驳斥抱怨简单的多，所以之掉干掉你这个不成熟的方案，就可以直接干掉你的抱怨。 ——我觉得这三个原因都源于方案提供者的懒惰或不自信。 其实我认为没有建议就不让抱怨是混蛋逻辑。抱怨者没有义务提供建议，告诉你我不舒服，不能这样，并且告诉你原因，足矣。怎样能做的更好，应该是解决方案提供者的义务。 另一个出现这种现象的场景，可能是多个人组成的解决方案提供团队，团队成员Ａ对某方案提出挑战或抱怨，但无法给出更佳解决方案，总会有人喊出“with suggestion”。在这种情况下，提供解决方案是Ａ的义务，所以他不能仅仅抱怨，换句话说，即使Ａ不抱怨，也必须要with suggestion。 所以说，提供建议与否，与职责相关，与抱怨无关。因为没有建议就不接受抱怨的做法，是荒唐的。那些接受抱怨的人，最好别要求必须要有建议，因为很多时候，找到解决方案是你的职责，是应尽的义务！ 虽然要求抱怨者提出建议是没有道理的，可从另一个角度说，提供建议确实是使抱怨更有价值的一种附加价值。这取决于抱怨者的能力，需要修炼。 ——有感于某管理部门厉色要求抱怨的同事『给出建议』而发 『你们吃皇粮的，自己狗屁不懂，还要求别人去编律法，岂不是白吃俸禄』