E-learning system integrated with CRM/ERP

The problem

The training business ran on Excel and chat messages: sales consultants logged leads in one file, Accounting tracked tuition in another, and the Academic office allocated classes in a third. The client wanted “one piece of software to manage everything” but could not yet describe how the current process actually ran.

ConsequencesThe three pain points the client mentioned first

• Receivables did not match between departments.
• Nobody knew which students were about to finish a course and should be followed up.
• Teachers' teaching hours had to be reconciled by hand at the end of each month.

Context and role

• Scope: CRM (from lead to enrolment), students and classes, tuition and receivables, teachers and teaching hours, reports for the Management board.
• Stakeholders: the technical team, the internal client, the outsourcing client, HR, Accounting and Sales.
• My role: discovery, As-Is and To-Be analysis, writing the BRD, PRD and SRS, wireframes, business rules, the data model, supporting testing and UAT.

The examples below use a simulated training centre called “BrightPath”.

Step 1: As-Is discovery, department by department

I interviewed each department separately, mapped the process they actually run and looked for the breaks between departments.

As-IsData breaks at two points between departments

1. 1Sales consultantleads from Facebook, Zalo; logged in Excel
2. 2Enrolmentpaper form
   discounts agreed verbally, recorded by nobody
3. 3Accountingtuition file
   deferrals not reported to Accounting
4. 4Academic officeclass allocation file

Stakeholder mapWhat each department needs and where it is stuck

	What they need	Current pain point	Impact on the design
Sales	Track leads, know who is about to finish a course	Duplicate leads, leads lost when a sales consultant leaves	CRM pipeline, permission to reassign leads
Accounting	Collect the right amount, in full, and reconcile quickly	Discounts agreed verbally, recorded by nobody	Pricing policy, discount approval
Academic office	Allocate classes, change classes, handle deferrals	Deferrals are not reported to Accounting	Enrolment status linked to receivables
Teachers	Know their schedule, have hours counted correctly	Self-reported hours, disputes at month end	Attendance linked to teaching hours
Management board	Revenue, receivables, re-enrolment rate	A long wait for every report	Reports built from operational data

Step 2: To-Be design around the student lifecycle

I did not design by department but by student lifecycle. Each module is one stage of that lifecycle.

To-BeOne lifecycle, one source of data

1. 1CRMconsult, close
2. 2Enrolmentcontract
3. 3Tuition and receivables
4. 4Classesattendance produces teaching hours

Classes → CRM · 4 or fewer sessions left: back to the re-enrolment follow-up list automatically (BR-06)

Business rulesExcerpt from the BRD, each rule has an owning department

	Owner
BR-01 · A discount above 10% must be approved by a manager in the system before enrolment	Accounting
BR-02 · Tuition in at most 3 instalments; instalment 1 is at least 30% and is collected before the first session	Accounting
BR-03 · Deferral lasts at most 6 months; receivables are frozen; Accounting and the sales consultant are notified automatically	Academic office
BR-04 · Refunds only before session 3, on a decreasing scale, calculated on the amount after discount	Management board
BR-05 · Teaching hours come from attendance, not entered by hand; any difference must be approved	HR
BR-06 · Students with 4 or fewer sessions left move automatically to the re-enrolment follow-up list	Sales

One action, two pieces of data

1. 1Teacher takes class attendanceStudents presentTeacher's teaching hours
2. 2No separate timekeeping module needed

Step 3: Data model and the tuition and receivables flow

I designed the data model together with the Dev team. The focus was a single source of truth for receivables.

Data modelMain relationships between entities

Tuition and receivables (To-Be)Receivables always equal total invoices minus total payments

1. 1Enrolmentgenerates an invoice for each instalment
2. ?30% of instalment 1 collected?if not, class allocation is blocked
3. 3Class allocation unlocked
4. 4Reminders for instalments 2 and 37 days in advance
5. 5Overduealert the sales consultant and Accounting, flag the student

Legacy data migrationDo not import the "Outstanding" column from Excel

1. 1Old invoices and payments
2. 2Recalculate receivables
3. 3Variance report
4. 4Accounting resolves it once

Step 4: Handover documents for Dev

Part of the Dev team is outsourced, so the documents have to stand on their own.

Document setEnough for a new person to read and carry on

• Goals, scope, stakeholders, As-Is and To-Be, business rules, success criteriaBRD
• Coded functional requirements by module; permissions, logging, report performancePRD, SRS
• Matrix of roles and functionsPermissions
• User stories, acceptance criteria, wireframes, technical diagramsSprint

US-FEE-04

Record a partial payment

As an accountant, I want to record a payment smaller than the invoice amount so that students can pay in stages while receivables stay accurate.

• Given the instalment 2 invoice is VND 3,000,000, when the accountant records VND 1,000,000, then the invoice changes to “Partially paid”, receivables go down by exactly VND 1,000,000 and the history shows the date and who collected it.
• Given total payments equal or exceed the invoice value, when the payment is recorded, then the invoice changes to “Paid” and no further payment can be recorded.
• Given a user with the Sales consultant role, when they open the payment recording screen, then they can only view it and there is no record button.

Module

Tuition and receivables

Rule

BR-02

Traceability

1. 1Coded requirement
2. 2User story
3. 3Test caseTesters follow the code
4. 4UAT result

Step 5: Testing and UAT by department

UAT was organised by department. Each department ran its own scenarios.

UAT checklistExcerpt from the Accounting section

• Enrolment with an unapproved 15% discount: the system blocks collectionBR-01
• Only 25% of instalment 1 collected: class allocation is blockedBR-02
• A student is deferred: receivables are frozen and Accounting receives a notificationBR-03
• Refunds are calculated on the amount after discountBR-04
• The total receivables report matches Accounting's own calculation on a sample of students

UAT often brings up a case that was never designed, for example which branch owns the receivables when a student transfers between branches:

When UAT reveals a new case

1. 1Case not yet designedstudent transfers branch
2. 2Log it as a change request
3. 3Short meeting with the departmentsagree the rule
4. 4Put it in the next sprintno rushed patch during UAT

Results

• An integrated CRM and ERP system: customers, tuition, receivables and the teaching done by teachers.
• A document set of BRD, PRD, SRS, technical diagrams and data model that serves as the reference for the Dev team.
• Departments share one source of data for receivables and teaching hours.

What I learned

• When a client says they want “software to manage everything”, the BA’s job is to find the few places where things really break.
• Designing around the lifecycle of the main entity reduces the number of modules and the disputes between departments.
• With outsourced developers, documents with traceable codes are the project’s insurance.