Spreadsheet Best Practices: Stop Making These Mistakes — csv-x.com

Tôi vẫn nhớ ngày mà tôi chứng kiến $2,3 triệu bốc hơi chỉ vì ai đó đã gõ một dấu phẩy thay vì dấu chấm trong một ô bảng tính. Tôi đã làm việc được ba năm trong vai trò phân tích tài chính tại một công ty đầu tư vừa và nhỏ, và nhóm của chúng tôi vừa gửi đi cái mà chúng tôi nghĩ là một đề xuất thâu tóm không thể bị đánh bại. Lỗi thập phân trong các dự báo dòng tiền của chúng tôi không chỉ làm chúng tôi mất hợp đồng — nó còn khiến chúng tôi mất uy tín với khách hàng và suýt khiến ba người mất việc.

Đó là năm 2009. Kể từ đó, tôi đã trải qua mười lăm năm trong vai trò tư vấn hoạt động dữ liệu, làm việc với tất cả các loại từ các công ty Fortune 500 đến các startup nhỏ, và tôi đã chứng kiến hầu như mọi thảm họa bảng tính mà bạn có thể tưởng tượng. Tôi đã chứng kiến những sai sót trong kiểm kê dẫn đến $800,000 hàng tồn kho dư thừa, lỗi trả lương dẫn đến thanh tra của IRS, và ngân sách tiếp thị bị sai một cách nghiêm trọng. Điểm chung? Những sai sót có thể phòng ngừa bắt nguồn từ việc đối xử với bảng tính như những tờ giấy nháp bình thường thay vì những công cụ kinh doanh quan trọng mà chúng thực sự là.

Dưới đây là điều mà hầu hết mọi người không nhận ra: theo một nghiên cứu của Raymond Panko tại Đại học Hawaii, 88% tất cả các bảng tính đều chứa lỗi. Không phải là lỗi đánh máy trong nhãn hoặc các vấn đề định dạng nhỏ — mà là những lỗi tính toán thực tế ảnh hưởng đến các quyết định kinh doanh. Khi các nhà nghiên cứu kinh tế châu Âu xem xét các bảng tính hoạt động từ các công ty thực tế, họ phát hiện ra tỷ lệ lỗi dao động từ 0,8% đến 1,8% cho mỗi công thức trong ô. Điều này có vẻ nhỏ cho đến khi bạn nhận ra rằng một mô hình tài chính điển hình chứa từ 500 đến 1.000 công thức. Hãy làm phép tính: bạn đang nhìn vào 4-18 lỗi trên mỗi bảng tính trung bình.

Tôi không ở đây để làm bạn sợ bảng tính. Chúng rất mạnh mẽ, linh hoạt, và khi được sử dụng đúng cách, hoàn toàn không thể thiếu. Nhưng sau khi tư vấn cho hơn 200 tổ chức và tự mình kiểm toán hàng ngàn bảng tính, tôi đã xác định được các mô hình phân biệt giữa những người dùng bảng tính nghiệp dư và những người chuyên nghiệp xây dựng các hệ thống dữ liệu đáng tin cậy và có thể mở rộng. Hãy để tôi chia sẻ những gì tôi đã học được.

Vấn đề Cơ bản: Đối xử với Bảng tính như Tài liệu Thay vì Cơ sở dữ liệu

Sai lầm lớn nhất mà tôi thấy — và tôi có ý nói rằng điều này chiếm khoảng 40% những lỗi nghiêm trọng mà tôi gặp phải — là mọi người đối xử với bảng tính như tài liệu xử lý từ. Họ gộp ô lại vì lý do thẩm mỹ, chèn các dòng trống để tạo không gian trực quan, sử dụng màu sắc như cách chính để truyền đạt ý nghĩa, và phân tán dữ liệu liên quan trên nhiều tab mà không có cấu trúc nhất quán.

Hãy để tôi cho bạn một ví dụ thực tế. Năm ngoái, tôi đã làm việc với một công ty sản xuất theo dõi dữ liệu sản xuất trong cái mà họ gọi là “bảng tính chính.” Nó đã được bảo trì bởi cùng một quản lý hoạt động trong bảy năm, và khi bà nghỉ hưu, hỗn loạn đã xảy ra. Bảng tính có 23 tab, mỗi tab đại diện cho một dòng sản phẩm khác nhau. Nghe có vẻ được tổ chức, đúng không? Sai rồi. Mỗi tab có một cấu trúc hoàn toàn khác nhau. Một số liệt kê ngày tháng ở cột A, số khác ở cột C. Một số sử dụng “Mã sản phẩm” làm tiêu đề, số khác sử dụng “SKU” hoặc “Mã mặt hàng” hoặc chỉ là “ID.” Có các ô gộp ở khắp mọi nơi, tạo ra các tiêu đề trực quan trông đẹp mắt nhưng khiến cho việc sắp xếp hoặc lọc dữ liệu trở nên không thể.

Khi họ yêu cầu tôi giúp hợp nhất điều này thành một hệ thống có thể sử dụng, tôi phát hiện ra rằng những câu hỏi đơn giản như “Tổng khối lượng sản xuất của chúng ta trong Q3 2022 là gì?” cần phải kiểm tra thủ công 23 tab khác nhau, mỗi tab có các định dạng ngày và cấu trúc cột khác nhau. Một truy vấn mà đáng lẽ chỉ mất 30 giây lại tốn 45 phút làm việc thủ công. Và vì cấu trúc không nhất quán, không có cách nào để tự động hóa nó.

Cách sửa chữa đòi hỏi phải quay lại với những nguyên tắc cơ bản. Tôi đã yêu cầu họ xây dựng lại hệ thống theo dõi của mình với một bảng dữ liệu phẳng duy nhất. Mỗi hàng đại diện cho một sự kiện sản xuất. Mỗi cột đại diện cho một thuộc tính: Ngày, Mã_Sản phẩm, Số_lượng, Số_dây_chuyền, Ca, Đánh_giá_Chất lượng. Không có ô gộp. Không có hàng trống cho không gian. Không có mã màu như chỉ báo dữ liệu chính. Chỉ là dữ liệu sạch, có cấu trúc có thể được lọc, sắp xếp, chuyển đổi và phân tích.

Kết quả? Thời gian báo cáo hàng tháng của họ giảm từ 12 giờ xuống 45 phút. Họ có thể đột nhiên trả lời những câu hỏi mà họ chưa bao giờ có thể trả lời trước đó. Và khi cuối cùng họ chuyển sang một hệ thống cơ sở dữ liệu phù hợp hai năm sau đó, quá trình chuyển đổi diễn ra suôn sẻ vì dữ liệu của họ đã được cấu trúc đúng cách.

Dưới đây là nguyên tắc: nếu bạn đang sử dụng bảng tính để lưu trữ dữ liệu mà bạn sẽ cần phân tích, truy vấn hoặc báo cáo, hãy coi nó như một bảng cơ sở dữ liệu, không phải như một tài liệu. Một hàng cho mỗi bản ghi. Một cột cho mỗi thuộc tính. Tiêu đề nhất quán. Không có ô gộp trong phạm vi dữ liệu của bạn. Hãy để định dạng đẹp cho lớp trình bày của bạn — tạo các bảng tổng hợp hoặc báo cáo riêng biệt lấy dữ liệu từ các bảng dữ liệu sạch của bạn.

Mối nguy Ẩn giấu của Nhập liệu Thủ công và Các thao tác Sao chép-Dán

Tôi đã từng kiểm toán hệ thống lên lịch bệnh nhân của một tổ chức y tế và phát hiện rằng nhân viên của họ đang sao chép thủ công dữ liệu cuộc hẹn từ phần mềm đặt lịch của họ sang Excel, rồi sao chép nó một lần nữa vào hệ thống thanh toán của họ. Điều này xảy ra từ 40-60 lần mỗi ngày, năm ngày một tuần. Khi tôi tính toán tỷ lệ lỗi — chỉ bằng việc kiểm tra ngẫu nhiên 200 mục dữ liệu so với các hồ sơ nguồn — tôi phát hiện thấy 3,2% tỷ lệ lỗi. Đó là khoảng 6-10 lỗi mỗi ngày, hoặc 1.500-2.500 lỗi mỗi năm.

"Những lỗi bảng tính đắt nhất không phải là những lỗi khiến chúng bị hỏng — mà là những lỗi vận hành hoàn hảo với những con số sai bên trong."

Mỗi lỗi đều có hậu quả về sau. Thời gian hẹn không chính xác khiến bệnh nhân đến khi không có bác sĩ nào có mặt. Mã thanh toán sai dẫn đến từ chối bảo hiểm và chậm trễ trong việc thanh toán. Mã bệnh nhân sai gây ra vi phạm HIPAA và có thể gây ra trách nhiệm pháp lý. Tổ chức này đang tiêu tốn khoảng 15 giờ mỗi tuần chỉ để sửa lỗi phát sinh từ việc truyền dữ liệu thủ công.

Vấn đề cơ bản với việc nhập liệu thủ công không chỉ là con người mắc sai lầm — mặc dù chúng tôi chắc chắn mắc phải, với tỷ lệ có thể dự đoán. Vấn đề sâu hơn là rằng các quy trình thủ công không thể mở rộng, không thể kiểm toán hiệu quả và tạo ra các điểm thất bại đơn. Khi một người biết "quy trình" để cập nhật bảng tính, chuyện gì xảy ra khi họ bị ốm, đi nghỉ, hoặc rời khỏi công ty?

Tôi đã thấy mẫu này hàng trăm lần: ai đó xây dựng một hệ thống bảng tính hoạt động hoàn hảo khi họ là người duy nhất sử dụng nó. Họ biết tất cả các điểm đặc biệt, nhớ tất cả các trường hợp đặc biệt, và có thể làm việc xung quanh những hạn chế. Rồi công ty phát triển, nhiều người cần truy cập, và đột nhiên hệ thống mà một chuyên gia đã hoạt động lại trở thành mối nguy. Dữ liệu bị nhập không nhất quán. Mọi người ghi đè lên công việc của nhau. Không ai biết phiên bản nào là hiện tại.

Giải pháp không phải lúc nào cũng là loại bỏ hoàn toàn việc nhập liệu thủ công—đôi khi điều đó không thực tế. Nhưng bạn có thể giảm đáng kể lỗi bằng cách tuân theo những thực hành này. Đầu tiên, hãy sử dụng xác thực dữ liệu một cách triệt để. Nếu một cột chỉ nên chứa ngày tháng, hãy thiết lập xác thực để từ chối bất kỳ thứ gì khác. Nếu mã sản phẩm tuân theo một định dạng cụ thể, hãy tạo một quy tắc xác thực để thực thi điều đó. Tôi thường thiết lập quy tắc xác thực cho 60-80% của các cột trong bất kỳ bảng tính nào nhập liệu dữ liệu.

Thứ hai, hãy tạo danh sách thả xuống cho bất kỳ trường nào có tập hợp giá trị hợp lệ hạn chế. Đừng để người ta nhập "New York," "NY," "new york," và "N.Y." vào một trường tiểu bang — hãy cho họ một danh sách thả xuống với đúng một tùy chọn cho New York. Chỉ riêng điều này có thể giảm lỗi nhập liệu từ 40-50% theo kinh nghiệm của tôi.

Thứ ba, mỗi khi có thể, hãy nhập dữ liệu thay vì gõ lại nó. Hầu hết phần mềm hiện đại có thể xuất sang định dạng CSV. Hãy học cách nhập tệp CSV vào bảng tính của bạn đúng cách, bảo tồn các loại dữ liệu và định dạng. Vâng, việc thiết lập lần đầu tiên mất 10 phút. Nhưng điều đó tiết kiệm hàng giờ làm việc và loại bỏ hoàn toàn các loại lỗi.

Lỗi Công thức: Những kẻ giết người Thầm lặng của Độ tin cậy Bảng tính

Dưới đây là một kịch bản mà tôi đã gặp ít nhất 30 lần trong sự nghiệp tư vấn của mình: ai đó xây dựng một mô hình tài chính với 200 công thức. Họ kiểm tra nó một cách cẩn thận, xác minh kết quả, và mọi thứ trông hoàn hảo. Sáu tháng sau, ai đó chèn một hàng mới vào giữa phạm vi dữ liệu. Một nửa các công thức được cập nhật đúng để bao gồm hàng mới. Một nửa còn lại thì không. Không ai nhận ra vì tổng số vẫn trông hợp lý. Mô hình giờ đây đang tạo ra kết quả không chính xác, và có thể mất vài tháng hoặc vài năm trước khi ai đó phát hiện ra vấn đề.