项目经理工作心得体会.docx

项目经理工作心得体会.docx

《项目经理工作心得体会.docx》由会员分享，可在线阅读，更多相关《项目经理工作心得体会.docx（12页珍藏版）》请在冰豆网上搜索。

项目经理工作心得体会

项目经理工作心得体会

项目经理工作心得体会

【篇一：

项目经理培训心得体会】

项目经理培训心得体会

——参加镇江市物业企业项目经理培训——在公司工作已有数年，这次有幸参加镇江市物业企业项目经理岗位培训，通过这次学习，让我对物业这方面有了更深的一层理解，受益匪浅。

这次培训，专业层次高，项目内容深。

是一次高水平，高效率的学习，不单是理论学习，而是对近几年来物业实际工作的创新的讲解和对企业内形式的介绍，比较和分析。

从理论到实际、实例，详细而丰富的将物业这行的精华呈现而出。

短暂的培训，深入独到，是我们每个学员的“加油站”，岗位的“起跑线”，这必将对我在今后的工作中产生积极而深远的影响。

现将我在这次培训过程中的学习感受归纳如下：

一、学习

1、学习风气正，在学习过程中，大家始终以积极饱满的热情，严谨求实的学风。

2、认真听讲，细致做好课堂笔记。

3、坚持理论联系实际，着眼于回答工作中遇到的实际问题。

4、将自身学习到的知识发扬到公司，改观公司人员旧思想，不断学习新知识。

二、收获

通过这次学习，经各位老师的精辟解析，独到的见解和大量的旁征博引，让我在无比叹服的同时深受鼓舞和教育，使我对这行业有了更深刻的了解，感觉自己的思想得到了进一步的升华。

1、提升了我们的理论素质。

作为公司的重要岗位的项目负责人

必须具备良好的理论素养，对行业的最新政策和重大现实问题要有系统的了解和准确的把握。

并且要熟悉社会发展的整体走向，否则就无法在今后的工作发挥应有的作用。

在学习过程中，由于我们的老师都是学术造诣较深、在学术和实践研究方面有一定影响的专家，他们的讲解通俗易懂，对于我们领会和掌握以前工作中未曾触及的知识具有重要的指导作用。

我们还比较系统的学习了有关法律法规、基本理论，深入研究了当前工作中面临的现实问题，对于我们强化理论基础、开拓视野、提高素养，进而做好今后本职工作必将产生重要的影响。

2、加强各方面的修养。

这次学习课程安排多样，我们感觉到了领导对物业整个行业经理人的期许，希望通过各个方面课程的讲解，能够使我们整体素质得到进一步提高。

此次培训，使我深深的体会到培训的重要性和迫切性，也使我由衷感觉有幸参加了这次的培训。

总之，这次物业项目经理岗位培训，使我学到了很多的新观点、新思路和新方法，进一步提高了理论水平，增强了分析和解决实际问题的能力，培养了长远眼光和决策思维。

我一定要以这次学习为契机，用学到的新知识和新思想去指导以后的工作，努力创新，勤奋工作，为所在物业公司再做新的更大的贡献。

最后，要衷心感谢万科物业公司和江成律师事务所的培训老师，为本人提供这次难得学习平台，谢谢！

镇江物业管理有限公司

2013-12-5

【篇二：

项目经理工作总结心得】

项目经理工作总结心得

时间：

2012-08-30作者：

模具联盟网点击：

77评论：

0字体：

t|t

本人做项目经理工作工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理工作最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。

以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。

项目开始阶段是一个最重要的阶段。

项目经理工作在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：

1、这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。

在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。

一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。

前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。

2、这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。

项目经理工作需要了解每个方面的人对这个项目的看法和期望是什么。

事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。

没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理工作是一定要记住的；

会放弃这个项目。

总之，没有人能完成一个不可能完成的任务，如果项目经理工作不能尽早发现风险，那么就只能去当烈士了。

7、明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。

很多项目经理工作都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。

成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理工作本人，大项目里会配备行业专家，这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。

我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。

其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。

8、现在你要面对三群人：

你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。

既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。

很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。

下面的东西看起来无聊，其实还是很管用的：

第一个是规定信息的流动方式和介质，是推还是拉。

推的意思就是项目经理工作将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。

这种情况适合小项目，人少；拉的意思就是项目经理工作就是一个类似web服务器，你自己需要什么信息就去问他。

当然，没有项目经理工作把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。

说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。

当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通

和被动访问是同时存在的，尤其是对领导，项目经理工作更加应该主动去和领导沟通。

第二个问题就是文档问题，很多人怕写文档，但是项目经理工作一定要牢记“好记性不如烂笔头”的道理。

有理有时候为什么会说不清呢？

就是因为没有证据。

所以项目经理工作开始就要和客户说清楚有些文档是必须签字的，比如项目经理工作的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。

记住：

说了的就和没说一样，只有写下来大家签字后才算真正发生了的。

还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。

这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：

如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。

再比如不同事件的审批流程问题：

什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理工作专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。

事先想得越周到，以后的项目经理工作就越主动。

9、好了，做了很多前期项目经理工作，定义了一些游戏规则，现在是坐下来做计划的时候了。

这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。

首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。

项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。

需求定义的是做什么的问题，而这里说的是怎么做的问题。

这里要强调一点：

完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。

有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：

你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。

采用一个计划会让你的工作更加明确，比如用微软的project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。

所有的结果最后用一个叫做甘特图的形式表现出来。

你做完这个表以后会惊奇地发现，甘特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。

当然，学过项目管理的人会大谈什么wbs、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。

如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。

这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。

按照什么标准牺牲？

这个项目的战略！

我们在第三节提到过的战略。

我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。

所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？

战略决定优先级，而正确排列事情的优先级是一个项目经理工作能力的主要体现。

好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。

进入这个阶段反而是项目经理工作比较空闲的时候，不像前期的时候项目经理工作要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。

当然，小项目的项目经理工作往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。

项目经理工作这段时间的主要工作是保持和客户领导以及自己领导的沟通。

和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：

“王局长，最近项目进度还算正常，就是jvm经常发生一些内存泄漏的情况…”王局长：

“（*$@@”。

和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。

和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。

与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。

一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。

这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。

你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。

所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。

会后，你自己写文档，做决定。

会议上大家的面子都被照顾了，自然实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。

组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。

在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：

美观大方、简洁明快】，这个要求我就不知道如何检查。

所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉ejb编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。

所以，时刻考虑如何检查结果、如何向客户交付是项目经理工作一直要注意的事情，我听说有些老项目经理工作拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定项目经理工作计划。

很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。

做项目就是为了验收，我们的

角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。

另外我插一句：

我是极其不主张到客户现场开发的。

尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。

我的做法是项目经理工作和项目实施人员到现场，软件开发人员还是在公司做项目。

项目实施人员就是初级项目经理工作，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。

他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得多。

接着，我们再谈谈最让人头痛的需求变更问题。

变更通常分为两种：

一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。

碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。

这时候，如果需要

改并且你的战略是容许这种情况的，那么注意下面几点：

1、确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；

2、和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？

3、（项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。

然后再让客户在上面签字。

见过医院给病人做手术以前让家人签的免责条款吗？

对，就学习那个，让大家都意识到任何的更改都有成本和代价。

【篇三：

项目经理心得体会与经验】

十四冶项目管理培训心得

创鑫公司工程部

李自光

一．项目要进行整体管理，善始善终

整个项目开始要做好项目整体计划，在项目的整个过程中，始终要按照项目计划执行，如若遇到项目发生变更，要进行影响分析，得到批准后制定变更计划，并按变更计划执行。

变更的影响情况，如：

费用，时间进度等要通知相关的项目利益干系人，说明变更的原因和产生的影响。

项目首尾工作也是项目管理中，一项重要的工作。

需要将项目过程中产生的文件资料进行整理，归档；对项目的费用和进度进行审计和审核，对项目的质量进行检验和验收；对项目的整个过程的利弊得失进行总结和交流。

变更计划在软件项目中经常遇到。

控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。

否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。

自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。

因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。

这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。

所以项目从一开始就要做好计划，搞清目标。

只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。

二．项目范围管理理论解决了项目开始需求不清的问题

需求管理是项目范围管理中的问题，这是因为它实际上是开发过程中的所有管理原则的先决条件。

只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。

实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。

计划、追踪、配置管理以及软件质量保证这些在其他关键过程中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

什么需求？

需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。

这些需求有可能是技术方面的（比如：

功能和性能需求），也有可能是非技术方面的（比如：

发布日期，开支限度）。

区分开需求管理和软件需求分析是很重要的。

一旦分配需求被文档化，并且被所有受影响部门（客户，系统工程，软件工程）通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。

没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。

事实上，通常它们不是。

优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果被称为“软件需求“。

这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。

需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。

从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。

问题经常出在企业对透明度的惧怕。

客户觉得保持需求含糊不清，松散或者无正式文件能够给他们

更多的机会去说：

“那并不是我所要的，那并不是我认为的需求的含义”。

文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。

相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：

“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。

”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。

这样一来，尽管客户与开发人员的利益动机相对，但他们却走到了一起。

每一方都认为他们在保护自己的利益，巩固自己讨价还价的地位，但是事实上每一方都在走向将来的失望和争吵，为项目埋下了一刻定时炸弹。

三．项目时间管理理论指导我们在项目管理中怎样抓主要矛盾。

以前进行项目管理时，是根据经验和每个人的工作特点，进行项目的分工的，软件项目基本是按照需求分析，概要设计，详细设计，代码编程，调试和测试，用户验收等几个主要过程来进行的。

但将项目分工更加细化，每个小过程的时间估算是多少，整个项目可以最短用多少时间来完成，怎样合理安排人员，怎样抓项目中的关键环节等等，这些都没有进行过量化的分析和管理。

项目管理的实施最为直观的就是缩短项目时间。

利用项目管理理论、方法，有许多缩短时间的例子。

美国路易斯维化工厂检修时把检修流程精细分解，按导向图建立起控制关系。

他们惊奇地发现，检修过程选择不同路径总时间是有差别的。

通过反复压缩最长路径上的任务，将工期反复优化，最后只用７８个小时就完成了通常需１２５小时完成的检修，节省时间３８％。

这就是至今项目管理工作者还在应用的著名的时间管理技术ＣＰＭ，即“关键路径法”。

所以我们在软件的项目管理中，也要将时间控制理论运用进来，结合软件工程的实际，将任务分解的更加详细，并用网络图将整个工作过程建立起来，估算好每个阶段的历时，找出关键路径，并通过快速跟进方法，将关键路径的工期缩短，以提高工效。

四．质量管理是项目成败的关键

我们在进行软件项目过程中，对软件的功能测试一直认为还是比较认真和严格的，每次测试都要有测试计划和用例的编写，然后才能进行测试；测试要有记录，并将记录整理成测试报告。

但通过此次培训后，感觉到我们的测试工作与质量管理的要求还差的远，有距离。

质量控制要深入到每个与项目相关的人，要深入到项目的每个过程中，从一开始，就要树立质量第一的理念，每个过程都要进行质量的控制，而不是到最好测试时，才想到质量，才去衡量是否符合标准。

标准化设计，标准化管理是项目质量的保证。

参加质量体系认证有助于企业提高项目的管理水平，有利于提高工程项目质量。

cmm模型已得到广泛的认可和接受，cmmi沿用其模型的组织方式，有5个等级和18个要素。

通过5个等级的认证和加强管理，企业对项目的管理将经过5个境界的提高：

从混乱，到里程碑的检查，到定义清楚的管理体系和标准，到进行统计过程控制量化管理，到最后的优化过程、评价工作流程、进行工作过程的改进。

本人以前参加过为日本软件进行部分功能的设计和编程工作。

日本的软件企业对一个项目的质量控制就做的比较细致，用我们的观念衡量简直是不可容忍。

做一个模块的详细设计，要用他们提供的标准的图形语言进行描述，用标准的设计摸版进行说明；并在设计完成后组织相关人员对这个设计进行评价，有问题需要修改设计，然后在评价直到通过才能开时以此为设计文件，进行代码。

代码写完后，不是见到结果就完事了，要将代码打印出来，相关人员对代码的整个实现过程进行评价，提出修改建议，代码修改后，需要再审，也是通过以后才能提交入代码库，进行代码的组装。

当时认为日本的方法太浪费时间和人力了，对技术人员个人的能力估计的太低，怎么能提高工

作效率呐。

可是软件质量问题的频繁出现，是我们不断的认识到，开始浪费一些时间和人力，控制好每个细节的质量，就是省去了许多时候为解决质量问题而进行的新的时间和人力的支出。

省去了大量的软件后期的质量维护费用。

总的来看是核算的。

为提高项目的质量，降低成本，必须从项目的开始就要做好质量的控制工作。

五．沟通管理中的一些策略的使用可以使项目更好的完成

做项目就需要与客户接触，就会出现一些正式和非正式的谈判。

双方都会为自己方的利益而进行讨价还价。

与客户之间搞好沟通，是项目进展是否顺利的一个条件。

沟通中有许多的策略在平时的实际工作中可以使用，目的不是坑害别人，而是为了更好地完成项目，达到双方事先确定的目标，而采用的一些艺术手段而已。

沟通的技巧包括：

下达最终期限，使用吃惊方法，采用有限权利法，不露面的人，公平合理，战略延迟，双方一起论理，撤退，不合理，既成事实等。

本人就是成功的采用了战略延迟法，将客户方的一笔项目质保金及时地催要了回来。

体会还有很多，总之通过这次学习自己对项目的管理又有了新的认识，我会将这些理论知识运用到实际工作中去的。

以提高项目的管理水平，提高项目的质量，降低项目的成本，降低项目的风险，最终提高企业的效益。