框架设定基本原则。构建框架也伴随着假设、方法以及选项--选择一些，舍弃另外一些，每一个问题都必须被架构，每一个模型都必须在一个框架内建立。
有一些问题是在构建框架时需要单独考虑的，比如风险。评估并为风险建模是构成许多模型所必需的一部分。当构建框架时，问题提出者和问题相关者产生了一些关于特定风险的想法。任何模型都必须将这些纳入框架中--虽然之后模型可能会暴露另一些同样甚至更加重要的风险。
为风险建模--就是评估风险，将其与基准比较、输出一个表述、估计约束条件等--是以非常不同的角度考虑风险问题。在框架中，为模型引入并建立了各种的风险，建模的时候，风险被明确、评估及评定。构架一个问题的风险确保风险适度，同时，那些风险的适当特征可以出现在模型中。为风险建模将导致决定被架构的风险在不同的情况中实际表现如何，构架风险是这样，构架其他所有问题也是如此。
构建框架的方式非常像摄影师构架一个图片。摄影师必须决定在最终的图片中包括什么，排除什么。风格和主题是什么、应该强调什么、以及不强调什么。选择主体、光线、焦距、景深等等对于最终的图像来说都很重要。经由一个技巧娴熟的摄影师之手做出的选择决定了最终图像表达的内容。同样，构建一个模型决定了最终的模型说明什么以及意味什么。
5.1 建立框架
用你自己的语言定义你面临的问题以及处理那个问题的方法，为了遵循说明，你将如何做？你如何去做取决于你怎样为这个问题建模。而且，你也必须为这个问题建模，事情的结果没有默认选择答案。没有所谓的对和错。仅仅在于你如何为问题建模。作为一个建模人员，你不需要发明、设计或者选择一个适合的模型。你所需要做的就是决定用问题相关者的哪些所见来作为问题的恰当框架。建模人员的首要任务是找到一个已有的框架，并为该框架生成一种客观的描述。即一种映射。发现并且映射框架的一个好方法是与人交流。
构架决策过程
基本上，定义问题会导致决定去做一些事情以改变目前的状况并且解决问题。制定决策过程的核心在于，在当前环境下做出可能的最好选择。框架要映射所有的问题，使得能够认识环境，选项和选择标准。
介绍形成决策构架过程的所有环节。这个过程起始于世界状态，们于图的左面。无论发生了什么，它之所以发生是因为感觉到一种改变的需要，是因为在现状和希望之间存在差距。
在我们的脑海中对预想的概念都有一个框架，它是这样的一个模型，其中有关于这个世界运行的方式，这种方式告诉我们什么是重要的，允许我们对世界的状态做出解释。公司也是如此，它们对预想概念构建的框架决定了公司在世界状态中的所见，通过客户关系管理(Customer Relationship Management,CRM)、及时(Just In Time,JIT)、企业资源规划(Enterprise Resource Planning,ERP)这样的商务模型框架。来告知管理者世界状态中的什么特征应当是被关注的。虽然通过为预想概念构建框架可以知道什么特征是重要的，但实际上所感知的是一个情形，其中那些特征具有特定的取值。
框架提供了许多关于情形的简化假设。假设的本质以及存在于情形之中的复杂度级别都必须被解释，并且被映射到9层决策图中。知识由信息获得，信息是汇总的数据。提供在已认知的情形下可采取的一系列潜在行为。知识是通过九层决策图所提供的特征化来获得的，然后从可获得的选项中进行选择。
行为的存在形式是战略，每一个都有相应的期望回报与之关联，并且有一个风险级别关联到那个回报。执行阶段实际上是采取行动，通过完成所有必要步骤以改变事件的进程 。
在制定决策的整个过程中，实际的结果是完全不可知的，因此在余下的过程中也呈现出困阻。虽然它是决策过程的目标，但只有在事件到期的时候才会显露出结果是什么。
5.2 确定目标
在许多建模应用中，初始问题描述依据的不是目标，而是问题持有者头脑中认定的想要的解决方案。因此，必须探查目标，并在一定程度上提出质疑。弄清楚那些陈述的目标如何起作用，或者它能实现什么。问一问为它为什么被认为是一个适合的目标，它还能实现什么；问一问一个完美的结果应该是什么样的，以及为什么这样的结果无法实现。
你要一次又一次地试着以这种形式表达你的目标：“这个模型的目标是主要根据......来描述的，其次是根据......来描述的。”表达中的空白处可以填入“顾客”和“收益”，或“回报”和“产品故障”。就是这种“构建依据”技术将帮助其明确建构模型的目标。
根本上，构建工作的完成是根据对模型的需求。这是对我们如何回答任何问题的一个简单扩展。也许有人会问你想从下一个工作中得到什么。你可以依据薪水、下班时间、工作满足感、职业发展或者是对娱乐的愿望来进行回答。一个包括了所有可能项的完整答案是永远适用的!几乎可以肯定，提问者有一个对头脑中答案的特定表达，在探索一个模型的构建依据时也是如此。
简单说，模型放入其中的框架，提供了模型产生的意义。甚至可以说，框架实际上创造了模
型产生的意义。
5.3 问题和决策
只有存在一个确定的问题时，才可以建立模型。在业务中，建立模型事实上就是为帮助解决问题。“存在问题”这样一个事实就意味着在决定采取哪一步行动上带存在着一定程度的不确定性。消除这个不确定性，并确定采取什么行动流程，就需要一个决策。一个决策在可采取的各行动流程中进行选择，并针对选择结果，谨慎地在事件进程中选择一定特定的干预。建模的目的是为制定决策提供信息。
模型可以在三个方面帮助决策：
1) 明确风险。
2) 确定选项。
3) 评估可能的结果。
5.3.1 决策符号
业务建模和数据挖掘只支持一类特殊的决策制定：理性决策制定。即不包括直觉、反应的或优先级的。另外对那些看起来完全不会被制定的决策。也不包括其中。
理性决策：经过深思熟，经过了分析和综合推理论证的。
决策由以下各个部分组成：
情形(situation)
选项(option)
选择(selection)
预期(expectation)
行动(action)
结果(outcome)
5.3.2 决策图
框架模型所需的是一个关于理性制定的决策图。决策图包括9个层次。从第1层到第9层，复试度逐渐增加。小圆圈代表情形中离散的元素或论题、选项、或问题的期望的片断。单个圆圈代表一个单独的元素或问题、图中，用虚线连接的三个圆圈表示这里有几个简单关联的元素，它们之间相互联系被认为对这个模型是不重要的。而图中多个圆圈被实线连接在一起表示这里有多个元素，它们以复杂的方式相互联系到一起，且这种联系的性质与元素本身至少同等重要。
第1层显示了一个需要决策的单一情形。只有一个选项被认为是可行的，且只有一个对应这个选项的期望结果被认为是有关的。
第2层显示了一个单一的情形和选项，但是有若干个独立的期望结果，这些结果简单地联系在一起。
第3层显示了一个情形，若干个简单连接的选项和若干个简单连接的结果。
第4层显示了一个情形和一个选项，但是多个结果通过复杂的方式相互作用。
第5层显示了一个情形，若干个简单连接的选项，若干个复杂交互的结果。
第6层显示了一个情形，若干个复杂关联的选项，若干个复杂关联的结果。
第7层显示了若干个复杂交互的情形，若干个简单连接的选项、若干个简单连接的结果。
第8层显示了若干个复杂交互的情形，若干个复杂交互的选项、若干个复杂交互的结果。
第9层显示了若干个复杂交互的情形，若干个复杂交互的选项、若干个复杂交互的结果。
5.3.3 建立决策框架
决策图是建模的有力工具。确认决策属于图中哪个层次可以呈现给建模人员很多要处理的问题和要做的假设，即使这些假设是在无意中做出的。记住，当在图中识别问题的层次时，将要映射的并不是实际的世界状态。对于任何问题，实际世界中的条件都是非常复杂的。问题持有者将衔对问题做出很多简化性的假设，真正在图中定位的问题是呈现在建模人员眼前的问题。所有情形组成部分已经被有效地简化为一个简单的问题。对选项和期望也是如此。因此，通过将问题填入决策图来为问题构建框架清楚地提示了决策过程中的很多假设。揭示它们意味着它们不再是隐藏的假设，而是经得起质疑和修改的。
在决策图中显示，一个问题被分解为三个组成部分：情形、选项和期望。
5.4 为情形建模：将决策与世界观连接起来
情形：就是在真实世界中相关事物的当前状态。
情形的难点在于我们对世界的看法是由我们用于看待世界的模型决定的，这样一个模型构架了我们对世界的见解。一个建模人员想从零开始来世界观是不太可能的。建模人员必须仅仅采用客户正在使用的任何世界观模型，或客户希望在将来使用的世界观模型。这类模型被称为“框架模型”。
框架模型用于识别世界中特定的、重要和相关的方面。在制定一个决策时，框架模型只是指出什么是重要的。情形模型则是关于框架模型所认为重要的牲的一组值。情形模型是对框架模型所指出的重要且相关的事件的一个单一、特定的表述。
对业务建模而言，框架模型很多。这样的框架模型被称为业务模型。每一个业务模型都构成一条特定的、全业务过程的理性的路径。
制定业务决策由问题持有者所选择的框架情形的业务模型开始。当透过所选的业务模型观察时，业务情形代表世界当前的状态，所以问题持有者和建模人员是透过“CRM有色眼镜”看世界的。眼镜的“颜色”定义了他们所看到的，这个视图就是业务情形。这样构建框架之后，决策的情形模型就建立起来了。
在几乎所有的业务决策中，建模人员从不需要建立一个框架模型。第6层以下的所有决策都将复杂的世界简化为单一问题。这个单独的问题相关者在面对这个问题时故意决定将它的复杂度简化至单一问题的水平，要么是没有察觉到有其他相关问题的存在。记得一个情形模型最初只是框架模型中的值的一个单独的实例化，即使在最完整时也是这样。建造一个完整的框架模型绝对是在需求之外的。在构架决策之前，采用的是业务（框架）模型。
5.5 选项：评估可能性
5.5.1 战略：对行动的计划
5.5.2 战术：实现战略的实际行动计划。
战略和战术是相对的。在它们之间没有可以基于二者特定行为的绝对区分。
完成工作的所有细节都被包含在战术中，作为战术，可以在缺少进一步指导的情况下执行。而且，回报不是由直接行动带来的。而是由战略带来的。这就是战术和战略在建模上的不同之处。战术自己不带来回报，它只是执行战略给出的决策。但是战术也可能很难从战略中区分出来。为方便起见，战术可以看作是没有回报的特殊的战略。
5.5.3 连接战略回报
当选项被连接到一起时，表示回报音的相互联系是很重要的，也就是说回报会根据执行哪些或哪一套战略而发生变化。设想现在有两个战略明显相互联系，为方便起见，我们称在现实世界中执行动作序列为“激发”战略。在只激发战略S1、只激发战略S2和同时激发S1与S2时，将会产生不同的回报。
5.5.4 将战略链接到一起
战略的联结并不是通过联结回来完成的。战略是在行为序列中串联在一起的。通过某种方式，一个战略图必须能够反映出哪些战略是潜在地可能被其他战略激活（或激活其他战略）的。
将依赖关系链接起来之后，它表示战略的激活顺序具有重要的相关性。激活链接中较高层战略的回报积累了较低层战略的回报。链接的最低层是战术。
不管处于哪个层次，所有的战略都可以被决策单独激活，而且，该激活只会向更低的层次传递。
5.5.5 将选项映射到战略
只有在将问题映射到一个合适的决策层之后，才能映射选项。
5.6 期望：评估未来
我们可以用概念和风险来表达我们对特定结果的期望。
5.6.1 或许是一个有风险的业务
概率：在这里它是用来简单测量我们相信某些事件的可能性程度。本文中概率与可能性可视为相同。
在本文，不是让你必须学会计算风险，为风险建模所需的计算比在这里讨论的要更复杂，且在任何情况下，计算都能由计算机完成。在实际为风险建模时，数据挖掘是一个很好的工具。
初级统计学教程中有两种传统的计算概率的方法：分别是：
1) 根据类似事件的历史纪录，计算在一定环境下发生和不发生的比率。
2) 计算一个事件发生方式的总数，概率就是每个方式出现的次数在所有可能方式出现次数总和中所占的比例。
对于任何情况，发生与不发生的比率就是结果，可以方便地用百分数表示。风险不仅仅是某些事件发生的概率。为了展示风险的框架，需要对如何为风险建模进行一个概要性讨论。
决定风险的标准统计学方法是考虑每种结果的价值。并用这个价值乘以它的概率。这个乘积被称为期望值(expected value)。对于每个策略，将期望价值加在一起即为这个战略的期望回报(expected return)。风险(risk)这一名词的统计学应用利用一种称为方差的度量来测量期望价值之间互不相同的程度，即用某种方法测量你获得任何特定回报的可能性有多大--方差越大,可能性越小,风险越大。
5.6.2 风险选择
风险的选择依据风险目标和目标。你的目标是带来回报还是获取新客户?
有两点需要说明：
第一，在战略的框架中，明确风险目标或目标是非常重要的(风险目标很可能不止一个)。
第二，我们还需要一些更好的方法来刻画风险。
5.6.3 令人满意的收获，令人遗憾的损失
有得必会有失。我们应该分别从对损失风险的讨论和对收益风险的讨论中寻找更好的度量方法。
目标不同，选择的风险目标就不一样
5.6.4 基准
在风险评估的建立框架中发现什么样的基些个相关基准。一个战略到底有多大风险取决于它有多BRAVE！(基准风险调整期望值)----你最想要的是什么?
5.6.5 战略风险
5.7 最后的调整
5.8 为问题框架构图
展示如何对一个问题绘图的最好方法就是真正去为某个问题绘制一个图。
所有的部分都在图中，但不代表它们都必须被使用。然而，它确实可以让人意识到哪里是不需要决策的，这与哪里需要决策同样重要。
架构实际的绘图过程分为两步----一个开端一个结尾。
而绘制过程包括九步，1~3代表对每个问题而言是必须的。另外6个是否需要则由环境决定。步骤是：
开端：寻找问题的各项。
第1步：在决策图中确定决策的位置。
第2步：发现框架模型或问题。
第3步：构建所需的战略。
第4步：如果存在若干相互关联的回报，画出它们的关系。
第5步：如果存在若干相互依赖的激活，确定激活链接。
第6步：确定目标。
第7步：确定回报。
第8步：如果为风险建模，确定基准。
第9步：如果为风险建模，确定概率。
收尾：最后调整。
5.8.2 作图、建模和挖掘
模型正如以后将表明的，模拟业务情形，并通过修改业务流程产生影响。
数据挖掘无论对发现关系还是表示关系都是很好的工具。
数据挖掘的主要应用要在问题框架构建好的时候才会出现，接下来的主要任务就是确定每个战略的期望结果是什么，以便可以在它们之间做出理性的选择。数据挖掘还将用于连续评估风险。
5.9 小结
对于创建一个可用的问题模型来说，获得问题的正确框架是非常重要的。而且所有的模型都是为解决问题而建立的。要建立一个满足使用者需求的模型，关键在于发现实际的需求， 这就是为问题构建框架时要做的事。
节录自《业务建模和数据挖掘》第五章