Приложение № 2 к тендерной документации Утверждаю Заместитель генерального директора

Приложение № 2 к тендерной документации
Утверждаю
Заместитель генерального директора
по планированию и развитию бизнеса
_________ К. Смагулов
«___»___________ 2014 года
ТЕХНИЧЕСКАЯ СПЕЦИФИКАЦИЯ
НА ЗАКУПКУ СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА
Общие требования:
Требования к программному обеспечению (далее - ПО), для системы электронного документооборота
и потенциальному поставщику указаны в настоящей технической спецификации, все предложенные
характеристики оборудования должны соответствовать или превосходить минимальные технические
характеристики, указанные в данной технической спецификации.
Общие требования к потенциальному поставщику:
Система электронного документооборота – программно-аппаратный
комплекс, осуществляющий ввод, обработку, согласование входящих,
исходящих, внутренних, организационно-распорядительных, договоров,
документов, составляющих основу корпоративного содержания.
Потенциальный поставщик должен быть действующим партнером вендора от
производителя платформы, на базе которой создаётся данная СЭД, с
наличием компетенции «Совместная работа и Управление Контентом».
СЭД должен быть создан на базе платформы, которая поддерживает
следующие функции:
- набор веб-приложений для организации совместной работы
- функциональность для создания веб-порталов
- модуль поиска информации в документах и информационных системах
- функциональность управления рабочими процессами и системой управления
- содержимым масштаба предприятия
- модуль создания форм для ввода информации
- функциональность для бизнес-анализа
- полная интеграция с существующими системами, такими как; ADDS,
Exchange
- возможность для совместной работы над одним документом
В проекте должны быть задействованы сертифицированные специалисты, что
должно быть подтверждено оригиналом либо нотариально заверенной копией
Общие
1
сертификата от производителя платформы, на базе которой создаётся данный
1
требования:
СЭД.
В области управления проектом:
 не менее 1 (одного) специалиста, обладающего сертификатом
общепризнанных международных ассоциаций управления проектами
не ниже категории, соответствующей наивысшему уровню
сертификации
В области оказания услуг по внедрению платформы СЭД, портала и
интеграции с инфраструктурой Общества:




не менее 1 (одного) специалиста, обладающего сертификатом
«Сертифицированный специалист по технологиям от производителя
платформы, на базе которой создаётся данная СЭД»
не менее 1 (одного) специалиста, обладающего сертификатом
«Профессиональный
сертифицированный
разработчик
от
производителя платформы, на базе которой создаётся данная СЭД»
не менее 1 (одного) специалиста, обладающего сертификатом
«Сертифицированный технический специалист от производителя
платформы, на базе которой создаётся данная СЭД»: «Configuration»
не менее 1 (одного) специалиста, обладающего сертификатом





2
Гарантия
2
и
поддержка
3
Требования
3
к
поставке
4
Требования к
лингвистическому
4
переводу
документов
«сертифицированный системный администратор от производителя
платформы, на базе которой создаётся данная СЭД»
не менее 1 (одного) специалиста, обладающего сертификатом
«Сертифицированный системный инженер от производителя
платформы, на базе которой создаётся данная СЭД»
не менее 1 (одного) специалиста, обладающего сертификатом
«Сертифицированный технический специалист от производителя
платформы, на базе
которой создаётся
данная СЭД»:
коммуникационная программа-клиент, позволяющая пользователям
общаться друг с другом в реальном времени, используя различные
виды коммуникаций, «Configuration»;
не менее 1 (одного) специалиста, обладающего сертификатом
«Сертифицированный ИТ-специалист от производителя платформы,
на базе которой создаётся данная СЭД» коммуникационная
программа-клиент, позволяющая пользователям общаться друг с
другом в реальном времени, используя различные виды
коммуникаций, «Administrator»;
не менее 1 (одного) специалиста, обладающего сертификатом
«Сертифицированный системный инженер от производителя
платформы, на базе которой создаётся данная СЭД»: «Server
Infrastructure»;
не менее 1 (одного) специалиста, обладающего сертификатом
«Сертифицированный технический специалист от производителя
платформы, на базе которой создаётся данная СЭД»: «NET
Framework 4», «Web Applications»;
Гарантия и техническая поддержка на данное ПО предоставляется в течение 1
(одного) года
Должно быть поставлено лицензионное ПО, необходимое для
функционирования Системы и отвечающее требованиям раздела 8.
«Требования к функциональным возможностям системы» на условиях DDP
по адресу Заказчика.
Лицензионное ПО должно обеспечивать бесперебойную работу постоянно
изменяющегося, в зависимости от интернет-подключений, числа
пользователей для работы на не менее, чем на 2 (двух) процессорных
серверах.
Количество Лицензий на ПО, поставляемого в рамках текущего Проекта,
должно быть определено и поставлено в соответствии с требованием,
указанным в разделе 5.2. данной технической спецификации.
Система лицензирования ПО в рамках данного технического решения должна
предполагать лицензии на все требуемые компоненты СЭД, без
необходимости последующего дополнительного приобретения лицензий на
какие-либо поставляемые компоненты, требуемые в зависимости от
архитектуры решения или других обстоятельств, кроме приобретения
лицензионного ПО под задачи увеличения количества пользователей.
Поставка лицензионного ПО не включает поставку лицензий на серверные
ОС, платформу СЭД и СУБД.
Поставка должна быть осуществлена единовременно и в полном объеме, в
адрес Заказчика. Поставка производится с даты заключения договора до 31
декабря 2014г.
Поставщик обязан предоставить оригинал авторизационного письма от
производителя платформы лингвистического перевода документов, с
указанием партнёра-интегратора.
Потенциальный Поставщик должен предоставить разбивку общей стоимости по пунктам:
Наименование пунктов
Стоимость
Заполняется потенциальным поставщиком
Заполняется потенциальным поставщиком
Заполняется потенциальным поставщиком
Заполняется потенциальным поставщиком
Заполняется потенциальным поставщиком
Название платформы
Название продукта
Срок внедрения продукта
Заполняется потенциальным поставщиком
Заполняется потенциальным поставщиком
Заполняется потенциальным поставщиком
Заполняется потенциальным поставщиком
Используемые термины и сокращения:
Термин
Библиотека
документов
Бизнес-процесс
Документ
Документооборот
Жизненный цикл
(ЖЦ) документа
Задача
Подсистема
Права доступа к
документу
Система (СЭД)
Электронная
цифровая подпись
(ЭЦП)
СУБД
Роль
Таблица 1. Основные термины
Определение
Место на веб-узле, где можно создавать, обновлять файлы, создавать их
коллекции и работать с ними совместно с другими пользователями
Представление деятельности организации в виде совокупности взаимосвязанных
процессов
1. Зафиксированная на материальном носителе информация с реквизитами,
позволяющими ее идентифицировать;
2. В Системе – совокупность реквизитов регистрационной карточки и
вложения (файла/файлов, прикрепленных к регистрационной карточке и
содержащих текст и/или сканированная копия документа).
Движение документов в организации с момента их создания или получения до
завершения исполнения или отправления.
Процесс прохождения документа по всем последовательным этапам, которые
определяют основные состояния «жизни» документа, начиная с момента его
создания до уничтожения или передачи в архив.
В общем случае, этапы
жизненного цикла включают стадии подбора материалов или выбора шаблона
документа, создания или составления
проекта документа, согласования и
внесения изменений в проект документа, визирования и утверждения документа,
опубликования документа, вывода из обращения, сдачи в архив или
уничтожения. Состав этапов «жизни» документа зависит от его типа
Совокупность элементов пользовательского интерфейса, предписывающая и
позволяющая Пользователю выполнить регламентированную бизнес-операцию.
Генерируется Системой на основании настроек маршрута.
Часть системы, реализующая фиксированный набор ее функций при
автоматизированной документарной поддержке конкретного делового процесса в
организации.
Совокупность ограничений на действия с документами для различных
пользователей (групп пользователей).
Система электронного документооборота
Набор электронных цифровых символов, созданных средствами электронной
цифровой подписи и подтверждающий достоверность электронного документа,
его принадлежность и неизменность содержания.
Система управления базами данных
Набор функций пользователя, определяющий его типовые полномочия при
работе в системе электронного документооборота
Назначение системы
Система предназначена для обеспечения управления информацией в различных форматах,
используемой в работе компании, в том числе содержанием, полученным из других корпоративных
приложений, баз данных, файловых и других систем.
СЭД будет использоваться для автоматизации обработки документов канцелярии, юридического
подразделения и остальных структурных подразделений, а также для совместной работы над документами.
Внедрение СЭД должно распространяться на все рабочие места РСС в рамках 250 (двухсот пятидесяти)
клиентских подключений.
Система должна обеспечивать автоматизацию основных процессов документооборота, включая
контроль исполнительской дисциплины:
1. Входящая корреспонденция:
 письма, телеграммы, телефонограммы;
 уведомления о проверке, претензии, иски.
2. Исходящая корреспонденция.
3. Организационно-распорядительные документы:
1.
 приказы по основной деятельности;
 распоряжения по основной деятельности.
4. Работа с договорами (согласование, регистрация, поиск и пр.).
5. Внутренние:
 Служебные записки (внутренняя переписка между структурными подразделениями):
 по производственным вопросам;
 по кадровым вопросам;
6.
Обращения граждан;
7.
Согласование документов (инициатор – любое подразделение);
8.
Хранение нормативно-справочной и типовой документации по папкам (инструкции,
положения, нормативная документация, шаблоны и пр.).
Детальные требования к перечню видов документов и процессов должны быть уточнены на этапе
реализации Технического задания.
Цели и задачи
2.1 Цель
Основной целью создания Системы является автоматизация процессов обработки документов.
Разработка Системы преследует следующие цели:
 оптимизация работы с бумажными носителями (работа с входящими, исходящими, внутренними,
организационно-распорядительными документами);
 контроль исполнения документа;
 повышение эффективности и оперативности работы сотрудников;
 улучшение качества, полноты и достоверности информации при соблюдении требований
информационной безопасности;
 снижение затрат на управление информацией;
 минимизация риска отсутствия или недоступности информации, необходимой для принятия
решений;
 Повышение оперативности и увеличение темпа документооборота;
 Повышение качества управленческих решений;
 Снижение затрат на лингвистический перевод документов.
2.
2.2
Задачи Проекта
В рамках Проекта должны быть решены следующие задачи:
 Внедрение безбумажного документооборота.
 Автоматизация основных бизнес-процессов (п.3), связанных с обработкой документов.
 Поиск и своевременная доставка необходимых для принятия решения документов на рабочие
места лиц, принимающих решения.
 Использование централизованных корпоративных классификаторов, применение современных
методов поиска электронных документов.
3.
Зона проекта (границы оказания услуг/проведения работ)
3.1 Место поставки ПО
Услуга должна быть оказана по месту нахождения Заказчика: г. Астана, 010000,
Казахстан, проспект Кабанбай батыра, 19, блок Б.
Республика
3.2 Поставка лицензионного программного обеспечения
Аппаратное обеспечение (Серверное оборудование, ПК), Операционные системы, антивирусные
программы под задачи функционирования СЭД – предоставляются Заказчиком.
 Лицензионное программное обеспечение СЭД для работы 250 (двухсот пятидесяти)
конкурентных пользователей поставляется Исполнителем;
3.3 Результаты поставки ПО
В рамках поставки ПО должны оказываться сопутствующие услуги:
1. Развернуть и ввести в эксплуатацию СЭД. Система считается готовой к эксплуатации в
случае, когда все требования, описанные в окончательном утвержденном заказчиком
«Техническом задании на создание СЭД», реализованы Потенциальным Исполнителем,
протестированы и одобрены Заказчиком, при этом должен быть подписан акт приемапередачи поставленного ПО.
2. Разработанная и переданная в 2 (двух) экземплярах проектная документация:
 Техническая документация («Техническое задание на создание СЭД»), содержащая описание
модели СЭД и являющаяся основой для создания Системы.
 Рабочая документация: «Руководство пользователя», «Руководство администратора», содержащая
инструкции по работе с Системой.
3. Обученные пользователи и Администраторы из числа рабочей группы Заказчика, имеющие
навыки самостоятельной работы в Системе и пользования рабочей документацией.
4. Переданные Заказчику CD-диски с дистрибутивами лицензионного ПО.
4.
Требования к функциональным возможностям системы
4.1 Требования к функциональным возможностям платформы для СЭД и портала
Используемая для разработки Системы платформа должна позволить сократить стоимость и сроки
внедрения, реализовать решение, которое будет полностью удовлетворять требованиям Заказчика, а также
обеспечит надежную базу для решения будущих задач в области управления информационными активами и
бизнес-процессами Заказчика.
Таблица 2 Требования к функциональным возможностям платформы
№
п/п
1
1.1
2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Описание требования
Требования к вендору платформы
Производитель Платформы должен иметь:
– официального дистрибьютора/Партнерскую сеть на территории РК
– партнерской сетью с сертифицированными Разработчиками по данной Платформе на территории
РК.
Общие требования к платформе
Платформа должна гарантировать возможность развития Системы, без изменений интерфейса
пользователей уже имеющихся подсистем (за исключением изменений от плановых обновлений ПО),
а также обладать интеграционными возможностями с внешними Системами, в частности Lotus Notes
в АО НК «КазМунайГаз».
СЭД должна быть реализована на платформе управления контентом.
Платформа должна использовать объектную модель хранения данных, т.е. должна быть явная
классификация данных по Типам. Тип может иметь свой набор полей (атрибутов) и методов. Должны
быть развиты механизмы ООП - такие как: Наследование Типов, Аспекты, другие механизмы.
Платформа должна поддерживать использование раздельного хранения Объектов: поля объектов
хранятся в СУБД, содержимое объектов (документов, кодов методов - программ обработки) в
структурированной файловой системе.
Платформа должна обеспечить поддержку данных и интерфейса на нескольких языках, в том числе:
казахский, русский, английский.
Платформа должна обеспечить поддержку просмотра и редактирования документов формата MS
Office Word, Excel, PowerPoint, просмотра Adobe Acrobat, Adobe Reader версии 2010 и выше, TIFF,
PNG, JPG, BMP в браузере.
Платформа должна поддерживать дополнительную функциональность управления на уровне сайтов:
 Размещение кастомизированных веб-частей
 Восстановление отсоединенной базы данных
 Поддержка встроенных веб-частей
 Делегация разрешений
 Доступ с мобильных устройств
 Лента управления
 Мастеры настройки
 Определение аудиторий пользователей
 Отделение механизма аутентификации от его реализации
 Отчеты об использовании
 Поддержка просмотра и редактирования документов формата MS Office Word, Excel,
PowerPoint, Adobe Acrobat, Adobe Reader версии 2010 и иные программы в браузере.
 Поддержка баз данных в режиме « Только для чтения»
 Поддержка больших списков
 Интеграция с Microsoft Office
 Управление обновлениями
 Управление разрешениями
 Управляемые учетные записи

Хранение больших объектов в файловой системе
Платформа должна поддерживать дополнительную функциональность управления на уровне
сообществ и сетей:
2.8
2.9
2.10
2.11






















Блоги
Вики-страницы
Доски обсуждений
Интеграция с Office Communications Server и Exchange Server
Фотографии и присутствие
Доски объявлений
Инструментарий тегов и заметок
Ключевые слова (тэги)
Каналы новостей пользователя
Коллеги пользователя
Контент пользователя
Профиль пользователя
Облака тэгов
Организационная структура
Последние события
Предложения ключевых слов
Предложения коллег
Профили тэгов
Рейтинги
Спроси меня
Статус пользователя
Участие в группах
Платформа должна поддерживать дополнительную функциональность управления на уровне
управления контентом:
 Наборы документов
 Навигация по метаданным
 Общие типы контента
 Организатор контента
 Службы Word Automation Services
 Служба управляемых метаданных
 Уникальные идентификаторы документов
 Управление мультимедиа контентом
Платформа должна поддерживать дополнительную функциональность управления на уровне
корпоративного поиска:
 Поиск по сайту
 Базовая сортировка
 Детализация на основе метаданных
 Детализация на основе социальных тегов
 Лучший выбор (Best Bets)
 Мобильный поиск
 Настройка релевантности
 Недавно-созданный контент
 Определение дубликатов
 Поиск из Windows 7
 Поиск корпоративного масштаба
 Поиск людей и экспертизы
 Поиск по произношению и никнейму
 Предложения поисковых запросов, "Возможно вы искали?"
 Рамки поиска
Платформа должна поддерживать дополнительную функциональность управления на уровне бизнесаналитики:
 Библиотека подключений к данным





2.12
Веб-части диаграмм и графиков
Вычисляимые Ключевые показатели эффективности(KPI)
Дерево декомпозиции
Приборные панели
Центр бизнес-аналитики
Платформа должна поддерживать дополнительную функциональность управления на уровне
конструктора приложений:
 Управление содержимым портала
 Внешние списки
 Инфраструктура ленты и диалогов
 Клиентская объектная модель
 Модели рабочих процессов
 Настройка на основе браузера
 Обработчики событий
 Пакеты решений
 Планировщик заданий
 Потоки данных ATOM и REST
 Приборная панель разработчика
 Рабочие процессы
 Сервисная архитектура
 Служба подключения к внешним данным
 Столбец внешних данных
 Язык интегрированных запросов
 Шаблоны рабочих процессов
 Веб части бизнес-данных
 Интеграция бизнес-данных в приложения Office
5
Требования к масштабированию платформы
Платформа должна позволять создавать несколько отдельных Хранилищ объектов в рамках одного
управляющего Сервера Платформы без закупа дополнительных лицензий.
Платформа должна использовать модульную модель построения Систем для гарантирования развития
Системы в будущем путем закупа /создания модулей с требуемой функциональностью.
Модульная модель платформы должна позволять организовать развертывание Системы как на
минимальном наборе физического или виртуального оборудования – один сервер, так и в случае
роста нагрузки должно быть гарантировано разнесение модулей платформы по различным серверам и
кластерам серверов.
Требования к средству поиска платформы
Платформа должна предоставить средство Поиска.
Модуль Поиска должен полностью учитывать Объектную модель хранения – то есть позволять
проводить поиск, с учетом Типов, как по атрибутам, так и по содержимому документов (контекстный
поиск). Например: возможность задать следующее Условие поиска: Только «Входящая
Корреспонденция»
Модуль Поиска должен поддерживать различные варианты развертывания Системы - как в
минимальной конфигурации развертывания – все на одном сервере, так и в конфигурации,
разнесенной по различным серверам, в том числе и модуль Поиска – на отдельном сервере.
Требования к средствам ограничения доступа платформы
5.1
Платформа должна обеспечивать автоматизацию режима ограничения доступа
3
3.1
3.2
3.3
4
4.1
4.2
4.3
5.2
5.3
5.4
Платформа должна предоставлять базовые средства Аутентификации. Как минимум, для получения
доступа к функциям, пользователи должны аутентифицироваться — ввести имя и пароль. Для
механизма Аутентификации должны использоваться либо хранимые в системе учетные записи, либо
учетные записи из каталогов LDAP (Active Directory). Поддержка ADFS (Active Directory Federation
Services)
Платформа должна предоставлять API и Интерфейс для объединения пользователей в Группы. Один
пользователь может находиться одновременно сразу в нескольких группах. Группы создаются по
необходимости.
Платформа должна предоставлять API и Интерфейс для назначения пользователю тех или иных
Ролей. Один пользователь может обладать сразу несколькими ролями. Роли создаются по
необходимости.
5.5
5.6
6
6.1
6.2
Платформа должна предоставлять API и Интерфейс для составления схем доступа (ACL) с указанием
доступных основных уровней доступа и расширенных полномочий для конкретного пользователя,
группы, либо роли. Основные уровни доступа указываются всегда, расширенные – по необходимости.
Перечень расширенных полномочий должен включать в себя, как минимум, такие полномочия как:
– смена владельца объекта
– смена прав доступа на объект
– другие расширенные полномочия
Расширенные полномочия, в отличие от основных, не включают в себя предыдущие и указываются в
ACL прямым перечислением требуемых расширенных прав.
Требования к интеграционным возможностям платформы
Должна быть предусмотрена возможность интеграции СЭД с информационными системами
Заказчика.
Возможности интеграции, с одной стороны, должны быть гарантированы наличием как готовых
(поставляемых отдельно) коннекторов к различным ИС, так и открытого API, а также поддержкой
мировых стандартов обмена данными, включая, но не ограничиваясь:
– работа по TCP/IP протоколу;
– поддержка SOA – (XML, XSLT, DTD форматы обмена);
– протоколы доступа к Базам Данных.
С другой стороны, успешность интеграции обеспечивается использованием Заказчиком систем,
которые также имеют открытый API и поддержку вышеуказанных стандартов обмена
4.2
Требования к функциональным возможностям платформы для лингвистического
перевода
Используемая для разработки Системы платформа лингвистического перевода должна позволить сократить
стоимость и сроки внедрения, реализовать решение, которое будет полностью удовлетворять требованиям
Заказчика.
Таблица 3. Требования к возможностям платформы лингвистического перевода
1
Требования к возможностям платформы лингвистического перевода
Основные возможности платформы:
 Перевод слов, словосочетаний и текстов.
 Перевод любого выделенного текста по «горячей» клавише.
1.1
 Использование, редактирование и создание специализированных словарей и профилей
перевода.
 Подключение баз Translation Memory и глоссариев.
 Интеграция в офисные приложения, веб-браузеры, корпоративные порталы и сайты.
1.2
1.3
1.4
1.5
1.6
Платформа должна поддерживать статистическое направление перевода
Платформа должна поддерживать гибридную систему – два основных компонента: базовый RBMTмодуль перевода и модуль статистического постредактирования, который использует данные,
полученные на этапе обучения (статистическая модель перевода, статистическая модель выходного
языка)
Платформа должна содержать инструмент настройки перевода: резервирование слов, использование
словарей, выбор семантики для существительных
Платформа должна поддерживать дополнительные настройки:
 использование правил перевода;
 занесение в словарь пользователя разрывных оборотов;
 создание или выбор шаблона тематики;
 подключение специализированных словарей Вендора для различных предметных областей;
 подключение пользовательских словарей;
 создание и редактирование групповых настроек перевода – шаблонов тематик, а также
сохранение текущих настроек перевода для каждого пользователя индивидуально;
 создание и редактирование правил перевода XML-документов.
Платформа должна осуществлять перевод текстов и документов, в том числе казахский - русский
и/или английский:
 Перевод неформатированного текста и файлов TXT в различных кодировках;
 Перевод документов с сохранением форматирования в форматах, RTF, HTML, XML. XLIFF;
 Перевод документов Microsoft® Office 2007-2010: поддержка форматов MS Word, Excel и
PowerPoint 2007-2010;
 Перевод Web-страниц (с автоматической закачкой, парсингом и переводом гиперссылок),
размещенных локально или в Интернете;


1.7
1.8
Создание правил для перевода XML;
Наряду с возможностью перевода одиночного файла реализована возможность перевода
файлов через очередь перевода;
 Реализован механизм, позволяющий изменять (масштабировать) количество серверов, на
которых выполняются задачи перевода в зависимости от имеющейся нагрузки. Данный
механизм основан на использовании двух компонентных систем: сервера приложения и
сервера перевода.
Интеграция в другие приложения:
 Встраивание функций перевода непосредственно в Microsoft® Word 2000-2010 с помощью
плагинов;
 Перевод Web-страниц в окне браузера с использованием toolbar для Microsoft® Internet
Explorer, Google Chrome, Safari и Mozilla Firefox;
 Перевод текстов с помощью комбинации «горячих» клавиш в любом Windows-приложении с
использованием специализированного агента
Платформа должна поддерживать перевод не менее чем на 64 языковые пары.
4.3
Требования к функциональным возможностям СЭД
Таблица 4. Требования к функциональным возможностям СЭД
№
п/п
1
1.1
1.2
Описание требования
Требования к возможностям Интерфейса СЭД
Использование интернет-браузера MS IE версии 10 и выше, Firefox версии 28 и выше, Safari
последней версии и Google Chrome.
Возможность отправки карточки документа или файла по электронной почте напрямую из карточки
документа
1.3
Возможность настройки интерфейса системы в рамках функциональности платформы.
1.4
Наличие папки «Задачи» для приема заданий в интерфейсе каждого пользователя системы
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
В описании задания должно быть указано, как минимум: кто и когда поставил данную задачу
исполнителю, что именно и когда поручено выполнить исполнителю.
Должны поддерживаться как минимум следующие карточки заданий: на исполнение, на
рассмотрение, на согласование, на ознакомление, на регистрацию. Формы заданий должны
отличаться в зависимости от типа заданий, например задание «на согласование» должно иметь
функцию для согласования документа.
В зависимости от задания, карточка документа должна содержать либо не содержать прилагаемые
файлы, доступ к которым возможен непосредственно из окна задания, имея возможность открыть
полученный на исполнение документ и его карточку.
Наличие в любом документе в системе СЭД двух составляющих: Карточки и Тела.
Тело документа – это содержимое файла, например письмо, записка в формате MS Word, либо PDF,
либо в других форматах. В качестве основного формата тел документов предполагается
использование форматов MS Office и PDF – для документов с текстовым содержимым и форматы
JPEG, GIF, TIFF, DWG для документов, состоящих только из графической информации (фото, сканкопии чертежей, файлы AutoCAD и т.п.), а также Outlook item (.msg).
Карточки документов должны представлять собой наборы атрибутов такие как: автор
(корреспондент), регистрационный номер документа, дата регистрации, откуда поступил документ
(наименование организации и тд., либо ФИО, при обращении граждан), исходящий номер
документа (при наличии), тип документа, срок исполнения (при наличии), краткое содержание
документа, номенклатурный индекс дела (папки).
Для облегчения визуального восприятия атрибуты распределение по «группам» карточки.
Поддерживание просмотра и редактирование файлов документов непосредственно в карточке
документа и карточки задания через веб-интерфейс без необходимости загрузки файла во внешнее
приложение.
Состав атрибутов карточки могут быть различным в зависимости от требований бизнес-процессов
(Письмо, Договор, ОРД и т.п.) будут определены на стадии подготовки технического задания.
Список доступных пользователю действий должен меняться в зависимости от того, в каком
делопроизводственном процессе в настоящий момент участвует документ и на каком этапе этого
процесса находится данный документ и какими правами обладает в этой «точке» пользователь.
Каждому процессу, реализованному в системе, должны быть присущи следующие характеристики:
наличие определенной цели, роли и ресурсы для его выполнения, операции и последовательность их
выполнения, ответственность и контроль за выполнением процесса, вход и выход процесса
(документы, отчеты и т.п.).
2
Общие требования к функциональным возможностям СЭД
2.1
Необходимость предусмотрения журналов регистрации документов с возможностью сортировки и
фильтрации данных.
2.2
Необходимость предусмотрения в системе формирования не менее 4 (четырех) отчетов.
2.3
Поддержка справочников и классификаторов, обеспечивающих работу СЭД.
2.4
Поддержка ЭЦП, а также применение ЭЦП посредством ее визуального отображения (логические
метки).
2.5
Версионность документов (работа с версиями до утверждения документа).
2.6
2.7
2.8
2.9
2.10
2.11
Управление состояниями одного и того же объекта (документа). Например, Тип – Входящее письмо.
Возможные состояния: Регистрация, Ознакомление, Исполнение, Архив.
Жизненный цикл должен определять цепочку состояний, через которые проходит документ с
момента создания. Каждое состояние документа должно наделяться определенным набором свойств
карточки документа, как минимум: списком пользователей, которые могут к нему обращаться;
набором действий, которые этим пользователям разрешены; перечень состояний, в которые
разрешен переход из текущего состояния.
Поддерживание функционала консолидированного комментирования карточки документа из
карточки документа и карточки задания
Возможность перемещения нескольких файлов документов напрямую в карточку методом
«drag&drop»
Возможность сканирования бумажного документа непосредственно из карточки документа или
карточки задания. При этом должен поддерживаться сканер, подключенный к ПК, либо выбор
отсканированного документа сканером из папки сетевого сканера.
Отправка уведомлений о назначении задания или документа, а также приближении срока
исполнения на электронную почту, в веб-интерфейс в виде всплывающих уведомлений, а также в
клиентское приложение, установленное на компьютере пользователя. Способ доставки уведомления
должен настраиваться.
2.12
Возможность добавления связанных карточек документов (ссылок), папок и внешних URL.
3
Требования к лингвистическому переводу документов
поддерживание языков перевода: русско-казахский, казахско-русский, англо-русский, русскоанглийский
Разделение основных и переведенных файлов
Осуществление лингвистического перевода в рамках типового бизнес-процесса «На перевод»
Осуществление лингвистического перевода в рамках любого бизнес-процесса путем добавления
соответствующего элемента бизнес-процесса при его конструировании
Порядок обработки документов
Для обработки в СЭД должны быть пригодны как уже находящиеся в хранилище системы
документы, так и новые документы, создаваемые сотрудниками в рамках выполнения какой-либо
задачи.
По завершении СЭД процесса, в зависимости от требований процесса, документы, участвующие в
процессе, должны иметь возможность быть как автоматически удаленными из системы, так и
оставленными в хранилище системы – в зависимости от условий бизнес-процесса.
Создание документов
Возможность создания пользователями документов:
– как во внешних приложениях (ПО сканирования, MS Office, Open Office и т.п.), с последующей
загрузкой этих документов в СЭД,
– так и в СЭД-среде с использованием автоматически предоставляемых СЭД актуальных шаблонов,
заготовки типовых документов, с автоматическим открытием для наполнения таких шаблонов
соответствующим ПО (MS Office).
Создание документов на основе шаблонов, включающих унифицированные формы документов,
унифицированные тексты (приказов, распоряжений, служебных записок и т.д.), типовые
нормативные документы (типовые положения, типовые правила и др.).
Регистрация документов в СЭД
Формирование регистрационного индекса, направленного на возможность однозначной
идентификации документа, а также обеспечение возможности его поиска и ссылок на него.
Возможность осуществления регистрации документов в пределах групп документов, в зависимости
от названия вида документа, автора и содержания документа.
3.1
3.2
3.3
3.4
4
4.1
4.2
5
5.1
5.2
6
6.1
6.2
6.3
Регистрация повторных документов, с одинаковым содержанием и разными идентификационными
признаками.
6.4
Возможность резервирования и замены регистрационных номеров
6.5
7
7.1
7.2
7.3
7.4
8
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
9
9.1
9.2
9.3
10
10.1
10.2
Возможность создания неограниченного количества фасетов регистрационного номера. При этом
источником фасета должны быть, как минимум, следующие сущности: Нумератор, Справочник,
Реквизит карточки, константа, дата в формате DDMMYYYY или ручной ввод.
Контроль исполнения документов
Формирование напоминаний руководителю и исполнителю о сроке исполнения.
Получение руководителем информации о ходе и результатах исполнения.
Запись истории исполнения.
Информирование руководителей о состоянии и результатах исполнения документов, формирование
отчетов о контролируемых и исполненных документах.
Обработка документов в СЭД
Выполнение закреплённых в инструкции Заказчика по делопроизводству регламентов прохождения
документов в процессах электронного документооборота.
Возможность выдачи множества поручений по одному документу/Возможность выдачи поручений и
подпоручений.
Поддержка последовательного/параллельного/комбинированного согласования для определенных
типов документов
Возможность отображения не созданных заданий в дереве заданий в рамках бизнес-процесса
(например, задание согласующему при последовательном согласовании)
Возможность визуального конструирования бизнес-процессов.
Возможность разрабатывать путем программирования новые элементы бизнес-процесса и
использовать их при конструировании.
Возможность при конструировании бизнес-процесса или карточки документа указать группу, в
которой расположены пользователи или роль карточки документа. В результате этой настройки
пользователи должны подставляться автоматически.
Возможность создания из карточки задания подчиненного бизнес-процесса. Уровень вложенности
процессов не должен ограничиваться.
Назначение заданий делегатам, изменение настроек делегирования
Хранение документов в СЭД
Для обеспечения регламентов хранения и доступа в СЭД должен использоваться механизм
управления жизненным циклом документа. Для каждой стадии жизненного цикла необходимо
определять набор действий, которые применимы к документу, и круг пользователей, которым эти
действия разрешены. Таким образом, при переводе документа на следующую стадию жизненного
цикла применимые к нему регламенты обработки, хранения и доступа должны меняться
автоматически.
Хранение авторства, даты загрузки и истории изменений (даты и авторства изменений) для каждого
отдельного документа
Функционал отметок об изъятии и возврате документов.
Требования СЭД к безопасности
Подсистема безопасности СЭД обеспечивает выполнение следующих основных задач:
гарантирование сохранности и неизменности документа, исключение несанкционированного
доступа.
Подсистема безопасности СЭД должна поддерживать механизмы Аутентификации пользователей.
Для получения доступа к функциям, данным и документам СЭД пользователи должны
аутентифицироваться — ввести имя и пароль. Для механизма Аутентификации СЭД должен
10.2.1
использовать либо хранимые в системе учетные записи, либо учетные записи из каталогов LDAP
(Active Directory).
Должно быть установлено определенное время продолжительности сессий, по истечении которого
10.3
система завершает любую неактивную сессию.
Подсистема безопасности СЭД должна поддерживать механизмы Авторизации пользователей. Как
минимум, должны быть предусмотрены возможности:
– идентификации автора документа;
10.4
– идентификации изменившего документ;
– идентификация пользователя одобрившего/согласовавшего то или иное действие в ходе Рабочего
Процесса (WorkFlow).
10.5
Подсистема безопасности СЭД должна поддерживать механизмы Аудита действий пользователей.
Аудит должен позволять идентифицировать информацию об участниках процесса, действия и
10.5.1 времени совершения события таким образом, чтобы с помощью аудита можно было отследить
хронологию действий пользователей с интересующим документом.
Все значимые события, которые происходят в пределах системы, могут подпадать под аудит и
10.5.2
фиксироваться в журнале аудита. Журнал аудита сохраняется в хранилище.
Уровни аудита (виды событий) - настраиваемые, состояния – Вкл/Выкл, то есть Журнал аудита и
10.5.3
события, которые будут в него сохраняться, должны настраиваться.
Поддержка ЭЦП как средства подтверждения авторства и подлинности документов, а также
10.6
подтверждения выполненных действий при обработке документов
СЭД должна поддерживать расширенную ролевую модель для типа карточки документа,
справочника и бизнес-процесса: условия и матрицу доступа. Ролевая модель должна поддерживаться
для карточки и журнала (списка).
Условие — правило, состоящее из связки параметр-операция-значение. Условие устанавливает связь
между субъектом (например текущим пользователем) и объектом системы (значением, например
полем карточки).
Матрица доступа — таблица соответствия ролей разрешенным операциям для данного вида
карточек.
Правила должны позволять использовать следующие параметры:
 Все — условие задается относительно всех пользователей;
 Я — условие задается относительно текущего пользователя;
 Регистратор – регистратор для текущего журнала;
 Руководитель — условие задается относительно руководителя текущего пользователя;
 Подчиненные — условие задается относительно подчиненных первого уровня текущего
пользователя;
 Все подчиненные — условие задается относительно всех подчиненных текущего
пользователя;
 Заместитель — условие задается относительно заместителя текущего пользователя;
10.7
 Замещаемый — условие задается относительно лица, заместителем которого является
текущий пользователь;
 Все, для кого я первый активный заместитель — условие задается относительно первого
активного заместителя текущего пользователя. Активный – это состояние сотрудника.
 Все, для кого я первый активный постоянный заместитель — условие задается относительно
первого активного заместителя текущего пользователя.
 Все, для кого я первый активный временный заместитель — условие задается относительно
первого активного заместителя текущего пользователя. Данный заместитель считается
временным на основании того, что для него не установлен параметр Постоянный
заместитель в Справочнике сотрудников;
 Все, для кого я временный заместитель — условие задается относительно временного
заместителя текущего пользователя;
 Все для кого я постоянный заместитель — условие задается относительно постоянного
заместителя текущего пользователя;
 Сегодня — условие задается относительно текущей даты (без учета производственного
календаря);
 Сейчас — условие задается относительно текущего момента времени (без учета
производственного календаря);
 Поле – любой реквизит карточки (не применимо для журнала)
Автоматическое продвижение документа по различным стадиям жизненного цикла при выполнении
определенных условий перехода, с соответствующим изменением прав доступа и набора действий,
которые могут осуществлять с документом пользователи. Например: проект приказа до утверждения
10.8
имеет редактируемый формат и доступен только исполнителю и его руководителю, а после
утверждения становится доступным всем сотрудникам, и в него уже нельзя будет вносить
изменения.
4.4
Требования к архитектуре СЭД
Таблица 5. Требования к архитектуре СЭД
№
п/п
I
Описание требования
Требования к функциональной архитектуре
№
п/п
Описание требования
1
СЭД должна состоять из Центрального хранилища СЭД и набора автоматизированных рабочих мест
(АРМ).
2
В СЭД должны быть выделены следующие автоматизированные рабочие места пользователей:
– АРМ Системного администратора;
– АРМ пользователя СЭД (универсальный АРМ).
II
1
2
Автоматизированные рабочие места пользователей СЭД должны быть реализованы с
использованием Web-технологий.
Требования к технической архитектуре
Центральное хранилище СЭД может состоять из нескольких серверных модулей, физически
располагаемых на одном или разных серверах, входящих в состав аппаратного обеспечения СЭД.
Центральное хранилище СЭД должно представлять совокупность компонентов:
– базы данных;
– файловых хранилищ для тел документов;
– Контент-сервера;
– программных расширений (кастомизаций) СЭД;
– индекс-сервера, для обеспечения быстрого и оптимального поиска документов;
– сервера веб-приложений.
3
В качестве системы управления базами данных (СУБД) должна использоваться реляционная СУБД
от известных мировых производителей.
4
Возможность использования фрагментов файловой операционной системы в качестве файловых
хранилищ для тел документов.
5
Контент-сервер должен организовывать хранение информации (в базе данных и файловых
хранилищах) и обеспечивать взаимодействие с ней пользователей СЭД.
6
7
Наличие встроенного механизма индексирования (индекс-сервер) для осуществления быстрого и
оптимального поиска документов , разработанного на основе поисковых машин от мировых
производителей.
На уровне архитектуры платформы в СЭД должна быть заложена возможность масштабирования от
локальной системы масштаба подразделения/небольшого предприятия до масштабов Холдинга, в
том числе, при сохранении существующей бизнес - логики (без необходимости ее
перепрограммирования)
8
Система должна позволять хранить Архив документов в отдельной БД для создания отдельного
плана резервного копирования
9
Возможность хранения типов карточек документов, реквизитов, атрибутов, информацию по
бизнес-процессам и остальной конфигурационной части, а также экземпляров карточек в одной БД,
а файлов документов в другой БД или на файловом хранилище.
10
Реализация операций с файлами документов на базе типовых возможностей платформенного
программного обеспечения
11
Построение бизнес-процессов на одном из продуктов Вендора, являющегося производителем
платформы для СЭД с использованием СУБД от того же Вендора.
12
Должна поддерживаться настройка СЭД как на существующую организационно-функциональную
структуру конкретного объекта автоматизации, так и на возможные горизонтальные изменения этой
структуры, без внесения изменений в исходный текст программы и привлечения разработчика
Системы, за исключением создания бизнес-процессов, не предусмотренных СЭД.
4.5
Требования к функциональным возможностям портала
Таблица 6. Требования к функциональным возможностям портала
№
п/п
1
1.1
Описание требования
Требования к порталу
Требуется разработать дизайн интерфейса портала
Требуется реализовать следующие функциональные модули на портале:
 Веб-часть «Руководство»
 Веб-часть «Наш коллектив»
 Веб-часть «Календарь событий»
 Веб-часть «Доска почета»
 Страница «Материалы для изучения, памятки и инструкции, шаблоны документов»
 Страница «Фото/видео галерея»
 Страница «Статистика посещения страниц»
 Раздел «Новости»
 Раздел «Тема недели»
 Раздел «Объявления»
 Раздел новые сотрудники
 Раздел «Поздравления с Днем Рождения»
 Раздел «Наши именинники»
 Новость дня
 Фотография дня
 Лучшие статьи
 Что нового
 Выступления руководства
 Индустриальные новости
 Блоги руководителей, департаментов
 Карты зданий и этажей
 Транспорт
 Компенсации и льготы
 Развитие карьеры
 Хобби в компании
 Сообщества
 Веб-часть «Руководство»
 Веб-часть «Наш коллектив»
Портал должен поддерживать не менее трех языков: казахский, русский и английский
1.2
1.3
5.
Прочие требования
5.1 Требования к порядку контроля и приемки услуг:
Порядок контроля и приемки услуг производится согласно объему работ, изложенному в настоящей
Технической спецификации.
5.2 Порядок предъявления заказчику результатов оказанных услуг:
Заказчиком и Исполнителем создается совместная Рабочая группа для принятия каждой стадии
выполненных работ. Результатом решений Рабочей группы является протокол и акт сдачи-приемки
выполненных работ.
5.3 Требования к языку документации:
Создаваемая Система электронного документооборота должна быть обеспечена комплектом
документации на русском языке.
5.4 Требования к виду носителей документации:
Разрабатываемая документация должна передаваться Заказчику на бумажном носителе, форматом
А4, а также на электронном носителе (CD с файлами в формате, согласованным с Заказчиком).
5.5 Требования к показателям нагрузки Системы.
СЭД должна поддерживать работу минимального количества пользователей, указанных выше.
СЭД должна обеспечивать обработку минимального объема документооборота, указанного в
Таблица 77.
Таблица 7. Показатели нагрузки
Наименование организации
Количество
сотрудников в
Объем внешнего
документооборота в
организации
ТОО «Научно-исследовательский
институт технологий добычи и бурения
«КазМунайГаз»
250
месяц в среднем (ч\б
сканирование в формате
PDF, разрешение 300 dpi.
300 Гб
5.6 Требования к гарантийному обслуживанию и сопровождению системы
9.6.1. Общие требования
Потенциальный Исполнитель должен предоставить гарантийное обслуживание на все поставляемое
программное обеспечение (в том числе системное и прикладное) на срок не менее 12 (двенадцати) месяцев с
момента подписания Заказчиком акта прием-передачи поставленного ПО.
Требования к гарантийному обслуживанию
Гарантийное обслуживание должно включать в себя следующие мероприятия:
– устранение Потенциальным Исполнителем неполадок, ошибок, сбоев в функционировании
Системы, выявленных в период гарантийного облуживания;
– консультации администраторов и разработчиков Заказчика, а также членов Рабочей Группы
Заказчика по вопросам повышения эффективности, настройки Системы при возникновении сбоев, а
также в случаях, когда Заказчик принимает решение выполнять запросы и устранять инциденты
силами своих сотрудников, сертифицированных по платформе СЭД;
– предоставление консультаций осуществляется по телефону, средствами VOIP, мгновенных
сообщений и электронной почтой;
– предоставление дополнительных программных компонентов (патчей), плановых системных
обновлений системного и прикладного программного обеспечения;
– уведомление о выходе обновленных версий программного обеспечения Системы (updates) с
предоставлением перечня отличий и исправлений от предыдущих версий;
– установка плановых и срочных программных обновлений системы и ее компонентов после
согласования Заказчиком;
– оказание содействия при принятии решения о целесообразности установки того или иного
обновления (update или upgrade);
– плановые обновления системного и прикладного программного обеспечения Системы.
Для обеспечения гарантийного обслуживания Потенциальный Исполнитель должен выделить
персонального менеджера для данного проекта, и информировать Заказчика об этом письменно.
В течение гарантийного срока Потенциальный Исполнитель должен устранять выявленные
неполадки, ошибки, сбои в функционировании Системы в согласованные с Заказчиком сроки. Сроки
устранения определяются совместно сторонами исходя из сложности задачи, но не более чем в течение 10
(десять) рабочих дней со дня сообщения о выявлении неисправностей.
Все расходы, связанные с устранением выявленных неисправностей, должен нести Потенциальный
Исполнитель.
В рамки гарантийного обслуживания не входит доработка Подрядчиком функциональности
Системы, выявленной в период гарантийного обслуживания, при условии, что данная функциональность не
описана в настоящей ТС или техническом задании, и это приведет к переработке функционального ядра
Системы, а именно:
– к изменению реализованных перечня и состава подсистем, модулей и функций Системы,
обозначенных в настоящей ТС и техническом проекте;
– к изменению структуры данных, описанных в техническом проекте;
– к изменению принципов организации информационного обеспечения Системы, описанных в
техническом проекте.
6.
Требования к Сопутствующим Услугам
Таблица 8. Требования к составу Услуг
№
п/п
Наименование услуг/работ
1
1.1
Планирование работ
Планирование работ (определение области охвата, целей и задач проекта,
формирование рабочей группы со стороны Заказчика)
Разработка и утверждение План-графика
1.2
Срок выполнения
7 дней с момента
заключения
договора
Фаза «Планирование работ» считается завершенной, когда:
– утвержден документ «План проекта»;
– сформирована Рабочая группа со стороны Заказчика;
2
2.1
Обследование
Обследование предметной области Проекта, детальное изучение
информационного пространства Заказчика (сбор данных о специфике
ведения документов, автоматизируемых бизнес-процессах, механизмах
интеграции, механизмов хранения документов и др.).
Фаза «Обследование» считается завершенной, когда:
– Разработан и утвержден документ «Техническое задание на создание СЭД»;
– Разработан и утвержден документ «Техническое задание на создание портала»;
– Подписан промежуточный акт сдачи-приемки промежуточных этапов услуг.
Разработка портала
3
Разработка и настройка портала
3.1
3.2
Разработка эксплуатационной документации (руководства пользователя,
администратора).
30 дней с момента
заключения
договора
до 15.12.2014
до 15.12.2014
Фаза «Разработка портала» считается завершенной, когда создан Рабочий проект Системы, включающий
программное обеспечение и следующий комплект эксплуатационной документации:
– Руководство администратора портала;
– Руководство пользователя портала;
– Программа и методика испытаний портала;
- Подписан промежуточный акт сдачи-приемки промежуточных этапов услуг.
Разработка Системы документооборота
4
Разработка, настройка и корректировка бизнес-процессов Системы
документооборота, разработка подсистем хранения документов,
4.1
согласования доступа, маршрутов обработки документов, 4 отчетных
до 15.12.2014
формы.
Разработка эксплуатационной документации (руководства
4.2 пользователя, администратора).
до 15.12.2014
Фаза «Разработка Системы документооборота» считается завершенной, когда создан Рабочий проект
Системы, включающий программное обеспечение и следующий комплект эксплуатационной документации:
– Руководство администратора;
– Руководство пользователя;
– Программа и методика испытаний;
– Подписан промежуточный акт сдачи-приемки промежуточных этапов услуг.
5
Поставка Лицензионного программного обеспечения под задачи СЭД
7 дней с момента
заключения
договора
Лицензионное программное обеспечение платформы для
30 дней с момента
5.2 лингвистического перевода
заключения
договора
Фаза «Поставка Лицензионного программного обеспечения под задачи СЭД» завершается
подписанием акта сдачи-приемки товара.
Опытная эксплуатация
6
Установка системы на технических средствах Заказчика (подготовка
инфраструктуры эксплуатации Заказчика, инсталляция Рабочего проекта у
6.1 Заказчика, обучение группы тестирования, наполнение Системы
контентом, тестирование Рабочего проекта у Заказчика, доработка
Рабочего проекта по результатам тестирования).
до 20.12.2014
Обучение пользователей Системы на территории Заказчика в г. Астана.
Обучение администраторов Системы (2 человека).
6.2
Проведение презентации по использованию СЭД.
до 25.12.2014
6.3 Тестирование Системы.
до 25.12.2014
5.1
Лицензионное программное обеспечение СЭД (на 250 клиентских
подключений)
6.4
6.5
Опытная эксплуатация Системы.
Доработка Системы по результатам опытной эксплуатации проекта.
до 26.12.2014
до 28.12.2014
Фаза «Ввод системы в опытную эксплуатацию» считается завершенной, когда:
– Система установлена на технических средствах Заказчика;
– Обучены пользователи и администраторы Системы;
– Подписан «Протокол проведения обучения»;
– Сформирован и утвержден документ «Журнал замечаний по результатам опытной эксплуатации»;
– Подписан «Акт приемки Системы в опытную эксплуатацию».
7
Ввод системы в эксплуатацию
Приемка в эксплуатацию
7.1
Фаза «Ввод системы в эксплуатацию» считается завершенной, когда:
– Подписан «Акт ввода эксплуатацию».
Гарантийная поддержка
8
После устранения
всех замечаний
опытной
эксплуатации
В течение 12
месяцев после
подписания акта
прием-передачи
поставленного ПО