===== Типы пользователей ИС ===== ==== META-USER ==== Пользователь (META-USER) - принадлежит ShariX, но у сервиса могут быть локальные пользователи (этот пользователь все равно дублируется с пустой структурой и флагом IS_GLOBAL на платформе). Зарегистрирован в системе. META-USER - базовая единица пользователя платформы, на которую могут быть назначены дополнительные права в соответствии с иными ролями. В зависимости от дополнительных прав на основе этого пользователя могут получаться как клиенты, так и исполнители, так и ответственные лица. Управление загруженными документами в собственном профиле. Изменение параметров собственного бронирования. Отправка запроса на установление взаимоотношений с организацией-партнером. Отправка запроса на установление взаимоотношений с сервисом. Ввод карты для снятия денег. ИС любого сервиса состоит из следующих уровней: * уровень платформы (PLATFORM-*) - не является сервисом вообще, а часть нашего программного продукта, которая обладает описанными свойствами, которые надо указывать ровно для того, чтобы оно с ней дружило. Юридический смысл - поставщик ПО. * уровень сервиса (METASERVICE-*). Юридический смысл - агент по конкретному виду услуг. (Например, сервис каршеринга). Устанавливает возможные профили услуг (схемы тарифов). * уровень партнера сервиса (PARTNER-*). Юридический смысл - компания, предоставляющая услугу, которой управляет сервис. Выбирает актуальные для организации схемы тарифов из доступных в вышестоящем сервисе, устанавливает цифровые значения тарифов. На каждом уровне (платформа, сервис, партнер) могут быть вспомогательные пользователи следующего вида: ==== Администратор статических процессов ===== Администратор статических процессов (*-ADMIN) - ответственное лицо организации перед уровнем выше (если есть). Организация - это структура в БД, которая не имеет своего отдельного аккаунта для входа. К ней назначается ответственный - админ, который представляет ее интересы. Он назначает любые иные права внутри организации, либо удовлетворяет запросы на них. Имеет доступ к статистическим и финансовым показателям, отчетности, просмотр данных по существующим договорам. Регистрирует организации на 1 уровень ниже и назначает ответственных в них. Управляет статусом доступности организаций на 1 уровень ниже. Устанавливает взаимоотношения или подтверждает запросы на взаимоотношения с организациями на 1 уровень ниже в случае их наличия в системе (юридический смысл - подписание договора). Управление тарифами (в рамках уровня). Изначально админ регистрирует организацию и предоставляет документы на уровень выше (если есть), подтверждающие право его представления организации. Если такое ответственное лицо от организации меняется - это происходит методом ручных обработок заявок ответственными на уровень выше (если есть). ==== Модератор динамических процессов ==== Модератор динамических процессов (*-SUPERVISOR) - ответственное лицо (может быть несколько) за функционирование организации. Выдает подтверждения на спецправа сотрудникам колл-центра и техподдержке при обработке заявок и ситуаций, назначает любые права внутри организации, помимо равных ему и админа. Управление статусом доступности организаций, стоящих на ступень ниже (модератор платформы - сервисами, модератор сервисов - партнерами, партнеры - связью с исполнителями (если предусмотрено смыслом сервиса)) ==== Сотрудник (оператор) call-центра ==== Сотрудник (оператор) call-центра (*-SUPPORT) - информационная обработка поступающих заявок, внесение изменений при удовлетворении запроса соответствующим его уровню *-SUPERVISOR. Взаимодействие с пользователями, которые имеют право обратиться. Операторы колл-центра внутри организации оказывают поддержку только в зоне ответственности функционирования организации, при несоответствии запросов отправляют заявку на 1 уровень выше или ниже. ==== Техподдержка (*-TECHSUPPORT) ==== Техподдержка (*-TECHSUPPORT) - физическая обработка заявок без непосредственного взаимодействия с пользователями (обработка ошибок ПО, оборудования или иных физических проявлений ошибок), при наличии на то прав/задания, подтвержденного модератором динамических процессов. ==== Исполнитель (PROVIDER) ==== Исполнитель (PROVIDER) - зарегистрированный пользователь, способный осуществлять заказы. ==== Клиент (CLIENT) ==== Клиент (CLIENT) - зарегистрированный пользователь, способный делать заказы. ==== Гость ==== ГОСТЬ - незарегистрированный пользователь с самым минимальным уровнем прав, достаточных только для ознакомления/просмотра с услугами, но не дающие ему возможности для пользования таковыми. Пользователь может отправить заявку на регистрацию. ===== Сценарии и возможности ===== ==== METASERVICE-ADMIN ==== представление интересов сервиса перед платформой: * получение и отправление отчетности по взаимодействию с партнером (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки) * получение и отправление отчетности по взаимодействию с платформой (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки) * получение информации по выплатам (текущая сводная информация по заявкам и статусам накапливаемой оплаты) (так как взаиморасчет раз в неделю) * указание счета для финансовых поступлений * загрузка и удаление документов, подтверждающих право оказания услуг * создание схем услуг в рамках сервиса (ST_REQUEST админу платформы) * (metaservice_roles) назначение любых прав (кроме своего уровня) внутри организации, удовлетворение запросов на них (ACCESS_REQUEST) (назначение - создание заявки за другого пользователя и тут же ее удовлетворение с точки зрения процесса, в системе хранится лог заявки) * (partner_activation) активация и деактивация аккаунтов партнеров (заключение и расторжение договора) (статусы ACTIVE/CHECK/BLOCKED в любых комбинациях) (обработка заявки NEG_REQUEST) * (metaservice_partner_docs) управление статусами проверки актуальности документов, загруженных пользователями внутри организации (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы) * (metaservice_partner_docs) управление статусами проверки актуальности документов, загруженных партнерами для установления взаимоотношений (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы) * назначение ответственного в организации-партнере (удовлетворение запроса - реализуется через базовые механизмы META-USER по удовлетворению заявок, направленных пользователю) (назначение - создание заявки за другого пользователя и тут же ее удовлетворение с точки зрения процесса, в системе хранится лог заявки, необходимо подтверждение назначаемого, без него организация неактивна или действует под управлением предыдущего назначенного, если он был) * Обработка заявок, назначенных на себя (ASSIGNED) ==== METASERVICE-SUPERVISOR ==== * (operational_control_extra) Удовлетворение или отмена заявок на получение дополнительных прав пользователей в рамках операции по заявке (например, ЧТО - надо перечислить все сценарии) (изменение статуса ACCESS_REQUEST) * (operational_control) Управление статусами заявок (ST_REQUEST) с доступными правами (кроме заявок админа) внутри организации, создание и комментирование заявок любого типа, назначенных на любого пользователя внутри организации * (activity_control) Управление статусами активности пользователей внутри организации, кроме админа и пользователей с аналогичными правами (только переключение между ACTIVE и CHECK, отправка запроса на подтверждение BLOCKED) (это частный случай обработки ST_REQUEST) * (access_control) Управление правами пользователей внутри организации, кроме админа и пользователей с аналогичными правами (это действие обработки заявки ST_REQUEST или действие назначения) (ПРОВЕРИТЬ ТИП ЗАЯВКИ) * (metaservice_partner_docs) Управление статусом проверки документов партнеров PARTNER-ADMIN (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы) * Обработка заявок, назначенных на себя (ASSIGNED) ==== METASERVICE-SUPPORT ==== информационная обработка поступающих заявок: * (service_request) чтение заявок NEW и переназначение на другого специалиста внутри организации, а также перенос на уровень партнера или платформы (ASSIGNED), обработка (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE) * (service-inbox) заведение заявок в системе при обработке звонков и чатов * прием входящих перенаправленных другими операторами звонков от платформы и партнеров * (service-inbox) прием сообщений в чате (чат сразу сделать формой заявки и продолжающимися комментариями) * отправка запросов ACCESS_REQUEST на уровень METASERVICE_SUPERVISOR (тут кстати вопрос - при удовлетворении доступа изменения вносит запросивший или подтвердивший?) Зона ответственности - работа программного обеспечения на уровне сервиса (ПО по управлению доступа к автомобилям), договорные отношения на уровне сервиса. ==== METASERVICE-TECHSUPPORT ==== (service-inbox-tech) * Техническая обработка поступающих заявок (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE) * Запрос на получение доступа к автомобилям партнеров при необходимости в результате обработки поступающих заявок * Взаимодействие с ресурсами партнеров при наличии доступа Зона ответственности - работа программного обеспечения на уровне сервиса (ПО по управлению доступа к автомобилям). ==== PARTNER-ADMIN ==== представление интересов организации перед сервисом: * получение и отправление отчетности по взаимодействию с сервисом (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки) * получение и отправление отчетности по взаимодействию с платформой (счета и акты по оказанным услугам, счета и акты по услугам агента, акты сверки) * получение информации по выплатам (текущая сводная информация по заявкам и статусам накапливаемой оплаты) (так как взаиморасчет раз в неделю) * указание счета для получения финансовых поступлений * загрузка и удаление документов, подтверждающих право оказания услуг * активация и деактивация действующих схем услуг * назначение и изменение тарифов внутри выбранных действующих схем услуг (ST_REQUEST админу сервиса) * (partner_roles) назначение любых прав (кроме своего уровня) внутри организации, удовлетворение запросов на них (назначение - создание заявки за другого пользователя и тут же ее удовлетворение с точки зрения процесса, в системе хранится лог заявки) * (provider_docs, resource_docs) управление статусами проверки актуальности документов, загруженных пользователями внутри организации (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы) * активация и деактивация допущенных к управлению водителей (DRIVER) (заключение и расторжение договора) (статусы ACTIVE/CHECK/BLOCKED в любых комбинациях) (это действие обработки заявки ST_REQUEST или действие назначения) * Обработка заявок, назначенных на себя (ASSIGNED) ==== PARTNER-SUPERVISOR ==== * (service_request_edit) Удовлетворение или отмена заявок на редактирование заявок/бронирований (ACCESS_REQUEST в отношении изменения SERVICE_REQUEST) (должен быть автоаппрув на уровень выше, если такая опция есть у партнера) * (operational_control_extra) Удовлетворение или отмена заявок на получение дополнительных прав пользователей в рамках операции по заявке (например, на открытие автомобиля в технических целях - надо перечислить все сценарии) (изменение статуса ACCESS_REQUEST) * (operational_control) Управление статусами заявок (ST_REQUEST) с доступными правами (кроме заявок админа) внутри организации, создание и комментирование заявок любого типа, назначенных на любого пользователя внутри организации * (activity_control) Управление статусами активности пользователей внутри организации, кроме админа и пользователей с аналогичными правами (только переключение между ACTIVE и CHECK, отправка запроса на подтверждение BLOCKED) (это частный случай обработки ST_REQUEST) * (access_control) Управление правами пользователей внутри организации, кроме админа и пользователей с аналогичными правами (это действие обработки заявки ST_REQUEST или действие назначения) (проверить тип заявки) * (provider_docs, resource_docs) Управление статусом проверки документов исполнителей и ресурсов (переключение с NEW на OK или с NEW на ERROR, или OK на ERROR) (это обработка ST_REQUEST и изменение статуса документа, если документ глобальный - с предупреждением, что в случае ошибочной деактивации документа ответственность на деактивировавшем, и предлагается выполнить действие без влияния на документы, либо можно отправить запрос на уровень платформы) * Обработка заявок, назначенных на себя (ASSIGNED) ==== PARTNER-SUPPORT ==== Важно: в концепции предполагается, что сопровождением заказов сервиса занимается сервис, а не партнер. (partner-inbox) информационная обработка поступающих заявок: * чтение заявок NEW и переназначение на другого специалиста внутри организации, а также перенос на уровень сервиса (ASSIGNED), обработка (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE) заведение заявок в системе при обработке звонков и чатов * прием заявок от пользователей по телефону * перенаправление звонков на уровень выше * прием сообщений в чате (чат сразу сделать формой заявки и продолжающимися комментариями) * отправка запросов ACCESS_REQUEST на уровень PARTNER_SUPERVISOR (тут кстати вопрос - при удовлетворении доступа изменения вносит запросивший или подтвердивший?) Зона ответственности - работа программного обеспечения на уровне автомобиля (ПО по управлению доступа к автомобилям), договорные отношения на уровне партнера, управление доступностью ресурсов, обработка первичных заявок клиентов. ==== PARTNER-TECHSUPPORT ==== (partner-inbox-tech) * Техническая обработка поступающих заявок (IN PROGRESS->DONE) или закрытие без выполнения (WONTFIX, DUPLICATE) * Запрос на получение доступа к автомобилям внутри организации при необходимости в результате обработки поступающих заявок * Взаимодействие с автомобилями внутри организации при наличии доступа Зона ответственности - работа программного обеспечения на уровне автомобиля (ПО по управлению доступа к автомобилям). ==== PROVIDER ==== * Использование ресурсов, осуществление заказов, формирование предложений конкретных услуг (если предусмотрено сервисом), в целом - обычный пользователь, если не требуется чего-то иного. ==== CLIENT ==== * Оставление заявок на заказы, в целом - обычный пользователь, если не требуется чего-то иного. Отличается от обычного пользователя тем, что согласился с условиями определенного договора. ==== GUEST ==== * Регистрация * Просмотр страниц с публичными документами * Просмотр страниц с публичным описанием платформы и сервиса