Хорошая практика для статистического анализа в бизнес-среде

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

Краткая предыстория:

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

Что я хочу сделать:

В настоящее время мы применяем подход, основанный на принципах laissez-faire. Человек из функции поддержки назначается, когда работа вводится в эксплуатацию, данные собираются (или извлекаются, если таковые имеются, Business Intelligence), анализируются, и окончательный набор выводов направляется комиссару. Это было слабо обосновано на том основании, что не роль комиссара читать анализ; наша роль в качестве вспомогательной функции заключается в обеспечении правильного анализа вопросов / тем, которые комиссар хочет изучить.

Я хочу призвать немного больше структуры в подходе, чтобы сделать

а) наш анализ более высокого качества;

б) обеспечить защиту, когда наш анализ может привести к неправильным решениям; и сделать

c) наш анализ более прозрачен, поэтому мы не видим себя как «черный ящик», который собирает данные и выкладывает результаты.

Мои первые мысли были:

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, запишите это в лабораторный журнал и опишите, почему вы приняли решение. В будущем люди, как правило, забывают обоснование решений, поэтому важно записать их. К сожалению, люди из социальных наук не имеют привычки вести лабораторные журналы, это проблема.

Другим аспектом хорошей практики является дисциплина на начальном этапе ввода в эксплуатацию. Это может включать в себя основные вещи, такие как согласование в письменной форме того, что требуется от комиссара (во избежание недоразумений и последующих споров) и выяснение того, кто в бизнесе имеет полномочия для ввода работы в эксплуатацию (первый шаг к обеспечению того, чтобы функция отвечала реальным потребностям бизнеса, а не просто потакать любому, у кого есть блестящая идея).

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

Я думаю, что у вас есть часть вашего ответа в вопросе - «хорошая структура» является ключевой.

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

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

Шесть Сигма (в некоторых местах, где я работал, - это немного грязный термин) и другие методологии обеспечивают основу для подхода, решения и встраивания решения. Поскольку они основаны на структуре, они могут быть проверены. Ключ должен гарантировать, что все обучены методологии И имеют хороший шаблон, который подлежит аудиту.

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

Возвращаясь к Шести сигмам, некоторые подходы могут заключаться в аудите на этапе определения, после измерения и анализа и, наконец, в заключении (после улучшения и контроля).

Шесть Сигма, конечно, не самая лучшая во всех ситуациях, но я могу рекомендовать ее в качестве потенциальной отправной точки.