[Kể chuyện đời] Cuộc sống, công việc của một Data Analyst trái ngành

Đọc thớt từ page đầu đến giờ mình thấy thớt ko phải là Data analyst rồi mà thực ra đây là Kế toán có thêm một số skill của DA.Vậy mà thớt giật tít, ăn theo trend Data. Vậy rồi nhiều bé hiểu lầm đổ xô vào data :(

Thớt là kế toán học thêm skill data. Rõ ràng ra như vậy đi.
 
Last edited:
có ACCA mà ko đc tăng lương à bác ?

Thực ra thì.... tùy nhu cầu của DN mà. ACCA này là do cty kêu mình đi học hay mình tự học; chứ mình tự đi học ko ai mướn thì lý do đâu mà tăng lương :sweat:

Cách khả quan hơn vẫn là có ACCA sau đó nhảy job để tăng lương, có offer mới thì có thể quay lại kỳ kèo vs sếp
5gcj2yy.gif


Đọc thớt từ page đầu đến giờ mình thấy thớt ko phải là Data analyst rồi mà thực ra đây là Kế toán có thêm một số skill của DA.Vậy mà thớt giật tít, ăn theo trend Data. Vậy rồi nhiều bé hiểu lầm đổ xô vào data :(

Thớt là kế toán học thêm skill data. Rõ ràng ra như vậy đi.
Thì tiêu đề ổng ghi rõ rồi mà: Data analyst trái ngành, tức là vốn ko phải dân chuyên DA mà rẽ ngang :waaaht:
Nhưng tính ra nhờ vậy kiến thức về business/finance mới ổn dc vậy á, chứ học DA mà ko có tí kiến thức nào về business đi giải thích cho các ông cũng mệt lắm
uxby0Nl.gif
 
Thực ra thì.... tùy nhu cầu của DN mà. ACCA này là do cty kêu mình đi học hay mình tự học; chứ mình tự đi học ko ai mướn thì lý do đâu mà tăng lương :sweat:

Cách khả quan hơn vẫn là có ACCA sau đó nhảy job để tăng lương, có offer mới thì có thể quay lại kỳ kèo vs sếp
5gcj2yy.gif



Thì tiêu đề ổng ghi rõ rồi mà: Data analyst trái ngành, tức là vốn ko phải dân chuyên DA mà rẽ ngang :waaaht:
Nhưng tính ra nhờ vậy kiến thức về business/finance mới ổn dc vậy á, chứ học DA mà ko có tí kiến thức nào về business đi giải thích cho các ông cũng mệt lắm
uxby0Nl.gif
:( :(:(:(
Mình cứ tưởng tìm được đồng môn.
Nhiều khi đọc mình nghĩ bác này cũng chưa phải là DA luôn.
DA vốn dĩ nghiêng về mặt data, tức là nhận kết quả và xử lý và phân tích data chứ involve đến mức detail thế kia thì ko phải rồi.
Scope của mình còn handle toàn bộ data từ build datamart, đảm bảo report của phòng chạy mỗi ngày. Bác này mình đọc thấy chưa có luôn mà.
 
:( :(:(:(
Mình cứ tưởng tìm được đồng môn.
Nhiều khi đọc mình nghĩ bác này cũng chưa phải là DA luôn.
DA vốn dĩ nghiêng về mặt data, tức là nhận kết quả và xử lý và phân tích data chứ involve đến mức detail thế kia thì ko phải rồi.
Scope của mình còn handle toàn bộ data từ build datamart, đảm bảo report của phòng chạy mỗi ngày. Bác này mình đọc thấy chưa có luôn mà.

Góc độ làm Kế toán tôi chưa hiểu lắm, fence giải thích thêm nhé, tại vì từ view của t thì thấy thớt cũng gọi là DA rồi chứ nhỉ :big_smile:
tức là nhận kết quả và xử lý và phân tích data
-> Chỗ nhận kết quả & xử lý thì t nghĩ ai cũng làm dc, nhưng nếu ko có kiến thức ngành/business thì bác định phân tích data kiểu gì, này hỏi thật đấy :ops:
Và thường thì phân tích phải đi đến mức độ chi tiết hết sức có thể mới đủ đưa ra insight (kiểu 5 Whys) ấy
8JgyqcC.gif


Cho nên, nếu làm dc đến mức này:
đến mức detail thế kia thì ko phải rồi.
thì tâm lý người ta sẽ thích hơn (nếu t là sếp thì sẽ nghĩ vậy) :shame:

Scope của mình còn handle toàn bộ data từ build datamart, đảm bảo report của phòng chạy mỗi ngày. Bác này mình đọc thấy chưa có luôn mà.
-> Hình như là trong scope ko có build datamart (trong cty có đội khác lo việc đó rồi) , nhưng có các step automate/chuẩn hóa báo cáo mà nhỉ. Cái này cũng rất là hữu ích đó :big_smile:

Nói chung theo cảm nhận của t thì roles của fence và bác thớt là 2 mắt xích nằm cạnh nhau trong 1 chuỗi dây chuyền vậy, và khi càng làm lâu thì scope của người này sẽ từ từ lấn sân sang người còn lại, nên cái ranh giới giữa 2 roles càng lúc càng mờ đi chứ ko rõ ràng như fence nghĩ đâu, thôi cứ gọi chung là DA chắc cũng dc nhỉ
FllsH3j.gif
 
2. Thường thì thủ thuật nó đến từ các ước tính kế toán là chính bác, ví dụ như trích lập dự phòng. Và các thủ thuật này chủ yếu hướng đến cook số lợi nhuận chứ dòng tiền thì nó đúng kiểu cash-trans, khó pha ke nếu không dùng đến các bên thứ 3. Hold thanh toán, đẩy tồn kho, nợ NCC thực chất nó chính là giải pháp để quản trị dòng tiền chứ không phải thủ thuật bác. :D. Thường thì nhận biết biến động các khoản VLĐ do bản thân doanh nghiệp tốt lên hay là giải pháp cứu dòng tiền thì cứ nhìn vào biên lợi nhuận hoặc thuyết mình chi phí tài chính trong kỳ là thấy.
3. Đồng ý với góc nhìn của bác. Như mình đã nói cái này góc nhìn của bác và mình đang GAP từ đầu rồi.
1+4+5+6. Đồng ý với bác luôn, như vậy mình hiểu góc nhìn của bác hướng tới forecast ngân sách và kế hoạch thu chi tiền (chỉ tập trung vào cash-trans) nên DCF hữu ích hơn, vì đối tượng tham gia bao gồm cả dân non-A&F. Nhưng với mục đích đánh giá dự án, kế hoạch kinh doanh,... thì luôn là cơ sở ICF vì chỉ có PL mới thể hiện được business model.
7. À ý của mình là đừng chủ động học "chi tiết" nếu không có cơ hội áp dụng ngay. Chứ thực ra mình vẫn luôn phải cập nhật những cái mới, nhưng chỉ tìm hiểu để biết tổng quan và khi nào có cơ hội thực hành mới đi sâu vào chi tiết. Ví dụ, mình muốn học Tableau, mình sẽ chỉ quan tâm nó làm được gì, chưa vội đi sâu nó làm được những thứ đó ntn. Vì không có cơ hội thực hành thì nhanh quên lắm bác. Thế nên mình không prefer học trung tâm vì họ dạy chi tiết (như thế không phải là xấu, đó là trách nhiệm của họ, nó phù hợp với các bạn thụ động chờ đc chỉ từng tí một), nếu muốn mình sẽ tìm các khóa học để có kiến thức tổng quan hơn.
1. Mình cũng trao đổi vs bác GBPham trước đó rồi, bác cũng chỉ cho mình ICF thể hiện mối liên hệ giữa profit và tiền, mình xem lại thì ICF bản chất là bảng reconcile từ PBT để ra Cash nhưng mình cũng challenge lại bác ấy là thực tế bây giờ profit và cash có khi chả liên quan gì tới nhau cả, việc gì phải reconcile từ profit ra cash làm gì khi 2 cái đó trên ghi nhận kế toán đâu liên quan (ghi nhận kế toán đâu dựa theo dòng tiền thực thu thực chi đâu) :ah:,anw dù sao cũng thank bác cho góc nhìn khác về ICF, trước mìnhđi từ audit thấy số từ ICF toàn số balancing nên hơi kì thị nó :beat_shot:
2. Vụ "chi tiết" thì mình ok vì mindset mình khá tốt về phân tích (hihi tự cảm nhận :boss:) mỗi tội là thiếu toolđể làm nên mình chủđộng học qua qua 1 số thứ như sql, power bi trước, vì việc chỗ mình thu nhập ổnnhưng nó sẽ đều đềuấy, chủ động thayđổi không sau dễ bịđào thải.

3. Có cái bên analytic này hằng hà đa số chứng chỉ hay sao ấy, và hình như chẳng có một chứng chỉ nào Tier S lvl. Bên chuyên ngành như Fin/Acc thì dễ lựa chọn hơn, quanh đi quẩn lại có ACCA/ICAEW/CPAaus với accouting, CIA ksnb, CIMA/CMA kế quản trị, CFA tài chính, FRM qtrr mà các chứng chỉ còn công nhận lẫn nhau nữa. Bên data e thấy hằng hà sa số khoá học và cả mả chứng chỉ chả biết đường nào mà lần. E không có ý chuộng bằng cấp nhưng kiểu e học xong thì có 1 bên external vào review để xem em đã đạt được cái trình độ tối thiểu để tốt nghiệp chưa (Vì em không có pain point hiện tại để giải quyết như bác, có thì có nhưng ở mức hệ thống chứ mình e không control được)
 
Hello các bác, em cũng làm kế toán, cũng đang học thêm tools data như Power Querry/ Pivot/ BI.

Em xin phép chia sẻ view của e về DCF

1. Về DCF, theo VAS 24 và IAS 7 có tới 2 cách để lập nhưng không hiểu sao về TT200 lại chỉ hướng dẫn lập theo Phân tích và tổng hợp trực tiếp các khoản tiền thu và chi theo từng nội dung thu, chi. Dẫn đến khi làm DCF ở Việt Nam phần lớn kế toán theo TT200.

1692242499053.png


1692242528948.png


2. Em cũng đã ngồi lập DCF theo cách thứ 2 thì e thấy rằng khi hoán đổi chỉ tiêu một chút nó sẽ khá giống phương pháp lập ICF.
 
có ACCA mà ko đc tăng lương à bác ?
học vì kiến thức của bạn, bạn học xong có kiến thức, mang lại added value cho Dn thi là sẽ tăng lương, không phải cầm cái bằng ném vào mặt họ là họ tăng x2 lương cho bạn đâu.
ACCA cũng có this that thôi, nhưng phần lởm nó íthơn vì kiểm soát đầu ra khá chặt, việc có acca mà k có chữ gì là hiếm, không như bằng đại học hay thạc sĩ tại việt nam (đặc biệt ngành kinh tế)
Mình thấy acca là 1 bằng cấp khá tốt để theo, từ acca xong bác định hướng mình theo cái j thì học tiếp. Acca bao quát bao gồm Finance, accouting, auditing, tax. Từ đó bác theo hướng nào thì học chuyên sâu cái đó thôi.
Ngoài ra các chứng chỉ khác công nhận acca cũng kha khá (thừa tiền thì đổi để đẹp CV) như CIA, ICAEW, CPA aus, CMA, CIMA
 
Đọc thớt từ page đầu đến giờ mình thấy thớt ko phải là Data analyst rồi mà thực ra đây là Kế toán có thêm một số skill của DA.Vậy mà thớt giật tít, ăn theo trend Data. Vậy rồi nhiều bé hiểu lầm đổ xô vào data :(

Thớt là kế toán học thêm skill data. Rõ ràng ra như vậy đi.
Oh mình ghi rõ ở tittle rồi mà nhỉ
 
:( :(:(:(
Mình cứ tưởng tìm được đồng môn.
Nhiều khi đọc mình nghĩ bác này cũng chưa phải là DA luôn.
DA vốn dĩ nghiêng về mặt data, tức là nhận kết quả và xử lý và phân tích data chứ involve đến mức detail thế kia thì ko phải rồi.
Scope của mình còn handle toàn bộ data từ build datamart, đảm bảo report của phòng chạy mỗi ngày. Bác này mình đọc thấy chưa có luôn mà.
Theo mình thấy thì việc xây dựng và duy trì hệ thống báo cáo (thường là dạng biểu đồ trực quan kết hợp bảng biểu số liệu, chủ yếu mô tả dữ liệu quá khứ) định kỳ hàng ngày/tuần/tháng/quý nên quy về role BI thì đúng hơn. Role DA đúng nghĩa thường tập trung vào các phân tích kiểu Ad-hoc, và kết quả thường là 1 bài trình bày (story telling) về insight khám phá được, giải thích phương pháp phân tích và ý nghĩa cho việc ra các quyết định có liên quan. Và công cụ cũng như kỹ năng của 2 role này cũng khác nhau tương đối.
  • BI: Tập trung vào các kỹ năng modeling, visualization,... công cụ chủ yếu là các tool BI như Tableau, Power BI, Qlik,...
  • DA: Cần nhiều kiến thức về xác suất, thống kê. Công cụ chủ yếu là các ngôn ngữ hỗ trợ xử lý và phân tích dữ liệu tốt như Python, R.
Và tất nhiên, điểm chung của cả 2 role này cần phải hiểu thật rõ business. Business knowledge ở đây có 2 khía cạnh:
  • Business functions: Là các mảng nghiệp vụ mà hầu hết doanh nghiệp nào cũng có như tài chính, kế toán, nhân sự, MKT, sales,...
  • Industry: Là các lĩnh vực kinh doanh khác nhau như bất động sản, ngân hàng, bán lẻ,...
2 cái này kết hợp lại tạo ra cả một biển kiến thức về business mà mình chắc chắn không ai dám vỗ ngực nhận mình hiểu sâu và hiểu hết (Ví dụ: Tài chính trong lĩnh vực bất động sản khác hoàn toàn tài chính trong ngân hàng, Sales bán lẻ khác hoàn toàn Sales B2B,...). Bản thân các công ty cung cấp dịch vụ triển khai hệ thống BI (Bên B) cũng chỉ dám định hướng và build team BI mạnh về một vài mảng business nhất định. Vì thế, mình tuyển BI/DA ưu tiên các bạn có business knowledge và thọt về tool hơn là các bạn mạnh về tool mà yếu business knowledge.
 
Last edited:
Oh mình ghi rõ ở tittle rồi mà nhỉ
Nhìn chung thì mình khá sure kèo fen không phải DA hay BI. Fen vẫn là kế toán chuyên nghiệp hoặc thậm chí đang giảng dạy trung tâm, trường lớp về DA/BI mà thôi.
Mình kết luận vậy cho cá nhân mình chắt lọc thông tin thôi chứ cũng không phải đánh giá mang tính khen chê gì fen đâu. Mình drop thớt fen vậy vì ko phải đồng môn rồi.

Chúc fen sức khỏe nhá.
 
Góc độ làm Kế toán tôi chưa hiểu lắm, fence giải thích thêm nhé, tại vì từ view của t thì thấy thớt cũng gọi là DA rồi chứ nhỉ :big_smile:

-> Chỗ nhận kết quả & xử lý thì t nghĩ ai cũng làm dc, nhưng nếu ko có kiến thức ngành/business thì bác định phân tích data kiểu gì, này hỏi thật đấy :ops:
Và thường thì phân tích phải đi đến mức độ chi tiết hết sức có thể mới đủ đưa ra insight (kiểu 5 Whys) ấy
8JgyqcC.gif


Cho nên, nếu làm dc đến mức này:

thì tâm lý người ta sẽ thích hơn (nếu t là sếp thì sẽ nghĩ vậy) :shame:


-> Hình như là trong scope ko có build datamart (trong cty có đội khác lo việc đó rồi) , nhưng có các step automate/chuẩn hóa báo cáo mà nhỉ. Cái này cũng rất là hữu ích đó :big_smile:

Nói chung theo cảm nhận của t thì roles của fence và bác thớt là 2 mắt xích nằm cạnh nhau trong 1 chuỗi dây chuyền vậy, và khi càng làm lâu thì scope của người này sẽ từ từ lấn sân sang người còn lại, nên cái ranh giới giữa 2 roles càng lúc càng mờ đi chứ ko rõ ràng như fence nghĩ đâu, thôi cứ gọi chung là DA chắc cũng dc nhỉ
FllsH3j.gif
Mình đọc còm thím mấy bữa rồi mà lười reply. Cviec cũng lu bu.
Nói chung là những cái thím nói chỉ là góc nhìn của người đứng xem và đọc các định nghĩa, JD. Còn công việc trong thực tế thì DA là DA phân tích đào bới data chứ không phải là hiểu đến chân tơ kẽ tóc nghiệp vụ vì nếu như vậy chẳng ai mướn thêm kế toán, quản lý rủi ro, nghiệp vụ kinh doanh, thẩm định, nhân sự.v...v... nữa rồi. Ngta tuyển thẳng Data Analyst để làm tất cả cho nhanh, vì vạn năng quá mà.

Cviec hằng ngày của mình bên cạnh việc đảm bảo hệ thống report của phòng mình hoạt động trơn tru, xây dựng datamart thì mình đào bới dữ liệu để tìm insight cho phòng mình. Có lúc trưởng phòng order cho mình việc "tháng này tỷ lệ khách hàng doanh nghiệp giảm nặng, tìm nguyên nhân thử xem. Lấy số lượng application đầu vào, số lượng đơn vay bị từ chối vì lý do gì, nhóm khách hàng tỉnh nào từ chối,v.v....." , những việc này chính là bới data. Mình lấy hết data và phân tích ở cơ bản xong , ngồi hội ý với đội phân tích nghiệp vụ , bắt đầu đào sâu hơn

Đội nghiệp vụ cho biết(cũng là đội ban hành chính sách mới) "à tháng này đội modeling vừa siết chặt thêm scoring, vừa gài thêm 1 rule a,b,c yêu cầu khách phải có xyz,...". Đội phân tích nghiệp vụ mở hết tài liệu chứng từ ra ngồi xem các trường hợp bị thẩm định hồ sơ cho là không đạt,.v.v.... Nghe recorded điện thoại khi điều tra viên gọi đến và đánh rớt hồ sơ khách này.
Những thứ này là không có data. Chứng từ có lưu thành data nhưng công việc DA không phải ngồi nhìn hồ sơ mà chỉ lấy ra thôi.

Những cái phân tích cơ bản bên trên vẫn không ra point out hay insight thì quay lại lượt mình sang data. Bắt đầu kéo hết nhóm khách hàng bị từ chối kết hợp với dữ liệu nợ từ các ngân hàng khác xem 1 khách đấy đã vay bao nhiêu hồ sơ mà bị từ chối. Số lượng 3000 khách đang bị từ chối nằm ở nhóm đang mắc nợ ở mấy ngân hàng , nhóm 3 ngân hàng, nhóm 4 ngân hàng hay nhóm 2 tổ chức tín dụng bla bla...

Hoặc một bài khác là phân tích tỷ lệ khách hàng quỵt nợ sau 6 tháng đang đi lên quá cao , vì sao vậy? Vừa rồi mình phải đào hết data nối với lại dữ liệu danh bạ của các khách trong diện quỵt nợ (1 tháng vài trăm case) nhìn kết quả trả ra thì thấy danh bạ các khách có dưới 30 số điện thoại đang có dấu hiệu quy mô lớn -> chuyển ngay cho an ninh tập đoàn gửi C06 điều tra xem có tổ chức đường dây tội phạm kinh tế ko.

................

Đấy, đâu phải cứ data hiểu nghiệp vụ là thay thế được và cho ra được insight , đó là tổ hợp của teamwork và dụng DA ở các công ty cần thiết thực sự cần data. Tất nhiên càng hiểu rõ là điều tốt , giúp ích cho công việc suôn sẻ hơn. Nhưng gì cũng vậy, có cái giới hạn. Ngta thuê vị trí DA khác, DS,DE và các kế toán, nghiệp vụ,.v....v... đều có mục đích. Chẳng qua là chưa hiểu cách làm việc vị trí đó mà thôi.

-------------
Thím thắc mắc và cho rằng tại sao DA phải build datamart. Hiện nay ít nhất các cty mình biết DA đều phải build datamart và điều đó hoàn toàn đúng. Doanh nghiệp đã sử dụng data là huyết mạch kinh doanh thì lượng data rất khủng khiếp. Như techcombank hiện nay bạn mình nói đã có database đến 2 tỷ dòng.

Table chứa khách hàng mới, table theo dõi khách hàng đang sử dụng dịch vụ, table chứa các dịch vụ mà khách hàng đang dùng. Không thể nào cứ mỗi lần muốn xem khách ID123 đang sử dụng dịch vụ 597 thì gọi BI hay DE đi nối data lại để xem khách đó sử dụng dv 597 là dịch vụ gì.
Đã là SQL thì phải build datamart chứ không phải excel bấm open là mở lên đọc từng file.
---
Tại sao cviec mình có cả owner và build report. Vì cấu trúc của công ty mình và nhiều ngân hàng, sàn tmdt, logistic company khác là Decentralized data. Tức data đưa về từng phòng ban. Không phải rằng công ty có bao nhiêu data đổ về hết cho 1 bộ phận BI/MIS/DE xây dựng từ dataware house đến reporting. Như vậy là thắt cổ chai khi chuyện gì cũng phải đợi. Cũng giải thích luôn chuyện DA phải build datamart.

Mô hình tổ chức đội ptich dữ liệu như vậy cũng là tiên tiến nhất hiện nay, khác nhau về cách tổ chức vi mô thôi.

1692381330548.png


---------------

Tóm lại những cái mình nói không phải chỉ là tool. DA vừa phải tool vừa phải hiểu về nghiệp vụ. Còn đi đến sâu xa detail nghiệp vụ như mở báo cáo tài chính ra đọc thì không phải rồi; đó là một chuyên gia/chuyên viên lĩnh vực nào đó học thêm skill DA/DS chứ không phải DA/DS.
 
Last edited:
Hồi mới đầu mình cũng nghe myth là sau này nghề data sẽ thay thế mất vì ai cũng sẽ có kỹ năng data. Mình thấy không phải đâu. Con người ai cũng có điểm giới hạn, ko vị trí cviec nào là vạn năng. Và người chuyên nghiệp data sẽ ngày càng nhiều lên vì sự phát triển của xã hội số hóa.

Nói chung là làm thôi, bản thân muốn gì thì đi theo đó. Data đi về hướng tool cũng được, đi về hướng nghiệp vụ cũng xong. Ai giỏi đều hết thì éc có đâu, chắc cực cực hiếm. Không ít người mình quen làm data 1 tgian xong chuyển hẳn sang làm BA,PM,Kế toán, nhân sự,planning.

Thường thì ai thích giao tiếp, thích title trưởng phòng, giám đốc thì thích chính trị công sở thì sẽ tự chạy về hướng ba,pm, kế toán quản trị, kế hoạch kdoanh,.v.v....
Ai thích làm chuyên gia, thích research, nghiền ngẫm đào bới và nghịch với dữ liệu thì đi về hướng DA/DS vận dụng nhuần nhuyễn tool, digest thật sâu vào data dnghiep, nhìn ra bức tranh insight. Đi quá sâu về tool thì ngả về DBA/DE/BI/MIS. Còn DS thì đi tiếp AI, mà ít.
 
Last edited:
Mình đọc còm thím mấy bữa rồi mà lười reply. Cviec cũng lu bu.
Nói chung là những cái thím nói chỉ là góc nhìn của người đứng xem và đọc các định nghĩa, JD. Còn công việc trong thực tế thì DA là DA phân tích đào bới data chứ không phải là hiểu đến chân tơ kẽ tóc nghiệp vụ vì nếu như vậy chẳng ai mướn thêm kế toán, quản lý rủi ro, nghiệp vụ kinh doanh, thẩm định, nhân sự.v...v... nữa rồi. Ngta tuyển thẳng Data Analyst để làm tất cả cho nhanh, vì vạn năng quá mà.

Cviec hằng ngày của mình bên cạnh việc đảm bảo hệ thống report của phòng mình hoạt động trơn tru, xây dựng datamart thì mình đào bới dữ liệu để tìm insight cho phòng mình. Có lúc trưởng phòng order cho mình việc "tháng này tỷ lệ khách hàng doanh nghiệp giảm nặng, tìm nguyên nhân thử xem. Lấy số lượng application đầu vào, số lượng đơn vay bị từ chối vì lý do gì, nhóm khách hàng tỉnh nào từ chối,v.v....." , những việc này chính là bới data. Mình lấy hết data và phân tích ở cơ bản xong , ngồi hội ý với đội phân tích nghiệp vụ , bắt đầu đào sâu hơn

Đội nghiệp vụ cho biết(cũng là đội ban hành chính sách mới) "à tháng này đội modeling vừa siết chặt thêm scoring, vừa gài thêm 1 rule a,b,c yêu cầu khách phải có xyz,...". Đội phân tích nghiệp vụ mở hết tài liệu chứng từ ra ngồi xem các trường hợp bị thẩm định hồ sơ cho là không đạt,.v.v.... Nghe recorded điện thoại khi điều tra viên gọi đến và đánh rớt hồ sơ khách này.
Những thứ này là không có data. Chứng từ có lưu thành data nhưng công việc DA không phải ngồi nhìn hồ sơ mà chỉ lấy ra thôi.

Những cái phân tích cơ bản bên trên vẫn không ra point out hay insight thì quay lại lượt mình sang data. Bắt đầu kéo hết nhóm khách hàng bị từ chối kết hợp với dữ liệu nợ từ các ngân hàng khác xem 1 khách đấy đã vay bao nhiêu hồ sơ mà bị từ chối. Số lượng 3000 khách đang bị từ chối nằm ở nhóm đang mắc nợ ở mấy ngân hàng , nhóm 3 ngân hàng, nhóm 4 ngân hàng hay nhóm 2 tổ chức tín dụng bla bla...

Hoặc một bài khác là phân tích tỷ lệ khách hàng quỵt nợ sau 6 tháng đang đi lên quá cao , vì sao vậy? Vừa rồi mình phải đào hết data nối với lại dữ liệu danh bạ của các khách trong diện quỵt nợ (1 tháng vài trăm case) nhìn kết quả trả ra thì thấy danh bạ các khách có dưới 30 số điện thoại đang có dấu hiệu quy mô lớn -> chuyển ngay cho an ninh tập đoàn gửi C06 điều tra xem có tổ chức đường dây tội phạm kinh tế ko.

................

Đấy, đâu phải cứ data hiểu nghiệp vụ là thay thế được và cho ra được insight , đó là tổ hợp của teamwork và dụng DA ở các công ty cần thiết thực sự cần data. Tất nhiên càng hiểu rõ là điều tốt , giúp ích cho công việc suôn sẻ hơn. Nhưng gì cũng vậy, có cái giới hạn. Ngta thuê vị trí DA khác, DS,DE và các kế toán, nghiệp vụ,.v....v... đều có mục đích. Chẳng qua là chưa hiểu cách làm việc vị trí đó mà thôi.

-------------
Thím thắc mắc và cho rằng tại sao DA phải build datamart. Hiện nay ít nhất các cty mình biết DA đều phải build datamart và điều đó hoàn toàn đúng. Doanh nghiệp đã sử dụng data là huyết mạch kinh doanh thì lượng data rất khủng khiếp. Như techcombank hiện nay bạn mình nói đã có database đến 2 tỷ dòng.

Table chứa khách hàng mới, table theo dõi khách hàng đang sử dụng dịch vụ, table chứa các dịch vụ mà khách hàng đang dùng. Không thể nào cứ mỗi lần muốn xem khách ID123 đang sử dụng dịch vụ 597 thì gọi BI hay DE đi nối data lại để xem khách đó sử dụng dv 597 là dịch vụ gì.
Đã là SQL thì phải build datamart chứ không phải excel bấm open là mở lên đọc từng file.
---
Tại sao cviec mình có cả owner và build report. Vì cấu trúc của công ty mình và nhiều ngân hàng, sàn tmdt, logistic company khác là Decentralized data. Tức data đưa về từng phòng ban. Không phải rằng công ty có bao nhiêu data đổ về hết cho 1 bộ phận BI/MIS/DE xây dựng từ dataware house đến reporting. Như vậy là thắt cổ chai khi chuyện gì cũng phải đợi. Cũng giải thích luôn chuyện DA phải build datamart.

Mô hình tổ chức đội ptich dữ liệu như vậy cũng là tiên tiến nhất hiện nay, khác nhau về cách tổ chức vi mô thôi.

View attachment 2023609

---------------

Tóm lại những cái mình nói không phải chỉ là tool. DA vừa phải tool vừa phải hiểu về nghiệp vụ. Còn đi đến sâu xa detail nghiệp vụ như mở báo cáo tài chính ra đọc thì không phải rồi; đó là một chuyên gia/chuyên viên lĩnh vực nào đó học thêm skill DA/DS chứ không phải DA/DS.

Nghe hợp lý phết nhỉ, vậy thì ông thớt là Finance BP hay gì đó nghe ổn hơn chăng?
zFNuZTA.png
 
Nghe hợp lý phết nhỉ, vậy thì ông thớt là Finance BP hay gì đó nghe ổn hơn chăng?
zFNuZTA.png
Chắc do mình trao đổi chi tiết sâu về F&A với bác heocon nên mọi người đang nghĩ mình đang làm mảng đó.:D:D Để mình chia sẻ sâu hơn một chút về mô tả công việc hiện tại của mình ở cả 3 Job:

1. Job chính làm cho một công ty bán lẻ của nước ngoài. Role: DA Leader. Mình lead một team DA với chiến lược hỗ trợ nhiều nhất việc sử dụng data cho việc ra quyết định. Cụ thể có 3 mảng việc lớn:
  • Nhận các các yêu cầu về report từ các phòng ban khác, tư vấn và xây dựng báo cáo theo yêu cầu. Mảng này có thể hiểu chính là role BI, tuy nhiên ở phạm vi dữ liệu lớn và nghiệp vụ phức tạp thì mấu chốt nằm ở việc xây dựng datamart linh hoạt và hợp lý, và đẩy cố gắng làm sao để End-User có thể tự chủ động lấy dữ liệu và tự tạo báo cáo được, bao gồm cả việc đào tạo và phát triển văn hóa data self-service. Còn lại các bước xây pipeline, lên báo cáo mình đánh giá nó khá "chân tay" nên định hướng đưa được các công việc này để End-user tự làm càng nhiều càng tốt, lúc đó sẽ có thời gian cho các mảng khác có value hơn. Công cụ chủ yếu là PBI, Azure SQL, Azure Data Lake,.... Đang nghiên cứu chuyển đổi về Fabric cho tiện.
  • Advanced Analytic (Phân tích nâng cao). Với mình thì đây mới đúng nghĩa là role DA. Mảng này chủ yếu tập trung vào xử lý các yêu cầu Ad-hoc, sử dụng các phân tích nâng cao (không chỉ là bày số liệu ra và nhìn bằng mắt) để tìm ra các insight. Về nguồn dữ liệu, phần lớn dữ liệu đến từ data lake chứ không phải data mart (đây cũng là một trong những khác biệt giữa 2 role DA và BI). Workflow thường bắt nguồn từ mục tiêu nghiệp vụ -> tìm kiếm dữ liệu tiềm năng có liên quan, có sẵn hoặc có thể thu thập được -> đánh giá khả năng sử dụng dữ liệu (bao gồm độ sạch, sau đó đánh về nghiệp vụ, chạy thử các đánh giá về tương quan, quan hệ về mặt nghiệp vụ của dữ liệu,...) -> Chạy phân tích -> Kiểm thử lại -> Đưa ra kết luận -> Triển khải thử nghiệm -> Đánh giá và đưa vào chính sách vận hành của công ty. Và tất nhiên không phải lúc nào kết luận cũng có ý nghĩa, việc bỏ ra một đống effort và nhận được kết quả là dữ liệu không nói lên điều gì là hoàn toàn bình thường. Ngoài ra phần việc này cũng bao gồm áp dụng các phương pháp phân tích cơ bản (Cohort, RFM, ABC analysis,...), nhưng cải tiến bằng cách áp dụng thay thế một số thuật toán phân tích nâng cao vào một step nào đó, cách này thường sẽ có kết quả vì dựa trên những phương pháp chuẩn được công nhận trước đó rồi. Công cụ chủ yếu là R và Python.
  • Định hướng về phát triển data platform cũng như nguồn lực về data: Cái này chủ yếu liên quan đến hoạch định về xây dựng hệ thống, build nguồn lực. Vì khi đơn vị lớn lên thì các nhu cầu, pain point liên quan đến data cũng thay đổi khá nhiều. Vì vậy mình cần liên tục đánh giá, cập nhật các phươn pháp, công nghệ phù hợp và các cách ứng phó kịp thời liên quan trong vòng 3-5 năm.

2. Job phụ 1 làm data SA (Solution Architect) cho một công ty sản xuất của nước ngoài. Nhiệm vụ chính là đánh giá các thay đổi liên quan đến hệ thống data khi cố gắng đáp ứng yêu cầu của đội nghiệp vụ, từ đó đưa ra giải pháp phù hợp (Có vài vị trí như mình, mỗi người sẽ cover một vài mảng nghiệp vụ tương ứng với datamart nhất định). Phạm vi cần cover bao gồm từ khi dữ liệu thô được lấy và lưu trữ rồi, đến khi dữ liệu được sẵn sàng khai thác trên data mart. Để các bác hiểu rõ mình sẽ mô tả cụ thể từng bước công việc. Đầu tiên khi End-User cần khai thác một dữ liệu gì đó mà họ chưa tiếp cận được, sẽ có một đội nghiệp vụ (thuộc team data, không phải là mình) đánh giá yêu cầu đó và ghi nhận lại, sau đó giải thích lại yêu cầu cho mình để tìm phương án đưa các dữ liệu cần thiết này lên datamart, và mình sẽ là người tìm giải pháp đưa nó lên như thế nào. Nghe thì có vẻ đơn giản nhưng với các hệ thống lớn và khối lượng dữ liệu lớn, có nhiều policy phải tuân thủ, thì lại cần các role kiểu như thế này. Mình cần phải nắm sâu nghiệp vụ để biết các dữ liệu cần thiết này quan hệ và tương tác với nhau như thế nào, sau đó đưa ra cách tổ chức dữ liệu phù trên datamart, bao gồm mô hình lưu trữ, mô hình load dữ liệu, chỉ dẫn về tối ưu performance như indexing, partitioning,... Giải pháp mình đưa ra lại qua vòng review của SA cao hơn và cả đội Data governance nữa. Sau khi được approve giải pháp sẽ chuyển qua cho đội DE thực hiện. Role này xoáy sâu về kiến thức xây dựng DWH và tổ chức cơ sở dữ liệu, nhưng vẫn cần hiểu về nghiệp vụ.

3. Job phụ 2 làm Leader cho một dữ án triển khai hệ thống data platform cho một đơn vị trong nước. Tương tự như Job phụ 1, nhưng phạm vi rộng hơn, bao gồm cả đánh giá toàn bộ các nguồn dữ liệu đầu vào, cover cả việc trực tiếp lấy yêu cầu nghiệp vụ với End User. Tất nhiên với role như vậy thì mình sẽ không làm chi tiết, mà chủ yếu review giải pháp của các bạn bên dưới, nếu phát sinh những case khó mình mới nhảy vào.

Về cơ bản thì 3 Job này giúp mình giữ và cập nhật liên tục các kiến thức mới theo kiểu full stack, full cycle của data.
 
Last edited:
Xin địa chỉ chỗ học DA uy tín, chất lượng các bác? Ko cần cam kết việc làm đâu vì e thấy nó bịp thế nào ấy, e cũng đang muốn chuyển ngành
 
Xin địa chỉ chỗ học DA uy tín, chất lượng các bác? Ko cần cam kết việc làm đâu vì e thấy nó bịp thế nào ấy, e cũng đang muốn chuyển ngành
Học mấy khóa online của nước ngoài rồi vừa làm vừa áp dụng tìm hiểu thôi bác.
 
Mấy hôm nghỉ lễ tranh thủ đi mổ cái xoang mà cũng không yên. Bên Mỹ không nghỉ lễ như bên này, rồi tháng vừa rồi cũng đạt kỷ lục doanh số, cả công ty nhìn vào cái báo cáo mà đúng lúc nó chập cheng, phát sinh issue. Vậy là Work from hospital cmnl.
 
Last edited:
Học mấy khóa online của nước ngoài rồi vừa làm vừa áp dụng tìm hiểu thôi bác.
hi bác, em cũng đang định hướng vừa làm vừa học qua mảng này, em thì chủ yếu bên tài chính (TCDN, tín dụng ngân hàng, kinh nghiệm thì >5 năm) hiện giờ cũng muốn tìm job DA để học hỏi cho nhanh thì có thể tìm những vị trí như nào để dần nắm full cycle, và nên dành bn năm cho việc này ạ :big_smile: mục tiêu để thay đổi bản thân (job e làm thì truyền thống của bank quá rồi) + theo làn sóng fintech chứ vài năm nữa cỡ như apple nó vào ngành ngân hàng ở vn thì tài chính tiêu dùng ở vn nó đập chết hết :haha:
 
Back
Top