我眼中的BW前世

几天前忽然收到一位前辈的邀约，需要我写一些关于bw4hana相关的文章，可能后续还有其他安排。我接到消息有些诚惶诚恐，看完任务以后说实话，对我来说非常之艰巨。仔细考虑了下我还是打算先接手下来：原因一这个邀约和我今年其中一个目标一致，实施起来就与内心想法不违背；原因二近期项目安排可能会有空档时间，最理想状态是可以利用近期空档时间来写东西，当然也可能会遇到两边都要花费时间的情况；原因三第一次如此靠近梦想吧，且让我“但行好事，莫问前程”。

目前大致对bw4hana有了些了解，环境在local已经搭好，接下来先有个熟悉的过程，在熟悉的过程中的一些思考我会记录下来，当做后续写作的素材。熟悉过程不仅要看资料，还得去实践，做例子，这些都要花费很多的时间。这个过程且等以后再写出来。

12月份前同事忽然联系我，说公司最近有个sapbw的岗位需要人，问我她现在转去学bw有什么建议。我问她，之前的岗位做得不好么，为什么想转去做bw。她说，之前岗位做得挺好，只是想学点新东西，所以想转。同事之前做XXX系统，和公司业务联系紧密，其实有这个基础去学bw技术的话，对于目前岗位需求实在是太好不过了。于是我说，没问题，只要领导同意，有同事带你。不过我后面补刀：不过后面你如果发现入坑越来越深，可不要后悔了。

昨天我问她，转岗的事情是否顺利。她说这个月已经开始了，现在在熟悉系统。接着她说，其实BW好像整体来说已经过了以前最盛的时期吗？但是sap是行业巨头，所以接触了学学还是不错的，将来跳槽也有帮助，比做XXX系统要好。

她的这段话让我想起11年最初接触BW的时候。

起初我做的运维岗位需要同时接手3个系统，每个系统很零散的活儿。除BW之外，其他两个系统都是公司自主研发的产品，尚处在不成熟阶段吧，做起来也比较容易，因为不成熟就有很多bug，用户反馈问题就反映给开发人员，等他们解决了再告诉用户，一来二往经验多的运维人员就能脱离开发自己找解决问题的方案或者原因。当时运维起来最难的要属BW了，因为我发现，一我连用户问的问题都搞不清楚，不知道他在问什么；二没有培训也没有人带你。当时运维BW的只有我一个，与开发顾问还不熟；三人员流动得很快。我记得当时才做了2-3个月，就走了两个与我对接的二线开发顾问。后来才发现，这或许是正常的职业发展道路吧。

慢慢对用户问的问题和解决方法熟悉了以后，我发现新来与我对接的开发同事，他能很快找到系统的根本原因，而我仅仅停留在表面，不知其所以然。而且我发现这个过程非常有意思：任何问题的产生并非无缘无故，是因为系统配置错了，或者业务系统主数据未处理，或者逻辑错误才导致报错或者数据错误。这个追根溯源的过程，像极了福尔摩斯侦探小说里推理过程（小学时候在新华书店看了一个暑假福尔摩斯侦探小说）。后面接触多了，会发现熟悉系统的顾问能根据用户的一句话一眼看出问题来，分析能力和观察能力让我叹服。

后面就开始把各种遇到的问题及解决方案写下来，然后给用户做培训。一般来说月末是最忙的时候，财务月结完毕后就要开始核对报表，以及营销总公司专门有一个人对接月度排名报表核对。每个公司有数据分析员，暂且称之为数据分析员，她们的任务是核对报表数据，作为业务人员每个月度分发奖金的数据。关系到钱的问题，自然不容一点差错。所以那个时候经常加班查问题。

后来解决问题多了，再加上同事培训我一些系统知识，终于知道怎么在系统里面查问题。那个时候自己申请去做二线支持，领导安排了同事培训我，并且还进行了考核，只有考核通过了才能接手工作。有时候证明你自己，让别人相信你是一件很不容易的事情。

当时用户一直抱怨系统很慢，更新报表的速度比不上手工报表速度。我个人看来，一系统不稳定，包括服务器硬件和报表本身性能方面两方面问题。抱怨声多了，老板不能不下定决心决定换硬件了，但换了硬件速度还是快不起来，仍然出现dump情况；然后找模型本身的原因。当时一个首要任务是监控处理链，每天下班后要看处理链更新情况，以及出现错误以后要及时修复。比较多的原因是聚集报错，导致后面的链走不下去。本来自动化的东西一旦要人为干预了，就变得特别累赘。有时候到深夜一两点看到报表都发出去了，才安心睡下。

最后的工作涉及到模型调整，以及跟其他业务系统对接，共同来做一个大的项目。但是回过头来看，这样的项目还是比较浅的，也是我后来做外部项目的基础吧。离开公司的时候整理了许多交接文档给同事，培训时候，有位同事告诉我，我做的培训交接比她在外面收获的还多。我觉得这句话里面有些玄乎，但起码有一点肯定的是，自己的工作方式是对的。后来有次还在的同事问我个问题，我能很快告诉她答案。她非常惊讶，我说我只是以前做了详细笔记而已。记得罗永浩在他的自传里说，不管你做的是好的事情或者是坏的事情，你最终多少影响了这个世界的。

嗯，但行好事，莫问前程。