第一天。有人提到"mandant"这个词，我点了点头。我不知道它是什么——不知道这个词，不知道这个概念，也不知道它和我反复听到的"client"有什么关系。

我花了两天时间，靠上下文线索自己拼出一套理论，而不是问一个45秒就能得到答案的问题。模型是错的。直到第三周，才有人告诉我client到底是什么。这比第一周就开口问，尴尬得多。

十八年后回头看，这个教训跟SAP术语无关。真正的问题是：你以为在攒经验，其实在攒错误。

第三到第五年，我犯的那个错

那几年我加了FI，又加了CO，还碰了点MM。简历看起来"全面发展"。我不是全面发展，我是四个模块各懂25%，而不是在一个模块里强到危险。

我本来在做SD，而且做得不错。我本该在SD再待三年，成为那种定价过程崩了、项目经理晚上11点会打电话找的人。

真正早期就变得有价值的顾问，做的是相反的事。他们找到项目里最难的那块，主动认领没人愿意碰的部分。他们读本模块的SAP帮助文档，像别人读小说一样。他们找一个领先自己十年的人，花六个月观察那个人怎么思考——不是他知道什么，而是他怎么框定问题。

我没这么做。我在第三年追广度，因为广度写在纸上像野心。到第八年再看，它一点都不像野心。

深度先于广度。在一个模块里至少待满五年，再刻意扩展。广度是深度的补充，不是替代品。"通才顾问"这步棋在第八年走才合理。第三年走，只意味着你是第一个被真正懂行的人替换掉的。

一封CFO和basis顾问都能读的状态邮件

写一封CFO和basis顾问都能看懂、都觉得有用的状态邮件，是一门技能。没人教。会写和不会写的人之间的差距，在我做过的每个项目里都看得见。

我用了十二年的格式：

• 第一行：[GREEN / AMBER / RED]——一句话说明原因。
• 本周：三条。过去时。只讲事实。不加评论。
• 需要行动：[姓名]：[具体请求]，截止[日期]。每人一行。

超过一页，你写的就不是状态，是报告。如果某人没有行动项，把他从收件人里删掉。

纪律在最后一条。点名具体的人、具体的请求、具体的日期，感觉很有攻击性，直到你意识到：模糊的行动项永远不会被完成。"团队本周内审阅"不是行动项，是许愿。

技术能力让你进得了那个房间。业务理解决定你会不会被再次叫回来。

那个你该跳过的会

我以"技术代表"身份坐过的指导委员会，多到数不清。我在其中大约80%的贡献是零。不是低，是零。决策发生在我的输入根本不相关的层面，我花两个小时当个暖场的人，只为让参会名单看起来周全。

你永远可以跳过的会，是那种当你诚实回答"我做了什么决策、或贡献了什么没有我就不可能发生的事"时，答案是"我把他们本可以在状态邮件里读到的东西更新了一遍"。

值得保护的会不一样。技术架构会，你的专业判断塑造一个三年后仍然重要的决策。工作会，你在业务方和开发之间实时翻译，而翻译本身就是全部价值。复盘会，团队的流程真的因此改变。

其余都是伪装成参与度的开销。

政治版本的做法是：你不能直接不出现。我的说法是——"我可以用那段时间准备你们决策所需的技术分析。只在议程上有技术决策时我加入，可以吗？"我从没被拒绝过。大多数项目经理是松了口气。

四件我学得太晚的事

1. 写作是职业能力。被反复叫回来的架构师和首席，几乎都是能写的人。让决策变得显而易见的提案。不浪费读者时间的状态邮件。新成员真能用的架构文档。
2. 名声传得很快。SAP咨询是个小圈子。你2012年让谁显得出色，他现在是交付总监。你2016年让谁不爽，他在2026年你想去的岗位的招聘小组里。
3. 第一周就问。你担心显得愚蠢的那个提问窗口，第六周就关了。第一周没人指望你懂。第六周，印象已经形成。
4. 深度先于广度。一个模块至少五年，再刻意扩展。

我早期做过一个制造业的SD实施。配置我烂熟于心。我不知道的是，他们有三个销售组织，是CFO设计的刻意的利润隔离策略。当我提议合并它们以获得更干净的订单管理时，我差点制造出一个报告问题，把哪条产品线在拖累公司这件事掩盖掉。

懂供应链的BW顾问，胜过只懂BEx的。不是因为供应链让他技术更强，是因为他对业务更有用。

SAP生态里满是技术极其出色却停滞的人——他们能配置任何东西，却说不清这个配置决策对运营副总裁为什么重要。

在每个项目上，找一个愿意容忍你提问的业务方，请他像你什么都不懂一样解释流程。读你服务的公司的年报。理解你构建的系统对损益表的影响。这笔投资，会让职业生涯的后十年看起来和前十年完全不同。