Финансово-бухгалтерская и договорная документация ⇐ ПредыдущаяСтр 2 из 2
Оказание услуг	- договор - счет-фактура - акт оказанных услуг - отчет
Приобретение ТМЦ, основные средства	- договор - счет-фактура - ТОРГ-12
Приобретение основных средств	- договор - счет-фактура - ТОРГ-12
Капитальный ремонт объектов основных средств	- договор - счет-фактура - акт о приемке выполненных работ (КС-2) - справка о стоимости выполненных работ и затрат (КС-3) - общий журнал работ (КС-6)
Капитальное строительство	- договор - счет-фактура - акт о приемке выполненных работ (КС-2) - справка о стоимости выполненных работ и затрат (КС-3) - общий журнал работ (КС-6) - акт приемки законченного строительством объекта приемочной комиссией (Унифицированная форма N КС-14)
Организационно-распорядительная документация
ОРД по основной деятельности	- приказ - распоряжение - протокол - приложение
Договорная документация
Договор	- договор - приложение к договору
Акты разграничения
Акт разграничения	- акт разграничения балансовой принадлежности сторон - акт разграничения эксплуатационной ответственности сторон

 

Атрибутивный состав перечисленных выше документов должен быть универсальным для каждого вида документа, независимо от того, к какому типу он относится. Например, реквизитный состав вида документа «Договор» должен быть единым для всех типов документации.

Система должна предусматривать возможность расширения в будущем (вне рамок проекта) перечня типов документов и данных, подлежащих хранению в ЭА.

ТРЕБОВАНИЯ К СИСТЕМЕ

Требования к функциональным возможностям платформы для ЭА

Используемая для разработки Системы платформа должна позволить сократить стоимость и сроки внедрения, реализовать решение, которое будет полностью удовлетворять требованиям Заказчика, а также обеспечит надежную базу для решения будущих задач в области управления информационными активами и бизнес-процессами Заказчика.

Требования к вендору платформы

Производитель платформы должен иметь:

- официального дистрибьютора/партнерскую сеть на территории РК (подтверждается официальным письмом потенциального поставщика в составе тендерной заявки с указанием наименования и адресов официального дистрибьютора/партнерской сети);

- партнерскую сеть с сертифицированными Разработчиками по данной Платформе на территории РК (подтверждается официальным письмом потенциального поставщика в составе тендерной заявки с указанием наименования и адресов партнерской сети).

4.3 Общие требования к платформе

4.3.1 Платформа должна гарантировать возможность развития Системы, без изменений интерфейса пользователей уже имеющихся подсистем (за исключением изменений от плановых обновлений ПО), а также обладать интеграционными возможностями с финансово-экономической системой SAP ERP;

4.3.2 ЭА должен быть реализован на платформе управления контентом;

4.3.3 Платформа должна использовать объектную модель хранения данных, т.е. должна быть явная классификация данных по Типам. Тип может иметь свой набор полей (атрибутов) и методов. Должны быть развиты механизмы ООП – такие как: Наследование типов, Аспекты, другие механизмы.

4.3.4 Платформа должна поддерживать использование раздельного хранения Объектов: поля объектов хранятся в СУБД, содержимое объектов (документов, кодов методов – программ обработки) в структурированной файловой системе;

4.3.5 Платформа должна обеспечить поддержку данных и интерфейса на нескольких языках, в том числе: казахский, русский, английский;

4.3.6 Платформа должна обеспечить поддержку просмотра файлов в следующих форматах: .JPG, .PNG, .BMP, .TIFF, .PDF.

Требования к масштабированию

Для обеспечения высокого уровня производительности Система должна обладать следующими возможностями:

• возможностью аппаратного и программного масштабирования по мере возрастания нагрузки, связанной как с ростом количества обращений к ЭА, так и с увеличением объема хранимой информации;

• возможностью функционального поэтапного расширения в рамках единой аппаратно-программной платформы.

 

4.4.1 Архитектура ЭА должна быть масштабируемой в части производительности и вычислительных мощностей без существенного изменения архитектуры;

4.4.2 ЭА должен иметь возможность в последствии работать не только с приложениями SAP;

4.4.3 Платформа ЭА должна иметь возможность последующего расширения функционала в части работы с документами и контентом до полноценных систем управления контентом (ECM, EIM).

 

Требования к средству поиска платформы

4.5.1 Платформа должна предоставить средство Поиска;

4.5.2 Модуль Поиска должен полностью учитывать Объектную модель хранения – то есть позволять проводить поиск, с учетом Типов, как по атрибутам, так и по содержимому документов (контекстный поиск);

4.5.3 Модуль Поиска должен поддерживать различные варианты развертывания Системы – как в минимальной конфигурации развертывания – все на одном сервере, так и в конфигурации, разнесенной по различным серверам, в том числе и модуль Поиска – на отдельном сервере.

Требования к средствам ограничения доступа платформы

4.6.1 Платформа должна обеспечивать автоматизацию режима ограничения доступа;

4.6.2 Платформа должна предоставлять базовые средства Аутентификации. Как минимум, для получения доступа к функциям, пользователи должны аутентифицироваться – ввести имя и пароль. Для механизма Аутентификации должны использоваться либо хранимые в системе учетные записи, либо учетные записи из каталогов LDAP (Active Directory);

4.6.3 Платформа должна предоставлять API и Интерфейс для объединения пользователей в Группы. Один пользователь может находиться одновременно сразу в нескольких группах. Группы создаются по необходимости;

4.6.4 Платформа должна предоставлять API и Интерфейс для назначения пользователю тех или иных Ролей. Один пользователь может обладать сразу несколькими ролями. Роли создаются по необходимости;

4.6.5 Платформа должна предоставлять API и Интерфейс для составления схем доступа (ACL) с указанием доступных основных уровней доступа и расширенных полномочий для конкретного пользователя, группы либо роли. Основные уровни доступа указываются всегда, расширенные – по необходимости;

4.6.6 Перечень расширенных полномочий должен включать в себя, как минимум, такие полномочия как:

- смена владельца объекта;

- смена прав доступа на объект;

- другие расширенные полномочия.

Расширенные полномочия, в отличие от основных, не включают в себя предыдущие и указываются в ACL прямым перечислением требуемых расширенных прав.

Требования к структуре системы

4.7.1 Система должна иметь многозвенную архитектуру:

- первое звено системной архитектуры – сервер СУБД;

- второе звено системной архитектуры – контент-сервер, на котором размещается защищённое хранилище неструктурированной информации и реализуется документно-ориентированная бизнес-логика;

- третье звено – клиентские рабочие места;

- четвертое звено ‑ интеграционные компоненты, обеспечивающие взаимодействие с финансово-экономической системой SAP ERP.

4.7.2 Компоненты реализации бизнес-логики должны включать:

- формализованные описания и системные настройки жизненных циклов (ЖЦ) документов;

- компоненты пользовательского интерфейса, адаптированные к решению задач автоматизации ЭА.

4.7.3 ЭА должен быть реализован в составе:

- прикладных функций;

- общего программного обеспечения;

- комплекса технических средств.

4.7.4 Общее программное обеспечение ЭА должно включать:

- прикладное программное обеспечение, в том числе для реализации технологий управления документами – базовое ПО ЭА (ECM-платформу);

- системное программное обеспечение, в том числе: операционную систему; систему управления базами данных; сервер приложений; доменную службу каталогов (Active Directory).

 

 

Требования к режимам функционирования системы

Система должна быть доступна пользователям 24 часа в сутки, 7 дней в неделю, за исключением периодов времени, необходимых для проведения регламентных технических работ. Периодичность, длительность и состав регламентных работ должны быть определены на этапе проектирования.

Требования к квалификации пользовательского персонала системы

Пользователи ЭА должны обладать необходимой квалификацией для полнофункциональной и эффективной эксплуатации Системы. Объем минимально необходимых знаний и навыков:

· владение компьютером и периферийной техникой (принтер, сканер и т.п.) на уровне рядового пользователя;

· знание основ операционной системы MS Windows;

· навыки использования клиентского интерфейса;

· знание нормативно-методической документации и стандартов Заказчика.

Перед подключением пользователя к ЭА должна проводиться проверка его квалификации. Для обеспечения требуемого уровня квалификации пользователи должны проходить начальную и периодическую подготовку. Периодически должен осуществляться контроль знаний и навыков пользователей ЭА (например, в рамках регулярной аттестации).

Администраторы ЭА должны обладать необходимой квалификацией для эффективной эксплуатации Системы. Объем минимально необходимых знаний и навыков, а также рекомендуемых курсов, должен быть определен на этапе проектирования.

 

Требования к эксплуатации и техническому обслуживанию системы

Условия эксплуатации и характеристики окружающей среды в помещениях размещения Системы должны соответствовать Санитарно-эпидемиологическим Правилам и Нормам СанПиН – «Гигиенические требования к персональным электронно-вычислительным машинам и организации работ» а также требованиям производителей используемых аппаратных средств.

Оборудование Системы должно сохранять возможность функционирования при следующих параметрах окружающей среды:

· температура воздуха – от +10С до +25С;

· относительная влажность воздуха – от 40% до 80%;

· атмосферное давление – от 630 до 800 мм. рт. ст.

Содержание пыли в серверных помещениях и помещениях хранения магнитных носителей не должно превышать 0.3 мг/м3, в рабочих помещениях (в которых осуществляется хранение и работа с информацией на бумажных носителях) не должна превышать 6 мг/м3 (ГОСТ РК).

В процессе эксплуатации Системы должны быть предусмотрены следующие виды ее технического обслуживания:

· ежедневное (или еженедельное) техническое обслуживание;

· ежемесячное техническое обслуживание;

· полугодовое техническое обслуживание;

· ежегодное техническое обслуживание.

Техническое обслуживание Системы должны выполнять технические администраторы численностью не менее 2 человек (с учетом отпусков и т.п.)

Резервные копии текущих версий прикладного программного обеспечения Системы, централизованно сохраняемых баз данных и информационных массивов должны храниться централизованно и быть доступны для использования только обслуживающему персоналу.

Техническое обслуживание аппаратных средств, на которых функционирует Система, должны выполнять технические администраторы в соответствии с эксплуатационной документацией на эти средства.

Требования к безопасности системы

4.11.1 Подсистема информационной безопасности ЭА должна обеспечить достижение следующих целей:

· противодействие попыткам несанкционированного доступа к защищаемой информации;

· пресечение попыток несанкционированного считывания, изменения и уничтожения данных;

· целостность данных;

· возможность криптографической защиты конфиденциальной информации.

4.11.2  Все информационные объекты и документы, хранимые в ЭА, должны быть защищены по матричной схеме безопасности. Матрица уровней доступа, который назначается пользователям, должна создаваться и редактироваться в защищенном редакторе Системы, к которому должны иметь доступ только администраторы Системы.

4.11.3 Программные средства обеспечения безопасности Системы не должны существенно ухудшать основные ее функциональные характеристики (надежность, быстродействие, возможность изменения конфигурации).

4.11.4 ЭА предназначен для обработки информации, составляющей коммерческую тайну, и иной конфиденциальной информации АО «KEGOC», в том числе персональных данных.

4.11.5 Перечень информации, обрабатываемой в системе, составляющей коммерческую тайну и иную конфиденциальную информацию будет определен Заказчиком на фазе проекта «Реализация и тестирование».

4.11.6 Система должна предусматривать наличие встроенных функций идентификации и аутентификации, протоколирования и ведения журналов событий, а также предусматривать встроенные функции для проверки и установки обновлений.

4.11.7 Разработка Системы должна производиться с учетом утвержденных корпоративных стандартов в области ИБ в АО «KEGOC», рекомендаций по обеспечению информационной безопасности Фонда. ЭА должен удовлетворять требованиям Правительства РК к защите персональных данных при их обработке в информационных системах персональных данных.

4.11.8 Базовым способом аутентификации пользователей в Системе должна быть аутентификация пользователей через систему единого входа Заказчика (Single Sign-On, SSO), с использованием технологии LDAP. Кроме того, должна быть возможность аутентификации по сочетанию персонального идентификатора имени пользователя (логина) и пароля. Периодичность смены и сложность паролей должны назначаться администратором Системы.

4.11.9 Система должна предусматривать возможность подключения подсистем электронного шифрования и электронной подписи (ЭП).

4.11.10 Система должна предусматривать возможность хранения документов в зашифрованном виде. Реализация данной возможности в рамках настоящего проекта не планируется. В будущем данная возможность может быть обеспечена путем приобретения Заказчиком лицензий на специализированное ПО. В случае перехода к зашифрованному виду хранения документов должна быть обеспечена возможность перевода в зашифрованный вид всех накопленных в Системе документов (или части из них – ДСП, конфиденциальных и т.п.).

4.11.11 Подсистема безопасности ЭА поддерживает механизм Авторизации пользователей. Как минимум, предусмотрены возможности:

 - идентификации автора документа;

- идентификация пользователя одобрившего/согласовавшего то или иное действие в ходе рабочего процесса (WorkFlow)

4.11.12 Подсистема безопасности ЭА поддерживает механизмы Аудита действий пользователей. Аудит позволяет идентифицировать информацию об участниках процесса, действия и времени совершения события таким образом, чтобы с помощью аудита можно было отследить хронологию действий пользователей с интересующим документом. Все значимые события, которые происходят в пределах системы, могут попадать под аудит и фиксироваться в журнале аудита. Журнал аудита сохраняется в хранилище.

4.11.13 Автоматическое продвижение документа по различным стадиям жизненного цикла при выполнении определённых условий перехода, с соответствующим изменением прав доступа и набора действий, которые могут осуществлять с документом пользователи.

4.11.14 В ЭА должны быть предусмотрены:

· возможность создания групп видов доступа и групп пользователей с заданными правами доступа. Виды доступа (для отдельных пользователей и для групп пользователей):

- полный доступ к документу;

- право на создание и редактирование;

- право на удаление;

- право на просмотр документа;

- право на доступ к учетной карточке (но не к документу) без права ее редактирования;

- документ не виден для пользователя.

· возможность назначения прав доступа к документам в соответствии с иерархической структурой Заказчика и определение прав доступа на основе принадлежности к определенному подразделению Заказчика;

· разграничение прав доступа к документу в зависимости от состояния документа (проект, согласован, утвержден, передан в архив и т.п.);

· разделение прав доступа по документам, папкам, объектам, по роли пользователя, по принадлежности к подразделению и занимаемой пользователем должности;

· возможность идентификации и проверки подлинности субъектов доступа при входе в Систему. Обеспечить доступ в Систему только для зарегистрированных пользователей, прошедших процедуру идентификации и аутентификации в домене;

· регистрация входа субъектов доступа в Систему. При регистрации должны указываться параметры: дата и время входа, идентификатор субъекта.

Требования по сохранности информации при авариях

После сбоя серверной операционной системы или СУБД в процессе выполнения пользовательских задач должно быть обеспечено восстановление информации в базе данных до состояния на момент окончания последней нормально завершенной перед сбоем транзакции.

При разработке эксплуатационной документации на Систему (руководства администратора) Исполнителем должна быть составлена классификация потенциально возможных ситуаций сбоя/отказа с указанием приоритета отработки, назначаемого каждой ситуации.

Выход из строя одного из ПК или нарушение канала связи между ПК и сервером не должны приводить к прекращению функционирования Системы.

Система должна обеспечивать возможность «горячей» замены сбойного или вышедшего из строя активного накопителя на жестком магнитном диске без остановки функционирования Системы и потерь информации. В Системе должна быть обеспечена возможность восстановления данных с внешнего накопителя после восстановления активного накопителя.

Требования к графическому интерфейсу и дизайну

Пользовательский интерфейс ЭА должен удовлетворять следующим требованиям по эргономике и технической эстетике:

· обеспечивать минимум усилий пользователя для навигации по ресурсам ЭА;

· обеспечивать легкую идентификацию раздела, в котором находится пользователь;

· обладать системой подсказок в местах, где у пользователя потенциально могут возникнуть затруднения;

· обеспечивать выполнение допустимых визуальных параметров отображения информации;

· обеспечивать приемлемый результат при распечатке страниц ЭА на принтере.

Требования к надежности системы

Надежность Системы в целом должна быть обеспечена за счет:

· надежности используемых технических средств (серверное оборудование, сетевое оборудование, рабочие станции пользователей);

· технической архитектуры Системы;

· надежности используемых программных средств (системное программное обеспечение, прикладное программное обеспечение);

· квалификации персонала;

· организации работ по техническому обслуживанию Системы.

Для обеспечения надежности технических средств АО «KEGOC»:

· должны использоваться технические средства повышенной отказоустойчивости с возможностью структурного резервирования;

· должна быть предусмотрена возможность поэлементного резервирования за счет:

- защиты технических средств от кратковременных перебоев в электропитании с помощью источников бесперебойного питания;

- использования отказоустойчивых дисковых массивов, отказоустойчивых серверных решений, ленточных накопителей;

- полного или частичного дублирования активного сетевого оборудования, к которому подключаются критически важные компоненты ЭА;

- дублирования подключения компонентов ЭА к активному сетевому оборудованию.

Для обеспечения надежности прикладного программного обеспечения АО «KEGOC»:

· должно использоваться только промышленное ПО;

· компоненты используемого прикладного ПО не должны нарушать целостности друг друга.

Система должна обеспечивать возможность построения различных схем резервирования данных. Должна быть предусмотрена поддержка «горячего» резервного копирования данных Системы без ее остановки.

Для обеспечения устойчивости к отказам электроснабжения все устройства хранения и обработки информации должны быть подключены к сети гарантированного электроснабжения. Время гарантированной работы для завершения серверных и прикладных приложений в случае отключения энергоснабжения, обеспечиваемое источниками бесперебойного питания, должно быть не менее 30 минут.

Требования к патентной чистоте системы

Проектные решения построения ЭА должны отвечать требованиям по патентной чистоте согласно действующему законодательству РК.

Должны соблюдаться положения нормативных правовых актов РК по соблюдению авторских прав и защиты специальных знаков.

Программное обеспечение и алгоритмы, разработанные в соответствии с требованиями настоящей ТС, не должны являться предметом претензий о нарушении патентного права любой третьей стороны.

Программное обеспечение и алгоритмы, разработанные в соответствии с требованиями настоящей ТС, должны быть защищены в соответствии с международными законами и законодательством РК.

Требования к производительности системы

При указанных параметрах ЭА должен обеспечивать отклик на запрос пользователя не более чем через 10 сек. для наиболее продолжительных в обработке запросов, и не более чем через 3 сек. – для большинства (90%) запросов. Полная загрузка страницы с результатами обработки запроса должна происходить за время не более 5 сек. для 90% пользовательских запросов и не более 30 сек. – для остальных 10% запросов. Исключение могут составлять первоначальные запросы подключения к ЭА и запросы, связанные с генерацией отчетов; для этих двух категорий запросов скорость обработки запроса может варьироваться в пределах от 1 минуты до нескольких (не более 5) минут.

Технические рекомендации по размерам размещаемых в ЭА файлов должны быть приведены разработчиком в руководствах администраторов и пользователей.

В ходе опытной эксплуатации ЭА должны быть проведены измерения достигнутой производительности и, в случае необходимости (при неудовлетворительном, т.е. не соответствующем ТЗ значении параметров производительности), должна быть проведена настройка системных параметров программного обеспечения ЭА, гарантирующая достижение требуемых значений производительности.

Требования к доступности и допустимому времени простоя

Высокая степень доступности Системы в течение эксплуатации, а также надежное хранение данных должны быть обеспечены следующими техническими и организационными мерами:

· проведения регулярного резервного копирования данных Системы;

· включением в руководство администратора Системы подробного описания процедуры регулярного резервного копирования и восстановления данных в случае сбоя;

· включением в должностную инструкцию системного администратора пункта о резервном копировании и восстановлении данных Системы.

Максимально допустимое Целевое Время Восстановления (Recovery Time Objective, RTO) для Системы должно составлять не более 8 часов с учетом времени восстановления данных из резервной копии.

Максимально допустимая потеря данных (Целевая Точка Восстановления (Recovery Point Objective, RPO) для Системы должна составлять не более 4 часов.

4.18 Общие требования к документированию

Проектные документы должны быть представлены Заказчику на бумажном (оригинал) и на электронном (компакт-диск, flash-card – копия) носителях, по одному экземпляру на каждом носителе.

Документация ЭА не должна противоречить руководящим и нормативным документам уровня РК, корпоративным требованиям, требованиям нормативных документов АО «KEGOC», а также требованиям настоящего документа.

Передача утвержденных версий документов осуществляется в формате PDF. Титульный лист и листы согласований должны быть представлены в виде сканов, содержащих подписи лиц согласующих и утверждающих эти документы.

Состав проектной, эксплуатационной и методико-регламентной документации, выпускаемой по результатам проведения работ на различных фазах проекта, приведен ниже.

В пакет документации на Систему должны входить следующие документы:

· частное техническое задание;

· пояснительная записка к техническому проекту;

· технический проект (описание настроек и разработок);

· комплексная программа и методика испытаний;

· технический паспорт Системы;

· протокол приемо-сдаточных испытаний;

· журналы опытной эксплуатации;

· акт приемки Системы в опытно-промышленную эксплуатацию;

· акт приемки Системы в промышленную эксплуатацию;

· укрупненный ресурсный план на всю длительность реализации проекта;

· спецификации на разработки заказного программного обеспечения;

· сценарии комплексных испытаний;

· программа и методика комплексных испытаний;

· документы по описанию конфигурации системы;

· технические спецификации объектов разработки (RICEFW);

· концепция технической поддержки;

· политика управления ролями и полномочиями;

· сценарии функционального тестирования;

· протокол подготовки данных для загрузки в тестовую систему;

· протоколы устранения замечаний в соответствии с Реестром замечаний;

· программа обучения конечных пользователей;

· протокол загрузки начальных данных;

· протокол загрузки нормативно-справочной информации;

· операционные инструкции конечных пользователей;

· технологические инструкции конечных пользователей;

· проектная и эксплуатационная документация ЭА;

· протокол приемочных испытаний.

 

ТРЕБОВАНИЯ К ФУНКЦИЯМ, ВЫПОЛНЯЕМЫМ СИСТЕМОЙ

Требования к организации хранения данных

ЭА предназначен для хранения:

· первичных финансово-бухгалтерских документов;

· договорных документов;

· организационно-распорядительных документов.

Перечень типов и видов документов приведен в Таблице 3.

Хранимые документы могут быть представлены в виде электронных (графических) образов бумажных документов, созданных с помощью средств сканирования или полученных по факсимильной связи (форматы TIFF, GIF, BMP, JPEG, PDF и прочие).

ЭА должен обеспечивать хранение документов, исходя из следующих количественных показателей прироста документов:

· организационно-распорядительные и договорные документы – 10000 док./мес.;

· первичные бухгалтерские (финансовые) документы – 5000 док./мес.;

· средний объем документа – 550 Кб.

ЭА должен поддерживать иерархическое хранение данных с учетом технологических особенностей базового ПО ЭА (платформы ECM). Политики управления иерархическим хранением данных должны базироваться как на системных параметрах объектов (размер, дата создания, дата изменения, дата последнего обращения, частота обращений), так и на прикладных параметрах (тип объекта, классификатор объекта и т.д.) с учетом технологических ограничений базового ПО ЭА. В Системе должно быть обеспечено автоматическое и ручное перемещение объектов между уровнями хранения. Уровни хранения данных и их количество должны быть определены на этапе проектирования Cистемы.

Для организации хранения документов в ЭА должна использоваться регистрационная карточка, содержащая набор атрибутов объекта хранения. Вид карточки должен соответствовать типу документа (формы карточек и набор атрибутов для каждого типа и вида документов должны быть окончательно определены на этапе проектирования ЭА). Регистрационная карточка документа должна позволять присоединять несколько файлов контента.

ЭА должен позволять объединение взаимосвязанных документов в единый комплект документов, так называемый «пакет». Требования к пакетам документов должны быть определены на этапе проектирования Системы.

Документы должны храниться в ЭА постоянно без установления сроков хранения.

Изменение статуса документа, установка/удаление связи между документами, добавление новой версии документа должны фиксироваться в истории документа.

Требования к вводу данных в Систему

Должна быть возможность ввода документов в ЭА вручную, а также их передачи из SAP ERP.

При создании (вводе) документа в ЭА его учет в Системе должен осуществляться путем создания регистрационной карточки документа соответствующего типа и вида, связанной с добавляемым файлом.

Должна быть обеспечена возможность введения предустановленных для пользователя значений атрибутов, при этом должны применяться соответствующие справочники.

Система должна предоставлять возможность установки ссылочных связей между регистрационными карточками документов.

ЭА должен предоставлять возможность ведения и сравнения версий документов.

Требования к управлению жизненным циклом объектов хранения

Система должна предоставлять возможности по управлению жизненным циклом объектов хранения.

Жизненные циклы объектов хранения должны быть описаны на этапе проектирования Системы.

Требования к организации доступа к данным

Доступ к данным ЭА должен быть возможен как из пользовательского интерфейса ЭА, так и по прямым ссылкам из SAP ERP с учетом разграничения прав доступа.

Управление доступом к документам должно быть организовано, с одной стороны, в соответствии с ролями участников соответствующего бизнес-процесса:

· на чтение / просмотр – всем участникам процесса;

· на создание / изменение текста документа / версии документа, его карточки – в соответствии с выполняемой бизнес-функцией участника в процессе;

с другой стороны, в соответствии с функциональными ролями ЭА:

· читатель – поиск и получение доступа к объекту в ЭА в соответствии с правами доступа подразделения пользователя;

· специалист хранилища (архивариус) – возможность ручного ввода данных в хранилище и работа с инструментами по автоматизированной загрузке данных;

· администратор хранилища – предоставление доступа, назначение ролей, ведение справочников.

Кроме того, при организации доступа к данным хранилища должен учитываться иерархический принцип: все вышестоящие в иерархии подразделения должны иметь доступ на чтение к документам и данным нижестоящих подразделений.

Требования по количеству пользователей и одновременной работе

Количество пользователей Системы должно быть масштабируемо до 2 000 человек.

Количество пользователей, одновременно работающих с Системой, составит не менее 20% от общего количества пользователей.

Требования к интерфейсу пользователя

Интерфейс пользователя должен представлять собой каталог документов, доступный для просмотра в соответствии с правами доступа. Должна быть возможность перехода по структуре организации в рамках текущего положения в иерархии организации.

В ЭА должна предоставляться возможность сортировки и фильтрации объектов по значениям отображаемых атрибутов.

Система должна поддерживать настраиваемый интерфейс рабочего места пользователя в зависимости от ролей пользователя.

Требования к отчетности

Функционал ЭА должен предоставлять возможность формирования отчетности на произвольную дату. Перечень отчетов должен быть уточнен на этапе проектирования Системы.

Вся отчетность должна иметь возможность экспорта данных во внешние форматы данных (CSV, XLS, PDF и т.д.) для последующей обработки, а также возможность вывода на печать.

Отчеты должны поддерживать как табличное отображение, так и графическое (графики, гистограммы и т.п.)

Требования к поисковому модулю

Данные в ЭА должны содержать параметры, позволяющие осуществлять индексацию, удобный поиск и систематизацию.

ЭА должен обеспечивать:

· атрибутивный поиск – по реквизитам регистрационной карточки;

· полнотекстовый поиск на русском и казахском языках– по тексту (содержанию) документа, расположенному в хранилище и представленному в текстовом формате;

· формирование состава полей поисковой формы (критерии отбора) с учетом набора атрибутов каждого вида объекта поиска;

· возможность построения комбинированных запросов по атрибутам и при полнотекстовом поиске;

· возможность сохранения поисковых запросов для их повторного использования;

· соблюдение разграничения прав доступа – в результаты поиска должны отбираться только те документы, которые доступны для просмотра осуществляющему поиск пользователю Системы в соответствии с настройками прав доступа в электронном хранилище документов.

Требования к функциям администрирования

Функции администрирования Системы должны предоставлять администратору возможность производить в ЭА:

· управление справочниками ЭА, содержащими значения полей регистрационных карточек документов;

· управление записями о пользователях: создание, редактирование, деактивация/активация записей пользователей;

· управление правами доступа к информационным объектам ЭА c учетом реализованной в базовом ПО ЭА модели информационной безопасности;

· управление параметрами ЭА;

· выполнение других операций по поддержке функционирования ЭА.

Требования к журналированию событий в Системе

ЭА должен поддерживать процессы протоколирования всех операций в Системе с фиксированием времени события и идентификатора пользователя, с возможностью выгрузки детализированных отчетов, а также давать возможность отслеживать информацию по возникающим ошибкам в Системе и составлять по ним отчеты.

Журналирование событий в Системе должно использовать стандартные возможности ECM-платформы.

Требования к модулю интеграции

Необходимо разработать на стороне ЭА универсальный интеграционный сервис / набор сервисов для обмена данными с SAP ERP. Данный сервис / набор сервисов должен обеспечивать:

· размещение информации в ЭА:

- передача атрибутов и содержимого документа и приложений к нему из автоматизированной информационной системы в ЭА с возвратом идентификаторов (ID) файла документа и приложений в ЭА;

- при необходимости ‑ проверка полученных атрибутов на соответствие значениям справочников, запрос корректных атрибутов;

- передача из ЭА в автоматизированную информационную систему прямой ссылки на документ в ЭА;

· изменение информации в ЭА:

- передача из автоматизированной информационной системы в ЭА изменяемых атрибутов и /или изменяемого содержимого документа или приложений к документу;

- при необходимости ‑ проверка полученных атрибутов на соответствие значениям справочников, запрос корректных атрибутов;

- передача из ЭА в автоматизированную информационную систему прямой ссылки на документ в ЭА (при ее изменении);

· запрос на поиск информации в ЭА:

- передача из автоматизированной информационной системы в ЭА параметров поиска информации;

- передача из ЭА в автоматизированную информационную систему результатов поиска;

· извлечение информации из ЭА:

- передача атрибутов и содержимого документа и приложений к нему из ЭА в автоматизированную информационную систему по идентификаторам (ID) файла документа и приложений в ЭА.

В частности, с помощью данного сервиса / набора сервисов ЭА должна быть обеспечена возможность интеграции: C финансово-экономической системой SAP ERP (в карточке договора в SAP должна быть ссылка на файл/файлы договора и файлы связанных с договором счетов-фактур в ЭА);

Основные требования к функциям механизма интеграции следующие:

· должна обеспечиваться полнота и корректность передаваемой информации между системами;

· должна обеспечиваться надежность передачи информации в рамках кросс-системных процессов;

· должен быть обеспечен мониторинг потоков информации с возможностью отслеживания ошибок и нештатных ситуаций;

· должны быть предусмотрены механизмы автоматизированного восстановления процессов обмена данными в случае возникновения нештатных ситуаций.

При создании интеграционных схем необходимо базироваться на следующих принципах:

· реализация концепции по построению бизнес-приложений и формированию архитектуры корпоративных сервисов;

· взаимодействие интегрируемых систем по принципу шины. Каждая интегрируемая система должна представлять набор сервисов/интерфейсов и быть максимально абстрагирована от остальных участников информационного взаимодействия;

· использование встроенного инструментария для мониторинга и журналирования передаваемых данных, контроля доставки и повторной передачи;

· использование средств управления приоритетами передачи данных и управления производительностью на основе очередей.

Кроме того, ЭА должен обеспечивать возможность рассылки информационных сообщений (в том числе по электронной почте) и поддерживать функционал ЭП.

Реализация механизма интеграции на стороне других информационных систем, таких как SAP ERP, АСУД и АИСБД, не входит в рамки данного проекта.

ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ

Требования к информационному обеспечению

Информационная база ЭА должна быть организована как совокупность независимых информационных массивов:

· хранилище документов;

· база метаданных, обеспечивающая возможность хранения атрибутов документов, прав пользователей, параметров и других данных, необходимых для функционирования ЭА;

· массивы полнотекстового индекса для обеспечения контекстного поиска.

Физическая структура информационной базы ЭА должна быть полностью скрыта от пользователей.

Должно быть обеспечено представление документа как сложного объекта, состоящего из следующих компонентов:

· регистрационная карточка (РК) документа, являющаяся носителем атрибутов данного документа, по которым может осуществляться его поиск;

· содержимое документа как графическая или полнотекстовая компонента, являющаяся электронным образом документа.

Информационное обеспечение должно обеспечить следующие свойства ЭА:

· поддержка логических связей между документами;

· автоматическое обновление полнотекстового индекса без остановки работы пользователей;

· актуализация измененных значений атрибутов для всех уполномоченных пользователей немедленно после сохранения РК документа.

Требования по применению систем классификации следующие:

· при регистрации документов в ЭА должны применяться справочники, хранящиеся в ЭА;

· справочники должны заполняться администратором ЭА средствами модуля администрирования.

Должна быть предусмотрена возможность расширения функциональности Системы, обеспечивающая заполнение справочников ЭА путем репликации данных из справочников первичных учетных систем.

Должны применяться, по крайней мере, следующие справочники:

· справочник пользователей;

· справочник видов документов;

· справочник организационной структуры;

· справочник корреспондентов;

· справочник номенклатуры дел – иерархическая структура дел Заказчика, причем каждому подразделению соответствует свой собственный набор заголовков (наименований) дел;

· справочник ролей пользователей.

Состав справочников ЭА должен быть конкретизирован на этапе проектирования Системы.

Должна быть обеспечена возможность поиска по справочникам.

Требования к программному обеспечению

Программное обеспечение должно удовлетворять требованиям к надежности, производительности, к защите информации, указанным в настоящем документе.

Требования к системному и базовому программному обеспечению

ЭА должен включать в себя:

· операционные системы серверов хранения документов и приложений;

· систему управления базами данных;

· средства авторизации и аутентификации пользователей;

· набор компонентов базового ПО ЭА;

· специализированные модули, разрабатываемые Исполнителем.

Выбор версий системного и базового программного обеспечения должен быть произведен на этапе проектирования ЭА.

Версии системного и базового ПО должны отвечать следующим требованиям:

· обеспечивать корректную работу с русским языком;

· иметь статус промышленно выпускаемой версии производителя;

· обеспечивать корректную совместную работу в составе ЭА;

· поддерживаться производителем.

Требования к рабочим местам пользователей

Рабочие места пользователей должны удовлетворять следующим требованиям:

· операционная система Windows XP / Windows 7/8/10

Требования к техническому обеспечению

Для функционирования модулей ЭА необходимо следующее техническое обеспечение:

· серверы системы управления документами;

· сервер управления базой данных;

· серверы приложений;

· серверы полнотекстового поиска;

· сканер или любое многофункциональное сканирующее устройство для ввода документов на штатном рабочем месте архивариуса ЭА;

· персональный компьютер сотрудника, являющегося пользователем ЭА.

Требования к вычислительным мощностям должны быть определены на этапе проектирования.

Система должна обеспечивать работу с устройствами хранения данных.

Заказчик обеспечивает наличие необходимого для развертывания ЭА аппаратного обеспечения.

Требования к методическому обеспечению

Методическое обеспечение Системы должно быть разработано на этапе проектирования с учетом требований нормативно-методических документов компании Заказчика.

Требования к организационному обеспечению

Организационное обеспечение ЭА должно быть достаточным для эффективного выполнения персоналом Системы возложенных на него обязанностей при осуществлении автоматизированных и связанных с ними неавтоматизированных функций ЭА.

Инструкции, входящие в состав организационного обеспечения ЭА, должны определять действия персонала, необходимые для выполнения каждой автоматизированной функции, во всех режимах функционирования ЭА, а также содержать конкретные указания о действиях в случае возникновения аварийных ситуаций или нарушении нормальных условий функционирования ЭА.

 

⇐ Предыдущая12

Поделиться: