金币
UID171161
帖子
主题
积分3388
注册时间2014-4-17
最后登录1970-1-1
听众
性别保密
|
楼主 |
发表于 2021-11-30 11:31:08
|
显示全部楼层
8.2 Key Phases in the Laboratory Informatics System Life Cycle:
8.2实验室信息系统生命周期的关键阶段：
8.2.1 Phase I: Project Initiation--The purpose of this section is to outline the activities that occur during the project initiation phase of the system life cycle. The section contains three parts, including project initiation and planning, developing a business case, and developing a quality plan. It will also emphasize the importance of change control mechanisms. Using this section will provide the reader with guidelines to follow as they initiate a new informatics prbject.
8.2.1阶段I：项目启动-本节的目的是概述在系统生命周期的项目启动阶段期间发生的活动。本节包含三个部分，包括项目启动和计划、开发业务案例和制定质量计划。它还将强调变更控制机制的重要性。使用本节将为读者提供在他们开始新的信息学主题时遵循的指南。
8.2.1.1 The project initiation phase is the process in which the idea of implementing a LI project or program either becomes a live project, a program, or is rejected, A key concept for any project or program is that it should start, achieve something, and stop. Project initiation lays the ground work for these three outcomes. For example, a business case should provide evidence of the value of the project as well as projected costs, a project brief may provide outline requirements that provide an overview of functional and nonfunctional requirements, a quality plan will outline the quality approach required for the project, and a communication plan can outline how project progress is to be communicated to all key stakeholders. The final output, or deliverable, of the project initiation phase will be a decision based on the information gathered during the phase as to whether the project or program will proceed or not. Accepted project management techniques explain the project initiation phase in detail and the possible deliverables of the phase. What is included in project initiation and how long it takes will depend on the nature and scope of the project. Project management techniques are scalable to allow different size projects to be managed effectively. As the project initiation phase provides and supports the rationale for the project, it should be included in some form or another for all LI projects, from a full implementation to the creation of a new report. Obviously, the size and scope of project initiation will vary enormously in these examples, but the outcomes are the same; at the minimum, an understanding of the reasons for the project (business case), and agreement as to whether to continue with the project. A decision to go ahead can only be made if funding is available for, at least, the next phase. Next are described three key deliverables of the project initiation phase: the project brief, business case, and quality plan, while also emphasizing the importance of change control mechanisms.
8.2.1.1项目启动阶段是实施LI项目或程序的想法成为一个实时项目、一个程序或被拒绝的过程。任何项目或程序的一个关键概念是它应该开始、实现一些事情然后停止。项目启动为这三个结果奠定了基础。例如，业务案例应提供项目价值以及预计成本的证据，项目简报可提供概述要求，提供功能和非功能要求的概述，质量计划将概述项目所需的质量方法，沟通计划可以概述如何将项目进展传达给所有关键利益相关者。项目启动阶段的最终输出或可交付成果将根据该阶段收集的关于项目或程序是否继续进行的信息作出决定。接受的项目管理技术详细解释了项目启动阶段和该阶段可能的可交付成果。项目启动包括哪些内容以及需要多长时间将取决于项目的性质和范围。项目管理技术是可扩展的，以允许有效管理不同大小的项目。由于项目启动阶段提供并支持项目的基本原理，因此应将其以某种形式或另一种形式纳入所有LI项目中，从完全实施到创建新报告。显然，在这些例子中，项目启动的规模和范围将有很大的不同，但结果是相同的；至少，了解项目的原因（业务案例），并就是否继续项目达成一致。只有至少为下一阶段提供资金，才能决定继续进行。接下来描述了项目启动阶段的三个关键可交付成果：项目简报、业务案例和质量计划，同时还强调了变更控制机制的重要性。
8.2.1.2 A project brief is designed to give an overview of the project, to place it in the context of the organization as a whole, and to position it with other projects or programs that may be running. The project brief describes the issue or issues the project is designed to address; this could be a problem that needs to be solved, an opportunity that can be exploited, or a requirement that needs to be addressed. These may be very
specific, for example, the introduction of a new regulatory requirement that needs to be incorporated into an existing LI solution or more general or larger is scope, such as the replacement of an existing paper-based management system. The project brief should document the project objectives and the currently identified project deliverables, which may include the outline requirements. These requirements may be very high level at this time, such as the implementation of a biobank sample tracking system to replace the existing paper-based system. Items that are specifically excluded should be documented as well. This applies especially when it could be assumed that the item would be included. For example, if a specific department or group will not be part of an LI implementation, it can be stated here. In the case of a biobank system, automated freezer management hardware and software might be explicitly excluded from the project. The project brief may define known constraints. These can include, among others, time constraints (for example, the deadline for implementing new regulatory requirements), financial constraints, or technical constraints (for example, the corporate standard requires a cloud-based virtual system or the corporate standard specifically prohibits a cloud-based virtual system). The project brief may also identify projects, products, and program interdependencies. For example, the implementation of the biobanking software may be dependent on the purchase and
commissioning of new freezers, or the implementation of a laboratory information management system (LIMS) may be dependent on the building of a new facility. Project briefs may also contain any known risks to the project, and an outlined project plan, if required, by the organization's project management methodology.
8.2.1.2项目简报旨在概述项目，将其置于整个组织的背景下，并将其与可能正在运行的其他项目或程序放在一起。项目简报描述了项目旨在解决的问题；这可能是需要解决的问题、可以利用的机会或需要解决的要求。这些可能是非常具体的，例如，引入新的监管要求需要纳入现有的LI解决方案或更普遍或更大的范围，例如替代现有的纸质管理系统。项目简报应记录项目目标和当前确定的项目可交付成果，可能包括大纲要求。这些要求此时可能是非常高的水平，比如实施生物样本库样本跟踪系统来替代现有的纸质系统。还应记录明确排除的项目。这尤其适用于可以假定该项目将被纳入的情况。例如，如果特定的部门或小组不是LI实施的一部分，则可以在此声明。在生物样本库系统的情况下，自动冰柜管理硬件和软件可能被明确排除在项目之外。项目简报可以定义已知约束。其中可能包括时间限制（例如，实施新监管要求的最后期限）、财务限制或技术限制（例如，公司标准要求基于云的虚拟系统或公司标准明确禁止基于云的虚拟系统）。项目简报还可以确定项目、产品和项目相互依赖关系。例如，生物样本库软件的实施可能取决于新冰箱的购买和调试，或者实验室信息管理系统(LIMS)的实施可能取决于新设施的建设。项目简报还可以包含项目的任何已知风险，以及组织的项目管理方法所概述的项目计划（如需要）。
8.2.1.3 A business case is used to justify the proposed project by defining the business benefits and costs. The business case developed during the project initiation phase may be a high-level document, especially as far as costs are concerned. For example, the requirements may not be fully defined at project initiation, a product or platform to base the project on may not have been selected, an approach to implementing the system may not have been decided on, and negotiations will not have started with the chosen supplier (internal or external). However, at project initiation the business benefits should be well understood, as these form the basis of why the project should be considered at all. The business benefits may have been outlined in the project brief, but the business case provides an opportunity to expand on them. The business case is a document that is subject to review during the course of the project to ensure that the rationale for it is still valid. As an extreme example, if the aim of the project is to install a LI solution at a site or in a specific laboratory, the business case becomes invalid if the organization closes or sells that site or laboratory and the project should stop. The benefits defined in the business case should, wherever possible. be measurable as they provide the best way of proving the success of a project once it has been completed. Developing a business case may be easier for some projects than for others. For example, regulatory reporting or compliance requirements may be easier to justify than the anticipated benefits of automation or quality improvements. Good cost-benefit analysis requires time, solid understanding of the laboratory environment, and careful analysis of the expected benefits. The cost-benefit components of inaction--not implementing the system--shall also be addressed. This is sometimes called the do-nothing option. An analysis of costs should consider the total cost of ownership (TCO), including the initial purchase costs, implementation (including antipated customization) costs, and ongoing maintenance costs. Benefits are normally characterized as tangible (hard benefits that are easily calculated) or intangible (soft benefits that are recognized but more difficult to quantify). As stated above, these may not be fully known at project initiation, and therefore, the business case
should be regularly reviewed and updated as required during the project. If possible, a financial value should be associated with each benefit. If a financial value cannot be associated with a benefit, some other way of measuring or proving its value should be identified. For example, for an internal service laboratory that does not generate revenue, increased sample throughput is only a valid business benefit if there is, or will be,
a demand for more samples to be processed. It is the case that "soft" benefits will often be challenged when used to justify a project. Protecting brand reputation is often cited as a benefit; if using this as a justification, it shall be backed up with how the system will help protect the brand and, if possible, the cost associated with failures. In the food industry, a LIMS may protect the brand reputation by preventing the shipment of products that later need to be recalled. Such recalls affect the brand reputation, but there is also a direct cost associated with the recall that can be measured and used in the justification. Table 3 provides a list of the types of benefits a LI project could provide, in this case specifically a LIMS; note that the list does not attempt to define the measurable value associated with each benefit. Any assumptions associated with each benefit calculation should be documented so that its validity can be confirmed each time the business case is reviewed. Avoid creating unrealistic expectations as disillusionment over the expected benefits by management or end users often leads to project failure. When creating a business case, it is not uncommon to overestimate the potential benefits. Sources of error may include underestimating the cost of implementing the system,
especially the cost of staff involvement and the cost of reworking ill-defined requirements; overestimating the potential productivity gains; overestimating the demand for the improved laboratory services; failing to account for the initial impact of the introduction of the new system on productivity because of lack of familiarity with the system (this should be short term); and assigning unrealistic values to "soft" benefits. The business case is a living document that should be reviewed and updated as required throughout the lifetime of the project. As the project progresses, items such as cost estimates will become more accurate and actual cost incurred can be in cluded. Assumptions used in the business case can be monitored and updated as required and the validity of the project confirmed. However, it is possible that reviewing the business case may show that the project is no longer viable or necessary, in which case it should be stopped. A project that is halted for the right reasons is not a failure but rather should be looked at as a success for good project management.
8.2.1.3通过定义业务效益和成本，使用业务案例证明拟定项目的合理性。在项目启动阶段开发的业务案例可能是高级文件，特别是在成本方面。例如，在项目启动时可能没有完全定义需求，可能没有选择项目所依据的产品或平台，可能没有决定实施系统的方法，并且不会与所选供应商（内部或外部）开始谈判。但是，在项目启动时，应充分了解业务效益，因为这些构成了应考虑项目的基础。业务效益可能已在项目简报中概述，但业务案例提供了扩展它们的机会。业务案例是在项目过程中需要审查的文件，以确保其理由仍然有效。作为一个极端的例子，如果项目的目的是在某个站点或特定的实验室安装LI解决方案，那么如果该组织关闭或销售该站点或实验室，并且该项目应该停止，则业务案例将变得无效。业务案例中定义的利益应尽可能地，是可衡量的，因为它们提供了证明项目完成后成功的最佳方式。对于一些项目来说，开发业务案例可能比其他项目更容易。例如，监管报告或合规性要求可能比自动化或质量改进的预期益处更容易证明其合理性。良好的成本效益分析需要时间、对实验室环境的扎实了解和对预期效益的仔细分析。还应解决不采取行动的成本效益组成部分——不实施该系统。这有时被称为“无所作为”选项。成本分析应考虑所有权总成本(TCO)，包括初始购买成本、实施（包括反对的定制）成本和持续维护成本。获益通常被描述为有形（易于计算的硬获益）或无形（公认但更难量化的软获益）。如上所述，这些信息在项目启动时可能并不完全为人所知，因此，应在项目期间根据需要定期审查和更新业务案例。如果可能，财务价值应与每个利益相关联。如果财务价值不能与利益相关联，则应确定衡量或证明其价值的其他方式。例如，对于一个不产生收入的内部服务实验室，如果有或将有更多待处理样本的需求，增加样本通量只是一个有效的业务效益。在这种情况下，当用于证明项目的合理性时，“软”益处往往会受到挑战。保护品牌声誉通常被认为是一种益处；如果将其用作理由，则应支持该系统将如何帮助保护品牌，以及如果可能，与故障相关的成本。在食品工业中，LIMS可能通过防止运出后来需要召回的产品来保护品牌声誉。此类召回影响品牌声誉，但也存在与召回相关的直接费用，可以在理由中衡量和使用。表3提供了LI项目可以提供的获益类型列表，在这种情况下尤其是LIMS；请注意，该列表未尝试定义与每种获益相关的可测量值。应记录与每项获益计算相关的任何假设，以便在每次审查业务案例时确认其有效性。避免产生不切实际的期望，因为对管理层或最终用户的预期益处的幻灭往往会导致项目失败。在创建商业案例时，高估潜在益处并不少见。误差来源可能包括低估实施该系统的成本，尤其是工作人员参与的成本和重新加工不明确要求的成本；高估潜在的生产力收益；高估对改进的实验室服务的需求；由于不熟悉该系统（这应该是短期的），未能说明引入新系统对生产力的初步影响；并将不切实际的价值观分配给“软”利益。商业案例是一个动态文件，应在项目的整个生命周期内根据需要进行审查和更新。随着项目的进展，成本估算等项目将变得更加准确，实际产生的成本可以包括在内。可以根据需要监测和更新业务案例中使用的假设，并确认项目的有效性。但是，审查商业案例可能会显示项目不再可行或必要，在这种情况下，应停止项目。由于正确的原因而停止的项目不是失败，而是应该被视为良好项目管理的成功。
8.2.1.4 A sound, well-considered, quality plan helps ensure a smooth, successful implementation and, if required, validation of a laboratory informatics system. Quality expectations for the LI project shall be identified. These will vary from organization to organization based on factors such as the level of regulation to which the organization is subject. Key stakeholders in quality planning will be the organization's quality or regulatory functions, or both. These functions shall be involved in identifying the quality requirements of the project. They may also need to be involved in monitoring adherence to the quality plan and final sign-off of the system. If they are not involved, they may prevent the system going live if it does not meet the defined quality standards. A quality plan should include a quality policy and objectives, identified expectations, and any assumptions made. A quality plan needs to assess the risk to the project, users, and ultimate customers impacted by the system. These risks will help guide the level of effort [backcolor=var(--im_chat_message_bg_color,#c9e7ff)]required for validation and support during implementation and throughout the system life cycle. There are several well-documented reference materials associated with risk assessment. (See, for example, ICH Quality Guideline Q9). Users should evaluate projects against their business objectives and the risk associated with the informatics project. Risk parameters include, but are not limited to, overall project risk, product risk based upon the impact that the new system will have on the product quality, people risk in the area of change management, and business risk. Business risk may include risk introduced by software customization. The quality plan should also identify any internal or external quality standards that need to be met, as well as any identified procedures to be followed. These procedures may define how the system will be implemented, validated, and maintained in a validated state
during routine use and retirement of the system (system life cycle). In addition, the quality plan may define the required documents for a project such as a user requirements document, functional specifications document, system design document, test scripts, and validation plan. Remember that the implementation of the quality requirements will have an impact on both the time required to implement the project and the cost. Therefore, the level of quality apphèd to the project shall be appropriate to the size, potential risks, and regulatory requirements associated with the project. If working with a supplier, either internal or external, they should have their own quality system in place. It is important, therefore, to ensure there is no conflict between the organization's quality plans and the supplier's. The best option is to agree to a single unified quality approach. For organizations or individuals not used to working in a quality environment, it may be appropriate to adopt the supplier's quality approach. In all cases, however, the supplier shall know, understand, and be given access to the relevant quality information.
8.2.1.4健全、经过充分考虑的质量计划有助于确保实验室信息学系统的顺利、成功实施和验证（如需要）。应确定LI项目的质量预期。这些将因组织而异，取决于组织所受的监管水平等因素。质量规划的主要利益相关者将是组织的质量或监管职能，或两者兼而有之。这些职能应参与确定项目的质量要求。他们可能还需要参与监测质量计划的遵守情况和系统的最终签署。如果不涉及，如果系统不符合规定的质量标准，则可能会阻止系统继续运行。质量计划应包括质量方针和目标、确定的期望和做出的任何假设。质量计划需要评估项目、用户和受系统影响的最终客户的风险。这些风险将有助于指导实施期间和整个系统生命周期内确认和支持所需的努力水平。有几种与风险评估相关的记录良好的参考物质。（例如，参见ICH质量指导原则Q9）。用户应根据其业务目标和与信息学项目相关的风险对项目进行评估。风险参数包括但不限于整体项目风险、基于新系统对产品质量影响的产品风险、变更管理领域的人员风险和业务风险。商业风险可能包括软件定制引入的风险。质量计划还应确定需要满足的任何内部或外部质量标准，以及需要遵循的任何确定的程序。这些程序可以定义系统在常规使用和系统报废（系统生命周期）期间如何实现、验证和保持验证状态。此外，质量计划可以定义项目所需的文件，如用户需求文件、功能规范文件、系统设计文件、测试脚本和确认计划。请记住，质量要求的实施将对实施项目所需的时间和成本产生影响。因此，项目的质量水平应与项目的规模、潜在风险和相关监管要求相适应。如果与内部或外部供应商合作，供应商应建立自己的质量体系。因此，确保组织的质量计划与供应商的质量计划之间不存在冲突是很重要的，最好的选择是同意单一的统一质量方法。对于不习惯在质量环境中工作的组织或个人，可以采用供应商的质量方法。但是，在所有情况下，供应商应了解、理解并获得相关质量信息的访问权限。
8.2.1.5 Nothing puts a project at risk more than uncontrolled change. Changing functional requirements, commonly referred to as scope creep, represents a type of change that can affect project success. However, other changes that affect project constraints will have the same effect. Change is almost inevitable, necessary, and often beneficial, even in the best planned projects. Potential change, therefore, needs to be managed through some form of change control mechanism, which shall be in place from the start of the project. During the project, and as changes are identified, they should be reviewed to ensure they are appropriate and required, and their impact should be assessed. Based on this assessment, they may be accepted for inclusion. Changes will impact the project constraints and can affect one or more of them, that is, the functionality (quality), the cost of the project, and the time to implement it. This cannot be forgotten when requesting changes; does the change affect existing agreed functionality, does the project have the budget to pay for them, and can the time line for the project be changed? When working with either internal or external suppliers, they shall be involved in managing and controlling change control as, in many cases, they will be best placed to assess the impact of the proposed changes and will be directly affected by them.
8.2.1.5没有任何东西使项目面临的风险超过不受控制的变更。变更功能需求（通常称为范围蠕变）代表可能影响项目成功的变更类型。然而，影响项目约束的其他变更将具有相同的效果。即使在计划最好的项目中，变更也几乎是不可避免的、必要的，而且往往是有益的。因此，潜在变更需要通过某种形式的变更控制机制进行管理，该机制应从项目开始就实施。在项目过程中以及发现变更时，应对其进行审查，以确保其适当性和必要性，并评估其影响。基于该评估，可接受将其纳入。变更将影响项目约束，并可能影响其中一个或多个约束，即功能（质量）、项目成本和实现时间。在请求变更时不能忘记这一点；变更是否影响现有的确定功能，项目是否有预算支付这些费用，项目的时间线是否可以改变？当与内部或外部供应商合作时，他们应参与管理和控制变更控制，因为在许多情况下，他们将最好地评估拟定变更的影响，并将直接受到其影响。
8.2.1.6 The initiation phase forms the groundwork for the entire project and is important to get it right. To help ensure this, the correct individuals and functions shall be involved. Who and what these are will vary depending on the nature and scope of the project. This guide provides some guidance but is not a complete list of all possible stakeholders. When developing a project brief, the key stakeholders will be the person or
group whose idea the project is. Creating the project brief will involve users and others who may be affected by the project and may require the involvement of the organization's project management function. If the project progresses, the chosen supplier should have access to the project brief so that they understand the background of the project. If the project brief contains sensitive material, this may need to be removed. The
key stakeholders for the business case will include the potential funding body for the project, the people who will sign off for the project, and the people or functions that will benefit or be affected by the project (for example, laboratory users, laboratory managers, quality and regulatory functions, and, potentially, customers). In developing the business case, the involvement of the finance function may be required to help calculate potential financial benefits, as well as the organizatin's project management function. If the project progresses, the chosen supplier should have access to the business case so that they understand the background to the project. The supplier may also be given the opportunity to contribute to the business case based on their experience of similar projects. The quality plan key stakeholders will include the project manager and the quality/regulatory function of the organization. People working on the project should be aware of the implication of the quality plan, for example, any implication for people creating user requirements or carrying out testing of the system. The supplier will be a key stakeholder as they will need to adhere to the quality plan. If undertaking a selection process for a system and supplier, details of the quality plan and the expectations placed on the suppliers shall be included so that they can confirm adherence to the quality plan and account for any costs associated with it in the overall system costs. If the organization does not have experience of defining quality plans, it may choose to adopt the supplier's own. When considering a change control mechanism, the key stakeholders will be the project manager and whoever is responsible for the project budget, as they will be most affected by changes to the project. However. it is important to make sure that other stakeholders, especially users, understand why change control is important and why all proposed changes, no matter how small, should be run through the change control mechanism.
8.2.1.6启动阶段是整个项目的基础，重要的是要使其正确。为了帮助确保这一点，应涉及正确的个人和职能。根据项目的性质和范围，这些人员和职能将有所不同。本指南提供了一些指导，但并不是所有可能的利益相关者的完整列表。在编写项目简报时，关键利益相关者将是提供项目想法的人或小组。创建项目简报将涉及可能受项目影响的用户和其他人员，可能需要组织的项目管理职能的参与。如果项目向前推进，所选供应商应能够访问项目简报，以便他们了解项目背景。如果项目简报包含敏感材料，则可能需要删除。业务案例的关键利益相关者将包括项目的潜在资助机构、项目签字人员以及将受益或受项目影响的人员或职能（例如，实验室用户、实验室经理、质量和监管职能以及可能的客户）。在开发业务案例时，可能需要财务职能的参与来帮助计算潜在的财务效益，以及组织的项目管理职能。如果项目向前推进，所选供应商应能够访问业务案例，以便他们了解项目背景。此外，还可根据供应商在类似项目方面的经验，向供应商提供机会促成业务案例。质量计划主要利益相关者将包括项目经理和组织的质量/监管职能。从事项目工作的人员应了解质量计划的含义，例如，对创建用户需求或执行系统测试的人员的任何影响。供应商将是一个关键的利益相关者，因为他们需要遵守质量计划。如果针对某系统和供应商开展遴选流程的，应纳入质量计划详情和对供应商的期望，以便供应商确认遵守质量计划，并在系统总成本中说明与之相关的任何成本。如果组织没有定义质量计划的经验，可以选择采用供应商自己的方式。在考虑变更控制机制时，主要利益相关者将是项目经理，谁负责项目预算，因为他们受项目变更的影响最大。然而，重要的是要确保其他利益相关者，尤其是用户，理解为什么变更控制很重要，以及为什么所有提出的变更，无论多么小，都应该通过变更控制机制运行。
8.2.1.7 Deliverables of the project initiation phase include the project brief, business case, quality plan, change control mechanisms, as outlined above. The deliverables may also include any other documents that the organization's project management function requires. However, the key deliverable of project initiation will be a "go" or "no-go" decision for the project. Such a decision indicates that the fundamentals of the project have been prepared and reviewed, and the project is at least worthy of moving to the next stage. This decision should be accompanied by a guarantee of funding for at least the next phase of the project.
8.2.1.7项目启动阶段的可交付成果包括项目简报、业务案例、质量计划、变更控制机制，如上所述。可交付成果还可包括组织的项目管理职能所需的任何其他文件。然而，项目启动的关键可交付成果将是项目的“做”或“不做”决定。这样的决定表明，项目的基本原理已经准备和审查，该项目至少值得进入下一阶段。这一决定应伴随着至少下一阶段项目的资金保证。
|
|
|手机版|蒲公英|ouryao|蒲公英
( 京ICP备14042168号-1 ) 增值电信业务经营许可证编号：京B2-20243455 互联网药品信息服务资格证书编号：(京)-非经营性-2024-0033
发表于 2021-11-29 09:24:44