## Executive Summary This initiative aims to convert workshop notes into a structured future-state supplier onboarding workflow that reduces delays, standardizes supplier data collection, and makes document requirements clearer. The core operational complexity is that onboarding is not uniform: supplier type affects required documentation, and some steps require Legal and Compliance review. The main scope risk is that the request is process-oriented but still underspecified in workflow detail, approval rules, system landscape, and success metrics. A practical first version should therefore focus on a controlled onboarding flow with supplier-type-based requirements, role-based review steps, and clear handoffs rather than attempting a full end-to-end transformation without confirmed business rules. ## Problem/opportunity Current supplier onboarding appears to suffer from three linked issues: 1. Delays in onboarding completion. 2. Inconsistent or incomplete supplier data collection. 3. Unclear document requirements, likely creating rework and approval bottlenecks. This creates an opportunity to design a standardized onboarding workflow that improves speed, completeness, and review transparency while still supporting supplier-type differences and mandatory Legal/Compliance checks. ## Facts provided * The request is to turn workshop notes into structured requirements for a future supplier onboarding workflow. * Primary involved groups are Procurement team, supplier managers, business analysts, and external suppliers. * Desired outcomes are: * reduce onboarding delays * standardize supplier data collection * clarify document requirements * Different supplier types require different documents. * Legal and Compliance teams must review some onboarding steps. * The output should be concise but complete. ## Assumptions These are assumptions, not confirmed facts: 1. There is currently no fully standardized onboarding workflow, or the current one is inconsistently applied. 2. Supplier onboarding includes both internal and external user actions. 3. Supplier data and documents are currently collected through mixed/manual methods such as email, spreadsheets, shared drives, or non-standard forms. 4. Legal and Compliance reviews are conditional rather than mandatory for every supplier. 5. The workflow should support status tracking, document validation, and approval routing. 6. The immediate goal is requirements definition, not vendor selection or implementation planning. 7. “Supplier type” can be operationalized into a manageable set of categories with distinct rule sets. ## Scope in / out ### In scope * Future-state onboarding workflow definition * Standardized supplier data collection requirements * Supplier-type-based document requirement logic * Role-based review and approval flow * Clarification of Legal and Compliance review points * User stories and acceptance criteria * Risks, dependencies, and edge cases ### Out of scope * Legal policy interpretation * Compliance policy creation * Final organizational design or team restructuring * Vendor/tool selection unless later requested * Detailed technical solution architecture * Contract negotiation process beyond onboarding workflow relevance * Supplier performance management after onboarding completion ## Primary users and stakeholder map ### Primary users * **Procurement team** * initiates or manages supplier onboarding * coordinates collection of required data/documents * monitors progress and completion * **Supplier managers** * sponsor or oversee supplier onboarding for business needs * validate supplier relevance and readiness * **External suppliers** * provide company data, contacts, tax/legal documents, and required onboarding materials * **Business analysts** * define workflow rules, requirements, and process logic ### Secondary stakeholders * **Legal team** * reviews suppliers or documents where legal review is required * **Compliance team** * reviews suppliers or onboarding cases with compliance requirements * **Potential additional but unconfirmed stakeholders** * Finance, Risk, IT, Data Privacy, Information Security ## Current-state understanding Based on the inputs, the likely current-state issues are: * document requirements are not consistently clear upfront * supplier-type differences are not being operationalized in a standard way * review steps may be triggered late or inconsistently * handoffs across Procurement, supplier managers, Legal, and Compliance may be unclear * external suppliers may not know what is required, causing incomplete submissions and delay cycles This suggests the current-state problem is not just speed; it is also rule clarity, intake quality, and approval orchestration. ## Business requirements 1. The business must have a standardized supplier onboarding workflow with defined stages, roles, and decision points. 2. The onboarding process must reduce avoidable delays caused by missing information, unclear document requirements, and unclear handoffs. 3. The process must support different supplier types with different required document sets. 4. The process must identify when Legal review is required and route those cases appropriately. 5. The process must identify when Compliance review is required and route those cases appropriately. 6. The workflow must provide clear visibility into onboarding status, pending actions, and blockers. 7. The business must collect a minimum standard set of supplier data consistently across onboarding cases. 8. The process must reduce rework by showing required fields and documents as early as possible. 9. The workflow must support external supplier participation in submitting requested information and documents. 10. The process must allow internal teams to review, approve, reject, or request corrections. ## Functional requirements 1. The workflow must allow creation of a new supplier onboarding case. 2. The workflow must capture supplier type at an early stage. 3. Based on supplier type, the workflow must display the applicable required data fields and document list. 4. The workflow must allow internal users to invite or request external supplier submission of data and documents. 5. The workflow must validate whether required fields and documents are complete before progressing to the next stage. 6. The workflow must route cases to Legal when predefined review conditions are met. 7. The workflow must route cases to Compliance when predefined review conditions are met. 8. The workflow must support internal review outcomes: * approved * rejected * more information required 9. The workflow must notify the relevant party when action is required. 10. The workflow must show current case status, pending reviewer, and blocked reason where applicable. 11. The workflow must maintain an audit trail of submitted documents, status changes, review actions, and comments. 12. The workflow must allow Procurement or designated internal users to view and manage all onboarding cases. 13. The workflow must prevent case completion until all mandatory approvals and required documents are satisfied. 14. The workflow should support standardized templates or checklists by supplier type. 15. The workflow should allow updates or resubmission when information is incomplete or rejected. ## Non-functional requirements 1. **Usability:** The workflow should be understandable by non-technical internal users and external suppliers. 2. **Clarity:** Required data and documents must be clearly visible and easy to interpret. 3. **Traceability:** All major actions, submissions, approvals, and status changes must be logged. 4. **Reliability:** No case should advance without required mandatory inputs and approvals. 5. **Security:** Supplier data and documents must be accessible only to authorized roles. 6. **Maintainability:** Supplier-type rules and document requirements should be configurable without major process redesign. 7. **Scalability:** The workflow should support multiple supplier onboarding cases concurrently. 8. **Transparency:** Users should be able to see who currently owns the next action. 9. **Consistency:** Similar supplier cases should follow the same rules unless an approved exception exists. ## User stories 1. **As a Procurement user**, I want to create a supplier onboarding case so that onboarding can begin in a structured way. 2. **As a Procurement user**, I want to classify the supplier by type so that the correct requirements are applied. 3. **As an external supplier**, I want to see all required data and documents clearly so that I can submit them correctly the first time. 4. **As an external supplier**, I want to know the status of my submission so that I understand what is pending. 5. **As a supplier manager**, I want visibility into onboarding progress and blockers so that I can escalate or support when needed. 6. **As a Legal reviewer**, I want only relevant cases routed to me so that I can review required items efficiently. 7. **As a Compliance reviewer**, I want to review flagged onboarding cases with the necessary context so that I can approve, reject, or request more information. 8. **As a Business Analyst/process owner**, I want supplier rules and required document sets to be standardized so that the onboarding process is consistent and measurable. 9. **As an internal reviewer**, I want to request corrections without restarting the entire case so that rework is controlled. 10. **As a process owner**, I want a full audit trail so that onboarding decisions and delays can be traced. ## Acceptance criteria ### Supplier-type logic * Given a new onboarding case, when the supplier type is selected, then the workflow shows the relevant required data fields and documents for that supplier type. ### Mandatory completion checks * Given an onboarding case with missing mandatory information, when a user tries to move it forward, then the workflow blocks progression and identifies the missing items. ### Legal review routing * Given a case that meets Legal review conditions, when the relevant trigger is reached, then the case is routed to Legal and cannot be completed before Legal disposition is recorded. ### Compliance review routing * Given a case that meets Compliance review conditions, when the relevant trigger is reached, then the case is routed to Compliance and cannot be completed before Compliance disposition is recorded. ### External supplier submission * Given an external supplier has been requested to provide onboarding information, when they access the request, then they can submit the required data and documents assigned to their case. ### Correction cycle * Given a reviewer finds issues in a submission, when they request more information, then the case status changes accordingly and the supplier/internal owner is notified of what must be corrected. ### Status visibility * Given an onboarding case exists, when an authorized user opens it, then they can see current status, pending owner, and unresolved blockers. ### Audit trail * Given any status change, document upload, approval, or rejection occurs, when the event is saved, then it is recorded with timestamp and acting user/role. ### Completion control * Given all required inputs and approvals are complete, when the final validation runs, then the case can be marked complete. * Given required approvals are still missing, when final validation runs, then the case cannot be marked complete. ## Dependencies / systems / integrations ### Confirmed dependencies * Legal review participation * Compliance review participation * Supplier-type-based rules and document requirements ### Likely dependencies needing confirmation * Master supplier data source or ERP/vendor master system * Document repository or attachment handling capability * Email/notification capability * Identity/access model for external suppliers * Reporting/dashboard capability for case monitoring ### Integration considerations No systems were named in the inputs. That is a material gap. If implementation is later planned, likely integration points may include: * supplier master / ERP * document management repository * workflow/task management * notification service * audit/reporting layer These are possibilities, not confirmed facts. ## Risks and edge cases ### Risks 1. **Supplier type ambiguity** * If supplier categories are unclear or overlap, routing and document logic will remain inconsistent. 2. **Approval bottlenecks** * Legal and Compliance reviews may reduce delays only if entry criteria and SLAs are clearly defined. 3. **Overstandardization** * A workflow that is too rigid may fail to handle valid exceptions. 4. **Unclear ownership** * If stage ownership is not explicit, cases may stall between teams. 5. **Incomplete policy-to-process translation** * Legal/Compliance requirements may exist in policy form but not in operational decision rules. 6. **Poor supplier experience** * External suppliers may still submit incomplete information if instructions are unclear. 7. **Missing system landscape definition** * Requirements may stay too abstract for build/design without confirmed systems and data sources. ### Edge cases * supplier type changes mid-process * one supplier serves multiple categories with different requirement sets * required document is expired, unreadable, or incorrect version * Legal approval granted but Compliance rejects * supplier submits partial information only * supplier becomes unresponsive mid-onboarding * urgent onboarding request bypass is requested * duplicate onboarding cases are created for the same supplier * an exception is requested for a normally mandatory document * internal reviewer changes after process start * case requires re-review after corrected documents are submitted ## Clarification Needed 1. What supplier types must the workflow support, and how are they defined? 2. Which onboarding steps always apply, and which are conditional? 3. What specific triggers require Legal review and Compliance review? 4. What minimum supplier data fields and document categories must be standardized? 5. Which systems, if any, are currently used for supplier onboarding, supplier master data, and document storage? ## Recommended next steps 1. Define the supplier-type taxonomy and map required documents per type. 2. Identify mandatory vs conditional workflow steps. 3. Convert Legal and Compliance review needs into explicit routing rules. 4. Define the minimum standard supplier data model. 5. Create a future-state workflow diagram with statuses, handoffs, and exception paths. 6. Align on ownership per stage, including who can approve, reject, request corrections, and complete onboarding. 7. Define operational KPIs, for example: * average onboarding cycle time * first-time-complete submission rate * number of rework cycles per onboarding case * review turnaround time by function 8. Validate whether the organization wants a simple workflow standard first or a system-enabled implementation scope next. Critical challenge to the current scope: “reduce onboarding delays” is valid, but not yet measurable. Before implementation, the business should define what delay reduction means operationally, such as target cycle time, fewer incomplete submissions, or reduced approval wait time.