Партнерка на США и Канаду по недвижимости, выплаты в крипто
- 30% recurring commission
- Выплаты в USDT
- Вывод каждую неделю
- Комиссия до 5 лет за каждого referral
Оглавление
1. Общее описание проекта
1.1. Предпосылки проекта
1.2. Задачи проекта
1.3. Описание логической структуры портала
2. Функциональные требования
2.1. Раздел « Управление знаниями»
2.1.1. Краткое описание функционала
2.1.2. Структура данных
2.1.2.1. Метаданные
2.1.2.2. Теги
2.1.2.3. Категории записей БЗ
2.1.3. Поисковые представления
2.1.3.1. Представление «Многоуровневый справочник»
2.1.3.2. Дерево тегов
2.1.3.3. Дерево глобальных представлений
2.1.4. Уведомления об изменениях в БЗ
2.1.5. Связанные записи БЗ
2.1.6. Пользователи и доступ к записям в БЗ
2.1.7. Верификация записи перед публикацией
2.2. Раздел «Управление коммуникациями»
2.2.1. Вертикальные коммуникации(замена InfoNetwork)
2.2.2. Горизонтальные коммуникации
2.3. Раздел «Отчетность»
2.3.1. Отображение отчетов
2.4. Раздел «Задачи»
2.4.1. Структура задачи
2.4.2. Подзадачи и этапы задач
2.4.3. Действия над задачей
2.4.4. Контроль выполнения задач и уведомления
2.4.5. Доступ к задачам
2.4.6. Ведение истории изменений
2.5. Раздел «Сервисные функции»
2.6. Общие функциональные требования
2.6.1. Поиск
2.6.1.1. Поисковый запрос
2.6.1.2. Дополнительные механизмы поиска
2.6.1.3. Повышение удобства поиска
2.6.2. Медиа-содержимое
2.6.3. Объединение сущностей
2.6.4. Нотификация
2.6.5. Ведение лога действий пользователей и статистики
2.6.6. Доступ к другим веб-базированным системам Банка в окне Портала
2.6.7. Экспресс-опрос
2.6.8. Календарь
2.6.9. Новостные блоки
2.6.10. Форматы файлов
2.6.11. Авторизация
2.6.12. Бизнес-администрирование
3. Нефункциональные требования
3.1. Права пользователей в системе
3.2. Требования к программной и аппаратной части
3.2.1. Технологическая платформа
3.2.2. Веб-сервер
3.2.3. Сервер баз данных
3.2.4. Рабочее место пользователя
3.3. Доступность системы
3.4. Языковые версии
4. Оценить опционально
4.1. Адаптация под планшетные устройства
4.2. Автономная работа
4.3. Интеграции
4.4. Поиск
2. Общее описание проекта
Проблема: разрозненность и не структурированность коммуникаций ГО и сети, сложности в получении необходимой (достоверной и актуальной) информации исполнителями, задействованными в процессе обслуживания розничных клиентов Банка.
1. Обеспечение эффективной двухсторонней коммуникации ГО с розничной сетью
2. Постановка и контроль выполнения бизнес-задач
3. Управления корпоративными знаниями, повышение уровня доступности информации, облегчения навигации и релевантности поиска за счет системы связей между знаниями
4. Реализация быстрого доступа к текущей отчетности для принятия управленческих решений
5. Упрощение управления инфраструктурой сети за счет автоматизации сервисных функций
3. Функциональные требования
NB! |
Все настройки и категории сущностей, описанные в этом разделе, являются предварительными. У бизнес-администратора должна быть возможность создавать/удалять/ редактировать их.
Данный документ верхнеуровнево описывает функционал, который должен быть реализован в Портале.
Под термином запись понимается оформленное в html-разметке тексто-графическое наполнение с приложенными файлами.
3.1.1. Краткое описание функционала
База знаний (БЗ) - совокупность программных средств, обеспечивающих создание, хранение, поиск и преобразование сложно-структурированной информации о процессах, продуктах и инструментах продаж Банка.
Переход к записям БЗ для ознакомления возможен из:
1. Поискового запроса
2. Поисковых представлений
3.1.2. Структура данных
3.1.2.1. Метаданные
Каждая запись в БЗ должна быть обогащена метаданными:
1. ID – назначается системой, должен быть виден пользователю и иметь числовое значение.
2. Автор.
3. Подразделение- владелец.
4. Дата внесения.
5. Дата изменения.
6. Перечень тегов.
7. Категория документа.
3.1.2.2. Теги
Реализовать тегирование записей БЗ.
К одной записи должно быть привязано более одного тега. Привязка тега к записи может(и должна) редактироваться редактором записи. Для управления тегами реализовать справочник тегов. Доступ к редактированию справочника должен быть только у бизнес-администратора.
3.1.2.3. Категории записей БЗ
В зависимости от смысловой нагрузки редактор записи должен присвоить ей одну из категорий. Предварительный список:
1. Выдержка из ВРД.
2. Скрипт.
3. Инструкция.
4. Подсказка.
5. Рекомендация.
6. Файл.
3.1.3. Поисковые представления
Кроме стандартного функционала поиска, описанного в п.2.6.1 «Поиск», должна быть возможность настроить представления с преднастроенной логикой поиска. Ниже представлены механизмы действия таких представлений, на базе которых должна быть возможность создавать различные «фильтры»(кроме «Дерева глобальных представлений» - он является самостоятельным представлением).
3.1.3.1. Представление «Многоуровневый справочник»
Реализовать механизм поиска данных в виде формирования каталогов неограниченной вложенности. Фактически, это должен быть многоуровневый справочник. При переходе на конкретный уровень справочника, в главном фрейме отфильтровываются все записи, что с ним связаны.
Структуру каталогов задает бизнес-администратор.
3.1.3.2. Дерево тегов
Дерево тегов должно формироваться на основании функционала «многоуровневый справочник», где к каждому уровню будет привязан тег или несколько тегов.
Т. о. при переходе на очередной уровень дерева:
1. в главном фрейме должны отфильтровываться записи, которые содержат как теги всех вышележащих уровней, так и теги текущего уровня.
2. Если в дереве не были настроены(бизнес-администратором) следующие подуровни, то в качестве их должны показаться теги, которые содержаться в найденных документах, за исключением всех вышележащих тегов.
3.1.3.3. Дерево глобальных представлений
Как и дерево тегов, дерево глобальных представлений связано с тегами на каждом своем уровне, но должно стоиться системой автоматически. Уровнями дерева должны быть категории глобальных представлений, причем подуровнями должны быть все категории, кроме той, что была указана в уровне дерева. Т. о. одна и та же запись БЗ может быть найдена в дереве глобальных представлений несколькими путями.
Макротег – связывающий под собой несколько тегов. Редактирование макротегов должно происходить в справочнике тегов только бизнес-администратором.
Категории глобальных представлений(макротеги):
1. Продукты.
2. Процессы.
3. Процедуры.
4. Проблемы/возражения клиентов.
5. Инструменты продаж.
6. Подразделение.
7. Информационные системы.
8. Новые – т. е. те, что созданы/отредактированы, например, в течении последней недели. Данный тег должен автоматически сниматься с записи по прошествии срока.
Дерево глобальных представлений должно быть динамичным. Под динамичностью дерева подразумевается автоматическое обновление его структуры в зависимости от наличия записей в БЗ с определенными тегами.
3.1.4. Уведомления об изменениях в БЗ
Реализовать механизмы информирования об изменениях в соответствии с п.2.6.1. Нотификация. Должна быть настройка уведомлений для конкретной сущности.
3.1.5. Связанные записи БЗ
Реализовать возможность связывать записи. Связь должна быть двусторонняя.
В конце страницы с записью БЗ должна быть выведена информация о связанных записях:
1. С этой записью также смотрели - перечень записей, которые наиболее часто просматривались другими пользователями в результате поиска по такому же поисковому запросу
2. Связанные записи – отображение ссылок на все связанные записи
3. Искать записи с тегами - вывести все теги записи в виде ссылок и по результату нажатия на каждый выводить все записи, которым присвоен этот тег
3.1.6. Пользователи и доступ к записям в БЗ
База знаний разрабатывается для нескольких категорий пользователей. Доступ к записям в БЗ должен настаиваться в соответствии с п.3.1. Права пользователей в системе. Таким образом по поисковому запросу могут быть найдены, но не выведены пользователю, записи к которым у него нет доступа.
3.1.7. Верификация записи перед публикацией
Должен быть настроен процесс верификации записи перед ее публикацией в БЗ. Для этого должен запускаться БП «Согласование документа».
Верхнеуровневый процесс публикации статей описан на диаграмме «Внесение статьи Альфа-вики TO BE».
3.2.1. Вертикальные коммуникации
Информационное сообщение является записью в определенном разделе Портала с назначенным механизмом Нотификации. Адресатом(получателем) сообщения может быть один получатель или группа получателей.
Информационные сообщения должны обладать параметрами:
1. Тема
2. Важность
3. Категория
4. Получатель/Группа получателей
5. Срок ознакомления
6. Экспресс-опрос
Принципы формирования и передачи информации должны осуществляться в соответствии с принятыми в Банке стандартами.
3.2.2. Горизонтальные коммуникации
Реализовать следующие средства коммуникации:
1. Блоги
2. Клубы по интересам
3. Чат/мгновенные сообщения
4. Форум
5. Нотификации
Функционал блогов должен не уступать блогам на технологиях Blogger или SharePoint. В блогах должна быть реализована «живая лента», фотогалереи, видеогалереи.
Клуб по интересам представляет собой блог с несколькими администраторами, которые могут вносить записи в блог и множеством пользователей, которые могут эти записи комментировать.
Должно быть реализовано отображение сетевой папки(для поиска файлов отчетов), а также функционал работы с документами формата MS Office 2003, MS Office 2007, MS Office 2010 во фрейме портала.
Предусмотреть наличие блога в этом разделе для фиксирования изменений в структуре сетевой папки отчетности.
Основная функциональность ограничивается настройкой разного вида отчетности и визуализации данных в MS Excel. В шаблоне предварительно должны быть настроены и отформатированы отчеты. Данные в файлы отчетов должны подтягиваться из файлов на сетевом ресурсе.
Реализовать мониторинг раздела «Отчетность» для вывода нотификации при появлении нового отчета.
Верхнеуровневый процесс публикации отчетов описан на диаграмме «Размещение отчетов TO BE».
3.3.1. Отображение отчетов
1. Реализовать flash-интерфейс для отображения отчетности по монетарной мотивации – флешка, которая на основании введенных данных будет рассчитывать величину мотивации
2. Рейтинги – в табличном виде в html-верстке с применением стилей выводит рейтинг с указанием, на сколько позиций изменилось положение в рейтинге, а также направление изменения(вверх/вниз). Исходные данные должны браться из xls-файла с готовым рейтингом. Т. е. функционал просто преобразует эксель-файл в информативный и стилизированный веб-интерфейс.
3.4.1. Структура задачи
Под задачей подразумевается типовая бизнес-задача для сотрудника розничной сети Банка.
Должны быть реализованы шаблоны типовых бизнес-задач:
1. Согласование документа – согласование может быть одним или несколькими людьми, в параллельном или последовательном сценарии
2. Утверждение платежа – процесс, базирующийся на «Согласовании документа» с возможностью просмотра на этапе фин. контроля счетов и балансов отделений в интернет-магазине(п.2.5. Раздел «Сервисные функции»)
3. Выполнение поручений – классический процесс «постановка задачи – исполнение»
Реализовать возможность проставления связи между задачами.
Задача в общем случае предусматривает:
1. Тема
2. Текст
3. Важность
4. Инициатор
5. Группа исполнителей
6. Срок
7. Статус выполнения по каждому исполнителю
8. Вложения
9. Связанные задачи
3.4.2. Бизнес-правила и диаграммы
Бизнес-правила:
1. «Мой руководитель» позволит автоматически внести в лист утверждения непосредственного руководителя автора документа
2. «Выбор исполнителя по должности» - определить сотрудника, занимающего в данный момент заданную должность в определенном подразделении.
3. «Делегирование»:
a. предварительное согласование - при согласовании документа руководитель может передать документ своему заместителю на предварительное согласование, а только после этого наложить свою резолюцию.
b. полное – передать обязанность выполнения другому пользователю
c. заместитель - на время отсутствия все задачи падают на другого пользователя
4. «Главный согласователь» - при параллельном согласовании один из Согласователей может иметь право «главного солгасователя», после визы которого система не ждет остальных согласований
5. «Перенос сроков» - у исполнителя конкретного этапа работ должна быть возможность перенести срок выполнения этапа работ. При этом инициатор БП должен быть уведомлен.
6. «Право руководителя» - пользователь с правами руководителя может просматривать задачи(включая закрытые) подчиненных и инициировать дополнительные работы по задаче, в т. ч. возвращать задачу назад.
Диаграммы некоторых процессов описаны в Приложении 1: «Согласование документа/счета – параллельное - TO BE», «Согласование документа/счета – последовательное - TO BE», «Система контролей: Выполнение поручения - TO BE».
3.4.3. Действия над задачей
Над задачей можно выполнять следующие действия:
1. Принять
2. Отклонить
3. Делегировать - а также запрет делегирования при постановке задачи
4. Вложить файл
5. Вернуть инициатору
6. Прокомментировать – возможность должна быть также при выполнении любого другого действия
3.4.4. Контроль выполнения задач и уведомления
Механизмы контроля:
1. Заполнение поля «Статус» исполнителем
2. Нотификация(в т. ч. автоматическое по истечению срока) исполнителю от инициатора
3. Ведение истории изменений задачи
4. Экспресс-опрос по тематике задачи
5. Отчеты о выполнении задач
3.4.5. Доступ к задачам и роли
Доступ на редактирование задачи имеет только исполнитель.
В соответствии со структурой групп описанной в п.3.1. Права пользователей в системе, любой пользователь, имеющий подчиненных, имеет право на просмотр задач поставленных его подчиненным.
Типовые роли:
1. Инициатор – сотрудник, который имеет право оформлять новые задачи.
2. Согласующий (чаще всего - линейный руководитель) – сотрудник, имеющий право согласовывать (для каждого подразделения отдельно).
3. Исполнитель – сотрудник, получающий поручения.
3.4.6. Ведение истории изменений
Каждое изменение пользователем параметров задачи должно фиксироваться.
3.4.7. Запуск задач
На основании шаблонов предполагается создавать экземпляры задач.
Предусмотреть возможность подставлять разных исполнителей в этапы рабочего процесса в зависимости от того, кто запустил задачу. Например, роль «Согласующий» примет на себя директор отделения, если задачу запустил сотрудник отделения и эту же роль примет на себя Региональный руководитель, если задачу запустил директор отделения.
С целью разгрузить пользователей от знания маршрута заказа и согласования АХО, рекламных материалов и пр., реализовать механизм интернет-магазина.
У каждого отделения должны быть отдельные счета для каждого из видов заказываемых ТМЦ. Пополнение счетов, а также редактирование(в т. ч. создание, удаление) видов ТМЦ должно выполняться бизнес-администратором.
Получатель заказа должен иметь возможность работать не с множеством входящих заказов от отправителей, а с одним общим заказом, сформированным из всех необработанных заказов.
Верхнеуровневый процесс заказа в интернет-магазине описан на диаграмме «Заказ обеспечения TO BE».
3.6.1. Поиск
3.6.1.1. Поисковый запрос
Документы, найденные в результате поиска должны быть релевантными поисковому запросу.
Поиск производится по заголовкам, метаданным и содержанию(включая вложенные файлы) записей в БЗ.
Поиск может производиться:
1. по вхождению фразы(в т. ч. с использованием логических операторов)
2. по тегам (в т. ч. с использованием логических операторов)
3. по неполному вхождению фразы/тега («кред» - для «кредит»)
4. по типу файла
5. расширенный поиск – форма с несколькими полями для ввода значений параметров:
a. поле для ввода общего поискового запроса
b. поля для ввода метаданных
6. по ID записи
3.6.1.2. Дополнительные механизмы поиска
1. Полнотекстовый поиск (необходимо индексирование всех записей и вложенных файлов для проведения поиска по содержимому)
2. Поиск на основании рейтинга записей
3.6.1.3. Повышение удобства поиска
1. Поисковая форма должна быть доступна на любой странице Портала
2. В результатах поиска должны выделяться цветовым фоном найденное словосочетание поискового запроса
3. Должен быть реализован механизм «поиск по результатам поиска» неограниченной вложенности, в т. ч. наложение дополнительного фильтра на результаты поиска
4. Каждый результат поискового запроса должен содержать не только название записи в БЗ, где найдено слово, но и метаданные записи(в виде справочной информации).
5. В конце страницы с записью разместить ссылку на эту запись, чтобы можно было ее скопировать и переслать
3.6.2. Медиа-содержимое
Реализовать возможность прикреплять видео и/или фотографии к записям на портале. Встроить средства просмотра медиа-содержимого прямо на портале.
3.6.3. Объединение сущностей
Реализовать возможность создавая новый экземпляр конкретной сущности(из описанных выше), связывать ее с другими.
Например, необходимо связывать:
1. При создании записи в БЗ – выслать информационное сообщение, назначать задачу
2. При публикации отчета - выслать информационное сообщение
3. При назначении задачи - выслать информационное сообщение, создать запись в БЗ
Т. е. на форме создания экземпляра сущности должен быть интерфейс для добавления(создания) в эту запись еще одной сущности другого рода.
3.6.4. Нотификация
Реализовать механизм уведомлений о событиях в системе:
1. RSS – ленты новостей:
a. По тегам
b. По категориям представлений
c. По категориям записей
2. Бегущая строка
3. Всплывающее окно
4. E-mail
Реализовать страницу с перечнем непрочитанных новостей. Если пользователь долго отсутствовал(например, отпуск/больничный), ему должна поступать сводная нотификация. Например, если за время отсутствия появилось 50 новостей, то пользователь должен увидеть не 50 нотификаций, а одну с темой «50 новостей» и ссылкой на страницу с непрочитанными новостями.
3.6.5. Ведение лога действий пользователей и статистики
Предусмотреть функционал отслеживания действий пользователей и трекинга их перемещений по порталу.
Вести статистику:
1. Посещаемости страниц.
2. Действий пользователя.
3. Поисковых запросов.
3.6.6. Доступ к другим веб-базированным системам Банка в окне Портала
В основном фрейме портала должна быть возможность отобразить другаю веб-базированную систему Банка( например, WebTutor).
Необходимо предусмотреть возможность разворачивания основного фрейма на весь экран для упрощения работы.
3.6.7. Экспресс-опрос
Реализовать привязку опросов к любой записи на Портале, в т. ч. к назначенным заданиям.
Опросы могут содержать более одного вопроса. Вопросы могут быть с одним или несколькими вариантами ответов, а также с полем для записи ответа на клавиатуре. Реализовать ветвление опросов в зависимости от ответов пользователей.
3.6.8. Календарь
Реализовать календарь, в который отмечать все события, связанные с конкретным пользователем.
При переходе к конкретной дате календаря выдавать страницу с перечнем событий, которые приходятся на эту дату и лежат в области видимости пользователя. Например, для сотрудника отделения это будет перечень задач, ссылок на изменения в БЗ, дней рождений коллег из того же отделения.
3.6.9. Новостные блоки
Отображение истории внесения новых записей в разделы Портала реализовать с помощью новостных блоков с настраиваемым количеством отображаемых записей.
3.6.10. Форматы файлов
Реализовать прямо в окне Портала отображение всех основных офисных типов файлов, включая, но не ограничиваясь:
1. .doc, .docx
2. .xls, .xlsx
3. .ppt, .pptx, .pps, .ppsx
4. .pdf
5. .txt
6. Файлы рисунков(.png, .jpg/.jpeg, .tiff, .bmp)
Реализовать загрузку файлов перечисленных выше типов на портал в виде готовых html-страниц. Причем все форматирование документа должно быть сохранено.
Кроме того предусмотреть открытие файлов из архива.zip, .rar, .7z.
3.6.11. Авторизация
Реализовать автоматический вход на Портал под логином из Active Directory. Предусмотреть возможность авторизации с помощью логина/пароля самого Портала, не связанных с учетной записью в AD.
3.6.12. Бизнес-администрирование
Портал должен предоставлять интуитивно-понятный интерфейс для его настройки и редактирования, причем для выполнения этих функций бизнес-администратору не должно быть нужно знать языки программирования.
3.6.13. Экспорт данных из Портала
Портал должен обладать функционалом экспорта данных в программы пакета MS Office. Все табличные данные должны выгружаться в файл MS Excel с настроенным условным форматированием.
4. Нефункциональные требования
Базовая иерархическая структура групп должна соответствовать структуре Active Directory Банка.
Доступ должен настаиваться гранулировано, в привязке к группе(группам), в которые входит пользователь или на самого пользователя. Типы доступов должны соответствовать стандартным типам разграничения прав Windows.
Должен быть реализован:
· механизм выделения подгрупп с наследованием прав от родительской группы
· механизм блокирования/разблокирования субъектов доступа
Также, на базе функционала, описанного в п.2.6.2.Ведение лога действий пользователей и статистики, должны быть реализованы отчеты по действиям пользователей в системе за определенный период:
1. В разрезе конкретного пользователя.
2. В разрезе конкретного раздела Портала, вплоть до самых мелких разделов, например, записи в БЗ.
Реализовать «копирование» всех доступов конкретного пользователя другому пользователю для замены отсутствующего сотрудника. При этом «заместитель» должен также получать всю корреспонденцию и быть исполнителем всех задач, назначенных на отсутствующего.
4.2.1. Технологическая платформа
Портал будет реализован на платформе Microsoft Office SharePoint Standart 2010.
4.2.2. Веб-сервер
Компонент | Минимальные требования |
Процессор | Intel® Xeon®, не менее 4 ядер, частота не менее 2.53 ГГц, или аналог |
ОЗУ | Не менее 8 GB |
Жесткий диск | 120 GB EIDE |
Программное обеспечение | Операционная система MS Windows Server Standard 2008 R2 |
4.2.3. Сервер баз данных
Компонент | Минимальные требования |
Процессор | Intel® Xeon®, не менее 4 ядер, частота не менее 2.66 ГГц, или аналог |
ОЗУ | Не менее 8 GB |
Жесткий диск | 120 GB EIDE |
Программное обеспечение | Операционная система MS Windows Server Standard 2008 R2 Серверная лицензия на SQL Server 2008 Standard R2 или выше. |
4.2.4. Рабочее место пользователя
Компонент | Минимальные требования |
Процессор | частота не менее 1.66 ГГц |
ОЗУ | Не менее 1Гб (Рекомендовано 2 Гб) |
Программное обеспечение | Браузер Internet Explorer версии 7 и выше. .Net Framework 3.5 Microsoft Office 2007 | 2010 – для пользователей, которым необходимы функции работы с документами. |
Портал должен поддерживать одновременную работу до 500 пользователей из 1000 зарегистрированных.
Портал должен быть доступен с 8.00 до 21.00 каждый рабочий день.
Портал реализуется на русском языке.
Элементы интерфейса будут созданы на трех языках:
1. Русский
2. Украинский
3. Английский
5. Оценить опционально
Портал должен правильно отображаться и работать на планшете IPad.
Реализовать возможность автономной работы и периодической репликация данных.
Реализовать интеграцию календарей Siebel, Lotus с календарем Портала посредством веб-сервисов.
1. Механизм вычисления рейтинга записи на основании поисковых запросов с использованием этого рейтинга при последующих поисковых запросах
2. Механизм подсказок в строке поиска(например, по первым двум буквам «кр» должен сработать фильтр и вывестись перечень тегов/фраз/слов начинающихся на «кр» - «кредит», «кредитная карта» и т. д.)
3. Фонетический поиск
4. Поиск сотрудников с определенными компетенциями
Приложение 1.
A1 Размещение отчетов TO BE
A2 Внесение статьи Альфа-вики TO BE
|
A3 Заказ обеспечения TO BE
|
A4 Система контролей: Согласование документа/счета – параллельное - TO BE
|
A5 Система контролей: Согласование документа/счета - последовательное - TO BE
|
A6 Система контролей: Выполнение поручения - TO BE
|
