如何进行IT项目管理

如何进行IT项目管理,第1张

北京市高级人民法院的IT运维采用全部外包的方式。IT主管部门不再插手诸如为各部门电脑系统安装软件、更换硬件这样的琐事,自己站在全局的角度把控IT运维的健康发展。这种全外包是否成为IT建设下一个热点?

目前为止,在很多行业中,基本上没有像北京市高级人民法院(下简称北京高法)这样,将IT运维完全外包出去的单位。

北京高法这种IT运维外包方式是否会成为下一阶段信息化建设的一大趋势?各大IT运营商是否支持?这其中的利益分成又该如何解决?信息化部门又是如何看待这种IT运维方式的?带着这些问题,本报记者走访了多个单位的信息化主管以及运营商,发现IT运维外包已经初见端倪。

为什么要外包?

为什么要将IT运维服务完全外包出去?北京高法技术处副处长王岚生说: “北京高法从2005年开始探讨运维服务,当时北京高法的业务系统建设进入成熟期,系统遍及整个业务部门,日常工作也离不开信息系统的支持。要让IT部门12个人的队伍负责复杂的系统简直不可能。”

在这种背景下,北京高法采用完全外包的方式,“甩手”运维,它们将运维外包交给一家总外包商――紫光华宇运营,后者再和5个分运营商签署了分包协议。“将IT运维服务完全交给第三方之后,首先解决了北京高法IT人员占用编制的问题,又充足了IT力量,达到了运维效果; 其次搞清楚了IT总资产、运维的重点、运维的满意度; 最后促进了IT系统与业务的深度融合,IT外包商将各种需求提炼出来之后,再告诉我们的业务人员,促进了业务发展。”王岚生说。

2002年,大连市政府正式推出了自己城市门户网站――“中国大连”,公众通过这个单一的网站入口,就可以联系到市政府各办事机构: 社保、税务、工商、公安、交通车辆管理等。从2003年开始,大连市政府网站尝试运维服务外包的方式。大连市政府网站管理中心副主任耿昭介绍说:“网站负责信息化建设的只有12个人,不可能维护600百多台终端,有必要将一些工作外包出去,交给擅长的IT公司做。”

北京市公共卫生信息中心副主任王晖向记者介绍,目前,北京市卫生局在信息系统运维工作中也采用了部分外包。其中包括服务器、网络设备运维外包、数据库运维外包、UPS运维外包、空调运维外包、PC、网络基础运维外包几个部分。

那么,这种IT运维服务外包方式能否成为潮流?

北京市信息化工作办公室(下简称信息办)发展计划规划处处长兼主任助理童腾飞认为,这种外包方式必然是大势所趋。他说: “外包在IT行业不算新鲜,无论以前是BPO(业务流程外包) 、KPO(知识流程外包)还是ITO(信息技术外包)等等,都是外包的一种方式,不过北京高法的这种外包更彻底,走得更前一步。”

神州数码信息系统公司咨询与服务总监李继刚长期从事IT咨询、建设和运维服务,他表示,在非IT行业中,外包已经成为一种趋势,走在了IT行业前面。IT运维外包也将走上类似的方向。从IT技术发展来看,现在的IT系统越来越复杂,运营商也越来越多,远远不是一个IT部门、几个人就能一切搞定的事情。从管理角度看,系统的复杂多变、和运营商的沟通协调、与业务人员的沟通,也存在复杂性,IT运营外包已经上升为复杂的管理,而非技术那么简单。外包方式也有利于管理者从技术中解脱出来,站在更高的层面指挥IT运营。

李继刚认为,正是这些因素造成IT运维服务外包成为趋势,不但有利于社会的专业化分工,而且可以让甲方乙方各自做自己擅长的事情。

耿昭也向记者表示,运维外包是一种趋势,但目前还要做更多标准化工作。他认为现在可参考一些电子商务方面的标准来做。在这种理念之下,政府要把责任之内的事情做好,运维外包可找总包和分包商来做,在规范之内提高服务质量。

王岚生说: “采用外包是运维服务中不可避免的发展趋势,是IT运营发展的必然阶段。IT发展到如今这个阶段,运维工作的强度和难度远远大于建设阶段。IT主管的任务重点是如何管理好IT系统,所以他必须重视运维工作,这样才能促进信息化与业务深度融合。”

什么可以外包?

如果按照IT的建设来划分,基本可分为基础设施、应用系统和业务流程等几个层面。行业中的各类业务应用,需要和上述各个层面打交道。运维服务外包是否有一个清晰的界限?哪些可以外包,哪些不能外包呢?

在王晖看来,运维服务外包是将非核心、技术复杂和繁琐,且与业务职能相对独立的运行维护工作外包。

童腾飞认为,行业单位必需首先分清楚哪些内容需要外包,那些内容不能外包?所以,在甲方和乙方签署协议的时候,必须将外包协议签署清楚,外包的内容是什么,服务的项目是什么,要做到什么程度,这些都必须明确,否则会影响服务质量。

王晖认为,明确外包范围的主要目的是清楚界定哪些内容可以外包,哪些内容不能外包。尤其是针对信息安全的外包,要严格按照主管部门的要求界定外包范围。“要做到责任明确受控,信息化部门必须准确定义外包服务需求边界和考核指标,明确各种衍生设备、软硬件和信息资源的产权,减少争议条款。外保范围定义不清,内部管理部门也难以有效管理外包公司,运维质量和资金投入就存在较大风险,外包公司和政府部门之间的沟通难以顺畅,外包服务的监督管理就会失控,更谈不上外包管理的规范。”

耿昭对于哪些IT工作中的内容可以外包出去,也有着自己的看法。耿昭曾经考察过一些地区IT运维服务全部外包的“交钥匙”工程,他认为这种方式并不适合大连市政府网站。“所谓‘交钥匙’就是运营商接管运维服务的所有事项,至少在目前阶段,‘中国大连’的运维工作不适合完全外包,一是考虑安全问题,二是考虑业务本身的连续性。”

目前,大连的政府门户网站采取局部外包方式,他们将服务项目分为11个大项,其中如计算环境、服务器升级、应用系统的备份和维护外包出去,由大连市政府办公厅和各个运营商(分包商)签署协议,在这些外包协议中甚至包括了一些“三天除尘,半个月彻底除尘”的“精细”服务条款。为了保障服务质量,大连市政府网站管理中心担负着类似于总监理的角色。

“IT运维外包是一个新鲜事物,刚刚开始发展,它的具体内容包括哪些部分,要达成什么效果,标准是否要统一规范,这些都正在摸索中。”童腾飞认为,对待这个新事物,信息化主管部门有必要从政策法规上加以引导。

在这种背景下,北京信息办和信息协会,在一些部委的支持下,联合业内专家、厂商和咨询机构,于去年底发布了“北京市电子政务IT运维服务支撑系统规范”。在这个规范中,明确地提出运维服务支撑系统应用需求、技术需求和测试方法。

“这其实是运维工具的标准化,通过这个标准来影响服务标准。”童腾飞介绍说,该规范定义了运维服务的范围、管理流程和支撑系统,希望从市场化的角度给各个运营商和电子政务部门提供一个参考。

在运维服务外包尚不明晰的情况下,由信息化主管部门率先提出规范,这是否有利于下一步的发展?

“运维服务外包考验的是甲方和乙方的成熟度,如果甲方并不清楚建设了哪些系统,需要什么样的服务,那么,作为政府部门,我们并不建议它去搞运维外包。”童腾飞认为,运维外包也不是说说就能做的事情。

“只有甲方成熟了,对IT系统熟悉了,有了对风险判断和度的把握,做到政务可控,才可以做好运维外包,做好核心业务。”童腾飞希望有更多成熟的IT可以采取运维外包服务。他认为,在现阶段的IT当中,99%的运维服务都可以外包出去。“根据国家信息公开法的相关规定,政府部门当中非涉密的信息越来越多,也越来越透明。运维外包作为整体性质的服务,再有了相关的系统标准做约束,必定会促进外包走向规范化。即便是涉密系统,也可以通过技术手段解决,比如甲方和乙方各自掌握一半密钥,保障系统安全。”

王晖介绍,在实际工作中,他们对外包公司在运维服务合同中层层落实了安全责任制,签订保密协议。保证外包公司不会违反规定而外泄一些政府内部敏感数据。“此外,还要防止外包公司对核心数据、政务信息资源私自设置处置权和开发利用权。政府部门必须加强运维状态的监控,全面掌握网络系统的实际运行状况,定期组织进行系统运行状况及风险评估,对外包运营商建立事故问责制和重大问题质询制。”

李继刚说: “现在还无法判断这个市场什么时候会成规模,但毫无疑问这是一个趋势,主要还要看政府部门的意识和观念。不能以安全作为电子政务不采取运维外包的一个借口。毕竟在建设中,政府部门是强势的,它们可指导乙方如何遵从相应的法律法规,从技术上解决安全问题。”

北京高法办公大楼7层设立有呼叫大厅,相隔不远是紫光华宇的两间大办公室,里面堆放着各类设备。作为紫光华宇的派出机构,这个运维部门租用了北京高法的办公地点,常年在这里服务。

紫光华宇运维部经理米坤说: “我们从2003年开始为北京高法提供IT服务。2006年之前所建设的系统出了问题,我们也会维修,当做是技术支持来做,甲方(北京高法)也会支付一定的费用。这两年和甲方一起磨合,搞清楚了资产需求,签署了详细的服务协议,我们作为外包的总服务商,统领其余几个分包商为甲方提供运维服务。”

他透露说,在这个办公楼区域内,紫光华宇常驻的工作人员有14个人,公司总部还有近10人的支持小组。如果加上其余分包商的人员,为甲方提供运维服务的人员有60多人。按照协议,分包商分别和甲方签署,其中还存在第三方的监理公司负责考核乙方的业务。

“从外表看,大家所干的活都差不多,其实,采取总包之后,现在的服务性质和从前完全不一样。以前也许是被动的,哪里坏了修哪里,现在则是主动的。如果系统出了问题,甲方会第一时间找到我们总服务商,会影响我们的绩效考核,和明年是否续约的问题。”米坤认为,外包方式使技术支持变为管理上的支持,是服务商职能的转变。

分工明确的情况下,乙方负责北京高法的非涉密的IT系统,从设备维修、更换,到庭审的录像、现场直播和速录,乃至后期资料整理和归档,都是由乙方负责。北京高法每年支付运营商一定费用之外,具体的IT业务和流程不再插手。

米坤透露说,在北京高法的这种外包模式带动下,接下来,北京部分法院也在尝试运营外包服务,这样即将呈现“星火燎原”之势。

神州数码在2004年底,与北京海淀区人民政府签署了一项“电子政务信息资源服务平台”的服务外包合同,长达5年。神州数码负责基础设施建设和维护,具体的应用和业务流程则不负责。李继刚说: “现在看来,运维外包是‘一揽子’的服务计划,不仅包括基础设施和业务系统的运作,还包括流程,这对运营商的要求比较高。”

他认为,IT部门要做运营外包,需要从范围上掌握好尺度,了解核心业务和非核心业务。

北京市信息资源管理中心(下简称中心)成立于2001年,主要负责北京市信息资源的共享、交换和整合工作等,集中管理全市重要的信息资源。该中心也做了一部分运维外包。中心计划部部长高顺尉说: “我们最近在考虑外包的下一步,究竟是采用大包方式还是分包方式?”他说,从现在的外包方式看,第一种方式是前期建设不管,运维由总包商来做,可分解到分包商; 第二种方式是前期建设开发由一家公司做,而运维交给另外一家总服务商来做; 第三种则是谁开发谁运营的方式。

高顺尉认为,每种方式都有利有弊。北京市信息资源管理中心采用的是第一种方式,将软硬件维护、系统升级等事情交给一家总包商来做,不过,由于总包商实力有限,他们又引入了分包商。除此之外,中心还将资源建设、网站栏目建设等事情交给了分包商做,可以认为中心正在迈向流程大包的方式。

“中心的技术实力比较强,日常维护交给运营商,可是在关键节点上都有我们的工程师提出要求,负责考核,这样确保了服务质量。”高顺尉说,每年有千万元的外包费用。由于系统复杂,必须要引入总包服务商,要在合同上写清楚运营维护的需求。而总包商又不是什么都能做的,所以它们又指定了分包商承担一定的分包业务。

“什么能包,什么不能包?流程的东西必须外包,如系统开发和维护等,外包有利于提高效率。政府能做的事情不能外包出去,这是属于政府的职能范围之内的。安全的范围也也不能外包出去。”高顺尉分析说。

高顺尉表示,其实还有一种外包方式,就是找一家类似于监理公司的角色,再由这个公司去找外包商。他说,大包肯定是一种趋势,政府部门在外包时必须考虑自己的掌控能力,并且对外包商的要求很高,需要有一定规模和技术。但政府部门要对外包商可掌控,不能被外包服务商牵着鼻子走。

如何做好外包?

北京高法每年运维外包费用向市财政要1000多万元。王岚生说: “我必须说清楚每一分钱花在哪里,起到什么作用,否则怎么能获得批准呢?”

北京高法在运维外包之前,让乙方摸清楚了所有的IT资产总和以及资产分布图,系统物理位置和所有的应用系统。随后还制订了6个分类,1700多项的服务类别,细致到响应时间、服务标准,服务工种等细节。

王岚生说,如果不把服务做到标准化和细致化,谁也说不清楚该花多少钱,也不能保障外包服务的质量。

童腾飞认同北京高法的这种做法,“甲方必须对自己的需求非常了解,才能梳理出清晰的运维服务范围,做到产品化和标准化,提高服务质量。”他提醒说,在外包中,需要注意“影子政府”的存在,即外包商一家独大之后,可从IT业务中架空甲方,或者是由于运营商本身的原因而影响到甲方的业务。

北京高法也采取了让外包运营商相互制衡的做法。原本是3家分包商,后来又增加了两家分包商,负责庭审光盘刻录服务以及安全保障服务。第三方监理公司则会考核这些外包商的工作质量。

童腾飞认为,服务外包的产品化和标准是外包服务的趋势,事先定义好运维外包的范围,可以核算出成本是多少,需要哪些服务,基础设施和系统的比重关系,让甲方用好每一分钱。他重点强调,IT运维可以外包出去,可政府职能不能外包出去,这就需要政府部门在IT外包的市场化之后,要真正发挥出来电子政务的作用。

米坤向记者表示: 他也能理解甲方再次引入的两家分外包商。“其实,这些分包商做的服务我们也能做,分解服务到多少外包商合适,这都需要一个度的把握。”

他们按照服务目录的要求,在保障质量的前提下,分解了服务任务,又落实到具体实施人,从人员、设备、流程以及目标等做出了考核要求,确保了服务质量。“每天早8点之前,有工作人员对一些关键性系统做巡回检查,排除潜在的故障,确保甲方的业务运转正常。我们将服务流程固化之后,服务也从被动转为主动的监控。”米坤认为,采用运维大包机制,可以给甲方一个清晰的责任接口,让甲方只关注最后的绩效,这是运维外包提高效率的体现。

神州数码的李继刚说,引入市场竞争机制,让运营商之间有相互制约是保障服务质量的前提。信息化建设也是如此,建设初期有各种标准,随着市场的成熟和竞争,市场逐步成熟和规范起来,形成业内公认的标准化。运维服务也是如此,在初期可能存在各类标准,价格也不透明,等完全发展起来之后,必然会走向正轨。

李继刚认为,IT运维服务外包可上升战略层面,确保IT系统在时间上、空间上具有连续性,确保IT系统的发展。从运营商角度看,这样也避免了每次更换服务外包商的资源浪费。

王晖向记者透露,“未来,市卫生局信息中心的运维工作中心将从自运维模式转变为混合运维模式,信息中心的运维工作重点转向对外包服务提供商的管理、对运维管理流程的梳理、对运维服务支撑系统的开发等工作。针对下一步运维管理工作,我们将结合市信息办运维管理相关规范从运维体系、服务流程和支撑工具几方面进一步深化; 探索运维绩效管理的新机制和新方法,研究系统运维与运维成本之间的关联程度,为IT运维管理的科学化规范化提供基础; 进一步加强信息资产的管理,信息资产和固定资产的含义是不一样的,只有对信息资产从硬件,软件和资料等方面加强管理才能更好地做好运维工作。”

评 论

运维服务外包考验管理能力

在本次采访中,绝大多数被访问者都表示,赞同IT的运维外包。有一些的信息化主管不同意外包仅是因为安全问题。

究竟要不要运维外包?如何做好运维外包,这些是讨论的热门话题。

可以断定,电子政务运维外包是下一个阶段的建设重点。可以几个维度可看,一是电子政务的发展方向,是该用好的阶段到了; 二是政府部门对电子政务的看法,究竟要拿电子政务做什么,是工具还是职能管辖范围之内。

电子政务IT运维外包可不是在厂商的忽悠下产生的,而是政府部门自己需要的。以大连市网站为例,他们能够做成运维外包是在人员压力、运营压力下产生的。厂商说,他们的利润还不足20%,远远低于项目建设的利润,并且运维服务比项目建设还要复杂,有一些柔性管理在里面。

著名管理学家彼得•德鲁克早在1989年就说过: “任何企业中仅做后台支持而不创造营业额的工作都应该外包出去,任何不提供高级发展机会的活动与业务也应该采取外包形式”。

政府部门的职能是什么?是为了提供更高效、透明的服务,如果把精力过多地放在IT系统的管理方面,必然是“抓小放大”。在这一点上,运维服务外包将有利于政府专心做服务,从琐碎IT业务中解脱出来。

期待电子政务IT运维外包服务越来越多。(文/吴玉征)

信息安全风险评估报告应当包括:识别评估对象面临的各种风险、评估风险概率和可能带来的负面影响、确定组织承受风险的能力、确定风险消减和控制的优先等级、推荐风险消减对策。

信息安全风险评估是参照风险评估标准和管理规范,对信息系统的资产价值、潜在威胁、薄弱环节、已采取的防护措施等进行分析,判断安全事件发生的概率以及可能造成的损失,提出风险管理措施的过程。当风险评估应用于IT领域时,就是对信息安全的风险评估。

风险评估从早期简单的漏洞扫描、人工审计、渗透性测试这种类型的纯技术 *** 作,逐渐过渡到目前普遍采用国际标准的BS7799、ISO17799、国家标准《信息系统安全等级评测准则》等方法,充分体现以资产为出发点、以威胁为触发因素、以技术/管理/运行等方面存在的脆弱性为诱因的信息安全风险评估综合方法及 *** 作模型。

风险评估是风险管理的基础,风险管理要依靠风险评估的结果来确定随后的风险控制和审核批准活动,使得组织能够准确“定位”风险管理的策略、实践和工具。从而将安全活动的重点放在重要的问题上,选择成本效益合理的、适用的安全对策。

什么是项目管理?

经过人们长期探索总结,项目管理在发达国家中已经逐步发展成为独立的学科体系,成为现代管理学的重要分支,并广泛应用于IT、金融、服务、航空航天以及工程等诸多行业。由于其诱人的高额年薪以及广泛的就业前景,项目管理目前已经成为超越MBA的最炙手可热的“黄金职业”。 项目管理无疑将会是未来二十年中最热门的行业。那么到底什么是项目管理?

项目管理的定义有很多,按照教科书的理解是:项目管理是在运作方式和管理思维模式上最大限度地利用了内外,去完成项目目标。项目管理包含很多层面:团队管理、风险管理、采购管理、流程管理、时间管理、成本管理和质量管理资源等。

笔者的理解是:项目管理,就是通过合理地组织,利用的一切可以利用的资源,按照计划的成本和计划的进度,完成一个计划的目标。在项目实施过程中,目标很可能会发生变更,那么成本和进度都需要做相应的调整。

项目主管如何解决问题?

按照白猫黑猫理论,评价项目管理是否成功的唯一标准就是项目是否保质保量按时完成。现在的项目实施一般都是主管负责制,项目主管重任在肩,要达到项目成功这一目标谈何容易。

在项目管理过程中,笔者就要经常思索以下问题:

如何在选择余地不多的情况下,组建一支得力的项目组?

项目组成员的挑选非常重要,假如在一个关键的岗位安排了一个不合适的人选,这个项目很可能会出师不利。当然在现有的人力资源中,不一定能顺利选到优秀的人才并组建成一只能战斗的队伍。笔者就碰到这种最恶劣的情况:项目组只有主管有经验,别的成员都是刚刚毕业的大学生,那么主管的任务就不仅仅是管理,而且需要花费大量时间精力来培养这些新手,让他们能尽快进入预定的角色。

如何界定项目成员工作的范围和定义他们之间的工作接口?

这个问题就是俗语说的"派活"。要把活分出去可不是一件简单的事情。项目主管首先需要对项目组成员非常了解和熟悉,知道他们的知识结构和能力水平;其次要对项目情况非常清楚,并能对项目实施过程进行划分和功能模块的细化,并结合每个人员的特点指派具体的任务;最后要重点注意的是,尽量让组员之间的工作接口简单和接口定义详尽,避免将来产生互相推诿和扯皮。

如何准确衡量项目成员的工作量?

做过主管的人都碰到过这种问题:分配给甲的工作,要求一周完成,但是一个月过去了,他还没干完;分给乙的工作,要求一周干完,但是他一天就干好了。实际上现在的项目管理中,工作量的衡量往往靠主管的经验来加以主观判断,而且这种判断也不是因人而异的。主观判断会造成较大的误差,这些误差的积累最终导致不可控制的因素增加和项目风险扩大。

如何在不打扰项目组成员工作的情况下,及时进行沟通?

现在很少有单q匹马就能把项目全部搞定,往往需要团队来完成,那么团队的合作精神就显得尤为重要。在一般人的眼里,技术人员都普遍比较孤傲,不好管理。主管不仅仅要掌握良好的沟通技巧,还要擅于感情交流,帮助解决项目组成员工作上和生活上的实际困难,使他们集中精力干好本职工作。良好的上下级和同级关系创造了融洽的工作气氛,项目成功的可能性大大增加。

如何评估项目执行状况,随时掌握项目进展?

在项目运作过程中,如果靠员工的报告来掌握项目进展是不够的。事实上,员工都愿意报喜不报忧,在项目初期就出现的问题苗头,如果不能传递上来,将在后续阶段造成大的纰漏。笔者认为除了要定期听取项目组成员的报告,还要专门有一个品保组来监督项目的执行情况。品保组就像廉政公署一样,不参与项目的具体实施,专门给别人"挑刺",或者写一些测试程序来发现问题。

如何与客户单位沟通与协作?

有时候,项目都已经执行到最后阶段,客户单位突然提出了新的要求,这会让主管非常为难。一方面要尽量满足客户的需求,另一方面又不能对系统做太大的改动,影响进度计划。这种情况往往是与客户的沟通出现了问题,说明在需求阶段做的不够好,同时在实施过程中没有与客户有密切的联系。

如何在诸多不确定因素和限制条件下,按时完成项目任务?

项目成功与否受太多的风险因素影响。所谓“风险”,是损失的不确定性;是给定情况下,一定时期内可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。项目开发是一项可能损失的活动,不管开发过程如何进行,都有可能超出预算或时间延迟。很少有人能保证开发工作一定成功,都要冒一定的风险,也就需要进行项目风险分析。在进行项目风险分析时,重要的是要量化不确定的程度和每个风险的损失程度。潜在的问题都可能会对项目的计划、成本、技术、产品的质量及团队的士气产生负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。

如何在完成项目任务同时,保证甚至提高交付结果的质量?

笔者的同事曾经做过一个项目,按计划按预算完成了,但是系统不稳定,某些关键技术指标不能满足国标。造成这种情况的原因有:没有划分清晰功能模块和接口关系,成员相互指责,最终难以定位不稳定的根源,;没有成立质保组,没能很好地实施项目过程控制;过分注重项目的时间进度,忽略或隐瞒了前期的小问题。

如何成为优秀的项目主管?

笔者认为:一个优秀的项目主管首先是一个乐观而自信的人。他凡事都从正面考虑,不把失败当失败,反而将其看作成功之母,吸取经验教训,在那里跌倒又在哪里爬起。优秀的项目主管不一定要很有经验,但是要有强烈的进取心和明确的目标,并能够与他人良好沟通,鼓舞他人为共同的目标一起努力。

IT项目管理的特征探讨

IT项目具有非常明显的特点:紧迫性、独特性和不确定性。下面分别讨论一下这些特点含义和项目管理的相应对策。

紧迫性

IT项目的紧迫性决定了项目的历时有限,具有明确的起点或终点,当实现了目标或被迫终止时,项目即结束。随着信息技术的飞速发展,IT项目的生命周期越来越短。有的项目时间甚至是决定性因素,因为市场时机稍纵即逝,如果项目的实施阶段耗时过长,市场份额将被竞争对手抢走。

在开始一个项目前,主管就必须明白项目的时间约束。具体到每个人、执行项目中的每一个任务都必须明确时间要求。一旦没有按照进度完成,必须要有充分的客观理由,否则就要追究相关人员的责任。

独特性

IT项目的独特性在IT服务领域表现得非常突出,厂商不仅向客户提供产品,更重要是根据其要求提供不同的解决方案。即使有现成的解决方案,也需要根据客户的特殊要求进行一定的客户化工作,因此可以说每个项目都有区别。

项目的这种独特性对实际项目管理有非常重要的指导意义。项目主管必须在项目开始前通过合同(或等同文件)明确地描述或定义最终的产品是什么。如果刚开始要提供什么没能定义清楚,或未达成一致,则最终交付产品或服务时将很容易发生纠纷,造成不必要的商务和名誉损失。即便是定义清楚了项目的目标,但是客户单位仍然会经常调整实现指标,这种变更很难控制,这就需要项目组与客户单位有良好的沟通渠道,否则改来改去,永远改不完。

不确定性

IT项目的不确定性是指项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上是一种预测,在执行过程中与实际情况可定会有差异。另外,在执行过程中还会遇到各种始料未及的“风险”,使得项目不能按原有的预测来运行。

针对不确定性,在项目管理中就要注意制定切实可行的计划。笔者在工作中就发现科研工作,特别是国家级的项目,往往有一个“后墙不倒”原则。也就是说,设定一个项目的最终完成时间,具体的实施过程中,时间进度的安排就没有计划。在具体实施中,这种方法的最终结果是要么后墙倒了,要么后墙勉强没倒,做出来的产品满足不了质量要求。

还有一种不好的做法是过度计划,即将项目中非常微小的事情都考虑清楚才动手,但如此“详细的计划”其实是在试图精确地预测未来,也是不切实际的,在执行中会发现难以与实际一致,而不得不频繁地进行调整。具体问题具体分析。尽管有项目计划,执行过程中仍会碰到各种各样意想不到的问题,且往往没有现成的处理方法,这就要求项目经理必须掌握必要的工具方法,掌握整体过程和关键要素,灵活面对,妥善解决。

几个迫切需要重视的问题

项目管理有一些规律,但是还要具体问题具体分析,如果照搬硬套肯定会事倍功半。下面三个案例就是笔者在管理中遇到过的,现在拿出来一起探讨。

管理新手的重要性

一个项目组除了主管,全是新手!其实能有几个项目主管会如此幸运,项目组成员全都身经百战经验丰富。很多人认为,新手加入在短时间内对项目毫无益处,不仅帮不上忙,还需要别人来传帮带。笔者认为恰好相反:新人的加入是将会给整个项目组带来一些新鲜的想法,挖掘和引导这种的想法对新人的培训和很快的上手工作是非常关键的。公司花了钱招来的新人往往经过了人事部门的过滤,都具备了一些基本知识,主管可以先给他们分配一些具体的工作,调动他们的积极性非常关键。

在培训新人时就应该注意:

项目内容培训,让他尽快了解项目组的工作内容,项目的方向、目的,用到的知识、技能;

给他在项目组中的角色做个定位,明确他的职责,并提供必要的支持;

告诉他项目组管理方面须注意的问题,让他尽快融入到项目组里来;

尽量与目前项目组的工作结合起来培训,如让他尽快熟悉项目已经完成的工作,告诉他以后的计划,以及他马上要做的工作等等;

保持良好的沟通,了解他的进展,根据实际情况调整培训计划。

管理文档的重要性

让项目主管最痛苦的事情莫过于:当一个重要成员半途离开项目组时,才发现他根本就没有留下任何可用的文档。天下没有不散的宴席,项目组的成员也是在动态调整中,文档就是成员之间交接的重要工具。很多主管很容易陷quot;重技术实现,轻文档"的误区。他们总是认为项目实施时间紧迫,为了节省时间,可以在项目收尾阶段突击写文档。要是项目周期稍长,到了最后,成员还会记得清清楚楚每个实现细节吗?没有文档的项目铁定是一个失败的项目。

从过程控制的角度看,项目的实施质量控制,最重要的就是文档的管理控制。通过文档来显示表明每个基线,每个成员的工作量和完成质量,达到项目的风险最小化。

管理平台的重要性

笔者最初的几个项目都没有管理平台,所以没有量化的概念,管理手段非常落后。去年笔者在公司率先引入了微软PROJECT2000作为核心的项目管理软件,并根据项目的需求,以现有的计算机网络系统(Network)为基础,建立了内部的INTRANET项目管理平台。经过一年多的使用达到了以下效果:

使用PROJECT2000建立项目计划信息共享门户,使技术人员、主管随时看到与自己相关的任务信息,并通过建立状态报告,达到了解技术人员各自工作完成情况;

利用研发内部网站、电子公告板等共享信息系统,提供有效的信息沟通途径;

根据项目计划,建立动态提醒机制;

建立项目数据管理系统(Data):对与项目有关的数据和与数据有关的过程,进行有效地管理;

电子文档管理系统(Document),对图纸、文件、资料等文档,采用集中管理的方式,进行有序地组织,实现充分的共享和重复使用,实现了通过IE浏览器访问项目文档功能;

建立数据记录体现变更控制记录,项目文档记录。

结束语

就中国现状而言,项目管理还是一个全新的尚待开发的领域,很多项目管理人员和笔者一样都是在实践中不断摸索和思考。

从现实来看,只有那些跨国公司和国内的大型企业才对项目管理提出要求;从教育来看,项目管理的系统教育基本上就是空白,甚至目前中国还没有项目管理这一学科设置。同时,在中国,你所能够获得的有关项目管理的出版物以及资料都极其有限。

好在国内的教育部门已经发现了这个问题,各种PMP的培训班广告也开始出现在各类媒体中。那么我们是否都需要这个一个证书呢?

曾记得庄子在《庄子·养生主》中谈到的解牛的庖丁,在外人看来,技艺高超的庖丁解牛时,一招一式,轻松自如,姿势优美,其节奏如美妙音乐的旋律。而庖丁自己在历经多年的实践后,解释他的高超技艺的境界是:"以神遇而不以目视,官欲止而神欲行,依乎天理,批大隙,导大,因其固然quot;

项目管理还是有"天理"可循,假如有机会还是应该带着实践中的问题多看书多学习,最终会达到所谓的管理艺术。(IT工程技术网)

IT部分大概分:需求分析部分,产品设计部门,软件研发部门,软件测试部门。

目前比较容易入手,而且起薪比较高的,就是软件研发和软件测试,随着这工作的深入这两个行业可以逐渐往产品和需求两个方向发展。

软件研发的主要语言分为:C#,Java,php,C语言等等

软件测试的主要学习自动化测试,还有一些脚本的编写能力。

软件研发目前Java是第一大语言,应用广泛,入门快,薪资高,第二梯队,就是C#,php,python,C。学习Java可以在网上下载免费的视频,当然也可以管我要,自学能力好的当然可以自己研究学习,然后找工作,不过难度挺大,因为涉及到很多技术难点要克服,个人毅力还要坚强,市场环境要分析,简历撰写也有很多学问,流行技术如果没有企业实战经验和指导自己摸着石头过河怕是会耽误时间甚至掉进坑里不能翻身。能花钱买到的服务尽量不要用时间去交换,寸金难买寸光阴。

1风险辨识。先对于每一个业务中的单元、各种相关的活动、以及业务流程里面的重要环节都进行反复的排查与辨识,看看这些项目都有着什么样的风险,这样子才能够在大体上面对于风险情况有一个估计,做出一个基础的判断。

2风险分析。在接下来的风险评估第二步,就是在那些有风险辨识度的项目或是流程上面,进行仔细的分析,看看这些风险的特征是什么,并且使用明确的定义来进行描述,从而能够更为精准,特别是使用数字或是档位定义来明确这些风险的发生条件、以及风险的程度高低,从而使得人们都能够对于这些风险的发生可能性、以及所会造成的后果有着更为直观的认知。

3风险评价。将企业方案、或是运营目标的最终影响程度、以及风险的可能性与价格、可能的后果都进行明确的量化评估。

问题1:什么是风险评估?

问题2:风险评估是什么意思?

说起风险评估,大家脑海中首先浮现的可能是:风险、资产、影响、威胁、弱点等一连串的术语,这些术语看起来并不难理解,但一旦综合考虑就会象绕口令般组合。比如风险,用ISO/IEC TR 13335-1:1996中的定义可以解释为:特定威胁利用某个(些)资产的弱点,造成资产损失或破坏的潜在可能性。

风险评估是对信息资产面临的威胁、存在的弱点、造成的影响,以及三者综合作用而带来风险的可能性的评估。作为风险管理的基础,风险评估(Risk Assessment)是组织确定信息安全需求的一个重要途径,属于组织信息安全管理体系策划的过程。

风险评估的主要任务包括:

识别组织面临的各种风险

评估风险概率和可能带来的负面影响

确定组织承受风险的能力

确定风险消减和控制的优先等级

推荐风险消减对策

在风险评估过程中,有几个关键的问题需要考虑。首先,要确定保护的对象(或者资产)是什么?它的直接和间接价值如何?其次,资产面临哪些潜在威胁?导致威胁的问题所在?威胁发生的可能性有多大?第三,资产中存在哪里弱点可能会被威胁所利用?利用的容易程度又如何?第四,一旦威胁事件发生,组织会遭受怎样的损失或者面临怎样的负面影响?最后,组织应该采取怎样的安全措施才能将风险带来的损失降低到最低程度?

解决以上问题的过程,就是风险评估的过程。

进行风险评估时,有几个对应关系必须考虑:

每项资产可能面临多种威胁

威胁源(威胁代理)可能不止一个

每种威胁可能利用一个或多个弱点

风险评估的三种可行途径

在风险管理的前期准备阶段,组织已经根据安全目标确定了自己的安全战略,其中就包括对风险评估战略的考虑。所谓风险评估战略,其实就是进行风险评估的途径,也就是规定风险评估应该延续的 *** 作过程和方式。

风险评估的 *** 作范围可以是整个组织,也可以是组织中的某一部门,或者的信息系统、特定系统组件和服务。影响风险评估进展的某些因素,包括评估时间、力度、展开幅度和深度,都应与组织的环境和安全要求相符合。组织应该针对不同的情况来选择恰当的风险评估途径。目前,实际工作中经常使用的风险评估途径包括基线评估、详细评估和组合评估三种。

基线评估

如果组织的商业运作不是很复杂,并且组织对信息处理和网络的依赖程度不是很高,或者组织信息系统多采用普遍且标准化的模式,基线风险评估(Baseline Risk Assessment)就可以直接而简单地实现基本的安全水平,并且满足组织及其商业环境的所有要求。

采用基线风险评估,组织根据自己的实际情况(所在行业、业务环境与性质等),对信息系统进行安全基线检查(拿现有的安全措施与安全基线规定的措施进行比较,找出其中的差距),得出基本的安全需求,通过选择并实施标准的安全措施来消减和控制风险。所谓的安全基线,是在诸多标准规范中规定的一组安全控制措施或者惯例,这些措施和惯例适用于特定环境下的所有系统,可以满足基本的安全需求,能使系统达到一定的安全防护水平。组织可以根据以下资源来选择安全基线:

·; 国际标准和国家标准,例如BS 7799-1、ISO 13335-4;

·; 行业标准或推荐,例如德国联邦安全局IT 基线保护手册;

·; 来自其他有类似商务目标和规模的组织的惯例。

当然,如果环境和商务目标较为典型,组织也可以自行建立基线。

基线评估的优点是需要的资源少,周期短, *** 作简单,对于环境相似且安全需求相当的诸多组织,基线评估显然是最经济有效的风险评估途径。当然,基线评估也有其难以避免的缺点,比如基线水平的高低难以设定,如果过高,可能导致资源浪费和限制过度,如果过低,可能难以达到充分的安全,此外,在管理安全相关的变化方面,基线评估比较困难。

基线评估的目标是建立一套满足信息安全基本目标的最小的对策集合,它可以在全组织范围内实行,如果有特殊需要,应该在此基础上,对特定系统进行更详细的评估。

详细评估

详细风险评估要求对资产进行详细识别和评价,对可能引起风险的威胁和弱点水平进行评估,根据风险评估的结果来识别和选择安全措施。这种评估途径集中体现了风险管理的思想,即识别资产的风险并将风险降低到可接受的水平,以此证明管理者所采用的安全控制措施是恰当的。

详细评估的优点在于:

·; 组织可以通过详细的风险评估而对信息安全风险有一个精确的认识,并且准确定义出组织目前的安全水平和安全需求;

·; 详细评估的结果可用来管理安全变化。当然,详细的风险评估可能是非常耗费资源的过程,包括时间、精力和技术,因此,组织应该仔细设定待评估的信息系统范围,明确商务环境、 *** 作和信息资产的边界。

组合评估

基线风险评估耗费资源少、周期短、 *** 作简单,但不够准确,适合一般环境的评估;详细风险评估准确而细致,但耗费资源较多,适合严格限定边界的较小范围内的评估。基于次实践当中,组织多是采用二者结合的组合评估方式。

为了决定选择哪种风险评估途径,组织首先对所有的系统进行一次初步的高级风险评估,着眼于信息系统的商务价值和可能面临的风险,识别出组织内具有高风险的或者对其商务运作极为关键的信息资产(或系统),这些资产或系统应该划入详细风险评估的范围,而其他系统则可以通过基线风险评估直接选择安全措施。

这种评估途径将基线和详细风险评估的优势结合起来,既节省了评估所耗费的资源,又能确保获得一个全面系统的评估结果,而且,组织的资源和资金能够应用到最能发挥作用的地方,具有高风险的信息系统能够被预先关注。当然,组合评估也有缺点:如果初步的高级风险评估不够准确,某些本来需要详细评估的系统也许会被忽略,最终导致结果失准。

风险评估的常用方法

在风险评估过程中,可以采用多种 *** 作方法,包括基于知识(Knowledge-based)的分析方法、基于模型(Model-based)的分析方法、定性(Qualitative)分析和定量(Quantitative)分析,无论何种方法,共同的目标都是找出组织信息资产面临的风险及其影响,以及目前安全水平与组织安全需求之间的差距。

基于知识的分析方法

在基线风险评估时,组织可以采用基于知识的分析方法来找出目前的安全状况和基线安全标准之间的差距。

基于知识的分析方法又称作经验方法,它牵涉到对来自类似组织(包括规模、商务目标和市场等)的“最佳惯例”的重用,适合一般性的信息安全社团。采用基于知识的分析方法,组织不需要付出很多精力、时间和资源,只要通过多种途径采集相关信息,识别组织的风险所在和当前的安全措施,与特定的标准或最佳惯例进行比较,从中找出不符合的地方,并按照标准或最佳惯例的推荐选择安全措施,最终达到消减和控制风险的目的。

基于知识的分析方法,最重要的还在于评估信息的采集,信息源包括:

·; 会议讨论;

·; 对当前的信息安全策略和相关文档进行复查;

·; 制作问卷,进行调查;

·; 对相关人员进行访谈;

·; 进行实地考察。

为了简化评估工作,组织可以采用一些辅助性的自动化工具,这些工具可以帮助组织拟订符合特定标准要求的问卷,然后对解答结果进行综合分析,在与特定标准比较之后给出最终的推荐报告。市场上可选的此类工具有多种,Cobra 就是典型的一种。

基于模型的分析方法

2001 年1 月,由希腊、德国、英国、挪威等国的多家商业公司和研究机构共同组织开发了一个名为CORAS 的项目,即Platform for Risk Analysis of Security Critical Systems。该项目的目的是开发一个基于面向对象建模特别是UML 技术的风险评估框架,它的评估对象是对安全要求很高的一般性的系统,特别是IT 系统的安全。CORAS 考虑到技术、人员以及所有与组织安全相关的方面,通过CORAS 风险评估,组织可以定义、获取并维护IT 系统的保密性、完整性、可用性、抗抵赖性、可追溯性、真实性和可靠性。

与传统的定性和定量分析类似,CORAS 风险评估沿用了识别风险、分析风险、评价并处理风险这样的过程,但其度量风险的方法则完全不同,所有的分析过程都是基于面向对象的模型来进行的。CORAS 的优点在于:提高了对安全相关特性描述的精确性,改善了分析结果的质量;图形化的建模机制便于沟通,减少了理解上的偏差;加强了不同评估方法互 *** 作的效率;等等。

定量分析

进行详细风险分析时,除了可以使用基于知识的评估方法外,最传统的还是定量和定性分析的方法。

定量分析方法的思想很明确:对构成风险的各个要素和潜在损失的水平赋予数值或货币金额,当度量风险的所有要素(资产价值、威胁频率、弱点利用程度、安全措施的效率和成本等)都被赋值,风险评估的整个过程和结果就都可以被量化了。

简单说,定量分析就是试图从数字上对安全风险进行分析评估的一种方法。

定量风险分析中有几个重要的概念:

·;暴露因子(Exposure Factor,EF)—— 特定威胁对特定资产造成损失的百分比,或者说损失的程度。

·;单一损失期望(Single Loss Expectancy,SLE)—— 或者称作SOC(Single OccuranceCosts),即特定威胁可能造成的潜在损失总量。

·;年度发生率(Annualized Rate of Occurrence,ARO)—— 即威胁在一年内估计会发生的频率。

·; 年度损失期望(Annualized Loss Expectancy,ALE)—— 或者称作EAC(EstimatedAnnual Cost),表示特定资产在一年内遭受损失的预期值。

考察定量分析的过程,从中就能看到这几个概念之间的关系:

(1) 首先,识别资产并为资产赋值;

(2) 通过威胁和弱点评估,评价特定威胁作用于特定资产所造成的影响,即EF(取值在0%~100%之间);

(3) 计算特定威胁发生的频率,即ARO;

(4) 计算资产的SLE:

SLE = Asset Value ×; EF

(5) 计算资产的ALE:

ALE = SLE ×; ARO

这里举个例子:假定某公司投资500,000 美元建了一个网络运营中心,其最大的威胁是火灾,一旦火灾发生,网络运营中心的估计损失程度是45%。根据消防部门推断,该网络运营中心所在的地区每5 年会发生一次火灾,于是我们得出了ARO 为020 的结果。基于以上数据,该公司网络运营中心的ALE 将是45,000 美元。

我们可以看到,对定量分析来说,有两个指标是最为关键的,一个是事件发生的可能性(可以用ARO 表示),另一个就是威胁事件可能引起的损失(用EF 来表示)。

理论上讲,通过定量分析可以对安全风险进行准确的分级,但这有个前提,那就是可供参考的数据指标是准确的,可事实上,在信息系统日益复杂多变的今天,定量分析所依据的数据的可靠性是很难保证的,再加上数据统计缺乏长期性,计算过程又极易出错,这就给分析的细化带来了很大困难,所以,目前的信息安全风险分析,采用定量分析或者纯定量分析方法的已经比较少了。

定性分析

定性分析方法是目前采用最为广泛的一种方法,它带有很强的主观性,往往需要凭借分析者的经验和直觉,或者业界的标准和惯例,为风险管理诸要素(资产价值,威胁的可能性,弱点被利用的容易度,现有控制措施的效力等)的大小或高低程度定性分级,例如“高”、“中”、“低”三级。

定性分析的 *** 作方法可以多种多样,包括小组讨论(例如Delphi 方法)、检查列表(Checklist)、问卷(Questionnaire)、人员访谈(Interview)、调查(Survey)等。定性分析 *** 作起来相对容易,但也可能因为 *** 作者经验和直觉的偏差而使分析结果失准。

与定量分析相比较,定性分析的准确性稍好但精确性不够,定量分析则相反;定性分析没有定量分析那样繁多的计算负担,但却要求分析者具备一定的经验和能力;定量分析依赖大量的统计数据,而定性分析没有这方面的要求;定性分析较为主观,定量分析基于客观;

此外,定量分析的结果很直观,容易理解,而定性分析的结果则很难有统一的解释。组织可以根据具体的情况来选择定性或定量的分析方法。

以上就是关于[三问IT运维外包] it运维服务外包合同全部的内容,包括:[三问IT运维外包] it运维服务外包合同、信息安全风险评估报告应当包括哪些、如何进行IT项目管理 等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/8824684.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-22
下一篇 2023-04-22

发表评论

登录后才能评论

评论列表(0条)

保存