IT部门组织架构Word文件下载.doc
《IT部门组织架构Word文件下载.doc》由会员分享,可在线阅读,更多相关《IT部门组织架构Word文件下载.doc(2页珍藏版)》请在冰点文库上搜索。
不是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.业务系统培训。
可以放在日常运维这块,日常碰到的业务问题全部都可以来培训,培训的结构可以通过日常运维这些”误报“率降低来体现。