lang thang

Chu trình triển khai ERP

1.1 THỰC HIỆN TIỀN ĐỊNH GIÁ (PRE-EVALUATION SCREENING)
2.1 ĐỊNH GIÁ TRỌN GÓI (PACKAGE EVALUATION)
3.1 LẬP KẾ HOẠCH DỰ ÁN (PROJECT PLANNING)
4.1 PHÂN TÍCH SỰ KHÁC BIỆT (GAP ANALYSIC)
4.2 TÁI CẤU TRÚC (REENGINEERING)
4.3 CẤU HÌNH HỆ THỐNG (CONFIGURATION)
4.4 ĐÀO TẠO ĐỘI TRIỂN KHAI (IMPLEMENTATION TEAM TRAINING)
4.5 KIỂM TRA, THỬ NGHIỆM (TESTING)
4.6 ĐÀO TẠO NGƯỜI SỬ DỤNG (END-USER TRAINING)
5.1 CHẠY THẬT HỆ THỐNG (GOING LIVE)
6.1 HẬU TRIỂN KHAI (POST-IMPLIMENTATION)


1.1 THỰC HIỆN TIỀN ĐỊNH GIÁ (PRE-EVALUATION SCREENING)

Khi một công ty quyết định triển khai hệ thống ERP thì việc nghiên cứu để có được phần mềm trọn gói (package) hoàn hảo bắt đầu. Nhưng có đến hàng trăm nhà cung cấp ERP với nhiều hình dạng và quy mô khác nhau – tất cả những yêu cầu cần thiết để có được giải pháp lý tưởng cho bạn. Phân tích toàn bộ các package trước khi đi đến quyết định không phải là một giải pháp dể dàng thực hiện được. Đó là quá trình tốn rất nhiều thời gian. Vì vậy tốt hơn, bạn giới hạn bớt con số của package định giá ít hơn 5. Tốt nhất là luôn luôn định giá tỉ mỉ chi tiết một con số nhỏ của package hơn là chỉ phân tích hàng tá các package một cách chung chung. Vì thế công ty nên tiến hành định giá trước để giới hạn con số của package vốn phải được định giá bởi Ban đánh giá. Không phải tất cả các ERP package đều như nhau, mỗi package đều có những điểm mạnh và yếu điểm của nó. Quá trình tiền định giá sẽ loại bỏ các ERP package không phù hợp hoàn toàn với quy trình kinh doanh của công ty. Có thể xem xét một vài packages tốt nhất bằng cách đọc các tài liệu sản phẩm của những nhà cung cấp, nhờ các chuyên gia tư vấn bên ngoài và quan trọng nhất là tìm ra được package mà được sử dụng bởi những công ty có hoạt động tương tự như công ty của bạn. Và thật sự tốt hơn là tìm ra các package đó khác như thế nào đang thể hiện trong một môi trường hoạt động tương tư.

Nếu nghiên cứu kỹ nguồn gốc của ERP package và biết được mỗi package phát triển như thế nào, thì chẳng mấy chốc chúng ta sẽ thấy rõ mỗi ERP package phát sinh ra từ kinh nghiệm hay cơ hội của một nhóm người làm việc trong một ngành kinh doanh cụ thể, những người tạo ra hệ thống để giải quyết một phần công việc nào đó. Điều đó được nhận định chung rằng hầu hết ERP package sẽ mạnh hơn ở các lĩnh vực “lợi thế” của họ hơn là ở những lĩnh vực khác. Và mỗi package cố gắng hết sức thêm vào các chức năng trong các lĩnh vực mà họ còn khiếm khuyết. Chẳng hạn, PeopleSoft mạnh về quản trị nhân sự, nhưng lại không mạnh trong quản trị sản xuất, mặt khác, Baan thì mạnh về quản lý sản xuất hơn là tài chính kế toán,…

Các công ty phát triển, lớn mạnh hơn theo thời gian và các ERP package cũng vậy. Kinh nghiệm có được từ việc triển khai, những phản hồi từ phía người sử dụng, nhu cầu xâm nhập vào các thị trường mới và áp lực từ các đối thủ cạnh tranh đã buộc hầu hết các nhà cung cấp ERP xác định lại và mở rộng phạm vi hoạt động và chức năng sản phẩm của họ. Các khái niệm được mở rộng trước, các chức năng mới được giới thiệu, các ý tưởng hay được sao chép lẫn nhau,… Nhưng hơn nữa, mỗi ERP package có nguồn gốc có thể xác định được ngành nghề kinh doanh nào phù hợp nhất với nó.

Trong khi phân tích, sẽ là một ý kiến hay nếu điều tra nghiên cứu các căn nguyên (nguồn gốc) của các package khác nhau. Bây giờ, hầu hết các package phục vụ cho các ngành nghề kinh doanh và các lĩnh vực dịch vụ. Sẽ sai lầm khi cho rằng đó là một hệ thống, ban đầu, được phát triển chỉ để áp dụng cho sản xuất, giờ đây sẽ không đủ khả năng phục vụ các nhu cầu trong các lĩnh vực kinh doanh khác, chẳng hạn như phát triển phần mềm. Hệ thống sẽ được sưã chữa và thiết kế lại một cách tỉ mỉ để phục vụ cho các nhu cầu trong các lĩnh vực kinh doanh đa dạng mà nó sẽ phục vụ. Nhưng nên nhớ rằng rất nhiều ERP package vẫn chạy tốt trong một vài lĩnh vực khác thậm chí vẫn có khả năng phục vụ nhu cầu của các lĩnh vực khác.

2.1 ĐỊNH GIÁ TRỌN GÓI (PACKAGE EVALUATION)

Quá trình chọn/định giá là một trong những giai đoạn quan trọng nhất khi thực thi ERP vì package mà được chọn sẽ quyết định thành công hay thất bại của dự án. Trong khi các hệ thống ERP đòi hỏi sự đầu tư lớn, thì một khi package đã được mua, sẽ thật không phải là chuyện dễ để chuyển ngay qua một package khác. Vì thế nó là lời tuyên bố “hãy làm đúng ngay từ đầu”!

Nhân tố quan trọng nhất nên nhớ trong đầu khi phân tích các package khác nhau là không có package nào hoàn hảo. Ý nghĩ đó cần thiết phải được mọi người trong nhóm đưa ra quyết định chọn lựa thấu hiểu. Mục tiêu của quá trình lựa chọn không phải là để xác định được package nào đáp ứng mọi yêu cầu. Mục tiêu đó là tìm được một package đủ linh động để đáp ứng các nhu cầu của công ty hay nói cách khác, một phần mềm có thể tuỳ biến để phù hợp tốt.

Khi đã xác định được package nào để định giá, công ty cần phải xác lập các tiêu chí lựa chọn cho phép định giá tất cả các package với quy mô như nhau. Để chọn được hệ thống tốt nhất, công ty nên nhận dạng được hệ thống nào đáp ứng với nhu cầu kinh doanh, phù hợp với tiểu sử công ty và những nhận định nào với thực tế kinh doanh của công ty. Khó có thể tìm được hệ thống phù hợp hoàn toàn với cách thức hoạt động của công ty, nhưng mục tiêu hướng tới làm tìm một hệ thống với sự khác biệt ít nhất.

Vài điểm mấu chốt quan trọng nên lưu ý khi đánh giá phần mềm ERP:

-Chức năng phù hợp với quy trình kinh doanh của công ty
-Mức độ tích hợp giữa các thành phần khác nhau của hệ thống ERP
-Sự linh động và khả năng thích ứng (scalability)
-Sự phức tạp
-Sự thân thiện với người sử dụng
-Triển khai nhanh chóng
-Khả năng hỗ trợ việc kiểm soát và hoạch định đa chiều
-Khả năng kỹ thuật chủ/khách, cơ sở dữ liệu độc lập, bảo mật
-Khả năng nâng cấp thường xuyên
-Số lượng sữa chữa theo yêu cầu
-Cơ sỡ hạ tầng hỗ trợ nội bộ
-Khả năng của các địa điểm tham khảo
-Tổng chi phí bao gồm: license, đào tạo, triển khai, bảo trì, sữa chữa (customization) và các yêu cầu về phần cứng

Nên thành lập chính thức một Ban lựa chọn hay đánh giá để thực hiện quá trình trên. Ban này bao gồm nhân sự từ các phòng ban khác nhau (chuyên gia chức năng), Ban giám đốc cấp cao (CIO hay COO) và các nhà tư vấn (các chuyên gia trọn gói). Ban tuyển chọn sẽ được tín nhiệm với trọng trách chọn package cho công ty. Khi tất cả các chức năng kinh doanh được trình bày với sự tham gia của Ban giám đốc thì package được chọn ra sẽ có được sự chấp thuận rộng rãi. Các chuyên gia hay các nhà tư vấn có thể đóng vai trò như những nhà trung gian hay đóng vai trò giải thích những điểm mạnh và yếu của mỗi package.

3.1 LẬP KẾ HOẠCH DỰ ÁN (PROJECT PLANNING)

Đây là giai đoạn thiết kế qui trình triển khai dự án. Giai đoạn này sẽ quyết định chi tiết triển khai như thế nào về lịch trình, thời hạn, … Kế hoạch dự án được bắt đầu. Xác định vai trò và phân công trách nhiệâm cho từng người. Các nguồn lực sử dụng cho việc triển khai được quyết định, những người đứng đầu để triển khai dự án được chỉ định. Các thành viên trong đội triển khai được lựa chọn và được phân công nhiệm vụ. Giai đoạn này sẽ quyết định khi nào bắt đầu dự án, thực hiện như thế nào và dự định khi nào hoàn tất dự án. Đây cũng là giai đoạn hoạch định “phải làm gì” trong trường hợp bất ngờ; làm sao giám sát được tiến trình triển khai; các phương thức kiểm soát nào nên được thiết lập và cần làm gì khi sự việc không còn nằm trong tầm kiểm soát. Kế hoạch dự án thường được lập bởi một Ban gồm các đội trưởng của các nhóm triển khai. Chỉ đạo Ban dự án ERP thường là CIO hay COO. Ban dự án ERP họp định kỳ trong suốt toàn bộ chu trình triển khai dự án để xem xét lại tiến trình và lập biểu đồ cho những hành động diễn biến tương lai.

4.1 PHÂN TÍCH SỰ KHÁC BIỆT (GAP ANALYSIC)

Có thể cho rằng giai đoạn này quyết định thành công hay thất bại cho quá trình triển khai dự án ERP. Nói một cách đơn giản, đây là tiến trình qua xuyên suốt của mô hình hoạt động hiện tai và định hướng mô hình trong tương lai. Cái hay là thiết kế một mô hình mà nó có thể đoán trước và bao gồm bất cứ chức năng thiếu sót nào. Người ta nhận định rằng, thậm chí một phần mềm ERP hòan hảo nhất cũng chĩ đáp ứng được 80% yêu cầu chức năng của công ty.

20% còn lại của những yêu cầu này là vấn đề tái cấu trúc qui trình kinh doanh của công ty (business process reengneering – Tái cấu trúc qui trình kinh doanh). Một trong những giải pháp thích ứng nhất cho dù đau đớn đó là đòi hỏi việc thay đổi kinh doanh để phù hợp với ERP package. Tất nhiên, một công ty có thể dễ dàng chấp nhận hoạt động mà không cần chức năng đặc thù (giải pháp rẻ nhưng bất lợi). Còn các giải pháp khác bao gồm:

- Hy vọng vào việc nâng cấp (chi phí thấp nhưng rủi ro)
- Xác định sản phẩm của bên thứ ba có thể lấp được kẻ hở (với hy vọng nó cũng tích hợp được với package ERP)
- Thiết kế chương trình theo sự đặt hàng
- Thay đổi mã nguồn ERP (đó là sự lựa chọn đắt giá, thường dành cho việc cài đặt sứ mạng khó khăn)

4.3 CẤU HÌNH HỆ THỐNG (CONFIGURATION)

Đây là phần chức năng chính của việc triển khai ERP. Ở đây có một chút bí mật về qui trình cấu hình hệ thộng và cho lý do tốt đẹp: Holy Grail hay quy tắc bất thành văn của triển khai ERP là: việc làm đồng bộ các hoạt động kinh doanh hiện tại trong công ty với ERP package hơn là thay đổi mã nguồn và chỉnh sữa (customization) để phù hợp với công ty. Để làm được như vậy, các qui trình kinh doanh phải được thấu hiểu và sắp đặt (ánh xạ – map) theo giải pháp phù hợp với mục tiêu chung của công ty. Nhưng các công ty không thể ngưng hoạt động khi diễn ra quá trình ánh xạ (mapping). Vì thế một nguyên mẫu – một sự mô phỏng các qui trình hoạt động thật sự của công ty - sẽ được sử dụng. Nguyên mẫu đó cho phép kiểm tra thử nghiệm toàn bộ một mô hình mong đợi trong một môi trường được kiểm soát. Vì các nhà tư vấn ERP định hình và thử nghiệm nguyên mẫu, họ cố gắng giải quyết bất kỳ vấn đề về lôgich vốn có trong BPR trước khi chạy hệ thống thật.

Cấu hình thể hệ thống công ty không những biểu lộ điểm mạnh của qui trình kinh doanh mà còn cả điểm yếu của nó. Điều đó vô cùng có lợi cho hoạt động của công ty cũng như để thành công trong triển khai ERP. Việc cấu hình hệ thống có thể giải thích và cho thấy những gì không phù hợp trong package đó và nơi nào xảy ra những khác biệt trong chức năng. Ví dụ, một công ty có thể có một hoạt động kế toán mà không thể cấu hình trong hệ thống hoặc một vài qui trình giao hàng không thích hợp với package. Công ty rỏ ràng cần biết những qui trình nào cần phải thay đổi trong tiến trình triển khai ERP. Công ty phải tự nhận biết những gì phải làm và những gì không yêu cầu trong qui trình kinh doanh của mình, và một khả năng là những nhân viên có kỹ nắng tốt sẽ được giao công việc này. Một nguyên tắc trong phần lớn các cuộc triển khai ERP là các chức năng cấu hình hệ thống được chia ra cho các bộ phận khác nhau trong công ty, ví dụ một vài sẽ chú trong đến HR, một vài sẽ liên quan đến tài chính, …

Các nhà cung cấp ERP rất cố gắng trong việc giảm thiểu chi phí cấu hình hệ thống. Các chiến lược được theo đuổi hiện nay là tự động hóa và tiền cấu hình. Baan chẳng hạn có phát triển Orgware – một công cụ cấu hình tự động, trong khi SAP tiền cấu hình bằng sử dụng công nghệ đặc biệt là các khuôn mẫu (template) cái này có thể tùy chỉnh cho mỗi công ty riêng biệt (Accelerated SAP Solutions).

Công nghệ ERP hiện tại đang hướng sự phát triển vào thị trường tầm trung làm giảm chi phí dự án, khuyến khích nhu cầu lớn các công ty cảm thấy đủ khả năng triển khai một ERP package hàng đầu. Bằng cách tạo ra một phân hệ tiền cấu hình ERP tùy chỉnh cho một công nghệ cụ thể - như thể là một nguyên mẫu phần mềm sản xuất tạo cho nhà sản xuất – nhu cầu chỉnh sửa sẽ giảm xuống, và như thế giữ được chi phí thấp. Hy vọng rằng dạng câu hỏi “question & answer” có thể được sử dụng để tìm ra các loại thông tin qui trình kinh doanh cho đến khi triển khai thông qua qui trình cấu hình hệ thống. Về mặt lý thuyết, những công cụ tiền cấu hình tiết kiệm được thời gian và tiền bạc, nhưng mỗi doanh nghiệp là độc nhất và ít nhất một vài cấu hình hệ thống là độc nhất cho từng dự án.

(Nguồn: Enterprise Resource Planning, Alexis Leon, 2000, Tata McGraw-Hill Publising Co. Ltd.)
(Translation by erpvn)

1. Giai đoạn chuẩn bị: Giai đoạn này rất quan trọng, nhưng thường bị rút ngắn thời gian. Lý do chính là sau khoảng thời gian thương thảo hợp đồng (sẽ rất căng thẳng), mọi người (kể cả nhà triển khai) thích tham gia ngay vào dự án mà không dành thời gian chuẩn bị đội ngũ, đả thông tư tưởng, xác định phạm vi cần triển khai, xác định vai trò thành viên đội dự án. Khung quản lý và các luật lệ riêng cho dự án cần được định nghĩa và có sự đồng tình của các thành viên trong đội dự án. “Mất lòng trước được lòng sau”, các trưởng dự án sẽ đề ra cách làm việc trong đội triển khai, giải thích về phạm vi dự án (đề phòng các “sáng kiến” mới trong thời gian thực hiện dự án và dự án sẽ kéo dài… vô tận). Các quy trình duyệt, chuyển giao, thời gian thành viên đội dự án có được nghiệm thu các chuyển giao từ nhà triển khai. Sự thay đổi vai trò của các thành viên đội dự án cũng cần được xác lập nhanh chóng. Ví dụ: ông xếp CFO có thể phải giữ một vai trò rất nhỏ trong dự án… Do đó, ông ấy sẽ phải làm quen với vai trò hỗ trợ một cách nhanh chóng. Về phía DN, người chủ đầu tư dự án, cần chuẩn bị tinh thần để thử nghiệm phần mềm với vai trò nghiệm thu dự án, kế hoạch nghiệm thu cũng cần bắt đầu từ các phạm vi dự án được đề ra ở giai đoạn này.


2. Giai đoạn định nghĩa các thay đổi (Change Definition): Giai đoạn này có tên khác nhau tùy vào phương pháp triển khai của nhà tư vấn triển khai: Business Blue Print, Gaps definitions, Solution Design… Nhưng nhìn chung, tất cả đều chú trọng vào các việc như: khảo sát hiện trạng môi trường làm việc từ cơ cấu tổ chức, cách sắp xếp vận hành công ty cho đến các quy trình xử lý nghiệp vụ. Sau khi khảo sát hiện trạng, nhà triển khai đánh giá mức độ khác biệt giữa hiện trạng và khả năng đáp ứng cho việc sử dụng phần mềm để giải quyết các quy trình công việc (Gaps Analysis). Chủ đầu tư sẽ xác nhận các sự khác biệt này bằng văn bản. Dựa trên các khác biệt, nhà triển khai đề xuất giải pháp khác nhau để thay đổi phần mềm. Những giải pháp này, có thể là customization (thay đổi ứng dụng) hoặc configuration (cài đặt thông số cho phù hợp). Thông thường, các chủ đầu tư không có kiến thức về phần mềm mới nên rất lúng túng trong các quyết định thay đổi phần mềm (ảnh hưởng rất lớn đến chi phí và thời gian triển khai). Những quyết định trong giai đoạn này lại có ảnh hưởng đến cách vận hành hệ thống, song song đó là vận hành các chức năng của phòng, ban trong DN.

Giai đoạn “Định nghĩa thay đổi”, như tên gọi của nó sẽ là kim chỉ nam về cách xử lý các quy trình nghiệp vụ trong suốt dự án và sau khi dự án được đóng lại. Vì nhiều lý do, một số nhà đầu tư đã không đầu tư đủ công sức để phê duyệt và kiểm tra các giải pháp đề ra, nên các nhà triển khai cứ theo giấy tờ mà làm. Hơn thế nữa, vì không chuẩn bị một quy trình quản lý thay đổi chặt chẽ ở giai đoạn trước, các đề xuất thay đổi không được phân tích kỹ lưỡng nên các thay đổi hoặc là không được tuân thủ (người dùng cuối không sử dụng được hệ thống) hoặc là không được triển khai trên thực tế (nhà triển khai chỉ thay đổi quy trình nhưng phần mềm không đáp ứng được). Giai đoạn này, việc liên lạc và thông tin trong đội triển khai rất quan trọng để đảm bảo các giải pháp sẽ dung hòa được nhu cầu của phòng, ban nghiệp vụ. Có những giải pháp phải được sự nhất trí của các phòng, ban khác nhau. Trong trường hợp này, nhà quản lý thay đổi (Change Manager) đóng vai trò rất quan trọng để thúc đẩy dự án đi tới.

3. Giai đoạn triển khai: Giai đoạn này có thể chia công việc làm hai phần tương đối rõ ràng. Nhà triển khai sẽ phải cài đặt phần cứng, phần mềm và cấu hình hệ thống. Sau đó, họ sẽ dựa vào các giải pháp đã được đồng ý trong giai đoạn trước và thay đổi hệ thống cho phù hợp với những quy trình điều hành DN. Công việc kiểm tra hệ thống, xác nhận phần mềm phù hợp với các quy trình vận hành công ty là phần việc nặng nề nhất của chủ đầu tư. Đây là giai đoạn nghiệm thu từng phần. Phần thử nghiệm do người dùng (User Acceptance Testing – UAT) là thước đo duy nhất trong giai đoạn triển khai mà nhà đầu tư có thể biết được chất lượng của hệ thống và dịch vụ cung cấp bởi nhà thầu. Chúng tôi cho rằng, các ràng buộc về chi phí của dự án nên xem đây là cột mốc quan trọng để giải ngân cho nhà triển khai. Thường thì các nhà đầu tư, vì đang vận hành DN của mình, bận rộn với công việc hàng ngày nên đã lơ là trong việc nghiệm thu. Khi việc nghiệm thu không làm kỹ lưỡng thì việc giải ngân phải… lơ là cho đỡ rủi ro. Sẽ có rất nhiều nguy hiểm khi thực hiện dự án ở giai đọan này.

4. Giai đoạn thu hoạch và đánh giá: Nếu bạn đã qua được giai đoạn triển khai, các quy trình được kiểm tra và nghiệm thu qua UAT. Như vậy, bạn đã qua được những phần việc nhiều rủi ro nhất trong dự án. Giai đoạn 4 chủ yếu nhằm vào đào tạo và huấn luyện cho người dùng cuối sử dụng hệ thống. Bộ phận CNTT có nhiệm vụ chuẩn bị cho hệ thống đi vào hoạt động chính thức (Production Environment). Các nhà đầu tư thường làm khá tốt công việc của giai đoạn này. Tuy nhiên, chúng tôi vẫn chưa thấy một nhà đầu tư nào cho ôn tập lại quá trình hoàn tất dự án một cách nghiêm túc. Đội dự án cần xoáy sâu vào các bài học giải quyết vấn đề trong dự án để có thể làm tốt hơn trong các dự án sau này.Triển khai phần mềm quản lý doanh nghiệp
theo tiến blog!