壳牌石油IT架构规划与实施经验.docx
《壳牌石油IT架构规划与实施经验.docx》由会员分享，可在线阅读，更多相关《壳牌石油IT架构规划与实施经验.docx（10页珍藏版）》请在冰豆网上搜索。
壳牌石油IT架构规划与实施经验
壳牌石油IT架构规划与实施经验
-----------------------作者：
-----------------------日期：
壳牌石油IT架构规划与实施经验
2003-06-1116:
33 柴勇、蔡建明/（ChinaByte）
经过不到1年时间的SAP实施，分别于2002年10月和2002年12月在镇海炼油、仪征化纤、石油公司和石油公司成功上线。
2003年计划在新的7个试点单位进一步推广实施SAP系统。
由于历史原因，前4个试点单位均在本地安装了各自的服务器系统和网络系统，服务支持也偏向于本地支持。
在新的试点单位启动之前，迫切希望了解SAP全球大型石油石化企业，它们的IT架构是如何构建的。
希望能和这些石油企业进行知识和经验的分享，从中借鉴一些经验与教训，以便在的实施过程中少走弯路。
众所周知，IT架构的构建是整个应用系统的基础，早期合理的、具有预见性的设计规划将为企业今后的应用打下良好的基础，从而事倍功半。
Shell（壳牌石油公司）是全球知名的能源行业的巨头，2002年在全球500强中排名第X位，在全球石油石化行业排名前3甲。
她的业务覆盖有加油站燃油和润滑油的销售，陆地和海上的石油勘探与生产，以及天然气的开发与生产。
Shell在全球的业务还包括为商业用户和消费者提高天然气与电力的服务，其化工产品几乎包罗了所有商业和家用产品材料。
同时Shell还在新能源领域，如氢、太阳能、地热能源和风力能源上大力开发，业务快速增长。
Shell的业务遍及145个国家，雇员超过11万5千员工。
Shell公司的目标是：
以经济的、大众化的和环保的手段，满足社会现在和将来对能源的需求。
中国石油化工股份是中国最大的一体化能源化工公司，主要从事石油与天然气勘探开发、开采、销售；石油炼制、石油化工、化纤、化肥及其它化工的生产与产品销售、储运；石油、天然气管道运输；石油、天然气、石油产品、石油化工及其它化工产品和其它商品、技术的进出口、代理进出口业务；技术、信息的研究、开发、应用。
是中国最大的石油产品（包括汽油、柴油、航空煤油的批发和零售）生产商和供应商，是中国最大的主要石化产品（包括中间石化产品、合成树脂、合成纤维单体及聚合物、合成纤维、合成橡胶和化肥）生产商和供应商，也是第二大原油生产商。
中国石油化工股份参照国际模式，构筑了新的公司架构，建立了规的法人治理结构，实行集中决策、分级管理和专业化经营的事业部制管理体制。
中国石油化工股份现有全资子公司、控股和参股子公司、分公司等共70余家，包括石油企业、炼油及化工企业、销售企业及科研、外贸等单位，其生产资产和主要市场集中在中国经济最发达、最活跃的东部、南部和中部地区。
中国石油化工股份发展的目标是真正建设成为主业突出、资产优良、技术创新、管理科学、财务严谨、具有国际竞争力的世界级一体化能源化工公司。
SAP公司根据的需求，联系到Shell公司的Anthony先生，Shell公司远东地区IT部经理，首席SAP支持服务顾问，拥有20年以上的SAP系统管理、项目管理和底层技术支持的经验。
由于中国非典疫情的特殊情况，SAP中国组织了一次与Shell新加坡公司的电视会议，主题是：
"SAP系统的IT架构与选择"。
由于商业的原因，在此我们不会过多提及的应用情况，而是介绍Shell公司的经验和知识。
参加此次交流会的中方人员有项目管理主管，IT管理主管和高级工程师，石化盈科的IT顾问和埃森哲咨询公司的项目主管和实施顾问，以及SAP公司石油天然气行业的人员。
1. SHELL全球及亚太地区IT架构介绍
从全球围来说，目前Shell公司在用的ERP系统主要包括两种软件：
SAP与JDE。
截至2000年12月止，Shell公司全球共有约53,000名用户在使用SAP的系统，同时有约8,000名用户在使用JDE的系统（当时Shell全球的雇员数约为100,000人）。
从地理分布上来看，应用SAP系统的企业主要分布在美国、欧洲大部及亚太地区；而应用JDE系统的企业主要分布在加拿大、非洲及南美洲。
形成目前这种布局有其多方面的原因：
1. 由于Shell公司在全球的业务均是通过与各个地区或国家的企业设立合资、独资或合作经营的形式进行经营。
各家企业相对有较高的经营自主权，集团总部更多是在人力资源、资金调度与运作以及重要战略决策方面进行宏观调控。
因此Shell集团下属在各国和地区的企业在进行信息系统项目建设的过程中都有自己的决定权。
这从根本上决定了Shell公司在全球围的ERP系统不同于全球其他大型跨国石化企业
2. 由于历史的原因，Shell集团下属公司在进行信息系统建设时也选择了两种不同的ERP系统：
SAP与JDE。
随着时间的推移及业务上不断的实践，Shell公司逐渐认识到SAP系统更能满足Shell管理上的需要，也更能满足石油天然气行业业务上的需要。
同时，Shell为了统一业务标准和模式，降低IT成本和运营费用，在全球的IT系统应用要逐步变成集中式的系统架构。
因此从战略上决定在Shell公司全球围的核心业务及地区均采用SAP的ERP系统。
3. 之所以在还保留着部分JDE的系统，主要是从成本角度考虑。
从上图中可以看出，目前使用JDE系统的企业主要分布南美洲及非洲等通讯不发达的国家和地区，而作为核心业务的地区，如美国、欧洲、中东及亚太地区均使用了统一的应用系统－SAP系统。
就整个中东及亚太地区来说，Shell公司具体的IT架构又可分为几种：
1. 澳大利亚模式：
由于地理上的特殊原因，Shell在澳大利亚的企业有自己独立的ERP系统及系统配置，以及独立的支持维护队伍；
2. 泰国与菲律宾模式：
泰国与菲律宾均有其各自独立的ERP系统及系统配置，但是这两个国家并没有自己独立的支持与维护队伍，他们所需要的维护与支持服务均由位于马来西亚维护服务中心统一提供；
3. 新加坡模式：
新加坡也有独立的ERP系统及系统配置，但与泰国与菲律宾不同的是他ERP系统的服务器是放置在马来西亚，而不是在新加坡国。
另外，他所需要的维护支持服务同样由马来西亚维护服务中心统一提供；
4. 马来西亚、中国（包括及）及中东（包括阿曼及迪拜）模式：
这五个国家和地区共享同一服务器、同一套ERP系统。
服务器放置在马来西亚的吉隆坡。
中国及中东的业务均通过网络远程登录至马来西亚的服务器中进行操作。
维护支持服务统一由马来西亚维护服务中心提供。
从上面的介绍中可以看到，Shell的SAP系统服务支持从中东到中亚，只有2个集中式的服务支持中心，一个是马来西亚的吉隆坡和总部的准噶尔，墨尔本的服务支持中心只负责澳大利亚自己SAP系统的服务支持。
在上述四种模式中，只有第四种模式可以称得上是完全意义上的、集中式的IT架构。
无论是马来西亚境的企业，还是中国境的或中东的企业，均共享同一套服务器，遵循系统中所设定的、标准的业务流程和规（约80－90％的业务模板是标准的）。
同时又充分考虑到不同国家和地区法律、法规的不同在系统中进行了必要的调整，以适应各国和地区对财务报表等方面的特殊需要。
另外，还有一点值得提醒的是，无论是澳大利亚、泰国、菲律宾，还是马来西亚，上述每个国家境的各个生产型或贸易型企业无论数量多少，均共享其位于当地国的同一套服务器。
Shell公司在全球的应用情况是，欧洲采用的是完全集中式的IT架构，在欧洲SAP系统中有超过1万个用户。
Shell全球SAP人力资源系统采用的是全部集中式的IT架构。
2. IT架构和选择标准
对于大型公司其业务运营一般都是基于业务部门运作，或是区域管理运作，或是企业集中运营管理。
针对业务运营模式，IT的决定因素来自三个方面，即硬件、系统结构和服务支持。
这三个因素都有三种选择，即A）L（Local）本地管理；B）BS（centralizedperBusinessSector）按照业务部门集中式管理；C）C（Centralizedacrossallbusinesssectors）所有业务部门统一集合管理。
从理论上将，用户的IT架构如下有27种组合：
如何构建一个公司系统架构，应该从以下几个方面进行分析：
1. 考虑可能影响的因素，比如网络稳定性、带宽，公司分布等等
2. 确定哪几个因素对你的决策至关重要
3. 评估企业现在和将来的应用环境与变化
4. 对各个因素进行综合评估选出最佳方案，特别要强调的是这个方案要满足未来2年以上的发展要求
用户要考虑的问题是
1. 采用集中式的IT架构还是分布式的IT架构
2. 如何处理各业务部门或事业部直接的业务系统和IT系统
3. 采取集中或分布式架构时，一套系统或多套系统，如生产服务器、测试服务器、开发服务器等，它们之间的关系
4. 从分布式走到集中式IT架构，系统合并的问题
5. 对这些IT系统的支持服务
A）硬件系统物理地点选择，集中式与分布式的优缺点比较：
减少硬件物理地点的优点是：
1. 减少系统运营成本，提高系统运营性能
2. 最重要的是公司可以尽可能地统一配置标准，总部可以进行集中的统一控制
减少硬件物理地点的缺点是：
1. 通讯费用增加使通讯成本的增加
2. 对网络系统的依赖性增加，对网络的要求增加，如网络的稳定性等。
从这个角度将，网络的结构将决定硬件系统的架构
B）从系统配置方面比较集中式和分布式的优缺点：
减少系统配置数量的优点是：
1. 减少实施成本和服务支持成本。
减少实施成本比较容易被理解，减少服务支持成本是因为如果企业采用多种系统配置（从硬件到业务模块），势必需要多个队伍支持这些不同的配置。
很难让一个人掌握多种业务模块在系统中的配置。
2. 特别是可以对业务流程进行标准化，对用户更加有利，增加流程的适用性，降低成本。
SHELL是基于事业部进行集中化改造的，每个事业部各国家的业务流程很多是共同的。
由于普遍采用了标准化流程和配置模块，SHELL地域和全球的服务支持相对要容易很多。
减少系统配置数量带来的不利因素有：
1. 修改业务流程的难度增加，因为改变一个流程会影响到其它国家和地区业务部门的流程。
2. 需要各支持服务的行动协调一致，这包括系统宕机时问题的处理。
C）从维护支持服务方面比较集中式和分布式的优缺点：
减少维护支持服务队伍数量的有点是：
1. 降低维护支持成本，提高维护支持服务的质量。
在SHELL基本是一个维护支持队伍只支持一套系统配置，如果让一个维护支持队伍支持多套系统配置，这种难度太大，对单个服务支持人员的要求太高，因为服务支持人员必须清除多套系统配置的差异是什么。
2. 改善对系统修改的控制力度。
在SHELL公司，服务支持有一套完善的服务支持规程和对底层系统的控制流程，因此服务支持方面效率是比较高的，而且被最终用户认可。
减少维护支持服务队伍的不利因素是：
1. 集中化服务支持的前提是尽量减少配置模板数量，导致各国家或企业只能依靠维护支持服务队伍，而这个队伍又不在这些国家和企业的控制围。
3. SHELL信息系统建设过程中的经验与教训
Shell在亚太地区实施SAP的最初计划是在各个国家和地区使用同一个模板、同一个配置。
然而随着项目的进程，由于各个国家和地区在业务管理上的不同要求及其他方面的不同，特别是由于各支实施和支持队伍是分散在各个国家与地区，项目管理上没有对各支实施与支持队伍做到集中控制，最终就变成了现在的不同国家不同版本不同配置的SAP系统的状况。
如上图所示，目前这种分散的系统分布状况对Shell亚太区下一步的合并带来了很大的障碍。
这也是Shell公司在项目实施过程中最大的一个教训。
Anthony特别强调了Shell在亚太这几个系统实施应用的效果，从本质上来说，马来西亚的系统应用是最为成功的。
最初在马来西亚开始项目实施时，并没有考虑到这套系统将来会被中东地区、中国及特别行政区共享，因此在最初设计系统时完全是按照马来西亚的法律、法规及管理上的要求设计的。
而后第二阶段在项目进行推广时，考虑到Shell公司全球进行系统集中的战略，因而将中东地区、中国及特别行政区的应用也纳入马来西亚的系统中。
在大部分共享系统用模板及业务流程的基础上，基于各国、地区管理上及法律法规上的特殊需求对系统进行了适当的调整与修改。
虽然使用马来西亚SAP系统的其它国家不断会有各式各样的业务要求，但这些要求都是被一个实施队伍统一管理。
从Shell在亚太走过的道路看，将来再实施新规划和远期规划绝对不会走这样一个分散的道路，而是要走中央控制道路，一方面减少硬件方面的投资，另一方面是减少实施和维护支持服务成本，特别是业务模板的统一和规。
所以在业务标准模式化和标准化过程中一定要统一管理，而统一管理最终是要落实到支持实施队伍的统一。
只有实施队伍统一，控制得好的话，在整个实施中才能确立一个标准。
实施队伍是不能分散的，系统的权限是要统一管理，集中到中心系统。
4. IT架构设计与规划中用户关心的问题解答
问题：
当几个项目同时实施时，如何进行集中管理？
（答）Anthony觉得如果同时展开几个项目确实是一个比较大的挑战，Shell在上游的项目实施就是这种情况。
在壳牌有一个控制点－即支持服务点来控制同时几个项目的并行实施，只有这个集中的支持服务队伍才有权对系统进行配置和修改。
其它实施点起的作用就是收集和输送需求，而不可以自己对系统进行配置和修改。
集中做配置可能相对慢一些，但好控制。
而且也有利于资源的统一管理和调配，对整体实施资源的要求较低。
当然，这种实施模式对集中的服务支持人员要求较高，同时要求有很高的效率及快速的响应，否则将会影响整个项目的进程。
其实，对于每个事业部部来说，它们大多数的业务需求均是一致的。
根据Shell的经验，有超过80％的核心业务流程是可以统一模板的。
譬如吉隆坡模式的实施看起来可能会慢一点，但由于相对修改很少，这样项目是可控制的、管理相对容易，整体速度反而要快一些。
Anthony曾担任泰国项目的项目经理，在泰国项目实施过程中即执行上述控制过程：
泰国的项目小组人员只能进行数据输入，或从系统中取数，但没有权限进行配置和修改。
问题：
目前，的计算机网络是星型拓扑网络结构，连接超过70个单位从本地到的通讯，与企业连接的带宽是2M。
请问Shell的网络结构是怎样的结构，中石化的这种网络结构是否能满足集中式的IT架构要求？
Shell目前的网络结构也是星型拓扑网络结构。
Anthony就SAP系统对网络带宽的要求做了个估算：
平均每1000个用户大概需要2至3M的带宽。
比如，Shell到吉隆坡系统的带宽是384K，而的用户数大约是100个用户。
从另一方面来说，最终决定系统对带宽要求的并不是用户总数，而是在系统上的并发用户数。
并发用户数量及业务操作量才会对网络形成真正的压力。
问题：
Anthony，Shell机构到吉隆坡系统的备份线路有几条？
Shell到吉隆坡目前有一条备份线路，是ISDN。
如果中石化目前是1万个用户，那么2M的带宽肯定是不够的。
中石化可以选择把系统放在本地，但支持服务进行集中管理。
这样，系统的带宽是可以满足这种IT架构管理要求的。
问题：
SHELL在事业部的设置和加油站管理方面与不同的地方？
SHELL的业务分为3个板块，E&P（勘探与生产）、OILPRODUCT（油品业务）和CHEMICAL（化工产品）。
如油品业务来说，从上游炼油至下游对加油站的油品销售都属于油品业务部管辖。
因此SHELL每个板块之间的业务往来很少，部业务往来多集中在业务板块部。
由于组织架构的划分与Shell有本质的区别（如炼油与油品销售是分属于不同事业部的），这也决定了各业务板块之间必然存在大量的业务往来。
SHELL很少管到加油站层次，因为国外加油站多属于CODO（CompanyOwned，DealerOperated）或DODO（DealerOwned，DealerOperated）。
加油站的经营管理及产品多属于经销商，Shell公司并不参与加油站的经营过程。
而绝大部分加油站是COCO（CompanyOwned，CompanyOperation公司拥有公司运营）模式，所以加油站管理对是非常重要的一块业务。
问题：
目前SHELL的网络情况
SHELL目前也是采用星型网络结构，对小型企业和小的国家的网络带宽一般是512K，大公司、国家的带宽大约是1M。
每个国家或公司有多少条备份通讯线路（Backuplines）取决于当地可提高网络服务的能力、线路的可用量以及当地公司的财力。
问题：
据我们所知，SHELL正在做IT应用的集中化改造，我们想了解你们做这个改造的业务驱动力（或业务需求）是什么，促使你们投入巨大资金来做？
是否是因为成本和标准化的原因？
Anthony认为最主要有两方面的原因，即节省成本及保证业务流程的标准化。
所以SHELL在油品业务板块正在全面进行流程标准化工作。
一方面，标准化给IT建设，同时也给业务带来诸多益处，同时借助SAP系统，再将这些标准化的流程进行固化。
如果没有这套系统，即使做了标准化也是空洞的。
问题：
在SHELL进行IT应用集中化改造的过程中，是否遇到了需要对管理模式进行改革的地方？
肯定需要在管理模式上进行一定的改变，所以信息系统的集中需要公司高层领导的全力支持及承诺。
比如在前面提到的油品业务板块，在业务上，原先美洲、欧洲及亚洲各有一位副总裁负责该地区的生产与销售业务，而后为了统一管理，对市场做出快速有效响应，Shell全球进行了一次重大的改革，即将原先由三位副总裁负责的事务合并为一位全球副总裁统一负责。
与之相适应，在全球信息系统项目实施过程中，Shell亦成立了一个管理委员会，对过去分散在各个公司或国家的业务流程管理小组进行集中的控制与管理。
各地区的业务流程小组负责收集、归纳不同的业务需求，由流程拥有者汇总、总结、制定模板。
底层的关键用户和各个业务流程小组可以提出他们所有的需求，但最终这些需要得到控制的。
而不像过去那样，每个项目小组都有权限对系统进行修改。
这个变化可以说是一个非常大的BPR（业务流程重组）。
特别强调的是，无论管理委员会还是各业务流程小组的成员，均是在各业务领域资深的专家，具有权威性，这样才能很好地把握需求。
当有原则性问题，如管理的重大变革等问题出现时，管理委员会将这些问题提交董事会（最高层管理层）进行决策。
问题：
下一个问题是有关IT应用集中化改造中的原则，比如是按照事业部进行集中吗？
SHELL公司目前在油品业务板块和化工业务板块正在进行这样的工作，你是否可以就SHELL公司在这方面的经验进行介绍？
目前SHELL是按照事业部进行集中化改造的。
因为，事业部的各单位有共同的产品和共同的管理模式。
你们所问的问题正是SHELL在做集中化改造之前非常关注的事情，是在得到高层明确承诺的情况下才开始工作的。
问题：
由于你们是按照事业部进行集中化改造的，你们如何处理事业部之间的业务往来呢？
在SHELL公司3个事业部之间的业务往来比较少，在每个事业部部的业务往来很多。
这主要是因为SHELL的每个事业部，它的业务链是完整的，也即它的产品销售、生产和开发是归属一个事业部的。
比如SHELL的油品业务板块，它的炼油和终端的加油站销售是隶属一个事业部。
而的炼油与销售是归属不同事业部，因此跨事业部的业务往来较多。
从这点看，SHELL进行应用集中整合相对要容易一些。
SHELL公司把事业部之间的业务往来按照供应商与客户的关系处理，但这种SHELL自己事业部之间的供应商和客户在系统中有特殊标示，以便在做Consolidation（合并报表）时，系统可以区别对待。
SHELL的SAP系统将每个国家设成是一个Client（客户），每个国家的公司和子公司设成公司代码。
问题：
我们知道你们在马来西亚等几个国家已经使用了集中式应用架构，你们是否遇到过网络崩溃的事件，是如何处理和防的？
在应对突发事件时，SHELL制订了2个计划：
一个是业务连续性计划，就是当出现任何可能的故障并致使系统无常使用的时候，我们可以采用什么方法继续我们的业务运作；另外一个是灾难恢复计划，这是专门针对IT所制定的措施。
由于这两个计划对于企业业务的正常运作的至关重要性，因此他们在上线之前一定要预先制订并进行完整测试以证明这些计划的有效性。
首先对于业务连续性计划，关键业务人员要提出哪些业务信息在没有系统时是十分关键、不可缺少的，对于这些信息就需要定期从SAP系统中下载到本地系统和PC机中。
比如，一般对企业来说销售与出货是最重要的，因此与销售业务相关的销售的价格、客户的信息及可以享受的信用与折扣等信息是企业业务运营的关键信息。
根据业务连续性计划，这些数据应当定期地从SAP系统中备份至本地系统或PC机中（当然要进行适当地权限控制，以防企业泄漏）。
这样当系统发生崩溃时，关键业务人员还可以从本地系统或PC机中得到他们所需要的业务信息。
另外，该计划还需要制订在系统无法运行时，相关业务操作是通过其他备份系统还是通过手工操作进行，以保证业务运作的连续性。
Shell公司在这方面主要是通过手工操作进行的。
另外一点Anthony先生提到很重要的是，业务连续性计划在系统上线前一定要经过必要的测试以证明该计划的有效性，这对于保证企业业务将来稳定持续进行非常重要。
Anthony先生认为，在业务连续性计划中还应考虑，在系统不能正常运作的情况下所有手工操作的业务数据，在系统恢复正常后如何再补入系统中。
第2点是在系统恢复以后，如何将历史数据及当前数据重新输入系统中，这就是系统灾难恢复计划。
信息部门在搭建整体信息架构时就应当有所考虑，如前面提到的备份线路。
灾难恢复计划同样应当进行测试，以保证计划的可行性及有效性。
问题：
SHELL的网络是否稳定？
你们是否遇到过网络方面带来的问题？
SHELL的网络总体感觉是不错的，但即使这样也时常会有网络中断而造成宕机的情况。
比如一次在中东地区，由于当地政府管制的原因造成网络瘫痪，数据无法传输；公司至今也发生过一次网络中断事故。
一般情况主线中断还会有备份线路，非常偶然的情况下备份线路也会同时中断。
所以，Anthony先生认为，即使当地的网络很好，线路很稳定，出现网络中断也是不可避免的事情。
因此业务连续计划与灾难备份计划就十分重要，这是做到防于未来。
问题：
Anthony，你可以介绍一下SHELL在欧洲是如何进行应用集中化改造的吗？
由于的一些特殊原因，势必要走一条从分布式应用架构到集中式应用架构的道路，你能否介绍一些SHELL从分布到集中过程中所遇到的困难，这个里程是什么，应该注意什么，以便于借鉴。
SHELL在欧洲的各国家，开始也是一个个独立的SAP系统，后来SHELL先将业务流程进行标准化和模板化，在一个国家实施，再把其它国家一个个纳入到该系统中。
目前在欧洲的ERP是一个统一的系统，全欧洲有大约一万名用户在应用该系统处理着Shell欧洲公司的核心业务。
在欧洲项目实施过程中，遇到的最大困难和阻力在于如何确定标准模板和业务流程，以保证这些标准模板和流程能够覆盖各企业大部分的业务流程。
在最终确定标准的业务流程及模板后，项目在各个国家的推广实施是显得相对容易很多，因为标准模板和流程已能覆盖各企业70%--80%的业务流程和管理需要，剩下要做的是针对各个国家和地区的法律法规要求进行少量的个性化修改（财务报表是这些特殊要求中的主要部分）。
在推广标准过程中，另外一个重点是对各国企业的管理层及用户进行重新培训，以使他们尽快掌握新系统及新流程，这对于新系统的及时成功上线及今后的稳定运行同样非常重要。
每个地区在集中化改造过程中的投入也不尽相同：
美国的投资就比较大，而中东的投资
升级会员 