Dobra praktyka analizy statystycznej w środowisku biznesowym

(Chociaż zdaję sobie sprawę, że nie chodzi wyłącznie o statystyki, chodzi o rozpowszechnianie statystyk w środowisku biznesowym, więc założyłem, że nadal mieści się w zakresie tematycznym CV)

Krótkie tło:

Nasze środowisko biznesowe (i podejrzewam, że inne środowiska) mają funkcję wsparcia, która specjalizuje się w analizach statystycznych i badaniach. Ściśle współpracujemy z Business Intelligence i są zlecane przez inne działy do ​​produkcji pracy. W efekcie dane, analizy i wnioski nie należą do nas: zbieramy dane, przeprowadzamy analizy i wyciągamy wnioski, które komisarz może wykorzystać w swojej pracy.

Co chcę robić:

Obecnie stosujemy podejście laissez-faire. Osoba z funkcji wsparcia jest przypisywana podczas zlecania pracy, gromadzenia danych (lub wyodrębniania, jeśli istnieje, przez Business Intelligence), analizowania, a ostateczny zestaw wniosków przesyłany jest do komisarza. Zostało to luźno uzasadnione na tej podstawie, że przeglądanie analizy nie jest zadaniem komisarza; naszą rolą jako funkcji wsparcia jest zapewnienie odpowiedniej analizy pytań / tematów, które komisarz chce zbadać.

Chcę przywołać nieco więcej struktury podejścia do tworzenia

a) nasza analiza wyższej jakości;

b) zapewniać obronę, gdy nasza analiza może prowadzić do złych decyzji; i zrób

c) nasza analiza jest bardziej przejrzysta, abyśmy nie byli postrzegani jako „czarna skrzynka”, która pobiera dane i wyrzuca wyniki.

Moje pierwsze myśli to:

1. Przygotuj dokument techniczny z każdym fragmentem pracy, który uzasadnia przyjęte podejście, przyjęte założenia, stwierdzone problemy, istniejące niepewności itp. Chociaż nie wszyscy koniecznie przeczytają ten dokument, należy go użyć jako środka wyjaśniającego komisarz konsekwencje wykorzystania wyciągniętych wniosków. Przenosi to część ryzyka tam, gdzie wydaje się, że powinno być: do komisarza.

2. Ogranicz wszystkie analizy do pakietu, takiego jak Stata, SPSS lub R, i wymagaj utworzenia pełnego zestawu kodu wraz z dokumentem technicznym. Każdy z nas ma zwyczaj używania Microsoft Excel do niektórych rodzajów analiz (zły nawyk bardziej niż cokolwiek innego). Jednak Excel nie promuje łatwej powtarzalności analizy. Pomaga to w obronie funkcji wsparcia, gdy nasza analiza jest kwestionowana, zapewnia przejrzystość w naszym podejściu, ale także znacznie ułatwia rolę (3):

3. Przypisywanie recenzenta do każdej pracy, która musi „podpisać” pracę, zanim zostanie wysłana do komisarza. Poprzez kontrasygnowanie rozdziela integralność analizy między 2 osoby i zachęca ich do współpracy (2 głowy są lepsze niż 1). Powinno to poprawić jakość analizy, a także zapewnić pewną obronę.

Czy istnieją inne aspekty dobrej praktyki, które można zastosować w tego rodzaju środowisku biznesowym?

Moja rada w dwóch słowach ( tryb TL; DR ): powtarzalne badania .

Aby uzyskać więcej informacji - w dużej mierze się nie powtarzać - pozwól, że odniosę się do moich odpowiednich odpowiedzi w innym miejscu na StackExchange. Te odpowiedzi reprezentują moje przemyślenia (i pewne doświadczenie) na te tematy:

• czyszczenie danych: /datascience//a/722/2452
• odtwarzalne badania: /datascience//a/759/2452
• raporty vs. pulpity nawigacyjne: /datascience//a/907/2452
• przepływy pracy analizy danych i EDA: /datascience//a/1006/2452
• duże zbiory danych i R: /datascience//a/780/2452

Uwaga końcowa (przepraszam, jeśli uznasz to za oczywiste): niezależnie od rodzaju środowiska biznesowego (które jest niejasne), poleciłbym zacząć od strony biznesowej i stworzyć architekturę analizy danych , która (jako wszystkie związane z IT) powinny być dostosowane do architektury biznesowej, w tym procesów biznesowych, jednostek organizacyjnych, kultury i ludzi. Mam nadzieję, że to jest pomocne.

AKTUALIZACJA: W odniesieniu do tworzenia nowej lub ulepszania istniejącej architektury analizy danych (zwanej również architekturą danych , w terminologii architektury korporacyjnej ), pomyślałem, że te dwa zestawy slajdów prezentacji mogą być również przydatne: to i to .

W bankowości modelowanie musi być zgodne z wytycznymi zarządzania ryzykiem modeli, takimi jak OCC 2011-12 . Myślę, że to interesujący dokument, nawet jeśli nie prowadzisz bankowości.

MathWorks ma ten artykuł na temat standardów modelowania.

Ponieważ modelowanie polega na pisaniu oprogramowania w takiej czy innej formie, używam elementów metodologii tworzenia oprogramowania , szczególnie jeśli chodzi o testowanie i testowanie jednostkowe . Korzystam również z narzędzi do zarządzania konfiguracją oprogramowania , takich jak SVN. Zespoły zajmujące się modelowaniem mogą się wiele nauczyć od programistów w zakresie zarządzania złożonymi projektami oprogramowania, takimi jak systemy śledzenia problemów i CMS .

Jedną z najważniejszych rzeczy jest metodologia i proces, cykl życia modelu. Utwórz wytyczne dotyczące opracowywania modeli, przetestuj je, wypisz standardowe narzędzia i przetestuj itp. Na przykład wybierz jeden lub dwa testy dopasowania i używaj ich wszędzie.

Twórz szablony wszystkiego: skrypty modelowania, białe księgi, prezentacje itp. Na przykład mam szablony w LaTeX do całej dokumentacji, więc nasze białe księgi wyglądają bardzo podobnie i wszyscy wiedzą, gdzie szukać informacji. Mamy w nich standardowe sekcje, takie jak statystyki opisowe i standardowe kolumny, takie jak kurtoza, pierwsza i ostatnia data obserwacji itp.

Miej dziennik laboratoryjny. Jest to jedna rzecz, której ludzie nauk ścisłych powinni się nauczyć na doktoracie: prowadzić dziennik wszystkich badań, pomysłów, a zwłaszcza decyzji. Kiedy zdecydujesz się użyć ARIMA zamiast GARCH, zapisz to w dzienniku laboratoryjnym i opisz, dlaczego podjąłeś decyzję. Na dole ludzie zwykle zapominają o uzasadnieniu decyzji, dlatego ważne jest, aby je zapisać. Niestety ludzie ze środowisk społecznych nie mają zwyczaju prowadzenia dzienników laboratoryjnych, to problem.

Kolejnym aspektem dobrej praktyki jest dyscyplina na etapie pierwszego uruchomienia. Może to obejmować podstawowe rzeczy, takie jak uzgodnienie na piśmie, co jest wymagane przez komisarza (aby uniknąć nieporozumień i późniejszych sporów) oraz wyjaśnienie, kto w firmie ma uprawnienia do zlecania pracy (pierwszy krok w kierunku zapewnienia, że ​​funkcja odpowiada rzeczywistym potrzebom biznesowym, a nie po prostu pozwalając każdemu, kto ma świetny pomysł).

Dyscyplina w zakresie uruchamiania powinna również promować konstruktywny dialog przed uzgodnieniem prac, które należy podjąć. Zleceniodawcy mogą mieć niejasne pojęcie o tym, czego potrzebują, ale mają trudności z ich precyzyjnym sformułowaniem, lub jeśli oferują precyzyjne sformułowanie, może nie być to, co najbardziej odpowiada ich potrzebom biznesowym (na przykład mogą poprosić o zbadanie przyczynami krótkoterminowego spadku sprzedaży, gdy tak naprawdę są zainteresowani długoterminowymi czynnikami napędzającymi sprzedaż). Statystycy i badacze mogą być dobrzy w formułowaniu precyzyjnych pytań lub planów pracy, ale mniej zdolni do określenia, co będzie przydatne dla firmy. Sugeruję równoległe z dobrą praktyką w badaniach akademickich rozróżnienie między pytaniami badawczymiidentyfikacja dość ogólnych tematów oraz hipotez badawczych i celów w ramach tych tematów, które są wystarczająco szczegółowe, aby prowadzić do dobrze określonych badań naukowych. Dlatego pomocne może być myślenie, że komisarze generują odpowiednik pytań badawczych, a statystycy i badacze - pomagają im w określeniu bardziej szczegółowych programów pracy odpowiednich do tych pytań.

Myślę, że masz część swojej odpowiedzi na pytanie - kluczem jest „dobra struktura”.

Jestem inżynierem i pracuję w rolach, które podkreślają podobną aplikację - w której zapoznajesz się z problemami, aby pomóc w analizie i poprawie wyników, ale pełnią rolę doradczą, a nie wdrażającą.

Najlepsze podejścia, jakie widziałem, to takie, które nie są zbyt nakazowe ani zbyt luźne, aby zapewnić odpowiednią ilość dowodów na to, że praca została wykonana z należytą starannością - tego właśnie oczekuję.

Six Sigma (co w niektórych miejscach, w których pracowałem jest trochę nieprzyzwoity), a inne metodologie zapewniają ramy dla podejścia, rozwiązywania i osadzania rozwiązania. Ponieważ są oparte na ramach, mogą być kontrolowane. Kluczem do sukcesu jest zapewnienie, że wszyscy są przeszkoleni w zakresie metodologii ORAZ mieć dobry szablon, który można skontrolować.

Na przykład prawdopodobnie chcesz, aby rozwiązania były standardowe - nie jest to zdefiniowane przez używany program, ale raczej to, czy możesz skontrolować etapy analizy zastosowane w późniejszym terminie i mieć pewność, że zadanie zostało wykonane zgodnie ze standardem. Zapewnienie kamieni milowych - np. Punkty kontrolne, w których można przeprowadzić audyt, będą łatwiejsze niż próba przeprowadzenia audytu na końcu projektu.

Wracając do Six Sigma, niektórymi podejściami może być audyt na etapie Definiowania, po Pomiarze i Analizie, a na końcu przy finalizacji (po Ulepszeniu i Kontroli).

Six Sigma z pewnością nie jest najlepszy we wszystkich sytuacjach, ale mogę go polecić jako potencjalny punkt wyjścia.