Hế lô anh em, nay mình sẽ chém gió đôi chút với anh em về các dự án Dynamics 365 hồi đó mình làm. Anh em cùng nghe rồi bình loạn cho vui nhé.

Bài này sẽ viết về những chiêm nghiệm của mình. Những điều mà mình hiểu và rút ra được từ các dự án. Mong những chia sẻ của mình sẽ giúp ích được anh em. Chí ít là không mắc phải những sai lầm củ chuối mà mình và team đã gặp.

Các dự án chủ yếu mình làm là về sản xuất hàng tiêu dùng. Các doanh nghiệp này muốn áp dụng CRM để quản lý việc bán hàng của mình hiệu quả hơn. Mình bắt đầu đi vào ý đầu tiên nhé.

1. BA mà thiếu thông tin là… tèo ngay

Hồi đó team mình làm từng function nhỏ rồi deliver cho khách hàng, nhận feedback và re-design lại cho khớp. Kiểu agile nửa mùa vậy đó. Chạy song song cả module Sales lẫn Marketing.

Vì lúc đó nhận KT từ một team khác nên sai lầm đầu tiên là: Cả mình và team không chú trọng đến đoạn này nhiều. Dẫn đến mình khá mơ hồ về thông tin khách hàng.

Cực kỳ mơ hồ. Từ những cái tổng quan đến những requirement cơ bản nhất. Mình đã gặp rất nhiều khó khăn để bắt kịp tiến độ được với team chạy trước.

Điều nay thì vô cùng khó chịu. Trong các buổi họp anh em khó mà hiểu được mọi người đang nói gì. Gặp khách hàng cũng không tự tin vì thông tin mình nắm không vững.

Thật ra thì vấn đề này không phải đến từ team hay PM, mà đến từ chính mình. Ngáo ngáo không chủ động hỏi là tèo ngay. Đến khi gặp khách hàng thì mới biết mình chả deliver được gì.

Credit: tranh của Lisa Benson

Làm BA mà nắm quá ít thông tin thì đương nhiên là chả làm được gì. Không nói chuyện được với người ta, không teamwork được với team. Mọi thứ lúc đó nó mịt mờ lắm anh em.

Mà thiệt ra là để lấy được thông tin, không nhất thiết phải đi hỏi, hay làm workshop. Hay cũng chả cần tổ chức một buổi offical KT gì cho hoành tráng cả. Đơn thuần chỉ cần đọc lại mấy tài liệu của team, có bao nhiêu đọc bấy nhiêu. Hoặc lên web khách hàng xem thông tin của họ.

Mình làm CRM mà, tìm hiểu về thị trường, các kênh bán hàng, các loại sản phẩm là quan trọng. Chỉ cần mình muốn thì sẽ có rất nhiều cách để nắm được thông tin.

Do đó, dù có làm gì thì cũng đừng để miss thông tin. Tìm mọi cách để update và hiểu vấn đề ngay có thể nhé anh em. BA cần thông tin để làm, cũng giống như con người mình cần Oxy để thở vậy.

BA thiếu thông tin chả khác nào cá thiếu nước

2. Hạn chế coding trong dự án triển khai

Đây là điều mình sẽ luôn aware đầu tiên cho bất cứ dự án nào. Làm dự án triển khai thì rất nên… né việc coding. Thay vào đó hãy cố gắng dùng các chức năng mặc định của hệ thống. Vì sao?

2.1. Chuẩn rồi, sao phải coding thêm chi nữa ?!?

Thứ nhất, bộ chức năng của hệ thống có sẵn đã quá chuẩn rồi. Bất kỳ hệ thống nào đi nữa thì đội ngũ phát triển họ đã nghiên cứu rất kỹ nhu cầu sử dụng của khách hàng. Rồi từ đó, họ mới develop thành các chức năng mặc định của hệ thống, gọi là các best-practice của hệ thống. Chứ chả có ông nào tự dưng bưng ba cái gì đâu bỏ vô hệ thống cho mình xài đâu.

Thiệt ra thì cũng chả bao giờ có chuyện hệ thống này chỉ áp dụng được với doanh nghiệp này. Còn đưa vô doanh nghiệp khác thì bó chiếu hết. Vụ này hiếm lắm.

Đối với các sản phẩm nổi tiếng như: Microsoft Dynamics, Salesforce, SAP hay Oracle, các chức năng của họ đã quá chuẩn rồi. Anh em thử nghĩ đi, nếu mình làm một cái gì đó quá lệch với những cái chuẩn của thị trường thì rõ ràng là không hợp lý về mặt hiệu quả kinh tế của chính sản phẩm đó rồi.

Đồng ý là sẽ có một vài sự chênh lệch giữa requirement và các chức năng mặc định của hệ thống. Nó có thể đến từ sự khác biệt giữa các quốc gia, khu vực.

Như bên châu Mỹ thì có thể họ không cần contract khi ra hợp đồng. Mà họ xem luôn báo giá như là một giấy tờ chứng minh việc mua hàng. Hay quy trình kinh doanh của người ta có quá nhiều điểm đặc biệt. Nhưng chắc chắn, sẽ luôn có sự chênh lệch giữa requirement và các chức năng chuẩn của hệ thống.

Đây chính là lúc giá trị của một người làm Functional Consultant (người làm công việc Business Analyst) phát huy tốt nhất. Là BA, mình phải luôn biết được hệ thống mình làm được gì, team mình làm được gì. Đâu là giải pháp tốt nhất với khách hàng, đâu là giải pháp không nên làm.

Guide cho người ta đi theo những chức năng chuẩn của hệ thống là điều cần thiết. Bằng cách này hoặc cách khác. Bằng góc nhìn này hoặc góc nhìn khác. Mình phải cố giải quyết bài toán của khách hàng bằng chức năng chuẩn của hệ thống, zậy mới hết sảy con bà bảy!!!

Credit: Ảnh từ Modern Analyst

Đối với một dự án triển khai, việc guide khách hàng đi theo những hệ thống chuẩn ngay từ đầu rất quan trọng. Nó hướng cho khách hàng biết được rằng, hệ thống chắc chắn sẽ giải quyết được những vấn đề nào của họ. Do đó, rất nên lấy những chức năng mặc định của hệ thống, để bắt đầu câu chuyện lấy requirement với khách hàng!

Thực tế thì ở nhiều dự án sau, mình mới rút kinh nghiệm được điều này.

Để có một cái nút mới (button) trong D365 (Dynamics 365) thì thường phải coding thêm, chứ không configure được.

Requirement ở đoạn này là: user 1 nhấn cái nút để yêu cầu duyệt báo giá. Sau khi nhấn nút, email sẽ tự động gửi tới Manager của người nhấn nút để yêu cầu duyệt. Manager sẽ nhấn nút “approve” hoặc “reject” để duyệt báo giá. Sau đó, cũng có 1 email gửi trả báo giá về cho user kèm thông báo. Thì lúc này mình sẽ có 3 cái nút đúng không nào:

• Nút Request Approval (dành cho user)
• Nút Approve (dành cho Manager)
• Nút Reject (dành cho Manager)

Nhưng khoan, thay vì làm cả 3 cái nút tốn nhiều effort như vậy, mình còn 1 vài cách nữa.

D365 hỗ trợ cho configure được khá nhiều trên hệ thống. Thay vì nhấn 1 cái nút yêu cầu duyệt, user có thể chuyển 1 dữ liệu thành Yes để yêu cầu duyệt báo giá!!! Mình chỉ cần tạo 1 dữ liệu tên là “Request Approval”, kiểu dữ liệu là option set (Yes/ No) và xem như nó là 1 cái cờ là ok.

User muốn yêu cầu duyệt thì bật cờ lên “Yes”, còn không thì để cờ ở “No”. Rồi configure thêm 1 cái workflow để nó lắng nghe dữ liệu Request Approval. Nếu Request Approval là “Yes” thì gửi email, còn “No” thì thôi.

Còn phía Manager cũng tương tự với việc tạo một dữ liệu. Tên là “Approve” đi chẳng hạn và để mặc định là Null. Manager bật “Yes” thì là duyệt, “No” thì không. Và chắc chắn là còn nhiều cách nữa để hoàn thành requirement này mà không cần đến coding.

Microsoft Dynamics 365

Dĩ nhiên, anh em sẽ phải chọn cách tốt nhất để deliver cho khách hàng. Nếu việc configure trên hệ thống không đáp ứng được requirement lẫn non-functional requirement, thì sẽ quay lại phương án coding.

Nhưng dù gì đi chăng nữa, mindset hạn chế coding vẫn rất quan trọng trong các dự án triển khai.

2.2 Không lường trước được… bug!

Bug là hệ quả chắc chắn xảy ra khi coding quá nhiều. Bug thì dự án nào cũng có, nhiều hay ít mới quan trọng.

Lúc anh em đang làm trên môi trường dev, vì 1 số lý do về requirement mà team mình phải coding khá nhiều.

Xong xuôi hết, đưa lên UAT, rồi Production. Kể nhanh vậy thôi, chứ việc đưa từ môi trường này sang môi trường khác team mình gặp cực kỳ nhiều vấn đề.

Vì coding nhiều, mà lại không quản lý được sự thay đổi trên hệ thống. Code cái gì, sửa cái gì, configure cái gì, không keep track được. Nên việc đưa qua đưa lại giữa các môi trường nó không tương thích, nên gặp nhiều vấn đề.

Fix tới fix lui thì cũng UAT được, rồi Go-live thành công. Đoạn tới 1 ngày đẹp trời, Microsoft tự động nâng cấp hệ thống, lên version mới. Bug bắt đầu xuất hiện. Mà trong đó khoảng gần 1 nửa bắt nguồn từ lỗi coding.

Team cũng dần dần fix được. Nhưng duy nhất có 1 lỗi không detect được và cũng không giải quyết được. Đành raise ticket nhờ support từ Microsoft. Và phải mất hơn 2 tuần mới giải quyết thành công.

Thậm chí có vài bug team phát hiện ra, gửi Microsoft nhờ support. Microsoft cũng bó chiếu luôn!!!

Vì đơn giản là 1 hệ thống khủng như vậy, nội đến chuyện Microsoft họ tự quản lý các issue phát sinh trong quá trình sử dụng chức năng chuẩn còn khó. Nói gì đến việc giải quyết được bug do các partner tự code. Do đó, nếu không cần thiết thì hẳn khoan coding nhé anh em.

…

3. Mindset của người làm Business Analyst?

BA thì có nhiều lĩnh vực, nhiều domain knowledge khác nhau. Có người chuyên về CRM, chuyên về ERP, về HR, về DMS hay Marketing…

Cách tiếp cận dự án của BA quan trọng ở chỗ này. Làm dự án nào thì nên tiếp cận dự án theo mindset đó. Không thể đem mindset của ERP áp dụng cho một dự án làm CRM được.

Thông thường một hệ thống CRM được sử dụng chủ yếu bởi nhân viên sales và marketing.

Mà thông thường thì cái ớn nhất của Sales là việc báo cáo, là report. Như một ngày làm sales quá trời quá đất, từ email đến điện thoại, chưa kể sales đi field thị trường nữa. Tối về còn phải tổng hợp số liệu là một cực hình đối với họ. Chưa kể nói về Sales thì có rất nhiều trường hợp có thể xảy ra. Nên quy trình sales trên hệ thống phải rất linh động.

Hiểu được công việc của họ, đem mindset của người làm sales áp dụng vào hệ thống. Làm CRM, hãy chắc chắn rằng hệ thống của mình đừng nên “quá chặt chẽ”. Mà hãy “nới lỏng” ra một chút.

Tưởng tượng mình là 1 seller, phải tạo mới 1 khách hàng trên hệ thống. Lúc này system bắt phải nhập đủ thứ, từ dữ liệu này tới dữ liệu khác mới cho lưu thì thực sự nó chả sát thực tế tí nào.

Chưa kể chưa nhập xong thì phải lo tiếp nhận một khách hàng khác, rồi phải tiếp tục đi chào cho kịp số. Chắc chắn người dũng sẽ không happy và dường như hệ thống này sinh ra không phải để dành cho họ.

Thường quan sát thì mình thấy: CRM luôn có độ nới lỏng nhất định đối với hành vi của users. Còn ERP thì mang tính quản trị số liệu nên cần sự chặt chẽ hơn.

Mình nhớ có lần mình làm 1 dự án chuyên gia công – sản xuất theo đơn đặt hàng. Doanh nghiệp này có quy trình duyệt giá và xin giá rất chặt chẽ.

Bước 1 xong thì phải qua bước 2, tới đích thị ông này, bà kia. Ông này mà không duyệt xong thì không cho qua. Duyệt xong thì qua bước 3. Mà bước 3 phải tiếp nhập đủ cái này, đủ cái kia. Nói chung là phải đúng và đầy đủ thì hệ thống mới cho qua.

Về mặt requirement thì process này đáp ứng đầy đủ 100%. Nhưng trong tương lai, nếu khách hàng thay đổi quy trình một chút thì gãy hết. Vì tất cả làm bằng coding nên khó mà thay đổi quy trình linh hoạt được.

Trong tháng cuối dự án chuẩn bị Go-Live, khách hàng họ thay đổi template report cho sales liên tục. Mà mỗi lần là 1 cấu trúc khác nhau. Vì nhu cầu quản trị, nên đó hoàn toàn là điều bình thường. Do đó hệ thống cần phải linh hoạt và thích nghi được với mọi sự thay đổi.

4. Đi training nói gì cho hấp dẫn?

Thú thật với anh em là đi train cho người ta thì đừng có nổ banh xác là hệ thống của tui làm được cái này, cái kia. Người ta ngáp dài hết mất. Cái cần nói là hệ thống của mình giúp gì được cho họ. Cái này quan trọng à nhen.

Hồi đó mình đi training cũng nói nhiều về hệ thống của mình lắm. Nhưng mindset của mỗi người là khác nhau. End-users thì thường không phải là Sếp.

Cái họ cần quan tâm là: hệ thống giúp họ giải quyết được gì trong mớ bồng bông công việc. Mà để nói được cái này thì chắc chắn phải hiểu được… công việc của họ!

Cái này ngó bộ dễ mà thiệt ra hồi đó mình chả quan tâm. Bản thân mình phải tự trả lời được câu hỏi:

Lúc lấy requirement, mình đã hiểu khách hàng hết chưa? Mình đã hiểu đầy đủ công việc hằng ngày của họ chưa, hay chỉ là đang mường tượng ra “cái-quy-trình” mà họ làm thường ngày thôi?!?

Thường thì phải ngồi trực tiếp, quan sát users làm thực tế thì mới clear được toàn bộ requirement. Mà điều này chỉ thường xảy ra khi anh em trực tiếp support users.

Tức là tới công ty người ta, ngồi làm việc chung với khách hàng, giống hệt anh em là nhân viên của công ty đó vậy.

Đây là cơ hội không thể tốt hơn để anh em hiểu requirement thực sự của khách hàng. Tại sao họ lại yêu cầu vậy, mà không yêu cầu khác đi. Chưa hết, mình còn có cơ hội biết được hệ thống trước họ sử dụng như thế nào nữa. Hoặc các hệ thống liên quan hình thù nó ra sao nữa.

Biết được cái này vô cùng quan trọng nhen, đặc biệt trong các dự án mà có tích hợp nhiều hệ thống với nhau. Đây là cơ hội quá tốt. Nhưng tiếc cái, nếu chờ tới lúc on-site support mà mới tiếp cận được những thông tin này thì đã quá trễ. Vì thường thì lúc này đang chuẩn bị Go-Live xong hoặc đã Go-Live xong quéo rồi.

Do đó ngay lúc lấy requirement, hãy tận dụng các cơ hội được quan sát và ngồi trực tiếp với users. Lúc họ thực hiện nghiệp vụ thường ngày. Có như vậy, mình mới nắm được thực tế và chính xác công việc hằng ngày của họ được.

11 cách lấy requirement phổ biến cho BA

Lúc này khi đã biết rõ được công việc thực tế hằng ngày của end-users, mình sẽ mapping nó vào hệ thống lúc training.

Ví dụ trong concept CRM thì có Lead, tức là 1 đầu mối kinh doanh. Nhân viên Marketing hoặc Sales sẽ chăm sóc Lead này thành một cơ hội kinh doanh thực thụ. Để rồi mục tiêu cuối cùng là ra được đơn hàng.

Mapping công việc thực tế của users vào hệ thống thực ra cũng không khó đâu. Chỉ cần show cho họ thấy được thực tế. Ví dụ như:

Lúc trước là bên Marketing phải copy toàn bộ data khách hàng vào excel. Rồi gọi điện từng ông confirm, rồi lại nhập thông tin vào Excel.

Sau đó lọc những Lead nào ổn ổn, rồi gửi cho Sales làm việc tiếp. Cái nào gửi rồi, note lại, cái nào chưa thì đánh dấu.

Công việc cứ tiếp diễn, đến kỳ báo cáo thì ngồi lấy lại toàn bộ file excel trước đó. Lọc qua hai ba lượt rồi kéo biểu đồ, số liệu này nọ ra, gửi sếp report.

Nhưng bây giờ có hệ thống, thì công việc sẽ được rút ngắn hơn. Mình chỉ việc tạo một cái Lead (hoặc import danh sách Lead vào hệ thống). Gọi điện và cập nhật dữ liệu lên hệ thống. Bấm nút “Qualify” một cái bụp, Lead tự động được gửi tới nhân viên Sales cần nhận. Thế là xong! Cuối kỳ không cần phải báo cáo gì hết, vì đã có hệ thống tự làm!

Đó, mình chỉ cần cho user thấy được cái THỰC TẾ trước mắt họ sẽ làm, cái đó giúp họ được gì. Thì chắc chắn buổi training của mình có giá trị và gây hứng thú tới người nghe.

Nói về cái mình có luôn là thứ gây buồn ngủ nhất trên đời!!! (Credit hình: BusinessIllustration.com)

5. Việc gì người ta phải sử dụng hệ thống của mình?

5.1. How can I help you?

Đây là câu hỏi mình suy nghĩ rất nhiều trong quá trình training. Thường thì con người ta có khuynh hướng co lại khi tiếp cận một cái mới. Kể cả người lớn tuổi lẫn người trẻ.

Luôn có một câu hỏi ngầm đặt ra trong đầu end-user. Mà thường thì họ chẳng bao giờ nói ra là: “Việc gì mình lại sử dụng phần mềm này???”

Trả lời được câu hỏi này. Anh em chắc chắn đang làm đúng giá trị của một người BA: đem lại chính xác thứ mà khách hàng cần, đó là giải pháp.

Cần phải chắc chắn rằng, hệ thống đã “gãi đúng chỗ ngứa” của khách hàng.

Nhưng mình quên bà mất cái này trong dự án đầu tay. Nhiều lúc dồn lực, dồn sức cho mấy cái requirement, mà bản thân nghĩ cứ nghĩ nó là quan trọng. Nhưng làm xong lại thấy chả có kí lô nào trong mắt khách hàng hết.

Những quy trình như tạo khách hàng, qualify Lead, duyệt giá, xin giá hay lên đơn hàng. Đó đúng là những requirement và mình cần phải tuân theo. Nhưng hoàn thành 100% những requirement này lại không đảm bảo sự thành công của dự án.

Nó còn nằm ở Non-requirement nữa. Điều này thực sự rất quan trọng.

Users có tiện dùng chức năng đó hay không. Họ có thấy happy khi dùng hệ thống hay không. Liệu hệ thống có thực sự rút ngắn thời gian của họ. Hay nó lại là một gánh nặng “bắt buộc phải làm theo chỉ đạo của sếp”!?!

Phía users Sales họ thao tác trên email rất nhiều. Thông thường trong 1 công ty, bất kể bộ phận nào, 2 phần mềm họ sẽ luôn dùng nhiều nhất là: Excel và Outlook.

Có mấy dự án, dàn Sales Manager lúc nào yêu cầu toàn bộ nhân viên phải gửi mail bằng hệ thống. Anh nào gửi mail bằng Outlook là bị “xử trảm” liền.

Để tiện keep track chứ chả có gì hết ráo. Sếp muốn xem thử, mức độ chăm sóc khách hàng của sales đã đủ hay chưa.

Mà kẹt cái, chức năng gửi email của D365 thì lại rất cùi bắp. Nó hạn chế tùm lum thứ như: font, size, signature, đính kèm hình, file, abc, xyz… Cái đâm ra end-users bên phía khách hàng bất bình lắm.

Best practice muốn sử dụng email tốt trên D365 thì phải cài 1 cái app bổ sung (D365 Apps for Outlook). Thế là lúc Go-Live, anh em cứ tự tin là solution đã đáp ứng hoàn toàn requirement. Nhưng lại quên mất 1 thứ cũng quan trọng không kém là: chức năng gửi email lại chưa được hoàn thiện.

Anh em cứ tưởng tượng xem. Ngày nào mình cũng uống nước bằng ly. Tự nhiên đùng 1 cái, bắt mình ngày nào cũng uống nước bằng… dĩa!!! Ai mà chả khó chịu đúng không. Uống bằng ly quen rồi, uống được nhiều mà dễ nữa. Tự nhiên giờ bắt uống bằng dĩa, chả uống được bao nhiêu mà còn dễ bị đổ nữa.

Cái này cũng giống như việc trước giờ mình gửi email qua Outlook quen rồi. Mà giờ bắt gửi email qua 1 cái phần mềm hạn chế đủ trò, từ font chữ cho tới ký tự. Không khó chịu mới lạ.

Chính vì vụ gửi email này làm dự án bị delay hơn cả 1 tuần để configure thêm. Users cũng khó chịu, phía team triển khai cũng tốn thêm thời gian.

Thiệt ra thì chỉ cần focus vào 20% những requirement quan trọng, nhưng nó đem tới 80% mức độ hài lòng của khách hàng. Và chức năng email là 1 trong số 20% requirement quan trọng kia.

5.2. Tản mạn về users

Có lần mình đi training gặp 1 bà chị bên sales. Chị đó là người chăm chú lắng nghe nhất. Và cũng là người năng nổ nhất trong việc đặt câu hỏi trong buổi training.

Mình nghĩ bụng phải ai mà cũng nhiệt như bả thì đỡ biết mấy. Thực tế thì chị đó rất chịu khó mày mò dùng hệ thống mới. Nên rất hay đặt ra những câu hỏi hay.

Training xong, đoạn users sử dụng thực tế để test, thì chị này cũng là người năng nổ nhất. Nhưng lại là người năng nổ… complain nhất.

Thực tế thì cũng không có gì. Vấn đề là ở vụ email như mình có nói ở trên. Việc một người users có cảm xúc mạnh như vậy cũng là một điều dễ hiểu.

Điều đáng nói là chính vì những phản ứng và cảm xúc đó mà mình mới thấy được đâu là cái khách hàng quan tâm thật sự.

• Cái họ muốn nhận được là một thứ giúp họ tiện lợi hơn trong công việc. Chứ không phải cản trở họ.
• Cái họ muốn nhận được là một hệ thống CRM giúp họ theo dõi được khách hàng, chứ không phải một mớ bồng bông các chức năng trên trời.
• Cái đó muốn nhận được là những báo cáo công việc hằng ngày của chính họ. Hiển thị rõ ràng, chính xác và đẹp đẽ trên dashboard. Chứ không phải là những phân tích hay dự đoán đao to búa lớn mà mình cứ chăm chăm vào build cho bằng được.

Anh em mình cần tập trung vào những gì Users làm được trên hệ thống. Thay vì những gì hệ thống có thể làm được.

Trên là những chiêm nghiệm mà mình rút ra được từ các dự án triển khai D365. Nếu còn thời gian mình sẽ note tiếp nhé anh em. Hẹn gặp anh em ở những bài sau! See yaaa!!!