Quy trình triển khai một dự án ERP: từ năm giai đoạn xuống mười hai bước

Bài này giữ nguyên năm giai đoạn rồi bóc chúng xuống mức bước, và mỗi bước chỉ nói vừa đủ để bạn biết nó nằm ở đâu; những trạm cần đi sâu thì tôi để ở các bài riêng và có trỏ đường trong lúc đi.

Ba câu hỏi áp cho mọi bước

Trước khi vào bản đồ thì cần một công cụ đọc nó, và công cụ này là thứ tôi thấy hữu dụng nhất trong những gì học được từ một quản lý dự án lâu năm ở công ty triển khai.

Với bất kỳ hoạt động nào trong dự án như một buổi demo, một buổi khảo sát, một buổi kick-off, một buổi đào tạo, hay chính ngày go-live, bạn hãy trả lời ba câu:

• trước đó cần chuẩn bị gì
• trong lúc đó ai làm gì
• và sau đó output là gì rồi gửi cho ai

Nghe đơn giản tới mức dễ bỏ qua, nhưng nó có một tác dụng rất cụ thể. Một hoạt động mà bạn không trả lời được câu thứ nhất là hoạt động sẽ bắt đầu bằng nửa tiếng loay hoay; không trả lời được câu thứ hai là hoạt động sẽ có người ngồi im và có người làm ba việc cùng lúc; không trả lời được câu thứ ba là hoạt động sẽ kết thúc mà không để lại gì, và tuần sau không ai nhớ đã chốt cái gì.

Do đó cách dùng bài này hiệu quả nhất không phải là học thuộc mười hai bước, mà là mỗi lần sắp làm gì thì lấy ba câu đó ra hỏi.

Năm giai đoạn và mười hai bước

Bản đồ đầy đủ nằm trong bảng dưới đây. Cột bên phải ghi thứ bạn cầm trong tay khi rời khỏi bước đó, bởi đó chính là câu hỏi thứ ba.

Ba bước đáng chú ý nhất trong bảng là tiếp nhận dự án, dựng bản production, và deploy. Cả ba đều thường bị coi là phần chuẩn bị của bước khác chứ không phải bước riêng, trong khi cả ba đều có output rõ ràng và đều là chỗ dự án hay trượt.

Tiếp nhận dự án

Bước đầu tiên thường do người quản lý dự án làm, và ở công ty không có vai trò đó thì rơi vào tay BA.

Ba thứ phải nhận đủ. Thứ nhất là hợp đồng cùng các phụ lục và phạm vi công việc. Thứ hai là milestone, và đây là chỗ dùng từ cần chính xác: milestone không phải timeline, nó là các mốc mà mỗi mốc có một mục tiêu, và trong nhiều dự án thì chính đội sale đã chia phase kèm mục tiêu ngay từ lúc bán.

Thứ ba là ma trận các bên liên quan, và đây là thứ hay bị làm cho có. Một ma trận dùng được không chỉ ghi ai giữ vai gì, nó còn ghi những câu chuyện phía sau: người phụ trách bên khách là bạn của giám đốc nên hợp đồng dễ nhưng chất lượng phải cao; hoặc dự án tới từ giới thiệu của một bên thứ ba nên thực tế bạn làm việc với một công ty khác chứ không phải công ty ký hợp đồng. Những thông tin này nằm trong đầu đội sale, và nếu không ai hỏi thì chúng ở lại đó.

Lập kế hoạch, và một bước hay bị bỏ

Sau khi nhận đủ thông tin thì tới kế hoạch tổng thể và kế hoạch chi tiết, cộng với việc phân rã công việc nếu dự án đủ lớn. Phần này thì mọi tài liệu đều nói, nên tôi không nhắc lại.

Cái tôi muốn nói là bước nằm ngay sau đó, tức chuẩn bị nguồn nhân lực trước khi cam kết roadmap.

Trong quy trình mà tôi viết cho công việc của mình, đây là một bước riêng chứ không phải một phần của lập kế hoạch, và nó nằm ngay sau khi lên roadmap, bạn cần lưu ý rằng tài liệu của tôi xếp buổi kick-off nội bộ lên trước cả roadmap, hơi khác với cách sắp trong bảng ở trên. Lý do bước này tồn tại thì rất thực tế: kế hoạch được lập dựa trên mục tiêu và ngày go-live mong muốn, còn năng lực thực hiện thì phụ thuộc vào số người bạn thật sự có. Hai thứ đó khớp nhau là may mắn chứ không phải mặc định.

Do đó sau khi có roadmap, việc tiếp theo là đối chiếu với đội hình hiện tại. Nếu đội không đủ để chạy theo roadmap thì bạn có hai đường: hoặc yêu cầu cấp trên bổ sung nhân sự, hoặc thương lượng lại roadmap với phía doanh nghiệp. Đường thứ hai khó hơn nhiều và cần chuẩn bị kỹ cả nội dung lẫn cách trình bày, và cách chuẩn bị hiệu quả nhất là mang sẵn một roadmap dự phòng để đưa ra ngay trong buổi kick-off, thay vì chỉ nói rằng lịch này không khả thi.

Bỏ qua bước này thì bạn cam kết một roadmap mà đội không chạy nổi, và cái giá của nó không hiện ra ở tuần đầu mà hiện ra ở milestone thứ hai, khi đã quá muộn để thương lượng.

Hai buổi kick-off

Kick-off không phải một buổi mà là hai, và dự án nào cũng cần cả hai.

Buổi nội bộ diễn ra trước và không có mặt khách, buổi với khách diễn ra sau và cần một bộ tài liệu kick-off riêng. Thứ tự này không đảo được, bởi mọi thông tin mà đội ngũ đang cầm ở thời điểm đó vẫn hoàn toàn đến từ nội bộ bên triển khai, nên buổi với khách là buổi xác nhận lại chứ không phải buổi bắt đầu đi hỏi.

Bước tiếp theo của kick-off thì dự án nào cũng giống nhau, đó là chốt lịch các buổi khảo sát. Trong dự án gấp, có nơi làm luôn buổi khảo sát đầu tiên ngay sau kick-off để khỏi mất thêm một lần hẹn.

Khảo sát, phân tích và thiết kế

Bước tiếp theo là phần đã có cả một chuỗi bài riêng nói kỹ, bắt đầu từ bài về lấy yêu cầu cho ERP, nên ở đây tôi chỉ đặt nó vào đúng chỗ trên bản đồ.

Bạn chạy các buổi khảo sát, vẽ hai bộ lưu đồ, phân tích yêu cầu theo từng quy trình, rồi viết tài liệu GAP và tài liệu đặc tả. Cách chạy một buổi khảo sát, bộ câu hỏi mang vào phòng, cách viết từng tài liệu, và cách chốt giải pháp với khách đều là những chủ đề riêng và tôi đã viết ở các bài tương ứng.

Điều duy nhất cần nhớ ở tầm bản đồ là thứ tự ràng buộc giữa chúng: lưu đồ phải có trước tài liệu đặc tả, và trên thực tế thì lưu đồ thường được vẽ ngay trong lúc làm tài liệu GAP chứ không phải một công đoạn tách rời. Và trong tất cả những thứ sinh ra ở giai đoạn này, lưu đồ là thứ bắt buộc phải gửi email cho khách xác nhận, còn tài liệu GAP hay tài liệu đặc tả thì tùy công ty và tùy mức độ gấp của dự án.

Phát triển theo sprint

Giai đoạn tùy biến thường chạy theo sprint, với bốn sự kiện quen thuộc là lập kế hoạch sprint, họp nhanh mỗi ngày, buổi review, và buổi cải tiến; cộng thêm buổi làm mịn backlog diễn ra trước mỗi sprint.

Có ba chi tiết đáng nói ở mức bản đồ.

Chi tiết đầu tiên là ở công ty không có vai trò quản lý dự án thì BA phải là người xác định mục tiêu của sprint, chứ không phải chỉ nhận backlog rồi viết tài liệu. Từ mục tiêu đó mới lấy ra các hạng mục tương ứng, cả nhóm cùng ước lượng, và kết quả cuối cùng là một cam kết được gửi cho khách hàng. Do đó, bước gửi này quan trọng hơn nó có vẻ, bởi tới lúc kiểm thử và đào tạo thì bạn phải đào tạo đúng những gì đã cam kết, và đó cũng là căn cứ để đánh giá đội chạy được tới đâu.

Chi tiết thứ hai là buổi review nên có hai lần. Theo tài liệu chuẩn thì chỉ có một buổi và mời các bên liên quan vào, nhưng ở công ty triển khai dịch vụ thì cần một buổi nội bộ trước để xem đã đạt mục tiêu chưa; đạt rồi mới demo cho khách, chưa đạt thì xử lý trước đã. Và cần lưu ý rằng buổi này review hệ thống về mặt tính năng, khác hẳn buổi cải tiến vốn chỉ bàn về cách làm việc chứ không bàn tính năng nào.

Chi tiết thứ ba là một quan sát thực tế nghe được từ một quản lý dự án ở công ty triển khai: một số dự án hiện nay không còn làm buổi cải tiến sau mỗi sprint nữa vì không đủ thời gian, và họ dồn lại làm một lần vào cuối dự án. Cách đó không lý tưởng nhưng nó tốt hơn là không làm gì.

Kiểm thử, đào tạo và ba bước khép lại giai đoạn xây dựng

Sau khi tính năng chạy được thì tới kiểm thử với người dùng và đào tạo, điều cần nhìn thấy ở tầm bản đồ là ba bước khép lại giai đoạn xây dựng, gồm hai bước nằm giữa đào tạo và ngày go-live cộng với chính ngày go-live, ba bước mà nhiều người tưởng là một.

Bước dựng bản production là dựng một hệ thống mới hoàn toàn cho khách, làm lại gần như toàn bộ những việc đã làm khi dựng bản demo, gồm sáu việc:

• cài module
• triển khai phần đã lập trình
• thiết lập tích hợp
• nạp master data
• phân quyền
• và bật tắt cấu hình từng phân hệ

Đây là bước có checklist riêng, và bỏ qua checklist thì bạn sẽ phát hiện thiếu một cấu hình vào đúng buổi sáng go-live.

Bước triển khai mã thì cần phân biệt trước và sau ngày go-live. Trước go-live thì cứ đẩy lên, vì chưa ai dùng và chưa có dữ liệu. Sau go-live thì mỗi lần đẩy đều có thể tác động tới chức năng lẫn dữ liệu, nên bắt buộc phải ghi lại đã đẩy cái gì vào lúc nào.

Bước go-live thì có checklist riêng của nó, và điểm mấu chốt là checklist đó phải có cả phần việc của khách chứ không chỉ phần việc của bên triển khai; cách chia hai phía đó tôi để ở bài riêng vì nó đủ dài.

Sau khi bấm nút

Hai bước cuối là hỗ trợ sau go-live và bảo trì.

Ở bước hỗ trợ, khối lượng công việc thường lớn hơn nhiều so với hình dung, và tính chất công việc cũng khác: bạn không còn xây gì nữa mà đang vận hành một dòng issue đổ về từ người dùng thật. Cách tổ chức dòng chảy đó là một chủ đề riêng.

Ở bước bảo trì, thứ quyết định là bạn có nắm được phạm vi dự án hay không. Người dùng sẽ tiếp tục yêu cầu, và một phần trong đó nằm ngoài những gì hai bên đã ký; không phân biệt được thì bạn làm miễn phí những việc lẽ ra phải báo giá, và tệ hơn là bạn tạo ra tiền lệ.

Với dự án nhiều phase thì vòng lặp không quay về bước một mà quay về bước khảo sát, bởi hợp đồng, milestone và đội hình đã có sẵn; cái chưa có là hiểu biết về phần nghiệp vụ thuộc phase tiếp theo.

Quay lại ba câu hỏi

Mười hai bước ở trên là bản đồ của một dự án cụ thể trong một cách làm cụ thể, và công ty bạn có thể chia khác, gọi tên khác, gộp hai bước làm một. Điều đó không quan trọng bằng chuyện mỗi hoạt động trong dự án đều có người trả lời được ba câu chuẩn bị gì, ai làm gì, và output gửi cho ai.

Nếu bạn chỉ mang được một thứ ra khỏi bài này thì hãy mang ba câu đó, và thử áp ngay vào việc gần nhất bạn sắp làm. Phần lớn các buổi họp trôi qua mà không để lại gì đều trượt ở câu thứ ba.

Trạm tốn công nhất trên bản đồ, và cũng là trạm mà sai lầm khó gỡ nhất, không nằm ở phần xây tính năng mà nằm ở phần đưa dữ liệu lên hệ thống.