LÀM THẾ NÀO TIN HỌC HOÁ TOÀN BỘ CÁC XÍ NGHIỆP VIỆT NAM (phần
1)
Dương Quang Thiện
Trước tiên,
tôi muốn trình bày lại mục tiêu của vấn đề mà tôi mong muốn giúp giải quyết cho
đất nước và đã mời anh chị em tham gia đóng góp ý kiến.
Hiện giờ,
theo tính toán của tôi dựa trên các báo chí, VN có vào khoảng 500.000
xí nghiệp & cơ quan hành chính nhà nước, đã được nối mạng và được trang bị
phần cứng đầy đủ, nhưng lại không có một hệ thống thông tin (HTTT) ra hồn giúp quản
lý xí nghiệp. HTTT phần lớn không được xây dựng theo mô hình Enterprise
Resource Planning (ERP) - hoạch định nguồn lực doanh nghiệp, như ở các nước
tiên tiến. Vì sao nông nỗi thế này?.
Theo các
nước Âu Mỹ, tại các xí nghiệp nào muốn tin học hoá thì bắt buộc phải có một bộ
phận trung tâm điện toán lo việc này, và người đứng đầu của cơ quan này phải có
chức vụ phó tổng giám đốc hoặc phó giám đốc, vì ngày nay người ta quan
niệm thông tin của xí nghiệp là một tài sản quý giá, phải được khai thác một
cách chính xác, có hiệu quả. Mọi quyết định quản lý được lấy ra sẽ xuất phát từ
HTTT này. Chính điều này, các giám đốc công ty tư nhân cũng như lãnh
đạo các cơ quan hành chính nhà nước VN chưa hề ý thức, do đó anh em IT thường
than phiền là mình không được tôn trọng, nếu không nói là không được trọng vọng
như ở Âu Mỹ.
Hiện giờ,
tại các xi nghiệp tiên tiến tại các nước phát triển, người ta sử dụng mô hình
ERP để tập trung xây dựng căn cứ dữ liệu (database) cho một HTTT quản lý. Mô
hình ERP, gồm vào khoảng 7 module cốt lõi:
1) Order
Processing & Sales (OPS) - xử lý hoá đơn & bán hàng. Module
OPS này lo việc các đơn đặt hàng từ khách hàng sẽ được xử lý thành những
hoá đơn, những phiếu giao hàng, và những báo cáo bán hàng cuối kỳ;
2) Inventory
Control (IC) - Tồn kho Sản Phẩm/Vật tư. Modul IC này lo ghi nhận các giao
dịch xuất nhập tồn kho, tính giá trị từng giao dịch xuất kho để tính ra doanh
thu, cũng như tính ra các điểm ROP và EOQ để đặt mua hàng tránh cháy hàng;
3) Account
Receivable (AR) - công nợ khách hàng. Modul AR này cho biết chi tiết
nợ nần của khách hàng đối với công ty xí nghiệp. Modul AR này luôn luôn liên hệ
tự động với modul OPS, và modul IC;
4) Fixed
Assets (FA) - tài sản cố định. Modul FA này giúp kiểm kê thường xuyên
các tài sản cố định: đất đai, nhà cửa, máy móc, thiết bị, tài sản văn phòng.
Đồng thời modul FA này tính tiền khấu hao hằng tháng theo loại tài sản để đưa
vào giá thành sản phẩm;
5) Account
Payable (AP) - công nợ nhà cung cấp. Phòng cung tiêu sử dụng modul AP
này phối hợp với modul IC và Modul FA để cho ra công nợ nhà cung cấp (tài sản
cố định, vật tư, sản phẩm) mà quỹ tiền mặt & ngân hàng sẽ dùng để chuẩn bị
tiền phải thanh toán cho nhà cung cấp;
6) Cash
& Bank (CBK) - Tiền Mặt & Ngân Hàng. Modul CBK này theo dõi
tiền mặt và tiền tại những tài khoản khác nhau ở ngân hàng. Modul CBK thường
xuyên liên hệ tự động với các modul OPS, IC, AR, AP liên quan đến tiền bạc,
chuyễn ngân;
7) Payroll
(PAR) - Lao Động Tiền Lương. Modul PAR lo tính tiền lương cho nhân
viên, kể cả các phí bảo hiểm xã hội, thuế thu nhập cá nhân. Từ tiền lương này,
ta có thể tính ra giá thành sản phẩm;
8) Accounting
(ACT) - kế toán. Modul ACT là modul tổng hợp các giao dịch kế toán đến
từ các modul công năng khác. Modul ACT này sẽ tự động tạo ra các báo cáo tài
chính nhanh hơn và chính xác. Ở trên, chúng tôi bảo rằng ERP có cả thảy 7 modul
cốt lõi, nhưng ở đây chúng tôi lại liệt kê ra đến 8 modul. Thật ra, modul AR -
công nợ khách hàng và modul AP - công nợ nhà cung cấp, có thể phối hợp lại
thành một modul, vì cách xử lý giống nhau, chỉ là khác chiều.
Nói tóm lại,
về mặt quản lý xí nghiệp, tại các nước tiên tiến, người ta thống nhất mô hình
ERP, với một database tập trung cho toàn xí nghiệp. Các máy tính được nổi mạng.
Các phòng ban làm đúng công năng bình thường, thường nhật của mình qua máy
tính. Khi xong một giao dịch đặc thù của công năng của minh, thì một số giao
dịch phát sinh (by product transaction) khác sẽ hiện lên tự động nhật tu các
modul khác, mà trước đây các kế toán viên khác nhau trong xí nghiệp phải lấy
bằng tay, với những sai sót kèm theo. Thí dụ, khi bạn làm xong một hoá đơn, thì
một số giao dịch tự động nhật tu các mặt hàng được đặt mua trên modul tồn kho
IC, một giao dịch khác nhật tu công nợ khách hàng trên modul AR theo số tiền
hoá đơn, v.v..
Nhìn chung
thì HTTT viết theo mô hình ERP rất phức tạp khó viết. Tuy nhiên, trong thị
trường phần mềm, cũng có nhiều công ty cho ra phần mềm ERP, nhưng rất mắc. Mỗi
modul vào khoảng 300.000 đô (= 6 tì đồng). Phần cốt lõi (core), gồm 7
modul, cũng phải tốn vào khoảng 40 tì đồng. Việc cài đặt và đưa vào hoạt động
không dễ dàng chút nào. Nói tóm lại, phải là đại gia, như Vinamilk, hoặc Sabeco
mới kham nổi, mà chưa chắc thành công vì sự phức tạp của phần mềm. Ngoài ra,
trên thị trường phần mềm. Cũng có những phần mềm mở, gọi là openERP, giá rẽ
hơn, nhưng phải nhờ một công ty trung gian làm giùm việc customize, nghïa là
thích nghi phần mềm với tình trạng của khách hàng.
Khi sử dụng
các phần mềm ERP của các hãng Oracle, SAP, Microsoft (Dynamics), hoặc của
PeopleSoft, sự phức tạp của phần mềm không ai giải thích cho bạn. Nếu có chuyên
viên công ty phần mềm đến tư vấn giải thích, thì khi họ bỏ đi, những giải thích
trước kia của chuyên viên đối với bạn giống như nước đổ đầu vịt. Gan ruột phèo
phổi của phần mềm được viết thế nào trong nội tạng phần mềm, bạn không bao giờ
được biết. Bạn có lục tìm sách về ERP trên Amazon.com, trên thế
giới, kể cả ở đại học, bạn cũng không thấy đâu cả. Lý do rất đơn giản là các kỹ
sư tin học, lập trình viên làm việc cho các công ty phần mềm ERP kể trên họ bị
ràng buộc bởi một điều khoản là những gì họ làm là thuộc quyền sở hữu trí tuệ
của công ty. Bạn không có quyền phổ biến chi tiết, không có quyền viết sách mô
tả chi tiết về ERP v.v..
Theo nguyên
tắc, nếu có một trung tâm điện toán lo việc xử lý các dữ liệu của cơ quan/xí
nghiệp, thì nhân viên sẽ gồm nhiều thành phần, kể từ dưới lên theo trình độ
chuyên môn là: lập trình viên (programmer), phân tích viên (analyst),
phát triển viên (developper), kiến trúc sư (architect). Trong các sách tôi
viết về C# và về phân tích thiết kế HTTT, tôi thường so sánh ngành tin học cũng
giống như ngành xây dựng, nhân viên ngành này thường gồm từ dưới lên: thợ
hồ-thợ nề-thợ điện, kỹ sư xây dựng, công trình sư, và cuối cùng là kiến trúc
sư.
Các đại học
VN từ 1980 đến nay đào tạo kỹ sư tin học chỉ biết lập trình một ngôn ngữ lạc
hậu nào đó, và "nghe nói sơ sơ" về phân tích (nghĩa là chưa bao giờ
thực hành, vì số tiết dành cho phân tích rất là nhỏ nhoi so với số tiết của môn
triết lý Mác Lê & tư tưởng Hồ Chí Minh, học viên học giống kiểu cưỡi ngựa
xem hoa). Các cơ sở đào tạo tin học tư nhân, như CNIT, APTECH, FPT, .. cũng cho
ra loại người như thế, nghĩa là tương đương với thợ hồ-thợ nề-thợ điện bên xây
dựng. Với một đội ngũ như thế, thì làm sao có thể xây dựng HTTT quản lý
đúng theo ý nghĩa của nó. Với một anh thợ hồ thợ nề thì giỏi lắm bạn cũng chỉ
có thể xây một cái chòi, một cái nhà cấp 4, làm gì mà mơ xây dựng được một toà
nhà chung cư cao cấp hiện đại. Do đó, không thể trách được các lãnh đạo VN là
không tin tưởng tay nghề của các kỹ sư tin học được đào tạo ở VN. Bạn cứ xem
lại việc Intel phải trắc nghiệm bao nhiêu ngàn kỹ sư tin học VN để chỉ lấy được
một hai chục mống, rồi còn phải gởi ra ngoại quốc đào tạo lại, sau đó mới mong
sử dụng được. Intel họ có tiền, họ mới làm chuyện ấy, chứ xí nghiệp VN thì làm
gì có tiền để làm chuyện đãi cát tìm vàng. Nói một cách thô tục, là kỹ
sư tin học (KSTH) được đào tạo tại VN là không xài được. Sản phẩm hoàn
tất (end product) KSTH đầy khiếm khuyết. Có một bài báo than phiền là lương trả
cho IT rẽ như bèo, và từ 3 năm nay không ai hăm hở đăng ký tuyển sinh vào ngành
tin học. Do đó, dù lãnh đạo giáo dục VN có dự trù trong 5 năm tới sẽ đào tạo ra
1 triệu kỹ sư tin học, thì tình trạng 500.000 cơ quan/xí nghiệp ở VN đói HTTT
quản lý cũng sẽ không giải quyết được, vì sản phẩm KSTH xài không được. Tôi có cảm
tưởng lãnh đạo ngành giáo dục ở VN không biết điều này, hoặc có biết nhưng
không bận tâm.
Như đã nói
trên, ở các nước phát triển, trung tâm điện toán làm nồng cốt, thường được gọi
là lực lượng in-house, gồm 4 thành phần: lập trình viên, phân tích viên, triển
khai viên và kiến trúc sư tin học. Lập trình viên khi mới ra trường vào chức vụ
này sau 3-4 năm kinh nghiệm sẽ lên phân tích viên. Và phân tích viên cũng thế,
bò lần lên triển khai viên. Khi bạn mới vào nghề lập trình viên thì bao giờ bạn
cũng được cặp kè chỉ dẫn bởi một phân tích viên, còn phân tích viên được cặp kè
với triển khai viên. Do đó, một HTTT quản lý, sau khi được phân tích rồi được
thiết kế, và được triễn khai lần lượt sẽ qua tay 4 loại người kể trên, được
phân công rõ ràng. Còn ở VN, thì KSTH một thân một mình, không ai ở trên kèm
cặp, chả biết xoay xở ra sao, giống như gà mắc tóc. Nếu bạn vào các diễn đàn
tin học, thì bạn sẽ đọc những lời kêu cứu như sau: “các bác ơi, công ty em giao
cho em viết phần mềm tồn kho vật tư nguyên liệu. Em chả biết viết sao đây. Bác
nào giúp em với”. Ông cậu này tưởng viết phần mềm tồn kho là chỉ cần vài câu tư
vấn là xong ngay. Nói tóm lại, KSTH mới ra trường, may mắn được xí nghiệp, thì
bao giờ cũng đơn thương độc mã, không biết kêu với ai. Rốt cuộc chả làm gì
được, chỉ đem lại sự thất vọng cho người tuyển mình vào làm.
Bây giờ, bạn
xem lại ở VN, người ta làm thế nào. Các giám đốc VN họ nghĩ rằng họ chỉ cần bỏ
tiền ra mua mấy cái máy vi tính, cho nối mạng, rồi cài vài cái phần mềm Word,
Excel, và Foxpro thế là xong, rồi thuê một cậu kỹ sư tin học nào đó (có thể là
loại COCC) bảo nó viết một ứng dụng là a lê hấp chạy xong, giống như mua một
chiếc xe hơi de luxe, thuê một tên tài xế, thế là rồi việc. Phần lớn các giám
đốc cơ quan/xí nghiệp nghĩ đơn giản như thế. Ngoài ra, ở đây, người ta nghỉ
rằng máy tính xử lý dữ liệu kế toán nhanh và chính xác. Đúng thế, nếu ta nhập
và kiểm tra dữ liệu đầu vào một cách chính xác, thì các báo cáo tổng hợp đi sau
sẽ chính xác và nhanh chóng. Nhưng khổ một nỗi là ở đại học tin học, anh/chị kỹ
sư tin học không biết chi về kế toán, mù tịt về tồn kho vật tư, về công nợ
khách hàng/nhà cung cấp, về khấu hao tài sản cố định, về lao động tiền lương,
về xử lý hoá đơn, khách hàng, về qũy tiền mặt và ngân hàng, về SCM, về HR, về
CRM, về... ERP. Nếu các thầy dạy tin học ở trường không biết những điều vừa kể
trên thì làm sao học trò biết được. Do đó, lỗi là ở bộ GDĐT đã cấu trúc nội
dung môn học chả ra thể thống gì cả, chứ không phải lỗi tại các thầy. Trong
thực tế, vào cuối năm 1976, một phái đoàn các nhà toán học cầm đầu bởi nhà toán
học Phan Đình Diệu, vào Sai Gon đến gặp tôi suốt một tuần lễ, khi tôi đang là
trưởng phòng điện toán của công ty Rượu Bia (trước là công ty BGI của Pháp, nay
là Sabeco). Vì lúc ấy, người miền Nam cho tôi là "trùm điện toán",
nên người ta đến gặp tôi xin ý kiến về tin học. Tôi đã chỉ dẫn tỉ mỉ đường đi
nước bước. Nhưng, vì cho mình là "bên thắng cuộc", nên mang tiếng là
nhà khoa học, họ đã bỏ qua những lời khuyên của tôi, thuộc bên thua cuộc. Kết
quả là họ cho ra một chương trình đào tạo không ra ngô ra khoai. Ta tự làm mất
đi 20 năm (+ thêm 20 năm bị Mỹ cấm vận) để cho ra những "ổ bánh mì"
KSTH vô dụng, và ta sẽ tiếp tục làm như thế. Vừa rồi ông Nguyễn Thiện Nhân,
trong một phát biểu, đã xác nhận ít nhiều tình trạng này, khi cho rằng không có
một HTTT nào ra hồn vì chưa có công trình sư. Thật ra ông muốn nói lớp người
phân tích viên + triển khai viên + kiến trúc sư tin học, như tôi đã kể trên.
Nói tóm lại,
thì với hiện tình đội ngũ nhân viên IT như thế này, thì trong một thời
gian ngắn, không tài nào tin học hoá đươc 500.000 xí nghiệp/cơ quan đang đói
HTTT quản lý. Có chờ một triệu KSTH trong 5 năm tới cũng không thay đổi gì được
tình hình. Do đó, người ta mới nghĩ ra một cách là dùng outsourcing hoặc
dùng software as service (SaS).
Outsourcing
là gì thế? Nghĩa là nguồn lực dùng tin học hoá lấy từ ngoài xí nghiệp/cơ quan
đưa vào. Người ta outsourcing như thế này: xí nghiệp có một đội ngũ IT in-house
đã đủ việc. Bây giờ thình lình, có một ứng dụng cũ muốn được cải tiến, hoặc một
ứng dụng mới chưa từng có trước đây muốn được đưa vào. Nhưng đội ngủ IT
in-house không thể đãm đang công việc mới. Do đó, xí nghiệp kiếm một công ty
viết phần mềm X ký hợp đồng viết ứng dụng. Công ty X lo mọi việc từ đầu tới
cuối, nghĩa là phân tích, thiết kế, triển khai, v.v.. Đây được xem như là một
ứng dụng chìa khoá trao tay. Để tiết kiệm chi phí lập trình rất mắc ở Mỹ, công
ty X ký hợp đồng outsourcing với một công ty Y ở VN, lo việc lập trình mà thôi.
Như vậy, việc outsourcing có đến 2 cấp. Cấp 1 từ công ty Mỹ với công ty X, cấp
2 giữa công ty X ở Mỹ với cộng ty Y ở VN. Nói tóm lại giải pháp outsourcing chỉ
là tạm thời giải quyết "nút thắt cổ chai" của phòng IT. Tuy nhiên,
phòng IT in-house phải có người biết phân tích thiết kế và triển khai thì mới
lợi dụng được tính tiện ich của outsourcing. Còn ở VN ta, thì thế nào? Tôi chưa
nghe thấy xí nghiệp VN nào làm việc này.
Cuối cùng,
có một giải pháp tiên tiến hơn nếu bạn có kết nối với Internet. Đó là giải pháp
SaS + cloud progranmming. SaS tắt của cụm từ Software as Service, nghĩa
là một phần mềm được cung cấp cho bạn như là một dịch vụ. Bạn không mua đứt bán
đoạn hoặc trả bản quyền rắc rối. Bạn dùng phần mềm qua Internet, đơn vị tính là
giao dịch, xài bao nhiêu giao dịch thì trả bấy nhiêu tiền. Không xài, không trả.
Còn cloud programming là lập trình theo đám mây, nghĩa dữ liệu của bạn
không còn nằm trong server của bạn mà được ký thác đâu đó, xê dịch liên tục
giống như mây trời. Nghĩa là giờ đây bạn không còn cài đặt server (do đó không
còn hiện diện đội ngũ quản trị mạng, không còn lo vi rut, hacker v.v..) mà dữ
liệu giao cho ai đó nhờ giữ hộ. Bạn chỉ trả tiền theo dịch vụ phần mềm bạn thuê
sử dụng. Ở VN, cũng bắt đầu chớm nở loại hình dịch vụ SaS này, ở Bình Dương thì
phải. Theo chúng tôi, đây là một giải pháp cho tương lai. Thời gian sẽ trả lời.
Tóm lại, ta
có thể rút ra những điều ta cần để ý đến khi giải quyết vấn đề trong phần 2 kế
tiếp:
1/ - Vẫn còn đó 500.000 xí nghiệp/cơ quan chưa được tin học hoá
trong một thời gian ngắn vào khoảng từ 2 đến 3 năm phải cho xong.
2/ - Đội ngũ IT được đào tạo trong thời gian qua cũng như trong
những năm tới không thể xài được nếu tiếp tục sử dụng theo truyền thống. Một số
IT đã bỏ nghề quay ngoắt qua một nghề khác, một số lang bang không làm gì cả,
một số đầu quân vào những công ty outsourcing (như công ty TMA chẵng hạn) viết
chương trình cho nước ngoài, số còn lại vất vưởng trong các công ty không làm được
gì ra trò. Làm sao cải tạo loại IT này.
3/ - Chiều hướng tới là sử dụng mô hình ERP để tin học hoá các xí
nghiệp mà khỏi qua các công ty ERP đại gia như Oracle, SAP, PeopleSoft hoặc
Microsoft. Làm thế nào tạo những modul, dạy cho khách hàng hiểu ý nghĩa từng
modul, rồi tự học lập trình từng modul cho tới khi chạy. Làm sao đào tạo những
người trong công ty thành những lâp trình viên, phân tích viên, triển khai
viên, và kiến trúc sư, không theo một phương thức truyền thống.
Tới đây, xem
như bạn đã biết qua mặt mũi thế nào của vấn đề mà ta mong muốn giải quyết.
********************