IT部门组织架构.doc

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经理的负责人这个熟一点；熟悉这个，可以有机会进入公司的决策层；业务推动的核心是掌握业务，掌握需求，代码开发可以全部外包。项目有开始时间，有结束时间。大的结构确定了，那么把我们日常碰到的几个角色放进去1. 安全人员。安全是一个很大的概念，是运维的安全，还是业务系统的安全（信息篡改，外泄等等）。如果是运维的安全那么就是运维保障这块，如果是业务系统的安 全，那么首先在业务系统的设计和需求分析的时候，就需要提出安全的要求，比如业务系统是否有帐号的概念；对于关键的操作是否有日志记录等等（嗨嗨，不知道 哪个鸟公司做的鸟系统，业务系统日志很烂，烂的比如用oracle的logminner来做日志，呸！）。2.业务系统培训。可以放在日常运维这块，日常碰到的业务问题全部都可以来培训，培训的结构可以通过日常运维这些”误报“率降低来体现。