BMX - 解决问题方法

BMX[/url]是一个草案[/url]问题解决[/url]管理方法，我已经设计了10个步骤。10步是自然的计数限制，这是有道理的。kep纳-tregoe [url=http://thinkingproblemmanagement.blogspot.com/2007/10/kepner-tregoe-houston-we-have-problem.html]， [url=http://thinkingproblemmanagement.blogspot.com/2007/11/root-cause-analysis-fault-tree-analysis.html]故障树分析[/url]，[url=http://en.wikipedia.org/wiki/Ishikawa_diagram]石川[/url]， [url=http://www.google.com/search?hl=en&q=technical+observation+post&meta=][url=http://thinkingproblemmanagement.blogspot.com/2007/10/major-incident-process.html]系统故障分析[/url]和[url=http://en.wikipedia.org/wiki/Single_point_of_failure]单点故障[/url]。然而，小轮车是我的方式，我建立了联系，使其更容易记住。该方法有助于以结构化的方式排除信息技术问题。该方法有多个检查点，以确定是否值得继续。[img=320x305]http://lh4.google.com/ronaldxbartels/Rzl7k7efNZI/AAAAAAAACX0/ODjSdaay-YM/s144/BMX.gif[/img]构建一个[url=http://thinkingproblemmanagement.blogspot.com/2007/11/tiger-team-step-1-in-bmx.html]老虎队[/url]。 A Tiger team is an expert problem solving team.检查点:我们是否拥有处理这个问题的所有技能?老虎队没有等级制度(所有人都是平等的)!2.使用[url = http：//thinkingproblobmmanagement.blogspot.com/2007/10/risk-management-as-table-by-meerkat.html] meerkat bolthole [/ url]。确定以下哪些实体中的高水平涉及问题：人，流程，合作伙伴和/或产品。记录可见和/或即时原因是重要的。还记录发生此问题的确切条件（环境）。在列出上述实体后，使用Cramp Lite对其进行风险评估。检查点:值得继续前进吗?风险是否较低且减轻了?是否有理由投入更多的时间和资源，或者它应该被记录下来并停止。3.你有一份[url=http://thinkingproblemmanagement.blogspot.com/2007/10/ultimate-test-pilots.html]飞行员的检查表吗?该检查表涵盖了发生该问题的区域。使用检查表进行调查。在清单上记下任何积极的结果。如果没有符合要求，那就从经验教训中找出清单上最可能符合要求的五个。另一种选择是查询知识库。很大一部分问题并不是唯一的，以前也发生过，并且已经被记录下来。如果知识库不存在，那么它甚至适合在谷歌中输入问题的描述并查看搜索结果!思科和微软都有技术知识基础。下面是一个用于[url=http://msexchangeteam.com/archive/category/3306.aspx]Exchange[/url]的示例检查表。检查站：是否已经在清单上击中了问题，或者是否有需要进一步的根本原因分析？4.我们现在有一个潜在原因的小样本，但需要扩大这个列表。然而，一些基础工作需要进行。我们需要创建一个完整而详细的清单，包括所有人、合作伙伴、流程和产品。将第1步中创建的高级列表扩展到尽可能详细的内容。正如Roald Amundsen[url=http://thinkingproblemmanagement.blogspot.com/2007/08/roald-amundsen-cmdb-expert.html]的方法所述，存在正确的设备和工具并对其进行测试是很重要的。作为此过程的一部分，需要提供或创建与问题有关的设置的完整图表。在处理一个问题时，第一次推出一个工具没有任何意义。在使用该工具之前，应该已经熟悉它(Amundsen使用的方法)。虽然问题并不总是与网络有关，但网络是进一步调查的好地方。 The tool sets available are network management tools like [url=http://thinkingproblemmanagement.blogspot.com/2007/10/riders-on-storm.html]Eye of the Storm[/url] or Crannog's [url=http://www.crannog-software.com/index.php?go=Product.ShowDetail&ProductID=1]Netflow Tracker[/url]. The tools use underlying technologies like [url=http://en.wikipedia.org/wiki/IP_SLAs]IPSLA[/url] and [url=http://en.wikipedia.org/wiki/Netflow]Netflow[/url], to highlight areas of potential causes. This will either confirm a network related issue or discount connectivity problems as a cause. Note any issues that are detected that could be a secondary influence to the problem. Microsoft provides an exceelant set of Amundsen tools for Exchange. An example is ExTrA which is available [url=http://technet.microsoft.com/en-us/exchange/bb288481.aspx]here[/url]. A checklist to resolve Exchange issues highlighted by ExTrA is available [url=http://technet.microsoft.com/en-us/library/aa997574.aspx]here[/url].检查点：已发现网络相关问题，并已解析。5.从上面的步骤中，我们知道了需要做什么，所以现在我们需要深入挖掘!这是Dart[/url =http://thinkingproblemmanagement.blogspot.com/2007/11/dart-fossil-excavation-step-5-in-bmx.html]的精神。与问题相关的项目应该被记录并在CMDB中可用。在询问这个CMDB时，我们应该能够提取相关事件(特别是[url=http://thinkingproblemmanagement.blogspot.com/2007/10/major-incident-process.html]主要事件[/url])、工作请求、变更和相关问题的列表。记下上面每一种类型的五种。调查列表中是否有一个项目与问题直接相关。特别是关注新的变化，因为这些往往是候选的原因。尝试确定是否存在多个与特定组件相关的故障?是否存在与这些组件相关的可靠性问题?检查点:更改或相关请求或事件是问题的原因吗?问题是否与组件故障有关?6.现在，问题变得越来越困难，我们需要找到模式并打破代码，如[URL = http：//thinkingproblobmanagement.blogspot.com/2007/11/turing-recognize-pattern-and-break-code.html] turing [/ url]将完成。调查正在使用的软件和硬件版本（此信息应记录在CMDB中）。查看最新硬件和软件版本的发行说明。调查应用了哪些软件升级，修补程序和错误修复。往往是一个问题的修复导致另一个问题。注意对符合问题的问题的任何偏差和引用。检查站：与修订的变化有关吗？7.现在是[URL = http：//thinkingprobermmanagement.blogspot.com/2007/11/dambert-step-7-in-bmx.html]毁坏者！[/ url]从问题向后工作是有用的这样做的方法是创建时间表。时间线通常用于FTA。检查站：问题是依赖的问题吗？8.把重点放在生产上，引入福特。检查与此问题相关的服务的sop。对现场生产环境中发生的事情和SOP中记录的事情进行差距分析。注意这些差异。检查站：这些偏差是在SOP中的问题的原因吗？SOP本身是否不正确？9.当你走到这一步时，问题是一只真正的狗，所以向巴甫洛夫寻求帮助。从供应商/供应商和客户/用户的角度调查问题的人员方面。与供应商和用户讨论这个问题。列出并记录以下任何问题:感知、解释、决策制定(基于知识、基于规则)和执行(技能)。检查站：我们是否处理人体错误？10.是时候安排优先次序了。我们要么充分确定了原因，要么列出了一系列潜在的原因。原因包括检查清单中的项目、知识库、网络问题、变更问题、组件故障、发布问题、SOP差距和人为错误。对这个列表进行头脑风暴，然后按照最可能的原因到最不可能的原因的顺序列出一个列表。根据帕累托原理，将原因分析集中到这一列表的前20%。不要忽视列表中的其他内容，但是当分析过程陷入死胡同时，可以将其作为一种刺激。检查点:大海捞针被发现了吗?如果没有，不要放弃，因为这个过程可以在以后的阶段使用更多的数据和信息重复，因为时间不是问题。