Hình minh họa quản trị sự thay đổi: chiếc ghế ba chân con người, quy trình, công nghệ đỡ một chiếc laptop, thước thủy trên mặt ghế cho thấy ghế đang cân bằng

Quản trị sự thay đổi: People, Process and Technology

Theo Hiệp hội Chuyên gia Quản trị Thay đổi (ACMP), quản trị sự thay đổi là việc áp dụng kiến thức, kỹ năng, năng lực, phương pháp, quy trình, công cụ và kỹ thuật để đưa một cá nhân hoặc một nhóm từ trạng thái hiện tại sang trạng thái mong muốn, sao cho đạt được kết quả và mục tiêu kinh doanh mong muốn. Với một công ty, ví dụ dễ thấy nhất là lúc mua phần mềm mới: trạng thái hiện tại là cách làm việc hôm nay, trạng thái mong muốn là cách làm việc sau khi phần mềm đi vào hoạt động.

Có hai câu hỏi mà chủ doanh nghiệp nào cũng gặp khi đưa phần mềm hay chuyển đổi số vào công ty. Câu thứ nhất: để thành công, cần quan tâm đến những yếu tố nào, và làm sao để bao quát đủ các yếu tố đó. Câu thứ hai: khi đang triển khai hoặc đã dùng phần mềm mà kết quả không như kỳ vọng, nên xem lại ở đâu. Mô hình People, Process and Technology (PPT) giúp trả lời cả hai. Nó chia một thay đổi thành ba phần phải xét cùng lúc là con người, quy trình và công nghệ, rồi dùng ba phần đó làm danh sách cần rà soát trước khi triển khai, và làm danh sách các điểm cần kiểm tra khi kết quả chưa như kỳ vọng.

Tam giác PPT gồm những gì

PPT là cách nhìn một thay đổi qua ba yếu tố phải xét cùng lúc: con người, quy trình, công nghệ. People là những người trong tổ chức, từ lãnh đạo ra quyết định đến nhân viên làm việc hằng ngày, cùng kỹ năng, thái độ và động lực của họ. Process là luồng công việc, thủ tục và thói quen dẫn dắt cách người ta làm việc. Technology là công cụ, hệ thống và phần mềm họ sử dụng. Cách chia này theo trang giải thích khung PPT của Prosci, một tổ chức chuyên về quản trị thay đổi. Lấy việc mua phần mềm mới làm ví dụ: phần mềm là công nghệ, nhưng nó kéo theo cách làm việc mới, tức quy trình, và những người phải học dùng nó, tức con người.

Theo Prosci, mô hình này dựa trên mô hình kim cương của Harold Leavitt, đưa ra năm 1965. Leavitt xem một tổ chức gồm bốn yếu tố gắn chặt với nhau: công việc, con người, cấu trúc, công nghệ. Ý tưởng của ông đến từ lý thuyết xã hội–kỹ thuật, ra đời từ các mỏ than nước Anh vào khoảng Thế chiến thứ hai và những năm 1950. Ở đó, một nhóm thuộc Viện Tavistock gồm Eric Trist, Ken Bamforth và Fred Emery làm việc với thợ mỏ. Năm 1951, Trist và Bamforth đăng một bài có tên nói rõ nội dung: một vài hậu quả xã hội và tâm lý của phương pháp khai thác than longwall. Thời đó, người ta tin công nghệ quyết định tất cả và con người chỉ là phần nối dài của máy móc. Nhóm Tavistock đi theo hướng ngược lại: phần xã hội và phần kỹ thuật cần được thiết kế song song để vận hành trơn tru cùng nhau, và họ gọi đó là tối ưu chung.

Sơ đồ mô hình kim cương Leavitt với bốn yếu tố công việc, con người, cấu trúc, công nghệ, và tam giác People, Process, Technology trong quản trị sự thay đổi
Từ bốn yếu tố của Leavitt xuống ba yếu tố PPT: Công việc và Cấu trúc được gộp thành Process.

Từ bốn yếu tố xuống ba chỉ cần một bước: cấu trúc và công việc được gộp thành Process. Hai yếu tố bị gộp này vốn có nội dung riêng. Công việc là việc gì được làm và làm như thế nào, gồm cả quyền quyết định gắn với việc đó. Cấu trúc là ai báo cáo cho ai, phạm vi quản lý, và cơ chế phối hợp như lịch họp, diễn đàn, chính sách. Trong khi đó, định nghĩa của Process chỉ nhắc luồng việc, thủ tục, thói quen, còn People chỉ nhắc lãnh đạo ra quyết định, không nói quyền quyết định giữa các phòng ban nằm ở đâu.

Vì vậy, khi dùng tam giác này để kiểm tra một dự án, nên tách Process thành hai nhóm: luồng việc và thủ tục, và quyền quyết định cùng cách phối hợp giữa các phòng ban. Làm vậy thì ba yếu tố PPT mới bao được hết bốn yếu tố của Leavitt.

Vì sao con người, quy trình và công nghệ phải đi cùng nhau

Khi một yếu tố thay đổi, hiệu ứng lan sang các yếu tố còn lại. Một ví dụ dễ hình dung là IBM Credit, công ty con của IBM chuyên cho khách hàng vay tiền để mua máy tính, phần mềm và dịch vụ của IBM, được Michael Hammer và James Champy kể trong cuốn Reengineering the Corporation năm 1993.

Ở IBM Credit, một yêu cầu vay đi qua năm bước, mỗi bước một phòng. Nhân viên trực ghi yêu cầu của người bán hàng vào một tờ phiếu. Phòng tín dụng xét khách có đủ điều kiện vay không. Phòng nghiệp vụ duyệt những điều khoản khách muốn đổi so với hợp đồng chuẩn. Phòng định giá tính lãi suất. Phòng hành chính soạn thư báo giá để gửi cho người bán hàng. Cả quy trình mất trung bình sáu ngày, có khi tới hai tuần, và theo Hammer và Champy, sáu ngày đó đủ để khách hàng đi tìm một nguồn vay khác.

Hai quản lý cấp cao quyết định tự cầm một yêu cầu đi qua từng phòng. Tổng thời gian làm việc thật chỉ khoảng 90 phút, phần còn lại là thời gian tờ phiếu nằm chờ hoặc đang được chuyển từ bàn này sang bàn khác. Theo Hammer và Champy, kể cả khi mỗi người làm nhanh gấp đôi thì tổng thời gian cũng chỉ giảm được khoảng 45 phút, vì vấn đề nằm ở cách công việc bị chia nhỏ chứ không nằm ở tốc độ của từng người.

Khi xem kỹ từng khâu, họ còn phát hiện thêm một vấn đề. Cả quy trình được dựng trên giả định rằng yêu cầu vay nào cũng riêng biệt và khó, nên cần bốn chuyên viên được đào tạo bài bản. Thực tế phần lớn yêu cầu đơn giản, và việc của các chuyên viên phần lớn chỉ là việc giấy tờ: tra điểm tín dụng trong cơ sở dữ liệu, nhập số vào một mô hình tính có sẵn, lấy điều khoản mẫu từ hồ sơ lưu.

Giải pháp là bỏ việc chuyền tay. Thay cho bốn chuyên viên mỗi người một khâu, một người gọi là deal structurer nhận yêu cầu và xử lý từ đầu đến cuối. IBM Credit xây cho người này một hệ thống máy tính mới, dễ dùng, mở được toàn bộ dữ liệu và công cụ mà các chuyên viên trước đây dùng. Nhờ đó, một người tự làm được cả bốn việc trước kia chia cho bốn phòng: tra điểm tín dụng của khách, xét các điều khoản khách muốn đổi, tính lãi suất bằng mô hình chuẩn, rồi soạn thư báo giá từ điều khoản mẫu. Trong phần lớn trường hợp, hệ thống đưa ra đủ hướng dẫn để người này tự làm tiếp. Với những ca thật sự khó, họ gọi thêm người từ một nhóm nhỏ chuyên viên thật sự về tín dụng hay định giá, và hai bên ngồi làm cùng nhau như một đội, nên vẫn không phát sinh việc chuyền tay. Kết quả là thời gian xử lý giảm từ bảy ngày xuống bốn giờ, số hồ sơ xử lý được tăng gấp trăm lần, còn số nhân viên giảm nhẹ.

Xét theo mô hình PPT, IBM Credit không chỉ đổi phần mềm mà thay đổi cả ba yếu tố cùng một lúc. Về Process, năm lần chuyền tay thành một người làm trọn từ đầu đến cuối. Về Technology, hệ thống máy tính mới giúp một người không chuyên sâu vẫn xử lý được phần lớn hồ sơ. Về People, vai trò của nhân viên đổi từ người chỉ làm một khâu sang người chịu trách nhiệm cả hồ sơ, còn chuyên viên giỏi được dành cho ca khó. Nếu chỉ mua phần mềm để từng phòng làm nhanh hơn mà vẫn giữ năm lần chuyền tay, phép tính 45 phút ở trên cho thấy kết quả gần như không đổi.

Từ ví dụ này rút ra ba điều. Thứ nhất, các yếu tố phải khớp với nhau thì thay đổi mới bền, còn sửa lẻ từng mảng thì không. Bản mô tả mô hình có một câu đáng nhớ: công cụ mới đừng để vai trò cũ kéo xuống, và sơ đồ tổ chức mới đừng để quy trình cũ phá ngầm. IBM Credit cũng cho thấy tăng tốc từng phòng là vô ích khi công việc vẫn phải chuyền qua năm phòng.

Thứ hai, công nghệ nên mở ra cách làm mới, không phải để làm nhanh cách cũ. Trong một bài trên Harvard Business Review năm 1990, Hammer viết: ngừng lát nhựa lên lối bò đi. Lối bò đi cong vì nó sinh ra cho con bò, lát nhựa lên đó thì được một con đường nhựa cũng cong y như vậy. Quy trình cũ nhiều khi nằm trong những luật chưa ai nói ra, chẳng hạn quyết định tín dụng thì do phòng tín dụng quyết, biểu mẫu thì phải điền đủ và đúng thứ tự. Nếu đưa toàn bộ những luật đó vào phần mềm, kết quả chỉ là một hệ thống chạy cách làm cũ nhanh hơn. Trường hợp Lidl cho thấy cái giá của lựa chọn này: công ty sửa SAP cho khớp với quy trình cũ, rồi dừng dự án sau khoản chi ước tính khoảng 500 triệu euro.

Thứ ba, người và công nghệ phải được thiết kế cùng nhau. Đây là nguyên lý của lý thuyết xã hội–kỹ thuật ở mỏ than: mỗi bên vừa theo mục tiêu riêng vừa phụ thuộc vào bên kia. Khi người và công nghệ không khớp nhau, không thể chỉ đòi con người thích nghi với máy móc.

Trước khi triển khai: cần quan tâm những gì

Đây là danh sách để chủ doanh nghiệp tự hỏi trước khi ký hợp đồng chuyển đổi số hay bắt đầu dự án. Nếu công ty chưa xác định nên chuyển đổi số ở mảng nào trước, bài chiến lược chuyển đổi số doanh nghiệp có khung để chọn hướng ưu tiên, sau đó mới dùng đến bộ câu hỏi bên dưới. Các câu hỏi dưới đây do mình tự đề ra, dựa trên định nghĩa của ba yếu tố PPT và các ví dụ ở trên, chưa phải một bộ câu hỏi chuẩn của nguồn nào.

Technology

  • Cho vài nhân viên dùng thử với một công việc thật của công ty, phần mềm có xử lý được từ bước đầu đến bước cuối không?
  • Nó giúp làm cách mới hay chỉ làm cách cũ nhanh hơn?
  • Báo giá dự án chuyển đổi số nói gì ngoài tính năng, giá và hạn nghiệm thu? Phần dựng lại quy trình và đào tạo người dùng có được tính không?

Process, nhóm luồng việc và thủ tục

  • Cách làm việc mà phần mềm giả định có thật sự tồn tại trong công ty không, hay mỗi phòng một kiểu?
  • Những luật chưa ai nói ra đã được viết ra và xem xét chưa?
  • Quy trình cần sửa trước khi viết dòng code nào, và công ty đã dành thời gian cho việc đó chưa?

Process, nhóm quyền quyết định và phối hợp

  • Khi hai phòng bất đồng về biểu mẫu hay cách làm, ai là người chốt?
  • Dự án có lãnh đạo trực tiếp chỉ đạo không, hay đang dựa vào các trưởng phòng tự thỏa thuận với nhau?
  • Sau khi có phần mềm, ai báo cáo cho ai và các phòng phối hợp với nhau thế nào?

People

  • Ai sẽ dùng phần mềm mỗi ngày, và công việc của họ thay đổi ra sao?
  • Họ có được hỏi ý khi chọn phần mềm không?
  • Ai chịu trách nhiệm khi thông tin nhập vào sai?

Một điểm cần lưu ý: nhóm câu hỏi về quyền quyết định thường bị bỏ trống nhất, vì nó không nằm trong bản báo giá của nhà cung cấp và cũng không thuộc phần việc của bất kỳ phòng nào.

Khi kết quả chưa như kỳ vọng: nên xem ở đâu

Sơ đồ ba bước tìm nguyên nhân khi phần mềm chưa như kỳ vọng: kiểm tra Technology, rồi Process, rồi People
Ba bước tìm nguyên nhân khi phần mềm chưa như kỳ vọng, đi từ Technology sang Process rồi People.

Giả sử công ty đang triển khai, hoặc đã dùng phần mềm một thời gian, mà nhân viên vẫn không chịu dùng, hoặc kết quả chưa như mong muốn. Bộ câu hỏi ở trên vẫn dùng được, nhưng nên đi lần lượt từng yếu tố, bắt đầu từ yếu tố dễ kiểm tra nhất.

Bước đầu, về Technology: phần mềm có làm đúng việc người ta cần không? Hãy nhờ vài nhân viên dùng phần mềm để làm trọn một công việc thật, từ bước đầu đến bước cuối, rồi quan sát họ gặp khó ở bước nào. Nếu khó khăn đến từ việc phần mềm thiếu chức năng cần thiết thì nguyên nhân nằm ở Technology, và cách xử lý là sửa hoặc thay phần mềm.

Bước thứ hai, về Process: cách làm việc mà phần mềm đang giả định có thật sự tồn tại trong công ty không? Đây là bước hay bị bỏ sót nhất, và cũng là chỗ dự án của mình từng gặp khó. Mình từng làm dự án chuyển đổi số cho một doanh nghiệp đào tạo và đưa lao động sang Nhật: 20 năm tuổi, thuộc nhóm đầu thị trường, có chi nhánh ở cả 3 miền lẫn bên Nhật. Trước khi khảo sát, mình nghĩ khá đơn giản: doanh nghiệp cỡ đó hẳn đã có quy trình gọn, việc của mình là dựng phần mềm lên trên. Khi đi khảo sát, mình thấy gần như mọi thứ vận hành bằng Excel, cùng một đơn hàng bị nhập lại ở nhiều nơi, và riêng nhân lực, đào tạo, hành chính đều tự dựng bộ dữ liệu riêng. Dự án phải dừng hơn 1 năm để xây lại một quy trình chung giữa các phòng ban, trước khi viết dòng code nào.

Tưởng như vậy là xong, nhưng sang giai đoạn làm phần mềm, biểu mẫu cho cùng một đối tượng vẫn khác nhau giữa các phòng, và không phòng nào chịu nhường phòng nào. Hai phòng bất đồng thì ai quyết định? Ba yếu tố PPT không tự trả lời câu này, nên mới cần tách riêng nhóm câu hỏi về quyền quyết định.

Bước cuối, về People: những người dùng phần mềm mỗi ngày có được lắng nghe không? IBM Credit cho thấy người dùng không phải yếu tố để tính sau, vì vai trò của nhân viên đổi từ làm một khâu sang chịu trách nhiệm cả hồ sơ. Ngược lại, nếu gốc vấn đề nằm ở Process thì đào tạo thêm cũng không giải quyết được.

Lấy một ví dụ giả định, không phải chuyện của công ty nào. Công ty đã có phần mềm kế toán, nhưng cuối tháng vẫn có người dựng lại bảng đối chiếu bằng Excel. Phần mềm có xuất được báo cáo người đó cần không? Quy tắc đối chiếu, tức ai kiểm, kiểm gì, theo mẫu nào, nằm trong phần mềm hay chỉ nằm trong đầu người làm lâu năm? Người dựng bảng có được hỏi ý lúc chọn phần mềm không? Ba câu trả lời khác nhau dẫn tới ba cách sửa khác nhau, và chỉ một trong số đó là đổi phần mềm. Nguyên nhân cũng có thể không chỉ có một: có thể là hai, có thể là cả ba. Các câu hỏi chỉ thu hẹp phạm vi cần xem xét, còn việc đến tận nơi quan sát vẫn là việc của bạn.

Áp dụng mô hình PPT trong doanh nghiệp

Trước khi chọn phần mềm, nên mô tả rõ công việc cần thay đổi: hiện nay việc đó được làm thế nào, mất bao lâu, qua tay những ai, và sau khi thay đổi cần được làm ra sao. IBM Credit chỉ tìm ra lời giải khi đi theo một hồ sơ thật qua từng phòng.

Khi đã rõ việc cần đổi, dùng bộ câu hỏi ở mục “Trước khi triển khai” để rà soát cả ba yếu tố PPT, và giao người chịu trách nhiệm cho từng phần: ai phụ trách quy trình, ai có quyền quyết định khi các phòng bất đồng, ai hỗ trợ người dùng hằng ngày. Thời gian và chi phí cho việc dựng lại quy trình và đào tạo cũng cần có trong kế hoạch ngay từ đầu, vì báo giá dự án chuyển đổi số thường không có các khoản này.

Trước khi triển khai cho toàn công ty, nên chạy thử với một nhóm nhỏ trên một công việc thật, rồi dùng ba bước ở mục “Khi kết quả chưa như kỳ vọng” để sửa những chỗ chưa khớp. Sau khi triển khai, chọn vài chỉ số gắn với mục tiêu ban đầu, như thời gian xử lý một hồ sơ, và định kỳ rà lại ba yếu tố PPT, vì như Prosci lưu ý, con người rất dễ quay về thói quen cũ.

Câu hỏi thường gặp

Trước khi triển khai chuyển đổi số, chủ doanh nghiệp cần quan tâm những gì?

Cả ba yếu tố cùng lúc: công nghệ, quy trình (gồm cả quyền quyết định và cách phối hợp giữa các phòng), và con người sẽ dùng phần mềm. Bài có một bộ câu hỏi cho từng nhóm, do tác giả tự đề ra từ định nghĩa của mô hình.

Dự án chuyển đổi số đang triển khai hoặc đã xong mà không như kỳ vọng thì nên xem ở đâu?

Đi theo thứ tự: thử một việc thật trên phần mềm (Technology), kiểm tra cách làm việc phần mềm giả định có tồn tại trong công ty không (Process), rồi hỏi người dùng hằng ngày (People). Nguyên nhân có thể nằm ở nhiều yếu tố cùng lúc.

Mô hình People, Process and Technology (PPT) là gì?

Là cách nhìn một thay đổi về quy trình và công nghệ trong công ty qua ba yếu tố phải xét cùng lúc: con người, quy trình, công nghệ. Thay đổi một yếu tố sẽ kéo theo thay đổi ở hai yếu tố còn lại. Theo Prosci, nó dựa trên mô hình kim cương của Harold Leavitt từ thập niên 1960.

PPT khác gì mô hình kim cương của Leavitt?

Leavitt (1965) có bốn yếu tố: công việc, con người, cấu trúc, công nghệ. Về sau cấu trúc và công việc bị gộp thành quy trình. Điểm cần lưu ý là cấu trúc, tức hệ thống báo cáo, quyền quyết định và cách phối hợp, không còn được gọi tên riêng trong mô hình PPT.

Có phải làm theo thứ tự People rồi Process rồi Technology không?

Không. Ba yếu tố PPT là cách điều chỉnh để ba yếu tố khớp với nhau, không phải ba bước làm lần lượt, và mô hình gốc cũng không đòi thứ tự cố định. Dự án của mình làm xong quy trình trước khi có dòng code nào, nhưng đó là cách sắp xếp riêng của dự án đó.

Hai lúc cần nhớ đến ba yếu tố PPT

Khi phần mềm không mang lại kết quả, thường mỗi bên đều đã làm đúng phần của mình: nhà cung cấp làm đúng phần của họ, nhân viên làm theo cách họ quen, còn người chi tiền nhận về một kết quả không ai giải thích được. Ba yếu tố PPT cho bạn ba điểm để kiểm tra, một lần trước khi ký hợp đồng chuyển đổi số và một lần khi kết quả chưa như kỳ vọng. Trong dự án của mình, yếu tố từng bị xem nhẹ nhất là Process.

Cảm ơn bạn đã đọc đến đây. Với dự án gần nhất của công ty bạn, khi công nghệ không mang lại kết quả như kỳ vọng, nguyên nhân theo bạn nằm ở yếu tố nào? Mình rất muốn đọc ý kiến của bạn ở phần bình luận.

Nguồn tham khảo


Ảnh đại diện Hưng Lưu

Experience Designer with 10+ years of expertise. Writing on experience design, digital transformation, and how technology truly shapes people and businesses.

Related

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *