项目环境是动态的,在过程、计划或范围等方面的变化是恒定的。您可以将这些更改分为两类:
- 更换管理层
- 配置管理
“变革管理”是第一类。在这里,您管理与项目管理计划、过程和基线相关的更改。
在第二类中,您可以管理与之相关的更改产品范围,即配置管理。
当建立基线时,就需要更改请求,并且您必须对它们进行更改。如果没有设置基线,则不需要正式的更改请求。变更请求和配置请求是集成管理系统的一部分。
更改管理是项目管理中的一个众所周知的术语,但配置管理不是。在IT字段中,术语“配置管理”经常使用,因此如果您不在该行业中,您可能会面临理解概念的问题。
作为一个非it专业人士,我有这样的挣扎。然而,现在我已经通过了PMP和PMI-RMP考试,我可以帮助您理解这篇博客文章中的概念。
请注意,更改管理和配置管理是最重要的概念PMP考试,你会看到他们的许多问题。
改变管理系统
根据PMBOK指南第6版,“更改控manbet最新版制专注于识别,记录和控制变更这个项目和项目基线。“
在更改管理系统中,您可以管理与项目范围,规划和基线相关的更改。
例如,您用完了资金,您需要额外的资金来完成项目,因此,您将提出额外资金的变更请求。或者,您可能无法在指定时间内完成项目,并需要时间扩展。
在变更管理系统中,变更请求被分析为对任何其他项目目标的任何可能的影响。之后,请求要么被批准,要么被拒绝。
为了最大限度地减少中断,变更管理系统必须确保所有参数都已确定并分析了任何可能的影响。
如果变更请求被批准,您将更新相关的基线,更新项目文档,并通知相关的涉众。
变更管理活动
在变更管理期间,您需要做以下工作:
- 确定更改。
- 准备更改的正确文档。
- 对变更请求进行审查、分析并作出决定。
- 确保请求得到实现、注册和沟通。
配置管理系统
根据PMBOK指南第6版,“配置控manbet最新版制侧重于可交付成果和流程的规格。”
在配置管理系统中,您可以管理与产品规格和流程相关的变更。
例如,假设您正在开发一个产品,客户端请求添加一些额外的功能。
由于此更改与产品的配置有关,您将使用配置管理系统来处理此更改。
配置管理记录了您将如何监视和控制变更。它是定义可配置项(产品、服务、结果和组件)并控制对这些项的更改的过程。
配置管理计划保持对产品的版本控制。在这里,您可以保存对产品的任何版本所做的所有更改的日志,以供查看。
配置管理活动
您在配置管理期间执行以下操作:
- 识别可配置项。
- 记录并为所有可配置项目准备报告。
- 根据要求对所有配置进行验证和审核。
一个真实的变革和配置管理示例
假设你正在进行一项工程,要建造一座有十个教室的校舍。
例:1
在工程进行到一半时,你的钢铁工程承包商罢工了,你不得不找一个替代者。你找到了一个替代方案,但新承包商一周内不会开始为你的项目工作。
这将推迟工程。因此,您将通过变更管理系统提出变更请求,要求将日程延长一周。
一旦这个请求被批准,您将更新您的日程基线。
这是变更管理系统的一个例子。
现在让我们看一个配置管理系统的例子。
案例:2
你正在建造一座学校大楼,客户要求你把房间的数量从10个增加到15个。
这是在客户端更改产品配置时更改产品范围的请求。
您将在配置管理系统下处理此更改,因为这里您的产品规格已经更改。早些时候,学校大楼有10个房间,现在它将有15个房间。
请注意,在第一个情况下,您提出了一个更改请求,以增加一个星期项目的截止日期。产品没有变化,只有在时间表基线中只需要更改;学校建筑是一样的,但一周后,你将把这座建筑物交给客户。
变更管理和配置管理系统的区别
变更管理和配置管理系统之间的主要区别是,变更管理处理过程、计划和基线,而配置管理处理产品规格。
变更管理系统的例子可以是额外的资金需求或进度扩展,而配置管理的例子可以是添加到产品中的额外特性。
变更管理条件
以下是变更管理的一些条件:
- 计划上的延迟:你将不得不制定一个新的计划来反映当前的情况。
- 成本超支:您需要重新估算您完成项目的成本。
配置管理条件
以下是配置管理的几个条件:
- 市场竞争迫使产品增加新功能。
- 这个项目花了很长时间,产品已经过时了,所以需要更新。
- 客户要求你添加一些额外的功能。
- 由于成本超支,产品中删除了一些功能。
- 为了尽早完成项目,删除了一些特性。
变更管理Vs配置管理
更改管理和配置管理不会竞争相同的空间。它们用于不同的目的。
根据PMBOK指南第6版,“配置控manbet最新版制集中于可交付成果和过程的规范,而变更控制集中于识别、记录和批准或拒绝对项目文档、可交付成果或基线的变更。”
产品配置中的任何更改也将影响项目范围,您将更新项目计划、成本和进度基线。
配置管理的范围比变更管理更大。
谁可以提高更改和配置请求,谁可以授权它?
任何人都可以提高更改请求,但必须由项目经理或更高权限批准,如配置或更改管理计划中所述。如果客户未涉及该过程,则需要其同意以实施更改请求。
更高的权威可以是项目管理计划中提到的更改控制板(CCB),项目管理办公室(PMO),或任何其他利益攸关方。
关于配置请求,通常,它来自客户端,因为它涉及产品的变化。
该请求由项目经理审核,然后转发给有关的更高权限,以获取审核和批准。可能需要来自客户的协议,因为它们必须支付任何其他功能。
总结
变更管理和配置管理是集成管理的一部分,它们都处理项目或产品中可能发生的所有变更。变更管理涉及到与计划、过程和基线相关的变更,而配置管理则涉及到与产品范围相关的变更。项目经理的工作是提出这些要求,并确保它们得到适当的审查。一旦做出决定,就应该立即执行。
现在我希望你在解决PMP考试中关于变更管理和配置管理系统的问题时不会有任何问题。
如何管理项目中的变更?请在评论区分享你的经验。
你好法赫德,
谢谢你的深思熟虑的文章。
我喜欢你的定义,似乎是正确的;并肯定是解释PMBOK的一种方式。但是,部分问题的一部分(以及为什么你已经写了像我这样的文章和谁以及追求读者的人员,那就是PMBok非常让它成为一个模糊的交易。你的定义是好的,是完美的感觉 - 这就是我的支持:配置与产品有关;变更与项目文档,基线,流程等有关。但是存在矛盾。
And, as I’ve tried to make sense of it in my own head in studying PMBOK (as you know PMI has “THEIR definition” of things, not always the same as “Organization/Company lambda’s”), there are some contradictions in PMBOK, and thus in your own definitions above—which are indeed direct out of PMBOK. You say that “Change Control” is about “Project stuff” — Project Documents, Baselines and Processes ; and “Configuration Control” as Product/Scope related (“Product Stuff”). Yet, you then correctly quote PMBOK that ““Configuration Control focuses on the specifications of both the deliverables and the processes” (i.e., note PROCESSES).
进一步说,当你引用PMBOK时,你再次指出了矛盾:“配置控制集中于可交付成果和过程的规范(例如,注意过程!),而变更控制集中于识别、记录和批准或拒绝对项目文档、可交付成果或基线的变更”(注意可交付成果!)因此不符合您所陈述的解释/定义。
另一种解释(我遇到过)是,变更控制是变更项目“工件”(项目文档、计划、过程、可交付成果、基线——简而言之,在控制之下的一切)的过程:书面变更请求、变更控制委员会、投票、批准/拒绝,等等。配置控制是所有“项目工件”的版本控制、“当前版本”的识别、旧版本的归档等(工件包括“项目材料”,如文档和过程,以及“产品材料”,如可交付成果)。这是Rita Mulcahey(她的总理书)所支持的。这种解释还与PMBOK中发现的变更控制(和变更管理)和配置控制(和配置管理)的一些相同定义(和其他定义)存在问题和矛盾。
所有这一切都可以说:PMBOK是由大量的人写的,然后在各种作者和章节上“控制”,以确保整体完整性。但仍然存在毫无丝状和矛盾 - 我相信这是一个。他们似乎与新版本的pmbok清除了这些,但其他人出现。这一切都说,你的定义是一个很好的一个 - 而且我一直认为是真的。现在我开始奇怪。已经阅读并现在为PMBOK进行了研究 - 因此试图了解“PMBOK如何定义这一点” - 因为正如前面的PMBOK定义一样,并不总是同一个的“真实世界”的定义。没关系,它不清楚他们不明确,他们的方法有矛盾。谢谢。伟大的文章。如果您可以或能够与他们的对话 - 告诉PMI澄清他们的脱发! Look forward to your feedback.
变更管理是第一类。在这里,您可以管理与项目管理计划,{进程}和基线相关的更改。
根据PMBOK指南第6版,“配置控manbet最新版制集中于可交付成果和{过程}的规范。”
我不明白如何处理{Process}
请澄清一下。
你好安娜,
变更管理是配置管理的一个子集。
嗨Fahad先生,
现在,如果客户端请求在我的范围内发生变化,
我需要并行使用更改管理和配置管理
你好安娜,
我相信他正在要求改变产品范围。在这种情况下,您将进行配置管理。
嗨法赫德,
改变产品范围,难道不需要改变进度和成本基线吗?随着产品范围的增加,成本和时间也相应增加。然后,我们必须同时进行配置管理和变更管理,不是吗?
变更管理是配置管理的一部分。
配置管理是否导致在项目管理中提出变更请求?
下面是两个用在这里的相同的例子,以帮助你理解,我试图传达的信息。
示例1
在项目中间,我的钢铁工作承包商走下了工作,我必须找到替代品。我发现了另一种选择,但新的承包商不会开始在项目上工作一周。
这将推迟工程。因此,我将通过变更管理系统提出变更请求,延长一周的时间。
示例2
现在,我正在建造一座学校建筑,客户要求我必须把房间的数量从10个增加到15个。
这是在客户端更改产品配置时更改产品范围的请求。
我将在配置管理系统下处理此更改,因为这里的产品规格已经更改。早些时候,学校大楼有10个房间,现在它将有15个房间。
但是,与之前计划的10个房间相比,增加5个房间需要更多的时间。因此,我的日程也将改变,从而影响我的基线,因此我必须提出更改请求。
请让我知道我的理解是否正确!
在这两种情况下,您都将提出更改请求。
很好解释。谢谢你!
不客气,哈什拉。
这是一个伟大的兄弟。非常感谢你让我在这个背景下更好地理解了这些概念。
欢迎你,穆罕默德。
部分错误的解释…
你好,Tunc,哪里出问题了?
太棒了!
谢谢你Babak。
伟大的解释,你显然指出了我在这部分的困惑。非常感谢。
别客气,肯尼。
非常有用的
感谢Shriram的评论。
谢谢。
变更管理处理项目范围,而配置管理处理产品范围。
正确的。
400个问题是模拟的?
你好Mahfuz,
在PMP题库中你会找到400个问题。PMP模拟考试有200道题。
ASC Fahad,万分感谢兄弟,感谢你伟大而聪明的头脑为我们提供了如此丰富的知识,
Wasalaam Ishmael,
谢谢你的评论。
伟大的写作。配置管理对我来说是新的,你的帖子很有用。谢谢。
安瓦尔
Janbi.me
欢迎你,安瓦尔。
这篇文章很好。它帮助我弄清楚了配置管理和变更请求。
所以,我想确认一下我们的项目。
我的项目是建造蓝色的窗户。但在执行时,窗户被漆成了蓝色。之后,涉众将颜色改为黄色。
因此,这应该由变更管理或配置管理来管理。
因为它会影响时间表,成本和产品规范。
请解释一下。
太感谢了。
这是规范中的变更,所以配置管理。
你好法赫德,
请阅读PMBOK®指南第六版中的这部分内容,然后更正你的答案,并努力理解它。你所说的配置管理和变更管理根本不是真的。
“配置管理计划:
描述如何记录和更新有关项目项目(以及哪些项目)的信息,以便项目的产品、服务或结果保持一致和/或可操作性。
“一旦提供的第一个版本完成,应申请更改控制。通过配置管理工具和程序支持可交付(例如,文档,软件和构建块)的多个版本或版本的控制。“
“在建立基线之前,不需要通过执行的集成变更控制过程正式控制变更。一旦项目被基线,更改请求就会通过此过程。作为一般规则,每个项目的配置管理计划应定义需要在配置控制下放置哪些项目工件。应正式控制配置元素中的任何更改,都需要更改请求。“
“配置管理活动,例如:如何启动变更;如何分析影响;他们将如何被追踪、追踪和报告;以及批准这些更改所需的授权级别;”
谢谢你!
你好Shady,虽然更多的技术细节可以添加到这篇博客文章中,但这里讨论的要点是有效的。
意思是20.0
应用7规则,输出数据失控,需要调查。
Hi Fahad,我上面也有同样的问题,为什么变更管理是配置管理的子集,而不是另一种方式。这背后有什么原因吗?
还有一个让我困惑的问题,
项目经理正在对20厘米的钢螺栓进行质量检查。可接受的控制极限是19.955厘米和20.045厘米。最后的测量结果如下:20.033厘米、19.982厘米、19995厘米、20.006厘米、19.970厘米、19.968厘米、19.963厘米、19.958厘米、19.962厘米、19.979厘米和19.959厘米。应该做些什么?
我总是认为如果控制限制是良好的,为什么我们需要更需要调查这个过程?它不是控制限制通常相似的容差(以前由PM及以后由客户定义)。
谢谢
苏米特
与变更管理相比,配置管理具有更大的范围。
Project Manager设置了控制限制以控制过程,如果有任何东西,他会检查一切是否正确,虽然项目是可接受的范围。
在我看来,配置的变化也可能影响成本、进度基线&或者可能引发一些风险。在这种情况下,需要根据影响开展变更管理。因此,变更管理可以是配置的一个子集。
请分享你对我的观点的看法。
变更管理是配置管理的一个子集。
您能解释为什么改变管理系统是配置管理系统的子集吗?
但是变更管理系统是如何归入配置管理系统的呢?
这是根据PMI定义的。
亲爱的法赫德,
您能否向PMI提供对此的参考..?
如果您可以访问PMBOK指南第5版,则可以参考第53manbet最新版2页。
感谢Fahad的解释,但一个问题,根据您的解释,配置主要用于产品和变更主要专注于基线和项目计划,所以我看到在许多点,他们会在一起见面,就像你的场景2需要将10到20的课堂数量更改为yes是的,但要满足该产品,您还需要更改计划,所以在那种情况下,我们将通过配置和更改,纠正我我错了
再次感谢
简而言之,变更管理是配置管理的子集。
哇,这是非常有趣和声音
谢谢你。
欢迎你,朗吉尔。
项目管理计划及其所有附属计划和基线的任何变更都需要通过变更控制过程进行更新,并得到批准。那么,在进行更新之前,是否所有的项目文件都需要经过变更控制过程?例如权益持有人登记册或风险登记册或要求文件。是否可以在不经过正式变更控制过程和批准的情况下进行更新?PM是否可以在没有其他人批准的情况下进行更改?
这些是项目文档,应该在整个项目生命周期中不断更新。他们不需要经历这个过程。
那么所有项目文件都对待同样的方式吗?PMBOK指南中有一份文档列表Page 78.除了像性数据和问题/更改日manbet最新版志/预测等明显的文件之外,还可以更新所有其他其他情况,而无需正式更改控制批准?
根据我的理解 - 是的。
非常感谢Fahad的这篇文章,它简单明了地区分了配置和变更管理系统。
欢迎您的Kemisola。
亲爱的
非常感谢你的精彩解释。
真的,我特别喜欢它,我正在开始PMP课程准备PMP考试。
谢谢和regalrds。
Abdulmohsen
感谢Abdulmohsen的访问并留下评论。
谢谢,现在很清楚了
不客气,阿莱克里。
我不同意这种澄清,PMBOK并没有很清楚地区分这两者,我的印象是配置管理是变更管理的超级集合,加上一些文档记录存储库功能。
好吧。
我们是否可以说spécifications(配置)中的更改可以类似于产品质量属性的更改?两者之间的区别是什么?我需要澄清一下
提前感谢!
你说的产品质量属性是什么意思?
我认为配置管理基本上就是你如何管理你的产品/工件的“完整性”,所有的涉众如何知道最新的蓝图是什么,最新的架构图是什么,最新的设计文档是什么,最新的源代码是什么,等等。
变更管理就是任何变更,甚至是那些没有导致范围、成本、进度变更的变更。
请再读一遍这篇博文。
好解释。法赫德,谢谢你和其他做出贡献的人。
不客气,贾利尔。
非常感谢。还有那些在评论中贡献的人。
你的解释使我明白了。
谢谢大家。
欢迎你,梅瑟达。
你好,
变更管理=项目变更。
配置管理=产品变更。
ri8?
正确的。
配置管理系统是在特定的技术细节中定义最终产品外观的系统。
变更控制系统:为了进行变更而需要应用的一组程序和过程
法赫德伟大的工作。这对我很有帮助
谢谢约瑟夫。
我在linkedin上找到了一篇类似的文章,它是逐字匹配的。你可以看一下:
https://www.linkedin.com/pulse/configuration-management-system-vs-change-bsc-pmp-pmi-rmp-tot-
那家伙抄袭了我的内容,然后贴在那里。我已经向LinkedIn提交了一份版权侵权通知。
谢谢Amit让我知道。
亲爱的Fahad,谢谢你的解释,但是我对配置管理系统还是有些困惑。
让我们以你为例(教室的数量从10个增加到15个),那很好。
你说任何chang项目流程或基线被认为是一个变更管理系统,所以在前面的实例,当我们决定从10增加到15,我认为这种变化直接影响了项目的范围,这是又一个项目的基线。
因此,在我看来,这将是在变革管理系统下。
等待更多信息,提前感谢。
变更管理是配置管理的一个子集。
变更管理工厂定义了管理项目变更的过程。
PMBOmanbet最新版K指南第五版,页数:138
这篇文章非常有用。因此,更改管理计划是配置管理计划的子集。但是如果要求问题 - 更改管理计划包含什么?正确的答案将是项目管理计划或配置管理计划。为什么?
先谢谢你
很好地解释了最令人困惑的差异之一。
感谢AG过来并留下你的评论。
你的网站是优秀的!解释/说明是很棒的! !下载了你的指南,希望它们有用!
感谢您的评论吱吱作响。
谁将发起或批准变更请求。何时我们将提出变更请求,以及何时我们可以在没有变更请求的情况下更新项目。
为了理解整个过程,我建议您阅读PMBOK指南中的集成管理知识领域。manbet最新版
巴西,
更改控制转到CCB更改控制板以批准或拒绝请求。在一些项目中,赞助商向项目经理提供了一些权限,以批准一些更改请求,这取决于合同和角色和职责。
变更管理是配置管理的一个子集。
篇不错的法赫德!
在你博客里的一个例子里。客人要求将房间数量从10个增加到15个。配置的改变是明显的…同意!但是变更请求并没有出现在图片中,因为增加更多的房间会导致项目基线的变更,例如成本,进度。例如,考虑到10个房间的工作包……这里有点混乱。请建议。
非常感谢这样简单易懂的解释。
欢迎你,阿努莎。
欢迎你,拉姆。
嗨法赫德,
这是对变更Vs配置管理的一个极好的解释。感谢如此精彩的对比和生动的澄清。
总结上述内容,
1.更改管理是配置管理的子集
2.更改管理适用于流程/基线变更。
3.配置管理适用于产品变更和更新的文档存储库。
4.两者都经历了集成的变更控制过程。
问候,
Ram Narayan.
谢谢Fahad,上周我以4P和1MP的成绩通过了PMP考试。
感谢您的所有支持,您的博客向我提供给我和所有PMP志愿者。
恭喜你通过PMP考试,我很高兴我对你有所帮助。
亲爱的法赫德:
您的解释对于PMP志愿者来说是令人敬畏的,参考本讨论,您可以澄清哪些PMI流程变更管理计划和/(如果PMBOK-5)开发了配置管理计划????
谢谢,祝福......
制定项目管理计划。
项目管理manbet最新版知识体系指南第77页
谢谢你!
不客气,阿瑞提特。
这解释真棒!继续努力,先生。
谢谢你!
谢谢Janak。
PMI是否回答了你的问题?
谢谢
不,我没有收到PMI的回复。
我就是喜欢你让事情变得简单的方式。
神奇的工作。
谢谢你,请
感谢Sarika的评论。
感谢你的博客信息。这对我帮助很大。谢谢。
感谢您的评论的Abhijeet。
对这个主题的清晰解释。非常感谢!!!!
欢迎您是迈克尔。
配置管理和变更管理与配置控制和变更控制不同吗?
在PMBOX指南第五版中说:配置控制集中于可交付成果和过程的规范,而您在配置管理系统中提到,与产品规范相关的变更被管理。
谢谢你!
请参阅532页,PMBOK指南第5版。manbet最新版
亲爱的法赫德,
你的工作令人印象深刻。但你能澄清萨阿德的疑虑吗?我也分享它。
配置管理是记录产品(可交付产品)范围/配置的变更
记录过程/成本基线/进度基线的变更是变更管理。
这种理解正确吗?如果是,项目管理知识体系第5版第96页说“配置控制集中于可交付成果和过程的规范”。为什么配置控制集中在过程的规格说明上?这是变更控制的描述,对吧?
我觉得这两个地方提到的配置管理的定义之间存在一些差异。
不管怎样,我要给PMI写封邮件,让我们看看他们的回复。
是的,我们应该。请更新我们。
根据我的理解,配置管理同时影响产品和过程,而变更管理只影响过程。
当管理到产品规范的更改时(配置),它“可能”并入调度和/或成本。两者都必须通过相同的集成变更控制,仅对产品规范或项目过程或两者之间影响。虽然PMBOK中没有特别提及,但是,虽然更改管理可以单独起作用,但是配置管理必须沿着更改管理,可以作为子集或作为随附的文档。
如果我有缺失/偏离,请纠正我。
我已经给PMI写了信。我希望他们能在本周内回复。
Tauseef,我同意你的评估:“变更管理可能单独行动,[但是]配置管理必须同时采取变更管理”。
同样基于PMBOK 5.6.1.1 -控制范围如何描述配置管理计划,似乎计划本身明确定义了什么是可配置的(因此,在什么情况下配置控制是适用的)。
我只发生在这个博客中,因为我的PMP认证考试预备学习问题之一断言,配置管理“不取代改变管理系统,而是与其有效。
你好,
请你告诉我什么之间的不同:
变更管理计划和变更管理体系
配置管理计划和配置管理系统
非常感谢
穆
基本上你是在问计划和系统之间的区别。
计划是一种记录下来的东西,它指导你的行动。系统是帮助你实现计划的东西。
希望能帮助到你。
我们可以说:配置管理将包括变更管理,但变更管理将不包括配置管理。
换句话说:如果我们回到建筑学校示例:
1-当客户从10个班变更到15个班时:我们应该做配置管理和变更管理。
2-当项目进度将推迟一周时:我们应该改变管理。
配置管理和变更管理是不同的。从我所理解的,在配置MGMT中,我们根据更改MGMT批准的更改顺序或变更顺序自定义。
您可以说变更管理是配置管理的一个子集。
感谢您的炉排样品
感谢瓦拉的评论!
嗨法赫德,
配置和变更管理都必须通过集成的变更控制过程来完成吗?这是否会直接影响项目管理计划?
是的,它们必须通过集成的变更控制过程来完成。它可能会也可能不会影响项目管理计划。
Thnks Fahad。
嗨法赫德
我读了你关于变更管理和配置管理的文章。我对这学期还是有些担心。
配置管理和变更管理系统
改变管理计划和变更控制系统
谁能给我更多的解释和区别这四个术语的例子,这将会很好
提前感谢你对我理解的贡献
最好的方面
我们来到PMP Sathish的世界,祝你职业生涯好运,兄弟
嗨法赫德,
我通过了考试。感谢你的博客信息。这对我帮助很大。谢谢。
祝贺Sathish !
用你的例子澄清了我的疑惑。
问候
Pullikol
欢迎你Pullikol……
非常感谢你的菲哈德
嗨Shariff,
与良好的例子进行了良好的解释。谢谢。您还可以在变更管理系统和配置管理系统之间解释不同。
嗨Thathish,
根据我的理解,配置管理系统和变更管理系统都是组织项目管理信息系统的组成部分。然而,配置管理系统由文件化的程序组成,这些程序用于识别、记录和控制对产品、服务和结果的功能和物理特性的变更,包括跟踪系统和批准级别。另一方面,变更管理系统定义了如何控制、变更和批准项目可交付成果和文档。后者通常是前者的子集。参见PMmanbet最新版BOK指南第428-429页。
我希望这个解释能有所帮助。
嗨Shariff,
配置管理系统来自pmis,但我想我可能错了,变更控制来自opa。另一个问题是变更管理和变更控制一样。谢谢。
法赫德。
您对更改与配置管理之间差异有效的解释是有效的。我想补充一下,配置管理还包括管理对文档的更改(启用项目团队知道哪个版本是当前的)以及在此努力中使用的组织工具。
问候,
Shariff
惊人的。非常感谢您的惊人解释
不客气。
亲爱的法赫德,
继续用你的方式解释事情!!
谢谢你的评论ritesh。
优秀的澄清……现在很难忘记……谢谢……
不客气
但在一些问题中,你会去哪里找到一个文档,答案是配置管理。似乎它也被认为是一个文档管理存储库工具,对吗?
在那里它谈到了最新版本的文档...因为有批准的更改请求时,我们对基线进行了更改。
你好施薇塔,
桑吉莎给你答案了吗?如果没有,那你能说得更具体一点吗?
嗨法赫德,
我们可以说配置管理是范围变更,变更管理是进度变更吗?
谢谢
ramesh.
配置管理就是范围变更—是的,我们可以这么说。
而变更管理包括计划和成本基线的变化。
我不这么认为,因为改变范围会增加一个新的范围和新的相关spécification。但是配置需要将spécifications更改为现有的范围。因此,我认为变更范围与变更管理系统有关,与配置管理系统无关
是的,你是对的,如果产品范围发生了变化,那么我们可以说它将通过配置变更管理系统进行管理。
正如Nedhir所说,如果有范围变化,它应该被视为变更管理。像学校的例子一样,如果教室的颜色从绿色变为黄色,那么这应该配置更改
嗨法赫德,
感谢传播知识。为什么配置管理系统属于EEF,变更控制属于OPA,两者是相关的。谢谢。
嗨Fahad,
我找到了这段视频来解释两者之间的区别:
变更管理vs.配置管理- PMP考试准备
https://www.youtube.com/watch?v=VErsnGIqzEQ
感谢您分享迈克尔。
好
谢谢aretit。