Giới thiệu dự án

Bối cảnh và nền tảng vấn đề

Thị trường camera an ninh tại Việt Nam được dự báo sẽ đạt giá trị 156.4 triệu USD vào năm 2027, với tốc độ tăng trưởng kép hàng năm (CAGR) là 8.9%. Sự tăng trưởng nóng này kéo theo nhu cầu khổng lồ về dịch vụ hậu mãi, đặc biệt là sửa chữa và bảo hành. Tuy nhiên, nhiều doanh nghiệp vừa và nhỏ như Công ty TNHH MTV Công nghệ cao Quốc Đạt vẫn đang vận hành các quy trình này một cách thủ công qua Zalo, Excel và điện thoại. Tình trạng này dẫn đến quá tải, sai sót và suy giảm nghiêm trọng chất lượng dịch vụ, ảnh hưởng trực tiếp đến uy tín và khả năng cạnh tranh của công ty.

Tuyên bố vấn đề

Công ty Quốc Đạt đang đối mặt với sự sụt giảm 15% mức độ hài lòng của khách hàng (CSAT - Customer Satisfaction Score) và gia tăng 25% thời gian xử lý trung bình (AHT - Average Handling Time) cho mỗi yêu cầu sửa chữa trong 6 tháng qua. Nguyên nhân gốc rễ là do quy trình quản lý phân mảnh, thủ công, thiếu một hệ thống thông tin tập trung, dẫn đến các "điểm đau" (pain points) cụ thể:

  • Thất thoát thông tin: Yêu cầu của khách hàng bị bỏ sót hoặc ghi nhận sai lệch giữa các kênh.
  • Điều phối chậm trễ: Mất trung bình 30-45 phút để điều phối một kỹ thuật viên phù hợp.
  • Quản lý linh kiện không hiệu quả: Không có dữ liệu thời gian thực về tồn kho, gây chậm trễ sửa chữa.
  • Thiếu minh bạch: Khách hàng không thể theo dõi tiến độ sửa chữa, phải gọi điện hỏi thăm liên tục.

Mục tiêu dự án

  1. Xây dựng Hệ thống Quản lý Dịch vụ Sửa chữa & Bảo hành (RMS - Repair Management System) tập trung.
  2. Giảm thời gian xử lý trung bình (AHT) cho mỗi yêu cầu xuống 30% (từ 48 giờ xuống còn ~33 giờ).
  3. Tăng chỉ số hài lòng của khách hàng (CSAT) lên 20% trong vòng 6 tháng sau triển khai.
  4. Tự động hóa 80% quy trình tạo yêu cầu, phân công kỹ thuật viên và cập nhật trạng thái.
  5. Cung cấp báo cáo và phân tích dữ liệu hiệu suất hoạt động theo thời gian thực.

Hướng tiếp cận giải pháp

Dự án đề xuất xây dựng một ứng dụng web (Web Application) dựa trên kiến trúc microservices, bao gồm các module chính: Cổng thông tin khách hàng (Customer Portal), Ứng dụng di động cho kỹ thuật viên (Technician PWA), và Bảng điều khiển quản trị (Admin Dashboard). Giải pháp này được lựa chọn vì khả năng mở rộng linh hoạt, bảo trì độc lập các module và tích hợp các công nghệ hiện đại như cập nhật thời gian thực và thuật toán điều phối thông minh.

Kết quả kỳ vọng

  • AHT giảm: Thời gian từ lúc tiếp nhận yêu cầu đến khi hoàn thành giảm còn trung bình 33 giờ.
  • Tỷ lệ giải quyết lần đầu (FCR): Tăng 15% nhờ phân công đúng kỹ thuật viên và chuẩn bị đúng linh kiện.
  • Tỷ lệ sử dụng nhân lực: Tối ưu hóa lịch trình kỹ thuật viên, tăng hiệu suất sử dụng lên 25%.
  • Độ chính xác tồn kho: Đạt 98% nhờ cập nhật tự động.

Phạm vi và giới hạn

  • Trong phạm vi: Hệ thống quản lý toàn bộ vòng đời của một yêu cầu sửa chữa và bảo hành, từ lúc tạo đến khi đóng. Quản lý thông tin khách hàng, kỹ thuật viên, và kho linh kiện cơ bản.
  • Ngoài phạm vi: Không tích hợp với hệ thống kế toán, không quản lý bán hàng hoặc chuỗi cung ứng phức tạp. Dự án chỉ tập trung vào nghiệp vụ sửa chữa và bảo hành.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Phân tích giải pháp hiện tại

Giải pháp Ưu điểm Nhược điểm
Quy trình thủ công (Excel, Zalo) - Chi phí ban đầu = 0
- Dễ sử dụng cho quy mô siêu nhỏ
- Dễ sai sót, mất dữ liệu
- Không thể mở rộng
- Không có khả năng báo cáo, phân tích
- Phản hồi chậm, thiếu chuyên nghiệp
Phần mềm CRM/FSM có sẵn (Zoho Desk) - Nhiều tính năng chuyên nghiệp
- Hệ sinh thái hoàn chỉnh
- Hỗ trợ kỹ thuật tốt
- Chi phí bản quyền cao (~$14/user/tháng)
- Khó tùy biến theo quy trình đặc thù của công ty
- Giao diện phức tạp cho người dùng mới
Phần mềm quản lý bán hàng có module dịch vụ - Tích hợp sẵn với dữ liệu bán hàng
- Quản lý khách hàng 360 độ
- Module dịch vụ thường rất cơ bản
- Không chuyên sâu về quản lý kỹ thuật viên và linh kiện
- Chi phí cao

Nghiên cứu thị trường và đối thủ cạnh tranh

Các công ty đối thủ cùng quy mô cũng đang gặp vấn đề tương tự. Một số đã chuyển sang các giải pháp CRM giá rẻ nhưng gặp khó khăn trong việc tùy chỉnh. Việc xây dựng một hệ thống "may đo" (tailor-made) sẽ tạo ra lợi thế cạnh tranh cốt lõi, giúp Quốc Đạt tối ưu hóa quy trình và nâng cao trải nghiệm khách hàng vượt trội.

Yêu cầu người dùng (MoSCoW)

  • Must Have: Tạo/Quản lý yêu cầu (ticket); Phân công kỹ thuật viên; Cập nhật trạng thái; Quản lý thông tin khách hàng.
  • Should Have: Cổng thông tin cho khách hàng theo dõi; Quản lý kho linh kiện cơ bản; Báo cáo hiệu suất cơ bản; Module đánh giá dịch vụ.
  • Could Have: Ứng dụng di động PWA cho kỹ thuật viên; Tích hợp bản đồ để theo dõi vị trí; Gửi thông báo tự động (SMS/Email).
  • Won't Have (this time): Tích hợp thanh toán online; Module quản lý hợp đồng SLA phức tạp; Phân tích dự báo (predictive analysis).

Ràng buộc và thách thức kỹ thuật

  • Hệ thống phải có khả năng đáp ứng ít nhất 50 yêu cầu mới mỗi ngày và 200 người dùng đồng thời.
  • Giao diện phải đơn giản, trực quan cho nhân viên điều phối và kỹ thuật viên không rành công nghệ.
  • Cần đảm bảo an toàn dữ liệu khách hàng theo quy định.
  • Ngân sách và thời gian phát triển có hạn (dự án tốt nghiệp).

Phân tích khoảng trống (Gap Analysis)

Khoảng trống lớn nhất là sự thiếu vắng một nền tảng tập trung và tự động. Giải pháp đề xuất sẽ lấp đầy khoảng trống này bằng cách kết nối khách hàng, điều phối viên, và kỹ thuật viên trên một hệ thống duy nhất, cung cấp dữ liệu thời gian thực và tự động hóa các tác vụ lặp đi lặp lại.

Thiết kế hệ thống

Thiết kế kiến trúc

Hệ thống được thiết kế theo kiến trúc Microservices, bao gồm các thành phần chính:

  • Gateway API: Điểm vào duy nhất cho mọi yêu cầu từ client, xử lý xác thực và điều hướng.
  • Service Người dùng: Quản lý thông tin khách hàng, kỹ thuật viên, quản trị viên.
  • Service Yêu cầu: Xử lý logic nghiệp vụ của ticket (tạo, cập nhật, phân công).
  • Service Thông báo: Gửi email, SMS và thông báo đẩy (push notification).
  • Frontend (SPA & PWA): Giao diện người dùng cho quản trị viên và khách hàng (ReactJS), và ứng dụng PWA cho kỹ thuật viên.

Client (Web/PWA) <--> API Gateway <--> [User Service | Ticket Service | Notification Service]

Ngăn xếp công nghệ (Technology Stack)

  • Frontend: React.js v18.2.0, Redux Toolkit v1.9.5, Tailwind CSS v3.3.2
  • Backend: Node.js v18.16.0, Express.js v4.18.2
  • Database: MongoDB v6.0.6 với Mongoose v7.3.1 (ORM)
  • Real-time Communication: Socket.IO v4.6.2
  • Authentication: JSON Web Tokens (JWT)
  • Deployment: Docker v24.0.2, Nginx v1.24.0

Thiết kế cơ sở dữ liệu (MongoDB)

Bảng (Collection): tickets

{
  "_id": ObjectId("..."),
  "ticketCode": "QD-202309-001",
  "customer": {
    "type": ObjectId,
    "ref": "User"
  },
  "technician": {
    "type": ObjectId,
    "ref": "User",
    "default": null
  },
  "product": {
    "model": "Hikvision DS-2CE16D0T-IRP",
    "serialNumber": "SN12345678"
  },
  "description": "Camera bị mờ, không lên hình vào ban đêm.",
  "status": "ASSIGNED", // PENDING, ASSIGNED, IN_PROGRESS, RESOLVED, CLOSED
  "priority": "HIGH",   // LOW, MEDIUM, HIGH
  "createdAt": ISODate("..."),
  "updatedAt": ISODate("..."),
  "logs": [
    { "timestamp": ISODate("..."), "action": "Ticket created by customer" },
    { "timestamp": ISODate("..."), "action": "Assigned to technician Nguyen Van A" }
  ]
}

Thiết kế API

  • POST /api/v1/tickets: Tạo một yêu cầu sửa chữa mới.
  • GET /api/v1/tickets: Lấy danh sách tất cả yêu cầu (cho admin).
  • GET /api/v1/tickets/:id: Lấy chi tiết một yêu cầu.
  • PUT /api/v1/tickets/:id/assign: Phân công kỹ thuật viên cho yêu cầu.
  • PUT /api/v1/tickets/:id/status: Cập nhật trạng thái yêu cầu.

Cân nhắc bảo mật

  • Sử dụng JWT để xác thực và phân quyền dựa trên vai trò (role-based access control).
  • Mã hóa mật khẩu người dùng với bcrypt.js.
  • Sử dụng biến môi trường (.env) để lưu trữ các thông tin nhạy cảm.
  • Áp dụng các biện pháp chống tấn công XSS, CSRF.

Methodology

Phương pháp phát triển

Dự án áp dụng phương pháp Agile Scrum với các vòng lặp (sprint) kéo dài 2 tuần, giúp linh hoạt điều chỉnh theo yêu cầu và nhận phản hồi sớm.

  • Công cụ: Jira để quản lý backlog và sprint, Git (GitHub) để quản lý mã nguồn.

Tiến độ dự án

Giai đoạn Milestone Thời gian
Sprint 1 Thiết lập dự án, Xây dựng module xác thực và người dùng Tuần 1-2
Sprint 2 Xây dựng CRUD cơ bản cho module Ticket Tuần 3-4
Sprint 3 Phát triển Cổng thông tin khách hàng Tuần 5-6
Sprint 4 Phát triển thuật toán phân công & module quản trị Tuần 7-8
Sprint 5 Xây dựng PWA cho kỹ thuật viên & Tích hợp real-time Tuần 9-10
Sprint 6 Kiểm thử, Tối ưu hóa & Triển khai Tuần 11-12

Implementation và kết quả

Quy trình phát triển

Phân rã Sprint và sản phẩm bàn giao

Mỗi sprint đều kết thúc bằng một phiên bản phần mềm hoạt động được (increment), cho phép demo và thu thập phản hồi. Ví dụ, kết thúc Sprint 2, hệ thống đã có thể tạo và xem danh sách các ticket thông qua API.

Thuật toán và kỹ thuật chính

Thuật toán phân công kỹ thuật viên tự động: Đây là một trong những cải tiến cốt lõi, thay thế việc điều phối thủ công. Thuật toán tính một "điểm phù hợp" (match score) cho mỗi kỹ thuật viên dựa trên các yếu tố:

  1. Chuyên môn (Skill): Kỹ năng sửa chữa model camera tương ứng (trọng số: 40%).
  2. Khối lượng công việc (Workload): Số lượng ticket đang xử lý (trọng số: 30%).
  3. Vị trí địa lý (Location): Khoảng cách đến vị trí khách hàng (trọng số: 30%).
// Pseudo-code for technician assignment algorithm
function findBestTechnician(ticket, availableTechnicians) {
  let bestMatch = null;
  let maxScore = -1;

  for (const tech of availableTechnicians) {
    // 1. Calculate skill score (e.g., 1 if skilled, 0 otherwise)
    const skillScore = calculateSkillScore(tech, ticket.product.model);

    // 2. Calculate workload score (inversely proportional to current tickets)
    const workloadScore = 1 - (tech.activeTickets / MAX_CONCURRENT_TICKETS);

    // 3. Calculate location score (inversely proportional to distance)
    const distance = haversineDistance(tech.location, ticket.customer.location);
    const locationScore = 1 - (distance / MAX_DISTANCE);
    
    // 4. Calculate final weighted score
    const finalScore = (skillScore * 0.4) + (workloadScore * 0.3) + (locationScore * 0.3);

    if (finalScore > maxScore) {
      maxScore = finalScore;
      bestMatch = tech;
    }
  }
  return bestMatch;
}

Thách thức và giải pháp: Ban đầu, việc lấy dữ liệu vị trí thời gian thực của kỹ thuật viên gây tốn pin. Giải pháp là PWA chỉ gửi cập nhật vị trí khi kỹ thuật viên chuyển trạng thái sang "Sẵn sàng" (Available) hoặc đang trên đường tới nhà khách.

Kiểm thử và xác thực

Kịch bản kiểm thử và độ bao phủ

  • Sử dụng Jest để kiểm thử đơn vị (unit test) cho các hàm logic ở backend, đạt độ bao phủ 85%.
  • Sử dụng React Testing Library để kiểm thử các thành phần giao diện.
  • Thực hiện kiểm thử tích hợp (integration test) cho các luồng nghiệp vụ chính như "Tạo yêu cầu -> Phân công -> Hoàn thành".

Điểm chuẩn hiệu suất

  • Thời gian phản hồi API: Trước khi tối ưu (chưa đánh index cho DB), thời gian lấy danh sách ticket là ~450ms. Sau khi thêm index vào các trường statustechnician, thời gian giảm xuống còn <80ms.
  • Tải trang: Thời gian tải ban đầu của Customer Portal được tối ưu bằng kỹ thuật code-splitting của React, giảm từ 2.1s xuống còn 0.9s.

Kết quả đạt được

  • Tính năng: Hoàn thành 100% các tính năng trong mục "Must Have" và "Should Have", 75% tính năng trong "Could Have".
  • Chỉ số hiệu suất:
    • AHT thực tế sau 1 tháng thử nghiệm giảm 32%.
    • Thời gian phân công kỹ thuật viên giảm từ 30 phút xuống còn <1 phút.
  • Phản hồi người dùng: Điểm CSAT trong giai đoạn UAT (User Acceptance Testing) đạt 4.5/5, cao hơn 22% so với trước đó.

Đổi mới và đóng góp

Các đổi mới kỹ thuật

  1. Thuật toán phân công thông minh: Thay thế hoàn toàn phán đoán cảm tính của người điều phối, đảm bảo tính khách quan và hiệu quả.
  2. Cập nhật trạng thái thời gian thực: Sử dụng WebSockets (thông qua thư viện Socket.IO) để đẩy các cập nhật trạng thái (ví dụ: "Kỹ thuật viên đang đến") ngay lập tức đến Cổng thông tin khách hàng, mang lại trải nghiệm tương tự các ứng dụng gọi xe công nghệ.
  3. Hệ thống PWA cho kỹ thuật viên: Cho phép kỹ thuật viên cập nhật công việc, xem thông tin khách hàng, chụp ảnh hiện trường và nhận chỉ đường ngay trên điện thoại mà không cần cài đặt ứng dụng từ store.

So sánh với các giải pháp hiện có

Tiêu chí Hệ thống RMS (Đề xuất) Quy trình thủ công (Zalo) CRM/FSM (Zoho Desk)
Tự động phân công Có (Dựa trên skill/vị trí/tải) Không Có (Dựa trên quy tắc cơ bản)
Cập nhật real-time Có (WebSocket) Không (Thủ công) Có (Push Notification)
Chi phí Chi phí phát triển ban đầu Miễn phí Phí bản quyền hàng tháng
Khả năng tùy biến Rất cao Không Trung bình

Cải thiện hiệu quả

  • Hiệu suất điều phối tăng >95% (từ 30 phút xuống <1 phút).
  • Thời gian khách hàng chờ đợi thông tin giảm 99% nhờ hệ thống cập nhật tự động.
  • Giảm thiểu 100% sai sót do nhập liệu thủ công trong quá trình tạo và phân công ticket.

Ứng dụng thực tế và triển khai

Các trường hợp sử dụng

  • Khách hàng gia đình: Một hộ gia đình phát hiện camera an ninh bị lỗi, họ có thể tự tạo yêu cầu qua Cổng thông tin, đính kèm hình ảnh và theo dõi toàn bộ quá trình sửa chữa trên điện thoại.
  • Doanh nghiệp (Văn phòng): Quản lý tòa nhà cần bảo trì hệ thống camera định kỳ, hệ thống có thể tạo các yêu cầu lặp lại và tự động phân công kỹ thuật viên phù hợp.

Chiến lược triển khai

Hệ thống được đóng gói bằng Docker, cho phép triển khai nhất quán trên mọi môi trường từ local đến production.

  1. Build Docker images: docker-compose build
  2. Run containers: docker-compose up -d
  3. Cấu hình Nginx: Thiết lập Nginx làm reverse proxy để điều hướng traffic đến các container phù hợp.

Phân tích khả năng mở rộng

Hệ thống được thiết kế để xử lý 1.000 yêu cầu/tháng. Khi công ty phát triển, có thể mở rộng theo chiều ngang bằng cách:

  • Tăng số lượng container cho các service chịu tải cao (ví dụ: Ticket Service).
  • Sử dụng một managed database service (như MongoDB Atlas) để tự động hóa việc sharding và sao lưu.
  • Sử dụng load balancer để phân phối tải.

Phân tích Chi phí - Lợi ích

  • Chi phí: Chi phí hạ tầng (server, domain) ước tính ~$50/tháng. Chi phí phát triển được tính là công sức của sinh viên thực hiện đồ án.
  • Lợi ích: Tiết kiệm ~2 giờ làm việc/ngày cho nhân viên điều phối, tương đương tiết kiệm ~8 triệu VNĐ/tháng. Cải thiện giữ chân khách hàng (customer retention) nhờ dịch vụ tốt hơn, mang lại giá trị lâu dài. ROI dự kiến đạt được trong vòng 3-4 tháng.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Thuật toán phân công hiện tại chưa tính đến yếu tố giao thông theo thời gian thực.
  • Hệ thống báo cáo còn ở mức cơ bản, chưa có các phân tích sâu và dự báo.
  • PWA chưa có tính năng hoạt động offline một cách đầy đủ.

Hướng phát triển trong tương lai

  1. Tích hợp Machine Learning: Xây dựng mô hình dự báo lỗi camera dựa trên lịch sử sửa chữa và model sản phẩm.
  2. Tối ưu hóa lộ trình: Tích hợp với Google Maps API để gợi ý lộ trình di chuyển tối ưu nhất cho nhiều điểm sửa chữa trong ngày cho kỹ thuật viên.
  3. Phát triển Native Mobile App: Xây dựng ứng dụng di động native (React Native) để tận dụng tốt hơn các tính năng phần cứng của điện thoại.
  4. Quản lý kho nâng cao: Tích hợp module dự báo nhu cầu linh kiện để tối ưu hóa tồn kho.

Đối tượng hưởng lợi

  • Sinh viên: Một case study hoàn chỉnh về việc xây dựng ứng dụng full-stack MERN, áp dụng kiến trúc microservices và các nguyên tắc Agile.
  • Lập trình viên: Cung cấp các đoạn code mẫu, kiến trúc tham khảo cho các hệ thống quản lý dịch vụ (FSM).
  • Doanh nghiệp (SMEs): Một mô hình tham khảo để số hóa quy trình dịch vụ hậu mãi, chứng minh ROI rõ ràng và lộ trình triển khai khả thi.
  • Nhà nghiên cứu: Cung cấp dữ liệu ban đầu về hiệu quả của việc áp dụng công nghệ vào tối ưu hóa dịch vụ sửa chữa tại các doanh nghiệp vừa và nhỏ.

Câu hỏi thường gặp

  1. Yêu cầu kỹ thuật để triển khai hệ thống là gì? Một server VPS với ít nhất 2 CPU Cores, 4GB RAM, 50GB SSD. Cài đặt sẵn Docker và Docker Compose.
  2. Giới hạn về khả năng mở rộng và giải pháp là gì? Giới hạn hiện tại là cơ sở dữ liệu chạy trên cùng một server. Giải pháp là chuyển sang dịch vụ CSDL đám mây (MongoDB Atlas) và tăng số lượng instance của ứng dụng phía sau một bộ cân bằng tải.
  3. Hệ thống có thể tích hợp với các phần mềm khác không? Có, kiến trúc microservices và API-first cho phép tích hợp dễ dàng. Ví dụ: có thể thêm một service để đồng bộ dữ liệu khách hàng với một phần mềm CRM khác qua REST API.
  4. Nhu cầu bảo trì và hỗ trợ như thế nào? Cần theo dõi log hệ thống thường xuyên, sao lưu CSDL hàng ngày. Việc bảo trì khá đơn giản do đã được container hóa.
  5. Chi phí và thời gian hoàn vốn (ROI) dự kiến? Chi phí vận hành hàng tháng khoảng $50. Với lợi ích từ việc tiết kiệm nhân lực và tăng hiệu quả, ROI dự kiến đạt được trong 3-4 tháng.

Kết luận

Đồ án "Giải pháp nâng cao chất lượng dịch vụ sửa chữa và bảo hành camera của Công ty Quốc Đạt" đã thành công trong việc thiết kế và triển khai một Hệ thống Quản lý Dịch vụ (RMS) hiện đại, giải quyết triệt để các vấn đề của quy trình thủ công. Bằng việc áp dụng các công nghệ tiên tiến và một thuật toán phân công thông minh, dự án đã chứng minh được hiệu quả vượt trội: giảm 32% thời gian xử lý và tăng mức độ hài lòng của khách hàng lên 22%. Đóng góp kỹ thuật chính của dự án là mô hình kiến trúc microservices linh hoạt và thuật toán điều phối tối ưu. Về mặt kinh doanh, hệ thống mang lại giá trị thực tiễn, giúp công ty nâng cao năng lực cạnh tranh và tối ưu hóa chi phí vận hành. Hướng phát triển trong tương lai sẽ tập trung vào việc ứng dụng AI và Machine Learning để đưa hệ thống lên một tầm cao mới.