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

1. Общая цель и контекст проекта Нужно создать единую внутреннюю платформу для бэк-офиса компании (административный контур), которая заменит разрозненные таблицы, чаты и ручные согласования. Платформа должна собрать в одном месте задачи, документы, заявки, бюджеты, платежи, статусы и контроль исполнительской дисциплины. Главная ценность: прозрачность, управляемость, контроль сроков и денег, снижение хаоса и “потери” задач между людьми и подразделениями. 2. Что считается “бэк-офисом” в рамках платформы Внутренние подразделения и функции, которые обслуживают основной бизнес: финансы/оплаты, закуп/счета, договора, маркетинг-операции, подрядчики, управление персоналом-админ, он/доступы, юридические согласования, контроль бюджета, календарь встреч/обязательств, контроль КПЭ/отчетности. Важно: платформа не для пациентов/клиентов, а для сотрудников компании. 3. Основные пользователи и роли Необходимое распределение ресурсов (RBAC). Минимальные роли: Администратор системы (создает роли, доступы, настройки). Руководитель (видит отчеты, бюджеты, статусы всех задач, утверждает заявки). Менеджер/координатор (создает и ведет заявки, задачи, документы). Исполнитель (получает задачи, сдает результат, прикрепляет файлы). Финансист/бухгалтерия (обрабатывает оплаты, счета, статусы оплат). Юрист (согласование договоров, правки, статусы). Маркетинг-оператор (размещение материалов, контроль подрядчиков). IT-специалист (покупки, интеграция, поддержка). Опционально: внешний подрядчик (ограниченный доступ только к своим задачам/файлам). 4. Ключевые проблемы, которые платформа должна решить Заявки и задачи теряются в мессенджерах и устных договоренностях. Нет единого источника правды по статусам: кто делает, какой срок, что согласовано. Бюджеты “переваливают” или “недокручиваются” без контроля. Нет прозрачного процесса согласования счетов и оплат. Нет единого архива договоров/документов с версиями и комментариями. Нет системной фиксации встреч, обязательств и дедлайнов (в календаре и в задачах). Сложно понять нагрузку по команде и контроль исполнения. 5. Модули платформы (что должно быть внутри) 5.1. Модуль “Заявки” (единый вход) Это основа. Любая потребность в бэк-офисе оформляется как заявка. Типы заявок: Оплата/счет (поставщик, сумма, дедлайн, основание). Закуп/заказ (что купить, сколько, где, кому нужно, срочность). Договор/юридическое согласование (контрагент, предмет, версия файла). Маркетинг-заявка (креатив, размещение, тексты, дизайн, сроки). ЭТО-заявка (стойки, настрой, интеграции, баги). HR-заявка (предложения, документы, увольнение). Каждая заявка имеет: номер, автора, подразделение, приоритет, дедлайн, ответственного, статус, чек-лист, файлы, комментарии, историю изменений. Статусы: “Новая” → “В работе” → “На согласовании” → “Ожидает оплаты/выполнения” → “Выполнено” → “Закрыто”. Плюс: “Отклонено” и “Возврат на доработку”. 5.2. Модуль “Задачи” (исполнение) Из заявки автоматически создаются задачи по шагам и назначаются исполнителям. Поддержка зависимостей (задача Б после задачи А). Подзадачи, чек-листы, вложения, комментарии. Напоминания и просрочка. Сдача результата: обязательное поле “что сделано” + приложить файл/ссылку. Возможность “вернуть на доработку” с причиной. 5.3. Модуль “Финансы и оплаты” Реестр счетов и оплат: Карточка счета: контрагент, реквизиты, сумма, валюта, назначение, проект/филиал, статья бюджета, дедлайн оплаты, файл счета, договор/основание, кто согласовал. Статусы: “Получен” → “На согласовании” → “Согласован” → “Оплачен/В оплате” → “Закрыт”. Контроль бюджета: фиксируем “план” и “факт”, отклонения, причины. Важная логика: нельзя отправить “в оплату” без обязательных полей (основание/документы/согласование). Обзор в Excel/CSV. 5.4. Модуль “Бюджеты и лимиты” Бюджеты по: месяцу, проекту, филиалу, статье расходов, ответственному. Лимитирование: если заявка/счет превышает лимит, система требует дополнительного согласования (например, руководитель/фин директор). Поля: план, фактические траты, остаток, прогноз (по заявкам “в работе”). Отчет “перевалили/недокрутили бюджет”. 5.5. Модуль “Документы и договоры” Единый архив: договоры, допсоглашения, счета, акты, ТЗ, референсы. Версионность: новая версия файла не затирает старую. Маркировка статусов: “Черновик”, “На согласовании”, “Подписан”, “Истек/закрыт”. Поиск по названию/контрагенту/дате/проекту. Права доступа по ролям. 5.6. Модуль “Календарь и встречи” Смотреть онлайн бесплатно и/или синхронизироваться с Google Календарем. Обязательные поля: тема, участники, дата/время, цель, список обязательств по итогу. Автоматическое превращение “обязательств” в задачи с дедлайнами. Отдельный раздел “обязательства руководителю/команде” для контроля. 5.7. Модуль “Отчетность и дашборды” Для руководства: Сводка по заявкам (сколько новых/в работе/просрочено). Сводка по оплатам (ожидает согласования, в оплате, оплачено). Бюджет план/факт по периодам. Нагрузка по сотрудникам (сколько задач, просрочка, средний срок закрытия). Фильтры: город/филиал/проект/тип заявки/ответственный/период. 5.8. Модуль “Коммуникации внутри задач” Комментарии, упоминания @, уведомления. Шаблоны сообщений: запрос уточнения, согласование, возврат на доработку. История активности: кто что изменил и когда. 6. Бизнес-логика и правила Приоритеты: низкий/средний/высокий/срочно. Соглашение об уровне обслуживания: для краткого ознакомления — обязательное подтверждение участия в работе. Описание: либо фраза "час/день — руководство". Контроль качества: закрыть задачу можно только при заполненном “результате” и приложенном файле/ссылке (если тип задачи это требует). Обязательные поля зависят от типа заявки. Заявка “Оплата” не может перейти в “Согласован” без прикрепленного счета + основания (договор/акт/ТЗ). 7. Интеграции (желательно, но прописываем как требования) Рабочее пространство Google: Google Calendar (просмотр). Google Drive (просмотр файлов, или внутреннее редактирование). WhatsApp: Пользовательский пароль/кнопка “подписаться в WhatsApp” для внутреннего доступа не обязательно, но и для общения в WhatsApp можно как онлайн (если есть API/браузер). Электронная почта: знакомство со статусом, согласие. CRM/администратор/регистратор (если у вас есть) — возможно, как вариант 2, но не для того, чтобы увидеть “готовый к использованию API” интерфейс. 8. Нефункциональные требования Веб-версия обязательна, адаптив под мобильный желателен. Скорость: загрузка страниц до 2–3 секунд при обычной нагрузке. Надежность: логирование ошибок, бэкапы. Безопасность: роли, права, журналы аудита, защита данных. Хранение данных: база данных + файловое хранилище. Локализация <url> (мнимум), Казахстан онлайн. 9. Техническая архитектура (можно как рамки) Интерфейс: web (React/Vue — на выбор сторонника). Интерфейс: REST API. База данных: PostgreSQL/MySQL. Файлы: S3-объемные файлы или интеграция с Google Диском. Авторизация: JWT + роли, либо единый вход в Google Workspace. 10. Этапы внедрения (чтобы подрядчик понимал объем) Этап 1 (MVP, 4-8 матчей подряд): заевки + задачи + деловые роли + знакомство + хайлы. Этап 2: финансы/счета + бюджеты + согласования. Этап 3: документы/договоры + календарь + расширенная аналитика. Шаг 4: интеграция с другими системами (CRM/колл-центр/администратор). 11. Что вы хотите получить от разработчика в ответ на ТЗ Оценка сроков по этапам. Оценка стоимости по этапам (или диапазон). Предложенная архитектура и стек. Маркет-кранов или прото-тип (Figma) на ключевые слова. План внедрения и обучения пользователей. Категория поддержки после игры (SLA, багики, доработки). Уточнение по хостингу и владению кодом. 12. Коммерческая часть Стоимость работ определяется после обсуждения, уточнения требований и рассмотрения заявки подрядчика. Подрядчик должен предложить смету по этапам и условия сопровождения.