经过了一年半的四大工艺锤炼后，老板让我开始转型方案顾问SA（Solution Architect）。 我问：“SA要做什么？ 我从没做过！ ”老板回答：“就像你之前做的那样，把用户需要的功能串联起来，讲述一个完整的故事。 ” 好吧，由于在前一个项目中，我开发了很多功能，但自己都不清楚具体在什么场景下该使用哪些功能，于是我尝试画了流程图。 老板看后认为我有潜力，便果断地将我推向了SA的岗位。 

我第一次担任SA是在一个整车厂的PLM项目中。 在完成调研后，我对客户的业务依旧感到模糊不清，不得不厚着脸皮请求客户的业务代表帮忙绘制业务流程图。 在得到了业务流程图后，我便开始思考如何将系统功能与这些流程对接。 除了已经熟悉的功能外，我常常查阅线上帮助，有时翻阅到深夜，希望能找到更优化的解决方式。 想方案想到半夜，做梦时也在思考方案场景，突然灵感迸发时，我会在睡梦中急忙醒来，打开电脑将想法记录下来。 压力之大，我曾几次半夜给老板打电话，哭诉自己不知道如何才能让方案系统化，如何才能清晰地表达用例场景，如何确保每个细节都考虑周全。 项目实施过程中，客户还临时要求按照CMII标准检验项目交付物。 经过两年的磕磕绊绊，终于项目顺利完成，交付物也被该客户正式确定为标准。

03

锤炼进阶

2006年底，我被借调到深圳参与一个PLM项目。 这个项目号称汇聚了原厂六大办公处的精英资源。 加入时项目已经经历了两个月的调研，我根据调研结论设计了系统实现方案，并与客户进行了讨论。 在交流中，我发现其实有一种更便捷的方式可以实现客户需求。 经过沟通后客户表示，他们希望我们先了解系统如何实现，然后再考虑最合适的业务方案，而不是完全按照他们的想法来进行设计。 这一过程中，我第一次遭遇了思想上的冲突：在项目实施中，是否应该明确区分业务顾问与方案顾问？ 业务顾问是否完全不需要考虑系统的实现方式？ 

2007年，我参与了广州某模具厂的售前项目。 客户要求我们证明实施能力。 应老板要求，我整理了项目实施每个阶段的交付技术文档，并规划了文档章节内容。 这些文档后来成为实施方法论和交付物标准的雏形。 而在实施过程中，客户要求在方案报告中写明必须满足某个需求，但我坚持不同意，因为该需求并不明确，难以清晰表述如何实现。 为此，我与项目经理争执不下，认为方案应明确指出系统如何实现，而不能光写虚无缥缈的内容，给实施顾问和开发顾问埋下不必要的风险。 最终，在老板的仲裁下，项目经理同意说服客户，要求客户在需求明确后再开展进一步讨论。

2008年，我参与了上海的一家电子行业项目。 这个项目进展顺利，客户非常配合，最终实际工时与预估工时之间的差距只有10天。 尽管项目本身很顺利，但让我印象最深刻的却是客户说的一段话：“你在与我们讨论方案时，总是站在客户公司的角度去看问题，判断怎样对公司最有利。 但有时你忽视了我们各部门的利益。 ”这让我深思：作为方案顾问，设计方案时是否应该始终站在客户公司的整体角度，而不仅仅是迎合某些关键用户的个人需求？

2008年底，我加入了大陆服务团队并开始担任技术经理。 我花了三个月时间重新梳理方法论，同时完善了实施过程中所有交付物模板，作为PLM项目实施的标准规范。 然而，在推进过程中，我遭遇了强烈的反弹，许多人质疑为什么方案顾问需要了解系统功能？ 为什么实施顾问必须具备编写开发规格的能力？ 为什么要写如此多的交付文档？ 这些疑问让我的老板承受了巨大的压力。 正巧此时，合肥有一个项目，老板决定让我亲自进入项目，向大家证明我所提出的方法论是行得通的。 

于是，我加入了这个备受瞩目的轮胎项目。 项目异常艰难，主要原因有两点：第一，轮胎产业兼具离散型和连续性特点，这让习惯于制造业PLM项目实施的顾问在理解业务时遇到了困难，项目最终导致了一名项目经理和一名方案顾问的离职； 第二，客户希望实现全参数化智能设计引导，而公司内部的资深顾问认为这个想法不太现实。 但我认为，客户有清晰的思路并愿意分享他们的知识，这对客户而言是一次创新且富有巨大价值，为什么不尝试一下呢？ 在提出这一概念并向客户副总汇报后，以两个月的项目延期为代价，我们最终成功完成了几个设计引导专家系统的实施和交付。 

项目的复杂性让一位拥有十多年经验的资深开发人员感叹：“从未遇到过如此复杂的开发逻辑，一个功能竟然需要两天以上才能完全理解其规格。 ”实施过程的艰辛也让客户的一位关键用户在深夜两点多恳求项目组：“拜托，你们休息吧，回酒店去休息吧！ ”

在测试阶段，还发生了一个有趣的插曲，用户后悔之前自己坚持的某个实现方式。 我的小徒弟有点幸灾乐祸地说：“谁叫你们当初不听方案顾问的意见，吃亏可就在眼前了。 ”这让我觉得又好气又好笑！

这个项目后续进入二期，并由客户自行负责三期实施。 这个过程证明了作为方案顾问，必须深入了解系统功能，才能确保最终落地的系统与方案保持一致； 实施顾问则需能够编写详细的开发规格，才能让开发人员在不了解业务背景的情况下，能够准确实现方案中定义的功能； 同时，完善的项目交付文档也是至关重要的，它能够确保后续项目执行和运维的顺利进行。

去年，当我再次踏入这家客户公司时，客户说他们认为PLM业务当年已经梳理得非常清楚，除了因已经使用了十几年系统性能稍有变慢之外，其他方面完全没有问题。 听到这番话，我突然意识到，这就是对方案顾问最好的认可吧！ 

2014年，我从Teamcenter平台转换到3DExperience平台。

为了争取第一个完全依赖中国本地能力的非外方支持的PLM项目，我再次加入项目组。 通过与项目组资深实施顾问的紧密合作，我逐渐深入了解了系统功能和背后的数据模型。 过程中，一位资深实施顾问显得非常不耐烦，问我：“你为什么要知道这些？ ”。 我答道：“只有了解系统如何运作，我才能在制定方案时，正确引导客户，确保系统能够支持的功能被充分利用，而不会给实施团队挖坑。 ”这位顾问惊讶地看着我，说道：“从来没有哪个SA像你这样考虑问题，大家通常只是做PPT，然后要求开发出来。 ”于是，另一段披荆斩棘的旅程开始了……

这项目当时该客户已经花大量时间与金钱进行过咨询，也有一整套流程改进的文档。 在项目启动前，客户方项目经理提出了一个挑战，他说我们有完整的流程体系，也特别挑选了你们比较有经验的实施团队，那你们能不能不开展冗长耗时的业务调研而直接开始实施，但又能保障系统对需求的满足呢？ 于是，我进行了一个大胆的试验，提出了原型方案设计的实施方法。

除了调整实施方法论之外，这是我第一次担任总方案顾问的角色。 在这个项目中，每个专业领域都有负责的方案顾问（SA）。 作为总方案顾问，我的任务是确保不同领域的方案能够满足业务需求，同时保证这些方案能够无缝衔接并协同工作。 

2018年，依托多年原厂实施经验，我开启了自己全新的合作伙伴职业征程……

方案顾问确实是一个极具挑战的角色，且方案的优劣常常需要经过多年的使用才能真正显现出来。 一路走来，我十分感激那些包容我的客户和一直为我提供支持的老板。 我始终坚信，作为方案顾问，应该从客户公司长远发展的角度去思考解决方案，方案也必须具备可落地性，避免给实施团队或开发团队挖坑。 尽管在这个过程中可能会得罪一些人，但我所追求的，始终是问心无愧。

你，期望自己成为怎样的方案顾问呢？