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

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