系统分析案例.docx
《系统分析案例.docx》由会员分享，可在线阅读，更多相关《系统分析案例.docx（14页珍藏版）》请在冰豆网上搜索。
系统分析案例
系统分析案例
论软件系统分析的方法和策略
当一个软件项目摆在人们面前时，进行系统的分析是首当其冲的,正如我们的一句古语:
三思而后行。
因此，无论做任何事都应考虑是否有意义以及它的可行性。
在过去，人们将“软件”与“程序”、“开发软件”与“编程序”划等号，粗略的进行估计和设计软件产品势必会影响软件的质量和生产效率。
然而现在，随着信息化产业的发展，软件企业的增多,尤其是当面对一些大中型的软件项目，对软件生命周期的各个环节进行系统详细的分析将更加重要,而且会提高软件的质量和效率。
一、软件系统开发
无论动物、植物，作为一个完整的事物,都有它的生命周期、或者说它的轨迹。
作为先进高科技的产物---软件产品,自然也不例外。
这期间,要经过一系列的过程,例如,开发者首先要考虑它的可行性,是否能解决当前问题或是将来是否能有更大的发展,当然要有详细的规划和设计,要形成书面的文档记录下来,以便开发员之间的交流。
其次关键的是能否满足用户的需求,因为判断开发出来的软件是否成功的标准之一就是看它有无实用性。
之后便是一系列的实施,例如程序设计,系统测试,以及接下来的后续工作---维护与修改工作。
软件生命周期的各个环节将软件系统开发大致分为四个阶段，用图示的方式表现出来即通常所说的“瀑布模型”，如图：
二、系统分析
系统分析是软件生命周期的一个关键环节，其目标是将对计算机应用系统的需求转化成实际的物理实现。
然而实际面太多，增加了软件分析的复杂度，那么究竟在系统分析的过程中需要考虑那些因素呢？
1、系统目的。
在考虑系统目的时，应更多的侧重于系统的最终目标考虑，因为一个系统不可能在最初就是完美的，要为系统留些余地。
2、系统参与者。
在整个项目中，要考虑有哪些方面参与了系统，这些参与者人可能在系统建设中起重要作用，他们采取什么样的态度将会对系统有一定的影响。
另外，还要了解各参与者的初衷是什么。
3、明确的评价标准。
最好从参与的各方面都进行考虑，要知道他们对这个系统是否有一个明确的评价标准。
4、系统开发计划的完善度。
计划表要有明确的阶段，每一阶段要有详细的完成计划，以及对阶段完成情况进行的评价。
当然还有很多因素值得考虑，可以根据面对的项目的不同而改变,譬如与软件开发人员的交流等等。
三、开发内容
开发软件系统最为困难的部分，就是准确说明开发什么。
这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。
这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。
需求类型包括三个:
1、业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。
2、用户需求（userrequirement）文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
3、功能需求（functionalrequirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
总之，无论是商业性或非商业目的的产品，都应具备完整的说明书,以避免发生状况时引起不必要的损失。
四、分析设计和系统方案
在考虑完各方面的实际因素后，就要对项目进行总体的分析设计。
简单的讲，总体设计需要确定的内容应当包括：
1、系统需要实现哪些功能；2、开发使用什么软件，在什么样的硬件环境；3、需要多少人，多少时间；4、需要遵循的规则和标准有哪些。
一般情况下，在总体设计出来后，就需要给客户一个系统的方案。
如果在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。
所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。
而方案则应包括以下几个部分：
1.客户情况分析；2.系统需要实现的目的和目标；3.系统各个模块与结构；4.使用软件，硬件和技术分析说明；5.开发时间进度表；6.维护方案；7.制作费用。
总之，总体设计阶段是以比较抽象概括的方式提出了解决问题的办法；而详细设计阶段的任务，也就是把解法具体化。
详细设计主要是针对程序开发部分来说的，但这个阶段的不是真正编写程序，而是设计出程序的详细规格说明。
这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，例如：
程序界面、表单、需要的数据等，程序员可以根据它们写出实际的程序代码；而至于后续的工作,就有程序员来完成编写程序,系统测试员来完成测试,还有之后的维护和修改。
五、运用策略
伟人有治国的策略,商人有致富的财路,巧妇有理家的本领,鹤发童颜的老人有长生的秘诀。
在进行软件开发系统分析时，也要本着一些策略：
1．“简单—复杂—简单”。
这是技术型分析人员经常碰到的情况，认为分析出错综复杂的关系，花哨的图表才能显示出分析水平高，其实，分析经常要经历"简单-复杂-简单"的过程，前一个简单表现为分析人员"认为简单"；随着分析的深入，原以为简单的问题会越来越复杂；最后，经过概括、消化、分解，使得需求简单明了。
2．软件复用技术。
新开发的软件，要从一开始就考虑其可演化性，以便以后的再工程和构件提取。
随着软件复用技术的不断发展，从头开始的软件大量减少，使用的遗产系统相应增多,这就避免了重复的工作,使得已完善的模块遗传下去。
3．模块化概念。
模块化可以增强系统的独立性，使耦合度降低，实现“高内聚-松耦合”。
对于模块的内部，使其高度集中，而模块与模块间的联系相对减少，这样使系统各模块独立的进行运转。
任何雄才伟略的人都能纵观全局,有一览众山小之气魄。
若想有出色的成果必然要有对事物进行总的分析的能力,这就包括是否着眼于长远利益,是否能对其很好的管理掌控。
系统并不是简单的计算机代替手工劳作的一种方式，它是一种高于现实的管理模式。
因此,系统分析是软件开发过程中必不可少的一个环节，它为高质量软件产品的开发奠定了基础。
教学目标：
通过对系统分析的过程进行阐述，让学生从全局把握系统开发的流程，理解其中的重点，难点，目的，要求；为以后分析设计信息系统打下基础
思考题：
1、系统开发有哪些典型的方法？
2、结合本案例谈谈系统分析的过程是怎样的，要注意哪些问题？
3、请你结合小组软件实验，谈谈你系统分析的思路，分析报告的内容？
IT系统“起死回生”的管理
台风“麦莎”72小时狂袭中国百余城市，瞬间改变了千万人的生活；从美国“9.11”事件、日本神户大地震到东南亚海啸；从2000年9月中国银行收付系统突然死机到去年北京首都机场系统瘫痪误机6,000人；再到花旗银行最近丢失390万客户信息的“数据门事件”，直至6月9日北京恒泰证券股票交易系统出现故障迫使股民望“红”兴叹?
在这不确定的信息化年代，啸聚而来的“天灾人祸”不仅给政府、商业机构甚至个人直接造成巨大生命财产损失，也对信息化时代各类组织机构赖以生存和运转的IT系统与业务连续性管理（BusinessContinuityManagement，简称“BCM”）带来毁灭性打击。
5月底，国务院信息工作办公室网络与信息安全组组长王渝次在中国首届灾难恢复行业高层论坛上指出：
“在信息网络化时代，没有灾难备份与业务恢复计划的企业，在遭遇灾难事件时常常不堪一击，甚至可能随时崩溃。
”
脆弱的系统
此次会议得到了银行、保险、制造等数十行业200多名IT主管、业界灾难备份专家及政府主管的积极响应。
大家齐聚广东南海的目的，就是共商一个“小概率”但又“高风险”的热点问题：
企业重要信息系统在遭受各类天灾人祸打击之后，如何迅速恢复并维持业务的连续性管理能力。
与会的企业高管们非常清楚，王渝次的话并不是危言耸听。
根据顾能公司（Gartner）的调查数据，在经历大型灾难事件而导致系统停运的公司中，有五分之二左右的公司再也没有恢复运营，剩下的公司中也有接近三分之一在两年内破产了。
不过，“9.11”不但没能让摩根斯坦利公司（Morganstanley）消失，就是业务正常运营的恢复，也只用了短短的2天时间。
其中的秘诀是，该公司设于美国新泽西州的完整业务灾难备份以及恢复系统，在关键时刻发挥了作用。
相比较之下，我国的金融机构防灾抗难意识及能力却极其脆弱，有时仅以一人之力就可以彻底破坏整个系统。
2000年8月，发生了一起令中国银行刻骨铭心的事件：
中国银行利川支行一名营业部主任对银行信息系统进行毁灭性破坏后，携款潜逃，导致银行数据丢失，业务陷入瘫痪状态。
应对各种灾难与紧急事件，企业需要提前推行业务连续性管理。
不过需要澄清的是，恢复并维持业务的连续性管理中，灾难备份（Backup）与恢复（Recovery）是两个完全不同的概念。
进行灾难备份的企业，在遭遇灾难后，未必能够迅速恢复，尽管前者对IT基础设施、信息技术与环境同样具有较高的要求，但企业要想在遭受灾难打击之后迅速“起死回生”，包括人员、流程、组织等非IT的业务连续管理计划、整体预案以及应急响应系统才是关键中的关键。
而国内相当数量的企业和机构，重视系统的备份，却忽视了尤为关键的灾难之后业务的恢复能力建设。
“BCM本质上是一个管理范畴内的问题。
”据国内第一位也是目前唯一获得国际CBCP认证的灾难备份专家、万国数据服务有限公司（称“GDS公司”）副总裁汪淇介绍，国际灾难备份与恢复行业已形成相当完备的BCM（或称之为“BCP”）理论体系和方法论。
化解集中的风险
深圳发展银行是国内首家实现了生产中心（业务系统）数据逻辑大集中和与灾难备份及业务持续管理系统同步建设的企业。
深圳发展银行科技部总经理刘政权坦言，深圳发展银行之所以领先同行实施BCM系统，一方面是因为把脉到BCM系统正在逐步成为国际金融通用规则的趋势，譬如在英国，业务持续管理规划已经成为企业上市的一个必要条件；另一方面是因为银行业数据大集中下潜藏的巨大风险。
数据集中也意味着风险的集中。
在深圳发展银行全行业务依赖于深圳一地单点处理的情况下，一旦深圳的电脑数据中心发生灾难，其全国范围中的全部分支机构几乎所有业务都将瘫痪。
这将造成巨大的经济损失，且不说客户流失、声誉受损，甚至还有可能会因此引起社会的不安定。
通过对业务风险与冲击影响的详细评估，深圳发展银行选用了复合等级的灾难备份方案—对核心业务系统采用“零数据丢失”的最高等级数据热备份方案；而对于一些辅助业务则采用了比较经济的第二级备份方案，在灾难备份中心保留最新的磁盘、磁带，并且定期进行更换。
该系统自2002年5月投入运行以来，包括数据、数据处理能力、网络在内的整个核心业务处理系统已经过多次切换复制，重新恢复业务流程演习，结果令人振奋。
刘政权说：
“一旦遭遇灾难冲击，只要1个小时，我们的备份系统就可以顺利切换到灾备中心的系统开展正常作业。
”
业务持续性管理（BCM）
企业通过灾难备份中心构建BCM系统，不仅着眼于IT系统的备份与恢复，更重要的是包括隐含于其中的、涉及企业整体生命周期的一种业务连续性管理策略与应急响应计划。
教学目标：
通过对本案例，使学生理解与信息系统相关的安全机制，在系统设计中能结合企业实际情况，进行数据备份与恢复子系统的设计，理解设计的相关原则。
思考题：
1、企业对信息系统安全设计有怎样的要求，试分析？
2、保障企业信息系统的安全要做好哪些方面的管理？
2、上网调查我国信息系统安全的现状如何，举例说明？
千万元工程的陨落—ERP实施亲历记
九十年代末，我当时所在的一家知名的软件开发商在一家大型制造企业获得了一项国家863CIMS项目，ERP被列为其中的一部分，另外还有CAD、CAPP、PDM系统，整个CIMS系统投入近千万。
本人作为ERP的实施顾问，参与了该项目的全过程，在长达一年半的实施过程中，对ERP有了更深的认识。
特别是对ERP在国企中的实施有深切的认识和切肤之痛，从中发现不少问题，而正是这些问题直接导致了实施的失败。
一、项目背景
这是一家产值八亿的机械制造企业，职工7000人，技术人员600人。
组织结构为5个事业部、20个处室、9个分厂、1个科研所，还附属有医院、小学、托儿所、招待所等社会福利机构。
九十年代中以来，企业连年亏损，好在树大根深，尚未大伤元气。
近来，由于国防订货激增，产品一时间供不应求。
但由于管理粗放，成本节节攀高，产值虽大，效益却很一般。
这是企业准备上ERP的动因之一。
开发商则是一家新兴的软件企业，有大约120人的开发人员。
近年来，仿照一家著名的外国软件开发出了自已的ERP软件，而这个项目则是开发商的第三个大型项目。
该项目经国家立项，列入863CIMS计划（并得到国家一定金额无偿拨款）。
因此，项目资金来源为：
自筹+上级主管拨款+国家拨款。
二、实施过程中的问题
国外关于ERP实施的阶段划分是有道理的，只有每一个阶段的工作都做好了，才能保证ERP的实施成功。
现在我就结合这个程序来分析我的亲身经历的ERP实施。
1.领导培训
ERP系统被视为一把手工程，对企业高层领导的培训是一项目十分重要的工作。
而实际情况是如何做的呢？
应该说开发商从一开始就十分重视对企业一把手的工作，但不是进行先进管理理念方面的导入，而是把大量的精力放在了公关上了。
这个价值近千万元的项目居然不进行招标，各家公司各显神通，种种手段不一而足。
只请了一位机械制造专家作了CIMS原理的专题讲演，而没有对ERP的理念作任何形式的导入工作，这就从一开始为项目的失败埋下了祸根。
原因：
一方面，开发商实施队伍尚未完善，笔者作为唯一具有开发经验和管理经历的实施顾问，既要从事开发工作，又要主持多个项目的实施，困难是很大的。
国内的ERP软件也是最近几年才出现的事，开发商尤其缺少既懂现代制造业管理又具备较高计算机水平的复合型人才。
开发商主观上认为自己在公关活动中的工作足以保证后续工作的顺利进行，也不愿意在这方面投入太大的人力、物力，尽可能减少成本开支。
除了搞了一次讲座外，就没有搞过管理理论方面的培训了。
另一方面，企业领导上ERP项目的动机复杂。
既想通过ERP提高管理水平，又有攀比跟风以及更深的不为人知的动机。
企业的各级管理人员对此也是心知肚明，所以上下都对ERP项目缺乏应有的信心和工作热情。
2.需求分析
开发商的需求分析工作也极为马虎。
仍然是出于确信自己的公关投入可以保证项目成功（这里开发商理解的成功就是收到项目款），开发商尽可能地减少成本开支，前期的系统规划工作基本上是为了应付立项报批而做的，对二次开发基本没有什么意义。
3.BPR
在这个项目的实施过程中，无论是开发商还是用户都没有提出来要进行企业管理流程再造的工作。
作为实施顾问，笔者曾提出过对企业工作流程进行改进的建议，但却泥牛入海，恨无消息。
而且在我们进驻企业的时候，企业刚完成了对组织机构的调整。
其组织结构仍然是高耸的非人格化的机械结构，我们就是在这样的管理环境下，开展ERP的实施工作的。
4.项目组织
从形式上成立了三级项目组织，企业一把手出任领导小组组长，核心小组、各部门项目组也有重量级人物出任组长。
但实际上，一把手虽说是组长，但从头到尾只参加过两次会议，说一些的官话、套话走人。
而其余负责人对ERP知识极为欠缺，信息中心主任（项目的具体负责人）虽说是计算机大专毕业，但很少钻研业务。
5.实施计划
由于CIMS涉及多个系统，计划的组织工作极为繁重，头绪极多。
但整个计划极为概略，只有一个粗线条的时间表，各系统分头进行，互不沟通。
加之在发包项目时，CAD、CAPP、PDM系统包给另一家驰名的软件开发商，不同的软件开发商所用的开发工具不一、工作方式各异，协调起来十分困难，经常出现混乱，而且开发出来的系统与我们的ERP系统不能有效集成，形成互无联系的信息孤岛。
6.培训工作
我们组织了对各部门的操作员培训班，从计算机的基本知识开始进行了系统的培训，并进行了较为严格的考试，合格的颁发了上岗证。
参加培训的是一线基层的女工，她们表现出了较高的学习热情，常常主动加班学到深夜。
但培训面不宽，没有进行持续扩大的培训，但各级管理人员没有参加，这直接影响了实施工作。
7.数据准备
企业布置了全厂的库存盘存，对库存账、物进行了一次较为彻底的清查。
但由于企业多年来实行的是粗放的生产管理方式，系统要求的一些基础数据，企业没有完整的记录，所以仍不能达到系统的要求。
比如，各零部件的制造提前期、采购提前期没有一个准确的数据，尤其是采购提前期没有历史记录资料，也没有制造经济批量和采购经济批量的概念。
我们不得不亲自整理浩如烟海的数据，进行分析勉强确定出每次订货成本、库存成本，从而为制定出经济制造批量、经济采购批量打下了基础。
另外，该厂很多零部件的工艺标准、成本标准、损耗标准均制定于七十年代，早已不能适应现在的市场情况。
8.二次开发
由于没有对企业业务流程进行重组，我们不得不对软件作了较大的修改。
在实施初期，我们坚持要求企业的业务流程按ERP的要求进行改造，双方爆发了激烈的争执。
经过一段时间的僵持，开发商的老板给发来我们训示：
用户是上帝，用户要我们怎么办就怎么办，不要再进行无谓的争执了。
于是，我们只有谨遵上帝的意愿，对软件进行了较大辐度的修改，使ERP软件带上了浓重的国企特色。
三、管理冲突
上面所述问题直接导致了两种管理模式的冲突。
1.观念之争
在实施过程中，我们一直处在先进与实用的观念之争的中心。
企业对笔者先进的管理理念和丰富的实践经验是肯定的，但又说他们那一套虽不先进但却是实用的、有效的。
支持他们的理由就是按ERP的模式重组生产，将会给已经超负荷的生产运转体制带来混乱。
实际上，正是由于企业延续三十年不变的管理体制才使得企业不能应付新世纪的挑战；正是由于旧的生产管理体制才使企业不得不进行低效益的超负荷运转。
这不可能应付市场日益严峻的挑战，总有一天会不负重荷、彻底崩溃。
如果等到企业完全丧失竞争力，再来进行重组时，可能为时已晚。
为了说服他们，笔者对企业的生产模式给他们做了详细的分析，明确指出其中的问题。
多年来，该企业的生产模式是计划目标或订货合同目标查半成品库库存数下达各分厂的月生产计划各车间生产调度指令各车间自拟物料需求计划生产处审批分厂审批各车间执行。
从这里可以看出，在下达生产计划时，传统的方法使企业生产计划制定者只考虑一个影响因素，即制定计划这个时点上马上可以用于装配成品的半成品库存数。
而其下层的物料库存数量则不在企业生产计划制定者考虑之内，而是交给下级分厂或车间自行决定，由于各部门之间信息不能共享，加之出于各种自身利益考虑，下级提出的物料需求计划常常出现多报、漏报的现象，很不准确。
且以上库存数据均为静态数据，没有考虑到即将到达的物料数量。
计划的环节多，审批烦琐，对市场的变化反应迟缓。
另外传统的生产管理模式没有进行生产能力计算，只是粗略地凭经验估计，没有制定出详细生产能力需求计划。
以上这些工作虽说对他们有所触动，然而囿于体制，企业难以对业务流程进行根本性的再思考和再设计。
2.利益之争
即便是没有进行BPR，没有出现权责利益再分配的大震荡。
但ERP项目仍给企业各级管理人员带来了利益之争。
由于这次项目的决定上，主管生产的副厂长在系统选型时被排除在外，其它领导对项目决定的方式也存在不满，所以一直对实施ERP采取消极态度。
而各车间、分厂的管理者则有很多人担心ERP系统的实施使他们对下面的管理太过透明，不利于运用权谋来治理下属，故而也采取了消极观望的态度。
3.粗放与精确之争
根据ERP的原理，我们要对制造的各环节进行精确的控制。
以α产品为例，该产品的BOM由十七层共127个物料组成。
其中有制造件、委外加工件和采购件，有的制造件工序达到几十道之多。
关于如何制定产品的BOM，我们与生产管理部门爆发了激烈的争执。
最先，我们和企业有关人员研究决定，根据α产品的零件表把BOM划分为十七层共127个物料，生产管理部门起初由于对ERP的工作原理不甚了了，也没有提出反对意见。
但在实践中一经施行，上下爆发出一片反对声。
企业长期以来一直管理粗放，工序多、流程长、环节多，制造加工过程常有各种损耗，发生差错又经常上推下卸。
车间与车间之间、各车间与分厂之间、分厂与总厂之间的统计数字长期不一致，经过多次大规模人工清查，仍然查不清原因。
整个制造的过程宛如一个黑箱，主管生产的领导只知道从源头投入了多少原材料，最后产出了多少成品；而中间损耗的详情不清楚，如具体损耗在哪一个部门、哪一个工序、损耗多少、原因是什么、责任人是谁不甚了了。
企业的领导极想通过ERP系统来控制生产的全过程，搞清上述问题。
那么要做到这一点，就必须把BOM层次分得尽可能细，当然就要求对BOM上每一层次的物料进行控制，要求每一个责任人每天录入收到原料数、加工完成数、加工损耗数、未加工完成数、检验合格数、加工损耗原因等数据。
生产线上的每个环节、每个责任人都处于受控状态，这当然与原有随意、散漫的工作模式大相径庭。
于是，从生产管理部门的管理人员到生产线上的工人都以种种理由拒不执行。
一个荒唐可笑的理由竟是ERP系统的工作模式产生控制单据过多，浪费纸张。
这一方面固然有两种管理模式更迭带来的必然振荡，而更有各级利益的深刻冲突。
作为企业的高层领导当然希望通过ERP系统更有效地对下面的工作情况进行监督，而中下层的管理人员、工人当然不愿意接受这种单方面的监督。
高层与中下层之间、中下层与工人之间原本就存在深刻的矛盾冲突，而ERP系统的实施在某种程度上加剧了这一冲突。
这也是没有事先进行BPR所带来的一个明显的恶果，如果事先进行了合理的管理改进，把各方的利益结合起来，就不会导致这种普遍反对的结果。
面对来自中下层的强烈反对，国有企业的管理弱点暴露无遗，高层领导也不敢强行推行。
最后，由开发商与企业的领导商讨后裁定，适当减少层次，减少控制环节。
于是α产品的BOM结构层降为9层86个物料。
4.采购方针之争
根据ERP的管理思想，应当在需要的时间向需要的部门提供需要数量和品种的物料。
原则上，要求物料不能脱供也不能早供。
然而，企业的实际情况却是生产所需求原材料以季度为单位进行采购。
也就是说，本季度生产中所需的大多数原材料在上季度末采购到位。
这就造成企业长期库存大、周转慢，而一旦市场发生变化，对生产进行调整而再需要某些已采购物料，则会造成库存积压，而调整生产后所急需的原材料又无钱购买。
我们提出了严格按ERP的物料需求计划生成的采购订单进行采购的解决方案。
但采购部门却认为，由于该企业采购资金紧张，通常采用赊购的采购方针。
而赊购某些较为紧俏的物料依赖业务人员的业务能力，订货周期难以确定，当然也不能制定正确的采购提前期。
我们认为采购部门提出的问题肯定有夸大的成分。
对于采购部门列出的26不能保证准时供应的物料（全是对生产有重大影响的物料），我们逐一对其市场情况作了详细调查。
最后确定只有2种物料的采购提前期是难以确定的，18种能很方便的确定，还有6种经过努力也能确定。
然而，企业并没有对采购方案调整。
四、结果
在开发商和企业共同“努力”下，此项目通过了国家863“专家组”的鉴定，并在各种媒体大吹大擂。
开发商如愿以偿地挣到了钱，有关人士也得到了不少好处。
而留给企业，留给工人们的是什么呢？
CAPP、PDM早已废置一旁，ERP中的生产计划、销售、采购模块仍然没有发挥作用。
倒是库存管理、人事管理、财务管理还能起一些作用，但企业付出的与得到的实在不成比例。
教学目标：
本案例对某企业实施ERP系统的过程进行了阐述，帮助学生理解企业信息化的一般过程，了解可能遇到的问题与阻力，更深刻的认识到信息系统建设的复杂性，并使用管信相关的知识和理解进行分析解决。
思考题：
1、如果你是作为ERP项目的分组负责人，在前期的管理理念项目培训中，你认为应该给企业灌输哪些理论或实践，才可以促使企业更好的认同ERP？
你如何向企业介绍ERP与其他一些应用型开发软件的区别？
你打算怎样制定你分组的项目计划书主体内容，给出你的提纲？
2、如果你作为企业的中层管理人员，你认为企业领导该如何规划项目才能够
升级会员 