在中世纪，教堂并不需要任何实际的蓝图就可以建造出来。主要的建造者只要对他所要建造的教堂有了一个模糊的概念，就开始着手实施。在施工的过程中，资助人可能希望做些改动，有些建筑最终以失败告终，或者建造者自己希望采用意大利或者法国的风格来建造教堂。但他并不会重新开始，而是利用他的经验加人一些修改，直到完成类似于教堂的建筑。通常，最终建成的教堂与最初的设计截然不同。有时，教堂会最终建成(比如那些一直保存到现在的教堂);有时却建不成(比如屋顶发生倒塌)。
这种哥特式思想总结出了那些不具有完整的计划或蓝图设计就开始业务工程的公司的特征。如果他们有了完整的方案，那通常也只存在于少数主要建造者的脑海里。同一个方案往往会发生剧变，以至它最终与最初的设计截然不同。有些时候，这种无计划的方法会成功(BE成为一个极其成功的故事);但大多数情况并不会成功(BE的屋顶倒塌)。
在过去，提出一个好的蓝图是非常困难的尝试和失误中吸取经验和教训。SAP正是在成功的和不成功的BE项目的集成上建立的，它创建了一个“蓝图”(即业务工程参考模型)，可以从工程的开始阶段(包括评价和分析)直到最终的实施，为公司提供指导。
神州数码erp模型的基础是R/3系统。这个蓝图是对R/3的定义性描述，它对R/3系统的主要流程和业务解决方案提供了全面的介绍，而不必要求用户了解具体技术细节。通过R/3系统的蓝图，SAP设计出了一种既符合逻辑而又灵活的方法来建造和优化业务流程。这个蓝图就像一个既能概览又能细看的地图集。这些“地图”是以R/3系统的完整参考模型的形式表现的。这个蓝图可以帮助公司定义自己的需求并且开发解决方案。业务解决方案已经构建在了蓝图内部，因此公司不必从头开始。用户可以简单地查看蓝图，以大致了解R/3系统，打印出相关的流程模型，并分析公司最重要的领域。之后，R/3的定制特征可以辅助系统的顺利实施，并实现客户的特定业务流程链。蓝图中显示了功能、流程、信息流和组织等视图。它描绘了业务场景，并且支持导航所有流程。有了蓝图，公司只需要选择与它们自己特定需求相关的业务流程(这个任务通常只需花费20秒钟的时间，而且不必开发新的代码)。它也是用户友好的，甚至可让几乎没有任何技术背景的用户能够理解表示公司的业务对象模型。
业务蓝图(又称R/3参考模型)是业务工程的基础。作为一种采用了两种语言(德语和英语)提供模型和图示的存储工具，它的目的是清楚地描述R/3的结构、集成和功能。换句话说，业务蓝图的设计是为了说明和描述R/3中现有业务流程，帮助加速实施R/3项目，支持业务流程工程，促进客户、咨询师和SAP之间的沟通。
在图形模型的帮助下，蓝图可以帮助用户理解SAP应用的业务流程(比如财务和会计、物流和人力资源)。使用易于理解的符号和图标，模型将业务流程描述为事件驱动流程链(EPC)，明确地说明了哪些流程对于支持业务活动是重要的，以及它们是怎样链接的。因此，通过R/3参考模型，公司可以将它们的业务需求映射到一个逻辑业务流程框架中。