Гарна практика для статистичного аналізу в бізнес-середовищі

(Хоча я усвідомлюю, що мова йде не лише про статистику, а про поширення статистики в діловому середовищі, тому я припускаю, що вона все ще знаходиться в межах теми резюме)

Короткий фон:

Наше ділове середовище (і я підозрюю, що в інших середовищах) підтримує функцію, яка спеціалізується на статистичному аналізі та дослідженнях. Ми тісно співпрацюємо з Business Intelligence, а інші департаменти отримують доручення виробляти роботи. Фактично, дані, аналіз та висновки не належать нам: ми збираємо дані, проводимо аналіз та робимо висновки для використання комісіонером у своїй роботі.

Що я хочу зробити:

В даний час ми застосовуємо досить підхід. Особа з функції підтримки призначається при введенні в експлуатацію, збираються дані (або витягуються, якщо такі існують, Business Intelligence), аналізуються і остаточний набір висновків надсилається уповноваженому. Це було необґрунтовано обґрунтовано, виходячи з того, що аналіз комісії не повинен читати аналіз; це наша роль як функції підтримки, щоб забезпечити правильний аналіз питань / тем, які комісар хоче вивчити.

Я хочу звернути трохи більше структури щодо підходу

а) наш аналіз вищої якості;

б) забезпечити захисність, коли наш аналіз може призвести до неправильних рішень; і зробити

в) наш аналіз більш прозорий, тому на нас не розглядають як на «чорну скриньку», яка бере дані та випльовує результати.

Мої початкові думки були:

1. Підготуйте технічний документ з кожним твором, який виправдовує підхід, зроблені припущення, виявлені проблеми, невизначеності, які існують і т. Д. Хоча це не обов’язково читатиметься всіма, його слід використовувати як засіб для пояснення комісіонером наслідки використання зроблених висновків. Це перекладає частину ризику туди, куди йому належить належати: комісіонеру.

2. Обмежте весь аналіз пакетом, таким як Stata, SPSS або R, і вимагайте, щоб поряд із технічним документом був створений повний набір коду. У всіх нас є звичка використовувати Microsoft Excel для деяких видів аналізу (шкідлива звичка більше за все). Однак Excel не сприяє легкій відтворюваності аналізу. Це допомагає захищати функцію підтримки, коли наш аналіз ставиться під сумнів, створює прозорість нашого підходу, але також значно полегшує роль (3):

3. Призначте рецензента до кожного твору, який повинен «підписати» роботу до того, як вона буде відправлена ​​комісіонеру. Підписавшись, вона розподіляє цілісність аналізу на 2 людини та заохочує їх працювати разом (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

Підсумкове зауваження (вибачте, якщо вам це здається очевидним): незалежно від типу вашого бізнес-середовища (що, до речі, незрозуміло), я б рекомендував почати з ділової сторони речей і створити архітектуру аналізу даних , яка (як усі ІТ) повинні бути узгоджені з архітектурою бізнесу, включаючи бізнес-процеси, організаційні підрозділи, культуру та людей. Я сподіваюся, що це корисно.

ОНОВЛЕННЯ: Що стосується створення нової або вдосконалення існуючої архітектури аналізу даних (також її називають архітектурою даних , в термінології архітектури підприємства ), я подумав, що ці два набори слайдів презентації можуть бути корисними також: це та це .

У банківській справі моделювання має відповідати типовим інструкціям щодо управління ризиками, як-от OCC 2011-12 . Я думаю, що це цікавий документ, навіть якщо ви не займаєтесь банківською діяльністю.

У MathWorks є ця стаття про стандарти моделювання.

Оскільки моделювання передбачає написання програмного забезпечення в тій чи іншій формі, я використовую елементи методології розробки програмного забезпечення , особливо якщо мова йде про тестування та тестування одиниць . Я також використовую засоби управління конфігурацією програмного забезпечення, такі як SVN. Є багато того, що команди з моделювання можуть навчитися програмістам в плані управління складними програмними проектами, такими як системи відстеження випусків та CMS .

Однією з найважливіших речей є методологія та процес, життєвий цикл розвитку моделі. Створіть настанови щодо розробки моделей та протестуйте їх, перелічіть стандартні інструменти та тести тощо. Наприклад, виберіть один-два тести на придатність та використовуйте їх всюди.

Створюйте шаблони всього: моделювання сценаріїв, білих робіт, презентацій тощо. Наприклад, у мене є шаблони в LaTeX для всієї документації, тому наші білі документи виглядають дуже схоже, і всі знають, де шукати інформацію. У нас є стандартні розділи, такі як описова статистика та стандартні стовпці в них, такі як куртоз, перша та остання дата спостереження тощо.

Майте журнал лабораторії. Це одне, чого люди з важких наук повинні були навчитися на докторантурі: вести щоденник усіх досліджень, ідей та особливо рішень. Коли ви вирішили використовувати ARIMA замість GARCH, запишіть його в журнал лабораторії та опишіть, чому ви прийняли рішення. Люди в дорозі, як правило, забувають обґрунтування рішень, тому важливо записати їх. На жаль, люди з соціальних груп не мають звички вести журнали лабораторій, це проблема.

Іншим аспектом належної практики є дисципліна на початковому етапі введення в експлуатацію. Це може включати основні речі, як узгодження в письмовій формі того, що вимагає уповноважений (щоб уникнути непорозумінь та подальших суперечок) та уточнення того, хто в бізнесі має повноваження виконувати завдання (перший крок до того, щоб функція відповідала реальним потребам бізнесу, а не просто балувати всіх, хто має яскраву ідею).

Дисципліна при введенні в експлуатацію повинна також сприяти конструктивному діалогу перед узгодженням роботи. Ті, хто вводить в експлуатацію, можуть мати розпливчасте уявлення про те, що їм потрібно, але мають складнощі в їх точному формулюванні, або якщо вони пропонують точну формулювання, можливо, це не є найбільш релевантним для їхніх бізнес-потреб (наприклад, вони можуть попросити розслідування Причини короткострокового падіння продажів, коли їх справді цікавить, - це довгострокові фактори, що сприяють продажам). Статистики та дослідники можуть бути хорошими у формулюванні точних питань чи планів роботи, але менш здатні визначити, що буде корисно для бізнесу. Там я пропоную паралель з хорошою практикою в академічному дослідженні, яка розрізняє дослідницькі питаннявизначення досить широких цікавих тем та гіпотез дослідження та цілей у межах таких тем, які є достатньо конкретними, щоб призвести до чітко визначених наукових досліджень. Таким чином, може бути корисним вважати членів комісії як генерування еквівалента дослідницьких питань, а статистиків та дослідників, як допомогти їм визначити більш конкретні робочі програми, що стосуються цих питань.

Я думаю, ви отримали частину своєї відповіді на запитання - ключова «хороша структура».

Я є інженером і працюю в ролях, які наголошують на аналогічному застосуванні - там, де ви знайомітеся з проблемами, щоб надати допомогу в аналізі та покращенні результатів, але перебуваєте в дорадчій, а не в ролі виконавця.

Найкращі підходи, які я бачив, - це не надто наказові чи розкуті, щоб забезпечити потрібну кількість доказів того, що робота була зроблена ретельно - це те, на що я думаю, що ви прагнете.

Шість знаків (це дещо брудний термін, де я працював) та інші методики створюють основу для підходу, вирішення та вбудовування рішення. Оскільки вони засновані на рамках, вони можуть бути перевірені. Ключовим моментом є те, щоб усі навчались методиці І мали хороший шаблон, який підлягає аудиту.

Наприклад, ви, мабуть, хочете, щоб рішення були стандартними - це не визначається використовуваною програмою, а скоріше, чи зможете ви перевірити етапи аналізу, використані на більш пізньому терміні, і бути впевненим, що завдання було виконане до стандарту. Забезпечення важливих етапів - наприклад, пункти пропуску, де можна зробити аудит, буде простіше, ніж намагатися провести аудит в кінці проекту.

Повертаючись до Шістьма сигмами, деякими підходами може бути аудит на етапі визначення, після вимірювання та аналізу та, нарешті, після завершення (після вдосконалення та контролю).

Six Sigma, безумовно, не найкращий у всіх ситуаціях, але я можу рекомендувати це як потенційну відправну точку.