비즈니스 환경에서 통계 분석을위한 모범 사례

(이것은 통계에 관한 것이 아니라 비즈니스 환경에서의 통계 보급에 관한 것이므로 CV의 주제 범위 내에 있다고 가정했습니다)

간단한 배경 :

우리의 비즈니스 환경 (및 다른 환경이 의심되는 경우)에는 통계 분석 및 연구를 전문으로하는 지원 기능이 있습니다. 우리는 비즈니스 인텔리전스와 긴밀히 협력하며 다른 부서에서 업무를 수행하도록 의뢰됩니다. 사실상 데이터, 분석 및 결론은 우리의 것이 아닙니다. 데이터를 수집하고, 분석을 수행하며, 위원이 업무에 사용할 결론을 도출합니다.

내가하고 싶은 것 :

현재 우리는 상당히 공정한 접근 방식을 운영하고 있습니다. 지원 기능의 개인은 작업이 시운전되고 데이터가 수집되거나 Business Intelligence에 의해 추출 된 경우 분석되고 최종 결론 세트가 커미셔너에게 전송됩니다. 이것은 분석을 읽는 것이 위원의 역할이 아님을 근거로하여 정당하게 정당화되었다; 커미셔너가 탐색하고자하는 질문 / 주제에 대한 올바른 분석을 제공하는 것이 지원 기능으로서의 역할입니다.

접근 방식에 대해 좀 더 구조를 만들고 싶습니다.

a) 고품질에 대한 우리의 분석;

b) 분석 결과가 잘못된 결정으로 이어질 수있을 때 방어력을 제공합니다. 하고

c) 분석이보다 투명 해 지므로 데이터를 가져오고 결과를 내뿜는 '블랙 박스'로 간주되지 않습니다.

나의 초기 생각은 다음과 같습니다.

1. 취한 접근법, 가정, 발견 된 문제, 존재하는 불확실성 등을 정당화하는 모든 작업에 대해 기술 문서를 작성하십시오. 반드시 모든 사람이 읽을 수있는 것은 아니지만,이를 설명하기위한 수단으로 사용해야합니다. 커미셔너는 도출 된 결론을 사용한 결과를 봅니다. 이로 인해 위험의 일부가 소속감이있는 곳으로 옮깁니다.

2. 모든 분석을 Stata, SPSS 또는 R과 같은 패키지로 제한하고 기술 문서와 함께 전체 코드 세트를 생성해야합니다. 우리 모두는 일부 유형의 분석에 Microsoft Excel을 사용하는 습관을 가지고 있습니다 (무엇보다 나쁜 습관). 그러나 Excel은 분석의 쉬운 재현성을 촉진하지 않습니다. 이를 통해 분석에 의문을 제기 할 때 지원 기능을 방어하고 접근 방식에 투명성을 제공 할뿐만 아니라 (3)의 역할을 훨씬 쉽게 수행 할 수 있습니다.

3. 작업을 커미셔너에게 보내기 전에 작업에 '카운터 서명'해야하는 모든 작업에 검토자를 지정하십시오. 서명을 통해 분석의 무결성을 두 사람에게 분산시키고 함께 일하도록 장려합니다 (2 개가 1보다 낫습니다). 이것은 분석의 질을 향상시키고 방어력을 제공해야합니다.

이런 종류의 비즈니스 환경에 적용 할 수있는 모범 사례가 있습니까?

두 단어 ( TL; DR 모드 ) 에서 내 조언 : 재현 가능한 연구 .

대한 자세한 내용은 - 주로 자신을 반복하지 - 나 다른 곳 StackExchange 내 관련 답변에 당신을 참조 할 수 있습니다. 이 답변은 주제에 대한 나의 생각과 경험을 나타냅니다.

• 데이터 정리 : /datascience//a/722/2452
• 재현 가능한 연구 : /datascience//a/759/2452
• 보고서 및 대시 보드 : /datascience//a/907/2452
• 데이터 분석 워크 플로우 및 EDA : /datascience//a/1006/2452
• 빅 데이터 및 R : /datascience//a/780/2452

마지막 주 (죄송합니다, 당신이 찾을 경우 명백한가)에 관계없이 (그런데, 불분명) 비즈니스 환경의 유형, 나는 사물의 비즈니스 측면에서 시작하고 작성하는 것이 좋습니다 데이터 분석 아키텍처를 , (같은 모든 IT 관련)은 비즈니스 프로세스, 조직 구성 단위, 문화 및 사람을 포함한 비즈니스 아키텍처와 일치 해야합니다 . 도움이 되길 바랍니다.

업데이트 : 새로운를 만들거나 기존 개선에 관해서 데이터 분석 아키텍처 (이라고도 데이터 아키텍처 에서, 엔터프라이즈 아키텍처의 용어), 나는이 두 세트 생각 프리젠 테이션 슬라이드 뿐만 아니라 유용 할 수 있습니다 : 이 와 이 .

뱅킹에서 모델링은 OCC 2011-12 와 같은 모델 위험 관리 지침을 준수해야합니다 . 은행에 있지 않더라도 흥미로운 문서라고 생각합니다.

MathWorks에는 모델링 표준에 대한 이 기사 가 있습니다.

모델링에는 소프트웨어를 한 형태 또는 다른 형태로 작성하는 것이 포함되므로 , 특히 테스트 및 단위 테스트 와 관련하여 소프트웨어 개발 방법론의 요소를 사용합니다 . SVN과 같은 소프트웨어 구성 관리 도구 도 사용 합니다 . 이슈 추적 시스템 및 CMS 와 같은 복잡한 소프트웨어 프로젝트 관리 측면에서 모델링 팀이 프로그래머로부터 배울 수있는 것이 많이 있습니다 .

가장 중요한 것 중 하나는 방법론과 프로세스, 모델 개발 수명주기입니다. 모델 개발 방법에 대한 지침을 작성하고 테스트하고 표준 도구와 테스트 등을 나열하십시오. 예를 들어 적합도 테스트를 하나 또는 두 개 선택하여 어디서나 사용할 수 있습니다.

모델링 스크립트, 백서, 프리젠 테이션 등 모든 템플릿을 작성하십시오. 예를 들어, LaTeX에 모든 문서에 대한 템플릿이 있으므로 백서가 매우 유사하게 보이고 모든 사람이 정보를 찾을 위치를 알고 있습니다. 우리는 설명 통계와 같은 표준 섹션과 첨도, 첫 번째 및 마지막 관찰 날짜 등과 같은 표준 열을 가지고 있습니다.

랩 일지가 있습니다. 이것은 어려운 과학 사람들이 박사 학위에서 배워야 할 한 가지 사항입니다. GARCH 대신 ARIMA를 사용하기로 결정한 경우 랩 저널에 ARIMA를 기록하고 결정한 이유를 설명하십시오. 길을 따라 내려가는 사람들은 의사 결정의 근거를 잊어 버리는 경향이 있으므로이를 기록하는 것이 중요합니다. 불행히도, 사회 과학 배경을 가진 사람들은 실험실 저널을 유지하는 습관이 없으므로 문제입니다.

모범 사례의 또 다른 측면은 초기 시운전 단계에서의 훈련입니다. 여기에는 커미셔너가 요구하는 것을 서면으로 동의하고 (오해 및 후속 분쟁을 피하기 위해) 업무를 위임 할 권한이있는 사람을 밝히는 것과 같은 기본 사항이 포함될 수 있습니다 (기능이 실제 비즈니스 요구를 해결하도록하는 첫 단계) 밝은 생각을 가진 사람에게 빠지다).

커미셔닝 분야는 또한 수행 될 작업에 대한 합의 이전에 건설적인 대화를 장려해야합니다. 이러한 커미셔닝은 필요한 것에 대해 모호한 아이디어를 가지고 있지만 정확하게 공식화하는 데 어려움이 있거나 정확한 공식을 제공하는 경우 비즈니스 요구와 가장 관련이없는 것일 수 있습니다 (예 : 그들이 실제로 관심이있는 것이 판매를 이끄는 장기적 요인 일 때 단기 판매 감소의 이유). 통계 학자와 연구원은 정확한 질문이나 작업 계획을 세우는 데 능숙하지만 비즈니스에 유용한 것이 무엇인지 파악하기가 어렵습니다. 나는 학문 연구에서 연구 문제를 구별하는 모범 사례와 비슷한 점을 제안합니다.상당히 광범위한 관심 주제와 연구 가설을 식별하고 잘 정의 된 연구 연구로 이어질 수있는 주제 내에서 목표를 세웁니다. 따라서 커미셔너가 연구 질문과 통계 학자 및 연구자에 해당하는 것을 생성하는 것으로 생각하면 도움이 될 수 있습니다.

나는 당신이 그 질문에 대한 당신의 대답의 일부를 가지고 있다고 생각합니다 – "좋은 구조"가 핵심입니다.

저는 엔지니어이며 유사한 응용 프로그램을 강조하는 역할을 수행하고 있습니다. 여기서 결과를 분석하고 개선하는 데 도움을주기 위해 문제가 발생하지만 구현 자 역할이 아닌 자문 역할을합니다.

내가 본 가장 좋은 접근 방식은 너무 규범 적이거나 느슨하지 않은 방법으로, 부지런히 작업이 완료되었다는 적절한 증거를 확보 할 수 없습니다.

Six Sigma (내가 일한 일부 장소에서 약간 불쾌한 용어 임)와 다른 방법론은 솔루션에 접근, 해결 및 포함하기위한 프레임 워크를 제공합니다. 프레임 워크를 기반으로하기 때문에 감사 할 수 있습니다. 핵심은 모든 사람이 방법론에 대해 훈련을 받고 감사 가능한 훌륭한 템플릿을 갖도록하는 것입니다.

예를 들어, 솔루션이 표준이되기를 원할 것입니다. 이는 사용 된 프로그램에 의해 정의되는 것이 아니라 나중에 사용 된 분석 단계를 감사하고 작업이 표준에 완료되었다는 것을 만족시킬 수 있는지 여부입니다. 이정표 제공-예를 들어 프로젝트 종료시 감사하는 것보다 감사 할 수있는 점검 점이 더 쉽습니다.

식스 시그마로 돌아가서, 일부 접근 방식은 정의 단계에서, 측정 및 분석 후, 그리고 최종적으로 (개선 및 제어 후) 감사하는 것입니다.

Six Sigma는 모든 상황에서 최고는 아니지만 잠재적 인 출발점으로 추천 할 수 있습니다.