从产品捆绑到关系过程的客户解决方案的再思考Word格式文档下载.docx

从产品捆绑到关系过程的客户解决方案的再思考Word格式文档下载.docx

《从产品捆绑到关系过程的客户解决方案的再思考Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《从产品捆绑到关系过程的客户解决方案的再思考Word格式文档下载.docx（10页珍藏版）》请在冰豆网上搜索。

请考虑一个客户的经验：

在转接项目时，我们的供应商都有一个报告关系。

当我们想要一个宿主的解决方案，服务器专家负责，并由软件员上交报告，但我们要一个门户解决方案时，软件员则负责，服务器专家向他们上交报告。

这是一个复杂的系统，但以我的经验，只要负责的是行家，问题都解决得很顺利。

在这个例子中，在服务单位与软件单位间，上级—下级报告关系的弹性，确保了在主管开发解决方案时，业务单位可以有充足的专业知识来满足客户的需求。

那就是说，在开发解决方案时，两个组织间的等级结构是有条件的。

在不同于更改章程和业务单位所涉及到的领域中，我们把它称为，多样性与灵活性的等级安排为“备用分层结构”，Galunic和艾森哈特（1996年）讨论道，备用层次结构所代表的变化是临时的，并且客户所需的是能回应解决方案性能的机构，而不是更广泛的环境变化。

我们认为备用分层结构加强解决方案的效率至少有三个原因。

首先，备用分层结构在开发解决方案时，可以让部门的技术人员对顾客的需求负责，并代表权威。

当专业人员处理问题时，供应商更能准确验证顾客是否认可，或将来还会有的要求（见Bunderson2003）。

正如一家信息技术的董事长指出，

我们希望在我们的能力范围内将系统从虚拟化升级到数字化（话外音网络协议书）。

供应商首先给我们分配了经营小组，而不是单单一个销售人员。

这是十分必要的，一大堆的问题并不是一个销售人员或一组销售人员就能应对得了的。

这些人的确很不错，他们懂得如何把握机遇，找到双方所能接受的最佳的接触点，并能整清楚这项系统的地位。

第二，备用分层结构能更好的平衡单位（或组织）内的权力。

因此，正如先前举过的例子，在宿主解决方案中，服务部门更适合高于软件部门。

然而，在门户解决方案中却截然相反。

在部门间权力平衡时，他们更喜欢共享信息（Lusch和Brown1996）。

如果业务单位间相互共享其各自的产品，便能在产品中支持他们的互助合作，这是他们的整合变得更加方便。

另外，如果各业务单位分享其顾客信息，那他们对客户需求就有了进一步了解，是他们的产品更具人性化（Murthi和Sarkar2003）。

第三，备用分层结构通过平衡权利，更鼓励业务部门间的互补。

这就好像在部署期间和部署之后，供应商对客户需求作出了一个更全面的响应。

比如，服务单位负责的客户是需要一个门户解决方案的（此时是软件部门主管），软件部门更喜欢通过负责宿主解决方案（此时是服务部门主管）来进行相互协作，这就成立了一个更全面的供应商响应。

因此：

P1：

供应商的备用分层结构越完美，其解决方案的效率就越高。

程序记录的强调。

程序记录的强调其内容指的是供应商雇员所要记载的各方案目标，个人的职位，工作表现，和所开发出解决方案的结果。

对大量客户进行解决方案发展的记录建立了一个供应商官方的记录，其包括了高效率和低效率的经验。

（Moorman和Miner1997；

Sinkula1994）.供应商可以从这里吸取经验来验证是否完全得到了顾客的认可和更深一步的需求。

记录重审同时也作为一个管理复杂解决方案的工具。

比如，一名参与解决方案的高级程序分析员断言道，

解决方案的主要一部分是他和其他产品相比所产现的复杂性。

这种复杂性会多次产生问题，并且问题的出处与不足仍不明显。

这对于解决方案的开发与执行的期限显得尤为重要。

随着时间流逝，若问题仍然莫能两可解决不了，很可能就完不成目标。

因为，在清晰地记录一件事物时拥有一个缜密的记录过程是很重要的。

如果在供应商中一个业务单元或一个功能组记录并分享其如为顾客如何设计和修改产品的话，其他业务单位就能相应的改编他们的产品，这样就使所有的产品能很好的整合在一起。

同样的，记录重审可以确保各业务单位产品的进程，因此可以同步部署所有产品。

比如，在部署一项网上采购的解决方案时，供应商可以通过硬件单位和软件单位所提供的采购应用来安排顾客训练与服务传递相一致。

此外，记录重审确保后期部署员工在客户公司中，可以接触已成规章的详细的产品知识，并和其他顾客公司不同的用户界面。

这方面的知识，增强了对

（1）在客户公司中部署其他产品在产品中的更改的影响对后期部署员工的理解和

（2）其他系统或客户公司中的过程。

反过来，这使供应商提供更好的后期部署支持。

正如客户所说的，

他们要确保他们的销售和市场营销专家知道其进展。

销售和技术的家伙们知道其进程，技术人员和支持人员知道什么发生在我身上。

所有这些人都是在这样的循环中，对他们来说。

并不是他们的困惑。

P2：

供应商越重视记录程序，其解决方案的效率就越高。

激励外部性。

激励外部性指的是在供应商中，跨部门的员工激励措施的程度和各个功能。

几个客户和供应商注意到缺乏这种互补性的奖励制度的不利影响。

他们的观察反映先前在个小分队中为达成更全面的企业目标而进行协调奖励的调查的重要性（例如，Westphal和Zajac1998）。

比如，销售人员在完成一项交易时通常会得到佣金。

因此，如果故意延期来拖延交易的话，他们就会在对顾客是否认可和日后需求的评估上就出现了障碍。

同样的，他们不太会考略刀发展，部署，和后期部署支持的可能性。

正如一个副总裁在商务会议上所提到的。

市场和营销人员一个劲的让你去在有点线的地方签字。

然后再转移到下一个市场制高点。

好了，现在你必须要去对付那些不愿意更换他们核心产品的专业人员了。

这种状况就好像是提高其积极性去卖新产品，执行和支持员工互助，一个接着一个的。

比如，如果销售的补偿取决于顾客对商品的满意度，和售后服务的话，销售可能就不会在不考虑售后等一系列条件下说的天花乱坠。

相反，他们会督促售后等服务更好的提高效率，来提高销售额。

外部激励制度同样鼓励和他人分享核心信息。

比如，此机制鼓励销售，发展，和执行部门与客户支持部门分享其解决方案的内容，其用户，和其与其他客户系统的依赖性。

反过来，客户支持的职员可以通过更改，升级，或替代商品来更好的服务客户。

常常，核心信息却不会在跨部门间共享。

请参考一位客户的经历：

销售人员一卖出去解决方案就立即得到报酬，而不会等到3，4个月以后。

他们不会因为解决方案的好坏而影响酬金。

他们有两群人：

一群是设法得到我们的而另一群是实际上为我们完成任务的。

有时，另一群人甚至不知道另一群人在成若什么，在做什么。

我们不得不充当他们的信使。

这真是个给付款人找了个不错的差事。

外部激励性反映了协调的单位（或司）性能目标和后续奖励，从而促进它们之间的协作。

正如一位解决方案的经理说道，

如果你在不同的商业模式中拥有不同的部门，它们就会有不同的地方，并且有时会有相冲突的目标。

反过来，这些竞争目标可能在试图成为解决方案提供商，因为他们会妨碍这些部门的相互配合能力的问题。

当跨部门间的外部激励十分高的时候，各部门之间就更喜欢分享其产品设计

，在彼此的产品中相互适应，从而促进了他们的集合。

另外，如果一个部门有信心其他部门会响应自己的修改，并随之修改的话，部门很可能为顾客修改自己的产品。

这是十分重要的，因为一个业务单位要满足客户需求的话，可能要其他部门重新设计其产品，以确保在解决方案中的合作性完好。

相似的，在部署期间，带互利因素的部门跟喜欢相互合来完成在一个或多个指定方案中意想不到的补丁。

P3：

供应商的外部激励制度构越完美，其解决方案的效率就越高。

客户互交稳定性。

客户互交稳定性指的是业务员（如销售人员，支持人员）和客户在一定期间内之间的相交情况。

强大的稳定性可以开展出更坚固的联系关系或者是与客户间的“社会资本”。

社会资本向来都促进互交过程中更快的掌握重要信息，并能完善共享的观点（Burt1992;

Granovetter1973;

Gulati1995;

Tsai和Ghosal1998）。

在本环境中，

这能更好的了解客户的行业，业务，雇员，部门和（潜在矛盾的）需求，并且更确定顾客是否认可，与其将来的需求（Kalwani和Narayandas1995）。

正如一个顾客所指出的：

不要每三个月就换一家。

这么做不明智。

在那么短的时间内他们怎么能足够的了解我们来回复我们的问题并提供解决方案呢？

对一个客户的深度了解是通过客户相交稳定性而产生的，这加强了供应商能为客户提供更人心化的产品来满足客户需求。

并且，与一个客户的相交时间越长，雇员和客户间就越容易建立一个稳定的人际关系。

这些关系有助于供应商克服在产品部署期间经常出现的意想不到的问题（同见Welch2005）。

请参考一下在客户公司销售总经理的经验：

他们的联络小组非常稳定。

我们能跟他们建立关系，信任他们，保持一定联系，并合伙解决那些意想不到的问题。

我们之间就建立了良好的信誉。

我们可以在彼此事物的后端进行公正的对话，并在事情不顺利时，可以换位思考。

最后，提高客户互交稳定性对于向客户提供有效支持是至关重要的。

稳定支持的工作人员很可能有更多产品的知识，尤其是为客户部署的产品，以及它们对客户的影响所做的更改。

P4：

一个供应商的客户相较稳定性越高，解决方案的效率就越高。

进程清晰度。

进程清晰度指的是一家供应商公司明确罗列和向其雇员提供开发解决方案的过程的程度。

这包括澄清角色和责任单位和职能，规则用于指定报告结构，转让定价单位之间、开发解决方案共享客户信息，与单位与职能参与的解决冲突的机制。

这与礼仪化的概念有点像（如Hage和Aiken1969;

Menonetal.1999），但这注重于解决方案的发展进程。

重要的是，进程清晰度并不指的是一些部门对具体解决方案的生硬的计划，或各部门必须完成的；

然而，它为顾客和各单位部门间相互合作陈列出一个框架。

正如一位与会者说，进程清晰度的本质是对供应商对单位和部门"

定义规则书，但没有订明剧本"

。

一家供应商的通信副总裁所说道，

这中肯的告诉他们，他们不得不做的是什么，多个任务的协调是必须的解决方案，但同时，如果你开始订明如何做好自己的工作，这又是适得其反，因为它抑制的是必须在设计解决方案的灵活性。

职位与权责的明确有助于确保准确定义顾客要求，而非掩饰。

因为在各单位与部门间谁定义客户需求是容易混淆的（同见Meuteretal2005）。

并且，明确的指向要求个单元共享客户和产品信息来确保他们修改各自产品来形成集合。

相同的，着眼于客户的明确向导鼓励各单位使其产品更人性化来满足客户的业务需求。

更进一步，把各单位与部门对顾客的权责明细化有助于避免各部门单位间由于权责不清而引发的障碍。

正如一家供应商的系统分析员指出，

在开发解决方案中明确各部门权责是十分重要的。

这是必要的因为有不同的组件，并划分角色很有用，因为它可以避免混乱和责任不同部门与部门之间的责任推卸游戏。

这就像一支队伍，每一个人都知道他们的需