不同情况下新建事件、问题、变更的业务含义
学习资料： ITIL培训基地专家讲堂直播 300期视频回放我是学习ITIL的新手，对于新建问题的入口，我目前知道的两种方式，一是在事件诊断的过程中，由事件的受理人将事件升级为问题，这个的业务含义我能够理解。
那么第二种：问题可以直接新建，可以是问题经理、用户都可以新建，那么他们新建问题应该怎么用业务语言来描述这呢，（也就是说，别人怎么知道这就是一个问题呢，而不是由事件新建后发现了根本原因而升级为问题呢），对于变更我也有这样的疑问。
希望各位ITIL达人们帮我解答哈。嘿嘿，Jessica跪求解答哦
首先说问题的确可以有很多入口，如事件升级而来或者主动发起。
问题是为了找到故障的根本原因，大多是技术人员需要的结果，客户一般不关注问题的解决数量和时间。这时候你的问题只要干系人能看懂达到了找到故障根本原因的目的就可以了，没必要和业务关联，转化为业务语言描述。
也有客户要求提供问题解决的sla，这样的客户都是真正的甲方而不是用户，也一定是懂技术语言，双方约定好相关问题类型和入口定期提交报告即可。依然不要求你进行业务语言转化。
变更的问题你可以再开个主题。 回复 水杉之镜 的帖子
你的解答对我很有帮助，不过我还有一个疑问，我该怎样确定，当发现了一个影响业务和服务的故障时，我该怎样判断这个是一个问题还是一个事件，比如：”系统崩溃“这个是归纳到事件还是问题呢。 Jessica_zou 发表于 2011-5-4 14:47 static/image/common/back.gif
回复 水杉之镜 的帖子
你的解答对我很有帮助，不过我还有一个疑问，我该怎样确定，当发现了一个影响业务 ...
你可以假设你们组织里没有问题流程。所有故障都是事件流程在处理。遇到问题了马上就尽量去恢复业务。可能是重启机器把故障解决了。
这时候部门经理或者客户要求要知道上次故障发生的原因及避免方法，你再启动问题流程。 ”系统崩溃“这个是归纳到事件还是问题呢。---单纯一个简单的故障描述是无法确定是不是问题，事件肯定是了，因为事件可能触发问题管理流程。
但千万别简单的认为 分析故障的根本原因就是问题管理。两码事
页:
[1]
2