Thực hành tốt để phân tích thống kê trong môi trường kinh doanh

(Mặc dù tôi nhận thấy điều này không nghiêm túc về thống kê, nhưng đó là về việc phổ biến số liệu thống kê trong môi trường kinh doanh nên tôi đã cho rằng nó vẫn nằm trong phạm vi chủ đề của CV)

Một chút nền tảng:

Môi trường kinh doanh của chúng tôi (và tôi nghi ngờ các môi trường khác) có chức năng hỗ trợ chuyên phân tích và nghiên cứu thống kê. Chúng tôi hợp tác chặt chẽ với Business Intelligence và được các bộ phận khác ủy quyền sản xuất các tác phẩm. Trên thực tế, dữ liệu, phân tích và kết luận không thuộc về chúng tôi: chúng tôi thu thập dữ liệu, thực hiện phân tích và đưa ra kết luận để ủy viên sử dụng trong công việc của họ.

Những gì tôi muốn làm:

Hiện tại, chúng tôi chạy một cách tiếp cận khá tự do. Một cá nhân từ chức năng hỗ trợ được chỉ định khi công việc được đưa vào, dữ liệu được thu thập (hoặc trích xuất, nếu nó tồn tại, bởi Business Intelligence), được phân tích và bộ kết luận cuối cùng được gửi đến ủy viên. Điều này đã được chứng minh một cách lỏng lẻo trên cơ sở rằng đó không phải là vai trò của ủy viên để đọc qua phân tích; vai trò của chúng tôi là chức năng hỗ trợ để đảm bảo chúng tôi cung cấp phân tích phù hợp cho các câu hỏi / chủ đề mà ủy viên muốn khám phá.

Tôi muốn gọi thêm một chút cấu trúc về cách tiếp cận để thực hiện

a) phân tích của chúng tôi về chất lượng cao hơn;

b) cung cấp khả năng phòng thủ khi phân tích của chúng tôi có thể dẫn đến các quyết định tồi tệ; và làm

c) phân tích của chúng tôi minh bạch hơn vì vậy chúng tôi không xem là 'hộp đen' lấy dữ liệu và đưa ra kết quả.

Suy nghĩ ban đầu của tôi là:

1. Tạo ra một tài liệu kỹ thuật với mọi phần công việc biện minh cho cách tiếp cận được thực hiện, các giả định được đưa ra, các vấn đề được tìm thấy, sự không chắc chắn tồn tại, v.v ... Mặc dù điều này không nhất thiết phải được mọi người đọc, nhưng nó nên được sử dụng như một phương tiện để giải thích ủy viên hậu quả của việc sử dụng các kết luận rút ra. Điều này chuyển một số rủi ro đến nơi mà nó cảm thấy như nó nên thuộc về: với ủy viên.

2. Hạn chế tất cả các phân tích đối với một gói như Stata, SPSS hoặc R và yêu cầu một bộ mã đầy đủ được sản xuất cùng với tài liệu kỹ thuật. Tất cả chúng ta đều có thói quen sử dụng Microsoft Excel cho một số loại phân tích (thói quen xấu nhiều hơn bất cứ điều gì). Tuy nhiên, Excel không thúc đẩy khả năng phân tích dễ dàng. Điều này giúp bảo vệ chức năng hỗ trợ khi phân tích của chúng tôi bị nghi ngờ, tạo sự minh bạch trong cách tiếp cận của chúng tôi nhưng cũng làm cho vai trò của (3) dễ dàng hơn nhiều:

3. Chỉ định người đánh giá cho mọi phần công việc phải 'ký' công việc trước khi nó được gửi cho ủy viên. Bằng cách ký hiệu, nó phân phối tính toàn vẹn của phân tích trên 2 người và khuyến khích họ làm việc cùng nhau (2 đầu tốt hơn 1). Điều này sẽ cải thiện chất lượng phân tích và cũng cung cấp một số khả năng phòng thủ.

Có bất kỳ khía cạnh nào khác của thực tiễn tốt có thể được áp dụng trong môi trường kinh doanh loại này không?

Lời khuyên của tôi trong hai từ ( chế độ TL; DR ): nghiên cứu tái sản xuất .

Để biết thêm chi tiết - phần lớn là không lặp lại chính mình - hãy để tôi giới thiệu cho bạn các câu trả lời có liên quan của tôi ở nơi khác trên StackExchange. Những câu trả lời này thể hiện suy nghĩ của tôi (và một số kinh nghiệm) về các chủ đề:

• làm sạch dữ liệu: /datascience//a/722/2452
• nghiên cứu tái sản xuất: /datascience//a/759/2452
• báo cáo so với bảng điều khiển: /datascience//a/907/2452
• quy trình phân tích dữ liệu và EDA: /datascience//a/1006/2452
• dữ liệu lớn và R: /datascience//a/780/2452

Lưu ý cuối cùng (xin lỗi, nếu bạn thấy rõ ràng): bất kể loại môi trường kinh doanh của bạn (không rõ ràng, nhân tiện), tôi khuyên bạn nên bắt đầu từ khía cạnh kinh doanh và tạo kiến trúc phân tích dữ liệu (như tất cả liên quan đến CNTT) phải phù hợp với kiến ​​trúc kinh doanh, bao gồm các quy trình kinh doanh, đơn vị tổ chức, văn hóa và con người. Tôi hy vọng rằng điều này là hữu ích.

CẬP NHẬT: Liên quan đến việc tạo mới hoặc cải thiện kiến trúc phân tích dữ liệu hiện có (còn được gọi là kiến trúc dữ liệu , theo thuật ngữ kiến trúc doanh nghiệp ), tôi nghĩ rằng hai bộ slide trình bày này cũng có thể hữu ích: cái này và cái này .

Trong ngân hàng, mô hình hóa phải tuân thủ các nguyên tắc quản lý rủi ro mô hình, chẳng hạn như OCC 2011-12 . Tôi nghĩ đó là một tài liệu thú vị ngay cả khi bạn không ở trong ngân hàng.

MathWorks có bài viết này về các tiêu chuẩn mô hình.

Vì mô hình hóa liên quan đến việc viết phần mềm ở dạng này hay dạng khác, tôi sử dụng các yếu tố của phương pháp phát triển phần mềm , đặc biệt khi nói đến kiểm thử và kiểm thử đơn vị . Tôi cũng sử dụng các công cụ quản lý cấu hình phần mềm như SVN. Có rất nhiều nhóm mô hình hóa có thể học hỏi từ các lập trình viên về mặt quản lý các dự án phần mềm phức tạp, chẳng hạn như hệ thống theo dõi vấn đề và CMS .

Một trong những điều quan trọng nhất là phương pháp và quy trình, vòng đời phát triển mô hình. Tạo hướng dẫn về cách phát triển các mô hình và kiểm tra chúng, liệt kê các công cụ tiêu chuẩn và kiểm tra, v.v. Ví dụ, chọn một hoặc hai bài kiểm tra mức độ phù hợp và sử dụng chúng ở mọi nơi.

Tạo các mẫu của tất cả mọi thứ: mô hình hóa tập lệnh, sách trắng, bản trình bày, v.v. Chẳng hạn, tôi có các mẫu trong LaTeX cho tất cả các tài liệu, vì vậy các trang trắng của chúng tôi trông rất giống nhau và mọi người đều biết tìm thông tin ở đâu. Chúng tôi có các phần tiêu chuẩn, chẳng hạn như thống kê mô tả và các cột tiêu chuẩn trong đó như kurtosis, ngày quan sát đầu tiên và cuối cùng, v.v.

Có tạp chí phòng thí nghiệm. Đây là một điều mà những người làm khoa học khó nên học ở Tiến sĩ: ghi nhật ký tất cả các nghiên cứu, ý tưởng và đặc biệt là các quyết định. Khi bạn quyết định sử dụng ARIMA thay vì GARCH, hãy ghi lại nó trong tạp chí phòng thí nghiệm và mô tả lý do tại sao bạn đưa ra quyết định. Mọi người thường có xu hướng quên đi lý do đằng sau các quyết định, vì vậy điều quan trọng là ghi lại chúng. Thật không may, những người từ nền tảng khoa học xã hội không có thói quen giữ các tạp chí trong phòng thí nghiệm, đó là một vấn đề.

Một khía cạnh khác của thực hành tốt là kỷ luật ở giai đoạn vận hành ban đầu. Điều này có thể bao gồm những điều cơ bản như đồng ý bằng văn bản những gì được ủy quyền yêu cầu (để tránh những hiểu lầm và tranh chấp tiếp theo) và làm rõ ai trong doanh nghiệp có thẩm quyền để ủy thác công việc (bước đầu tiên hướng tới đảm bảo rằng chức năng đang giải quyết nhu cầu kinh doanh thực sự chứ không phải chỉ cần nuông chiều bất cứ ai có một ý tưởng sáng sủa).

Kỷ luật trong vận hành cũng nên thúc đẩy đối thoại mang tính xây dựng trước khi thỏa thuận về công việc sẽ được thực hiện. Những người vận hành có thể có một ý tưởng mơ hồ về những gì họ cần nhưng gặp khó khăn trong việc xây dựng nó một cách chính xác, hoặc nếu họ đưa ra một công thức chính xác thì đó có thể không phải là điều phù hợp nhất với nhu cầu kinh doanh của họ (ví dụ, họ có thể yêu cầu điều tra những lý do khiến doanh số giảm trong thời gian ngắn, khi điều họ thực sự quan tâm là những yếu tố dài hạn thúc đẩy doanh số). Các nhà thống kê và nhà nghiên cứu có thể giỏi trong việc đưa ra các câu hỏi hoặc kế hoạch làm việc chính xác, nhưng ít có khả năng xác định những gì sẽ hữu ích cho doanh nghiệp. Có một gợi ý song song với thực tiễn tốt trong nghiên cứu học thuật, điều này tạo ra sự khác biệt giữa các câu hỏi nghiên cứuxác định các chủ đề khá quan tâm và các giả thuyết nghiên cứu và mục đích trong các chủ đề đó đủ cụ thể để dẫn đến các nghiên cứu được xác định rõ. Do đó, có thể hữu ích khi nghĩ về các ủy viên khi tạo ra tương đương với các câu hỏi nghiên cứu và các nhà thống kê và nhà nghiên cứu khi giúp họ xác định các chương trình làm việc cụ thể hơn có liên quan đến những câu hỏi đó.

Tôi nghĩ rằng bạn đã có một phần câu trả lời của mình trong câu hỏi - một "cấu trúc tốt" là chìa khóa.

Tôi là một kỹ sư và đã làm việc trong các vai trò nhấn mạnh một ứng dụng tương tự - nơi bạn được giới thiệu các vấn đề để cung cấp hỗ trợ phân tích và cải thiện kết quả nhưng là một vai trò tư vấn thay vì thực hiện.

Các cách tiếp cận tốt nhất, mà tôi đã thấy, là những phương pháp không quá quy định hoặc lỏng lẻo để đảm bảo đúng bằng chứng cho thấy công việc được thực hiện với sự chuyên cần - đó là những gì tôi nghĩ bạn đang theo đuổi.

Six Sigma (một chút thuật ngữ bẩn ở một số nơi tôi đã làm việc) và các phương pháp khác cung cấp một khuôn khổ để tiếp cận, giải quyết và đưa ra giải pháp. Bởi vì chúng dựa trên một khung, chúng có thể được kiểm toán. Điều quan trọng là đảm bảo rằng tất cả mọi người được đào tạo về phương pháp VÀ có một khuôn mẫu tốt có thể nghe được.

Ví dụ, bạn có thể muốn các giải pháp đạt tiêu chuẩn - điều này không được xác định bởi chương trình được sử dụng mà là bạn có thể kiểm tra các bước phân tích được sử dụng vào một ngày sau đó và hài lòng rằng nhiệm vụ đã được hoàn thành theo tiêu chuẩn. Cung cấp các mốc quan trọng - ví dụ: kiểm tra các điểm mà bạn có thể kiểm toán sẽ dễ dàng hơn so với cố gắng kiểm toán vào cuối dự án.

Quay trở lại Six Sigma, một số cách tiếp cận có thể là kiểm toán ở giai đoạn Xác định, sau Biện pháp và Phân tích, và cuối cùng là kết luận (sau Cải thiện và Kiểm soát).

Six Sigma chắc chắn không phải là tốt nhất trong mọi tình huống nhưng tôi có thể đề nghị nó như một điểm khởi đầu tiềm năng.