这个问题问得好，不仅因为软件产品的运维服务，需要悉心筹划；而且，开展运维活动首先需要考虑的是机构设置，也就是职能设置问题，其次才是所谓的流程管理。
重要的考虑因素是服务数量和服务形态。
服务数量，确定不同的“团队”是部门，还是小组，或者仅仅是不同的岗位？

设计运维的组织架构，实际上是设计服务提供方式。可以用三个步骤来思考：
1）需要考虑提供什么服务；2）如何提供服务；3）服务有多复杂，是否需要不同的团队来完成？

也就是：
1）首先，需要考虑服务的有多复杂？也就是服务目录。辅导用户使用？帮助进行系统配置？修改系统缺陷？需要进行系统升级？
2）其次，根据服务目录，可以设计需要如何提供服务。例如？远程解答，现场服务，现场修改？远程修改？
3）最后，服务有多复杂？需要怎样的团队架构？
如果只是进行解答，那么只是服务台即可，如果系统有比较深入的问题需要解答，那么需要有二线技术团队；如果需要现场服务，那么需要设立现场服务团队，如果系统非常复杂，个人无法掌握整个系统，哪么需要针对不同的子系统设立不同的技术服务团队。如果需要进行系统进行修改，哪么就要加上开发团队。另外，还需要考虑维护与开发和实施的接口。

itsm-duan 发表于 2011-12-29 21:24
这个问题问得好，不仅因为软件产品的运维服务，需要悉心筹划；而且，开展运维活动首先需要考虑的是机构设置 ...

非常感谢您的回复！也带给我了些思路。多谢！
回答您的三个问题：
1、提供的服务包含但不仅限于事件、问题、监控、健康检查、调度、缺陷修复等等
2、如何提供服务？分多种形式，一种客户现场支持、第二种远程支持、或少量客户现场人员+后方团队
3、服务复杂度较高，主要服务公司客户。前期咨询部门打标、产品+实施部门实施、后期运维组织运营和维护工作。需要考虑人员培养和知识转移。
我的问题：
您更多的是从一个团队或项目上去考虑组织架构的。我想考虑的是，我们已经有了几个或几个这样的团队，如何构建更高层次上的部门管理团队，能建立体系，指导各个团队按照流程规范体系完成工作，并且能培养人，有考核体系...

我知道，一个客户现场的团队我可以按照功能分别组织出事件经理、问题经理、监控岗经理、变更经理等，在这之上有个项目经理或客户经理总负责。
但是，若是有多个这样的团队，这样的团队之上是什么组织？
按照岗位分？事件和问题部、变更和发布部、监控部、基础环境部（网络、存储、服务器）
按照部门职能分？体系流程建设部、人力资源部（人员能力培养、人员安排）、技术部（运维相关工具开发）
按照技术或产品线划分？C、JAVA等等

请各位发表下高见吧，多谢了！

顶下。关注。