Selecting digital tools and technologies is an integral part of business operations leadership. Often following a lengthy scoping and business justification process, it includes identifying and choosing the relevant technology for product capabilities, and also digital enterprise platforms to effectively manage data to deliver such products and associated services. Operationally, enterprise applications and PLM platforms are mandatory solutions to manage complexity, large volumes of structured and un-structured data, involving diverse stakeholder groups across the extended enterprise. Selecting a digital platform involve selecting a given vendor; committing to building and maintaining positive commercial relationships with this vendor and their partner network.
In part 1, we elaborate on key considerations when running vendor Request-For-Quotation processes: from context to strategy, selection pre-requisites, stakeholder alignment—especially when dealing with PLM complexity.
RFQ context and strategy
An RFQ process is first and foremost a procurement-driven business process. It requires rigor and discipline in order to derive the best solution and commercial proposal from a supplier, while mitigating related short- and long-term risks:
Short-term:
- Platform is fit-for-purpose and address a given problem statement.
- Platform is good value for money.
- Platform is easy to implement and maintain (at least easier than the legacy solution, and / or based on modern technologies).
- Vendor and / or its partners can efficiently implement and tailor the platform to the enterprise context.
- Platform does not contain showstopper bugs or limitations, and key risks can be mitigated.
Long-term:
- Platform is scalable to enable business growth.
- Platform provides sustainable competitive advantage.
- Platform is a foundation for future evolutions or operational enhancements (per the organization’s context).
- Platform is adaptable to new capabilities (per vendor’s roadmap).
These requirements are not specific to PLM; they apply generically to most enterprise platforms and industry contexts. They would however have specific PLM flavors based on legacy data and processes, integration requirements, process complexity, etc.
Based on complexity, RPQs are often following RFIs and / or RFPs; typically, they are iterative competitive tender processes:
- RFIs aim to qualify vendor information.
- RFPs aim to assert for the best solution (not just the best written proposal).
- RFQs aim to get best price for projects (when you know what you want to buy).
RFQ pre-requisites
Embarking onto an RFP process requires a solid understanding of the business, but also the industry context and trends, as the foundation for a detailed specification of the product or service to purchase. It typically includes:
- Problem statement.
- Business strategy, specifically the operational context, growth or performance expectations, new capability requirements, etc.
- Business case: expected benefit statements, speed-to-benefit, budget split for software license / subscription, enabling technologies, implementation and maintenance services.
- Strategic and tactical solution elements (per high-level roadmap).
- High-level storyboards / use cases to inform business scope.
- IT / system / infrastructure enablers.
- Operating models: current and future change expectations.
- Competitive analysis: market, technology, external references, trends from reputable market analysts and trusted advisors (potentially including existing technology / platform providers).
- Stakeholder map.
- Shortlisted vendor list (based on pre-RFQ screening).
- Selection decision criteria, timeframe, tender deadlines, quality expectations.
RFP stakeholders
Running an RFP requires a variety of skills and expertise, from business to IT, technical, legal, commercial, delivery decision makers, influencers and experts:
- Business stakeholders typically own requirements, budget, cultural-fit, business deliverable sign-off; they contribute as delivery champions, change leads, SMEs, key users, take part of steering committee, design and testing activities, validating high-level assumptions.
- IT stakeholders include technical delivery champions and technical specialists; they own technical delivery, from design to deployment, including infrastructure, converting business to technical requirements, technical governance, operational committee, change management process, technical assumption validations.
- Procurement or purchasing stakeholders ensure the business will get value-for-money, guiding and validating assumptions, making sure the proposal and quotation are fit-for-purpose; they typically drive the overall RFQ process, including the formal relationship with bidders and suppliers.
- Legal stakeholders ensure the organization is protected; they validate terms and conditions, response and quotation compliance.
- Finance stakeholders ensure cost control, financial assumptions and alignment to standards.
Dealing with PLM complexity
Business, data, technical transition planning complexity is often what’s get in the way of PLM platform selection processes:
- How to link high-level business expectation and requirements with detailed technical requirements?
- How data quality and integration stand in the way to a seamless transition to the new PLM platform?
- Is the deployment roadmap technically sound and mitigating transition risks of all types?
- What platform parameters are critical to contextual success, including vendor cultural fit?
- How to balance technical implementation with business change and adoption requirements?
In part 2 of this two-part series, we will elaborate on the decision criteria, how to build positive relationship with the vendor, while staying realist about expected outcomes? What delivery governance must be established to deliver successful PLM platform implementation?
What are your thoughts?
This post was originally published on Momentum-PLM on 22 September 2020.
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
