Kinh nghiệm triển khai Odoo ERP trên Ubuntu Server & VMware

Giới thiệu

Tôi bắt đầu làm việc với Odoo ERP từ tháng 6/2018, thời điểm Odoo đã là một trong những nền tảng ERP mã nguồn mở đáng chú ý dành cho doanh nghiệp.

Trong quá trình triển khai và vận hành thực tế, tôi đã làm việc với nhiều phiên bản như Odoo 8, 9, 10 và 12 Community, phục vụ hệ thống có hơn 100 người dùng thuộc nhiều phòng ban khác nhau.

Điểm đặc biệt trong quá trình này là tôi không chỉ quản trị Odoo ở cấp độ ứng dụng, mà trực tiếp xây dựng gần như toàn bộ nền tảng phía dưới:

VMware ESXi → Ubuntu Server → PostgreSQL → Odoo → Nginx → SSL/HTTPS → Firewall → Backup

Hệ thống ban đầu được triển khai trên hạ tầng VMware ESXi nội bộ, sau đó từng bước chuyển lên môi trường Cloud.

Qua nhiều năm vận hành, Odoo giúp tôi có một góc nhìn khá thực tế về ERP: cài đặt được một hệ thống ERP không phải là phần khó nhất; làm sao để hệ thống vận hành ổn định và phù hợp với quy trình của từng phòng ban mới thực sự là vấn đề quan trọng.

1. Vì sao tôi lựa chọn Odoo?

Một trong những lý do lớn nhất khiến tôi lựa chọn Odoo là:

Open Source – linh hoạt – chi phí triển khai hợp lý – có khả năng tùy biến theo nhu cầu doanh nghiệp.

Thay vì phải đầu tư ngay một khoản chi phí lớn cho bản quyền ERP, với Odoo Community, doanh nghiệp có thể bắt đầu từ những module thực sự cần thiết.

Chi phí chủ yếu tập trung vào:

Hạ tầng Server.
Nhân sự triển khai.
Customization.
Module bên thứ ba nếu cần.
Vận hành và bảo trì hệ thống.

Đây là hướng tiếp cận khá phù hợp đối với doanh nghiệp muốn từng bước số hóa và tự động hóa quy trình nhưng vẫn muốn kiểm soát chi phí.

Mục tiêu ban đầu của hệ thống tôi triển khai là quản lý tập trung các hoạt động như:

Quản lý công việc.
Quản lý dự án.
CRM cho Phòng Kinh doanh.
Quản lý kho.
Quản lý sản xuất.
Website.
Helpdesk/Ticket Support.

Trong đó, Project Management là module được sử dụng nhiều nhất.

2. Hạ tầng Odoo ban đầu: VMware + Ubuntu Server

Ở giai đoạn đầu, tôi triển khai Odoo dưới dạng máy ảo trên:

VMware ESXi 5.5 / ESXi 6.0

Kiến trúc cơ bản:

Physical Server

↓

VMware ESXi

↓

Ubuntu Server VM

↓

PostgreSQL

↓

Odoo Community

↓

Nginx Reverse Proxy

↓

HTTPS / Firewall / Internet

Tùy từng phiên bản Odoo, tôi sử dụng phiên bản Ubuntu Server, PostgreSQL và Python tương thích tương ứng.

Odoo được cài trực tiếp trên Ubuntu Server (native installation) thay vì Docker.

Sau này tôi có thử nghiệm Odoo chạy bằng Docker, kể cả triển khai thử trên NAS. Docker thuận tiện hơn khá nhiều trong việc đóng gói môi trường và hạn chế các vấn đề dependency, tuy nhiên khi triển khai production, người quản trị vẫn cần hiểu rõ các thành phần bên trong thay vì xem container như một “black box”.

3. Tự triển khai toàn bộ hệ thống

Trong quá trình xây dựng Odoo, tôi trực tiếp thực hiện hầu hết các công việc liên quan đến hạ tầng và hệ thống:

Tạo VM trên VMware.
Cài đặt Ubuntu Server.
Cấu hình Network, IP và DNS.
Cài đặt PostgreSQL.
Cài đặt Odoo Community.
Cấu hình Odoo.
Cấu hình Nginx Reverse Proxy.
Cài đặt SSL/HTTPS.
Cấu hình Firewall.
Quản lý Domain/DNS.
Cài đặt module.
Quản lý User và phân quyền.
Backup Database.
Backup Filestore.
Backup toàn bộ VM.
Restore hệ thống khi xảy ra sự cố.
Theo dõi log và xử lý lỗi dịch vụ.

Nhờ trực tiếp triển khai từ lớp hạ tầng đến ứng dụng nên khi hệ thống gặp vấn đề, tôi có thể kiểm tra xuyên suốt từ:

Network → Linux → PostgreSQL → Odoo Service → Module → Nginx → Client

Điều này đặc biệt hữu ích đối với ERP vì một lỗi người dùng nhìn thấy trên giao diện chưa chắc nguyên nhân nằm ở Odoo.

4. Bảo mật truy cập Odoo

Đối với hệ thống ERP, tôi không muốn đưa toàn bộ dịch vụ ra Internet mà không có kiểm soát.

Nguyên tắc tôi áp dụng là:

Trong LAN: người dùng nội bộ có thể truy cập đầy đủ theo quyền được cấp.

Ngoài Internet: chỉ những IP được cho phép mới có thể truy cập hệ thống.

Ngoài ra hệ thống sử dụng:

Nginx Reverse Proxy.
HTTPS.
Cloudflare.
Firewall.
DNS.
Kiểm soát quyền truy cập người dùng.

Việc xác thực người dùng cũng có thể được tích hợp với LDAP/Active Directory, giúp doanh nghiệp quản lý tài khoản tập trung thay vì phải duy trì nhiều bộ username/password riêng biệt.

5. Những module Odoo tôi đã vận hành

Trong thực tế, tôi đã làm việc với nhiều module khác nhau, bao gồm:

Project

Đây là module được sử dụng nhiều nhất trong hệ thống.

Project giúp quản lý:

Dự án.
Công việc.
Task.
Người phụ trách.
Tiến độ.
Phối hợp giữa các bộ phận.

CRM

CRM được sử dụng phục vụ Phòng Kinh doanh, quản lý tập trung các thông tin và hoạt động liên quan đến khách hàng.

Inventory

Quản lý kho là một trong những thành phần quan trọng khi ERP được mở rộng sang hoạt động sản xuất.

Manufacturing / MRP

Odoo có khả năng kết nối quy trình kho với sản xuất, giúp dữ liệu không còn nằm riêng lẻ ở từng bộ phận.

Website

Website cũng có thể được tích hợp trực tiếp vào hệ sinh thái Odoo.

Helpdesk / Ticket Support

Hệ thống Ticket giúp tiếp nhận và theo dõi các yêu cầu hỗ trợ thay cho việc xử lý rời rạc qua email hoặc trao đổi trực tiếp.

Ngoài module chuẩn, trong quá trình sử dụng tôi cũng triển khai module bên thứ ba và các module được customize riêng theo yêu cầu thực tế.

6. Công việc của người quản trị Odoo

Sau khi ERP đi vào hoạt động, công việc không dừng lại ở việc “Server đang chạy”.

Người quản trị cần thường xuyên thực hiện:

Quản lý user.
Phân quyền.
Quản lý PostgreSQL.
Theo dõi dung lượng.
Kiểm tra log.
Theo dõi Odoo Service.
Restart service khi cần.
Update hệ thống.
Quản lý module.
Backup.
Kiểm tra khả năng restore.
Xử lý lỗi cho người dùng.
Hướng dẫn IT Support hỗ trợ người dùng.

Theo kinh nghiệm của tôi, một ERP có thể hoạt động tốt về mặt kỹ thuật nhưng vẫn thất bại nếu quy trình vận hành giữa các phòng ban không được quản lý chặt chẽ.

7. Backup Odoo: Database thôi chưa đủ

Đây là một trong những kinh nghiệm tôi đánh giá rất quan trọng.

Tôi thực hiện backup Odoo theo nhiều lớp:

Odoo Backup

PostgreSQL Database

Odoo Filestore

Backup toàn bộ VM

Dữ liệu backup được đưa sang hệ thống lưu trữ khác như:

NAS.
Google Workspace/Cloud Storage phù hợp với chính sách lưu trữ của doanh nghiệp.

Backup được thực hiện hằng ngày.

Tôi cũng đã thực hiện restore Odoo trong thực tế. Khi phiên bản Odoo và cấu trúc dữ liệu tương thích, việc phục hồi nhìn chung có thể kiểm soát được.

Một nguyên tắc tôi luôn chú ý:

Không nên lưu bản backup duy nhất trên chính Server đang chạy Odoo.

Nếu Server hoặc Storage gặp sự cố thì production và backup có thể mất cùng lúc.

8. Những lỗi Odoo tôi từng gặp trong thực tế

Qua nhiều năm vận hành, tôi gặp khá nhiều vấn đề khác nhau.

Odoo Service không khởi động

Nguyên nhân có thể liên quan đến:

Cấu hình Odoo.
Python.
Dependency.
Module.
PostgreSQL.
Permission.

Log của Odoo và Linux Service là nơi đầu tiên cần kiểm tra.

Python không tương thích

Các phiên bản Odoo cũ phụ thuộc khá chặt vào phiên bản Python và các thư viện đi kèm.

Nếu cài sai phiên bản dependency, Odoo có thể không khởi động hoặc module không hoạt động.

PostgreSQL

Một số vấn đề tôi từng gặp:

Odoo không kết nối được Database.
Sai quyền PostgreSQL.
Database restore không thành công.
Không tương thích khi migration.

Module không tương thích

Đây là vấn đề khá phổ biến khi hệ thống có nhiều customization.

Một module có thể hoạt động tốt ở phiên bản Odoo hiện tại nhưng không còn chạy được khi chuyển sang phiên bản mới.

Nghiêm trọng hơn là:

Custom Module → lỗi dependency → Odoo Service crash → toàn bộ hệ thống không hoạt động.

Khi đó phải kiểm tra log, xác định module gây lỗi và xử lý ở mức source code/database nếu cần.

9. Customization – sức mạnh nhưng cũng là rủi ro

Customization là một trong những ưu điểm lớn nhất của Odoo.

Doanh nghiệp có thể thay đổi hệ thống để phù hợp với quy trình thực tế thay vì ép doanh nghiệp phải thay đổi hoàn toàn theo phần mềm.

Nhưng customization cũng tạo ra một vấn đề:

Customize càng sâu thì việc nâng cấp phiên bản càng khó.

Tôi từng gặp các tình huống:

Custom module không chạy trên Odoo mới.
Xung đột giữa module custom và module core.
Field thay đổi sau update.
Permission bị thay đổi.
API custom thiếu kiểm soát quyền.
Module làm Odoo không thể khởi động.

Vì vậy nếu triển khai lại, tôi sẽ hạn chế can thiệp trực tiếp vào core và yêu cầu các customization phải được thiết kế theo chuẩn module của Odoo.

10. Khó khăn lớn nhất: Upgrade và Migration

Đây là điểm tôi gặp khó khăn nhất trong quá trình vận hành Odoo Community.

Việc nâng cấp từ một phiên bản Odoo cũ đã customize nhiều sang phiên bản mới không đơn giản như update một ứng dụng thông thường.

Không thể chỉ:

Cài Odoo mới → Restore Database cũ → chạy tiếp.

Schema database, module, Python dependency, PostgreSQL và đặc biệt là custom code có thể đã thay đổi.

Tôi từng gặp tình huống database phiên bản cũ không thể đơn giản import vào môi trường Odoo mới, đặc biệt khi hệ thống đã được customize.

Vì vậy, theo kinh nghiệm của tôi:

Migration Odoo cần được xem như một dự án riêng, không nên xem là một thao tác update Server.

Đây cũng là lý do tôi ưu tiên tính ổn định của hệ thống đang hoạt động hơn việc chạy theo phiên bản mới nhất.

11. Từ VMware lên Cloud

Hạ tầng Odoo ban đầu của tôi được xây dựng trên VMware ESXi 5.5/6.0.

Sau này hệ thống được chuyển dần sang môi trường Cloud, bao gồm:

Google Cloud.
Amazon Web Services (AWS).

Việc chuyển lên Cloud giúp giảm sự phụ thuộc vào Server vật lý tại chỗ, nhưng nguyên tắc quản trị Odoo cơ bản vẫn không thay đổi:

Hạ tầng ổn định + Database an toàn + Backup tốt + Security + kiểm soát customization.

Cloud không tự động giải quyết các vấn đề về ERP nếu quy trình ứng dụng và dữ liệu không được quản trị tốt.

12. Nếu xây dựng Odoo ERP lại từ đầu hiện nay

Nếu doanh nghiệp có nhu cầu xây dựng một hệ thống ERP mới, tôi hoàn toàn có thể lựa chọn Odoo một lần nữa.

Và thực tế, tôi rất thích việc xây dựng một hệ thống mới từ đầu vì có thể chủ động thiết kế kiến trúc, bảo mật, backup và quy trình vận hành ngay từ ban đầu.

Nền tảng

Tôi sẽ ưu tiên:

Odoo Community phiên bản phù hợp và còn được duy trì

Ubuntu Server LTS

PostgreSQL

Docker

Nginx Reverse Proxy

HTTPS

Hạ tầng có thể chạy trên:

VMware ESXi.
Proxmox VE.
Cloud.

Docker là lựa chọn tôi muốn sử dụng nhiều hơn so với trước đây vì giúp quản lý dependency và triển khai môi trường thuận tiện hơn.

Tuy nhiên tôi vẫn muốn control được toàn bộ Odoo, PostgreSQL, volume, log và backup, thay vì chỉ biết cách start/stop container.

13. Backup nếu triển khai mới

Tôi vẫn giữ nguyên nguyên tắc backup nhiều lớp:

Database + Filestore + Application/Configuration + VM/Container + Off-site Backup

Backup có thể được đưa về:

NAS.
Google Workspace/Cloud Storage.
OneDrive.
Một vị trí off-site khác.

Điều quan trọng không phải chỉ là:

“Backup Successful”

mà phải trả lời được câu hỏi:

“Khi Server chết hoàn toàn, có restore được ERP hay không?”

14. Odoo + QR Code + truy xuất nguồn gốc

Nếu triển khai ERP cho doanh nghiệp sản xuất hiện nay, một hướng tôi đặc biệt quan tâm là kết hợp:

Odoo ERP + Inventory + Manufacturing + QR/Barcode + API

Dữ liệu từ ERP có thể liên kết với hệ thống truy xuất nguồn gốc thông qua API.

Ví dụ một kiến trúc có thể phát triển:

Nguyên liệu

↓

Kho

↓

Sản xuất

↓

Thành phẩm

↓

Odoo ERP

↓

QR Code / Barcode

↓

API

↓

Hệ thống truy xuất nguồn gốc

Trong trường hợp phù hợp, có thể nghiên cứu tích hợp với VeriGoods hoặc các nền tảng truy xuất nguồn gốc khác thông qua API.

Đây là hướng tôi đánh giá có giá trị đối với doanh nghiệp sản xuất khi ERP không chỉ dùng để nhập liệu mà trở thành nguồn dữ liệu trung tâm của quá trình chuyển đổi số.

15. Odoo có phù hợp với doanh nghiệp Việt Nam?

Theo trải nghiệm của tôi, có.

Một số điểm tôi đánh giá cao:

Open Source.
Có Community Edition.
Khả năng Việt hóa tốt.
Nhiều module.
Có cộng đồng phát triển lớn.
Có thể customize.
Có thể tích hợp API.
Có khả năng mở rộng từ Project/CRM đến Kho và Sản xuất.
Không bắt buộc doanh nghiệp phải đầu tư lớn ngay từ đầu.

Điểm tôi chưa thực sự thích là giao diện ở các phiên bản tôi từng sử dụng chưa phải lúc nào cũng đẹp và trực quan, đặc biệt với người dùng mới.

Khó khăn lớn hơn là upgrade khi hệ thống đã customize nhiều.

Vì vậy, Odoo Community có thể tiết kiệm đáng kể chi phí license, nhưng điều đó không có nghĩa ERP sẽ hoàn toàn “miễn phí”.

Doanh nghiệp vẫn cần đầu tư vào:

Hạ tầng + triển khai + customization + đào tạo + vận hành + backup + bảo mật.

16. Kinh nghiệm quan trọng nhất sau nhiều năm vận hành Odoo

Sau thời gian dài làm việc với Odoo, điều tôi quan tâm nhất không còn là câu hỏi:

“Cài Odoo như thế nào?”

Mà là:

“Làm sao để Odoo thực sự trở thành một phần trong quy trình vận hành của doanh nghiệp?”

Mỗi phòng ban có quy trình khác nhau.

Project khác CRM.

CRM khác Inventory.

Inventory lại liên quan Manufacturing.

Vì vậy người quản trị cần giám sát chặt chẽ cách vận hành của từng module dựa trên quy trình thực tế của từng phòng ban.

Nếu dữ liệu đầu vào không chính xác hoặc người dùng không tuân thủ quy trình, ERP dù tốt đến đâu cũng không thể tạo ra dữ liệu quản trị đáng tin cậy.

Kết luận

Tôi bắt đầu với Odoo từ năm 2018, trải qua nhiều phiên bản Community và trực tiếp xây dựng hệ thống từ VMware, Ubuntu Server, PostgreSQL đến Odoo, Nginx, SSL, Firewall và Backup.

Quá trình đó giúp tôi nhận ra rằng giá trị lớn nhất của ERP không nằm ở việc có bao nhiêu module.

Giá trị thực sự nằm ở khả năng:

Tập trung dữ liệu → Chuẩn hóa quy trình → Kết nối các phòng ban → Tự động hóa → Tạo dữ liệu phục vụ quản trị.

Nếu có một dự án ERP mới, Odoo Community vẫn là một trong những nền tảng tôi sẵn sàng lựa chọn.

Đặc biệt trong giai đoạn hiện nay, tôi cho rằng ERP có thể tiến thêm một bước nữa:

ERP + API + QR/Traceability + Cloud + AI

Khi đó ERP không còn đơn thuần là phần mềm quản lý nội bộ, mà có thể trở thành nền tảng dữ liệu trung tâm phục vụ quá trình chuyển đổi số của doanh nghiệp.