Chuyển đổi Agile – một xu hướng chuyển đổi tổ chức mà ngân hàng không phải lĩnh vực ngoại lệ, theo hướng linh hoạt nhằm nhanh chóng xây dựng và phát triển các ý tưởng mới. Tuy nhiên, mặc dù đã được đầu tư, nhưng việc chuyển đổi Agile trong ngành ngân hàng tại Việt Nam chưa đem lại kết quả như kỳ vọng.
Để hiểu về chuyển đổi Agile, trước hết chúng ta cần biết đến Agile là gì. Trong một chia sẻ gần đây của Dr. Alistair Cockburn, một trong 17 người đồng xuất bản tuyên ngôn Agile (Agile Manifesto) (1), rằng khi chỉ có 10 giây để giải thích về Agile, ông đã nói 2 điểm (2):
- Giá trị kinh doanh được bàn giao sớm. (“Early delivery of business value.”)
- Sự quan liêu được giảm thiểu. (“Reduced bureaucracy.”)
Đó là những lợi ích mà mọi doanh nghiệp đều mong muốn.
Hiểu biết chung về chuyển đổi Agile
Gần hai mươi năm trôi qua từ thời điểm Agile Manifesto được xuất bản, Agile đã vượt ra khỏi khuôn khổ của các công ty phần mềm và trở thành mong muốn chuyển đổi (transformation) của nhiều ngành nghề khác nhau, đặc biệt là ngân hàng. Theo như khảo sát của chúng tôi, cả 8 ngân hàng thương mại cổ phần có lợi nhuận trước thuế năm 2019 cao nhất Việt Nam (không tính nhóm Big4) (3) đã và đang tuyển dụng các vị trí nhân sự liên quan đến việc chuyển đổi Agile trong năm 2020.
Chuyển đổi Agile (Agile transformation) trở thành một làn sóng không thể tránh khỏi tại Việt Nam và cũng đã đem lại những kết quả nhất định như sự nhanh nhạy triển khai eKYC, VTM (Video Teller Machine) hay gần đây là một ngân hàng triển khai đánh giá tín dụng dựa trên dữ liệu lớn. Tuy nhiên, vẫn còn nhiều vấn đề về sự “chậm trễ” của đa số ngân hàng khiến trải nghiệm khách hàng trên các kênh số không khác nhiều so với 05 năm trước, với các sản phẩm cơ bản và trải nghiệm được thiết kế từ “đời đầu”. Sự khác biệt, không đồng nhất về trải nghiệm trên các kênh cũng là kết quả của việc chậm thay đổi. Đặc biệt là trải nghiệm khách hàng tại quầy, chi nhánh có lẽ không khác gì so với cả 10 năm trước.
Những lý do dẫn đến chuyển đổi Agile chưa thành công
Qua phân tích của chúng tôi, việc chưa thành công này có thể do một hoặc tất cả các câu chuyện sau:
- Chưa có sự cấp thiết của việc chuyển đổi
- Không phù hợp văn hóa và hiểu nhầm về Spotify engineering culture
- Thiếu sự hiểu biết sâu sắc khi áp dụng Agile
1. Chưa có sự cấp thiết của việc chuyển đổi
Giai đoạn 2016-2019, đi cùng sự phát triển kinh tế của đất nước với tăng trưởng GDP ổn định ở mức xấp xỉ 7%, ngành ngân hàng đã có một giai đoạn rực rỡ, các ngân hàng top đầu đã có mức tăng tưởng LNTT lên đến 3 lần chỉ sau 3 năm. Sự phát triển này khiến cho các ngân hàng bắt tay vào chuyển đổi Agile giống như một người đi mua sắm hơn là để chiến đấu cho sự sống còn.
Các đội dự án, phòng ban áp dụng Agile mới thành lập chưa thể đem lại những kết quả to lớn, trong khi đó, các phòng ban kinh doanh với cách làm việc truyền thống vẫn đem lại kết quả lợi nhuận vượt trội. Cách giao và đánh giá chỉ tiêu truyền thống trong ngành ngân hàng thường gắn liền với doanh thu, lợi nhuận cũng góp phần tạo nên sức ép cho các đội nhóm Agile non trẻ.
Thành công của DBS, ING, CommBank luôn là những câu chuyện đầy cảm hứng, tuy nhiên, trong bối cảnh mà cách làm việc truyền thống vẫn đem lại kết quả vượt kế hoạch, chuyển đổi Agile chưa thể nhận được sự ưu tiên để đem lại các kết quả như kỳ vọng. Dự đoán sau năm 2020, với sự ảnh hưởng nặng nề của Covid đến nền kinh tế nói chung, ngành ngân hàng sẽ có động lực lớn hơn cho việc chuyển đổi này.
2. Không phù hợp văn hóa và hiểu nhầm về Spotify engineering culture
Hiện trạng văn hóa nội bộ ngân hàng
Có một sự thật là các lỗi xảy ra trong ngân hàng đều phải trả giá bằng tiền mặt, rất nhiều tiền. Nên từ khi thành lập, quy trình nội bộ trong ngân hàng đã được thiết lập để tạo ra nhiều lớp kiểm soát và hạn chế rủi ro vận hành đến mức tối đa. Bên cạnh đó, tổ chức phân cấp nhiều tầng với phong cách lãnh đạo mang tính chỉ huy cũng là sự đối nghịch lại với cách làm việc Agile. Ở vị trí một lãnh đạo cấp trung trong ngân hàng, người lãnh đạo nhận chỉ tiêu và dễ dàng phải nhận phạt nếu có sai phạm xảy ra, thật khó khăn để trao quyền một đội nhóm Agile mới thành lập. Khi không có sự tin tưởng, sẽ không có người lãnh đạo phục vụ (servant leader) và đội nhóm tự quản (self-organizing team).
Văn hóa “Spotify Engineering Culture”
Song hành với đó là phong trào áp dụng Spotify Engineering Culture (4) như một mô hình tổ chức (model) với squad, tribe, chapter và guild mặc dù chính tác giả Henrik Kniberg đã gọi đó là “văn hóa” chứ không phải “mô hình tổ chức” (5). Sự nhầm lẫn lớn này dẫn đến kết quả các phòng ban chuyên môn đóng góp nhân sự vào các đội nhóm dự án với 30% – 50% thời gian làm việc và tạo thành mô hình ma trận như thường thấy. Tình huống xấu hơn nữa đó là các quản lý chuyên môn (functional managers) vẫn đóng vai trò là người giao việc và nhận báo cáo từ nhân sự trong đội nhóm Agile. Điều này trái ngược hoàn toàn với mô tả về Chapter lead, người lẽ ra cần tập trung vào tạo điều kiện và hỗ trợ chuyên môn.
Ken Beck, cũng nằm trong nhóm 17 người xuất bản Agile manifesto, đã chia sẻ rằng: “Spotify didn’t implement the Spotify model by copying Spotify. Why do folks at other companies think they can implement the Spotify model by copying Spotify?” (6). Điều này cho thấy sự nhầm lẫn đã xảy ra rộng khắp cả trên thế giới, và cũng dễ hiểu nếu như có sự nhầm lẫn trong cách triển khai tại Việt Nam.
3. Thiếu sự hiểu biết sâu sắc khi áp dụng Agile
Thiếu vắng sự cấp thiết và khác biệt về văn hóa góp phần khiến cho tổ chức không thể “being agile”, không dừng ở đó, việc “doing agile” ở mức công việc hàng ngày cũng chưa đạt như kỳ vọng. Ví dụ điển hình đó là việc ưu tiên cao nhất cho tài liệu với mục đích lưu trữ và phân tách trách nhiệm khi có lỗi cao hơn cả sản phẩm phần mềm đã đi ngược lại với Agile Manifesto. Kết quả là coi tài liệu như một giá trị cần bàn giao và sinh ra những sprint chỉ để làm tài liệu. Thay vì cách quản lý kiểu thác nước (waterfall) với giai đoạn yêu cầu, thiết kế, phát triển, các đội nhóm Agile sẽ có Sprint #1 làm tài liệu yêu cầu, Sprint #2 làm tài liệu thiết kế và các Sprints sau đó để phát triển.
Một yếu tố khách quan nữa cũng cần được nhắc đến đó là yếu tố nhân sự. Đa phần nhân sự được tuyển dụng để chuyển đổi Agile đến từ ngành phần mềm, nơi có môi trường làm việc phóng khoáng hơn và ít tiếp xúc với các quy trình nghiệp vụ phức tạp của ngân hàng. Điều này dẫn đến các đề xuất thay đổi của đội nhóm Agile thường vấp phải rất nhiều điều bị cho là “không thể”, “bất khả thi” vì quy trình ngân hàng 10-20 năm đã như thế. Thậm chí qua thời gian, chính đội nhóm Agile cũng thích nghi và chuyển sang cách làm việc truyền thống của ngân hàng cùng sự quy chụp rằng đội nhóm Agile sẽ luôn phải thích nghi với mọi môi trường.
Hướng tới tương lai
Bên cạnh những câu chuyện nổi bật được liệt kê trong bài, chúng ta có thể gặp ở đâu đó những câu chuyện khác như không có sự đầu tư nguồn lực, chưa tạo được lộ trình chuyển đổi hoặc sự thiếu hụt nhân sự khiến cho một người đóng nhiều vai trò như Product Owner và Scrum Master cùng lúc. Tuy nhiên, đó không phải là dấu chấm hết cho những nỗ lực chuyển đổi Agile vì như John P. Kotter từng viết cách đây 25 năm rằng ngay cả những tổ chức chuyển đổi thành công cũng đã mất rất nhiều công sức vượt qua sự hỗn độn và đầy bất ngờ (7).
Ở FPT Digital, với phương pháp luận FPT Digital KaizenTM, chúng tôi tin tưởng rằng việc chuyển đổi cách làm việc cần song hành với việc thay đổi văn hóa (culture) và căn chỉnh (alignment) ở tất cả các cấp. Nếu như không có chung niềm tin về giá trị và cách ứng xử một cách xuyên suốt, lãnh đạo cao cấp chưa thể thấy sự cấp thiết, lãnh đạo cấp trung sẽ không trao quyền cho cấp dưới và nhân viên có thể mất định hướng như Peter Drucker đã từng nói: “Culture eats strategy for breakfast.”
Nguồn tham khảo
(1) Agile Manifesto. n.d. Manifesto for Agile Software Development.
(2) Linkedin. 2020. Alistair Cockburn.
(3) Vietnambiz. 2020. 10 ngân hàng sở hữu hơn 80% lợi nhuận năm 2019.
(4) Engineering Spotify R&D. 2014. Spotify engineering culture (part 1) & Spotify engineering culture (part 2).
(5) Crisp’s Blog. 2015. No, I didn’t invent the Spotify model.
(6) Tweet. 2018. Kent Beck.
(7) Harvard Business Review. 1995. Leading Change: Why Transformation Efforts Fail.
