ERP Tổ chức đội ngũ triển khai dự án ERP về phía nhà cung cấp giải pháp.

  • Thread starter ERPSolution
  • Ngày gửi
E

ERPSolution

Thành viên thân thiết
6/4/05
191
0
0
44
HCMC
#1
Lâu nay thấy box này ít bài quá, mình mở một topic mới hy vọng mọi người đón nhận.

Cách tổ chức nhân lực triển khai các hệ thống ERP như thế nào cho hiệu quả có ý nghĩa quan trọng đến thành bại của dự án. Tuy nhiên, cách thực hiện của mỗi Nhà cung cấp giải pháp ERP lại khác nhau, một số mô hình minh họa tượng trưng như sau (nói về phía nhà cung cấp giải pháp thôi):

1. Trưởng dự án thuộc thành viên BGĐ, các thành viên gồm các chuyên viên tư vấn triển khai mà mỗi người chuyên về mỗi mãng như:Accounting, Sản xuất, Warehouse, Sales...Các thành viên có vai trò ngang nhau

2. Trưởng dự án thuộc thành viên BGĐ, các thành viên gồm các chuyên viên tư vấn triển khai mà mỗi người chuyên về mỗi mãng như:Accounting, Sản xuất, Warehouse, Sales... Trong đó có một người kinh nghiệm là nhóm trưởng nhóm triển khai.

3.Trưởng dự án là một chuyên viên giỏi trong phòng tư vấn triển khai nắm tất cả các phân hệ, các thành viên như vệ tinh coi như giúp việc
....

Theo bạn, mô hình như thế nào mới là hiệu quả nhất?
Ghi chú: các mô hình ERPS đưa ra chỉ tượng trưng thôi, không cần phải mổ sẽ chi tiết, chúng ta cần đưa ra mô hình lý tưởng

ERPS
 
Sửa lần cuối:
S

ss4u-vn.com

Sơ cấp
13/5/06
7
0
0
Quan Tan Binh, tp hcm
#2
Đúng là lau lắm rồi không có nhiều bài nói về ERP, topic cùa ERPSolution đưa ra rất hay và phù hợp. Hy vọng các vấn đề về ERP sẽ cứ tiếp tục.

Với chút kinh nghiệm tư vấn và quản trị các dự án ERP hàng đầu của thế giới và hiện là nhà cung cấp ERP chuyên nghiệp, tôi xin góp ý về tổ chức nhân sự cho các dự án ERP.

Trong 1 dự án ERP(cho dù quy mô nhỏ hay lớn) thi việc xây dựng tổ chức dự án rất quan trọng, nó ảnh hưởng rất lớn đến sự thành bại của dự án. Các thành viên như sau:

+ Giám đốc dự án: Quản lý chung dự án, có trách nhiệm hỗ trợ kịp thời nhân sự, tài chính, tinh thần,..và làm việc với khách hàng khi có vấn đề lớn phát sinh. Giám đốc dự án có thể không phải là Ban lãnh đạo công ty và cùng lúc làm giám đốc nhiều dự án.

+ Trưởng dự án(Quản trị dự án): Người quản lý toán bộ quá trình triển khai của dự án. Nên chọn trưởng dự án là người am hiểu về hệ thống tài chính kế toán(có thể đã là trưởng nhóm phân hệ tài chính), nắm vững tổng quan của hệ thống ERP, nắm tương đối các phân hệ khác. Trưởng dự án phải có tố chất của 1 nhà quản trị.,...

+ Tư vấn giải pháp: Đây là nhân vật rất quan trọng trong các dự án ERP. Người này phải am hiểu rất sâu về hệ thống cũng như luật pháp của nhà nước. Có đầy đủ kiến thức để tư vấn cho đội dự án, thiết phục, tư vấn cho khách hàng thay đổi cho phù hợp ERP. Tư vấn giải pháp tốt hết từng là trưởng dự án. Cùng lúc có thể tư vấn cho nhiều dự án.

+ Các trưởng nhóm triển khai ở từng phân hệ: Nắm vững phân hệ mình triển khai

+ Các trưởng nhóm triển khai ờ từng site(nếu dự án có nhiều site): Chịu trách nhiệm triển khai tại các site chi nhánh. Nếu các site chi nhánh có quy mô lớn thì cũng phải tổ chức nhân sự gần như ở công ty.

Triển khai ERP là công việc khó, vì vậy chúng ta nên chuẩn bị rất tốt mọi vấn đề liên quan trước khi Kitoff.
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#3
Rất tiếc dạo này mình ko có điều kiện tham gia mấy vụ này. Các bạn thử tham khảo tài liệu về mấy phương pháp triển khai ERP như AIM của Oracle, ASAP của SAP xem họ làm thế nào. Sau đó tùy từng dự án, điều kiện cụ thể như môi trường của khách hàng, khả năng của NCC, độ lớn của dự án, v.v... (gọi là liệu cơm mà gắp mắm ấy) mà customised lại cho phù hợp. Mấy tài liệu này cũng nêu khá đầy đủ các loại hình tổ chức của dự án ERP, miêu tả khá rõ ràng vai trò của từng roles trong dự án, v.v... Tiếc là tài liệu loại này mình cho "đi tiêu hết rồi" :)).
 
E

ERPSolution

Thành viên thân thiết
6/4/05
191
0
0
44
HCMC
#4
hai2hai nói:
Rất tiếc dạo này mình ko có điều kiện tham gia mấy vụ này. Các bạn thử tham khảo tài liệu về mấy phương pháp triển khai ERP như AIM của Oracle, ASAP của SAP xem họ làm thế nào. Sau đó tùy từng dự án, điều kiện cụ thể như môi trường của khách hàng, khả năng của NCC, độ lớn của dự án, v.v... (gọi là liệu cơm mà gắp mắm ấy) mà customised lại cho phù hợp. Mấy tài liệu này cũng nêu khá đầy đủ các loại hình tổ chức của dự án ERP, miêu tả khá rõ ràng vai trò của từng roles trong dự án, v.v... Tiếc là tài liệu loại này mình cho "đi tiêu hết rồi" :)).
Thật sự những cái này chỉ nên tham khảo thôi, mỗi nơi mỗi khác, nhất là các nhà cung cấp giải pháp ERP của chúng ta đều là mới, các giải pháp vừa xây dựng vừa triển khai chứ ít khi có sản phẩm đã hoàn chỉnh (một số hườm hườm thôi). Các SP nước ngoài đã hoàn chỉnh & chuyên nghiệp hơn nên sẽ khác.
Dĩ nhiên, dựa vào mức độ hoàn thiện của sản phẩm có thể điều chỉnh nhân lực dự án cho phù hợp hơn. Đó mới là bí quyết. Nên sẽ có nhiều giải pháp hay nhất, mỗi giải pháp sẽ thích hợp với mỗi sản phẩm dựa theo mức độ hoàn thiện sản phẩm. Có nhiều trường hợp, người viết code đi triển khai luôn
 
E

ERPSolution

Thành viên thân thiết
6/4/05
191
0
0
44
HCMC
#5
ss4u-vn.com nói:
+ Trưởng dự án(Quản trị dự án): Người quản lý toán bộ quá trình triển khai của dự án. Nên chọn trưởng dự án là người am hiểu về hệ thống tài chính kế toán(có thể đã là trưởng nhóm phân hệ tài chính), nắm vững tổng quan của hệ thống ERP, nắm tương đối các phân hệ khác. Trưởng dự án phải có tố chất của 1 nhà quản trị.,...

+ Tư vấn giải pháp: Đây là nhân vật rất quan trọng trong các dự án ERP. Người này phải am hiểu rất sâu về hệ thống cũng như luật pháp của nhà nước. Có đầy đủ kiến thức để tư vấn cho đội dự án, thiết phục, tư vấn cho khách hàng thay đổi cho phù hợp ERP. Tư vấn giải pháp tốt hết từng là trưởng dự án. Cùng lúc có thể tư vấn cho nhiều dự án.

.
Có chồng chéo giữa hai chuyên gia này ko, sao ko gộp làm 1 luôn? Rất mong ss4u-vn.com phân tích thêm


ss4u-vn.com nói:
+ Các trưởng nhóm triển khai ở từng phân hệ: Nắm vững phân hệ mình triển khai

+.

Mỗi phân hệ mà cần nhiều người như vậy có rườm rà ko, có cần thiết ko trong khi các DN của VN ít có DN nào quá lớn ?
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#6
ERPSolution nói:
Có chồng chéo giữa hai chuyên gia này ko, sao ko gộp làm 1 luôn? Rất mong ss4u-vn.com phân tích thêm

Mỗi phân hệ mà cần nhiều người như vậy có rườm rà ko, có cần thiết ko trong khi các DN của VN ít có DN nào quá lớn ?

Có lẽ bạn chưa quen với khái niệm "vai trò" (tiếng anh: Role) nhỉ.

Vai trò quản trị dự án, Vai trò tư vấn cấp cao, vai trò triển khai, v.v...

Ở mỗi giai đoạn thì vai trò nào là sử dụng nhiều, vai trò nào là sử dụng ít.

Tùy theo mỗi loại hình dự án, khả năng của nhà cung cấp, khả năng (độ lớn) của mỗi sản phẩm, v.v... mà 1 người có thể đóng những vai trò nào trong dự án. (Nghĩa là quan hệ giữa thực thể con người vật lý và vai trò là nhiều nhiều: 1 người có thể làm nhiều vai trò, nhiều vai trò có thể do nhiều người làm. Cái này giống hệt tính năng quản trị User trong hệ thống phần mềm). Ví dụ ở SAP, Oracle thì thông thường một người chỉ làm 1 vai trò là cùng (nhưng họ là chuyên gia trong vai trò đó), còn ở các NCC khác nhỏ hơn hoặc ở những dự án nhỏ hơn (đặc biệt là ở VN) thì một người làm nhiều vai trò khác nhau (ví dụ 1 người có thể vừa làm quản trị dự án, vừa làm vai trò implementation leader 1 phân hệ nào đó trong hệ thống, v.v...).

He he, nghĩa là ERP Solution cần phải tìm hiểu thêm nhiều những concept cơ bản đó nhé. Ở bài trên tớ muốn nói là tham khảo mô hình của họ, từ đó áp dụng vào từng dự án cụ thể (gọi là liệu cơm mà gắp mắm). Thế mà bạn lại Quote lại bài của tớ và nói là "Thật sự những cái này chỉ nên tham khảo thôi, mỗi nơi mỗi khác....". Tớ có bảo là các bạn làm y chang như họ đâu. Chính họ cũng phải tùy vào mỗi dự án mà phân công con người cụ thể (Mr A, Mr B, v.v...) vào các vai trò khác nhau (vai trò quản trị dự án, vai trò triển khai, vai trò tư vấn, v.v...). Trên đời này làm gì có cái gì là giống nhau, là đứng im 1 cách .... vĩnh cửu. Bất cứ vật thể nào tồn tại trên 1 hành tinh dù trông có "đứng im" đi chăng nữa thì thực tế cũng đang chuyển động theo quỹ đạo của hành tinh đó cơ mà. :) Vì thế ko có khái niệm mô hình này giống hệt mô hình kia rồi.

Không hiểu nói thế bạn đã hình dung ra được vấn đề hay chưa? (Vai trò khác thực thể con người cụ thể) :) :) :) :biggrin:

Đơn cử cho bạn nhé: 1 phòng phần mềm gồm có 5 người. Quy trình sản xuất phần mềm thì có rất nhiều quy trình trong đó có quy trình, công việc (process, jobs) là bắt buộc (madatory), có quy trình, công việc là optional. Tùy vào tính chất của dự án mà ta có thể thực hiện quy trình này, loại bỏ quy trình kia, làm công việc này, ko làm công việc kia, v.v... chứ ko phải dự án, sản phẩm phần mềm nào (như CDM project, commercial software, shareware, outsource project, v.v...) ta cũng làm như nhau (không flexible như thế thì các công ty nhỏ có mà chết à :)). Cái đó người ta gọi là tính flexibility trong việc áp dụng quy trình (mà những người ko hiểu thì cứ nói là áp dụng quy trình nhiều như vậy là khó, là ko thực hiện được, là ko hiệu quả, là...). Không có gì là ko thực hiện được cả. Cái chính là người lãnh đạo (nói chung cho các nhà quản lý, các nhà quản trị dự án, leaders, v.v...) nên biết áp dụng quy trình như thế nào CHO HIỆU QUẢ vào mỗi công việc cụ thể mà thôi.

Understand?

PS: Còn nhiều điều muốn nói lắm nhưng không có nhiều time nữa.
 
Sửa lần cuối:
E

ERPSolution

Thành viên thân thiết
6/4/05
191
0
0
44
HCMC
#7
To Hai2hai,

Trước tiên, mình rất vui và cảm ơn vì bạn đã tham gia tích cực cho topic này dù rằng bạn rất ít time.

Tuy nhiên, bạn nên hiểu rằng:'một người đặt vấn đề cần nhờ mọi người phân tích chưa hẳn là người đó không đồng tình với quan điểm đó', có khi người ta muốn lắng nghe thêm, muốn được mọi người chia sẽ, cũng có thể họ muốn các chuyên gia viết bài chia sẽ với mọi người.

Vì vậy, bài viết nên có thái độ thân ái, tôn trọng nhau hơn, đây cũng là tính cách mà người làm nghề tư vấn như chúng ta nên rèn luyện, nó ảnh hưởng rất nhiều đến chuyện thành bại của dự án triển khai đó.


Có lẽ hai2hai bức xúc vì mình đã Quote bài viết của bạn, Hãy thông cảm bởi vì cái mình cần các chuyên gia chia sẽ ở đây ko phải là những lý thuyết lan man mà là giải pháp thực tế cho hiện trạng tại Việt Nam, cái ứng dụng thực tế thiết thực nhất để chia sẽ với mọi người
.

Chào thân ái,:flower:


ERPS
 
Sửa lần cuối:
S

ss4u-vn.com

Sơ cấp
13/5/06
7
0
0
Quan Tan Binh, tp hcm
#8
Đã là dự án ERP "đúng nghĩa" thì chúng ta không nên so sánh nhỏ hay lớn. Đã có rất nhiều dự án ERP thất bại do quan niệm như thế. Chúng ta nên chuẩn bị kỹ và chuyên nghiệp thì may ra mới thành công được. Tất nhiên các dự án ERP có quy mô nhỏ hơn thì thời gian sẽ rút ngắn lại và độ phức tạp sẽ ít đi.

Có trùng lắp giữa quản trị dự án và tư vấn giải pháp không?! Theo kinh nghiệm xương máu của tôi thì hoàn toàn không. Quá trình triển ERP, giai đoạn tư vấn giải pháp là quan trọng nhất, trong các doanh nghiệp đang cung cấp ERP của Việt Nam hiện nay(Cả FPT, Pythis,..) thì đội ngũ tư vấn giải pháp "rất hiếm", thường thì họ chỉ tham gia cùng lúc nhiều dự án và chỉ ở vai trò tư vấn giải pháp, không dành 100% thời gian cho bất kỳ dự án nào. Trong khi đó Trưởng dự án thì phải có mặt full times.

Các dự án ERP có 1 site thì mỗi phân hệ nên có 1 thủ lĩnh, còn nếu nhiều site có quy mô phức tạp, địa bàn ở xa thì nên mỗi site phải có người lãnh đạo, kể cả ở cấp phân hệ. Chúng ta đừng chủ quan trong vấn đề này. Hệ thống ERP phải ứng dụng cho hầu hết phòng ban trong doanh nghiệp, kiến thức chúng ta có hạn, vậy nên chuyên môn hóa cao ở từng khâu. Tất nhiên ở các dự án có quy mô nhỏ hơn thì mỗi phân hệ chỉ cần 1 người là OK.

Hẹn gặp các bạn lần sau! Giờ phải đi rồi
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#9
ERPSolution nói:

Có lẽ hai2hai bức xúc vì mình đã Quote bài viết của bạn, Hãy thông cảm bởi vì cái mình cần các chuyên gia chia sẽ ở đây ko phải là những lý thuyết lan man mà là giải pháp thực tế cho hiện trạng tại Việt Nam, cái ứng dụng thực tế thiết thực nhất để chia sẽ với mọi người
.

ERPS
Sory nhé :beer:

Ý tớ đơn giản là: (thông thường đó là phương pháp của tớ)

Bước 1: Hiểu tổng quan (kể cả lý thuyết tổng thể)
Bước 2: Tùy vào mỗi công việc cụ thể mà áp dụng cái tổng quan (lý thuyết) đó vào thực tế.

Vì vậy: Khi đã có tổng quan ban đầu rồi (bạn gọi là lý thuyết lan man đó :)) thì bước 2 là ... tùy vào mỗi công việc cụ thể mà ra quyết định (vì có ai đứng ở đúng vị trí của bạn đâu mà ra quyết định giúp bạn). Thực tế hiện trạng ở VN thì có vô vàn thực tế khác nhau (chả phải ở VN, ở đâu cũng thế cả thôi). Áp dụng đầy đủ cũng có, áp dụng kiểu customize cũng có, v.v... Và đặc biệt mỗi dự án cụ thể thì việc áp dụng là khác nhau mà chỉ có ai nằm trong dự án đó (hoặc sắp thực hiện dự án đó) mới hiểu để mà áp dụng cho hiệu quả. Bạn hay bất cứ ai cũng đều biết là làm quản trị dự án thì cần phải balance giữa 3 yếu tố: Khối lượng công việc, chất lượng, nguồn lực thực hiện (thời gian, tài chính, nhân lực,...). Không thể làm 1 khối lượng khổng lồ với chất lương cực cao trong khi nguồn lực (thời gian thì ít, tiền thì ko nhiều, người thì vắng teo...) lại hạn hẹp được. Thế tớ mới nói là tùy vào từng dự án, công việc cụ thể mà "optimizes" cái tổng thể, cái lý thuyết vào thực tế cho phù hợp.

Phương pháp đó tớ áp dụng cho mọi công việc (chứ ko chỉ nói đến ERP không đâu). Vì thế mới có khái niệm tổng quan (lý thuyết) đi trước, chi tiết (thực tế) đi sau.

Xét về mặt hướng đối tượng mà nói :) thì cứ có cái based concept thì mới có cái concrete (derived) concepts. (hơi OOP 1 chút he he...) (vì có thể những người tham gia lại chưa có based mà lại nói về cái concrete thì sợ lại sai lệch định hướng thì hỏng bét.). Tớ thì lại thích thừa hưởng những gì (kiến thức chẳng hạn) mà họ (ai cũng được) đã trả bao nhiêu chi phí để trải qua rất nhiều kinh nghiệm hơn là tự làm từ đầu (vì ko đủ khả năng để làm mọi cái từ đầu).

Sory ERPS nhé :)
 
Sửa lần cuối:
B

bibinew

Sơ cấp
20/5/06
20
0
0
36
TP HCM
#10
Mình đồng ý với bác Hai2hai! Mình cần có nền lý thuyết căn bản, rồi tùy trường hợp thực tế sẽ có cách áp dụng khác nhau trên nền cơ bản đó. Tới đây mình nghĩ mọi người đã có thể hình dung được cơ bản việc yêu cầu nhân lực cho một dự án ERP(qua bài của bác ss4u-vn.com, nhưng mình nghĩ hình như còn thiếu nhân viên triển khai, thấy toàn đầu não mà không thấy tay chân đâu :wall: )
Bây giờ mình nên đi thực tế một chút theo ý của bác ERPSolution. Các bác nào đã từng tham gia triển khai trong một dự án ERP(lớn, nhỏ, thành công, thất bại...) xin post cách bố trí nhân lực thực tế trong dự án đó(nếu có thể thì các bác mô tả đôi chút về công ty đối tác và phân tích vì sao thành công vì sao thất bại) để chúng mình tham khảo và học tập. À mình còn thấy việc quan trọng là cần chuẩn bị gì cho việc thay đổi nhân lực trong dự án? MÌnh đang tìm hiểu về ERP nên chưa có nhiều kinh nghiệm nên xin các bác chỉ dẫn.thanks
 
E

ERPSolution

Thành viên thân thiết
6/4/05
191
0
0
44
HCMC
#11
Lý thuyết là nền tảng, làm sao mà bỏ qua được, không phải mình xem nhẹ lý thuyết. Vấn đề quan trọng là đã có kiến thức, kinh nghiệm...nhưng QUYẾT ĐỊNH ĐÚNG VẤN ĐỀ mới là điều quan trọng.

Trong một cuộc họp, cần đưa ra phương thức xử lý tình huống thì bạn có thể vận dụng mọi vốn liếng của mình để quyết định như thế nào để đưa ra ý kiến.

Biết lý thuyết chưa chắc đã hiểu, hiểu rồi chưa chắc đã vận dụng được. Tuy nhiên đã vận dụng tốt với các quyết định đúng thì bạn phải có nhiều kiến thức và kinh nghiệm.


ERPS
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#12
Bạn hay bất cứ ai cũng đều biết là làm quản trị dự án thì cần phải balance giữa 3 yếu tố: Khối lượng công việc, chất lượng, nguồn lực thực hiện (thời gian, tài chính, nhân lực,...). Không thể làm 1 khối lượng khổng lồ với chất lương cực cao trong khi nguồn lực (thời gian thì ít, tiền thì ko nhiều, người thì vắng teo...) lại hạn hẹp được. Thế tớ mới nói là tùy vào từng dự án, công việc cụ thể mà "optimizes" cái tổng thể, cái lý thuyết vào thực tế cho phù hợp.
Quản lý 3 yếu tố trên thế nào --> Nó thuộc về lĩnh vực quản trị dự án (bất kể đó là dự án ERP, dự án xây dựng, hay bất cứ dự án gì).

Theo "kinh nghiệm" ít ỏi của mình, kinh nghiệm để quyết định những tình huống cụ thể thì khó mà có thể trao đổi qua diễn đàn được. (vì chúng ta có chung tình huống đâu, tớ thì dự án ABCDEF, bạn thì dự án XYZ, anh PAT thì dự án 1234, v.v....) :)

Vấn đề quyết định thế nào cho đúng, như mình đã nói ở trên rồi, là tùy tình hình mà quyết. Làm sao mà có thể trao đổi trên diễn đàn được những tình hình cụ thể đó. Ai có thể làm thay cái con người cụ thể ở cái tình hình đó bây giờ?

Bạn nói biết lý thuyết chưa chắc đã hiểu, hiểu rồi chưa chắc đã vận dụng được. Đúng 100%! Nhưng tớ chưa biết lý thuyết!! :) !!, một số người khác chưa hề biết lý thuyết về quản trị dự án nói chung, quản trị dự án ERP nói riêng nó như thế nào? (ai có thể sure nói là biết rồi xin giơ tay cái). Vậy thì làm sao trao đổi được ở đây về những kinh nghiệm cụ thể nếu chưa có lý thuyết? Đã ai đọc AIM của Oracle hay ASAP của SAP, hay cái gì đó của QAD, cái gì đó của AZ Co., chưa? OK, nếu coi mớ lý thuyết đó là của bọn Tây ko đáng để học thì Lý thuyết mà các bạn đã biết và tích lũy được rồi là cái gì thì copy vài dòng lên đây cho mình xem với??? Ai chỉ cho mình các phrases triển khai 1 hệ thống XYZ nói chung thì có những cái gì? Có bao nhiêu vai trò trong dự án đó? Mỗi vai trò đó tham gia như thế nào trong mỗi phrase đó? v.v... Đó toàn là lý thuyết thôi, các bạn giới thiệu cho mình biết với.... Many thanks!!!!

Cheers! :)
 
E

ERPSolution

Thành viên thân thiết
6/4/05
191
0
0
44
HCMC
#13
Chúng ta thử đánh giá trên thị trường VN hiện tại, có các dạng nhà cung cấp ERP như thế nào (hoặc là các giai đoạn phát triển của môt nhà cung cấp ERP). Sau đó, hãy đưa ra mô hình, cách thức tổ chức nhân lực triển khai thích hợp cho mỗi trường hợp (hoặc mỗi giai đoạn). Đây cũng xem như việc ra quyết định, tình huống ở đây là sự phát triển của DN bạn theo từng giai đoạn phát triển sản phẩm nên có quyết định điều chỉnh cho phù hợp.
Biết đâu, các NCC ERP sau khi xem các bài viết trên đây có thể điều chỉnh tổ chức nhân sự của mình cho hiệu quả hơn. Hy vọng như vậy.

Ví dụ:
1. Nhóm 1: Nhóm NCC ERP đã có SP ổn định.
2. Nhóm 2: Nhóm NCC ERP đang dần hoàn thiện SP.
3. Nhóm 3: Nhóm NCC ERP mới bắt tay vào
.....
Nhóm triển khai ERP Package
Nhóm triển khai ERP Customize toàn bộ
Nhóm triển khai ERP Customize một phần dựa trên SP có sẳn.

:two:

ERPS
 
Sửa lần cuối:
yukos

yukos

bsdinsight.com
19/8/04
188
4
18
46
bsdinsight.com
www.bsdinsight.com
#14
he he, lâu lắm rồi mới vào đây (chắc cũng gần 7 tháng) - "lắm thầy nhiều ma" thôi mấy bác ơi - theo tớ là thế, nếu làm việc ra hồn thì triển khai ERP, doanh nghiệp chỉ cần nhiều nhất là 2 - 3 người là xong (2 người là số nhiều rồi, mà trong tiếng Anh là có "S" rồi đó) - phần còn lại của nhà cung cấp, còn nhà cung cấp bao nhiêu thì kệ họ - Nếu họ không hoàn tất hợp đồng đúng hạn, các bác cứ thẳng tay đền cho họ biết tay. Còn liên lạc với nhà cung cấp hả, doanh nghiệp chỉ liên lạc với Project Manager thôi, thế là xong.
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#15
yukos nói:
he he, lâu lắm rồi mới vào đây (chắc cũng gần 7 tháng) - "lắm thầy nhiều ma" thôi mấy bác ơi - theo tớ là thế, nếu làm việc ra hồn thì triển khai ERP, doanh nghiệp chỉ cần nhiều nhất là 2 - 3 người là xong (2 người là số nhiều rồi, mà trong tiếng Anh là có "S" rồi đó) - phần còn lại của nhà cung cấp, còn nhà cung cấp bao nhiêu thì kệ họ - Nếu họ không hoàn tất hợp đồng đúng hạn, các bác cứ thẳng tay đền cho họ biết tay. Còn liên lạc với nhà cung cấp hả, doanh nghiệp chỉ liên lạc với Project Manager thôi, thế là xong.
Bác chỉ được cái nói đúng :). Cứ vác anh PM ra mà trảm. Mấy công việc đó là của hắn mà, hắn nhận lương cao mà làm ko xong (nào là ko estimate được công việc, nào là ko communicate được tốt với KH, nào là ko bỗ trí lực lượng nhân sự cho phù hợp dự án, nào là over budget/time, v.v... ---> toàn là công việc của PM) thì phải trảm thôi. Bên KH chỉ cần có 1, 2 người chịu trách nhiệm chính (và được delicate vào dự án hoàn toàn) là ngon rùi (còn những người khác khi cần thì tham gia vào theo vụ việc thôi).
 
yukos

yukos

bsdinsight.com
19/8/04
188
4
18
46
bsdinsight.com
www.bsdinsight.com
#16
hehe, thì ra là dạo này có khá nhiều người quan tâm ERP mà không viết bài lên đây - Sau khi tớ viết vài câu thì nhận được rất nhiều PM hỏi như sau:
- Tôi đọc trên các báo chí, thấy rằng khi triển khai, doanh nghiệp nhất thiết cần phải có một đội ngũ triển khai - sao ông Yukos viết chỉ cần 2-3 người.
- Làm thế nào tôi có thể đền cty tư vấn triển khai, và yêu cầu họ thực hiện đúng hợp đồng vì khi triển khai ERP, thì có rất nhiều việc phát sinh (và như tooi thấy thì chưa có công ty nào triển triển khai thành công ở VN)
- Tôi có thể gặp anh bằng cách nào, hoặc cách nào đó anh có thể cung cấp thêm thông tin.
- Anh cùng với các anh em yêu ERP và có kinh nghiệm về ERP có thể tổ chức buối nói chuyện về ERP được không?
- Khi triển khai ERP thì có sự tham gia của những phòng ban nào?
- Các tài liệu nào mà cty tôi nhận được khi triển khai ERP
- Công ty anh là công ty gì?,...phải là cty tư vấn không
- còn nhiều

(He he, để tớ pos rồi sửa bài lại sau, diễn đàn này mà gõ lâu lâu tí là mất cả chì lẫn chài)

- Nói 1 cách máy móc thì 2 người cũng là 1 nhóm, một đội ngũ rồi bác ơi. Như thế cty của bác cũng đã có 1 đội ngũ triển khai ERP rồi còn gì, đội ngũ đó gồm có 2 người. Trên báo chí viết thế, nhưng là d/n thì không nên đánh giá ERP là cái gì đó quá to tác khi phải triển khai. Khi triển khai ERP thì người ta tập trung và cách thức triển khai (methodology) hơn là "Chiến lược triển khai" - không quá to tác như thế. - 2, hoặc 3 người là đủ rồi, phần còn lại là nhà tư vấn triển khai phải cung cấp dịch vụ cho Bác thôi.

- Sống dưới bầu trời đất Việt, người sử dụng nhiều khi quên luôn mình được cái gì, mình phải có cái gì khi mua dịch vụ của nhà cung cấp (Nhiều lúc tớ cũng quên luôn, tỉ như điện thoại di động chẳng hạn,.. he he). Bác phải có những yêu cầu với nhà cung cấp, và đó là "MUST"

- Gặp tớ hả, không cần phải nhà hàng sang trọng - he he, làm ly cafe đá 2,000 VND - 7,000 VND là xong - Số của tớ là 090 375 9119 - trong khả năng của mình, tớ biết gì nói nấy, cái gì không biết thì tịt ngòi

- Món tổ chức này chắc không xong rồi - Sorrry nhé, nhiều thứ rắc rối lắm.

- Gồm tất cả phòng ban, khả năng chỉ trừ phòng bảo vệ, và lao công của cty thôi.

- Các tài liệu hả? nhiều, ít nhất phải là 10, nếu dưới 10 là nhà cung cấp đó chắc chắn chưa làm việc tốt rồi (VD như: Kế hoạch triển khai (Project Implementation Planning), quản trị dự án (Project Mamagement Planning), Project Implementaion Review, đánh giá rủi ro (Project Rick Analisys), project scoping (rõ khổ, tớ dùng tiếng Anh quen, không biết tiếng Việt là gì, bác nào văn hay chữ tốt dịch phát), phần cứng (tớ thường dùng tiếng Anh là Hardware sizing, chẳng biết dịch ra là sao nữa), đánh giá khác biệt (thường tớ dùng là Gap & Fit Analisys) - các tài liệu về chech list (dùng đề đánh giá, hỏi han,..), Technicial Implementaion Planning, Codding, Training material, training guide, workflow,.....nhiều lắm lắm luôn) - thường thì tài liệu training sẽ có 2 phiên bản, 01 cho Key-User, và 01 cho End-User,

- Cty của tớ chỉ là c/ty tư vấn triển khai thôi, bên tớ triển khai QAD với sản phẩm làm MFG/PRO - và là ERP của Mỹ (không biết viết thế này có bị xem là quảng cáo không nữa, nếu là quảng cáo thì bác mod cho mục này lên thiên đàng nhé bác)
 
Sửa lần cuối:
erpvn

erpvn

Don't know what is erp!
28/1/04
416
0
16
42
Miền đất hứa
www.erpvna.com
#17
Anh cùng với các anh em yêu ERP và có kinh nghiệm về ERP có thể tổ chức buối nói chuyện về ERP được không?
Box ERP cũng đã từng tổ chức các buổi như thế sau này thì thấy ít người post bài -> chắc các bác chán ERP rồi nên không tổ chức thêm buổi nào nữa. Các bác quan tâm thì cũng nêu lên yêu cầu của mình để anh em còn biết đường mà tổ với chức... còn Hội những người yêu ERP chúng tôi luôn sẵn lòng.

Nhà em sẽ có những bài viết về tình hình ERP thực tế ở VN và những kinh nghiệm đúc kết mong là sẽ hữu ích cho các DN đã, đang và sắp triển khai ERP trong topic cuối năm.

Còn gà yukos quảng cáo quá xa... thôi kệ chắc cũng k quá xa sự thật là bao...
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#18
yukos nói:
project scoping (rõ khổ, tớ dùng tiếng Anh quen, không biết tiếng Việt là gì, bác nào văn hay chữ tốt dịch phát)
Phạm vi dự án. Đây cũng là tài liệu mấu chốt để dự án thành công. Không có tài liệu này khéo khách hàng lại tưởng triển khai ERP xong mỗi nhân viên lại có ... 1 email account, có 1 ... máy di động cầm tay để truy cập vào chương trình, mọi khâu nghiệp vụ nó chạy từ A đến Z 1 cách tự động mà người dùng chẳng phải làm gì hoặc tệ hơn là tưởng các sếp ngồi chơi ở nhà mà tiền nó vẫn ào ào chảy vào công ty :D.

Đùa tý cho bớt căng thẳng thôi nhưng thực sự tài liệu project scope là khá quan trọng. Scope về yêu cầu liên quan đến khối lượng công việc (nghiệp vụ, triển khai,...), liên quan đến tài nguyên (resources) của dự án như ngân sách, thời gian, nhân lực, vật lực, tài lực,...).
 
G

gaugau

Trung cấp
6/9/04
111
2
0
48
HCM
#19
- Sống dưới bầu trời đất Việt, người sử dụng nhiều khi quên luôn mình được cái gì, mình phải có cái gì khi mua dịch vụ của nhà cung cấp (Nhiều lúc tớ cũng quên luôn, tỉ như điện thoại di động chẳng hạn,.. he he). Bác phải có những yêu cầu với nhà cung cấp, và đó là "MUST"
cám ơn anh yukos rất nhiều. Anh có thể nào cung cấp thêm các thông tin về các yêu cầu ràng buộc trong hợp đồng với Nhà tư vấn triển khai không anh? anh có thể liệt kê giống như anh liệt kê trong phần tài liệu không - nói thật, lâu nay không nghĩ là khi triển khai ERP thì nhiều tài liệu đến thế, ngay như anh nói tài liệu training cũng có 2 phiên bản thì chắc là chưa ai có cả.

Em vẫn chưa hiểu hết key-user và end-user như thế nào, anh có thể giải thích thêm được không?

cám ơn anh trước nhé
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#20
gaugau nói:
Em vẫn chưa hiểu hết key-user và end-user như thế nào, anh có thể giải thích thêm được không?

cám ơn anh trước nhé
Vì ERP là hệ thống lớn chứ ko phải 1 PM con con 1 người sử dụng. Để vận hành thì DN cũng nên có 1 (nhóm) người gọi là admin gì đó (nói thế cho nôm na nhé) (Ví dụ, đối với dự án cỡ như TABMIS thì có thể ko phải 1 người rồi). Vì thế phải có tài liệu cho những người đó riêng (thường gọi là system manual or administration manual). Còn những người sử dụng đầu cuối (business end users) thì thường sài user manual (thực ra mỗi end user chỉ cần nắm bắt 1 chương trong đó thôi). Ngoài ra, như Yukos nói, tài liệu training material & training guide để dùng cho việc đào tạo và chúng được thiết kế khác với các manual ở trên.
 
Sửa lần cuối:

Thành viên trực tuyến

Không có thành viên trực tuyến.




Xem nhiều