Dự án triển khai Oracle ERP tại tập đoàn FPT được đánh giá là một trong những dự án triển khai thành công nhất trên thị trường ERP Việt Nam. Tuy nhiên con đường đến với thành công ấy không phải lúc nào cũng bằng phẳng. Loạt bài viết tổng hợp dưới đây điểm lại một số dấu mốc quan trọng trên con đường đầy gian nan ấy để DN thấy rằng triển khai ERP không phải lúc nào cũng “xuôi chèo mát mái”.

Loạt bài viết được tổng hợp từ báo nội bộ của tập đoàn FPT (chungta.vn) phản ánh giai đoạn khó khăn trong quá trình triển khai Oracle tại FPT (từ  khoảng tháng 03/2007 đến 12/2007). Với tiềm lực tài chính, kinh nghiệm trong triển khai các dự án CNTT, đặc biệt sở hữu đội ngũ triển khai ERP tinh nhuệ bậc nhất trên thị trường ERP (Công ty dịch vụ ERP FPT), thế nhưng con đường đến với thành công không hề đơn giản.

Câu chuyện thứ nhất: Quay về cái máng lợn cũ?
Hai thầy trò đang vi vu trên con Mẹc mới bỗng khựng lại, không đi tiếp được. Thầy trò cãi nhau xem không chạy được là do lái xe hay do … bản đồ chỉ vào chỗ tắc đường. Chuyện này nghe rất giống việc triển khai ERP - Oracle ở FPT.

TiếnHN cho biết để có được con số kinh doanh chính xác trong ngày, trong tuần, anh em FDC hiện đang phải bò ra mà tính toán bằng … tay; người kinh doanh và người quản lý ở FDC đang nhìn nhau với “đôi mắt mang hình viên đạn” bởi kẻ thì cho rằng mình vẫn còn hạn nợ, kẻ lại cho rằng không. Mà tất cả chỉ vì cái hệ thống ERP mới, vốn được coi là một thế mạnh của FPT.

Với hệ thống ERP mới, người FDC thực sự không biết đích xác doanh số, công nợ, hạn mức tín dụng cũng như trăm thứ bà rằn khác. Kết quả, họ mắc kẹt trong cái rừng rậm tối đen, không trăng, không sao, và quan trọng nhất là không … la bàn. TiếnHN nhăn nhó: “Nhìn cảnh anh em om sòm nhau các con số đúng sai, tôi đau lòng lắm!”

Không chỉ ông TiếnHN đau lòng. Nhiều ông khác, nhất là người kinh doanh và tài chính ở các đơn vị, họ cũng đau lòng và mệt mỏi.

Trước kia dùng Solomon, FIFA, tất cả chạy phe phé. GiangDS nhận xét: “Nghiêm túc mà nói, Solomon còn có thể đáp ứng cho FPT ít nhất cũng từ ba đến năm năm nữa.” Ấy nhưng vì chưa “xứng” nên FPT quyết định chuyển sang Oracle.

Việc chuyển đổi có vẻ suôn sẻ. Chỉ mới cách đây hai tháng, người ta hồ hởi tung hô, tưng bừng mở hội chào mừng nhà nhà hoàn thành vượt mức mọi thứ. Ban lãnh đạo FPT vội vàng thưởng to cho nhóm triển khai vì đã có thành tích lớn. FPT đã sống trong không khí thành tích mang tính cách mạng, cuộc cách mạng về công nghệ thông tin.

Thực tế thương đau! Mọi chuyện không hề suôn sẻ như đã tưởng. Với hệ thống ERP mới, các giao dịch trở nên cực kì phức tạp. Lại nữa, tốc độ quá chậm, các hoạt động nghiệp vụ kế toán diễn ra rất lờ đờ. Bộ phận kế toán đã tăng người nhưng vẫn không kịp. Một trong những người mong đợi nhiều nhất ở hệ thống ERP, GiangDS, cho biết, cái ông mong đợi đang có vấn đề rất lớn. GiangDS cho rằng nguyên nhân chính là do lỗi hệ thống, trong khi đội triển khai lại thiếu cán bộ tư vấn triển khai có kinh nghiệm và nắm vững giải pháp của Oracle. Thực tế phần lớn nhân sự của đội triển khai đều mới ra trường.

Nguyên nhân này được GiangDS quy cho việc FES đã thực hiện dự án cho khách hàng HPT và lấy đó làm kinh nghiệm để làm cho FPT; tiếc rằng HPT có quy mô nhỏ hơn FPT rất nhiều. Một vài người trong ngành công nghệ thông tin cho rằng ERP là lĩnh vực “cực kỳ xương xẩu”, đòi hỏi phải có nhiều kinh nghiệm thực tế. Chẳng biết đúng sai nhưng họ chỉ ra rằng FPT đã từng chào thua dự án triển khai ERP cho Co-opmark và siêu thị này đã phải mời Cisco vào làm với giá 5 M USD. Vậy, có lẽ nào hệ thống kế toán FPT đã trở thành “chuột bạch”?

Trên cuộc họp giao ban, các phòng ban kêu eo éo. Họ chỉ ra tốc độ chậm và tính không ổn định của hệ thống, sự không ăn khớp của các báo cáo và tính xác thực của những con số. Lãnh đạo vò đầu bứt tai, rốt cục vẫn không rõ chuyện gì đang xảy ra. Người thì đổ cho lái xe, kẻ thì cho là tại bản đồ, có kẻ đổ cho cả lái xe lẫn bản đồ, hệt như trong câu chuyện nọ.

Phản ứng một cách gay gắt với những lời kêu ca của người sử dụng, đại diện cho cả bên lắp đặt, triển khai ERP lẫn bên sử dụng là FPT, ông Bùi Quang Ngọc, PTGĐ FPT, nói rằng: “Bên A có lỗi, bên B có lỗi. Nhưng bên B có lỗi nhiều hơn”. Tuy nhiên, ông Ngọc đã không chỉ ra lỗi cụ thể của bên B, nhất là phần…”nhiều hơn” kia là gì. Cái ông phàn nàn nhất là việc các đơn vị đã không…chạy thử nghiệm.

Việc không chạy thử nghiệm bị quy cho thiếu thời gian? Kẻ ác mồm thì cho rằng FPT có bệnh … “thành tích”. Cuối năm ngoái, mọi nhà, mọi nơi đã chẳng hồ hởi và tưng bừng thông báo việc chuyển đổi đã hoàn tất trước mọi thời hạn đó sao?!

Vấn đề giờ đây không phải là lôi là “ông” nào ra, thu lại tiền thưởng hay quy lỗi hay tìm một con tốt. Vấn đề là hệ thống quản lý phải có, phải tốt, nếu không thì mọi chuyện sẽ rối tung. Cái xảy nó nảy cái ung; vạn sự rắc rối có thể sẽ bắt đầu từ đây, gây đình đốn kinh doanh, mất đoàn kết nội bộ.

GiangDS cho biết hiện tại, giải pháp quan trọng được đưa ra là chuyển dự án sang tay cao thủ Thanh Hà, vốn được coi là chuyên gia chữa cháy và cứu các dự án bên bờ vực thất bại, điều chuyên gia Oracle của FPT về tham gia dự án và nếu sau 15/4/2007 mà hệ thống này không có cải thiện thì sẽ quay lại dùng Solomon.

Thời gian tới đó chẳng còn nhiều. Việc quay về cái máng lợn cũ xem ra cũng chẳng còn xa xôi.

Câu chuyện thứ hai: Giải cứu binh nhì Oracle
Chỉ còn hơn một tháng nữa, FPT sẽ kết thúc một năm tài khóa và chưa bao giờ vấn đề về phần mềm Oracle được đặt ra gấp gáp, khốc liệt như hiện nay.
Tối hậu thư của TGĐ FPT BìnhTG tại Hội nghị Chiến lược (HNCL) khá rõ ràng: “Một tháng phải giải quyết xong vấn đề Oracle”.

Nhóm giải cứu Oracle gấp rút vào cuộc tuy việc giải cứu “binh nhì” Oracle trong thời gian một tháng được nhiều người coi như một “nhiệm vụ bất khả thi”.
Hai cuộc họp khẩn đã được tiến hành ngay sau tối hậu thư. Một cuộc họp vào chiều tối ngay sau khi kết thúc HNCL FPT 2007, ngày 04/11, và một cuộc họp vào sáng ngày 10/11. Biểu hiện “bệnh” của Oracle được nhóm tổng hợp và nêu rõ: chậm, chập chờn - lúc sống, lúc chết.

“Nguyên nhân sơ bộ của bệnh ‘chậm’ được ghi nhận chủ yếu do hệ thống Oracle của FPT là dữ liệu tập trung tại Hà Nội trong khi có rất nhiều người sử dụng trên toàn quốc, mỗi ngày có khoảng 200 người đồng thời nối vào. Mặc khác, khi triển khai hệ thống này, FPT đã chỉnh sửa lại nhiều lần, đặc biệt là hệ thống báo cáo so với hệ thống chuẩn của Oracle. Điều này dẫn đến trong quá trình thao tác liên quan đến tìm dữ liệu, lên báo cáo có nhiều cái bất hợp lý, gây ra chậm trong quá trình xử lý hoá đơn chứng từ và báo cáo”, TriềuDD, PTGĐ FPT IS, Trưởng nhóm cứu Oracle giải thích.

Đối với bệnh “tậm tịt” — lúc thì Oracle chạy tốt, lúc lại lăn đùng ra chết “không lời báo trước”, anh Triều cho rằng đó là do “nhiều báo cáo của FPT rất dài, thậm chí có báo cáo dài đến 80 trang với những yêu cầu khác nhau”. Điều này cũng là một phần gây ra … cái chết cho hệ thống.

Cũng theo anh Triều, Oracle trên thế giới có hệ thống báo cáo chuẩn riêng nhưng FPT chưa bao giờ sử dụng hệ thống báo cáo chuẩn này. Thực tế, FPT phát triển những báo cáo theo đòi hỏi riêng của mình và rất có thể đây là lý do tại sao phần mềm Oracle chạy tốt ở nhiều quốc gia nhưng lại gặp trục trặc tại FPT.
Hiện nhóm giải cứu đưa ra phương án yêu cầu so sánh biểu mẫu báo cáo của FPT với báo cáo chuẩn của hệ thống Oracle. Trong trường hợp báo cáo của FPT có vấn đề, sẽ chuyển sang sử dụng báo cáo của Oracle.

Một nguyên nhân khác cũng không loại trừ là có thể một phần cứng nào đó của hệ thống bị hỏng.
Lộ trình xử lý trục trặc của Oracle cũng đã được nhóm giải cứu phác thảo theo một lộ trình khá rõ ràng.

Theo anh TriềuDD, từ ngày 12/11, FPT sẽ thuê hai nhóm chuyên gia rà soát toàn bộ hệ thống để tìm ra đúng bệnh của Oracle. Nhóm 1, bao gồm các chuyên gia Oracle, sẽ ngồi từ xa đăng nhập (off-side), đánh giá các tham số, kiểm tra cấu hình, máy chủ, dữ liệu và “review” lại các báo cáo của FPT. Nhóm 2, bao gồm các chuyên gia Việt Nam đã từng cứu các dự án Oracle cho Vinamilk và Viettel, sẽ sang tận nơi để chẩn bệnh cho hệ thống Oracle của FPT.
Hai nhóm này sẽ làm việc độc lập trong 10 ngày để xem xét lại tổng thể cả hệ thống.

Đối với nội bộ FPT, nhóm giải cứu sẽ có những yêu cầu nhất định đối với người sử dụng: Những gì không ưu tiên sẽ phải giảm bớt, những cái gì không hợp lý, không cần thiết sẽ được loại bỏ để tập trung vào những yêu cầu chính.
Mặt khác, nhóm sẽ tổ chức hướng dẫn lại thao tác chuẩn khi sử dụng Oracle cho những nhân viên thường xuyên sử dụng chương trình này. “Thậm chí, có thể dùng các biện pháp nghiệp vụ phần mềm để buộc người sử dụng phải tuân thủ một số hạn chế nhất định trong giai đoạn này, ví dụ như hệ thống waiting chỗ khi chạy báo cáo…”, anh LộcNV, PTGĐ FDC, thành viên nhóm giải cứu, cho biết thêm.

Cứu hệ thống Oracle trong vòng một tháng không phải là việc đơn giản. Kết luận “chẩn bệnh” cuối cùng vẫn phải chờ sau vài ngày nữa khi hai nhóm chuyên gia rà soát xong hệ thống. “Lúc đó, chúng ta mới biết cụ thể sẽ chữa Oracle như thế nào”, anh TriềuDD cho biết.

Thực tế, các quản trị viên đang rất lo ngại trước tình hình hiện tại của hệ thống Oracle khi chỉ còn hơn một tháng nữa là hết năm 2007, thời điểm đỉnh cao đòi hỏi báo cáo, hoá đơn, chứng từ.

Anh TriềuDD cũng cho biết một phương án “back up” đã được tính đến. Theo kế hoạch, nếu đến 31/12, hệ thống Oracle vẫn tậm tịt, FPT sẽ có hai phương án: (i) cài nhiều bản Oracle cho từng công ty thành viên, theo dạng phân tán hoá, không tập trung hóa nữa; (ii) quay về với hệ thống Solomon cũ.

Tất cả các tình huống đều đã được đội dự án đặt ra, đảm bảo trong mọi trường hợp, hệ thống phần mềm của FPT có thể hoạt động sau từ 24-48h.

Với “Giải cứu Binh nhì Ryan” của Steven Spielberg, cứu được Ryan tức là cứu lấy niềm hy vọng cuối cùng của một bà mẹ, và trên tất cả là cứu lấy danh dự của một quốc gia.
Với FPT, giải cứu thành công Oracle cũng chính là cứu lấy danh dự của một công ty công nghệ hàng đầu Việt Nam.

Câu chuyện thứ 3: Sống sót!
Đã có thể khẳng định, FPT sẽ không phải quay về với hệ thống Solomon như “tối hậu thư” của TGĐ Tưương Gia bình.

Trước đây một tháng, TGĐ BìnhTG đã ra tối hậu thư”: Hoặc sửa xong Oracle trong vòng một tháng hoặc quay lại với Solomon. Đúng một tháng sau, “binh nhì” Oracle dường như đã được giải thoát thành công.

“Hệ thống Oracle đã chạy khá ổn định và phục vụ tốt công việc hàng ngày, kể cả thời gian đóng sổ tháng 11. Tốc độ cải thiện hơn tháng trước rất nhiều!”, LộcNV, Phó ban Kế hoạch- Tài chính FPT và là thành viên nhóm cứu Oracle, hồ hởi cho biết.

Theo anh Lộc, trong thời gian đóng sổ vừa qua, hệ thống có chậm hơn ngày thường nhưng hoàn toàn không ảnh hưởng tới các giao dịch hàng ngày. Thời gian xuất một hoá đơn với 10 dòng hàng mất khoảng từ 4-8 phút, tùy theo kỹ năng của người sử dụng.

Tuy nhiên, anh Lộc cũng không phủ nhận một sự thật là hệ thống Oracle hiện “vẫn còn rất nhiều nguy cơ gây chậm, hay tê liệt tạm thời”.

Thực tế, từ 05/11 đến 10/12, hệ thống đã chạy chậm khoảng 15 lần và 3 lần “chết”. Giải thích về nguyên nhân bệnh chậm này, anh LộcNV nói: “Hệ thống chậm là do báo cáo nặng, chạy nhiều. Đội kỹ thuật khi cài đặt đã thiết kế các báo cáo không tốt, không tính được ‘ngưỡng’ chịu đựng của hệ thống nên báo cáo nào dài vài chục trang là hệ thống sẽ … ỳ ra”.

Ý thức người sử dụng cũng là một nguyên nhân không nhỏ khiến hệ thống hoạt động chậm. “Nhiều người chỉ cần xem dữ liệu một tháng nhưng vẫn hoành tráng in hẳn dữ liệu cả năm”, anh Lộc ví dụ.

Hai phần ba số lần hệ thống “chết” cục bộ cũng được xác định nguyên nhân là do hệ thống máy chủ dự phòng đặt tại FPT Distribution gây ra.

Hai nhóm chuyên gia, một nhóm chuyên gia Việt Nam và một nhóm chuyên gia Oracle của công ty OSSI (Ấn Độ) đã bắt bệnh hệ thống Oracle của FPT và kết luận sơ bộ:

i) hệ thống báo cáo của FPT đa số dùng báo cáo customize, nhiều báo cáo quá lớn về mặt dữ liệu nên cần phải xem xét lại;
(ii) hệ thống dữ liệu (database) của FPT đang dùng là bản Oracle 9.2.0.6 nên không đảm bảo và cần phải nâng cấp lên 9.2.0.8 hoặc 10G;
(iii) FPT thiết lập hệ thống máy chủ dự phòng chưa tốt.

Anh Lộc cho biết, để giảm tải cho hệ thống Oracle, thời gian qua, tập đoàn đã tách xong toàn bộ các báo cáo doanh số, công nợ và một phần báo cáo hàng tồn sang hệ thống MIS. “Hiện có trung bình 1,700 - 1,800 lượt khai thác hệ thống MIS mỗi ngày. Tuy các báo cáo chuyển sang này đáp ứng được nhu cầu của người sử dụng nhưng nó chưa thực sự ổn định về giải pháp công nghệ. Điều này sẽ được khắc phục trước khi đóng sổ tháng 12/2007″, anh Lộc khẳng định.

“Mặt khác, Tập đoàn sẽ giám sát chặt việc sử dụng báo cáo của các đơn vị, như yêu cầu chỉ khai thác đúng nhu cầu để tiết kiệm tài nguyên hệ thống”.

“Chúng tôi cũng đã tiến hành cập nhật một số bản vá lỗi của Oracle, thay đổi một vài thông số hệ thống. Kết quả ban đầu ghi nhận được rất khả quan”, anh Lộc vui vẻ nhận định.

Hiện hệ thống Oracle đã qua giai đoạn khắc phục khẩn cấp và chuyển sang giai đoạn hoàn thiện và nâng cao hiệu suất sử dụng.

Theo anh Lộc, từ giờ đến cuối năm, để khắc phục những “bệnh” của Oracle, nhóm giải cứu sẽ cùng các đội tư vấn xử lý những vấn đề còn tồn tại.

“Chúng tôi sẽ tách hệ thống tác nghiệp ‘online’ hàng ngày ra khỏi hệ thống báo cáo, nhất là những báo cáo nặng, báo cáo đối soát số liệu. Sau khi kết thúc một năm tài chính sẽ chuyển dữ liệu sang ‘database offline’, đảm bảo phục vụ công tác kiểm toán và không gây ảnh hưởng đến giao dịch tiếp tục của năm sau”, anh Lộc nói về hướng xử lý.

Sứ mệnh giải cứu Oracle đã đi đến chặng cuối, sau gần một năm hoạt động không ra gì với vài lần “giải cứu”. Có lẽ, tối hậu thư của TGĐ là phương cách phù hợp với những tồn tại “mãi không giải quyết được”.

(http://eac.vn - Lê Hưng tổng hợp)