Digital Contractor Control of Work Platform

Preliminary Market Engagement Digital Contractor Control of Work Platform Background Severn Trent Water is seeking information from the market regarding SaaS solutions capable of digitising and governing the lifecycle of contractor management and work authorisation activities. Current processes are fragmented across email, spreadsheets, SharePoint, paper records and localised working practices. There are opportunities to improve visibility, consistency, auditability and operational efficiency. The organisation wishes to understand the maturity of the market and identify potential SaaS solutions that could support a future procurement exercise. This market engagement is not a call for competition, invitation to tender or commitment to procure. Business Problem Severn Trent requires a solution that provides consistent governance and visibility over contractor activities occurring across operational sites and facilities. The organisation seeks to: • Improve contractor governance and compliance • Digitise contractor work authorisation processes • Reduce administrative effort • Improve management visibility • Strengthen auditability • Improve consistency across business units • Improve efficiency by digitising manual processes • Maintain a clear record of contractor competence, approvals and activities Scope The scope may include: • Wastewater operations • Water operations • Bio Resources • Property • Other operational business functions Suppliers should identify whether their platform can support deployment across multiple business units using common workflows whilst maintaining local operational flexibility. Existing Business Processes The organisation currently operates contractor governance and work authorisation processes which include: • Contractor approvals • Site attendance acceptance • Work authorisation • RAMS review • Permit controls Desired Outcomes The solution should provide: 1. Contractor Governance The ability to maintain a central contractor repository containing: • Contractor information • Competency records • Insurance information • Accreditation records • Authorisations • Expiry management • Supporting documentation 2. Work Authorisation The ability to: • Receive contractor work requests • Review and approve requests • Apply site-specific controls • Communicate site hazards • Authorise work • Track work status • Close activities 3. RAMS Management The ability to: • Receive RAMS submissions • Review and approve RAMS • Reject and request amendments • Version control submissions • Maintain an audit trail 4. Permit Management The ability to: • Create permits • Approve permits • Track permits • Close permits • View current and historical permits • Support a variety of permit types Examples may include: • Hot works • Confined space • Excavations • Electrical work • Contractor work authorisations 5. Visibility and Control The ability to: • View current activities • View future planned activities • View historical activities • Report on contractor performance • Report on compliance activity • Identify conflicting activities 6. Auditing and Assurance The ability to: • Record audits • Record inspections • Record assurance activities • Track actions • Maintain full audit trails 7. Mobility The solution should support: • Mobile devices • Operational users • Contractors • Remote working • Field-based approvals Non-Functional Requirements Suppliers should comment on: • SaaS deployment model • UK hosting options • Cyber security accreditations • Identity management • Single Sign-On • Zero Trust Architecture • API capability • Data export capability • Business continuity • Disaster recovery • Mobile capability • Offline working • Accessibility Suppliers are not expected to understand current process names or terminology. Instead, suppliers should explain: How their product would support: • Repeat contractor authorisations • Site-specific approval processes • Work authorisation workflows • Contractor governance • Permit-to-work processes without requiring bespoke development. Solution Architecture Suppliers should describe their proposed solution architecture and indicate whether the capabilities described in this PME are delivered through: • A single SaaS platform • Multiple integrated modules within a common platform • Multiple products requiring integration • Custom-developed functionality • Third-party partner products Severn Trent recognises that these capabilities may not necessarily be delivered through a single product. Suppliers should clearly identify: • Which capabilities are native • Which capabilities require configuration • Which capabilities require integration • Which capabilities require custom development Responses should explain any implementation, support, licensing or operational implications arising from the proposed architecture. Suppliers should describe the largest customer environments currently supported by their platform, including: • Number of sites • Number of contractor organisations • Number of users • Geographic coverage Supplier Response Instructions Supplier responses must be submitted through SAP Business Network. Responses should be concise and focused on the requirements described in this PME. Responses should comprise: 1. Supplier Overview (maximum 2 pages) Please provide: • Company name • Product name(s) • Headquarters location • Approximate number of employees • Relevant industry sectors served • Utility sector experience • Water sector experience • • 2. Solution Overview (maximum 5 pages) Describe: • How your solution addresses the business problem described in this PME • Key differentiators • Typical deployment model • Typical implementation approach • Mobile capabilities • Reporting and analytics capabilities Please avoid generic marketing material where possible. 3. Architecture Statement (maximum 2 pages) Describe: • Whether the solution is provided as: o A single SaaS platform o Multiple modules within a common platform o Multiple integrated products o A partially bespoke solution • Any third-party products required • Any custom development required • Any significant implementation dependencies 4. Capability Response For each requirement identify whether the capability is: • Native • Configurable • Integration required • Custom development required • Roadmap • Not available Suppliers should provide explanatory comments where appropriate. 5. Customer Scale (maximum 2 pages) Provide examples of the largest customer environments currently supported, including: • Number of sites • Number of contractor organisations • Number of users • Geographic footprint 6. Commercial Model (maximum 2 pages) Provide high-level indicative pricing information including: • Licence model • Charging basis • Typical implementation costs • Typical support costs • Typical integration costs Detailed pricing is not required at this stage.