控制系统迁移 | 采购规范和供应商选择

　　Introduction | Control System Migrations | Part 3

　　October 2024 — by Tom McGreevy, PE, PMP, CFSE — If you’ve made it through justifying the cost for your control system migration project and mitigating risks through front-end loading (FEL), you are probably well aware that control system migrations are complex projects that require careful planning and strategic decision-making to ensure a successful outcome. Whether upgrading legacy systems or implementing new technology, organizations are faced with several choices throughout the migration process. From deciding whether to handle tasks internally or outsource them, to selecting the right vendor(s) and structuring procurement, each decision plays a vital role in the overall success of the project.

　　In part three of our control system migration series, we take a look at procurement specification and vendor selection considerations such as the make-or-buy decision, specification development, comparing bids, managing purchase orders, and selecting between an OEM or systems integrator. This blog will help operators navigate the challenges of control system migrations and make informed decisions that align with their project goals, budget, and long-term operational needs.

　　To Make or To Buy — That is the Question

　　One of the biggest questions that operators must ask themselves during any control system migration project is whether to perform key tasks internally ("make") or to outsource them to external engineering firms ("buy"). This decision impacts not only the project’s cost structure but also the timeline, resource allocation, and overall risk management.

　　In-House Expertise vs. External Support

　　The first question any organization must ask is whether they have the internal expertise to first develop the necessary procurement specifications, and later to perform critical tasks like hardware and software configuration, testing, construction or construction oversight, and finally commissioning and startup. If a company has a seasoned in-house team with experience in these areas, then it might make sense to handle much of the work internally. However, the reality for many organizations is that, while in the past they may have had this level of specialization in-house, years of corporate downsizing has resulted in a plant that is staffed to operate and maintain, but not to change or grow. This is where external partners can offer value.

　　Developing Functional and Hardware Specifications

　　Many clients seeking to replace or upgrade their control systems find that developing detailed functional specifications and hardware requirements is one of the most daunting challenges. It has become more common for organizations to partner with engineering firms like aeSolutions to provide these services, ensuring that the right foundation is set for successful vendor engagement and implementation. Whether you decide to develop specifications internally or bring in external help largely depends on your team’s capacity to handle such detail-oriented work in the time required to complete it.

　　Project Scope and Complexity

　　Projects that involve complex control system migrations, especially those operating in regulated or highly specialized industries, often benefit from third-party expertise to manage risk. The make-or-buy decision can also hinge on how familiar your internal team is with new technology or compliance requirements.

　　Resource Allocation and Timeline

　　Time is a critical factor. Even if you have the expertise to, for instance, develop the specifications internally, does your team have the bandwidth to dedicate to such a significant task? External vendors can accelerate this process, as they often have pre-existing frameworks, tools, and processes to expedite specification development, procurement planning, and system integration.

　　The decision to "make or buy" in a control system migration project is multifaceted, involving an assessment of internal capabilities, the scope of the project, and the available resources. Partnering with an external engineering firm can significantly help operators navigate these decisions by offering specialized services in functional specification development, hardware design, and project management. For companies without the necessary in-house resources, opting for external support can ensure that projects stay on time and within budget, while minimizing risk and ensuring compliance with industry standards.

　　The Importance of an Apples-to-Apples Comparison of Bids

　　If you’ve decided to work with an external vendor for your control system migrations project, you’ll need to be prepared to solicit and compare bids. The process of comparing these bids can become complex if the requirements are not clearly defined or standardized across vendors. The key to a fair comparison is ensuring that the procurement specifications are well-documented, precise, and conveyed in a way that all bidders understand and respond to similarly.

　　Establishing Clear and Consistent Requirements

　　A well-defined procurement specification is essential to level the playing field for all potential vendors. The goal here is to outline your system’s requirements in enough detail so that bidders know exactly what you need. Even if every detail isn't fully defined at the outset, sharing a clear overview of the project's scope and expectations can prevent wide variations in vendor proposals.

　　If the procurement specifications are vague or too open-ended, you may end up receiving a wide range of responses — from proposals that only cover the absolute bare minimum to others that offer high-end, premium solutions that far exceed the project’s actual needs. This spectrum of responses can make it challenging to make an apples-to-apples comparison of the bids and determine which one offers the best value for your organization.

　　Balancing Price and Value

　　Without precise specifications, vendors may interpret your project needs differently, leading to bids that range from cost-effective solutions to more feature-rich — and more expensive — options. For instance, one bidder might propose the minimum viable solution to meet basic operational requirements, while another might propose an advanced system that exceeds your actual needs.

　　The challenge lies in striking a balance between affordability and value. While the lowest bid may seem attractive from a budgetary perspective, it may not meet all the functional requirements. Conversely, the highest bid may offer unnecessary features that inflate the overall cost. By defining the requirements clearly from the start, you can ensure that all vendors are bidding on the same or a very similar scope, which in turn allows you to make a fair comparison.

　　The process of comparing bids is more than just identifying the lowest price — it's about ensuring that the bids align with the project's requirements and offer the best value. By taking the time to develop a detailed procurement specification, you can help ensure that all vendors are bidding on the same scope, enabling a fair and effective comparison. This ultimately helps reduce the risk of selecting a solution that either underperforms or overextends your budget without adding proportional value.

　　One Purchase Order or Several?

　　When planning a control system migration, contracting strategy is an area that can significantly impact project execution, specifically, whether to issue one purchase order covering all aspects of the project or to break it down into several purchase orders, each targeting specific phases or services. This decision is largely influenced by how much control an organization wants over individual project elements and the resources available for managing multiple contractors or vendors.

　　In recent years, it has become more common for clients to solicit bids that cover the entire project scope — functional specification, configuration, construction, and testing — under one proposal. This trend is driven by a desire to reduce management complexity and place responsibility on a single contractor, who may either perform all the work or manage subcontractors on behalf of the client.

　　Choosing to issue a single purchase order means entrusting a single entity with managing the entire project, from developing the functional requirements specification to system configuration, construction, and even system testing. This centralized approach can streamline communication and coordination, as one vendor takes responsibility for delivering the full scope of the project. This option can reduce the burden on the operator/project manager(s), who won't need to oversee multiple contractors or manage complex interdependencies between different service providers. It is likely that most bidders responding to a “one purchase order” solicitation will themselves have to partner with others to bring the full set of skills needed. For instance, it is a rare systems integrator who is also a fully qualified electrical contractor and has its own craft labor, so the SI may have to sub-contract the construction and perform a construction management role. In these circumstances, the ability of the bidding “prime” contactor to manage sub-contractors should be fully investigated.

　　Alternatively, opting for several purchase orders allows the client to maintain more direct control over each phase of the project. For example, one organization might handle the functional specification, another would take care of configuration, a separate electrical contractor could be hired for construction, and yet another vendor could handle system fabrication and testing. By compartmentalizing the work across multiple vendors, the client can select specialists for each task, potentially increasing the quality of each deliverable. However, this approach demands more from the client in terms of project management and coordination, as they will need to ensure seamless handoffs between each contractor and resolve any issues that arise between different teams.

　　Benefits of a Single Purchase Order

　　Streamlined Communication and Management: With a single PO, there’s one main point of contact and fewer layers of coordination, making it easier to maintain clarity and avoid misunderstandings.

　　Reduced Administrative Overhead: Managing multiple POs can create administrative challenges, from contract negotiation to handling project milestones and payments. A single contract reduces the complexity.

　　Accountability: A single vendor is accountable for the entire project, meaning they are responsible for both the high-level planning and the detailed execution. This can lead to better overall project alignment and fewer disputes over scope or responsibility. With a well-developed scope, you likely will have structured your commercial terms to be mostly “fixed fee”, with some exceptions (typically commissioning and startup support are performed on a “time and expense” basis). This transfers risk to the seller, but you are likely to pay marginally more for that risk reduction than you would otherwise by managing several vendors through multiple purchase orders.

　　Benefits of Multiple Purchase Orders

　　Specialization and Expertise: By issuing separate POs for functional specification, configuration, construction, and fabrication, clients can hire specialized organizations with the expertise to excel in each area. This can lead to higher-quality outputs for each phase of the project.

　　Greater Control: Multiple POs give the client more control over the contracting process and each project's stage. For organizations that want tight oversight or are managing a particularly complex or high-risk control system migration, this level of control can help mitigate potential risks. If your organization has the skills and bandwidth to manage multiple vendors, and with a well-defined scope, you may save money by assuming the coordination efforts and associated project risk.

　　Flexibility in Vendor Selection: When using several purchase orders, the client can select different vendors based on their strengths and price points for specific tasks.

　　Deciding What’s Right for Your Control System Migration Project

　　The decision between one purchase order or several is often determined by the company’s internal resources and its desired level of control. Some companies prefer the simplicity and efficiency of a single purchase order, especially if they have limited resources for managing multiple vendors. Others, particularly those with more complex projects or specific performance requirements, may prefer to split the project into smaller parts, ensuring they have direct control over each critical phase.

　　Think Through Getting Keys to Your New System

　　When planning a control system migration, it is natural for an organization to focus on the design, configuration, and installation phases. However, it’s equally important to think through what happens when the project is complete and the “keys” to the new system are handed over. This handoff represents not only the culmination of the technical work but also the point where the organization takes full responsibility for operating and maintaining the system or has appropriately arranged for contracted maintenance support.

　　Beyond Design and Configuration

　　The process of "getting the keys" involves much more than simply having a control system delivered and installed. Organizations must consider the resources needed for successful cutover, site testing, startup, and ongoing support once the project is complete. It’s not enough to just focus on the technical aspects leading up to the handover. Teams must think ahead about the operational and maintenance requirements once the vendor steps back.

　　In many cases, a company might not have the internal resources or expertise to fully support the new system, especially if it's significantly different from what was in place before. This lack of resources has become more common, which makes planning for post-handover support essential.

　　Planning for Post-Commissioning Support

　　One important consideration is whether your organization will need follow-on support contracts. Although the system may be handed over in a fully operational state, it’s important to have a plan in place for ongoing maintenance and troubleshooting. For many organizations, this means working with the vendor to establish a support contract that extends beyond the handover period.

　　In some cases, the first year of support can be capitalized as part of the control system migration project itself. This can be a significant advantage, as capitalizing the support allows organizations to fund it through the project’s capital budget rather than requiring additional operating expenses after the project is complete. However, it’s important to consider this early in the planning process. If your organization decides that a support contract is needed, this needs to be factored into the overall project budget and submitted for capital approval before the project begins. Early involvement by your company’s accounting department may prevent difficult discussions later regarding capitalizing or expensing support contracts.

　　Whether it's planning for site testing, securing support contracts, or ensuring proper training, the handoff should be seen as the start of ownership rather than the end of the project. This proactive approach will set the stage for sustained success well beyond the initial migration.

　　Defining System Specification and Functional Specification

　　With any control system migration project, there are two subsets of the overall procurement specification — the system specification and the functional specification. These two areas serve distinct purposes and must be clearly defined to ensure a successful control system migration. The terms for these project documents vary in name and format, but the content is critically important.

　　System Specification: Defining the Hardware and Software Requirements

　　The system specification, sometimes referred to as the hardware specification, focuses on the technical aspects of the control system — specifically, what hardware and software are required to meet the control system migration project’s goals. This specification details the necessary components, such as controllers, servers, communication networks, and software platforms, ensuring that the system will meet the operational and performance requirements laid out by the client.

　　The development of the system specification is usually a more straightforward process compared to the functional specification. Owners can rely heavily on the expertise of their chosen OEMs or systems integrators, as they are familiar with the capabilities of the control platforms they work with. Although not as necessary as with the functional specification aspect, it is still beneficial for a client to work with the vendor to ensure that the specification aligns with the project’s overall objectives and operational constraints.

　　Functional Specification: Defining What the System Needs to Do

　　The functional specification, on the other hand, focuses on the operational requirements of the system — what it must do to meet the company’s needs. A functional specification document answers critical questions about how the system should behave, how processes will be controlled, and how new or existing functionalities will be managed within the system. For example, if the project involves a legacy system upgrade, the functional specification must outline what the system currently does and any additional functionalities that the new system needs to perform.

　　To a greater extent than the system specification, the development of the functional specification requires collaboration between the owner and the vendor. It should be noted however, that vendors and systems integrators, while experts in control systems and platforms, are not typically process experts. They may have extensive knowledge of the systems they engineer, but they may not have the same depth of understanding about the specific chemical or mechanical processes that the system must control.

　　This is why functional specification development requires input from both parties. The client, who has a thorough understanding of the processes involved, must work closely with the vendor to ensure that the control narratives and operational requirements are fully captured. This collaboration is critical to avoid misunderstandings or gaps in the system’s functionality, which could lead to delays or operational issues during startup.

　　Exceptions do exist, so you may find an OEM or a systems integrator with deep process knowledge of your industry. If so, consider yourself fortunate, as functional specification development is often an area where a dearth of owner resources or expertise can bog down the progress and result in schedule delays, or worse, improperly specified functional requirements.

　　System and functional specifications are fundamental to the success of a control system migration project. While the system specification focuses on the hardware and software requirements, the functional specification defines how the system will operate and meet the owner's needs. Developing these specifications requires a balance between technical expertise and process knowledge, with close collaboration between the owner and vendor. By selecting a vendor that understands both the platforms and the importance of collaboration, owners can ensure a smoother, successful migration process.

　　Understanding the “As-Is” State of a System

　　One of the more challenging elements of a control system migration is documenting the current, or “as-is” state of the system — both the physical and the logical (the programming). The accuracy of the existing system’s documentation impacts the success of the migration process, particularly during detail design and implementation. Unfortunately, for systems that have been in place for decades, such documentation may be incomplete, outdated, or exist only in the form of internal team knowledge passed down informally within the organization.

　　Project teams and vendors should have a clear understanding of the physical layout, wiring, and system configuration before beginning any detailed design work. This includes capturing details such as I/O points, control panels, network architecture, and wiring diagrams. In some cases, the hardware may have undergone ad-hoc modifications over the years that were never formally documented, further complicating the process. The configuration (programming) of the system must also be documented, so that all parties can understand how the process is currently controlled, even if significant changes are planned.

　　For these reasons, documenting the as-is state of the hardware and software must happen during the Front-End Loading (FEL) phase. Doing so helps ensure that the team has a solid foundation to work from when transitioning to the new system. The risk of skipping this step, or relying on incomplete documentation, is that errors will arise during cutover — especially during time-critical turnarounds — which can lead to expensive delays or operational disruptions.

　　Options for Capturing the As-Is State

　　Companies must make a decision early in the project about how to approach capturing the as-is state. If the system documentation is poorly maintained, as is often the case with older systems, the owner needs to assess whether they have the internal resources and expertise to update and complete the documentation themselves. This effort can be time-consuming and requires a deep understanding of both the process and the control system architecture. Alternatively, the owner may choose to outsource this work to third-party vendors who specialize in control system migrations.

　　Vendor Migration Options

　　The process of evaluating vendor migration options involves not only selecting the right platform (a vendor may offer several variations), but also defining the stages of migration and determining how much flexibility or structure you want to allow in the vendor proposals. The goal is to ensure that vendors understand the scope of the project and are equipped to meet both your technical and operational needs.

　　Platform Choices: Balancing Cost and Capability

　　The choice of platform for your control system migration is one that will impact the cost, capability, and future flexibility of the system. There is a wide range of options, from more affordable, bare-bones platforms to premium, highly capable systems with extensive features and flexibility.

　　By clearly defining your platform requirements, you can guide vendors to propose solutions that meet both your budgetary and operational needs. However, it’s important to strike a balance — although low-cost solutions may be attractive, they may not offer the long-term benefits or reliability needed for your specific industry.

　　Staging the Migration Process

　　Another important consideration is determining the stages of the migration process. Operators should define an execution strategy that outlines the sequence of steps: which parts of the system will be migrated first, second, third, and so on. This approach allows you to ensure a smooth transition and minimize disruptions during the migration.

　　If vendors aren’t provided with enough detail about how the migration will unfold, they may make assumptions that lead to misaligned or faulty bids that may not be executable if the migration stages and sequence aren’t properly communicated.

　　Providing Flexibility for Vendors

　　While some companies may know exactly what they need and dictate a rigid scope, others may want to give vendors the flexibility to propose creative solutions or cost-saving ideas. In these cases, it’s important to structure the procurement specifications to allow for both a base bid and optional upgrades or alternative strategies. For example, the base bid would cover the minimum requirements, while vendors could offer additional features or enhancements as options.

　　This approach ensures that vendors meet the project’s essential needs but also allows room for innovation, enabling the owner to consider creative or cost-effective solutions that may not have been previously identified.

　　Choosing the right vendor migration options involves a balance between defining project requirements, an execution sequence that aligns with business needs, and allowing vendors the flexibility to propose creative solutions. Owners need to determine the most appropriate platform based on budget, capability, operational constraints (allowed downtime for migration activities), and future needs, while also structuring the procurement specifications to allow for both base bids and optional enhancements. By clearly defining the stages of migration and establishing guidelines for vendor proposals, owners can avoid the pitfalls of inconsistent or inexecutable bids and ensure a smoother, more predictable migration process.

　　OEM vs. Systems Integrator

　　在任何控制系统迁移项目中，公司面临的一个重要决策是是否与原始设备制造商(OEM)或系统集成商(SI)合作进行实施。这个决策取决于多个因素，包括项目的规模和复杂性、预算限制以及对本地还是全球需求的考虑。

　　与原始设备制造商合作

　　OEM是运行世界上大多数自动化控制系统的基础硬件和软件平台的原始提供商。这些公司对其产品有深入的了解，并且可以为实施和配置其系统提供全面的支持。

　　然而，与OEM合作通常伴随着更高的成本。大型OEM通常具有更高的每小时人工费率，而且他们的团队可能不在当地，这可能会增加项目的差旅费用。此外，OEM有时更专注于大型、高价值的项目，他们可能不会对小型迁移项目感到同样吸引。这意味着对于小型项目，您可能不会从OEM那里获得相同水平的关注或优先级。

　　尽管有这些潜在的缺点，与原始设备制造商(OEM)合作的优势在于可以确保你与对平台了如指掌的团队合作。他们通常可以提供直接访问新功能、更新以及最高水平的技术支持，这对于高度复杂或高风险的项目来说可能是至关重要的。此外，如果你的公司正在多个地点同时进行迁移作为战略业务举措，那么拥有深厚资源的OEM合作伙伴关系可能最为合适。

　　与系统集成商合作

　　或者，许多组织选择与系统集成商(SI)合作进行他们的控制系统迁移项目。SI通常是较小的、更本地化或区域性的公司，专门从事控制系统平台的实施和集成，通常与一个或多个OEM合作。它们可以提供更具有成本效益的选择，特别是对于中型项目，因为它们的劳动费率通常低于大型OEM。

　　与系统集成商合作的一个关键好处是他们地理位置上的接近。本地或区域系统集成商在整个迁移过程中可以提供更多的实际支持和及时的帮助。他们还可能对小型项目更加灵活和响应，而这些项目可能不是OEM的优先事项。此外，因为他们与OEM保持关系，他们通常可以提供必要的专业知识，同时提供更个性化和更经济的服务。

　　还应考虑SI与OEM的关系。许多SI在特定平台上拥有丰富的经验，并与OEM紧密合作，以确保他们了解最新的技术和标准。这使他们能够作为OEM专业知识的延伸发挥作用，但同时更加关注您的具体需求。

　　The Takeaway | 控制系统迁移 采购规范 & 供应商选择

　　控制系统迁移是复杂且多方面的项目，需要仔细规划、战略决策和与合适合作伙伴的协作。从决定是内部管理任务还是外包给工程专家，到制定良好的采购规范、选择单个或多个采购订单，以及选择正确的供应商迁移选项，每一个决策都会影响项目成功的可能性。组织必须仔细考虑内部资源、系统的复杂性以及长期运营需求，以确定最佳方法。通过花时间记录“现状”，明确定义系统和功能规范，并与其他合适的供应商(无论是OEM还是系统集成商)合作，公司可以有效地应对控制系统迁移的挑战。成功的关键在于充分准备、明智选择供应商以及战略性执行，以确保顺利过渡和可持续的结果。