Control System Migrations | Procurement Specification & Vendor Selection

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.

Control System Migrations | Procurement Specification & Vendor Selection

Tom McGreevy, PE, PMP, CFSE

12/12/24, 05:55 AM | Automation & IIoT, Engineering | OEM

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

Another decision companies face with any control system migration project where a “buy” decision has been made is whether to partner with an Original Equipment Manufacturer (OEM) or a systems integrator (SI) to perform the implementation. This decision depends on several factors, including the size and complexity of the project, budget constraints, and the need for local versus global availability.

Working with an OEM

OEMs are the original providers of the hardware and software platforms running the vast majority of the world’s automated control systems. These companies have deep knowledge of their products and can provide comprehensive support for implementing and configuring their systems.

However, partnering with an OEM often comes with higher costs. Large OEMs typically have higher hourly labor rates, and their teams may not be located locally, which can add travel expenses to the project. Additionally, OEMs are sometimes more focused on larger, high-value projects, and they may not find smaller migration projects as attractive. This means that for smaller projects, you might not receive the same level of attention or priority from the OEM.

Despite these potential downsides, the advantage of working with an OEM is the assurance that you’re working with the team that knows the platform inside and out. They can often provide direct access to new features, updates, and the highest levels of technical support, which can be critical for highly complex or high-risk projects. Additionally, if your company is taking on migrations as a strategic business initiative at multiple sites concurrently, an OEM partnership, with its deep resources, may make the most sense.

Working with a Systems Integrator

Alternatively, many organizations choose to partner with a systems integrator (SI) for their control system migration projects. SIs are typically smaller, more localized or regional firms that specialize in implementing and integrating control system platforms, often in partnership with one or more OEMs. They can provide a more cost-effective option, particularly for small to mid-sized projects, as their labor rates tend to be lower than those of the large OEMs.

One key benefit of working with a systems integrator is their proximity. A local or regional SI can offer more hands-on, timely support throughout the migration process. They are also likely to be more flexible and responsive to smaller projects, which might not be a priority for the OEM. Additionally, because they maintain relationships with the OEM, they can often provide the necessary expertise while still offering a more personalized and cost-effective service.

It’s also important to consider the relationship that an SI has with the OEM. Many SIs have deep experience with specific platforms and work closely with the OEMs to ensure they are up to date on the latest technologies and standards. This allows them to act as an extension of the OEM’s expertise, but with the added benefit of being more focused on your specific needs.

The Takeaway | Control System Migration Procurement Specification & Vendor Selection

Control system migrations are complex, multifaceted projects that require careful planning, strategic decision-making, and collaboration with the right partners. From deciding whether to manage tasks in-house or outsource to engineering experts, to developing well-written procurement specifications, choosing between single or multiple purchase orders, and selecting the right vendor migration options, every decision impacts the project’s chances of success. Organizations must carefully consider their internal resources, the complexity of the system, and their long-term operational needs to determine the best approach. By taking the time to document the "as-is" state, clearly define system and functional specifications, and engage the right vendors — whether OEMs or systems integrators — companies can navigate the challenges of control system migrations effectively. The key to success lies in thorough preparation, informed vendor selection, and strategic execution to ensure a smooth transition and sustainable outcomes.

The content & opinions in this article are the author’s and do not necessarily represent the views of ManufacturingTomorrow

12/12/24, 05:55 AM | Automation & IIoT, Engineering | OEM

More Engineering Articles | Stories | News

Comments (0)

This post does not have any comments. Be the first to leave a comment below.

Thermal Seal Inspection for Improved Quality and Efficiency

MoviTHERM's Thermal Seal Inspection (TSI) solution provides precise and reliable detection of defects in a variety of packaging types, including pouches, bags, blister packs, bottle caps, and more. By detecting defects in your packages, the TSI solution helps increase efficiency in your production line and ensures top-quality packaging is delivered to your customers every time. With state-of-the-art technology and an experienced team, MoviTHERM is dedicated to delivering accurate inspection solutions and peace of mind to its clients. Contact MoviTHERM today to learn more about their thermal seal inspection solution.

More Products

Feature Your Product