ERP Ứng dụng ERP - Vì sao bại nhiều hơn thắng

  • Thread starter HyperVN
  • Ngày gửi
H

HyperVN

<b>Phu hót rác</b>
17/3/03
1,833
14
0
42
Hải Phòng
www.webketoan.vn
#1
OLEK BANNUIK
Chúng ta đang sống trong thế kỷ thông tin. Việc ứng dụng công nghệ mới vào quản lý là bước phát triển không thể thiếu được của doanh nghiệp hiện đại. Nhưng ứng dụng như thế nào? Nên bắt đầu ra sao? Không phải khi muốn cứ hô một... hai...ba là chúng ta có được hệ thống quản lý hữu hiệu. Cũng giống như cổ phần hoá, công nghệ thông tin chỉ là một trong những phương tiện thực hiện, còn cái đích mà chúng ta cần đạt được là hiệu quả làm việc thực tế của doanh nghiệp.

Cái khó đối với doanh nghiệp Việt Nam nói riêng và nền kinh tế nước ta nói chung là chúng ta đang phải giải quyết những nhiệm vụ của thế kỷ 21 với thực lực của một nền kinh tế đầu thế kỷ 20. Cho nên, việc học hỏi kinh nghiệm, tránh không lập lại “vết xe đổ” của các nước đi trước, đúc kết và hình thành được một hướng đi riêng phù hợp với hoàn cách của mình - đó có lẽ là những việc cần làm ngay trước mắt. Với suy nghĩ này chúng tôi xin trích giới thiệu bài viết về kinh nghiệm ứng dụng công nghệ ERP ở Nga, đất nước cũng có nền kinh tế chuyển đổi sang thị trường, của tác giả Olek Bannuik, đăng trên tạp chí Expert mới đây để bạn đọc tham khảo.

ERP (Enterprise Resource Planning) – Hoạch định nguồn lực doanh nghiệp. Đây là phương tiện hiện đại, sử dụng công nghệ thông tin để quản lý tất cả các nguồn lực của doanh nghiệp (nhân lực, tài chính, phương tiện và tư liệu sản xuất ...). Ngoài chức năng quản lý, ERP còn đảm nhận luôn nhiệm vụ phân tích, kiểm tra thực trạng sử dụng nguồn lực với mọi mức độ cập nhật phù thuộc theo yêu cầu của nhà quản lý. Về lý thuyết, ứng dụng ERP doanh nghiệp sẽ thực hiện một cuộc đổi đời. Với hệ thống phần mềm thống nhất, đa năng, quán xuyến mọi lĩnh vực hoạt động từ kế hoạch hoá, thống kê, kiểm toán, phân tích, điều hành – ERP sẽ giúp theo dõi và quản lý thông suốt hoạt động của doanh nghiệp, tăng tính năng động, mền dẻo, đảm bảo phản ứng kịp thời trước thay đổi liên tục của môi trường bên ngoài.

Cuộc cách mạng

Mua một bộ ERP bạn nhận được cùng lúc 3 sản phẩm. Trước hết là ý tưởng để xây dựng hệ thống quản lý, thứ hai là chương trình quản lý (thành phần và thứ tự xử lý), thứ 3 là hệ thống mạng giao tiếp và tính toán (tổ chức mạng tính toán và phương tiện liên lạc). Nói ngắn gọn, người mua hàng sẽ nhận được: ý tưởng quản lý, chương trình phần mềm và phương tiện nối kết, liên lạc qua mạng máy tính. Do đó việc chọn và ứng dụng công nghệ ERP vào quản lý có ý nghĩa đặc biệt, ảnh hưởng trực tiếp số phận của doanh nghiệp. Bởi suy cho cùng, ERP chính là kết quả kết hợp của hai cuộc cách mạng: cách mạng trong khoa học quản lý và cách mạng trong công nghệ xử lý thông tin. Chỉ có điều cuộc cách mạng nào rồi cũng không thể tránh khỏi “mất mát, thương đau”, kẻ thắng người bại. Rất may, cuộc cách mạng này không diễn ra ở ta, nên hôm nay chúng ta có thể bình tĩnh nhìn nhận thành công và thất bại của nó.

Thành quả ban đầu

“Gần 70% dự án ứng dụng ERP kết cục thất bại” (Gartner Group); “Khoảng 50% khách sử dụng dịch vụ ERP cho rằng các chương trình phần mềm không đạt được mục đích đề ra, chỉ có 30% là hài lòng với sự thành công của những dự án này” (Boston Consulting Group); “Các phần mềm quản lý doanh nghiệp đang ở trong tình trạng hỗn loạn. Thời ERP đã kết thúc!” (chuyên gia hàng đầu về giám định công nghệ IT, Paul Strassmann). Tất nhiên những nhà cung cấp dịch vụ ERP sẽ có ý kiến trái ngược (Việt Nam chúng ta còn chưa bắt đầu, làm sao lại kết thúc! – người dịch). Nhưng cho dù các con số thống kê có thể đổi ngôi, với 70% thành công và 30% thất bại thì đây vẫn là một hậu quả nặng nề. Bởi ERP không phải là trò chơi, một chương trình giải trí bắn súng, đánh trận hay lái ô tô mà đó là nền tảng quản lý của cả một doanh nghiệp. Thất bại của ERP đồng nghĩa với việc doanh nghiệp phá sản hoặc ít ra khó khăn lắm mới gượng dậy được.

Vì sao bại nhiều hơn thắng?

Về bản chất ứng dụng ERP là một quá trình bắt chước, mô phỏng cuộc sống đời thường thông qua ngôn ngữ lập trình. Sự gượng ép này đương nhiên sẽ dẫn đến việc hình thành một thư viện các chương trình nhỏ (module), mỗi chương trình là một tình huống của cuộc đời. Nhà tư vấn sẽ lấy đó làm chuẩn để tiến hành cải tổ toàn bộ cấu trúc quản lý doanh nghiệp. Do vậy, ngay sản phẩm đầu tiên là ý tưởng quản lý, trên thực tế hoàn toàn không có một ý tưởng nào cả, chỉ có đơn thuần kinh nghiệm của một doanh nghiệp nào đó ở trong một hoàn cảnh không gian và thời gian cụ thể. Nếu để ý bạn sẽ thấy các nhà tư vấn luôn bắt đầu bằng việc rà soát lại toàn bộ cơ cấu bên trong của doanh nghiệp (reengineering) với những tiêu chí đã có sẵn trên đĩa CD. Tiêu chuẩn, kinh nghiệm của nước ngoài dĩ nhiên là khác biệt nhiều với hoàn cảnh trong nước, do đó quá trình nhận thức lại lúc nào cũng rất “triệt để”. Bước tiếp theo nhà tư vấn sẽ giúp bạn cải tổ “cuộc sống” hiện tại theo chuẩn mức và module có sẵn của các nước tiến tiến – dĩ nhiên xác suất thất bại trên 70% vẫn còn là khiêm tốn.

Chúng tôi thật không có ý định chỉ trích các nhà tư vấn. Bởi tư vấn là một công việc hết sức cần thiết, hình thành và phát triển rực rỡ trên 40 năm nay. Công nghệ ERP có thể coi là một trong những đỉnh cao của tư vấn, ứng dụng thành tựu tiến bộ khoa học kỹ thuật mới nhất. Nhưng kết quả ứng dụng không mấy khả quan của nó lại cho thấy chính bản thân ngành tư vấn đang có vấn đề. Tư vấn đúng nghĩa là người đầy tớ của khoa học quản lý, nhưng hiện tại nó đang là nạn nhân của nền khoa học này thì đúng hơn.
 
H

HyperVN

<b>Phu hót rác</b>
17/3/03
1,833
14
0
42
Hải Phòng
www.webketoan.vn
#2
Chuyện gì đã xẩy ra với khoa học quản lý?

Bất ổn đầu tiên xuất phát chính từ nơi khởi nguồn của nền khoa học quản lý hiện đại – nước Mỹ. Để xây dựng nền tảng cho một nền khoa học, cái mà chúng ta cần không phải là những giải pháp cụ thể, mà là cơ sở lý thuyết căn bản, có tính tổng quát, thiên về định hướng triết học, cái mà nước Mỹ thực dụng chưa bao giờ cho là quan trọng. Suốt trong nửa sau của thế kỷ 20, các nhà bác học Mỹ, dựa trên cơ sở dữ liệu khổng lồ của thực tế, đã cố gắng hình thành nhiều học thuyết quản lý khác nhau, nhưng đều khó có thể gọi là thành công. Nên ngày hôm nay, khi ta đang cần một cách nhìn hệ thống toàn diện, thì khoa học quản lý lại đưa ra hàng loạt những lời giải đáp tuy rất độc đáo nhưng lại trả lời cho những câu hỏi hay tình huống cụ thể. Lỗi không chỉ ở sự “non tay” trong phương pháp luận của giới khoa học mà cái chính là từ khi lọt lòng khoa học quản lý hiện đại đã nằm gọn trong vành nôi của công nghiệp tư vấn. Mục đích của một nền công nghiệp là tạo ra được thật nhiều sản phẩm mới, trong khi nhiệm vụ của khoa học là đi tìm chân lý. Sự kết hợp lẫn lộn giữ công nghiệp và khoa học đã dẫn đến tình trạng: chúng ta có nhiều chân lý cho cùng một sự việc (doanh nghiệp). Và những chân lý này là gì? Thật đơn giản: chân lý đó là những gì có lãi, những gì bán chạy. Khách hàng chịu trả tiền – xin mời cứ thử. Dùng nếu trúng, hiệu quả - thì đích thực là chân lý, còn sai – khoa học đâu có lỗi? Đến một lúc nào đó khi khách hàng đồng loạt nhận ra rằng, hình như đơn thuốc không đúng bệnh. Khoa học đã làm một động tác thật cực kỳ đơn giản – thay đổi ngôn từ và bắt đầu nói lại cũng vấn đề đó, sự vật đó, giải pháp đó với một góc nhìn và ngôn ngữ khác. Cho nên ngày nay, khi các doanh nghiệp chúng ta đứng trước nhu cầu cải cách hệ thống quản lý, các nhà tư vấn về bản chất đang chào mời họ một tập hợp hổ lốn các giải pháp khó xác định được hiệu quả.
 
H

HyperVN

<b>Phu hót rác</b>
17/3/03
1,833
14
0
42
Hải Phòng
www.webketoan.vn
#3
Phí tổn thế nào?

Chi phí cho từng dự án cụ thể chúng tôi dành lại cho các doanh nghiệp tự tính toán. ở đây, chúng tôi muốn bàn kỹ hơn dưới góc nhìn vĩ mô: đất nước Nga phải tốn bao nhiều tiền để ứng dụng công nghệ quản lý mới?

Hai mươi năm trở lại đây, đời sống kinh tế thế giới có những biến đổi về chất. Người ta nói nhiều đến những giá trị lợi tức (rent). Hiểu một cách nôm na, lợi tức đó là thu nhập không làm mà có. Thông thường có ba loại lợi tức. Thứ nhất, lợi tức thiên nhiên – khoản này nước Nga đang có ưu thế vì đang chiếm tới 1/6 diện tích thế giới với nguồn tài nguyên giàu có. Thứ hai, lợi tức tài chính – món lợi này sẽ thuộc về quốc gia nào đã thuyết phục được cả thế giới sử dụng đồng tiền của mình làm phương tiện tích luỹ, thanh toán (Mỹ, châu Âu, Nhật ... nhưng chắc chắn không phải chúng ta). Thứ ba, gần đây người ta đưa ra một loại lợi tức nữa với cái tên rất đẹp: lợi tức trí tuệ. Nhưng nó không chỉ đẹp vì tên mà còn độc đáo bởi bản chất cấu thành. Nếu lợi tức thiên nhiên là sự may mắn tự nhiên của tạo hoá, lợi tức tài chính – là thành quả lao động không mệt mỏi của cả dân tộc, thì lợi tức trí tuệ sẽ thuộc về những ai thuyết phục được người khác tin rằng sản phẩm của họ làm ra là thông minh nhất. Một thuộc tính nổi bật của loại lợi tức này: chi phí để làm ra các sản phẩm trí tuệ có thể chênh lệch nhau hàng trăm lần, trong khi chi phí nhân bản sản phẩm coi như bằng không và bản thân sản phẩm không nhất thiết phải “trí tuệ” cho lắm, miễn là làm sao thuyết phục được một lượng người đủ lớn tin vào sự “trí tuệ” của nó là được.

Trở lại với thị trường tư vấn công nghệ thông tin. Chúng ta thấy 2/3 lợi tức trí tuệ trong lĩnh vực này nằm trong tay 5 đại gia: (PricewaterhouseCoopers, Andersen Worldwide, Ernst & Young, KPMG, và Deloitte & Touche) và khoảng chừng 30 công ty nữa. Họ kết hợp tạo nên hệ thống chuẩn quốc tế tương tự như chuẩn ISO, mà thiếu nó doanh nghiệp sẽ trở nên cô độc. Ví dụ nếu không có chứng chỉ kiểm toán hay chất lượng của các đại gia này bạn đừng hy vọng gì xông vào được thị trường vốn hay hàng hoá quốc tế. Tương tự như thế, mô hình EPR dần dần cũng được chuẩn hoá, tạo thành lá chắn bảo vệ lợi tức trí tuệ cho các công ty tư vấn. Theo nhà kinh tế học Mikhail Deliagin, trong thời đại toàn cầu hoá rất dễ xảy ra hiện tượng khi một vài nước, một vài công ty, thậm chí một vài cá nhân có thể hình thành cả một học thuyết, tôn giáo, hệ tư tưởng hay những mô hình khoa học, quản lý, cuốn hút mọi người đi theo một cách “tự nguyện - ép buộc”, tất nhiên là họ phải kiếm được một khoản tiền khá. Anh gọi đây là công nghệ metatechnology. Có thể nhận thấy hệ thống tiêu chuẩn và mẫu hình EPR trên là phiên bản của công nghệ meta trong quản lý, khi nhóm 5 đại gia đang thâu tóm và điều hành thị trường tư vấn thế giới.

Giá trị đích thực của lợi tức trí tuệ có thể nhìn thấy qua một so sánh đơn giản. Lấy hai sản phẩm: một phiên bản hệ điều hành Windows và mấy tấn dầu thô. Loại người vẫn sống tốt hàng chục thế kỷ nay không có hệ điều hành, nhưng nếu thiếu dầu mỏ (tài nguyên thiên nhiên) thì trái đất này sẽ ra sao? Với hệ điều hành chi phí sản xuất (tạo phiên bản) không thể đem so sánh được với chi phí khai thác một tấn dầu. Hai sản phẩm có ý nghĩa thực tế khác biệt, lại được thị trường đánh giá ngang nhau, chưa kể các chương trình phần mềm trước khi đến tay người tiêu dùng còn được kích giá thêm 3-4 lần.

Hiện nay các doanh nghiệp Nga cần ít nhất vài chục nghìn chương trình quản lý lớn. Trị giá một chương trình vào khoảng từ 0.5 đến 1.5 triệu USD. Tính sơ sơ chí phí cũng đã lên đến vài chục tỉ USD. Đã thế, sau khi cài đặt doanh nghiệp sẽ phải dính chặt vào nhà cung cấp dịch vụ, trường hợp cần thay đổi hoặc mở rộng kinh doanh đều phải chi thêm không ít tiền cho chương trình mới. Nhưng đây chỉ mới là chi phí trực tiếp. Chi phí gián tiếp còn cao hơn nhiều. Ai cũng biết các ông lớn trong ngành tư vấn sử dụng ngày càng nhiều chất xám từ nước Nga. Vô hình chung chúng ta đã trả tiền hai lần cho một sản phẩm. Nếu nhìn kỹ hơn ta sẽ thấy rõ cái giá mà nước Nga phải trả cho cuộc cách mạng quản lý hiện đại:

1. Trong thời gian tới đây, doanh nghiệp Nga sẽ đầu tư hàng chục tỉ USD để phát triển nền công nghiệp thông tin và tư vấn của nước ngoài. Số tiền này đáng ra có thể sử dụng rất hiệu quả để thúc đẩy ngành IT trong nước.

2. Một phần số tiền này sẽ được sử dụng để kêu gọi, mời chào chất xám từ nước Nga. Một hình thức mỡ nó rán nó. Nhưng quan trọng hơn là nước Nga dần dần sẽ trở thành đất nước xuất khẩu nhân lực khoa học tương tự như ta đang xuất khẩu dầu mỏ hiện nay.

3. Độc quyền do nhờ công nghệ metatechnology sẽ là nguyên nhân làm giảm chất lượng các hệ thống ERP, đồng thời giữ nguyên giá thành ở mức độ cao ngất trời.

4. Doanh nghiệp Nga sẽ phụ thuộc hoàn toàn vào công nghệ quản lý từ nước ngoài với 70% sác xuất không thành công.

5. Ngành khoa học quản lý của Nga sẽ không có cơ hội phát triển vì không được đầu tư cũng như khó có khả năng thực nghiệm.

6. Toàn bộ ngành tư vấn dịch vụ trong nước sẽ chuyển thành người trung chuyển công nghệ của nuớc ngoài, sống nhờ và phụ thuộc hoàn toàn vào họ.

7. Nguy cơ ảnh hưởng an ninh thông tin – kinh tế quốc gia. Toàn bộ các hệ thống ERP hiện hành đều có mã nguồn đóng. Không ai có thể biết nó còn có thêm những chức năng phụ nào nữa?

Có cái để bàn

Chúng tôi nghĩ, đề tài trên đây thật có nhiều cái đáng phải bàn. Nhưng quan trọng nhất là chúng ta đừng lôi nhau vào những cuộc tranh cãi vụn vặt, đánh đố nhau về công nghệ, từ ngữ chuyên môn, hay tồi tệ hơn là sử dụng nguyên tắc “chính anh ngu thì có!”. Cần phải suy nghĩ thật nghiêm túc, bởi vấn đề ảnh hưởng trực tiếp đến tương lai đất nước Nga. Còn nếu cứ chặc lưỡi buông xuôi: ta không vào vũ trụ thì người khác vào; không dùng của ta thì dùng của người... thì đất nước này, nhà máy này, đồng tiền này không phải của ta thì sẽ của ai? ª

Nguyễn Văn Minh
(Lược dịch và giới thiệu)
 
P

PAT

PAT
10/12/04
287
3
18
56
Ho chi Minh city
#5
Mình cũng đã đọc bài nói về đầu tư của Nga cho hệ thống ERP này rồi. Thực sự mình cũng chưa đủ tầm để đánh giá nó hay/dở nhưng cũng có một vài ý kiến chủ quan :

1. Tác giả muốn cổ xúy cho các giải pháp tự phát triển từ nội tại nước Nga nhiều hơn là quá phụ thuộc và chạy theo các giải pháp của nước ngoài - Đặc biệt là Mỹ.

2. Ghi nhận tỷ lệ thất bại tương đối cao khi đưa ERP áp dụgn vào nước Nga.

Tuy nhiên một trong những khía cạnh mà tác giả chưa nêu kỹ càng nguyên do thất bại nằm ở đâu. Cá nhân PAT đánh giá một phần là ở chỗ : Hệ thống quản lý cũ kỹ, sức ì của nền kinh tế kế hoạch hóa gần 100 năm của Nga không dễ gì xóa bỏ nhanh được và vì thế áp dụng các mô hình quản lý có tính quy trình, thủ tục nghiêm ngặt như ERP sẽ dễ thất bại

Nếu bạn nào có dịp tiếp xúc & thử so sánh hai phong cách quản lý và tác phong của từng con người của các đơn vị liên doanh sản xuất và khai thác dầu khí phía Nam Việt nam là các bạn sẽ thấy ngay điều này.
 
T

tuanna_itsoft

Thành viên sơ cấp
13/10/05
55
0
0
43
Dân "du mục"
www.itjsc.com.vn
#6
Bác PAT ơi

Trong diễn đàn này bác là người có nhiều kinh nghiệm nhất, bác chia sẻ cho mọi người cùng tham khảo những kinh nghiệm của bác đi. Công ty tôi bây giờ mới "tập tẹ", gọi là ERP thì cũng không dám, "chẳng biết gọi nó là gì nữa". Theo PAT thì ngoài những vấn đề mà Hyper_vn đưa ra, còn gì nữa không??? tôi thấy mình thiếu nhiều thứ quá :0frown:
 
P

PAT

PAT
10/12/04
287
3
18
56
Ho chi Minh city
#7
tuanna_itsoft nói:
Trong diễn đàn này bác là người có nhiều kinh nghiệm nhất, bác chia sẻ cho mọi người cùng tham khảo những kinh nghiệm của bác đi. Công ty tôi bây giờ mới "tập tẹ", gọi là ERP thì cũng không dám, "chẳng biết gọi nó là gì nữa". Theo PAT thì ngoài những vấn đề mà Hyper_vn đưa ra, còn gì nữa không??? tôi thấy mình thiếu nhiều thứ quá :0frown:
Từ phía NCC Việt Nam theo mình là gồm có một số nguyên nhân cơ bản sau :

1. Từ phần sản xuất phát triển sản phẩm :

1.1 Chưa hình thành một quy trình chuyên nghiệp trong khi phát triển giải pháp. Đặc biệt là các kiến thức chuyên gia (enginering) về quản trị DN khi phân tích hệ thống. Rất nhiều trường hợp đi từ một đơn hàng nào đó với một khách hàng cụ thể nào đó nên sản phẩm không có tầm rộng khi phân tích - Từ đó khi tổng quát hoá về quản trị DN thường bị thiếu nghiệp vụ. Đồng thời sản phẩm khi phát triển lớn lên khó kiểm soát chất lượng cũng như cấu trúc giải pháp.

1.2 Chưa chú trọng cấu trúc phần mềm (Software Architecture) khi phân tích thiết kế giải pháp - Từ đó cũng dẫn đến tình trạng khi hệ thống lớn lên các cấu trúc thiết kế ban đầu bị phá vỡ hoặc khó kiểm soát các nghiệp vụ bổ sung. Chỉ bàn riêng về cái này cũng tốn khá nhiều thời gian đấy. Đôi khi mình caafn phải được làm gia công cho nước ngoài rồi thì mới "vỡ" ra được các vấn đề. Ví dụ như vấn đề tổ chức các lớp Midleware - các lớp giao diện và đặc biệt là các vấn đề về bảo mật và an ninh (Security) của hệ thống

1.3 Thiếu cách nhìn của End-User trong quá trình thiết kế từ đó gây khó khăn cho thao tác vận hành ( Tuy nhiên vấn đề này cũng có hai mặt của nó vì thường những người ở mức End-User hay đòi hỏi các tiện ích "tùy tiện" mà không chịu tuân theo quy trình)

1.4 Chưa hình thành quy trình testing chuyên nghiệp cho sản phẩm của mình. Mặt khác vì mong muốn tung sản phẩm ra sớm nên thiếu hẳn những chuẩn mực Test alpha, test beta và vì vậy sản phẩm bị lỗi khi đưa xuống Implement cho khách hàng. Theo nhận xét của PAT một số công ty software hiện nay biến khách hàng thành một test lab của mình trong quá trình triển khai. Từ đó dẫn đến tình trạng sai đâu sửa đấy -> sửa đâu phát sinh lỗi tiếp -> tiếp tục sửa .... Kéo dài dự án gây mệt mỏi cho cả hai bên.

Một vài ý kiến ban đầu về nguyên nhân từ đơn vị làm software ( PAT đang nói về các vendor của VN đấy nhé )
 
T

the7habitsman

Thành viên sơ cấp
10/9/05
89
0
0
Hà nội
#8
Bác PAT quả là tuyệt vời đấy. Một người rất có tâm huyết và hình như chỉ có những người làm phần mềm mới hiểu được phần 1.2, 1.3 và 1.4 của bác. Khốn nỗi, các DN Việt nam thì bé tý tẹo. Người có tầm quản lý, làm KD thì lại ít biết về công nghệ, về quy trình SXPM nó đang ở đâu và tầm quan trọng, tầm ảnh hưởng của công nghệ, của quy trình SXPM đối với 1 SP True ERP nó có tính sống còn thế nào trên thị trường (à, dĩ nhiên còn các yếu tố khác nữa). Còn người làm technical thì thường (chỉ nói là thường thôi nhé, ko phải tất cả) ít có đầu óc tổ chức, v.v... Thế nên, việc quản lý ở các công ty PM, công với chuyện vốn là cực kỳ quan trọng. Mấy công ty con con như chúng em dù có là dân chuyên gia về công nghệ, chuyên gia về quy trình PM nhưng vốn thì ít, người thì hẻo, mà SP thì lại phải nhanh ra thị trường... thì lấy đâu ra resources để thực hiện các bác nhỉ? :)

Mấy cái việc "Ví dụ như vấn đề tổ chức các lớp Midleware - các lớp giao diện và đặc biệt là các vấn đề về bảo mật và an ninh (Security) của hệ thống" rồi "quy trình testing chuyên nghiệp cho sản phẩm" là em cũng khoái và có chút ít "vốn liếng" hiểu biết về nó. Dân IT nghĩ mà thèm quá. Ko đủ resources để thực hiện các cái mơ ước của mình.

Anh Tuấn à, thực ra em nói đó là nói lên tình trạng của các cty làm PM KT Việtnam (mà nay đang là làm phần mềm ... ERP) đó bác ạ. Ở chỗ em, 1 phòng SP thôi cũng phải đến 50 hay 60 người (thế chưa phải là nhiều đâu) - Nhưng đó có thể là con số về nhân lực gấp đôi 1 số các công ty làm phần mềm KT (nay là ERP) khác rồi đấy bác ạ. Em nhìn mà thèm lắm.

Hiện nay, trên thị trường còn có nhiều quan điểm khi giới thiệu SP cho khách hàng: Mèo trắng, mèo đen ko quan trọng - Miễn là bắt được chuột.

Dịch là: Công nghệ cao hay thấp ko quan trọng - miễn là ... bán được (và thỏa mãn yêu cầu hiện thời của khách hàng). E...lại đang phải học cái quan điểm này đấy bác ạ :(
 
T

the7habitsman

Thành viên sơ cấp
10/9/05
89
0
0
Hà nội
#9
À, ở SAP em thấy bọn nó đề cao cái Invest vào RD lắm. Nó nói cái đó là 1 trong các nguyên nhân làm tăng TCO của khách hàng. Không biết ở ta khi đi tư vấn có ai nói về TCO ko nhỉ? hay là chỉ cố mà giảm giá thật mạnh để bán bằng được SP thôi (nhiều khi budget khách hàng chỉ có vậy, nhưng vẫn phải có đủ mọi thứ :)).

:)
 
erpvn

erpvn

Don't know what is erp!
28/1/04
416
0
16
42
Miền đất hứa
www.erpvna.com
#10
Triển khai như bác Tangtd có mà chết à, cái methodology triển khai sp của bác vứt đâu mà thảm vậy?
 
C

cá ngão

Thành viên sơ cấp
20/7/05
9
0
0
#11
Nói như pác erpvn thì khó quá, nếu khách hàng cứ không chịu nghe thì làm thế nào. TGĐ của họ nói mà họ còn không nghe nữa thì sao (đấy là tôi giả sử thế). các phòng ban vẫn cứ đá nhau thì làm thế nào. Bởi vì họ mâu thuẫn với nhau từ trước, đợi cái vụ erp này là bùng phát mà.
 
Q

qingsong

Thành viên sơ cấp
21/7/05
18
0
0
48
Germany
#12
Hình như các nhà cung cấp ERP đều đang e sợ sự thất bại, cả PAT và TANGTD đều đúng, các bác chỉ quan tâm đến phần mềm và giải pháp chứ không quan tâm đến người sử dụng (enduser) như chúng em. Các bác chỉ biết đưa sản phẩm vào và phải theo mô hình này nọ nhưng các bác có biết khi đưa một dự án ERP vào thì cái gọi là "tinh giảm" sẽ ra sao không, đấy chưa kể là một số công ty khi đã có IT manager (chuyên về IT) thì sao hiểu được cái vụ ERP, họ chỉ hiểu được mỗi vấn đề công nghệ, chứ đâu hiểu được nghiệp vụ. Cái này thì quá rõ ràng, ý thức của các nhà lãnh đạo "VN" là chọn IT manager là phải chọn thằng về IT chứ các nghiệp vụ quản trị thì đã có các bộ phận khác, chắc điều này làm cho các nhà cung cấp ERP phải mệt lắm đây. Khách hàng đương nhiên là khách hàng chứ không phải là Tester cho các nhà cung cấp ERP, vì vậy dự án kéo dài thì chẳng sai chút nào. Bravo PAT, bác lên tiếng đúng lúc giúp người dùng như em đỡ mệt hơn mấy phần. :banana:
 
T

tuanna_itsoft

Thành viên sơ cấp
13/10/05
55
0
0
43
Dân "du mục"
www.itjsc.com.vn
#13
E ngại gì chứ, chẳng sợ chút nào đâu bác qingsong ơi!!! Cứ làm cho nó máu, dù sao thì đây cũng là thời gian tích lũy kinh nghiệm mà, tận dụng được bao nhiêu cứ tận dụng.
Ở chỗ em cũng có phòng TEST nhưng chưa đạt được mức cao "siêu" như mấy ông làm Quản trị hay tư vấn gì đó. mỗi người một mảng sau đó nhờ một ông manager được đào tạo, ăn ngủ bên tây chuyên về ERP ghép nối, nói chung cũng đỡ hơn cho enduser. Còn khách hàng, lúc đầu khỏi cần có IT manager, bọn em làm luôn được khoảng 6 tháng, vừa đủ tuyển chọn và đào tạo cho 1 IT manager cho khách hàng thế là OK, em rút.
Bác PAT và mấy bác ơi hay mình mở thêm một chủ đề ERP-TESTER, em thấy cái này cũng hay, anh em cùng chia sẻ kinh nghiệm TEST để cùng nhau phát triển một môi trường phần mềm hoàn chỉnh để tranh đấu với bọn phần mềm nước ngoài. Các bác cho ý kiến :dzo:
 
P

PAT

PAT
10/12/04
287
3
18
56
Ho chi Minh city
#14
TANGTD nói:
Các bác cứ mải nói đến nhà cung cấp mà không chịu đề cập đến phía khách hàng. Mình cũng đang tham gia triển khai ERP là người làm ra sản phẩm và mang nó đi triển khai mình thấy khó khăn về sản phẩm, quy trình, nghiệp vụ không có gì đáng ngại. Mà đáng ngiạ chính là những con người tiếp quản chúng(ERP). Có thể có nhiều lý do nhưng lý do khách hàng theo mình quả là đáng kể
Việc khó ở đây theo mình là các phòng ban của khách hàng không chịu ngồi vào bàn cùng nhau. Phòng kế toán một kiểu Mua bán một kiểu... chẳng ông nào chịu ông nào cả. Đã nói đến triển khai ERP là phải đồng bộ, giữa các phòng ban tham gia phải phối hợp với nhau một cách thật nhịp nhàng thì may ra mới có cơ hội cho ERP thành công được. Mình đang triển khai cho một công ty của nhật đây là một công ty lớn thế mà phòng kế toán và phòng Purchase không chịu ngồi vào bàn cùng nhau. Hệ thống khách hàng, vật tư mỗi ông một kiểu chẳng ông nào chịu ông nào cả. Và cuối cùng thì mỗi ông làm một mảng độc lập thử hỏi như thế thì còn gì là ERP nữa.
Mình là người mang sản phẩm đi triển khai thực sự mình không thấy sợ phải sửa đổi, phải tìm hiểu nghiệp vụ, nhưng về phía khách hàng thì quả thật là quá kho.
Khách hàng là thượng đế mà. Các ngài muôns thế nào thì đành chịu vậy thôi
Thực ra khái niệm KH là thượng đế trong áp dụng triển khai ERP không đúng nữa rồi. PAT thì thẳng thắn luôn ngay từ khi chưa ký kết hợp đồng: Mặc dù tôi là người cung cấp giải pháp cho các bạn. Đúng là các bạn trả tiền cho tôi nhưng các bạn cũng phải nỗ lực gần bằng hoặc thậm chí bằng tôi thì mới có khả năng thành công trong áp dụng ERP.

Mình nghĩ một phần cũng vì do khách hàng nhưng một phần cũng do nhà cung cấp chưa có phương pháp luận tốt để có thể đặt vấn đề rõ ràng ngay từ đầu và vì vậy gây ngộ nhận cho khách hàng. Theo kinh nghiệm của mình khi đã dặt vấn đề như vậy thì triển khai dễ dàng hơn nhiều. Tuy nhiên lúc này cũng phải nói rằng NCC rất tin tưởng vào tính năng của sản phẩm và thực tế là tính năng của sản phẩm phải đủ mạnh thì mới thuyết phục được khách hàng đi theo cách như vậy được.
 
phamcung

phamcung

Thành viên sơ cấp
30/9/05
378
12
0
Hanoi
#15
một câu hỏi

Mình không phải dân ERP, có một số câu hỏi sau để làm rõ thêm:

1. Nếu như trong quá trình design mà tư vấn thấy là quy trình kinh doanh là bất hợp lý, hoặc nghiêm trọng hơn, định hướng kinh doanh của khách hàng là bất hợp lý (ví dụ thị trường, kênh phân phối, khách hàng), thì tư vấn ERP có đề xuất thay đổi với khách hàng hay không, hay sẽ cho là out of scope? Ý mình là các bạn ERP có làm cả BPR- Business Process Reengineering không hay chỉ bó hẹp trong phạm vi ứng dụng?

2. Nếu như câu trả lời là No, thì nghĩa là tư vấn ERP sẽ phải thay đổi chương trình của mình để phù hợp với khách hàng và có nghĩa là sẽ dẫn tới khả năng là mặc dù chương trình của mình chạy tổt, phù hợp với khách hàng, nhưng hiệu quả có thể sẽ không tối ưu (vì quy trình kinh doanh vốn dĩ đã không tốt), nếu vậy thì giải pháp khắc phục là gì?

3. Nếu như câu trả lời là Yes, thì phạm vi tư vấn sẽ mở rộng, lúc ấy các bạn làm ERP các bạn có làm được cái việc thay đổi stratey không hay chỉ dửng mở mức operational?

Theo mình, ERP nên đi kèm vơi BPR, không biết có phải luôn luôn như vậy không?
 
T

the7habitsman

Thành viên sơ cấp
10/9/05
89
0
0
Hà nội
#16
Theo mình, ERP nên đi kèm vơi BPR, không biết có phải luôn luôn như vậy không?
Về mặt tư vấn ERP mà nói, BPR cũng là 1 phần công việc của các nhà tư vấn ERP. Như bác PAT đã nói rồi đấy:
Thực ra khái niệm KH là thượng đế trong áp dụng triển khai ERP không đúng nữa rồi. PAT thì thẳng thắn luôn ngay từ khi chưa ký kết hợp đồng: Mặc dù tôi là người cung cấp giải pháp cho các bạn. Đúng là các bạn trả tiền cho tôi nhưng các bạn cũng phải nỗ lực gần bằng hoặc thậm chí bằng tôi thì mới có khả năng thành công trong áp dụng ERP.
Việc bác PAT thẳng thắn nói như vậy là bác ấy rất tin tưởng vào giải pháp mình đưa ra cho khách hàng.

Nhân tiện đây mình cũng attach luôn 3 cái images có show những gì liên quan đến BPR trong 1 dự án ERP. (hic, lâu lắm rồi ko động đến món này nữa)
 

Đính kèm

P

PAT

PAT
10/12/04
287
3
18
56
Ho chi Minh city
#17
phamcung nói:
Mình không phải dân ERP, có một số câu hỏi sau để làm rõ thêm:

1. Nếu như trong quá trình design mà tư vấn thấy là quy trình kinh doanh là bất hợp lý, hoặc nghiêm trọng hơn, định hướng kinh doanh của khách hàng là bất hợp lý (ví dụ thị trường, kênh phân phối, khách hàng), thì tư vấn ERP có đề xuất thay đổi với khách hàng hay không, hay sẽ cho là out of scope? Ý mình là các bạn ERP có làm cả BPR- Business Process Reengineering không hay chỉ bó hẹp trong phạm vi ứng dụng?

2. Nếu như câu trả lời là No, thì nghĩa là tư vấn ERP sẽ phải thay đổi chương trình của mình để phù hợp với khách hàng và có nghĩa là sẽ dẫn tới khả năng là mặc dù chương trình của mình chạy tổt, phù hợp với khách hàng, nhưng hiệu quả có thể sẽ không tối ưu (vì quy trình kinh doanh vốn dĩ đã không tốt), nếu vậy thì giải pháp khắc phục là gì?

3. Nếu như câu trả lời là Yes, thì phạm vi tư vấn sẽ mở rộng, lúc ấy các bạn làm ERP các bạn có làm được cái việc thay đổi stratey không hay chỉ dửng mở mức operational?

Theo mình, ERP nên đi kèm vơi BPR, không biết có phải luôn luôn như vậy không?
Theo PAT vấn đề này có hai khả năng xẩy ra :

Khả năng một : Một đơn vị tư vấn độc lập tham gia vào quá trình xây dựng và triển khai tại DN thì họ sẽ làm công việc BPR này và cùng với DN thực thi reengineering trước khi đưa hệ thống phần mềm vào áp dụng. Quá trình này độc lập với giải pháp phần mềm. Sau khi reengineering đơn vị tư vấn sẽ xem xét phần mềm nào có tính năng đầy đủ nhất và gần với các quy trình đã thống nhất để lựa chọn ( Dù có đầy đủ nhất thì vẫn có một phần customize thêm).

Khả năng hai - Nhà cung cấp làm luôn việc này : Đã là NCC giải pháp ERP đúng nghĩa của từ này thì việc tư vấn giải pháp thường được NCC đảm trách luôn (kể cả các giải pháp nước ngoài). Lúc đó chỉ thay thế vai trò tư vấn độc lập bằng NCC mà thôi – Công việc vẫn như vậy. Chỉ có đặc thù hơi khác là lúc đó xây dựng BPR cho DN là áp đặt luôn quy trình nghiệp vụ vốn có trong giải pháp để DN thực thi. Trong trường hợp bản thân quy trình của KH đã tốt và tối ưu thì NCC phải giữ nguyên và đưa vào hệ thống. Các công việc này NCC phải tính luôn chi phí này vào trong quá trình triển khai giải pháp nên cái này không gọi là out of scop được.

Với khả năng thứ hai sẽ xuất hiện vấn đề là tính năng giải pháp, kinh nghiệm của NCC có đủ ở đẳng cấp là nhà tư vấn hay không thì mới đủ sức thuyết phục và “bắt” khách hàng đi theo mình. Các giải pháp ERP lớn thường dễ dàng đạt được điều này nhờ chuẩn thiết kế theo dạng Open System với hệ thống parameter mạnh. Các nghiệp vụ sẽ được mapping xuống giải pháp theo các quy trình nghiệp vụ. ( Thực ra mình cứ nói là KH chưa có quy trình là không đúng mà nói là các quy trình chưa được chuẩn hóa để tối ưu thì đúng hơn). Theo kinh nghiệm của PAT thì KH không phải khó tính đâu. Sẽ không bao giờ KH nói No nếu như mình nêu rõ được sự bất hợp lý và tổn thất của bất hợp lý ảnh hưởng đến hiệu quả hoạt động sản xuất kinh doanh của họ .

Đùa vui một tý nhưng các bạn đừng nâng lên thành quan điểm nhé : Làm ERP mà không bắt khách hàng đi theo mình thì không là làm ERP nữa rồi.

PAT
 
phamcung

phamcung

Thành viên sơ cấp
30/9/05
378
12
0
Hanoi
#18
To 7habit...: Cái mà bác attach vào trong scope of work là Business Process Reviewing chứ không phải là Business Process Reengineering.

Một doanh nghiệp không nhất thiết lúc nào cũng phải làm BPR trước khi làm ERP vì BPR là một quy trình to tướng "fundamental rethinking and radical re-design of business processes to achieve dramatic improrevement"- (Michael Hammer and James Chapy). Nếu chỉ thay đổi chút chút trong quá trình kinh doanh thì không thể coi là BPR. ERP theo mình hiểu chỉ là một công cụ nhằm hỗ trợ cho DN làm ăn có hiệu quả hơn. Một DN có thể làm BPR cần hoặc không cần có ERP, cũng như ngược lại, một doanh nghiệp triển khai ERP có thể trong quá trình làm BPR hoặc không. Ở đây đồng ý với bác Phí Anh Tuấn là nếu trong quá trình triển khai ERP mà mình phân tích được những mặt lợi cho khách hàng thì mình cũng nên làm, nhưng như đã nói ở trên BPR là một quá trình lớn, tốn kém, liệu ERP consultant có nên "đá lấn sân" của BPR không? Và trong thực tế, theo kinh nghiệm triển khai của mọi người làm ERP mọi người đã từng làm BPR chưa?
 
T

the7habitsman

Thành viên sơ cấp
10/9/05
89
0
0
Hà nội
#19
phamcung nói:
To 7habit...: Cái mà bác attach vào trong scope of work là Business Process Reviewing chứ không phải là Business Process Reengineering.

Một doanh nghiệp không nhất thiết lúc nào cũng phải làm BPR trước khi làm ERP vì BPR là một quy trình to tướng "fundamental rethinking and radical re-design of business processes to achieve dramatic improrevement"- (Michael Hammer and James Chapy). Nếu chỉ thay đổi chút chút trong quá trình kinh doanh thì không thể coi là BPR. ERP theo mình hiểu chỉ là một công cụ nhằm hỗ trợ cho DN làm ăn có hiệu quả hơn. Một DN có thể làm BPR cần hoặc không cần có ERP, cũng như ngược lại, một doanh nghiệp triển khai ERP có thể trong quá trình làm BPR hoặc không. Ở đây đồng ý với bác Phí Anh Tuấn là nếu trong quá trình triển khai ERP mà mình phân tích được những mặt lợi cho khách hàng thì mình cũng nên làm, nhưng như đã nói ở trên BPR là một quá trình lớn, tốn kém, liệu ERP consultant có nên "đá lấn sân" của BPR không? Và trong thực tế, theo kinh nghiệm triển khai của mọi người làm ERP mọi người đã từng làm BPR chưa?
À, nếu BPR là như vậy có lẽ cứ để các bác khách hàng tự làm (hoặc là đi thuê tư vấn gì gì đó) cái to tát (ISO hay BPR...) của các bác ấy trước đi đã.

Nhân tiện gửi phamcung cái Application Implementation Overview của phương pháp triển khai AIM của Oracle eBusiness Suite Application để tham khảo xem mấy chú ERP Consultants phải làm gì nhé. (Lúc khác post cái của SAP lên sau)
 

Đính kèm

Sửa lần cuối:
T

tuanna_itsoft

Thành viên sơ cấp
13/10/05
55
0
0
43
Dân "du mục"
www.itjsc.com.vn
#20
phianhtuan nói:
Thực ra khái niệm KH là thượng đế trong áp dụng triển khai ERP không đúng nữa rồi. PAT thì thẳng thắn luôn ngay từ khi chưa ký kết hợp đồng: Mặc dù tôi là người cung cấp giải pháp cho các bạn. Đúng là các bạn trả tiền cho tôi nhưng các bạn cũng phải nỗ lực gần bằng hoặc thậm chí bằng tôi thì mới có khả năng thành công trong áp dụng ERP.

Mình nghĩ một phần cũng vì do khách hàng nhưng một phần cũng do nhà cung cấp chưa có phương pháp luận tốt để có thể đặt vấn đề rõ ràng ngay từ đầu và vì vậy gây ngộ nhận cho khách hàng. Theo kinh nghiệm của mình khi đã dặt vấn đề như vậy thì triển khai dễ dàng hơn nhiều. Tuy nhiên lúc này cũng phải nói rằng NCC rất tin tưởng vào tính năng của sản phẩm và thực tế là tính năng của sản phẩm phải đủ mạnh thì mới thuyết phục được khách hàng đi theo cách như vậy được.
Chính xác, như PAT nói, khách hàng nhiều khi là thượng đế nhưng khi triển khai hoặc bán sản phẩm ERP, điều đó không còn có ý nghĩa nhiều nữa, chúng ta là nhà cung cấp phải tự đề cao mình với khách hàng chứ, tất nhiên sản phẩm hoặc dịch vụ của chúng ta phải đạt được tiêu chuẩn của ERP. Nếu một nhà cung cấp chỉ chạy theo khách hàng mà không có tính áp đặt lên họ, thì công việc triển khai sẽ kéo dài ....vô tận. Chính vì một phần chúng ta (NCC), không tự tin vào sản phẩm của mình, nói cách khác tính áp đặt của chúng ta chưa cao. Cứ như công ty chúng tôi, khách hàng khi đã chấp nhận chọn chúng ta là nhà cung cấp thì phải chấp nhận toàn bộ cách tư vấn (tất nhiên không vượt quá quy mô của khách hàng), sản phẩm vì họ có nhiều thời gian để lựa chọn
 

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

  • Huyen2971991KT
  • NgocNguyen.s2
  • cando

Xem nhiều