标题: [原创] 大话服务目录
学习资料：IT运维管理社区专家讲堂直播300期视频回放以下纯属于我个人的理解，并不基于ITIL理论，在没有接触ITIL之前，我脑中的认为的服务目录就是如此，以下所讲的都是基于一个有一定规模的运维服务商而言，并不适于所有的厂商与情况：
对服务目录的最早接触是由于公司ITSM系统设计时，当里在构建配置模型时，发现需要一个纬度把我们的服务种类构画出来，我们的服务资源、服务对象与服务种类都是存在关联的，只有把这一类的信息定义出来，而且从我们服务种类中进行分析我们的资源投放，这样才能实现有效的服务管理。
上面说的可能粗放了些，说白一些，如果把IT服务商比喻成一个餐厅，那么这个餐厅的菜单就是服务目录，IT服务商呈现给客户是的服务目录（菜单），客户来点菜，这就是服务产品化，我们的能够的服务应该是可以定义清楚，同时是便于客户阅读理解的，重要的是真的知道我们可以提供哪一些服务，可能大家会觉得奇怪，难道一个IT服务商自已可以提供哪一些服务，自已都不知道吗？我相信，只有这家IT服务商初具规模，服务的领域复杂一点的话，多数情况下是根本不知道自已的服务到底有多少种的，它可能知道自已可以做什么服务活动（比如知道怎样更换一个硬盘，升级一个操作系统），但是不知道自已能提供的服务到底是什么（无法定义菜单，更换硬盘某种程度上并不是一种服务，而是为了某个服务，而需要做的一种技能活动），这种情况如果不深入现实的运维业务（IT服务）是很难有深入的体会的，多数公司把技能活动与服务没有界定清楚，结果服务目录变得没有意义，成了一种活动清单
服务目录我认为是一个运维服务商可以提供的服务的总目录，它是基于运维服务商本身的，但是又面向广大客户的，为了讲解的清楚，服务目录事实上分两个层次，第一个层面是我通常讲的服务目录是指总目录（餐厅的菜单），这是我认为的真正意义的服务目录，第二个层面是具体跟一个客户签订了一个合同后，要向客户的提供的服务条目（餐厅里服务员写的每桌客人的点菜记录，用来结账用），这里的服务条目，全部是取自总目录，我个人一直认为服务目录是指总目录（菜单），而不是指服务条目（点菜记录）。而大多数人（包括ITIL的咨询顾问）以及ITIL理论是认为后者是服务目录，我一直不认同这种看法，同时我不认同ITIL及大多数认为中的服务目录内包含的信息定义，请大家注意我以下的说明与ITIL中对服务目录的定义是不相同的，因为我觉得这种定义无利于IT服务商，服务目录对一个服务商而言，只有一份，而不是多份，服务目录的信息应该更单纯，如果ITIL认为的服务目录是正确，那一定还缺少一个对我认为的那个服务目录的定义及说明，而我认为的那个服务目录是服务管理体系中一个非常重要的一环。
以下就分别说明服务目录的一些常见问题做一些说明：
1、没有形成服务产品战略
可以想象一个没有菜单的餐厅如何管理，又如何发展，客人到餐店因为没有菜单，只能想吃什么就点什么，餐店要临时去采购材料，而且临时请厨师，事实也没有这样的餐厅，现实中，餐厅首先知道自已是做什么菜系，然后请到有这种技能的厨师，这时会订出菜单出来，然后预计每天的订单量，去提前采购相关的材料，客户进这个餐厅时，事实已被动选择了这个餐厅的菜系，然后只能在菜单中的范围中点菜，餐厅会根据客户的需求，去发展菜单。
所以现在的情况是IT服务商是本末倒置了，连自已的的菜单都没有理清楚，只知道这里提供餐饮，由于客户去任意要求具体的点菜，这时会引发一系列的管理问题，最终无法形成自已有核心竞争力的服务产品，只要没有服务产品战略，自已内部的员工招募以及员工技能培养，甚至内部的组织设计与制度，以及成本管理都会面临很大的难度，IT服务商的存在的一个优势在于专业与成本，因为客户做的没你的专业，或者客户如果想到你的专业程度，需要付出更大的成本，所以客户选择IT服务商来外包服务，但是当IT服务商没有做到服务产品化时，你如何做真正的专业？（可以想象餐厅的厨师一年到头只炒菜单上的几十个菜，一定会时间越来越短，手艺越来越精），你又如何做到成本控制？（如果你每一道菜所需的人员与材料都不一样，你服务成本会非常大的）
上面用餐厅来做例子事实上会也不合适，因为无论一个餐厅是有一个怎样复杂的菜单，服务员都可以统一服务，而厨师基本上可以应对，但IT服务商面临的问题更为复杂，只要你的服务产品之间的同性不大，你的成本很可能因为加了一条服务目录（一道菜）而成本飞升，同时带来管理的难题，所以一定要清楚自已可以做什么，而且要清楚做什么才能有优势，事实上在合同报价时，有些许多服务我们向客户要求了太高的价格（当有规模效应时，单价不应该如此之高），而在一些真正对我们成本造成影响的服务，我们要求的价格又太低了（为几个菜，单独设立了服务台（服务员），与专业的工程师（厨师）），这种现象是客户与我们自已都没有真正意识到的，这需要有一些分析才能知道具体的数据，而这些数据的核心基础之一，就是一个真正意义上的服务目录
2、不知道服务目录的信息包含哪一些，把服务目录的信息
如果把餐厅的菜单比喻成IT服务商的服务目录，这一比喻是正确的话，那我们的服务目录到底有什么信息呢？，再想想菜单有什么内容？菜名及单价，这些信息是客户可以理解，内部也可以理解的，但大多数IT服务商把具体的技能管理活动也定义进了服务目录中，比如把硬盘更换与操作系统更换也定义了一条服务目录，这是把服务目录定义得过细了，事实硬盘更换或CPU更换，事实都属于PC硬件维护服务，在常态情况下，穷举你的技能活动是没有太多意义的（如果你的桌面规模非常庞大，也有可能有意义），因为客户点菜只会点酸菜鱼，不会点让你杀，让你煮，一条服务的活动是非常非常多与复杂的，就象一个道酸菜鱼，当客人点后，你如果店内没有鱼，你需要去买，还要杀，还需要材料，还要去煎与煮，这些为了做到这条服务需要进的一系列技能活动，这些客户是不关心的。如果真要定义出来，也是IT服务商的内部操作手册（厨师的菜谱），这一类的信息与服务目录是完全不同层面的东西
还有一些信息，比如每个服务做多少次，做多久时间，谁做，这些信息同样是不建议放在服务目录里面的，我们一定要想清楚，服务目录用来做什么的，服务目录基于内部，面向客户，它告诉世界，这个组织可以提供一些服务（产品），做多少次这是由客户决定的，当客户点了你的桌面服务，他的钱多，你就做得多。至于做多久，由哪一类的人员做，这是内部的信息，对于报价有用，但只是内部信息，置于服务目录之中，只会让服务目录失去管理焦点，服务目录对合同关系，但与这些完全是不同层面的东西，不能混为一谈，比如报价，更重要的信息在合同上，每一服务要做到什么级别，每一服务的对象有多少，这才是最关键的
3、基于项目定义服务目录，是对服务目录的曲解
服务目录的设计需要根据企业资源，首先从公司层面去思考能做什么，而不是能让每个项目去定义自已的服务目录，其原因是，我们说服务产品化，到底产品化的目的是什么，不是去为吵口号，而是当服务产品化后，我们可以享受到规模优势，我们可以做得把服务更专业，成本更容易控制，同时真正定位自已的业务，更重要的是我们会可以象制造业去升级或淘汰我们的服务，或者发现某一个产品（服务）非常具有市场潜力，我们可以进行细化扩展我们产品目录（服务目录）
在这讲根据每个项目去定义服务目录，会造成什么后果，大家不会有很直观的感受，只有当你真正接触到其中才会强烈感受，如果你有50个项目时，根据每一个项目去定义服务目录时，可能你的服务目录会数千条，而这其中，80%的目录是重复的，A项目有一条系统升级的服务，B项目也有一条系统升级的服务，意义相同，可能是叫法不同，这样缺乏一个全局的战略考虑，同时技能活动与服务的界限没有区别清楚，服务目录非常多时，一定是出了问题，一个100-200人的IT服务商，说他的服务目录数千条，就根本不用看什么目录内容，用脑子想想也知道出了问题，服务目录对于具体的一个项目，事实上意义不大，根据每一个项目去定的服务目录，事实上多数最后变成一个作业计划，上面的信息是告诉项目人员每天要做什么，这事实是是对服务目录极大的异化与曲解。
对于IT服务管理而言，很多时候需要站在整个服务商的层面去分析思考，而不是站在每一个项目上去分析思考，规模、效率、专业最根本是土壤在公司整面而不是项目层面，根据每个项目定义的服务目录，最后无法做出任何对公司经营有价值的分析与统计，更无法为市场发现与经营战略提供有价值的数据统计。
4、到底哪一些是服务目录？
当一个人到餐厅吃饭时，他会根据菜单点菜，注意喔，他只会点菜单上的菜名喔，我们可以看一下，一个餐厅的服务目录是怎么做的，当一个人去吃饭时，他享受了什么？除了饮菜本身外，还可以享用了免费的茶水，还享用了服务员热情的服务，他可能还免费使用了餐厅的电话与洗手间，后面这些是服务吗？是的，在菜单上吗？不在，为什么？这种思考方法会帮助我们极大的理清我们的服务目录到底装载什么信息与内容，你可以提供桌面运维服务，你可以提供的服务是什么？你有一个怎样子菜单让客户去点菜？你会把桌面运维需要做仓库管理，桌面运维需要有服务台，桌面运维需要盘点，桌面运维需要配置管理，仓库管理、服务台、盘点、配置这些是服务吗？我认为不是的，这些只是为了达到桌面运维服务需要支撑性的管理活动或技能内容，它不属于服务目录需要记录的内容，虽然这些会耗费你的成本与人力资源，但并不表示这些需要记录在服务目录中，这种情况荒唐到需要你去吃一个餐厅时，人家给你一个菜单，上面写着，服务员记账、去菜场买菜、切菜、炒菜，端菜、端茶送水、提供桌椅、上洗手间、打电话，这些东西都是餐厅为了给你服务需要做的一系列活动，虽然这些包含服务的性质，但并不是焦点所在，客户并不关心这些。
服务目录应该列出客户需要而且愿意付费的服务清单，而支撑这个服务背后的活动信息是不应该列在上面的，虽然服务商的所有活动的成本最终是由客户支付，但这些是你在定价或报价时需要考虑的计算问题，服务目录本身是不需要列出这些信息的，就象一道菜是10元钱（清炒土豆丝才这么便宜）为了提供这个菜给客户，你需要有一张桌子，一张椅子，还有有饭碗，还要有厨师，还有材料费用，采购费用，服务员端菜等等这些都是你的成本所在，但这些并不是客户关心的，但是你关心的，虽然这些成本最终会全部分摊在客户身上，但并不表示一定需要在服务目录上记录着。
上面只说了服务目录这样做也不是，那样做也不是，那服务目录到底应该怎么做呢？有什么硬性原则吗？我认为应该没有什么刚性的原则的，但我理解中的服务目录首先是有结构的，它是多层次的，服务目录应该有一个分类，每一个类再分子类，这里会面临着与配置管理的CI分类的颗粒度一样的问题，即我们分到什么地步，分到最细时，一定会直指服务活动，这时目录已无法应用，失去了服务目录的建立初衷了，这里要考虑好管理需求；服务目录的特性不应该是经常变化的，不应该硬性以我们的业务领域去切分分类（按桌面、网络、系统、软件等作为服务目录的第一层分类，并不合适），这样做造成底层的服务目录重叠（病毒防治这是一条服务目录，但可能会在多个领域中存在），到时计算与统计会受到影响，要尽可能以不变的特性去定义服务目录，这样无论如何应用都不会造成服务目录出现问题（菜单中分了汤、菜、火锅，这样的特性就可能是合适），很遗憾我们具体的服务产品化还没有真正展开，等于我们还没有具体展开我们服务目录梳理，但我相信真正梳理的话，很快就可以完成，一至两个月就可以发布一版出来（当你真正清楚要的是怎样的东西式时，并有一定方法，真正梳理并不会特别困难），到时就可以谈得更具体些，而不是象现在这样停留在理念层面。
给象我们一样的摸索前进的同行的建议是：先收集所有的服务目录，然后进行分析总结，定义一个稍稍粗放些的服务目录，层次结构不要过深，数目不要过多，能用就好，然后运行一个周期，最好是利用一款软件把数据采集起来，这里的数据采集是把你的服务资源投放与服务目录关联起不，以便分析，每一条服务目录占用资源的情况，然后对资源占用大的服务目录进行细化，这是一个进化的过程，然后更重要的是，要考虑根据历史数据，去做计算模型，用处是报价及核算成本，服务目录定出来后，客户点后，你如何报价，你没有计算模型是根本无从报价的，或者是乱报，事实当你的服务资源（多是人员工时）与每一个服务目录形成关系后，你的所有活动都被有效归类到服务目录中，同时留下工时记录，此时数据积累到一定历史后，就可以大致推算出一条服务目录与服务对象、服务资源的成本是多少，一旦推导出这个计算模型，对这个公司的市场开拓与内部控制将会非常有用，你每年的改善点可以指明，你的成本也是非常清晰的。这正是我现在在公司在规划我们的ITSM系统时一个考虑，在实施这款系统时，我也会按照这种思路去作业。这个过程非一朝一夕之事，我估计以我有充足的决策支持的情况，帮助公司真正出台一个可以摊开给全世界去审视的服务目录，同时具备初步计算模型，需要两个财年的周期，注意是周期，并不是工作量，这种工作，需要在组织中沉淀消化，及需要时间积累数据。
服务目录就先写这么多吧，等后面我们第一版的服务目录出来时，我可能会再写一些怎么具体整理服务目录的文章。
大话服务目录
大话服务目录大话服务目录
以下纯属于我个人的理解，并不基于ITIL理论，在没有接触ITIL之前，我脑中的认为的服务目录就是如此，以下所讲的都是基于一个有一定规模的运维服务商而言，并不适于所有的厂商与情况：
对服务目录的最早接触是由于公司ITSM系统设计时，当里在构建配置模型时，发现需要一个纬度把我们的服务种类构画出来，我们的服务资源、服务对象与服务种类都是存在关联的，只有把这一类的信息定义出来，而且从我们服务种类中进行分析我们的资源投放，这样才能实现有效的服务管理。
上面说的可能粗放了些，说白一些，如果把IT服务商比喻成一个餐厅，那么这个餐厅的菜单就是服务目录，IT服务商呈现给客户是的服务目录（菜单），客户来点菜，这就是服务产品化，我们的能够的服务应该是可以定义清楚，同时是便于客户阅读理解的，重要的是真的知道我们可以提供哪一些服务，可能大家会觉得奇怪，难道一个IT服务商自已可以提供哪一些服务，自已都不知道吗？我相信，只有这家IT服务商初具规模，服务的领域复杂一点的话，多数情况下是根本不知道自已的服务到底有多少种的，它可能知道自已可以做什么服务活动（比如知道怎样更换一个硬盘，升级一个操作系统），但是不知道自已能提供的服务到底是什么（无法定义菜单，更换硬盘某种程度上并不是一种服务，而是为了某个服务，而需要做的一种技能活动），这种情况如果不深入现实的运维业务（IT服务）是很难有深入的体会的，多数公司把技能活动与服务没有界定清楚，结果服务目录变得没有意义，成了一种活动清单
服务目录我认为是一个运维服务商可以提供的服务的总目录，它是基于运维服务商本身的，但是又面向广大客户的，为了讲解的清楚，服务目录事实上分两个层次，第一个层面是我通常讲的服务目录是指总目录（餐厅的菜单），这是我认为的真正意义的服务目录，第二个层面是具体跟一个客户签订了一个合同后，要向客户的提供的服务条目（餐厅里服务员写的每桌客人的点菜记录，用来结账用），这里的服务条目，全部是取自总目录，我个人一直认为服务目录是指总目录（菜单），而不是指服务条目（点菜记录）。而大多数人（包括ITIL的咨询顾问）以及ITIL理论是认为后者是服务目录，我一直不认同这种看法，同时我不认同ITIL及大多数认为中的服务目录内包含的信息定义，请大家注意我以下的说明与ITIL中对服务目录的定义是不相同的，因为我觉得这种定义无利于IT服务商，服务目录对一个服务商而言，只有一份，而不是多份，服务目录的信息应该更单纯，如果ITIL认为的服务目录是正确，那一定还缺少一个对我认为的那个服务目录的定义及说明，而我认为的那个服务目录是服务管理体系中一个非常重要的一环。
以下就分别说明服务目录的一些常见问题做一些说明：
1、 没有形成服务产品战略
可以想象一个没有菜单的餐厅如何管理，又如何发展，客人到餐店因为没有菜单，只能想吃什么就点什么，餐店要临时去采购材料，而且临时请厨师，事实也没有这样的餐厅，现实中，餐厅首先知道自已是做什么菜系，然后请到有这种技能的厨师，这时会订出菜单出来，然后预计每天的订单量，去提前采购相关的材料，客户进这个餐厅时，事实已被动选择了这个餐厅的菜系，然后只能在菜单中的范围中点菜，餐厅会根据客户的需求，去发展菜单，。
所以现在的情况是IT服务商是本末倒置了，连自已的的菜单都没有理清楚，只知道这里提供餐饮，由于客户去任意要求具体的点菜，这时会引发一系列的管理问题，最终无法形成自已有核心竞争力的服务产品，只要没有服务产品战略，自已内部的员工招募以及员工技能培养，甚至内部的组织设计与制度，以及成本管理都会面临很大的难度，IT服务商的存在的一个优势在于专业与成本，因为客户做的没你的专业，或者客户如果想到你的专业程度，需要付出更大的成本，所以客户选择IT服务商来外包服务，但是当IT服务商没有做到服务产品化时，你如何做真正的专业？（可以想象餐厅的厨师一年到头只炒菜单上的几十个菜，一定会时间越来越短，手艺越来越精），你又如何做到成本控制？（如果你每一道菜所需的人员与材料都不一样，你服务成本会非常大的）
上面用餐厅来做例子事实上会也不合适，因为无论一个餐厅是有一个怎样复杂的菜单，服务员都可以统一服务，而厨师基本上可以应对，但IT服务商面临的问题更为复杂，只要你的服务产品之间的同性不大，你的成本很可能因为加了一条服务目录（一道菜）而成本飞升，同时带来管理的难题，所以一定要清楚自已可以做什么，而且要清楚做什么才能有优势，事实上在合同报价时，有些许多服务我们向客户要求了太高的价格（当有规模效应时，单价不应该如此之高），而在一些真正对我们成本造成影响的服务，我们要求的价格又太低了（为几个菜，单独设立了服务台（服务员），与专业的工程师（厨师）），这种现象是客户与我们自已都没有真正意识到的，这需要有一些分析才能知道具体的数据，而这些数据的核心基础之一，就是一个真正意义上的服务目录
2、 不知道服务目录的信息包含哪一些，把服务目录的信息
如果把餐厅的菜单比喻成IT服务商的服务目录，这一比喻是正确的话，那我们的服务目录到底有什么信息呢？，再想想菜单有什么内容？菜名及单价，这些信息是客户可以理解，内部也可以理解的，但大多数IT服务商把具体的技能管理活动也定义进了服务目录中，比如把硬盘更换与操作系统更换也定义了一条服务目录，这是把服务目录定义得过细了，事实硬盘更换或CPU更换，事实都属于PC硬件维护服务，在常态情况下，穷举你的技能活动是没有太多意义的（如果你的桌面规模非常庞大，也有可能有意义），因为客户点菜只会点酸菜鱼，不会点让你杀，让你煮，一条服务的活动是非常非常多与复杂的，就象一个道酸菜鱼，当客人点后，你如果店内没有鱼，你需要去买，还要杀，还需要材料，还要去煎与煮，这些为了做到这条服务需要进的一系列技能活动，这些客户是不关心的。如果真要定义出来，也是IT服务商的内部操作手册（厨师的菜谱），这一类的信息与服务目录是完全不同层面的东西
还有一些信息，比如每个服务做多少次，做多久时间，谁做，这些信息同样是不建议放在服务目录里面的，我们一定要想清楚，服务目录用来做什么的，服务目录基于内部，面向客户，它告诉世界，这个组织可以提供一些服务（产品），做多少次这是由客户决定的，当客户点了你的桌面服务，他的钱多，你就做得多。至于做多久，由哪一类的人员做，这是内部的信息，对于报价有用，但只是内部信息，置于服务目录之中，只会让服务目录失去管理焦点，服务目录对合同关系，但与这些完全是不同层面的东西，不能混为一谈，比如报价，更重要的信息在合同上，每一服务要做到什么级别，每一服务的对象有多少，这才是最关键的
3、 基于项目定义服务目录，是对服务目录的曲解
服务目录的设计需要根据企业资源，首先从公司层面去思考能做什么，而不是能让每个项目去定义自已的服务目录，其原因是，我们说服务产品化，到底产品化的目的是什么，不是去为吵口号，而是当服务产品化后，我们可以享受到规模优势，我们可以做得把服务更专业，成本更容易控制，同时真正定位自已的业务，更重要的是我们会可以象制造业去升级或淘汰我们的服务，或者发现某一个产品（服务）非常具有市场潜力，我们可以进行细化扩展我们产品目录（服务目录）
在这讲根据每个项目去定义服务目录，会造成什么后果，大家不会有很直观的感受，只有当你真正接触到其中才会强烈感受，如果你有50个项目时，根据每一个项目去定义服务目录时，可能你的服务目录会数千条，而这其中，80%的目录是重复的，A项目有一条系统升级的服务，B项目也有一条系统升级的服务，意义相同，可能是叫法不同，这样缺乏一个全局的战略考虑，同时技能活动与服务的界限没有区别清楚，服务目录非常多时，一定是出了问题，一个100-200人的IT服务商，说他的服务目录数千条，就根本不用看什么目录内容，用脑子想想也知道出了问题，服务目录对于具体的一个项目，事实上意义不大，根据每一个项目去定的服务目录，事实上多数最后变成一个作业计划，上面的信息是告诉项目人员每天要做什么，这事实是是对服务目录极大的异化与曲解。
对于IT服务管理而言，很多时候需要站在整个服务商的层面去分析思考，而不是站在每一个项目上去分析思考，规模、效率、专业最根本是土壤在公司整面而不是项目层面，根据每个项目定义的服务目录，最后无法做出任何对公司经营有价值的分析与统计，更无法为市场发现与经营战略提供有价值的数据统计。
4、 到底哪一些是服务目录？
当一个人到餐厅吃饭时，他会根据菜单点菜，注意喔，他只会点菜单上的菜名喔，我们可以看一下，一个餐厅的服务目录是怎么做的，当一个人去吃饭时，他享受了什么？除了饮菜本身外，还可以享用了免费的茶水，还享用了服务员热情的服务，他可能还免费使用了餐厅的电话与洗手间，后面这些是服务吗？是的，在菜单上吗？不在，为什么？这种思考方法会帮助我们极大的理清我们的服务目录到底装载什么信息与内容，你可以提供桌面运维服务，你可以提供的服务是什么？你有一个怎样子菜单让客户去点菜？你会把桌面运维需要做仓库管理，桌面运维需要有服务台，桌面运维需要盘点，桌面运维需要配置管理，仓库管理、服务台、盘点、配置这些是服务吗？我认为不是的，这些只是为了达到桌面运维服务需要支撑性的管理活动或技能内容，它不属于服务目录需要记录的内容，虽然这些会耗费你的成本与人力资源，但并不表示这些需要记录在服务目录中，这种情况荒唐到需要你去吃一个餐厅时，人家给你一个菜单，上面写着，服务员记账、去菜场买菜、切菜、炒菜，端菜、端茶送水、提供桌椅、上洗手间、打电话，这些东西都是餐厅为了给你服务需要做的一系列活动，虽然这些包含服务的性质，但并不是焦点所在，客户并不关心这些。
服务目录应该列出客户需要而且愿意付费的服务清单，而支撑这个服务背后的活动信息是不应该列在上面的，虽然服务商的所有活动的成本最终是由客户支付，但这些是你在定价或报价时需要考虑的计算问题，服务目录本身是不需要列出这些信息的，就象一道菜是10元钱（清炒土豆丝才这么便宜）为了提供这个菜给客户，你需要有一张桌子，一张椅子，还有有饭碗，还要有厨师，还有材料费用，采购费用，服务员端菜等等这些都是你的成本所在，但这些并不是客户关心的，但是你关心的，虽然这些成本最终会全部分摊在客户身上，但并不表示一定需要在服务目录上记录着。
上面只说了服务目录这样做也不是，那样做也不是，那服务目录到底应该怎么做呢？有什么硬性原则吗？我认为应该没有什么刚性的原则的，但我理解中的服务目录首先是有结构的，它是多层次的，服务目录应该有一个分类，每一个类再分子类，这里会面临着与配置管理的CI分类的颗粒度一样的问题，即我们分到什么地步，分到最细时，一定会直指服务活动，这时目录已无法应用，失去了服务目录的建立初衷了，这里要考虑好管理需求；服务目录的特性不应该是经常变化的，不应该硬性以我们的业务领域去切分分类（按桌面、网络、系统、软件等作为服务目录的第一层分类，并不合适），这样做造成底层的服务目录重叠（病毒防治这是一条服务目录，但可能会在多个领域中存在），到时计算与统计会受到影响，要尽可能以不变的特性去定义服务目录，这样无论如何应用都不会造成服务目录出现问题（菜单中分了汤、菜、火锅，这样的特性就可能是合适），很遗憾我们具体的服务产品化还没有真正展开，等于我们还没有具体展开我们服务目录梳理，但我相信真正梳理的话，很快就可以完成，一至两个月就可以发布一版出来（当你真正清楚要的是怎样的东西式时，并有一定方法，真正梳理并不会特别困难），到时就可以谈得更具体些，而不是象现在这样停留在理念层面。
给象我们一样的摸索前进的同行的建议是：先收集所有的服务目录，然后进行分析总结，定义一个稍稍粗放些的服务目录，层次结构不要过深，数目不要过多，能用就好，然后运行一个周期，最好是利用一款软件把数据采集起来，这里的数据采集是把你的服务资源投放与服务目录关联起不，以便分析，每一条服务目录占用资源的情况，然后对资源占用大的服务目录进行细化，这是一个进化的过程，然后更重要的是，要考虑根据历史数据，去做计算模型，用处是报价及核算成本，服务目录定出来后，客户点后，你如何报价，你没有计算模型是根本无从报价的，或者是乱报，事实当你的服务资源（多是人员工时）与每一个服务目录形成关系后，你的所有活动都被有效归类到服务目录中，同时留下工时记录，此时数据积累到一定历史后，就可以大致推算出一条服务目录与服务对象、服务资源的成本是多少，一旦推导出这个计算模型，对这个公司的市场开拓与内部控制将会非常有用，你每年的改善点可以指明，你的成本也是非常清晰的。这正是我现在在公司在规划我们的ITSM系统时一个考虑，在实施这款系统时，我也会按照这种思路去作业。这个过程非一朝一夕之事，我估计以我有充足的决策支持的情况，帮助公司真正出台一个可以摊开给全世界去审视的服务目录，同时具备初步计算模型，需要两个财年的周期，注意是周期，并不是工作量，这种工作，需要在组织中沉淀消化，及需要时间积累数据。
服务目录就先写这么多吧，等后面我们第一版的服务目录出来时，我可能会再写一些怎么具体整理服务目录的文章。 好像有点过时的信息啊 看完了，写的不错啊