Курсовая по бизнес-информатике в НИУ ВШЭ: как связать бизнес-процесс, данные, архитектуру и измеримый эффект

Курсовая по бизнес-информатике в НИУ ВШЭ имеет прямой образовательный контекст. В 2026 году программа «Бизнес-информатика» реализуется Высшей школой бизнеса и соединяет информатику, экономику, управление и разработку информационных систем.

Официальные страницы:
https://www.hse.ru/ba/bi/
https://www.hse.ru/ba/bi/admission/

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

Начните с процесса

Слабая тема:

«Разработка CRM-системы».

Сильнее:

«Сокращение времени обработки B2B-заявки через автоматизацию маршрутизации и контроля SLA».

Или:

«Информационная система для анализа возвратов заказов с drill-down до причины».

Сначала бизнес-задача, потом технология.

As-Is

Опишите фактический процесс:

1. trigger;
2. input;
3. role;
4. action;
5. decision;
6. output.

Для каждого шага соберите:

• time;
• system;
• document;
• error.

Не рисуйте BPMN до интервью и наблюдения.

Baseline

До автоматизации измерьте:

• lead time;
• manual steps;
• rework;
• error rate;
• backlog.

Иначе новый продукт нельзя сравнить с текущим процессом.

Business requirement

Пример:

«Руководитель должен видеть просроченные заявки».

System requirement

«Система вычисляет deadline и возвращает заявки со status overdue».

Связь между двумя уровнями должна быть прозрачной.

Acceptance criteria

Например:

если deadline < current date и status != closed, заявка отображается в overdue list.

Так requirement становится тестируемым.

Stakeholders

Определите:

• end user;
• process owner;
• approver;
• IT;
• customer.

Их требования могут конфликтовать.

Не собирайте требования только у одного человека.

Prioritization

Используйте:

• MoSCoW;
• value/effort;
• risk.

Не пытайтесь реализовать 100% пожеланий за одну курсовую.

BPMN

Если используете BPMN, соблюдайте смысл:

• event;
• task;
• gateway;
• pool/lane.

Не называйте обычную блок-схему BPMN.

To-Be

Новая схема должна показывать конкретное изменение.

Например:

ручная проверка -> автоматическая validation.

Сравните количество шагов и roles.

Data model

Выделите сущности:

• customer;
• request;
• order;
• document;
• employee;
• status.

Связи должны соответствовать процессу.

Не создавайте таблицу `data`, где лежит всё.

Master data

Определите, где находится источник истины.

Например:

клиент ведётся в CRM, а заказ в ERP.

Не создавайте дублирующий справочник без синхронизации.

Data quality

Проверьте:

• duplicates;
• missing;
• invalid code;
• outdated status.

Плохие master data быстро разрушают аналитику.

Integration

Опишите:

source -> API/file -> target.

Для интеграции нужны:

• mapping;
• frequency;
• error handling;
• ownership.

Не ограничивайтесь стрелкой между двумя прямоугольниками.

API contract

Для нескольких ключевых endpoint покажите:

• method;
• request;
• response;
• error.

Не вставляйте весь Swagger.

Event-driven

Если процесс должен реагировать на событие, можно использовать event.

Например:

order.created.

Но message broker имеет смысл только при реальной потребности в decoupling или async processing.

Асинхронный процесс

Для долгой операции:

request -> job -> worker -> result.

Покажите status.

Не заставляйте пользователя ждать открытый request минуту.

BI

Dashboard должен отвечать на управленческий вопрос.

Например:

• где SLA violations;
• какой segment;
• какая причина возврата;
• какой trend.

Не делайте дашборд из всех полей БД.

KPI

Показатель должен вести к действию.

Например:

«Если backlog > X, перераспределить capacity».

Dashboard без decision rule часто становится декоративным.

Drill-down

Из агрегированного KPI пользователь должен дойти до причины.

Например:

returns -> category -> order.

Так аналитика помогает действию.

Data mart

Для аналитики можно создать витрину.

Например:

fact_orders
dim_customer
dim_time.

Но star schema нужна только если она упрощает реальные запросы.

ETL

Покажите:

extract -> validate -> transform -> load.

Разделите raw и cleaned layer.

Не исправляйте исходные данные без traceability.

Data lineage

Для важного показателя ответьте:

из каких полей он рассчитан?

Это особенно важно для финансовых и операционных dashboard.

Business rule

Например:

заказ считается просроченным после срока доставки, если status не delivered.

Правило должно быть одно и то же в:

• backend;
• report;
• documentation.

Не копируйте логику в трёх местах вручную.

Testing

Проверяйте:

• normal flow;
• invalid data;
• duplicate;
• access;
• integration failure.

Happy path недостаточен.

User acceptance test

Дайте пользователю выполнить задачу.

Измерьте:

• time;
• errors;
• completion.

Не пишите «интерфейс удобный» только по собственной оценке.

Security

Для бизнес-системы минимум:

• authentication;
• authorization;
• input validation;
• secrets;
• audit.

Роль пользователя должна проверяться в backend.

Audit

Для важной операции сохраняйте:

• actor;
• action;
• object;
• time.

Это особенно полезно в approval process.

Производительность

Если система должна поддерживать 100 пользователей, создайте соответствующий load scenario.

Измерьте p95.

Не используйте только average latency.

Reliability

Проверьте:

• external API timeout;
• DB unavailable;
• duplicate message;
• invalid file.

Система должна иметь предсказуемую реакцию.

Business effect

Сравните:

до
и
после.

Например:

lead time 26 часов -> 18 часов.

Но если это prototype без реального внедрения, не выдумывайте observed effect.

Используйте расчетный scenario.

Time saving

Если экономится 10 минут на 1000 операций:

10 000 минут.

Это высвобождаемая трудоёмкость.

Не переводите её автоматически в сокращение payroll.

Error reduction

Если automation убирает ручной transfer, можно сравнить error rate.

Это часто более надежный effect, чем финансовая оценка.

Практическая глава

Схема:

1. business problem;
2. As-Is;
3. baseline;
4. requirements;
5. To-Be;
6. data;
7. architecture;
8. prototype;
9. tests;
10. effect.

Контекст ВШЭ

В 2026 году «Бизнес-информатика» является отдельной программой НИУ ВШЭ и прямо соединяет бизнес и IT.

Поэтому курсовая особенно сильна, когда каждый технический компонент можно проследить до business requirement.

Защита

Будьте готовы показать:

• process map;
• requirement;
• data model;
• architecture;
• test;
• KPI;
• effect.

Сильная курсовая по бизнес-информатике в НИУ ВШЭ показывает, как цифровая система меняет конкретный бизнес-процесс и как это изменение можно проверить.