业务流程需要重组。ITIL是基于最佳实践的。不是基于方法论的。所以在应用的过程是会有些实践方式的不同

QUOTE:

---

最初由 sdsdsd 发布
还有个问题是审批往往不能立即执行，manager不可能整天坐在那里等着审批阿，有时候会拖上半天，业务部门又使劲儿催。。。

---

变更流程中Urgent Change可以很快处理变更。

我想起了一个问题，ITIL的变更流程面向运行环境，如果是开发环境，相应的流程又不一样了。原因是运行环境中变更没有很好的控制的话，很容易引入Incident，造成SLA Break.

QUOTE:

---

最初由 slayer_wolf 发布
这种显然不会增加多少成本的事情，先执行，完成了做一份记录，定期交给经理不就成了，何必这样负责的枝枝叶叶呢。

---

大公司一般分工都比较细，修改程序的人和测试，TP的人往往是分开的，没有领导的审批，下面的人是不会先执行的。。

QUOTE:

---

最初由 petertse168 发布
这个明显是没有做好服务的分级。
对于一些关键的业务，如SALE部门要更改某种产品的属性，这个对于生产或者日来销售影响很大的，这当然要经过这么多的步骤去做了。这个流程还能给在这个流程中做决策的领导一个思考的时间。
但是如果是一些很简单的业务，级别可以调成低一个档次的，就是直接到Service Desk--->IT人员---->通知SALE就可以了。

---

有道理，服务分级

QUOTE:

---

最初由 nastar 发布


用多种快捷的通知方式，比如短信、邮件等等，同时设置超时提醒，另外建立相应的考核制度，这样就能在一定程度上推动流程的流转。

---

我们用的是邮件提醒，但这要保证呆在电脑面前才可以，这是很难保证的，经常地情况是有了审批的需求，要通过手机通知，其实感觉很多审批都是不必要的，但是普华永道来审计的时候，还增加了很多需要审批的流程，真是搞不懂，难道普华永道的水平也不过尔尔？。。。

现在好多公司，尤其是外企，都在按SOX制定流程，在IT部分核心思想就是做事都要留下证据，所以每个流程都搞的特别复杂，应付审计

QUOTE:

---

最初由 pridver 发布
现在好多公司，尤其是外企，都在按SOX制定流程，在IT部分核心思想就是做事都要留下证据，所以每个流程都搞的特别复杂，应付审计

---

做事都要留下证据

流程问题不能完全由ITIL来解决

QUOTE:

---

最初由 mygreatjob 发布
业务流程需要重组。ITIL是基于最佳实践的。不是基于方法论的。所以在应用的过程是会有些实践方式的不同

---

不是基于方法论的
书上好像也是这么强调的哦

QUOTE:

---

最初由 sdsdsd 发布
还有这样一个问题：
       对于像硬件，网络或者服务器这样主要基于IT技术的IT服务，往往在业务部门提出相关需求后，IT人员在不需要与用户更多的互动交流的基础上就可以解决问题；
       但是对于像ERP这样与业务息息相关的软件服务，则往往需要IT和业务人员的大量交流和磋商，以准确理解用户的需求，而仅依靠业务人员提供的业务需求文档往往是不够的；
      针对第二种情况，在采用ITIL系统进行管理时，是从原始的需求就通过ITIL系统来进行交互还是在需求确定的情况下再提交到系统？如果是前一方法，这样的交流方式估计双方都不会满意，不如电话+需求文档的方式；如果是后一种方式，则系统沦为了文档管理系统；怎样处理才能发挥ITIL系统的最佳功效？

---

我个人觉得，还是以业务为主来考虑IT的支持问题。不了解业务需求，就无法做到支持的满足。有时候业务需求的提出仅仅考虑到业务的实现，没有考虑到IT的支持能力。从IT部门来看在明确业务部门的需求之后可能会有更好的IT建议，使得最终的解决方案比预想的要好。
至于是否会沦为文档管理系统，个人觉得，对于软件需求的变更文档还是必不可少。不论是书面文档，还是电子文档。