Bộ tài liệu của một dự án ERP: cái nào cần, cái nào bỏ được

Vị trí thật của tài liệu trong dự án

Trước khi đi vào từng file, cần đặt lại một chuyện.

Theo cách tôi vẫn nhìn, cái quyết định dự án ERP thành hay bại là hệ thống mà khách hàng dùng được sau khi go-live, còn tài liệu là kết quả tất yếu của quá trình triển khai chứ không phải yếu tố quyết định; một dự án có bộ tài liệu hoàn hảo mà hệ thống không chạy được thì vẫn là dự án thất bại, và điều ngược lại cũng đúng. Đây cũng là tinh thần của Agile Manifesto khi đặt phần mềm chạy được lên trên tài liệu đầy đủ.

Nói vậy không có nghĩa là đừng viết tài liệu. Tài liệu vẫn cần, vì nó là cách nhiều người cùng làm một việc mà không hiểu nhầm nhau, đồng thời là căn cứ khi có tranh chấp. Tuy nhiên, nếu bạn nhầm tài liệu với mục tiêu thì bạn sẽ dành hai tuần làm đẹp một file mà đáng lẽ nên dùng để dựng thử giải pháp trên hệ thống rồi cho khách xem.

Cần lưu ý rằng cái bẫy này rơi vào người mới nhiều hơn, bởi tài liệu là thứ đo được còn "hệ thống chạy đúng nghiệp vụ" thì không; viết xong một tài liệu BA ERP bạn có cảm giác đã làm được việc gì đó, và cảm giác đó không phải lúc nào cũng đúng.

Hợp đồng quyết định, không phải chuẩn ngành

Đây là nguyên tắc thay thế cho danh sách cứng.

Số lượng tài liệu dự án ERP và độ chi tiết của từng tài liệu phụ thuộc vào việc hợp đồng có bàn giao tài liệu đó hay không. Nếu hợp đồng ghi rõ bàn giao SRS thì bạn viết đầy đủ theo format, và mỗi lần viết đều gửi hai bên review rồi xác nhận mới thực hiện; nếu hợp đồng không bàn giao SRS thì bạn viết bản rút gọn đủ để đội phát triển làm đúng, và không cần chỉn chu hơn thế.

Do đó có hai câu bạn phải chốt ngay từ buổi kick-off, trước khi bắt đầu triển khai:

• dự án này bàn giao những tài liệu nào
• và có đào tạo, có bàn giao test case, có bàn giao dữ liệu go-live hay không

Nghe đơn giản, nhưng rất nhiều người tham gia dự án mà không nắm hai thông tin này, và hệ quả là làm thừa ở chỗ này rồi làm thiếu ở chỗ kia, tới lúc nghiệm thu mới phát hiện.

Bên cạnh đó còn một yếu tố nữa quyết định độ dày tài liệu mà ít người nói tới, đó là dự án có customize nhiều không. Khi triển khai một nền tảng có sẵn như Odoo, phần lớn hành vi hệ thống đã tồn tại và không cần mô tả lại, nên một dự án chỉ cấu hình mà không code thì bộ tài liệu tự nhiên mỏng, không phải vì bạn làm ẩu, mà vì không có gì mới để mô tả.

Bộ tài liệu xếp theo giai đoạn dự án

Cách xếp dễ nhớ nhất không phải theo tên tài liệu mà theo giai đoạn sinh ra nó. Đây là bộ tôi vẫn dùng, chia theo năm giai đoạn của một dự án Odoo.

• Giai đoạn khởi tạo và lập kế hoạch có Kickoff Document và Master Plan.
• Giai đoạn khảo sát và phân tích có báo cáo khảo sát, lưu đồ BPMN hoặc Flowchart, tài liệu GAP và FRD khi dự án cần đặc tả chức năng ở mức tổng thể.
• Giai đoạn cấu hình và tùy biến có SRS, Config System Document, test case và DataSet Checklist.
• Giai đoạn UAT và Pilot có kịch bản UAT/Pilot và file quản lý issue.
• Cuối cùng, giai đoạn go-live và bảo trì có User Guide.

Cần lưu ý một chuyện về tên gọi trước khi đi tiếp. Trong các khóa học và tài liệu BA nói chung, bạn hay gặp cặp BRD và SRS; còn trong bộ template thực tế mà tôi dùng cho dự án Odoo thì phần "làm thế nào" được tách thành hai tài liệu riêng, một cái mô tả giải pháp cho phần customize, một cái mô tả cấu hình hệ thống. Lý do tách là vì hai phần đó do hai nhóm người khác nhau thực hiện và được nghiệm thu theo hai cách khác nhau. Nếu công ty bạn gọi chung là SRS thì cũng không sao, miễn là bạn biết bên trong nó có hai loại nội dung.

Biên bản và báo cáo khảo sát

Biên bản là ghi chép của từng buổi khảo sát, gửi email cho các bên tham gia và cc ban dự án hai bên; báo cáo khảo sát là bản tổng hợp gồm danh sách quy trình, mong muốn ở từng quy trình và mô tả cụ thể từng bước.

Cái này gần như không bỏ được, nhưng lý do có thể khác bạn nghĩ: giá trị lớn nhất của báo cáo khảo sát không phải là lưu trữ, mà là giúp những người không tham gia buổi khảo sát vẫn hình dung được doanh nghiệp đang vận hành thế nào. Một dự án có hơn chục người mà chỉ hai người đi khảo sát, nếu không có tài liệu này thì năm người còn lại làm theo suy đoán.

Đặc biệt, khi gửi biên bản đi thì đừng quên đặt thời hạn phản hồi, vì không có deadline thì khách sẽ không đọc, và bạn mất căn cứ cho mọi bước sau.

Lưu đồ quy trình

Nếu bạn chỉ giữ được một tài liệu trong toàn bộ dự án, hãy giữ cái này.

Lý do là lưu đồ chính là base để tất cả các team cùng chạy: người viết tài liệu đặc tả nhìn vào đó, đội phát triển nhìn vào đó, tester viết kịch bản test dựa vào đó, người đi training dựa vào đó để dựng kịch bản hướng dẫn. Bỏ nó đi thì mỗi nhóm tự hiểu một kiểu, và bạn chỉ phát hiện ra khi mọi thứ đã lệch nhau.

Có hai bộ là quy trình hiện tại (As is) và quy trình tương lai (To be), trong đó bộ To be là bộ quan trọng vì đó là cái sẽ được xây. Và đây là điểm khác biệt so với các tài liệu còn lại: lưu đồ bắt buộc phải gửi email cho khách hàng và được xác nhận. Tài liệu GAP hay SRS trong tình huống gấp còn có thể cắt bớt, riêng lưu đồ thì không, bởi nó là thứ duy nhất mô tả cách doanh nghiệp sẽ vận hành sau khi lên hệ thống, khách xác nhận sai ở đây thì mọi thứ phía sau đều sai theo.

Về framework thì dùng BPMN hay Flowchart đều được, và tiêu chí chọn cùng các quy tắc vẽ là một chủ đề riêng đủ dài để nói ở chỗ khác.

Tài liệu GAP

GAP là phần nằm giữa yêu cầu của khách và hệ thống mặc định, tức những thứ hệ thống không đáp ứng được hoặc chỉ đáp ứng một phần.

Theo cách tôi thấy ở các dự án gần đây, tài liệu này phục vụ pre-sale nhiều hơn là phục vụ giai đoạn triển khai: nó dùng để chứng minh với khách cái gì hệ thống làm được và cái gì phải làm thêm, từ đó ra được phương án giá. Tuy nhiên, dù dùng cho mục đích nào thì nó vẫn là đầu vào bắt buộc để viết SRS, bởi bạn không thể mô tả giải pháp nếu chưa xác định được cái gì cần giải pháp. Do đó GAP là tài liệu hiếm khi bỏ được, kể cả khi hợp đồng không yêu cầu bàn giao.

BRD

BRD là tài liệu hay bị hiểu là bắt buộc nhất, và thực tế lại là tài liệu bỏ được nhiều nhất trong dự án ERP.

Lý do nằm ở đặc thù của việc triển khai nền tảng có sẵn: phần lớn yêu cầu nghiệp vụ của khách đã có tính năng tương ứng trong hệ thống, và những yêu cầu đó không cần được mô tả ở tầng business requirement rồi mới xuống tầng giải pháp, bạn đối chiếu thẳng vào GAP là xong.

BRD thực sự cần khi dự án lớn, customize nhiều, tích hợp với nhiều bên thứ ba, hoặc khi hợp đồng yêu cầu bàn giao. Trong trường hợp dự án nhỏ, chỉ cấu hình và customize ít, bạn không cần viết BRD, và điều đó không có nghĩa là bạn làm thiếu quy trình.

Nếu có viết thì phần đáng đầu tư nhất trong BRD không phải mục yêu cầu, mà là mục phạm vi dự án, và cụ thể hơn nữa là phần ngoài phạm vi; cách viết mục đó cho có sức nặng thì tôi để ở bài riêng về ba tầng tài liệu yêu cầu.

Tài liệu giải pháp SRS

Đây là tài liệu mô tả chi tiết những gì bạn làm thêm trên hệ thống, và nó phục vụ bốn nhóm người:

• đội phát triển dùng làm đầu vào để code
• tester dùng để viết test case
• hai bên dùng làm tiêu chí nghiệm thu
• và một vendor khác trong tương lai dùng để biết hệ thống đã được customize những gì

Nhóm thứ tư ít người nghĩ tới nhưng lại là lý do đáng giá nhất để viết tài liệu này tử tế. Doanh nghiệp có thể đổi đối tác triển khai ở giai đoạn sau, và không có SRS thì bên mới phải đọc ngược từ code, mất rất nhiều thời gian, mà chi phí đó cuối cùng khách chịu.

Cấu trúc mà tôi vẫn dùng đi theo từng mã GAP, và với mỗi mã thì có các thành phần: user story lấy nguyên từ tài liệu GAP, sơ đồ thao tác của người dùng, mô tả giải pháp gồm tên tính năng cùng ràng buộc và phân quyền và trạng thái, giao diện, thiết kế dữ liệu và các business rule. Cách tổ chức này có một lợi ích rất cụ thể: đọc một mục là truy ngược được về đúng dòng GAP đã chốt với khách, nên khi có tranh cãi thì không phải lật lại từ đầu.

Riêng phần thiết kế dữ liệu thì bảng trường trong bộ template của tôi rộng hơn các mẫu thông thường, và mỗi cột thêm vào đều tồn tại vì một lý do rất cụ thể của nền tảng; cách viết bảng đó là một chủ đề riêng nên tôi để ở chỗ khác.

Đồng thời cần lưu ý rằng tài liệu này phải được cập nhật liên tục cho tới khi go-live, vì khi khách bắt đầu dùng thử sẽ có tính năng họ thấy không cần nữa hoặc phải chỉnh cho hợp thói quen người dùng. Tài liệu viết một lần rồi đóng lại là tài liệu chết.

Checklist dữ liệu và kịch bản UAT

Hai tài liệu này ít được nhắc tới trong các bài viết về BA, nhưng bỏ chúng đi thì hai giai đoạn cuối dự án chạy bằng trí nhớ.

Checklist dữ liệu là danh sách những gì phải đưa lên hệ thống, chia làm hai loại là master và transaction data, mỗi dòng ghi tên đối tượng và ghi chú. Chính nó quyết định thứ tự nạp dữ liệu và quyết định luôn việc bạn phát hiện thiếu dữ liệu trước hay sau khi go-live.

Kịch bản UAT là bộ tình huống mà người dùng sẽ chạy thử. Nó là thứ quyết định buổi UAT có giá trị hay chỉ là một buổi ngồi bấm cho biết, và cách viết nó là một chủ đề riêng đủ dài để nói ở chỗ khác.

Test case

Thường do QC hoặc đội phát triển làm, dựa trên SRS. Với BA thì phần liên quan là: nếu SRS của bạn không có exception flow và business rule rõ ràng, tester sẽ viết thiếu case, và những case thiếu đó khách sẽ tìm ra trong UAT.

Trong dự án không có QC riêng thì BA thường kiêm luôn, và trong các mô tả công việc ERP tại Việt Nam mà tôi đọc được, có tin tuyển dụng gộp thẳng vai BA với QA vào một vị trí.

User Guide

Có ba tình huống, chọn theo mức độ customize và theo hợp đồng.

Nếu dự án customize ít, hãy viết sẵn một bộ hướng dẫn mặc định dùng chung cho mọi khách, tạo đơn hàng thế nào, tạo sản phẩm thế nào, rồi viết thêm một tài liệu bổ sung cho phần custom, khách dùng module nào thì mở phần đó. Nếu customize rất nhiều tới mức bộ mặc định không dùng được thì viết lại từ đầu. Còn nếu hợp đồng không bàn giao User Guide, bạn có thể thay bằng một buổi training có quay màn hình rồi gửi lại file ghi hình; khách dùng được ngay và bạn không mất hai tuần viết.

Cần phân biệt rõ rằng SRS không phải User Guide: SRS mô tả cách làm ra tính năng, còn User Guide hướng dẫn người dùng thao tác, và đưa SRS cho người dùng cuối là họ không đọc được.

Issue Log

Đây là tài liệu ít được nhắc tới nhất, và cũng là tài liệu hay bị bỏ nhất khi dự án gấp.

Nó ghi nhận mọi vấn đề khách raise trong giai đoạn UAT, training, pilot và go-live. Các thành phần chính gồm mã issue, ngày tạo, thời hạn hoàn thành, người raise, vai trò và phòng ban của người đó, giai đoạn phát sinh, độ ưu tiên, mô tả, giải pháp, trạng thái, ghi chú và một cột nữa mà nhiều mẫu không có, đó là in-scope hay out-scope. Không có cột đó thì tới cuối dự án bạn không có căn cứ nào để phân biệt việc nằm trong hợp đồng với yêu cầu phát sinh, và mọi thứ trở thành tranh cãi cảm tính.

Bản rút gọn khi dự án gấp

Đây là phần dùng được ngay, và cũng là phần ít tài liệu hướng dẫn nào nói tới.

Khi hợp đồng không bàn giao SRS, bạn không cần viết đủ bốn phần lớn của tài liệu; phần tổng quan tài liệu, tổng quan hệ thống và mô tả quy trình đều có thể bỏ, vì thông tin đó đã nằm ở lưu đồ và báo cáo khảo sát. Cái phải giữ là phần đặc tả yêu cầu hệ thống, và ngay trong phần đó bạn cũng bỏ được ba mục là mô tả tính năng, điều kiện trước, và trigger.

Các mục còn lại thì không được bỏ, gồm:

• main flow là luồng chính user sẽ thao tác
• alternative flow là các cách khác dẫn tới cùng kết quả
• exception flow là các trường hợp báo lỗi hoặc không lưu được
• và đặc biệt là business rule, tức quy tắc nghiệp vụ do chính doanh nghiệp đưa ra

Lý do giữ đúng bốn mục này là để người đọc hiểu được tính năng dựa vào rule nào mà làm, bỏ business rule đi thì đội phát triển làm theo cảm tính, còn tester không biết phải test gì.

Cộng thêm hai thứ nữa luôn phải có bất kể tài liệu dày hay mỏng, đó là bảng mô tả trường gồm tên trường, tên kỹ thuật, kiểu dữ liệu, bắt buộc hay không, mô tả; và ảnh chụp màn hình có đánh số các thành phần. Bảng trường thiếu thì đội phát triển đặt sai vị trí và sai kiểu dữ liệu; ảnh màn hình thiếu thì sau này bạn không viết được User Guide, và cũng không dùng được công cụ nào để sinh tự động.

Change Log (Release Note) của việc deploy

Còn một tài liệu nữa hay bị quên, và nó không nằm trong bộ template nào.

Nội dung rất đơn giản: deploy cái gì, vào thời điểm nào. Trước go-live thì chuyện này không quan trọng lắm, vì chưa ai dùng và chưa có dữ liệu; sau go-live thì mỗi lần deploy đều có thể tác động tới chức năng và tới dữ liệu, và khi đó bạn cần truy vết được để biết nên revert về mốc nào. Giá trị của nó chỉ hiện ra đúng một lần, nhưng đúng vào lúc bạn cần nhất.

Ba câu hỏi lọc trước khi viết

Trước khi bắt đầu viết bất kỳ tài liệu nào, hãy trả lời ba câu.

Hợp đồng có bàn giao tài liệu này không, nếu có thì viết đầy đủ theo format và gửi review từng lần, nếu không thì viết đủ để đội bạn làm đúng.

Tài liệu này phục vụ ai, nếu bạn không chỉ ra được một người cụ thể sẽ đọc nó, khả năng cao bạn đang viết cho chính mình.

Nếu bỏ nó thì ai bị kẹt, đây là câu hỏi lọc tốt nhất, vì bỏ lưu đồ thì cả dự án kẹt, còn bỏ BRD trong một dự án nhỏ thì không ai kẹt cả.

Và bất kể bạn cắt tới đâu, trước khi đóng một tài liệu thì hãy mở hộp thư ra kiểm lại xem đã có email xác nhận của khách cho lưu đồ chưa; nếu chưa thì đừng để đội phát triển bắt đầu.

Chuyện tiếp theo, và cũng là chuyện khó nhất trong nhóm tài liệu này, là làm sao xác định được cái gì hệ thống đáp ứng và cái gì không. Đó là công việc của tài liệu GAP.