关于成功的故事

关于成功的故事

作者：庄德珍

来源：《CAD/CAM与制造业信息化》2013年第10期

成功案例多数情况下是软件厂商和用户初次接触的见面礼，有时也会成为最终合作所要求的、必要的正式文件。软件厂商希望以此作为宣传的工具，对于企业用户本身的宣传也不无裨益。

编写软件实施和应用成果的案例，通常是软件厂商发起和推动的。一般来说，软件厂商希望通过案例来显示自己的技术优势和在某个用户处实际应用的效果，最终达到扩大宣传、证实自身价值的目的。

软件厂商都会比较重视案例的出版，并在长期的实践中形成了一套成熟的做法。例如，内容和格式常常包括：用户的背景介绍、面临的业务挑战、如何选择软件厂商、项目实施包括那些内容、实际应用价值如何、未来的期望……其中，非常重要的两点是：①实际应用价值或者业务收益的量化评估；②用户领导和技术人员的正面评价。

可以这样说，一方面，成功案例的确是软件厂商的宣传工具；另一方面，一个要公开发表的案例，表述了企业用户实际应用的成果，从形式上又是用户对自身工作、经验的公开分享。那就意味着，用户需要同意案例中的每个字都是自身真实意思的表述。

实际上，成功案例是双方共同工作的成果，体现了双方都认可的内容。由于这一点，再加上原本这件事情多数情况下是软件厂商鼓动的，很多软件用户在案例编写上都呈现出非常谨慎的态度，主要的原因包括：①不愿意为软件厂商背书，特别是看不到对自己的企业有什么好处的时候；②担心商业机密的外泄；③牵扯的工作量和复杂的内部审批流程。

与此矛盾的是，对于企业用户来说，虽然在编写关于自己工作成果的案例时有些顾虑。但是，企业自己在接触一个软件公司的初期，却非常希望能看到类似的成功案例，期望对软件厂商及其解决方案有更多的了解。

成功案例常常是软件厂商和用户初次接触的见面礼，有时也会成为最终合作所要求的、必要的正式文件。尤其在建立用户信心、软件选型、甚至在合同内容中发挥着非常重要的作用。 将心比心，成功案例看来的确是必要的。

编写案例的难点主要在于如何使双方都能认可这项工作的意义，并最终能批准成功案例文件——这种批准不但表明了企业用户对文件内容和表达方式的认可，同时也表示其授权该文件在何种范围内、以何种形式下被使用。

经过企业用户和软件厂商多年的努力，软件使用情况变得越来越好以后，企业用户会逐渐认识到这项工作对企业本身的好处，并愿意与软件厂商合作宣传，比如：①如其他产品研发技术一样，用软件支持产品研发已经成为创新手段之一，企业愿意宣传和表明自己的技术创新能力；②驾驭复杂、大型的软件解决方案，并成功地应用在业务流程中，体现了企业的管理创新能力；③跻身本行业一流企业之列，与一流的软件厂商合作，同品牌、产品、服务和管理等要素一样，同样值得宣传；④对自身行业发展的贡献；⑤对自身IT战略和IT团队的肯定和褒奖。

在一些公开的媒体报道中，我们可以看到一些如下的案例阐述。

◎“设计出国内第一架全机电子样机，在国内第一次实现了整机研制三维设计和电子预装配，从传统设计一步跨越到国际水平。”

◎“通过系统的项目办公室，实现了多项目的同时管理。项目办公室集合了所有研发项目的信息。只要通过项目办公室的业务地图，项目管理层便可查看多个项目的实时状况，并且可以逐个追踪项目明细，做出合理的评估、指示。项目办公室增加了IT项目管理的透明度，为项目决策提供了实时的数据支持，提高了决策准确率。”

◎“建立覆盖全集团的集中、透明、控制、共享信息平台，消除以往信息系统分散建设形成的信息孤岛，实现集资金流、物资流、信息流和价值流于一体的资源整合调配体系，建立公司集中、高效、统一的管控机制，为公司实施组织结构、管理模式和业务流程提升提供支撑，增强公司对市场变化的快速反应能力及适应力。”

◎“解决方案不仅带来了直接收益，同时实现了以信息整合、数据分析、销售机会发现、营销名单分配、渠道沟通、销售过程管理和效果反馈为关键结点的闭环营销管理流程。”

类似这样的描述，初读时，感觉上言之有物，确实不错。不过，看得多了，会发现并不解渴，尤其是对一个刚刚迈进这个领域、希望用类似软件解决业务问题的企业来说。

即使在企业用户百般追逐的情况下，成功案例也很难为用户提供其所期望的内容：无论是详细的程度，还是全面的程度——参考的意思大概是聊胜于无。

这就是理想和现实之间的差距。

成功案例能提供的信息，充其量包括：哪个企业、在什么时候、做了什么以及有何成就等几个方面。而至于 “为什么？如何做？有何教训？ ”，通常是寥寥几句、言语不详，甚至从不涉及。造成这种情况原因多为： ①篇幅限制； ②可披露内容的顾虑 ——尤其是那些敏感行业、上市公司和商业竞争领域。

在有限的篇幅中只能提供最重要的信息，以软件厂商和企业用户的角度而言，最重要的是希望读者能了解 “做了什么、有那些收获 ”等。而且， “一些量化的数据 ”不适合提供太多。一

方面，像屡受质疑的统计数据一样，数据依赖于出处和统计方法；另一方面，很多企业由于以前的粗放管理方式，很难提供一个软件应用之前的基线数据，因而，软件系统应用之后的数据失去了可比较性。

其实在这方面，企业用户不必过分担忧。因为读者都会理解：关于成功的故事是当时情况下的一个表述。除了法律和竞争因素，提供一些数据或者详细的信息的确对读者帮助较大。 至于 “为什么？如何做？有何教训？ ”等方面的信息，虽然对其他用户的参考价值非常大，但几乎不可能放在成功案例中。这既是一个明要求、又是一个潜规则：成功案例用于企业用户和软件厂商的共同宣传，不能出现有可能导致负面影响、甚至不能出现可能导致负面猜想或者推断的内容。因此，软件实施和应用中的挫折和失败当然不会提及，往往都会简而化之、或者处理成适用广泛和空洞的文字。因为如果提供详细的信息，可能会被推测出企业当时或现在的业务水平。这种情况，非常像大家私下讨论的那样：保密的原因不是担心你知道我有多先进，而是担心你知道我有多落后。

如果一个企业用户需要了解某个软件厂商或者其解决方案更多、更详细的信息，就需要多种方式的组合：成功案例是个开始，还可以现场参观该用户、与同行交流、与更多的用户交流……有三个词与成功案例相关，并经常被软件厂商使用： Reference、 CaseStudy和 SuccessStory。我们看到的成功案例大概都应当归属于 SuccessStory之列，因为，如果是 CaseStudy的话，我们理应可以看到中肯的分析和评价——无论好坏。

对于用户而言，积极通过成功案例了解软件、参与成功案例来宣传自己，是值得鼓励和赞扬的。但同时，也要心态平和地处之以Reference Only。

第三方观点：

由于对业务渗透的深度会参差不齐，成功案例中对业务的剖析也就有深有浅：深的，可以在软件推广中起到抛砖引玉的作用；浅的，确属聊胜于无，这时，只能姑且把它作为软件发展履历中一个 case的一笔记录。如果用户很难有感于软件厂商的成功案例，重任就落在了软件工程师们的身上，他们需兼顾用户业务、尽可能地突出其解决方案为用户带来的利益。（文文）