(完整word版)IT部门组织架构.docxVIP

IT 部门的组织架构 最近朋友去了一家企业，做 IT 经理。另外另外一个朋友公司也在组建 IT 部门，确定 IT 架 构。这些事情和若干朋友交换了一下意见，这里强调一下这个 IT 架构 是传统企业的 IT 架 构。这个传统企业的定义我不好说，但是如果举例就是：不是 taobao ，sina 之类。 net 公 司，可能是物流公司，能源公司，金融公 司等。下面拍点砖： 无论 IT 组织架构怎么弄，从功能上，无非是保障 IT 系统的一班人马，推动企业内部信息化 的一班人马。前面讲的是 IT 语言，后面讲的是业务语言。（这样的表述有点老套，可能想 睡觉。） 打破刚才的说法和思维，可以把 IT 的工作分两块， 一块是运维保障，一块是业务推动。 运维保障：可以理解为对于现有对外提供服务的保持， 比如业务系统的可用率， IT 系统的 可用率等等，这些服务可以有两个层次，一个是 IT 视角的层次，那么无非就是交换机，路 由器，数据库等 IT 具体的技术的硬 件和软件。通过网管软件， IT 技术等进行有效监控。如 果考虑的全面一点， 那么无非就是需要考虑容灾部分， 制定应急预案。 运维保障是一个只有 起点，没有终点 的过程，要做好这个事情建议是用 ITIL ，把 IT 的日常工作，按照 ITIL 的思 路来做。运维保障是 IT 的基本职责，也是 IT 对外提供服务的窗口，通过管理 的思路来理 顺运维保障的工作，提高 IT 对外提供服务的能力，提高 IT 对外提供服务的质量。 为了防止结构性的问题，那么需要做好 IT 基础架构的规划。 总结：稳定压倒一切；通过 ITIL 的思路来做日常工作。此项公司可以外包。负责 这个人物的 IT 副手无法进入公司的决策层。 项 目建设：项目分硬件项目和软件项目。硬件项目可以理解为用户是 IT 自己，软件项目可 以理解为用户是公司内业务人员。  IT  为了提升自己的价值，必须积极推动  企业的信息化， 否则自己没啥地位。  通过理顺内部需求， 来上一个个业务系统。业务推动的指标，  这个不好 说看领导的要求，比较难量化，一般是年初的时候制定一 个需要上应用系统的计划，如果 IT 达到了，那么就差不多了。项目需要年年想，不像运维保障，每年的要求都差不多，你 不需要去想太多。这些业务系统用的好不 好，要看业务部门对你的评价。对于这个评价我 个人的想法是还是需要多沟通，很多事情没有对与错，需要的是心要齐。 为了防止结构性的问题。需要做好公司整体信息系统软件架构的问题。关键是 需要考虑好每个业务系统之间如何做好数据交换。否则一个个业务系统都上去了，你发 现 有很多不爽的事情， 比如：业务系统之间交换数据困难； 基础数据需要在每个业务系统输入； 总结：业务推动是核心，变化也很多， IT 的地位也是这项任务来决定的；一般 IT 经理的负责人这个熟一点； 熟悉这个， 可以有机会进入公司的决策层； 业务推动的核心是掌 握业务，掌握需求，代码开发可以全部外包。项目有开始时间，有结束时间。 大的结构确定了，那么把我们日常碰到的几个角色放进去 安全人员。安全是一个很大的概念，是运维的安全，还是业务系统的安全（信息篡改， 外泄等等）。如果是运维的安全那么就是运维保障这块，如果是业务系统的安 全，那么首先在业务系统的设计和需求分析的时候， 就需要提出安全的要求， 比如业务系统是否有帐号 的概念；对于关键的操作是否有日志记录等等（嗨嗨，不知道  哪个鸟公司做的鸟系统，业 务系统日志很烂，烂的比如用  oracle  的  logminner  来做日志，呸！）。 业务系统培训。 可以放在日常运维这块，日常碰到的业务问题全部都可以来培训，培训的结构可以通过日常运维这些 ”误报 “率降低来体现。