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

На этапе проектирования все требования к будущей СППР последовательно декомпозируются (разбиваются) на три уровня:

• Бизнес-требования (Business Requirements) отвечают на вопрос «зачем компании эта система?» и фиксируют конкретную управленческую проблему, которую нужно решить, а также измеримую выгоду для бизнеса (например, сократить объем неликвидных запасов на складе на 20% или ускорить процесс формирования квартального бюджета с двух недель до одного дня).
• Пользовательские требования (User Requirements) описывают задачи с точки зрения лица, принимающего решение (ЛПР). Они оформляются в виде пользовательских историй (User Stories) или сценариев использования (Use Cases) и показывают, что именно руководитель должен делать в системе для достижения бизнес-цели (например: «как коммерческий директор, я хочу менять процент скидки в финансовой модели, чтобы сразу видеть прогноз чистой прибыли по филиалам»).
• Функциональные требования (Functional Requirements) переводят пожелания пользователей на технический язык разработчиков и определяют, как именно должна работать программа. Сюда входят конкретные функции интерфейса и расчетов: точные математические формулы, система фильтров (по датам, регионам, категориям товаров), настройка прав доступа, правила подсветки критических отклонений и кнопки экспорта отчетов в Excel или PDF.

Поскольку СППР сама не создает первичную информацию о ежедневных операциях компании, а лишь анализирует ее, главными поставщиками «сырых» данных для нее выступают учетные транзакционные системы:

• ERP (Enterprise Resource Planning / Система планирования ресурсов предприятия) охватывает весь внутренний контур бизнеса и отвечает за учет материальных, производственных и финансовых ресурсов. Из ERP-системы в СППР выгружаются данные о закупках сырья, загрузке производства, себестоимости продукции, текущих складских запасах, бухгалтерских проводках, исполнении бюджета и кадрах.
• CRM (Customer Relationship Management / Система управления взаимоотношениями с клиентами) отвечает за внешний контур компании и оцифровывает всю историю работы с покупателями. Она передает в СППР данные о входящих заявках (лидах), этапах сделок в воронке продаж, отклике на маркетинговые акции, частоте повторных покупок и обращениях клиентов в службу технической поддержки.

При слиянии данных из ERP, CRM и внешних источников в единую базу СППР неизбежно возникает проблема их нестыковки и загрязнения (например, когда один и тот же контрагент записан по-разному в базах отдела продаж и бухгалтерии). В аналитике эта проблема описывается правилом GIGO (Garbage In - Garbage Out / «Мусор на входе - мусор на выходе»): даже самая сложная и математически безупречная модель выдаст ложный прогноз и приведет к ошибочному управленческому решению, если на вход ей подать неполные, дублирующиеся или искаженные данные.

Чтобы предотвратить эффект GIGO, перед загрузкой в СППР информация проходит процедуру очистки и проверяется по пяти ключевым измерениям качества данных (Data Quality):

1. Полнота (Completeness) означает, что в данных нет критических пропусков и пустых ячеек. Если менеджеры заполняют поле «источник клиента» или «причина отказа» только в половине карточек CRM, система не сможет построить достоверный отчет об эффективности рекламы.
2. Точность (Accuracy) показывает, насколько данные в системе соответствуют реальному положению дел. Сюда относится отсутствие опечаток при ручном вводе, правильность указанных цен, корректность расчетов и совпадение цифр в базе с фактическим наличием товара на складе.
3. Актуальность / Своевременность (Timeliness) определяет, насколько данные свежие и доступны ли они в тот момент, когда нужно принять решение. Отчет о продажах, который обновляется с задержкой в две недели, бесполезен для оперативного управления запасами или корректировки запущенной рекламной кампании.
4. Непротиворечивость / Согласованность (Consistency) требует, чтобы данные из разных систем не конфликтовали между собой и подчинялись единой логике. Например, сумма выручки за квартал в CRM не должна расходиться с данными финансового модуля ERP, а все филиалы должны использовать одинаковые справочники товаров, валюты и единицы измерения.
5. Уникальность (Uniqueness) гарантирует отсутствие дубликатов, когда один и тот же клиент, товар или сделка по ошибке заведены в базу несколько раз под разными номерами. Дубликаты искусственно завышают показатели клиентской базы и искажают расчет среднего чека или прогноза спроса.