astana_hub - Technical tasks - Страница 8

Создание платформы для бэк офиса

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. Коммерческая часть Стоимость работ определяется после обсуждения, уточнения требований и рассмотрения заявки подрядчика. Подрядчик должен предложить смету по этапам и условия сопровождения.

Technological tasks

The Tech-tasks module is tasks related to the development, implementation and improvement of new technologies, products and processes. If you have development, implementation and other needs you can post information below.

Разработка плагина для iiko

Заказчик

LoyaBonus.app

Модуль защиты бюджета

Заказчик

I-CON Digital

Определение спроса на беспилотные авиационные системы с грузоподьемностью до 5кг в гражданском секторе

Заказчик

TOO WSE

Разработка системы интеллектуального контроля качества работы сотрудников клиники

Заказчик

ТОО DIGITAL CLINIC HUB

Создание унифицированного интеграционного слоя (Integration Gateway / Digital Core)

Заказчик

ТОО DIGITAL CLINIC HUB

Разработка алгоритма интеллектуальной оптимизации маршрута пациента в медицинской клинике (Протокол)

Заказчик

ТОО DIGITAL CLINIC HUB

Создание нейронной сети для обработки и анализа данных клиентов медицинских клиник

Заказчик

ТОО DIGITAL CLINIC HUB

Создание интегрируемого SaaS-решения для отслеживания и анализа звонков колл-центра в цифровой медицинской системе

Заказчик

ТОО DIGITAL CLINIC HUB

Создание платформы для бэк офиса

Заказчик

ТОО DIGITAL CLINIC HUB

Автоматизация и оптимизация внутренних процессов

Заказчик

Alem School