Phần I: Đã đến lúc cần chuyên môn hoá sản xuất và triển khai ERP
Theo Gartner, tạp chí nghiên cứu hàng đầu về CNTT, tỷ lệ thành công của các dự án CNTT trên
thế giới đạt chưa đến 20%, một con số đáng thất vọng. Trong kỳ suy thoái kinh tế toàn cầu hiện
tại, nhiều công ty đã rà soát lại và phát hiện ra nhiều phần mềm (PM) chưa được khai thác thực
sự, một số PM khác thì không thể tích hợp được với nhau, kết quả chung là bộ phận tin học cứ
phình ra và tiêu tốn ngân sách, trong khi năng suất lao động chung không tăng lên bao nhiêu. Một
chuyện vui là các công ty tin học đáp ứng lại vấn đề này bằng cách thuyết phục khách hàng mua
thêm một PM khác có tác dụng tích hợp các PM hiện có của khách hàng, các hệ thống này được
gọi là "enterprise-wide application integration system" (EAIS) và bán khá chạy. Thế là để giảm độ
phức tạp do có quá nhiều PM, giải pháp lại là mua thêm một PM nữa!
Sự thất bại của các dự án CNTT một phần do khách hàng mua hệ thống không đáp ứng nhu cầu,
nhưng phần lớn hơn là do sai sót trong triển khai dẫn đến hệ thống mới không đi vào công việc
của doanh nghiệp. Vì vậy, bên cạnh việc phát triển các hệ thống ERP, người ta cũng đầu tư
nghiên cứu triển khai ERP. Loạt bài này giúp bạn đọc hiểu được phần nào về những cơ sở lý
thuyết triển khai ERP và kinh nghiệm áp dụng tại Việt Nam.
Các chủ thể liên quan đến việc triển khai ERP
o Nhà cung cấp hệ thống (software vendor): là người tạo ra sản phẩm ERP, ví dụ Oracle, Exact,
SAP... Để cho gọn trong bài này ta sẽ gọi là Hãng PM.
o Nhà bán lẻ với dịch vụ gia tăng (Value Added Reseller - VAR): đây là hệ thống phân phối cho
Hãng PM. Những đơn vị này trực tiếp phát triển thị trường và bán sản phẩm (ERP). Thông thường
họ làm luôn việc nghiên cứu yêu cầu, tình trạng thực tế của khách hàng và tư vấn về ERP, cũng
như tư vấn về lộ trình mua và triển khai, tức là cung cấp các dịch vụ gia tăng cho khách hàng.
o Nhà tư vấn triển khai (Implementer): Đây là người trực tiếp triển khai ERP cho khách hàng. Họ
cũng thường là những người cung cấp dịch vụ hỗ trợ sau triển khai. Vì vậy, trong suốt quá trình
triển khai và hỗ trợ khách hàng thường chỉ làm việc với nhà tư vấn triển khai. Đa số các nhà tư
vấn triển khai đều có quan hệ chặt chẽ vỡi Hãng PM và được cập nhật thường xuyên về những
thay đổi trong sản phẩm, và họ cũng thường phải vượt qua các kỳ kiểm tra thường xuyên và ngặt
nghèo của Hãng PM.
Nhà tư vấn triển khai cũng sẽ gặp vấn đề nếu như VAR đưa cho khách hàng một hệ thống không
phù hợp, ngược lại VAR không thể tư vấn cho khách hàng mà không hiểu cặn kẽ về hệ thống định
giới thiệu, tức là có kiến thức tư vấn triển khai. Vì mối tương tác như vậy nên trong đa số trường
hợp nhà tư vấn triển khai cũng chính là VAR, triển khai cho khách hàng các hệ thống mà họ tư
vấn. Do lý do này, khái niệm VAR chỉ chung cho VAR kiêm Nhà tư vấn triển khai.
Điểm khác biệt căn bản giữa VAR và Hãng PM hệ thống: Hãng PM là công ty tin học với lực lượng
đa số là các chuyên viên lập trình và kỹ sư hệ thống, VAR lại thường xuất xứ từ các đơn vị tư vấn
quản trị. VAR không cần biết PM được tạo ra như thế nào, dùng nền tảng hay ngôn ngữ gì, mà chỉ
cần biết doanh nghiệp cần chu trình nghiệp vụ nào để giới thiệu cho họ hệ thống ERP thích hợp,
và giúp họ sử dụng được hệ thống mới này. Tóm lại, một chuyên viên của VAR cần 50% kiến thức
ERP và 50% về nghiệp vụ quản lý. Công việc của VAR cũng giống như một kiến trúc sư không cần
biết cách làm ra viên gạch hay cánh cửa, nhưng rất giỏi trong việc ghép những vật liệu đó lại phù
hợp với yêu cầu sử dụng và túi tiền của khách hàng.
Những VAR uy tín trên thế giới có tiểu sử về tư vấn quản lý rất mạnh. Một số được tạo ra từ
những hãng kiểm toán hàng đầu, như Accenture (Mỹ) được tách ra từ hãng Andersen Worldwide;
Cap Gemini Ernst & Young từ sự hợp nhất của bộ phận tư vấn của Ernst & Young và công ty tư
vấn tin học hàng đầu châu Âu Cap Gemini; IBM Consulting từ sự hợp nhất bộ phận tư vấn của
IBM và bộ phận tư vấn của hãng kiểm toán PriceWaterhouseCoopers v.v... Tại Việt Nam, các
VAR này chưa chính thức hiện diện, mặc dù các hãng kiểm toán sinh ra chúng như KPMG/Arthur
Andersen, Ernst & Young, PriceWaterhouseCoopers đều đã có mặt từ lâu.
Các VAR lớn này được chia ra nhiều bộ phận, mỗi bộ phận phụ trách một hệ thống ERP. Ngoài ra
còn có nhiều VAR nhỏ hơn chuyên chú vào một hệ thống ERP như Magnus của Hà Lan chỉ
chuyên làm SAP (hãng này hiện đại diện độc quyền cho phần mềm SAP tại Việt Nam dưới tên
Team Synergia).
Chuyên môn hóa hãng PM và VAR - Xu hướng của Thế Giới
Trước kia, các Hãng PM thường tự bán và triển khai PM cho khách hàng, nhiều khi còn cạnh tranh
với các VAR của chính họ. Gần đây, xu hướng chuyên môn hoá đã thắng thế, các Hãng PM đã
hoàn toàn dựa vào VAR để bám sát và đưa ra các giải pháp phù hợp cho khách hàng. Cách phân
công công việc này giúp Hãng PM tập trung phát triển sản phẩm mà không phải lo lắng triển khai
cho vô vàn khách hàng với những yêu cầu rất khác nhau, trải trên diện rộng (xuyên quốc gia) luôn
cần trợ giúp kỹ thuật khi có sự cố. Họ giao việc này cho các VAR trên khắp thế giới hiện đang rất
gần khách hàng, hiểu khách hàng. Ngược lại, VAR không cần đầu tư phát triển ERP mà vẫn có
giải pháp cung cấp cho khách hàng và thu phí từ các dịch vụ tư vấn lựa chọn, triển khai, đào tạo,
trợ giúp và tất nhiên là một khoản hoa hồng bán PM do Hãng PM trả. Hãng PM nghe ý kiến từ các
VAR, nhờ VAR thử nghiệm trước khi phát triển thêm các tính năng và tung sản phẩm ra thị trường.
Mối quan hệ cộng sinh này rất khăng khít và là nền tảng phát triển ERP hiện đại.
Hiện một số doanh nghiệp PM đã cố gắng phổ cập sản phẩm của mình cho người dùng cuối như
tổ chức các khoá học thường xuyên cấp chứng chỉ, hoặc đưa PM vào dạy trong một số trường
ĐH, cao đẳng... Tuy nhiên, cách tiếp cận này chỉ thích hợp với các PM đại trà như MS Office hoặc
các PM kế toán nhỏ. Với những PM phức tạp như ERP với nhiều phân hệ và công cụ đikèm, cách
làm này sẽ mang tính cưỡi ngựa xem hoa, người học xong không đủ kiến thức để doanh nghiệp
có thể tự lựa chọn triển khai sản phẩm được (thường các hãng nước ngoài đều cần hàng năm với
nhiều chương trình huấn luyện chuyên sâu để đào tạo ra một chuyên gia có thể đem PM đi triển
khai cho khách hàng). Nên chăng thay vì đào tạo mà tập trung đầu tư xây dựng một hệ thống VAR
với tính chuyên nghiệp cao và lợi ích lâu dài.
Khó khăn chính, theo chúng tôi, nếu doanh nghiệp PM Việt Nam đi theo hướng này là phải chuẩn
hoá được tài liệu huấn luyện, triển khai cũng như các chu trình nghiệp vụ trong sản phẩm và
chuyển giao được những kiến thức này cho các đối tác VAR, cũng như xây dựng được quan hệ
làm việc hai chiều giữa các VAR và Hãng PM.ÿ
Việt Nam hiện còn tụt hậu quá xa trong tổ chức, phân phối và triển khai ERP. Số lượng các nhà
sản xuất trong nước và nhập khẩu cộng lại hiện cũng đã đưa ra được sự lựa chọn nhất định cho
nhiều đối tượng khách hàng khác nhau với giá từ vài ngàn đến vài triệu USD (xem TGVT - PCW B
số tháng 11/2003). Tuy nhiên, chưa hãng phần mềm ERP nào xây dựng được một hệ thống VAR
mạnh và chuyên nghiệp. Các hãng PM của ta thiên về "tự sản tự tiêu", một nửa công ty cặm cụi
phát triển PM cho nửa kia ngược xuôi đem bán và trợ giúp khách hàng; hãng PM nước ngoài thì e
dè chưa tin tưởng công ty Việt Nam có thể làm VAR và vẫn dựa chính vào các đối tác VAR truyền
thống, chỉ tác động được vào một khoảng hẹp các khách hàng có vốn đầu tư nước ngoài.
Quan hệ hãng PM/VAR phát triển chậm đối với các hãng PM Việt Nam do thị trường nhỏ, khách
hàng chưa nhiều, mối lo mất bản quyền, thiếu quy trình triển khai chuẩn hoá để có thể chuyển giao
lại cho VAR... Đối với các hãng PM nước ngoài, sự lo lắng về chất lượng dịch vụ do VAR địa
phương cung cấp và chưa xem trọng mảng doanh nghiệp trong nước là những nguyên nhân chủ
yếu.
Tình hình phân phối, triền khai ERP tại Việt Nam
Do thiếu vắng mạng lưới VAR, các doanh nghiệp PM (ERP) Việt Nam chỉ có thể phục vụ khách
hàng trong một phạm vi hẹp, ví dụ như Lạc Việt có thể được biết đến trong TP. HCM và các tỉnh
phía Nam nhưng gần như vắng bóng tại các tỉnh phía Bắc. Kết quả là những khách hàng lớn có
cơ sở ở cả hai miền sẽ không chọn mua PM Việt Nam vì chỉ được hỗ trợ tại một đầu, dù trong một
số trường hợp có thể họ chấp nhận được PM nội địa. Việc phát triển chi nhánh lại tốn kém mà gần
như chưa có hãng PM ERP nào làm được một cách hiệu quả, và như đã nói, khi lượng khách
hàng lớn đến mức độ nhất định, hãng PM sẽ không đủ khả năng quy tụ được các chuyên gia tin
học và quản trị để tổ chức quản lý, phát triển sản phẩm, tư vấn và triển khai sản phẩm. Nếu các
hãng PM ERP nước ngoài đã không cùng lúc phát triển và quản lý được hai loại nguồn lực rất
khác nhau này, thì có lẽ các hãng PM ERP của Việt Nam cũng nên suy nghĩ về vấn đề có tính
chiến lược này
Phân phối và triển khai ERP - Phần 3: Cách giải quyết bài toán giá
thành trong ERP
Để có thể áp dụng phân hệ sản xuất của ERP tiêu chuẩn vào tính giá thành, những doanh nghiệp
(DN) đang sử dụng phương pháp tính chi phí thực cần chuyển sang phương pháp tính giá thành
định mức (Standard Cost- SC).
Phần lớn doanh nghiệp của ta mới làm được một việc gọi là 'tập hợp giá thành', tức là tổng kết từ
phòng kế toán các khoản đầu vào trước đó đã được định khoản vào các tài khoản giá thành, cộng
với một số phân bổ của chi phí gián tiếp (như lương văn phòng, chi phí tiếp thị v.v…). Theo cách
này, sẽ không thể tính toán được giá thành của từng đơn vị sản phẩm ngay trong tháng và nhìn
chung phòng kế toán thường bị trễ nhiều tuần hoặc hàng tháng so với thực tế dưới phân xưởng
dẫn đến việc báo cáo thường đi sau, không thể giúp ban giám đốc có được báo cáo giá thành tức
thời để đưa ra ngay được chính sách giá, cũng như các lượng định về nguồn tiền (để mua nguyên
vật liệu - NVL) có thể cần cho các tháng tới.
Các phần mềm ERP hiện đại đều thể hiện một tư tưởng khác về quản lý và hoạch định giá thành,
đó là quản lý theo giá thành định mức . Đây là phương pháp tính giá thành tiêu chuẩn mà mọi hệ
thống ERP của nước ngoài từ lớn như SAP, Oracle tới các hệ thống nhỏ hơn như Accpac,
Solomon, Exact đều sử dụng. Các phần mềm ERP nội địa cũng đang cố gắng đi theo con đường
này, vì vậy các nhà quản lý doanh nghiệp cần hiểu bản chất của cách quản lý giá thành này để có
thể tạo được tiếng nói chung với các nhà sản xuất hệ thống ERP và vận dụng được tối đa ích lợi
của ERP.
Căn bản về phương pháp giá thành định mức (SC)
Về mặt lý thuyết, phương pháp này khá dễ hiểu và đã được dạy từ lâu trong các chương trình kế
toán quản trị. Theo phương pháp này, giá thành của một đơn vị sản phẩm được phân nhỏ xuống
giá thành của các cấu phần (NVL, nhân công, quản lý phí …) tạo nên sản phẩm đó. Ví dụ công ty
X bán các ghế được lắp ráp từ 4 cái chân với giá mua vào là 500 đồng một chiếc, một cái mặt ghế
giá 5.000 đồng, một cái tựa có giá 4.000 đồng, một số đinh ốc giá 300 đồng, một phần năm công
lao động với giá 30.000 đồng/công, cộng với phí gián tiếp (điện nước, khấu hao, quản lý phí) là
300 đồng, thì SC của chiếc ghế sẽ là 17.600 đồng theo như bảng tính dưới đây:
Giá thành định mức 17.600 này sau đó sẽ được sử dụng trong báo cáo trước khi phòng kế toán có
thể thu thập được các dữ liệu thực tế. Ví dụ vào ngày 29/2/2004 phòng kế toán của công ty X từ
báo cáo của bộ phận kho biết rằng họ đã bán được 1.000 cái ghế thì ngay hôm đó họ đã làm được
báo cáo chi phí giá thành phân xưởng cho giám đốc là 17.600.000 đồng, không cần chờ đến khi
thu thập được các số liệu thực tế về nguyên liệu thực xuất từ kho hoặc lương thực trả cho công
nhân. Có thể thấy ngay, báo cáo chi phí lợi nhuận của từng tháng luôn có thể đưa ra ngay trong
tháng đó. Ngoài ra, việc lập kế hoạch tài chính cũng rất thuận lợi, vì dựa trên con số ước tính về
lượng hàng bán ra từng tháng là doanh nghiệp đã có thể lên được ước tính về luồng tiền mặt cũng
như các ước tính về khoản phải thu, kế hoạch đặt NVL…
Nhưng chúng ta cũng thấy nếu làm theo cách này thì sẽ nảy sinh một số vấn đề:
- Giá thành các cấu phần có thể thay đổi, chi phí cho tháng sau có thể không thật chính xác.
- Cũng vì lý do trên tổng giá thành trên thực tế cuối cùng sẽ chênh với tổng giá thành định mức,
làm cho sổ kế toán không khớp.
- Có một số định mức khó tính toán ví dụ như định lượng của một lớp sơn trên bề mặt sản phẩm.
- Các cấu phần tạo nên sản phẩm có thể lại là bán thành phẩm từ một dây chuyền khác chứ không
đơn giản như ví dụ nêu trên, làm cho việc tính giá thành đơn vị trở thành khá phức tạp
Người ta đã giải quyết các vấn đề trên như sau:
- Dựa trên thực tế về độ dao động của giá và chính sách trong công ty để đưa ra một khoảng thời
gian thích hợp cho việc điều chỉnh SC. Ví dụ một công ty đa quốc gia lớn như Castrol với một mặt
hàng tương đối ổn định là dầu nhớt sẽ điều chỉnh SC của mặt hàng này mỗi năm một lần, trong khi
một công ty nhỏ làm về giấy vệ sinh của VN thì có thể sẽ cần điều chỉnh SC mỗi quý hoặc nửa
năm một lần.
- Người ta chấp nhận có sự sai số tạm thời giữa chi phí tính theo SC và chi phí thực, sai số này sẽ
được điều chỉnh bằng một bút toán điều chỉnh lên SC khi phòng kế toán thu thập được chi phí
thực tế .
- Để định lượng được thật sát với thực tế doanh nghiệp, không có cách nào khác là cần có cán bộ
thống kê phối hợp với quản đốc phân xưởng thường xuyên theo dõi và ghi nhận lượng sử dụng
thực tế.
- Việc sản phẩm có cấu trúc phức tạp có thể tạo khó khăn cho kế toán thủ công, nhưng lại được
xử lý tương đối dễ dàng trong các hệ thống ERP như phần sau sẽ nêu chi tiết hơn.
Cách sử dụng SC trong một ERP tiêu chuẩn
Trước hết cần khẳng định lại là các ERP chỉ giải quyết bài toán giá thành theo một cách duy nhất
là dùng SC và phần này thường nằm trong phân hệ sản xuất (production/manufacturing module)
chứ không phải trong phân hệ kế toán tài chính như một số doanh nghiệp vẫn nhầm lẫn. Trước khi
có thể tính được giá thành người dùng sẽ được yêu cầu khai báo một số thông tin căn bản như
sau:
Công thức sản phẩm (Bill of Material-BoM): có dạng tương tự như bảng tính trong ví dụ trên.
BoM trong các hệ thống ERP thường cho phép khai báo nhiều tầng theo hình cây. Ví dụ, sản
phẩm A được làm từ B và C, B lại là một bán thành phẩm được làm từ E và F, v.v... Tùy theo cách
cấu tạo của mỗi phần mềm, BoM có thể sẽ bao gồm luôn cả các cấu phần không phải NVL ví dụ
như công lao động hoặc các chi phí phân bổ. BoM phải được khai báo đến mức chi tiết cuối cùng
là các đơn vị NVL đã được khai báo trong phân hệ Kho hoặc các đơn vị lao động đã được khai
báo trong phần khai báo của phân hệ sản xuất.
Chu trình sản xuất (Routing): routing chỉ ra 'con đường' đi từ NVL cho đến khi ra được sản phẩm
hoàn chỉnh, con đường đó sẽ đi qua các phân xưởng khác nhau và tại mỗi phân xưởng sẽ đi từ
chiếc máy này sang chiếc máy khác. Routing còn có phần khai báo thời gian chỉ ra bán sản phẩm
sẽ dừng lại tại mỗi máy trong bao lâu. Phần mềm sẽ dựa vào những khai báo này để tính chi phí
phát sinh mỗi khi sản phẩm đi qua một máy.
Sau khi đã làm các khai báo về BoM và Routing hệ thống đã sẵn sàng để hoạt động. Mỗi khi người
dùng kích hoạt một lệnh sản xuất, hệ thống sẽ từ BoM và lượng sản phẩm cần sản xuất tính ra
lượng vật tư cần dùng, sau khi kiểm tra lại với phân hệ Kho xem có cần mua bổ sung thêm loại vật
tư nào không (thao tác này thường được gọi là MRP- Material requirement planning) hệ thống sẽ
đưa lệnh sản xuất vào routing.
Hệ thống sau đó cũng sẽ tự động tạo ra các bút toán ghi nợ/có thích hợp vào các tài khoản NVL,
bán thành phẩm, thành phẩm, giá thành phân xưởng để chuyển lên phân hệ kế toán tài chính.
Lời kết
Phân hệ sản xuất của một ERP tiêu chuẩn sử dụng phương pháp giá thành định mức. Vấn đề rút
ra ở đây là trước khi đưa ERP vào sử dụng tính giá thành, doanh nghiệp cần chuyển từ phương
pháp tính chi phí thực sang phương pháp giá thành định mức. Doanh nghiệp hoàn toàn có thể
dùng bảng tính Excel để theo dõi giá thành theo cách này khi chưa có ERP. Với các bút toán điều
chỉnh được làm định kỳ, doanh nghiệp có thể yên tâm rằng, giá thành ghi nhận theo phương pháp
SC, sẽ sai số không đáng kể với giá thành thực. Nhưng những lợi ích về quản lý và lập kế hoạch
từ việc dùng SC thì rất lớn. Khi doanh nghiệp đã quen với phương pháp SC có thể tự tin đưa ERP
vào áp dụng