IT部门组织架构.doc

IT部门组织架构.doc

《IT部门组织架构.doc》由会员分享，可在线阅读，更多相关《IT部门组织架构.doc（2页珍藏版）》请在冰豆网上搜索。

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.业务系统培训。

可以放在日常运维这块，日常碰到的业务问题全部都可以来培训，培训的结构可以通过日常运维这些”误报“率降低来体现。