345 lines
12 KiB
Markdown
345 lines
12 KiB
Markdown
# RE Onboarding & Offboarding System
|
||
|
||
# Requirements
|
||
|
||
```
|
||
System Requirements Specifications
|
||
```
|
||
## 16 - Oct- 2025
|
||
|
||
## Version 1. 4
|
||
|
||
|
||
## Contents
|
||
|
||
|
||
-
|
||
|
||
## Change Log
|
||
|
||
### 1.1 Change Log – Version 2.0
|
||
|
||
|
||
**1.1.1 Notification Channel Enhancement**
|
||
|
||
- Added **WhatsApp as a supported notification channel** for reminders and workflow
|
||
communications (e.g., questionnaire completion and status updates), while restricting
|
||
sensitive document sharing to email only.
|
||
|
||
|
||
|
||
|
||
**1.1.8 Access Control & Visibility Refinements**
|
||
|
||
- Defined **view-only access** for DD ASM, DD ZM, and RBM at relevant workflow stages.
|
||
- Granted **approval visibility** to DD Lead where applicable.
|
||
- Enabled **DD ASM and DD ZM** to upload site readiness and LOA-related documents,
|
||
with **DD Lead, RBM, and ZBH** having view access.
|
||
- Limited applicant and dealer portal access to **stage-specific and context-specific**
|
||
**scenarios only**.
|
||
- Confirmed that **dealer portal access is revoked after resignation or termination**.
|
||
|
||
**1.1.9 Terminology & Documentation Corrections**
|
||
|
||
- Clarified **KT Matrix as Kepner Tregoe Matrix** for consistency and correctness.
|
||
|
||
**1.1.10 Super Admin Role Introduction**
|
||
|
||
- Introduced a **Super Admin (Master Role)** with end-to-end access and workflow control
|
||
across modules.
|
||
- Defined segregation of duties by splitting Super Admin into **two DD Admin roles** with
|
||
clearly scoped responsibilities.
|
||
|
||
|
||
|
||
|
||
**1.2.1 Introduction of Dealer Portal**
|
||
|
||
- Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track
|
||
post-onboarding lifecycle requests through the portal.
|
||
- Dealer actions are governed by **role-based access controls** , approval hierarchies, and
|
||
audit mechanisms.
|
||
|
||
|
||
**1.2.3 Dealer Relocation Request Enablement**
|
||
|
||
- Enabled dealers to **initiate and track relocation requests** through a guided workflow.
|
||
- Added support for:
|
||
o Manual or map-based location entry
|
||
o Distance calculation from existing location
|
||
o Property type selection and expected relocation date
|
||
|
||
|
||
- Introduced **document-driven relocation validation** , including statutory, legal, property,
|
||
and infrastructure documents.
|
||
- Implemented **multi-level approval workflow** with Work Notes–based communication
|
||
and audit trail.
|
||
- Ensured dealer has **view and upload access only** , with approvals retained by RE
|
||
stakeholders.
|
||
|
||
|
||
|
||
|
||
## 1 System Overview & Problem Statement
|
||
|
||
**1.1.1 System Overview**
|
||
|
||
The **Dealer Onboarding and Offboarding System** for **Royal Enfield (RE)** is designed to **digitize,
|
||
standardize, and streamline** the complete dealer lifecycle — from **application and
|
||
evaluation** to **approval, resignation, termination, and full-and-final (F&F) settlement**.
|
||
|
||
At present, the process operates through **manual coordination** , involving **emails, spreadsheets,
|
||
and physical documentation** , which makes it difficult to maintain visibility, accountability, and
|
||
consistency across teams.
|
||
|
||
The proposed solution introduces a **centralized digital platform** that brings all stakeholders onto
|
||
a single workflow. It ensures that every stage — **onboarding, operational approvals, financial
|
||
diligence, legal validation, and final closure** — follows a **structured and traceable process**.
|
||
|
||
The system integrates seamlessly with existing RE applications such as **SSO** , **SAP** , and **Finance
|
||
modules** , providing **role-based access** , **real-time tracking** , and **secure document management**.
|
||
It also offers **automated workflows** , **configurable approval hierarchies** , and **AI-assisted decision
|
||
support** to improve efficiency and reduce turnaround time.
|
||
|
||
By moving to a digital workflow, Royal Enfield will achieve higher levels of **process
|
||
efficiency** , **data accuracy** , and **transparency** , ensuring faster decision-making and stronger
|
||
control over the dealer network lifecycle.
|
||
|
||
## 2 Intended Audience
|
||
|
||
This document is intended for all stakeholders involved in the **design, implementation, approval,
|
||
and operational use** of the **Dealer Onboarding and Offboarding System** at **Royal Enfield (RE)**.
|
||
|
||
The following user personas and roles are part of the system:
|
||
|
||
### 2.1 Business & Functional Users
|
||
|
||
|
||
**2.1.2 Regional Sales & Business Team**
|
||
|
||
- **RBM (Regional Business Manager):** Participates in early-stage evaluations, provides
|
||
ground-level business insights, and recommends suitable candidates.
|
||
- **ZBH (Zonal Business Head):** Conducts the second-level review along with DD-Lead;
|
||
provides strategic feedback on market and location viability.
|
||
- **NBH (National Business Head):** Holds final authority for approval or rejection of dealer
|
||
onboarding; reviews consolidated feedback from all levels.
|
||
|
||
- **Relocation Request Submission**
|
||
|
||
```
|
||
The dealer can submit a relocation request in scenarios where there is an intent to shift
|
||
the dealership from the current location to a new proposed location. The request is
|
||
routed for internal feasibility assessment, validation, and management approval before
|
||
execution.
|
||
```
|
||
|
||
All dealer-initiated requests are subject to **defined validations, mandatory document
|
||
submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation,
|
||
document upload, and status visibility** , with **final decision-making authority retained by
|
||
authorized internal stakeholders of RE**
|
||
|
||
|
||
4.5.1.1 Overview
|
||
```
|
||
The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle
|
||
management — from **security deposit validation at onboarding** to **final settlement at
|
||
resignation or termination**.
|
||
It ensures complete financial traceability, proper verification of payments, and compliance with
|
||
Royal Enfield’s financial governance standards.
|
||
The process flow integrates with **Admin, Legal, Dealer Development (DD)** , and **Departmental
|
||
Modules** , ensuring accurate financial updates and timely closure of all financial transactions.
|
||
|
||
**4.5.2 Step-by-Step Process Flow**
|
||
|
||
|
||
```
|
||
4.5.2.3 Internal Clarification & Approval
|
||
```
|
||
- **Action:**
|
||
Finance initiates clarification rounds with departments or DD-Lead for mismatched data.
|
||
- **System Steps:**
|
||
o Uses the **Work Notes** section for comments, tagging users like _@DD-_
|
||
_Lead_ , _@Legal_ , or _@Admin_.
|
||
o Tracks status as _Pending Clarification_ until resolved.
|
||
o After reconciliation, Finance locks the summary and updates case status
|
||
to _Ready for Approval_.
|
||
|
||
`
|
||
|
||
|
||
## 5 System Features & Requirements
|
||
|
||
Here, we describe the **system features** along with their respective **Width** and **Depth** to provide
|
||
complete visibility of each requirement.
|
||
|
||
The **Width** defines the **functional coverage** of a feature — outlining what the feature does,
|
||
its **boundaries, use cases, and user interactions**. It answers the question: _“What scenarios and
|
||
actions are covered by this feature?”_
|
||
|
||
The **Depth** captures the **operational and behavioral details** — describing how the feature
|
||
behaves through its **logic, workflow, system responses, and edge-case handling**. It answers the
|
||
question: _“How does the system execute and respond in these scenarios?”_
|
||
|
||
---
|
||
|
||
Dealer Relocation Request
|
||
|
||
|
||
|
||
**12.2.6 Functionality Scope**
|
||
|
||
This functionality enables a **dealer to initiate, track, and manage dealership relocation
|
||
requests** through the portal after successful onboarding. The system provides a **guided self-
|
||
service mechanism** to propose a new dealership location, submit **location-specific statutory,
|
||
property, and infrastructure documents** , and route the request through a **multi-level internal
|
||
approval workflow**.
|
||
|
||
**12.2.7 Functional Width**
|
||
|
||
- Displays a **dealer-facing relocation dashboard** with summary indicators:
|
||
o Total Requests
|
||
o Pending Requests
|
||
o Completed Requests
|
||
- Lists all **relocation requests** with:
|
||
o Request ID
|
||
o Current location
|
||
o Proposed location
|
||
o Distance from current location
|
||
o Submission date
|
||
o Current status
|
||
o Progress percentage
|
||
- Enables **initiation of a new relocation request**
|
||
- Allows **manual address entry** or **map-based location selection** for the proposed site
|
||
- Captures **distance from the existing location**
|
||
- Provides **request-level detailed view** including:
|
||
o Relocation overview
|
||
o Submitted information
|
||
o Workflow progress
|
||
|
||
|
||
```
|
||
o Required and uploaded documents
|
||
o History & audit trail
|
||
```
|
||
- Supports **document upload, verification, and status tracking**
|
||
- Provides **role-based visibility and action controls**
|
||
- Prevents parallel or duplicate relocation requests for the same outlet
|
||
|
||
**12.2.8 11.3.3 Functional Depth**
|
||
|
||
- Relocation requests can be initiated **only for active and eligible dealerships**.
|
||
- On selecting **“New Relocation Request”** , the dealer is presented with a structured
|
||
submission form capturing:
|
||
o Dealer Code and Dealer Name (auto-populated, non-editable)
|
||
o Current dealership address (auto-populated)
|
||
o Proposed new location (manual entry or map selection)
|
||
o Complete address details (city, state, pincode)
|
||
o Distance from the current location
|
||
o Property type
|
||
o Expected relocation date
|
||
o Reason for relocation
|
||
- Upon submission, the request enters a **multi-level approval workflow** , typically
|
||
progressing through:
|
||
o DD ASM Review
|
||
o RBM Review
|
||
o DD ZM Review
|
||
o ZBH Review
|
||
o DD Lead Review
|
||
o NBH Review
|
||
o Legal (as applicable)
|
||
- Each stage is reflected through a **visual workflow progress timeline** , showing:
|
||
o Responsible role
|
||
o Stage status (Completed / In Progress / Pending)
|
||
o Overall progress percentage
|
||
- The system enforces **mandatory document submission and verification** , categorized as:
|
||
o Property
|
||
o Legal
|
||
o Statutory
|
||
o Infrastructure
|
||
- Required documents include, but are not limited to:
|
||
o Property documents for new location
|
||
o Lease / Rental agreement for new location
|
||
o NOC from current landlord
|
||
o Municipal approvals
|
||
|
||
|
||
```
|
||
o Fire safety certificate
|
||
o Pollution clearance
|
||
o Layout / Floor plan of new location
|
||
o Photos of new location
|
||
o Locality map
|
||
o Building plan approval
|
||
o Electricity connection documents
|
||
o Water supply documents
|
||
```
|
||
- Document status is tracked as **Pending Verification** , **Verified** , or **Rejected**.
|
||
- Authorized internal users may **Approve, Send Back, or Revoke** the relocation request.
|
||
- **Send Back and Revoke actions are communicated through Work Notes** , with mandatory
|
||
remarks captured by the system.
|
||
- All uploads, verifications, remarks, and approvals are **logged in the audit trail**.
|
||
- Upon final approval:
|
||
o The relocation request is marked as completed.
|
||
o Dealer master records are updated as per the approved new location.
|
||
- The system ensures **full traceability and compliance** across all stages of the relocation
|
||
process.
|
||
|
||
**12.2.9 11.3.4 Personas-wise Accessibility & Visibility**
|
||
|
||
```
|
||
Persona Responsibilities Access Rights
|
||
Dealer Initiates and tracks dealership
|
||
relocation requests.
|
||
```
|
||
- Initiate relocation request
|
||
- Provide proposed location details
|
||
- Upload required documents
|
||
- View request status, workflow
|
||
progress, and Work Notes
|
||
DD ASM Coordinates initial review and
|
||
document readiness.
|
||
- View relocation requests
|
||
- Upload and review documents
|
||
- Support coordination
|
||
RBM Performs regional feasibility and
|
||
business review.
|
||
- View requests
|
||
- Review and recommend
|
||
DD ZM Conducts zonal-level evaluation. • View requests
|
||
- Review and provide inputs
|
||
ZBH Ensures zonal governance and
|
||
compliance.
|
||
- Review requests
|
||
- Send Back or Revoke with mandatory
|
||
Work Notes
|
||
- Approve as per hierarchy
|
||
DD Lead Ensures policy adherence and cross-
|
||
functional alignment.
|
||
- Review requests
|
||
- Send Back or Revoke with mandatory
|
||
Work Notes
|
||
- Approval visibility
|
||
|
||
|
||
```
|
||
NBH Provides senior management approval. • Review requests
|
||
```
|
||
- Send Back or Revoke with mandatory
|
||
Work Notes
|
||
- Final approval authority
|
||
Legal
|
||
Team
|
||
|
||
```
|
||
Validates statutory and legal
|
||
compliance.
|
||
```
|
||
- Review legal documents
|
||
- Validate approvals and clearances
|
||
System Enforces workflow and compliance
|
||
rules.
|
||
- Control action availability
|
||
- Track document status and progress
|
||
- Maintain history and audit trail
|
||
|