CRM для некоммерческого фонда в дипломе: архитектура учёта подопечных и метрики эффективности
В конце марта 2026 года компания «Норбит» отчиталась о завершении очередного этапа развития CRM-системы благотворительного фонда «Хранители детства». Речь не о косметических правках интерфейса: в фонде выстроили единый контур работы с подопечными, волонтёрами и жертвователями, а сама система перестала быть «записной книжкой» и превратилась в рабочий инструмент с отчётностью и разграничением доступа. Для выпускника ИТ-направления это готовый, подтверждённый отраслью сценарий: некоммерческий сектор сегодня цифровизуется теми же средствами, что ритейл или банки, только с жёсткими ограничениями по бюджету и по работе с персональными данными. Если вы ищете тему, где видно и анализ предметной области, и проектирование, и измеримый результат внедрения, — этот кейс стоит разобрать внимательно.
Три темы ВКР, которые вырастают из этого кейса
Тема 1. Проектирование CRM-системы учёта благополучателей для некоммерческой организации
- Актуальность: фонды и НКО переходят от разрозненных таблиц к единым учётным системам — тренд, который статья «Норбит» фиксирует как завершённый проект, а не как эксперимент.
- Цель: разработать архитектуру и прототип CRM, обеспечивающей полный жизненный цикл обращения подопечного и прозрачную отчётность для грантодателей.
- Задачи: анализ бизнес-процессов фонда и их формализация в BPMN 2.0; проектирование модели данных; реализация ролевой модели доступа (RBAC); расчёт экономии трудозатрат после внедрения.
- Структура: Глава 1 — обзор рынка CRM и специфики НКО, требования по 152-ФЗ; Глава 2 — архитектура, ER-модель, диаграммы последовательностей, интеграционные сценарии; Глава 3 — тестирование, метрики, оценка эффекта.
Тема 2. Интеграция CRM с внешними сервисами сбора пожертвований и государственными информационными системами
- Актуальность: доработка CRM в фонде почти всегда означает стыковку с платёжными шлюзами, порталами и сервисами отчётности — именно эта часть даёт основную сложность и основную ценность.
- Цель: спроектировать слой интеграций, устойчивый к сбоям внешних поставщиков.
- Задачи: описать контракты REST API и webhook-сценарии; реализовать идемпотентную обработку платежей; настроить очереди повторной доставки; оценить RTO/RPO.
- Структура: Глава 1 — протоколы и стандарты обмена; Глава 2 — схема интеграционной шины, диаграмма компонентов; Глава 3 — нагрузочное тестирование и разбор инцидентов.
Тема 3. Аналитическая подсистема оценки эффективности работы фонда на данных CRM
- Актуальность: система собрана, данные копятся — но без витрин и дашбордов они не превращаются в решения. Кейс «Норбит» показывает, что заказчик ждёт от CRM управленческой аналитики, а не только карточек.
- Цель: построить подсистему отчётности с набором измеримых показателей по модели качества ISO/IEC 25010.
- Задачи: определить перечень метрик (SLA, конверсия заявок, стоимость привлечения жертвователя); спроектировать витрину данных; реализовать SQL-представления и дашборд; валидировать расчёты на тестовом наборе.
- Структура: Глава 1 — методы оценки эффективности ИС; Глава 2 — модель хранилища, ETL-поток; Глава 3 — проверка метрик и интерпретация результатов.
Аналитическая глава: чем обосновывать выбор платформы, а не «мне так удобнее»
Самое слабое место дипломов по CRM — обоснование. Комиссия редко спорит с выбором, но почти всегда спрашивает: почему не готовая коробка, почему не low-code, считали ли вы совокупную стоимость владения. Готовьте ответ заранее и подкрепляйте сравнительной таблицей.
| Вариант реализации | Срок внедрения | Гибкость под процессы НКО | Что реально защитить в ВКР |
|---|---|---|---|
| Готовая коробочная CRM | 2–6 недель | Низкая, кастомизация через настройки | Анализ требований, план миграции данных, расчёт TCO |
| Low-code платформа | 3–8 недель | Средняя, ограничена вендором | Модель процессов, регламенты, оценка производительности |
| Собственная разработка (Python/Django, PostgreSQL) | 3–6 месяцев | Высокая | Архитектура, схема БД, API, тесты, развёртывание |
| Доработка open-source решения | 6–12 недель | Средняя и высокая | Форки и патчи, вклад в upstream, оценка рисков поддержки |
К таблице добавьте строку с требованиями: какие данные относятся к персональным, кто имеет доступ к медицинским или социальным сведениям, как выполняется требование 152-ФЗ об уничтожении данных по достижении цели обработки. Это тот аргумент, который в гуманитарной предметной области весит больше, чем любая диаграмма.
Проектная часть: что рисовать и в каком порядке
Порядок такой: контекстная диаграмма → декомпозиция процессов → модель данных → компонентная схема → сценарии взаимодействия. Не наоборот. Если начать с компонентов, на защите спросят, откуда они взялись, и ответить будет нечего.
Формализация процессов
Опишите путь обращения подопечного в BPMN 2.0: регистрация, проверка документов, назначение куратора, оказание помощи, закрытие дела, архивирование. Ровно те же шаги потом станут состояниями сущности в базе — это удобно показать одним слайдом.
Данные и доступ
Минимальный набор сущностей: подопечный, обращение, куратор, волонтёр, жертвователь, платёж, документ, история изменений. Ролевую модель стройте не «по должностям», а по операциям: кому видно поле, кому — только факт наличия записи, кто может выгрузить отчёт. Журнал аудита внесите в требования сразу, иначе его придётся прикручивать к готовой схеме.
Интеграции
Типовой набор для фонда: платёжный шлюз, почтовый сервис, сервис рассылок, внешнее файловое хранилище, sometimes 1С для бухгалтерии. Каждую стыковку оформляйте как отдельный контракт с описанием формата, частоты обмена и поведения при ошибке.
POST /api/v1/donations
Idempotency-Key: 8f14e45f-c0a1-4b3e-9d21-77aa10cc9b04
{
"donor_id": 10432,
"amount": 5000.00,
"currency": "RUB",
"purpose": "program_children_support",
"paid_at": "2026-03-24T18:41:12+03:00"
}
Тестирование, метрики и то, что обычно забывают посчитать
Раздел тестирования чаще всего сводится к фразе «система работает корректно». Так писать нельзя. Нужны числа, воспроизводимые методики и указание инструментов.
- Функциональное покрытие: сколько тест-кейсов, сколько пройдено, какие дефекты остались открытыми и почему это допустимо.
- Нагрузка: k6 или JMeter, профиль из 200 одновременных пользователей, время отклика 95-го перцентиля, поведение при пиковой нагрузке в день сбора пожертвований.
- Надёжность: RTO и RPO, проверка восстановления из резервной копии, сценарий отказа интеграции с платёжным шлюзом.
- Наблюдаемость: метрики, логи, трассировки — стандарт OpenTelemetry позволяет не изобретать формат и корректно сослаться на него в тексте.
Для аналитической темы пригодятся расчёты прямо в SQL — их удобно вынести в приложение и показать комиссии, что метрики не выдуманы:
-- Доля обращений, закрытых в срок (упрощённо)
SELECT date_trunc('month', closed_at) AS period,
round(100.0 * count(*) FILTER (WHERE closed_at <= due_at)
/ count(*), 1) AS sla_percent
FROM cases
WHERE closed_at IS NOT NULL
GROUP BY 1
ORDER BY 1;
Отдельно проговорите, как метрики соотносятся со стандартом ISO/IEC 25010: производительность, надёжность, удобство использования, защищённость. Это снимает вопрос «а почему вы выбрали именно эти показатели».
- Подмена понятий «коробка / low-code / собственная разработка» без обоснования. Выбирайте вариант после сравнительной таблицы с критериями, а не до неё. Критерии: срок, стоимость, требования по хранению персональных данных, наличие поддержки.
- Отсутствие измеримых метрик эффективности. «Стало удобнее» — не результат. Результат: сокращение времени обработки заявки с 40 до 12 минут, снижение доли ручных операций на 60%, стоимость владения за три года.
- Игнорирование требований ГОСТ 34.602-89 при оформлении технического задания. ТЗ оформляется по структуре стандарта, со ссылками на разделы; произвольная форма вызывает вопросы у нормоконтроля.
Чему вы научитесь на такой работе
- Обследовать предметную область, где нет готового технического задания, и превращать интервью с заказчиком в требования.
- Обосновывать стек и архитектурный стиль через критерии, а не через личные предпочтения.
- Проектировать схему данных так, чтобы к ней потом добавлялись аудит, роли и отчётность, не ломая ядро.
- Описывать интеграции контрактами и обрабатывать отказы внешних сервисов.
- Считать метрики и оформлять результаты так, чтобы они читались и в тексте ВКР, и на защите.
Вопросы, которые студенты задают чаще всего
Обязательно ли писать код, если тема про CRM-систему?
Не всегда, но должен быть артефакт: прототип, схема базы с работающими скриптами, набор SQL-представлений для отчётности или модуль интеграции. Чисто описательная работа защищается тяжелее — комиссии нечего проверить руками.
Где брать тестовые данные, если речь о подопечных фонда?
Ни в коем случае не реальные. Генерируйте синтетический набор скриптом: ФИО-заглушки, случайные даты, суммы, статусы. Такой генератор сам по себе становится приложением к работе и снимает вопросы по 152-ФЗ.
Как оформить UML-диаграммы, чтобы их приняли?
Единый нотационный стиль по всей работе, подписи на русском, ссылки на диаграммы из текста («на рисунке 12 представлена…»), читаемый шрифт при печати. Диаграммы компонентов и последовательностей стройте из одной модели — расхождения между ними замечают сразу.
Насколько сложно защитить тему, если система внедрена не у вас?
Внедрение в чужом фонде — это ваш кейс-анализ, а не ваш проект. Формулируйте вклад честно: реверс-инжиниринг процессов, спроектированная архитектура, прототип, расчёты. Такой подход защищается спокойно, если цели и выводы согласованы между собой.
- Цель работы и выводы в заключении совпадают дословно по смыслу, а не «примерно».
- Каждая задача из введения имеет свой раздел с результатом.
- ТЗ оформлено по структуре ГОСТ 34.602-89, ссылки на стандарт указаны корректно.
- Есть минимум одна сравнительная таблица обоснования выбора решения.
- Есть схема данных, схема компонентов и хотя бы один сценарий взаимодействия.
- Метрики эффективности приведены с единицами измерения и методикой расчёта.
- Тестовые данные синтетические, реальные персональные данные не используются.
- Список источников оформлен единообразно, ссылка на отраслевой кейс присутствует.
Источник: «Норбит» завершила доработку CRM для фонда «Хранители детства» (опубликовано 2026-03-25)