这是我一直想写的内容，本来是希望把这个项目从立项到规划，到设计开发，到最后的实施应用的全部过程写成一个笔记，但工程浩大，就先把我们规划这款
ITSM系统的想法写出来，里面会夹杂着我对这类系统的深入思考。
这种考虑一是基于对ITIL的理解，二是对软件实现的理解，三是运维管理的考量。内容不会十分具体，因为每一个部份基本都是一个模块，如果写得深入，就是一个详细的设计说明书了。下面逐步展开说明。
一．系统目标
系统目标是为了说明我们想开发一个怎样的系统，想利用这个系统做什么，达到怎样的目的。最简单的是，我们想打造一个运维平台，把我们在各个地区分布的运维服务团队，无论属于哪一个客户群的，无论是属于哪一种业务领域的（桌面、网络、系统、软件），都统一纳入到一个相同的平台上。
他们要基于相同的制度，基于相同的流程，基于相同的理念，用统一术语与方式去服务客户。我们的一个优势是规模与平台资源，但如果我们的人员与业务无法整合到一起，这种优势就不复存在，反而可能成为一个负面原因。因为你没有了大船的承载能力，也没有小船的灵活转身能力。
运维服务业务有其特点，很难标准化，太容易受客户的影响而改变流程或制度。一旦你的团队分散、客户多，而且地理分散，光依靠发布ISO20000的体系文件，对人员做扎实的培训，就指望把大家的各种作业规范统一起来，不是说不可能，极难。运维服务数据极难分析与采集，一个显而易见的方式就是利用软件。
我们在打造自已的平台时，概括来说，有这么几个方面要求：
①设计要求：基于我们的运维服务业务特点，把我们的管理经验置入其中，同时纳入ISO20000的实施所得，就是我们的服务体系。还要参考REMEDY优缺点，这些是我们规划设计这系统的基础。
②范围要求：我们这个平台要能管理所有的运维对象（各种类型的项目），同时要管理我们的运维资源（人）。运维对象可以具体到具体每一个CI及其备件，运维资源具体到每一个人的工时利用。其它像服务目录与SLA等，都要纳入管理。
③扩展要求：运维平台可以满足公司模式的发展需求，以及产品的发展，这里涉及具体的公司现状，就不多作说明了。
④质量要求：在应用质量上我们要超过REMEDY，注意是应用质量，不是指功能，功能上我们无意与REMEDY去一争长短。我们有信心只要一年实施时间，就完全可以超过REMEDY在公司的应用质量。
二．系统架构
我们使用的是B/S系统架构，这是为了方便地理分散的员工使用，也是考虑到日后全国的用户可能会登录系统进行部份作业，比如参与调查，或者开放论坛等。采用B/S的架构，负面的影响一是速度，二是界面表现力，但日后的升级维护比较方便，用户登录也很方便。是否成功，要等日后大规模应用时才能进一步验证。
开发平台是.NET2005 C#，数据库采用ORACLE 10G。另外我们在流程中（比如事件升级、派单）做了一些邮件通知与短信通知的功能，其它技术方面，倒没有太多值得说明的地方，也可以说技术并没有太多的亮点。
三．流程控制
在系统流程控制方面，放弃了采用工作流引擎的想法，一是不希望增加项目复杂度，二是硬性的流程事实上不现实。因为在运维服务活动中，单据的流转方式很难硬性定义，加上一人担负多个角色，去配工作流没有太多意义；同时我们主要是自用，运转起来后，去调整流程的可能性较低，那样工作流引擎存在意义就很低了。
所以我们在开发过程中，一旦有硬性的流程就写死在程序中，而单据的流转是由人确定的，可以不做限制进行单据的转派。不能指望软件去实现一切控制，有些控制点放在系统之外，往往会更好更省力。
软件只是一个汽车，你想它跑得更快更好，需要有一条道路去配合在一起，这条路就是你的管理制度。许多寄望软件实现的控制点，一旦没有考虑清楚，最后会带来许多麻烦。所以要有先松后紧的策略，逐步增加控制，而且要以制度为先。
四．服务台管理
事件管理与服务台管理是不同的概念，前者是一种流程，后者是一种职能，许多人没有搞清楚这两者的关系。事实上事件管理的许多操作是由服务台人员完成的，服务台本身并不存在流程（注意这是站在ITIL流程的层面），服务台管理本身也是一个独立的学问。
这要根据每个组织的特点去考虑，在我们的情况中，有几名独立的热线人员作为服务窗口。对这些人员的话务管理是通过语音系统管理的，而这个语音系统与我们的ITSM系统是有接口的，真正的事件操作事实还是在事件管理中完成。
这里特别提一下，在我们的ITSM系统中，事实上是没有一个服务台管理模块的，我相信许多人没有真正理解服务台的含义。把热线与服务台划等号是有问题的，尤其是IT服务领域，一旦你包含比较多的软件项目，服务台就一定会发生变异。如果你的服务台人员只是起到一个转电话与派单的作用，那事实是一个语音菜单的功能，这样的服务台设立意义不大。
多数人以为服务台作用是单点受理以及快速响应，但这更多只是手段不是目的。服务台并不一定在物理上坐在一起，它可以是多种多样的，一定搞清楚服务台的目的是什么，它为什么而存在。IT服务不同于其它的行业，当用户打电话到携程与招商银行的的服务台时，跟打电话到一个IT服务商是不一样的。携程与招行的服务是“大众”与“标准”的，他们的服务台基本可以做到你电话过去就能响应，而IT服务商的服务台通常做不到，为什么？
因为你的服务更具“纵深”，所以对你的服务台提出了更高的要求，你让几个完全听不懂用户问题与需求所在的热线非常快地接到用户电话有用吗？响应的定义是什么？如果仅仅是接听了用户的请求，而不做任何反应，这叫响应吗？
共4页: 上一页 1
[2] [3] [4] 下一页
责任编辑：
评论加载中…
0631-3653338
站长中国编辑部
收藏本文
打印本文
告诉好友
投稿邮箱
