Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Người ký hợp đồng và người phải đổi thao tác là hai người khác nhau. BA làm được gì trong quản lý thay đổi, và cách đo mức độ chấp nhận bằng dữ liệu.
Hình dung một doanh nghiệp phân phối thiết bị điện, tháng thứ hai sau khi chuyển hẳn sang hệ thống mới. Buổi họp tiến độ diễn ra rất êm: phía khách nói hệ thống chạy ổn, đội triển khai không nhận thêm vướng mắc nào đáng kể, và hai bên đã bàn tới việc đóng giai đoạn hỗ trợ.
Chỉ tới lúc mở danh sách phiếu xuất kho ra xem theo thời điểm tạo thì mới lộ ra một chi tiết lệch. Gần như toàn bộ phiếu của cả ngày được tạo trong nửa tiếng cuối giờ chiều, trong khi xe thì chạy rải ra từ sáng.
Hệ thống vẫn có dữ liệu và biên bản nghiệm thu vẫn ký được, nhưng mọi con số tồn kho trong giờ làm việc đều sai, nên bộ phận bán hàng vẫn phải gọi điện xuống kho hỏi tồn trước khi hứa ngày giao với khách, tức là đúng cái việc mà dự án sinh ra để bỏ đi.
Không ai nói dối trong buổi họp đó và cũng không ai công khai từ chối hệ thống.
Chỗ hỏng nằm ở nơi khác: người quyết định mua là ban giám đốc, người phải đổi thao tác hằng ngày là tổ trưởng kho, và giữa hai người đó không ai được giao việc làm cho thay đổi thật sự xảy ra.
Đây là một đầu việc có thật nhưng gần như không bao giờ có người nhận.
Nhân sự một dự án cỡ vừa thường gồm đội sale, người quản lý dự án, BA, đội phát triển và đội kiểm thử, và gần như không bao giờ có dòng nào ghi người phụ trách quản lý thay đổi.
Công việc đó không vì thế mà biến mất, nó chỉ chuyển sang trạng thái không ai chịu trách nhiệm, và tới lúc hệ thống chạy thật thì hậu quả rơi xuống người ở gần người dùng nhất. Trong hầu hết dự án, người đó là bạn, bởi BA vừa ngồi họp với cấp quyết định vừa ngồi cạnh người nhập liệu.
Tuy nhiên nhận phần việc này không đồng nghĩa với nhận mọi thứ người khác đẩy sang, và việc BA nên từ chối cái gì là chủ đề của một bài riêng về ranh giới trách nhiệm. Ở đây chỉ cần nhớ rằng phần bạn làm được là thông tin, thứ tự công việc và bằng chứng, còn thẩm quyền thì không bao giờ là của bạn.
Năm đặc điểm dưới đây tôi gặp đi gặp lại, và mỗi cái đi kèm một cách xử lý.
Đầu tiên là người quyết định và người chịu ảnh hưởng không phải một người. Hợp đồng do ban giám đốc ký dựa trên buổi demo, còn cái giá của việc đổi cách làm thì nhân viên trả bằng thời gian mỗi ngày. Cách xử lý là đưa ít nhất một người dùng thật của mỗi bộ phận vào các buổi khảo sát và kiểm thử.
Tiếp theo, ở các doanh nghiệp vừa và nhỏ tôi đi qua thì gần như không có bộ phận nào phụ trách việc này, nên nó rơi vào tay bạn theo mặc định chứ không theo quyết định. Việc nên làm là gọi tên nó ra trong buổi kick-off nội bộ: ai thông báo cho người dùng, ai trả lời câu hỏi của họ, và nếu chưa có ai thì ít nhất cả đội cùng biết là đang thiếu.
Đặc điểm thứ ba nặng hơn. Quy trình cũ ở nhiều nơi không tồn tại dưới dạng văn bản mà tồn tại dưới dạng thói quen, sổ tay cá nhân, file trên máy riêng và quy ước truyền miệng giữa vài người. Hệ quả là bạn không có hai tài liệu để đối chiếu, nên cách làm phải đổi thành đi tìm vật chứng, tức là xin bản chụp cuốn sổ, xin file đang dùng, và quan sát tại chỗ ở những bộ phận nặng thao tác tay.
Đặc điểm thứ tư là người phản đối mạnh nhất thường không phải người yếu nhất mà là người giỏi việc cũ nhất. Một người thuộc lòng bảng giá và xử lý được một tình huống ngoại lệ trong ba phút bằng kinh nghiệm riêng, thì khi hệ thống biến toàn bộ thứ đó thành dữ liệu công khai, lợi thế cá nhân của họ mất đi trước khi lợi ích chung kịp hiện ra.
Nguyên tắc gói trong một câu: đừng xếp họ vào nhóm người phải học, hãy xếp họ vào nhóm người đi kiểm chứng.
Cuối cùng là chuyện không ai đo. Mức độ chấp nhận thường được báo cáo bằng cảm giác trong buổi họp, mà cảm giác thì luôn tốt hơn thực tế; cách xử lý là bốn con số ở mục cuối bài, lấy thẳng từ dữ liệu hệ thống chứ không hỏi lại trong họp.
Cần lưu ý rằng năm điều trên là quan sát về cách tổ chức vận hành, không phải kết luận về con người ở một quốc gia nào. Tôi không có bộ dữ liệu nào đứng sau chúng, và những câu khái quát kiểu người ở đâu đó thì ngại thay đổi vừa không kiểm chứng được vừa che mất nguyên nhân thật, vốn thường chỉ là chưa ai nói cho người đó biết vì sao phải làm khác đi.
Khảo sát là lần duy nhất bạn ngồi với đủ các bộ phận trước khi mọi thứ bị chốt, nên đây là chỗ rẻ nhất để làm phần đầu tiên của quản lý thay đổi.
Ngoài các câu hỏi nghiệp vụ thông thường, có một câu đáng hỏi thêm ở cuối mỗi buổi: sau khi lên hệ thống thì việc gì trong ngày làm việc của anh chị sẽ biến mất, và việc gì xuất hiện thêm. Câu trả lời cho bạn danh sách những người sắp mất một phần công việc hoặc một phần vị thế, và đó chính là những người quyết định dự án chạy hay không chạy sau go-live.
Bên cạnh đó, hãy chủ động đi tìm những công cụ cá nhân đang gánh quy trình, chẳng hạn một bảng giá riêng trong máy của người bán hàng lâu năm mà không ai ngoài người đó biết bên trong có gì. Không phát hiện ra nó từ giai đoạn khảo sát thì hệ thống mới sẽ bị đem ra so với nó suốt nửa năm đầu, và bạn luôn ở thế thua vì không biết mình đang bị so với cái gì.
Riêng phần được và mất thì tách thành một danh sách theo bộ phận và gửi kèm biên bản buổi khảo sát. Trong quy trình tôi dùng, biên bản mỗi buổi khảo sát đều được gửi email cho các bên, cc ban dự án hai phía, và mọi việc phía doanh nghiệp đều có thời hạn; danh sách được và mất đi theo đúng đường đó, vì bạn sẽ dùng lại nó ở giai đoạn kiểm thử và đào tạo.
Khi một yêu cầu được trả lời bằng cách đổi quy trình thay vì đổi phần mềm, luôn có một người cụ thể phải làm khác đi, mà tài liệu giải pháp thì thường bỏ trống đúng chỗ đó.
Vì vậy với mỗi hạng mục làm đổi cách làm việc của một bộ phận, hãy viết thêm một dòng ghi rõ:
Dòng cuối quan trọng nhất. Cùng một thông tin, do người triển khai nói ra thì nó là quy định của nhà cung cấp phần mềm, còn do trưởng bộ phận của họ nói ra thì nó là quyết định nội bộ, và hai thứ đó tạo ra hai mức tuân thủ khác hẳn nhau.
Đồng thời cần nhớ một nguyên tắc mà một quản lý dự án lâu năm ở công ty triển khai vẫn nhắc trước mọi buổi demo, rằng hệ thống mới ít nhất phải làm được những việc hệ thống cũ đang làm được, và đó là chủ đề của một bài riêng. Mỗi việc người dùng làm được trên công cụ cũ mà chưa làm được trên hệ thống mới là một lý do chính đáng để họ quay về công cụ cũ, và lý do chính đáng thì không thuyết phục được bằng đào tạo.
Danh sách người tham gia kiểm thử thường được phía khách chọn theo chức vụ hoặc theo ai đang rảnh, và đó là một cơ hội bị bỏ phí.
Cách dùng được hơn là chọn theo hai tiêu chí: người đó có làm công việc sẽ đổi nhiều nhất hay không, và người đó có được đồng nghiệp hỏi ý kiến hay không. Tiêu chí thứ hai ít khi trùng với chức danh, nhưng ngồi trong bộ phận đó một buổi là nhận ra.
Đây cũng là chỗ xử lý đặc điểm thứ tư đã nêu ở trên. Người giỏi việc cũ nếu bị xếp vào lớp đào tạo chung thì họ ngồi im rồi về chỗ làm theo cách cũ; ngược lại, nếu được mời vào vai người kiểm chứng thì tình thế đảo lại, bởi bạn đang nhờ họ dùng chính kinh nghiệm mà họ sợ mất để tìm ra chỗ hệ thống chưa đúng.
Việc nên giao là dựng lại vài tình huống khó nhất họ từng gặp rồi chạy thử, sau đó ghi nhận cái nào chạy được, cái nào phải đi vòng, cái nào không làm được.
Buổi đào tạo hay bị coi là toàn bộ phần quản lý thay đổi, trong khi nó chỉ là phần truyền đạt thao tác; nội dung dạy gì và dạy cho ai thì đã có một bài riêng về đào tạo người dùng cuối.
Phần thuộc về quản lý thay đổi nằm ở xung quanh buổi đó. Trước buổi, người dùng cần biết:
Thông tin này phải do phía doanh nghiệp phát ra. Sau buổi, hãy thu lại những câu hỏi người dùng đã đặt, bởi một câu hỏi lặp lại nhiều lần là dấu hiệu của chỗ thiết kế chưa tự giải thích được.
Riêng hai tuần đầu sau go-live cùng kênh nhận vướng mắc thì đã là chủ đề của một bài khác. Còn lý do mọi kết luận về mức độ chấp nhận rút ra ở giai đoạn kiểm thử đều chỉ là tạm thời thì tôi đã nói ở bài về UAT và Pilot.
Đây là phần gần như không dự án nhỏ nào làm, dù nó chỉ tốn vài chục phút mỗi tuần.
Trên Odoo 19, mỗi bản ghi mặc định lưu bốn thông tin ghi vết, gồm người tạo, thời điểm tạo, người sửa gần nhất và thời điểm sửa gần nhất, trừ những model được thiết kế để tắt cơ chế này. Trên màn hình chúng mang nhãn Created by, Created on, Last Updated by và Last Updated on, và xuất ra file được như mọi trường khác.
Nghĩa là bạn đã có sẵn nguyên liệu, không cần thêm công cụ nào; dù vậy, trước khi dựa vào chúng hãy thử xuất một lần trên đúng phiên bản và đúng đối tượng mình định đo.
Bốn con số đáng theo dõi gồm:
Checklist thao tác mỗi tuần:
Cần chú ý rằng những con số này dùng để tìm chỗ cần hỏi, không dùng để đánh giá con người. Gửi chúng cho khách dưới dạng bảng xếp hạng nhân viên thì lần sau sẽ không ai nói thật với bạn nữa. Cách dùng đúng là mang con số lệch nhất xuống hỏi trực tiếp người liên quan, bởi câu trả lời gần như luôn là một lý do vận hành hợp lý mà không ai kịp nói ra trong giai đoạn khảo sát.
Trong trường hợp doanh nghiệp cố ý chạy song song hệ thống cũ theo một thỏa thuận có thời hạn thì những con số trên sẽ xấu, và đó là chuyện bình thường. Cách phân biệt giữa chạy song song và âm thầm giữ file riêng là hỏi xem ngày kết thúc đã được ai ấn định hay chưa.
Có một giới hạn phải nói thẳng: toàn bộ những việc trên chỉ giảm được ma sát chứ không tạo ra được thay đổi.
Nếu ban lãnh đạo không nói ra lấy một câu rằng từ ngày này công việc được ghi nhận trên hệ thống, thì mọi thứ bạn làm chỉ giúp người muốn dùng dùng dễ hơn, chứ không chạm tới người không muốn dùng. Việc đúng nhất của bạn khi đó là đưa những con số ở phần trên rồi để người có thẩm quyền tự quyết định.
Một giới hạn nữa nằm ở chính bài này. Những gì vừa viết là cách sắp xếp của riêng tôi cho dễ nhớ, không phải một khung phương pháp đã được kiểm nghiệm trên một tập dự án đủ lớn, nên nếu bạn có cách làm khác chạy được trong bối cảnh của mình thì cách đó thắng.
Phần việc nặng nhất trong tất cả những thứ vừa nói là ghi chép và lặp lại, và đó cũng chính là phần mà các công cụ AI đang bắt đầu chen vào công việc hằng ngày của một BA.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận