郑重声明：本博客所发文章全部为原创，其他地方所看到同样文章如无授权，均为盗用！以下为本篇正文（文章是多年以来积累所写，以前主要发布于知乎，后续陆续发布到此博客）：
SAP整个系统都是脱胎于业务本身的需求，没有业务也就不需要ERP了，也就没有SAP了。
因此笔者认为我们所有的方案的基本出发点就是业务本身，我们所有的方案都应紧贴业务去考虑，所以我认为SAP方案设计的第一原则就是“以业务为导向”，下面分几条来谈一谈SAP的方案如何设计。
以实际业务为导向，笔者认为这是最重要的方案设计原则。以实际业务为基础进行设计方案，同时要考虑业务间的相互关联，避免顾此失彼。
当然，方案不能仅仅考虑业务细节，更要从业务整体入手考虑，或者说从流程入手考虑，因为细节总是包括在整体中的，整体问题解决了，细节问题往往也就解决了。
我们需要强调的是，“以业务为导向”的意思并不是说现在的业务是什么，怎么做的，就是把现有业务原样搬到系统里就行了，而是考虑如何优化现有的业务。
所有的改变都是以现在的业务为基础的，对业务了解越清楚，越有利于我们根据以往的经验设计出切实可行的方案。对于不合理的业务流程，我们不仅要指出其不合理之处，更要给出解决问题的方案，并要说清楚方案执行落地的前提条件以及带来的好处。
另外，在考虑实际业务时，不要花费太多精力在一些不重要或者占比很小的业务流程中。
在实际项目中，我们遇到这样的情况，一些特殊的业务场景，是用户日常工作中比较耗精力的，用户会愿意花很多时间去诉说这些特殊的业务，并希望能够满足他们这些特殊业务的需求。
实际上，这些特殊业务场景，往往占正常业务比重并不大（也往往的确比较牵扯用户的精力，这些业务往往是因为不断的拓展企业本身的业务范围衍生出来的，比如原来主要做某个产品，然后发现某个产品也能做，就逐步拓展产品线，结果量不大，却占不少精力），这些业务即使讨论了，第一不会有特别好的方案的，第二即使设计出一个方案，最后往往不了了之，因为方案无法执行。
对这些特殊业务，笔者认为比较好的办法是告诉用户，我们会考虑的，也把问题记录下来，然后自己该干嘛干嘛就行了，最后问起来，给一个能够手工处理的方式就可以了（前提是判断这个特殊业务的确是系统层面很难解决的，那就不要花费冤枉精力，做吃力不讨好的事情了，以为即使做了，也不满意，不做，也不满意，反正都是不满意，那还不如不做，至少成本节省下来了，后面慢慢说服嘛）。
2. 以标准流程为重要参考（注意：非唯一参考）。
为什么这么说呢，我们前面谈到过，成熟软件往往包括的大部分是标准化的流程，引导企业往标准流程靠拢，这其实对企业和顾问都是有利的。
一句话，能用标准的就不要开发。我们讲SAP历史的时提到过，SAP的创始人就是为了做一套标准化的软件才创立SAP的，我们当然要以标准流程为重要的方案设计依据了，这也是风险最小的。备注：一定存在标准化软件功能不能满足的需求，而且目前来看，个性化需求的确越来越多，如何满足个性化需求？永远是值得讨论的话题。
3. 可行性。
方案不可以仅从系统角度考虑，还是考虑企业的实际情况，比如人员的素质、网络情况、实际业务的执行过程、工作环境、工作量、工作流程复杂度是不是支持这个方案很好地执行和落地。如果方案本身很好，但是不具有可行性，我们宁可选择方案虽然不是很好，但执行性比较好的方案。
4. 兼容性。
方案不仅仅要考虑现有的业务，也需要考虑业务将来的变化，所以方案不宜设置的太死，就像开发，代码都写死了，后面就没法调整了，也就是说方案也需要考虑将来调整的便利性。这方面尤其体现在组织架构方面。 5. 整体性。
SAP作为集成性很强的一个软件，我们设计方案时还需考虑对其他模块的影响，如果拿不定主意，就请别的模块顾问一起讨论确定。
