xmlhack.ru XML-форумы
Обсуждение XML и связанных с ним технологий

Казахстанский машинопонимаемый коммуникативный формат

На страницу Пред.  1, 2, 3, 4  След.

Автор Сообщение
Janne Saarela
Гость




[5034] Чт Сен 25, 2003 04:17
Finland project
Some interesting projects have been running in Finland.
The only one for which I was able to find material
in English is EC funded eGov project

http://www.egov-project.org/

This project introduced the concept of a metadata
repository which aggregates content from multiple
back-end systems to one portal. The ontology
defined for this set-up was specific to life events.
Vassilios Peristeras
Гость




[5035] Чт Сен 25, 2003 04:23
applications in PA sphere
If you are interested in high level representations of the public
administration domain, you may find ideas on the following work :

1. Tarabanis, K. and Peristeras V. (2003). Knowledge Management Requirements
for Pan-European Public Administration Service Delivery, in Knowledge
Management in Electronic Government: 4th IFIP International Working
Conference, KMGov 2003, Rhodes, Greece, May 26-28, 2003. Proceedings. Rhodes
Island, Greece, Springer-Verlag Heidelberg. Volume 2645 / 2003.
2. Peristeras V., Tsekos Th., and Tarabanis K., "Building Domain Models for
the (e-) Governance System", proceedings of the International Conference on
Politics and Information Systems: Technologies and Applications (PISTA '03).
31 Jul.-2 Aug. 2003 - Orlando, Florida, USA
3. Tarabanis K. and Peristeras V. , "Enhancing e-Government through the use
of Web Services and Semantic Web technologies", proceedings of the 3rd
European Conference on e-Government 3-4 July 2003, Trinity College Dublin,
Ireland
4. Peristeras V., Tsekos Th. and Tarabanis K., "Governance as a complex
system: building a domain model using ontological representations",
presented at the 47th Annual Conference of the International System Sciences
Society, 4-8 July 2003, Crete, Greece.
5. Peristeras V. and Tarabanis, K.(2002). Requirements for Transparent
Public Services Provision amongst Public Administrations, in Electronic
Government: First International Conference, EGOV 2002, Aix-en-Provence,
France, September 2-5, 2002. Proceedings. Aix-en-Province, France,
Springer-Verlag Heidelberg. vol. 2456 / 2002: 330 - 337.
6. Tarabanis K., Peristeras V., and Fragidis G. "Building an Enterprise
Architecture for Public Administration: A High Level Model for Strategic
Planning", proceedings of the 9th European Conference on Information
Systems, special track for e-Government, pp. 987-998, June 2001, Bled,
Slovenia.
7. Peristeras V., K., Tarabanis, "Towards an Enterprise Architecture for
Public Administration: A Top Down Approach", in European Journal of
Information Systems, vol. 9, pp. 252-260. Dec. 2000. Also in proceedings of
the 8th European Conference on Information Systems, Vienna, vol.2,
pp.1160-1167.


Feel free to ask any of these papers or any additional information on the
current stage of our research.

Regards,

Vassilios Peristeras

IT Consultant
per@untcentre.org
tel: +30 2310 595902

United Nations Thessaloniki Centre
fax: +30 2310 595940
e-mail: info@untcentre.org
http://www.untcentre.org
Koletti 25D, 54627
Thessaloniki
Канат
Гость




[5036] Чт Сен 25, 2003 04:37
ТЗ ЕСЭДО-Н
It seems to me we are changing language from russian to english. I am not stisfied! I will write in Kazakh next time -Smile

РАЗРАБОТКА ЕДИНОЙ СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА ГОСУДАРСТВЕННЫХ ОРГАНОВ РЕСПУБЛИКИ КАЗАХСТАН
(ШИФР ЕСЭДО РК)
ВТОРАЯ ОЧЕРЕДЬ
НАУЧНО – ИССЛЕДОВАТЕЛЬСКАЯ ОПЫТНО - КОНСТРУКТОРСКАЯ РАЗРАБОТКА
ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Астана, 2002
АННОТАЦИЯ
В настоящем документе описываются основные технические требования ко второй очереди Единой Системы Электронного Документооборота (ЕСЭДО РК) Республики Казахстан.
Приведены требования к комплексу технических средств, общесистемному программному обеспечению, прикладному программному обеспечению, условиям эксплуатации и технологичности, телекоммуникациям, персоналу, а также описаны основные прикладные функции системы.
Положения настоящего документа должны лечь в основу технорабочего проекта системы, разработки организационных и технических мероприятий по внедрению второй очереди ЕСЭДО РК, формирования заказов на поставку средств вычислительной техники и сопутствующего оборудования, выбора поставщиков услуг телекоммуникаций.
ОГЛАВЛЕНИЕ
1. ВВЕДЕНИЕ 5
2. ОСНОВНЫЕ МЕХАНИЗМЫ РЕШЕНИЯ ПРОБЛЕМЫ УПРАВЛЕНИЯ ЗНАНИЯМИ, ФОРМИРУЮЩИМИСЯ В ПРОЦЕССЕ ФУНКЦИОНИРОВАНИЯ ЕСЭДО РК 6
3. ПОЛНОЕ НАИМЕНОВАНИЕ РАЗРАБОТКИ 11
4. УСЛОВНОЕ ОБОЗНАЧЕНИЕ РАЗРАБОТКИ 12
5. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ 13
6. НАЗНАЧЕНИЕ И ЦЕЛЬ РАЗРАБОТКИ 14
7. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 15
8. СТРАТЕГИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ 16
8.1. Характеристики ЕСЭДО РК 16
8.2. Задачи, решаемые ЕСЭДО РК 19
8.3. Технологические требования к ЕСЭДО РК 20
8.4. Требования к архитектуре системы 21
8.4.1. Подсистема автоматизации документооборота и делопроизводства ведомственного уровня 21
8.4.2. Подсистема автоматизации документооборота и делопроизводства национального уровня 22
8.4.3. Подсистема управления знаниями 24
8.4.4. Подсистема поддержки принятия решений 24
8.4.5. Подсистема доступа к открытым ЭД 26
8.4.6. Подсистема «Транспортная среда» 27
8.5. Требования к стандартизации 27
9. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К ЕСЭДО РК 29
9.1. Обработка документов на бумажных носителях 29
9.2. Преобразование документов на бумажных носителях в ЭД 32
9.3. Управление ЭД (электронный документооборот) 33
9.3.1. Разработка, согласование и утверждение ЭД 33
9.3.2. Обработка внутренних ЭД организации 33
9.3.3. Обработка исходящих ЭД 34
9.3.4. Контроль исполнения ЭД 34
9.3.5. Общие функции обработки ЭД в ЕСЭДО РК 35
9.4. Функции взаимодействия ЕСЭДО РК с системами НИИ РК и внешними системами 36
9.5. Функции информационно – справочной работы 36
9.6. Функции управления знаниями 36
9.6.1. Общие функции управления знаниями 37
9.6.2. Функции интеллектуального анализа данных 37
9.6.3. Основные функции OLTP 38
9.6.4. Основные функции OLAP 54
9.7. Функции поддержки принятия решений 56
10. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ ВТОРОЙ ОЧЕРЕДИ (НАЦИОНАЛЬНОГО УРОВНЯ) ЕСЭДО РК 58
11. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ВТОРОЙ ОЧЕРЕДИ (НАЦИОНАЛЬНОГО УРОВНЯ) ЕСЭДО РК 59
12. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ ВТОРОЙ ОЧЕРЕДИ (НАЦИОНАЛЬНОГО УРОВНЯ) ЕСЭДО РК В ДЕЙСТВИЕ 60
13. ТРЕБОВАНИЯ К АППАРАТНОМУ ОБЕСПЕЧЕНИЮ 61
13.1. Требования к аппаратному обеспечению серверов системы 61
14. ТРЕБОВАНИЯ К БАЗОВОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ 64
14.1. Требования к базовому программному клиентских мест системы 64
14.2. Требования к базовому программному обеспечению серверов национального уровня 65
15. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 66
15.1. Пояснительная записка техно-рабочего проекта 66
15.2. Общее описание системы 66
15.3. Программа и методика испытаний 67
15.4. Руководство администратора БД 67
15.5. Руководство пользователя 67
15.6. Технологические инструкции 68
ПРИЛОЖЕНИЕ 1 70

1. ВВЕДЕНИЕ
Настоящее Техническое Задание на вторую очередь Научно – Исследовательской Опытно – Конструкторской Работы (НИОКР) по созданию Единой Системы Электронного Документооборота государственных органов РК (ЕСЭДО РК), разработанное с целью дальнейшего развития ЕСЭДО РК и являясь логическим развитием Технического Задания на первую очередь НИОКР ЕСЭДО РК, определяет детальные требования к подсистемам национального уровня ЕСЭДО РК.
С момента Утверждения настоящего Технического Задания на вторую очередь ЕСЭДО РК вступают в силу следующие положения:
Считать утратившим силу раздел 8 Технического Задания на первую очередь ЕСЭДО РК «СТРАТЕГИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ» и вместо него в дальнейшем руководствоваться разделом 8 данного документа.
Считать утратившим силу раздел 9 Технического Задания на первую очередь ЕСЭДО РК «ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К ЕСЭДО РК» и вместо него в дальнейшем руководствоваться разделом 9 данного документа.


2. ОСНОВНЫЕ МЕХАНИЗМЫ РЕШЕНИЯ ПРОБЛЕМЫ УПРАВЛЕНИЯ ЗНАНИЯМИ, ФОРМИРУЮЩИМИСЯ В ПРОЦЕССЕ ФУНКЦИОНИРОВАНИЯ ЕСЭДО РК
Вторая очередь ЕСЭДО РК должна обеспечивать управление ЭД, создаваемыми подсистемами ведомственного уровня и поступающими извне через подсистему массового доступа к открытым ЭД и знаниям, на национальном уровне. Для этого предусмотрено структурированное накопление ЭД в Национальном Фонде ЭД, что предоставляет большие удобства пользователям ЕСЭДО РК в извлечении знаний из содержащейся в Национальной информационной инфраструктуре (НИИ РК) информации. (под знаниями здесь и далее понимается результат осмысления информации по заданным критериям).
Проблематика управления знаниями - одно из ключевых концептуальных понятий, определяющих стратегическую цель применения информационных технологий. Рост объема информации создает огромную потребность в извлечении знаний. Управление же знаниями является формальным порядком работы с информационными ресурсами для облегчения доступа к знаниям и повторного их использования с помощью современных информационных технологий. При этом знания классифицируются и распределяются по категориям в соответствии с предопределенной, но развивающейся онтологией структурированных и полуструктурированных баз данных и баз знаний. Ресурсом знаний являются массивы неструктурированной информации. В первую очередь это чаще всего текстовые документы, а затем графика, видео, звук.
Основными механизмами управления знаниями являются методы организации знаний и доступа к ним с применением программных средств, созданных с использованием алгоритмов прикладной лингвистики.
Вследствие большого потока документов, которые будут передаваться в ЕСЭДО РК, возникает необходимость организации структурированного хранения информации в Национальном Фонде ЭД, которая должна обеспечиваться средствами автоматической классификации документов на основе КМПКФ.
Таким образом, при выпуске ЭД необходима реализация его приведения к единому формату НИИ РК – КМПКФ, обеспечения машинного аннотирования с целью последующего использования аннотаций в поисковых механизмах и каталогах, а также подготовка базового списка ключевых слов на русском и казахском языках.
Средства индексирования и поиска информации в системе управления знаниями Национального Фонда ЭД должны
• реализовывать сквозной поиск информации по метаданным и контенту вне зависимости от их формата и принадлежности к различным СУБД, системам управления документами, почтовым системам;
• реализовывать интуитивный поиск документов, аналогичных заданному шаблону;
• реализовывать механизмы нечеткого поиска;
• позволять выполнять вложенные запросы (по ранее отобранному массиву документов);
• иметь механизм автоматической оценки значимости найденных документов;
• автоматически отслеживать поступление новых документов;
• производить автоматическое аннотирование;
• иметь атрибутивный поиск по полям для аннотированных документов;
• производить автоматическую рубрикацию документов;
• осуществлять переиндексацию при поступлении новых документов без прерывания доступа пользователей к архиву;
• являться масштабируемыми по объему информации и числу пользователей.
Наиболее высокое качество и полнота как автоматической классификации, так и поиска должна обеспечиваться за счет учета морфологии и семантики русского и казахского языка, так как реализация морфологического блока обеспечивает поиск слова в любой его словоформе, при этом уменьшая объем индексных данных и частично разрешая омонимию. Семантический блок необходим для автоматического преобразования запросов на естественном языке в набор связанных по смыслу понятий.
Гибкость адаптации технологии автоматической классификации и поиска к решению конкретных задач должна обеспечиваться за счет одновременного использования нескольких словарей (систем структурирования) и нескольких семантических сетей (включая наложение нескольких сетей на один словарь).
Кроме использования обычных логических операторов, необходимо иметь возможность задавать ограничения расстояния между словами и позициями классификатора, порядок следования слов, использовать операторы нечеткого и семантического расширения слов, операторы поиска по диапазонам чисел и дат и т. п.
Базы знаний генерируются для экспертов и систем, основанных на знаниях, в которых ПО использует правила вывода для получения ответов на вопросы пользователя. Также СУЗ обеспечивают знания в удобной для восприятия форме, или поставляют ПО для обработки этих знаний. Такая система содержит набор инструментальных средств для нисходящего доступа к базам данных, – все, что необходимо для поддержки принятия решений.
Чем больше накапливается информации, тем сложнее становится ее хранить. Поэтому многие решения проблемы невозможны без использования хранилищ данных.
Хранилища данных отличаются от традиционных БД тем, что они проектируются для поддержки процессов принятия решений, а не просто для эффективного сбора и обработки данных. Как правило, хранилище содержит многолетние версии обычной БД, физически размещаемые в той же самой базе. Данные в хранилище не обновляются на основании отдельных запросов пользователей. Вместо этого вся база данных периодически обновляется целиком. Когда все данные содержатся в едином хранилище, изучение связей между отдельными элементами данных может быть более плодотворным, а результатом анализа становятся новые знания.
Для поиска в данных дополнительных, скрытых в них знаний, применяется разведка знаний , использующая методы искусственного интеллекта, математики и статистики для «выуживания» знаний из хранилищ данных.
Если хранилища данных содержат в основном количественные данные, то хранилища знаний ориентированы в большей степени на качественные данные, СУЗ генерируют знания из широкого диапазона баз данных (включая Lotus Notes), хранилищ данных, рабочих процессов, внешних баз, Web-страниц (как внешних, так и внутренних).
Знания, приходящие из рабочих процессов, базируются на рабочих материалах, предложениях и т. п. Кроме того, базы знаний могут быть спроектированы в расчете на ведение хронологии деятельности организации или для обучения. Обучающие БД могут использоваться для поддержки деловых процессов или генерации информации о деятельности организации в целом. Например, обучающая база данных Национального агентства безопасности США (NSA – National Security Agency) содержит три типа уроков: информационные, уроки успеха и проблемы . Информационный урок может описывать, как служащий NSA принимает на себя временные обязанности в случае опасности. В «Уроках успеха» приводится позитивный опыт разрешения трудной ситуации. В «Уроках по проблемам» показаны примеры типичных ситуаций возникновения ошибок и возможные пути их устранения.
Знания, накапливающиеся в процессе использования различных тестов при поиске эффективных путей решения задач, хранятся в базе знаний оптимальных решений. После того, как организация получила знания о наилучшем решении, доступ к ним открыт для сотрудников согласно предоставленным им прав доступа. В случае же ЕСЭДО РК доступ к накапливаемым знаниям потенциально может быть предоставлен всем государственным служащим, а в перспективе через подсистему массового доступа к открытым ЭД и знаниям – всему миру.
Выводы:
1. Знания извлекаются из информации, накапливаемой в Национальном фонде ЭД.
2. Для решения проблемы управления знаниями на этапе создания второй очереди ЕСЭДО РК необходимо предусмотреть инструменты извлечения знаний, действующие на основе добычи данных и текстов, разведки знаний, разноплановой обработки информации.
3. Знания при помощи ПО агентов и фильтров распределяются по разным базам знаний национального уровня ЕСЭДО РК. Процесс создания различных баз знаний – перманентный и должен учитываться при определении затрат на эксплуатацию национального уровня ЕСЭДО РК.
4. Знания потребляются пользователями ЕСЭДО РК посредством интеллектуальных программных агентов, разрабатываемых для конкретных областей знаний. Процесс разработки указанных агентов происходит постоянно и затраты на него должны быть учтены при определении затрат на эксплуатацию национального уровня ЕСЭДО РК.
5. Интеллектуальные программные агенты работают только с хорошо структурированной информацией. Поэтому в СУЗ необходимо предусмотреть как функции интеллектуального анализа информации, так и ее OLTP и OLAP обработки.

3. ПОЛНОЕ НАИМЕНОВАНИЕ РАЗРАБОТКИ
Полное наименование научно – исследовательской опытно – конструкторской разработки (далее НИОКР) – Единая Система электронного документооборота для государственных органов Республики Казахстан, вторая очередь, национальный уровень.


4. УСЛОВНОЕ ОБОЗНАЧЕНИЕ РАЗРАБОТКИ
Условное обозначение НИОКР - ЕСЭДО РК.


5. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ
Основанием для разработки является:
1. Указ Президента Республики Казахстан №427 от 30 июля 2000 года «О мерах по улучшению работы государственного аппарата, борьбе с бюрократизмом и сокращению документооборота»
2. Указ Президента Республики Казахстан №573 от 16 марта 2001 года «О Государственной программе формирования и развития национальной информационной инфраструктуры Республики Казахстан»
3. Постановление Правительства Республики Казахстан №674 от 21 мая 2001 года «Об утверждении Плана мероприятий по реализации Государственной Программы формирования и развития Национальной информационной инфраструктуры в Республике Казахстан на 2000 – 2003 годы»
4. Концепция развития электронного документооборота, утвержденная Правительственной Комиссией по координации работы по формированию Единого Информационного Пространства и процессов информатизации государственных учреждений 23.04.2001, протокол №2..
5. Техническое Задание на первую очередь Научно – Исследовательской Опытно – Конструкторской Работы по созданию Единой Системы Электронного Документооборота государственных органов Республики Казахстан. ЗАО НИТ, Астана, 2001
Заказчиком ЕСЭДО РК является Министерство Транспорта и Коммуникаций РК в лице Комитета связи и информатизации.
Генеральным подрядчиком по работам в рамках создания ЕСЭДО РК является ЗАО НИТ.


6. НАЗНАЧЕНИЕ И ЦЕЛЬ РАЗРАБОТКИ
ЕСЭДО РК является автоматизированной информационно-справочной системой, предназначенной для автоматизации технологических процессов подготовки, регистрации, структурирования, маршрутизации, хранения, архивации, поиска и обработки электронных документов (далее ЭД), контроля их исполнения, авторизации доступа к ним, выпуска и рассылки ЭД, извлечения информации из ЭД и ее анализа, получения знаний из накапливаемой информации, поддержки принятия решений.
В системе производится обработка создаваемых и используемых в делопроизводстве государственных органов Республики Казахстан как несекретных, так и содержащих информацию с пометой «Для служебного пользования» ЭД.
Целью разработки второй очереди ЕСЭДО РК является создание подсистем национального уровня, обеспечивающих:
1. Управление ЭД на национальном уровне, в том числе формирование Национального Фонда электронных документов, организация массового доступа к ЭД, передача ЭД на хранение в СЭА ГО.
2. Управление извлекаемыми из ЭД знаниями.
3. Организация поддержки принятия решений высших должностных лиц органов государственного управления РК


7. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
Объект автоматизации является Системой органов государственного управления РК, которая включает в себя Администрацию Президента РК, Канцелярию Премьер – Министра РК, министерства, агентства, ведомства и акиматы - всего 769 бюджетных организаций республиканского и областного уровней, финансируемых из республиканского бюджета.
Подробные сведения об объекте автоматизации приведены в Техническом Задании на первую очередь ЕСЭДО РК.


8. СТРАТЕГИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ
Данный раздел приведен взамен раздела 8 Технического Задания на первую очередь ЕСЭДО РК. Считать утратившим силу раздел 8 Технического Задания на первую очередь ЕСЭДО РК. В дальнейшем руководствоваться приведенными в данном разделе стратегическими требованиями к ЕСЭДО РК

8.1. Характеристики ЕСЭДО РК
Дополнительно к Техническому Заданию на первую очередь ЕСЭДО РК вводятся следующие основные принципы ее построения:
1. Масштабируемость – ЕСЭДО РК должна обеспечивать наращивание мощностей системы и определяется только характеристиками аппаратного обеспечения, на котором функционирует данная система, что позволяет неограниченно увеличивать количество рабочих мест и пропускную способность транспортной среды без внесения существенных изменений в логическую структуры системы и с наименьшими затратами на дополнительное оборудование. Масштабируемость достигается путем замены оборудования на более производительное и перераспределением нагрузки от вычислительных процессов за счет использования ресурсов подключаемого распределено другого оборудования.
2. Интегрированость – ЕСЭДО РК должна состоять из интегрированных подсистем, построенных на основе стандартных настраиваемых комплексов программного обеспечения (ПО), обеспечивающих работу системы в составе Национальной информационной инфраструктуры РК
3. Открытость – ЕСЭДО РК должна обладать открытым программным API интерфейсом, что позволяет использовать программные средства не только как готовое решение, но и как мощный инструмент разработчика.
4. Информационная безопасность – ЕСЭДО РК должна использовать механизмы, обеспечивающие автоматизацию режима ограничения доступа по чтению и / или редактированию в отношении отдельных подсистем, комплексов, отдельных документов и отдельных полей (частей) документов. ЕСЭДО РК обеспечивает возможность подключения внешних средств криптозащиты информации (шифрование, засекречивание) и алгоритмов электронной подписи и шифрования документов. ЕСЭДО РК обеспечивает минимизацию риска некорректного использования или злоупотребления за счет следующих мероприятий: получения доступа к системе только после идентификации пользователя с помощью программно – аппаратных средств идентификации, ввода корректного пароля, разграничения прав, поддержки аудита (фиксации) каждого вхождения или попыток подбора паролей, автоматического отключения пользователей после определенного интервала отсутствия активности и при выходе из прикладной программы.
5. Гибкость – возможность добавления новых функций в систему без нарушения её функционирования.
6. Распределенность – ЕСЭДО РК должна обеспечивать территориально распределенное хранение и доступ информации, включая удаленный доступ к ней по технологии WEB. ЕСЭДО РК должна обеспечивать распределенную обработку информации, расположенных на территориально распределенных серверах.
7. Поддержка полного жизненного цикла ЭД – система обеспечивает автоматизацию работы с ЭД, начиная с его разработки, затем согласования, подписания, регистрации, контроля исполнения и заканчивая архивным хранением. Поддержка жизненного цикла ЭД должна обеспечивать возможность сопряжения с системой маршрутизации для автоматического изменения состояния документа по мере его прохождения по маршруту.
8. Комплексность – ЕСЭДО РК должна обеспечивать поддержку смешанного характера делопроизводства, когда система обеспечивает ведение электронного делопроизводства на основе безбумажной технологии, смешанное делопроизводство с элементами безбумажной технологии обработки бумажных документов, бумажное делопроизводство. ЕСЭДО РК должна обеспечивать поддержку версионности документов, составных документов (с автоматической поддержкой их актуальности).
9. Надежность – ЕСЭДО РК должна обеспечивать резервное копирование информации, рестарт системы после сбойных и аварийных ситуаций без потери логической целостности баз данных, процедуры для поддержки целостности обработки данных после сбоев системы или других незапланированных простоев, логическую проверку входных данных. ЕСЭДО РК должна предусматривать применение средств гарантированного питания, резервирования носителей информации и основных узлов оборудования, резервного копирования, резервирования каналов связи. Для наиболее ответственных участков необходимо предусмотреть горячее резервирование серверов системы.
10. Поддержка гетерогенной сетевой среды – функционирование ЕСЭДО РК в сетевой среде, построенной с использованием различных сетевых и клиентских операционных систем. В качестве сетевых операционных систем необходимо предусмотреть использование Linux, Windows, Unix (Sun Solaris, HP-UX, OS/400, AIX). В качестве клиентских операционных систем следует предусмотреть Linux, Windows.
11. Расширяемость – ЕСЭДО РК поддерживает работу неограниченного числа организаций, имеющих свое независимое организационно-штатное расписание (работа с штатным расписанием всех филиалов и всем персоналом организации), обеспечивая при этом их объединение в единую национальную информационную инфраструктуру.
12. Преемственность - ЕСЭДО РК обеспечивает адекватное воспроизведение ранее созданной информации вне зависимости от технического прогресса и перманентной смены поколений средств вычислительной техники, носителей информации.
13. Модульность - ЕСЭДО РК в связи с разнородностью выполняемых функций должна состоять из отдельных взаимодействующих между собой подсистем, построенных на основе сопряжения путем настройки стандартных комплексов программного обеспечения (ПО), реализующего функции системы.
14. Унификация - методы описания, представления, передачи и обработки данных в электронной форме должны быть унифицированы.
15. Сопряжённость - в ЕСЭДО РК должны быть предусмотрены средства сопряжения с НИИ РК и системами республиканских государственных органов, а также с информационными системами учреждений-источников комплектования и учреждений, являющихся постоянными потребителями, а также с внеотраслевыми системами передачи данных.


8.2. Задачи, решаемые ЕСЭДО РК
1. Формирование сегмента обработки документов национальной информационной инфраструктуры для органов государственного управления РК, граждан и хозяйствующих субъектов.
2. Разработка и согласование новых ЭД в государственных органах.
3. Ввод в систему с преобразованием в ЭД в случае записи информации на неэлектронных носителях писем, обращений, предложений и других документов граждан Республики Казахстан, иностранных граждан и других физических лиц, общественных, политических, государственных, коммерческих организаций и прочих юридических лиц в государственные органы РК в ЭД с дальнейшей регистраций, формированием метаданных, каталогизацией и маршрутизаций получаемых ЭД, а также занесением их в Национальный фонд ЭД при наличии соответствующих разрешающих признаков в метаданных ЭД.
4. Управление потоками работ с ЭД (workflow), в том числе сквозной контроль исполнения ЭД на всех уровнях.
5. Формирование Национального Фонда ЭД, ведение каталога ЕСЭДО РК, классификатора на основе казахстанском машинопонимаемом коммуникативном формате (далее КМПКФ) и информационно – справочного фонда находящихся в ЕСЭДО РК ЭД.
6. Извлечение и анализ данных из ЭД, хранящихся в ЕСЭДО РК.
7. Формализация, обработка и обобщение знаний, получаемых из ЭД ЕСЭДО РК.
8. Предоставление пользователю знаний из всех доступных ему в соответствии с предоставленными правами доступа источников, хранящихся в НИИ РК.
9. Поддержка принятия решений высших должностных лиц государственных органов РК, в том числе создание ситуационной комнаты. Передача документов в СЭА ГО для их хранения и организация доступа по запросам пользователей ЕСЭДО РК.
10. Поддержка открытого централизованного WEB-сайта Электронного Документооборота, содержащего классифицированные открытые документы государственных организаций и поддерживающий передачу вводимых гражданами документов через сайт в ЕСЭДО РК.

8.3. Технологические требования к ЕСЭДО РК
1. При выборе программных и технических средств должна быть поставлена задача минимизации числа используемых программных и аппаратных платформ, что позволит значительно снизить развертывания системы ЕСЭДО РК за счет унификации применяемых решений.
2. Программные средства должны предусматривать режим удаленного администрирования, что позволит снизить стоимость владения системой за счет снижения затрат на администрирование системы.
3. Программные средства системы ЕСЭДО РК должны быть построены по следующим схемам:
• трехуровневая схема «клиент сервер обработки данных – сервер хранения информации», что позволяет снизить стоимость владения системой за счет концентрации обработки данных на небольшом количестве серверов обработки данных и, как следствие, снижение затрат на администрирование системы;
• четырехзвенная архитектура: «клиент сервер представления информации – сервер обработки данных – сервер хранения информации», что позволяет уменьшить нагрузку на общие информационные ресурсы и вычислительные мощности от вспомогательных процессов.
4. Программные средства системы должны позволять проводить обработку в распределенном режиме с резервированием серверов, что повышает надежность и живучесть системы.
5. Предпочтение должно отдаваться интегрированным программным продуктам, которые обеспечивают выполнение максимального числа технологических требований к системе ЕСЭДО РК.
6. Программные системы, используемые для реализации ЕСЭДО РК, должны быть объектно-ориентированными для облегчения дальнейшей реструктуризации системы.

8.4. Требования к архитектуре системы
ЕСЭДО РК должна состоять из подсистем:
1. Автоматизации документооборота и делопроизводства ведомственного уровня;
2. Автоматизации документооборота и делопроизводства национального уровня;
3. Управления знаниями;
4. Поддержки принятия решений;
5. Массового доступа к открытым ЭД и знаниям;
6. Транспортной среды.

8.4.1. Подсистема автоматизации документооборота и делопроизводства ведомственного уровня
Основная задача подсистемы – обеспечение электронного документооборота министерств, ведомств и местных органов самоуправления. Данная подсистема должна обеспечивать решение следующих задач:
1. Разработка и согласование ЭД организации с поддержкой групповой работы над ЭД и, последовательной версионности документов;
2. Регистрация ЭД;
3. Маршрутизация ЭД для организации внутриведомственного документооборота;
4. Управление потоками работ (workflow), в том числе контроль за исполнением ЭД организации и.вышестоящих органов власти.
5. Поддержка каталога и информационно – справочного фонда находящихся в организации ЭД;
6. Связь с подсистемой автоматизации документооборота и делопроизводства национального уровня.
7. Передача ЭД в СЭА ГО.

8.4.2. Подсистема автоматизации документооборота и делопроизводства национального уровня
Основная задача подсистемы – обеспечение деятельности НСДОУ РК. Данная подсистема должна обеспечивать решение следующих задач
1. Учет, обработку и маршрутизацию поступающих в подсистему ЭД от входящих в ЕСЭДО РК организаций;
2. Приведение электронных документов к единому формату хранения и единому оформлению, их автоматическая (до 80% случаев) классификация;
3. Ведение каталога, классификатора на основе казахстанского машинопонимаемого коммуникативного формата (далее КМПКФ), информационно-справочного фонда находящихся в ЕСЭДО РК ЭД;
4. Обеспечение связи между ЭД;
5. Ввод (ручной, автоматизированный, электронный) в ЕСЭДО РК поступающих извне документов на любых известных носителях информации с преобразованием из в ЭД с созданием метаданных в КМПКФ;
6. Формирование Национального Фонда ЭД;
7. Ведение учета находящихся в исполнении ЭД, формирование отчетов о находящихся в ЕСЭДО РК ЭД и их состоянии;
8. Поиск зарегистрированных документов по любому набору реквизитов КМПКФ и/или по содержащейся в ЭД информации;
9. Поддержка макроязыков описания документов, структурированных запросов, структурированных ответов и согласования классификаторов;
10. Ведение информационно-справочной работы с возможностью формирования и выдачи стандартных и произвольных справок (перечней документов);
11. Хранение, учет и использование большого объема документов;
12. Импорт/экспорт баз данных (отдельных таблиц и наборов метаданных) в КМПКФ и по указанным диапазонам значений реквизитов ЭД по стандартам электронного обмена данными согласно целевой подпрограммы Плана мероприятий по реализации Государственной программы формирования и развития национальной информационной инфраструктуры РК;
13. Перевод ЭД в СЭА ГО;
14. Многоуровневое хранение ЭД с прозрачной для пользователя миграцией документов с уровня на уровень.
Обеспечение информационной безопасности, для чего необходимо внедрить инфраструктуру открытых ключей с распределением цифровых сертификатов Х.509 и обеспечить ее интеграцию с ЕСЭДО РК. В качестве хранилища закрытого ключа и цифрового сертификата могут выступать следующие устройства: жесткий диск, дискета, токен, смарт-карта. Основные функции реализации информационной безопасности:
• Аутентификация пользователя;
• Формирование цифровой подписи на электронных документах;
• Проверка действительности цифрового сертификата X.509 v3 по списку отозванных сертификатов;
• Аутентификация электронной цифровой подписи на электронных документах;
• Шифрование электронных документов и других данных;


8.4.3. Подсистема управления знаниями
Основная задача данной подсистемы – подготовка документов к анализу, формализация и установления связей между данными, хранимыми в системе.
1. Добыча данных и текстов из электронных документов.
2. Обработка, анализ и обобщение добытых из документов данных.
3. Формирование знаний из данных.
4. Предоставление знаний пользователю в соответствии с предоставленными ему правами.

8.4.4. Подсистема поддержки принятия решений
Основная задача данной подсистемы – обеспечение поддержки принятия решений как высших должностных лиц государства, так и руководителей государственных органов РК на основе содержащихся в системе знаний путем реализации следующих сценариев с возможностью расширения состава информационно – аналитических и модельно – аналитических услуг:
1. Мониторинг и анализ (включающий построение синтетических, сводных показателей) основных индикаторов социально-экономической ситуации в стране и ее регионах;
2. Прогноз - построение кратко- и средне- и долгосрочных прогнозов для основных макроэкономических показателей, характеризующих уровень социально-экономического развития региона или Республики Казахстан в целом, по заданным значениям экзогенных (в том числе, – управляемых) переменных;
3. Сценарный анализ - подготовка государственных решений с помощью многовариантных расчетов, позволяющих проследить последствия от планируемых изменений в бюджетной, налоговой, социальной, тарифной и т.п. сферах с точки зрения их влияния на ключевые индикаторы социально-экономического развития страны (региона);
4. Определение области тех допустимых значений управляемых или частично управляемых переменных, которые обеспечивают выход ключевых индикаторов социально-экономического развития страны (региона) на заданные уровни за определенное число тактов времени (кварталов, лет);
5. Анализ текущего влияния параметров основных мировых рынков (товарного, сырьевого, фондового, денежного) на ключевые индикаторы социально-экономического развития Казахстана и регионов;
6. Выработка предложений по основным направлениям стратегии социально-экономического развития страны (региона), основанных на компьютерных моделях экономического равновесия, дополненных долгосрочными экспертными прогнозами основных (глобальных) тенденций;
7. Проведение прогнозных расчетов по определению постатейных расходов и доходов государственного бюджета, формированию инвестиционных программ (включая инвестиционные фонды регионального развития) при различных вариантах структурной налоговой, социальной политик, внешнеэкономической ситуации и графиках погашения государственного долга;
8. Многовариантный расчет параметров платежного баланса при различных вариантах основных экзогенных переменных — объемах импорта, экспорта и золотовалютных запасов.
9. Исследование управляющих воздействий в области кредитно-денежной и инвестиционной (в территориальном разрезе) политики на основные индикаторы социально-экономического развития регионов, и в частности, на динамику каждого из них в пространстве состояний «реципиент – самодостаточный регион – донор»;
10. Взаимоувязка и стыковка прогнозных и сценарных расчетов по социально-экономическому развитию регионов как между собой, так и с соответствующими расчетами на уровне страны в целом.
11. Построение динамического межотраслевого баланса (МОБ) в прямой и обратной постановках задач.
12. Сценарный и прогнозный анализ ситуаций внутри отдельных секторов экономики (энергетического, транспортного, строительного, сельскохозяйственного и т.п.).

8.4.5. Подсистема доступа к открытым ЭД
Основная задача данной подсистемы – дать доступ широкой общественности к официальным документам органов государственного управления Республики Казахстан и обеспечить обратную связь с населением республики; общественными, государственными и коммерческими организациями. Данная подсистема является «информационной витриной» государственных органов власти РК.
Задачи этой подсистемы:
1. Связь с подсистемой автоматизации документооборота национального уровня.
2. Обеспечение защищенного доступа к системе различных групп пользователей через WEB-интерфейс с поддержки профилей (аутентификация, персонификация).
3. Поддержка основных функций обработки документов для группы удаленных пользователей канцелярий организаций, в которых не установлена ЕСЭДО-В.
4. Регистрация обращений граждан с проверкой регистрационных данных автора обращения через базу данных физических лиц.
5. Поддержка размещения государственными органами РК информации в Национальном фонде ЭД без передачи ее в подсистемы ведомственного уровня.
6. Предоставление руководителям государственных органов РК доступа к подсистеме управления знаниями.
7. Публикация отдельных категорий ЭД для массового доступа к ним в сети Интернет.
8. Обмен ЭД с внешними системами (не входящими в НИИ РК) через Интернет.

8.4.6. Подсистема «Транспортная среда»
Основное назначение транспортной среды – обеспечение надежной защищенной передачи данных между остальными подсистемами ЕСЭДО РК. Для этого эта подсистема должна обеспечивать:
1. Удаленный телекоммуникационный доступ к вычислительным ресурсам серверов с использованием протокола TCP/IP из всех региональных узлов.
2. Обмен данными между подсистемами ЕСЭДО РК вне зависимости от содержания передаваемой информации.
3. Гарантированную доставку данных в течение заданного интервала времени (с уведомлением о нарушении сроков доставки информации).
4. Защиту информации от несанкционированного доступа в момент передачи, сохранность информации от разрушения и живучесть транспортной системы.
5. Решение задач администрирования сети и диагностирования динамики функционирования телекоммуникационной системы.
6. Обмен ЭД между подсистемами ведомственного и национального уровня ЕСЭДО РК производится на основании метаданных ЭД в КМПКФ.

8.5. Требования к стандартизации
Программные средства ЕСЭДО РК должны удовлетворять основным мировым стандартам в области обработки документов:
7. Поддержка современных транспортных протоколов: TCP/IP, включая поддержку IP V6; HTTP 1.1; HTTPS; SSL (до уровня 3.0), WAP.
8. Поддержка наиболее распространенных форматов документов: Microsoft Office, PDF; HTML, XML.
9. Поддержка автоматического преобразования форматов документов.
10. Поддержка основных стандартов в области сопряжения с СУД – ODMA.
11. В области интеграции со средствами разработки:
12. Поддержка Java.
13. Поддержка Microsoft .Net.
14. Поддержка в области повышения отказоустойчивости и надежности системы:
15. Поддержка кластерных решений с балансировкой нагрузки.
16. Поддержка распределенного поиска информации.
17. Поддержка распределенного доступа к информации.
18. Возможность функционирования на различных аппаратных платформах.

9. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К ЕСЭДО РК
Основные функции системы:
1. Обработка документов на бумажных носителях (делопроизводство)
2. Преобразование документов на бумажных носителях в ЭД
3. Управление ЭД (электронный документооборот)
4. Передача ЭД на архивное хранение в СЭА ГО
5. Обмен ЭД с системами, ПО НИИ РК и внешними системами и ПО
6. Информационно справочная работа
7. Управление знаниями
8. Поддержка принятия решений
9. Предоставление массового доступа к открытым ЭД и знаниям через Интернет

9.1. Обработка документов на бумажных носителях
1. Учет и регистрация поступающей в организацию корреспонденции.
2. Регистрация резолюций на документах на бумажных носителях.
3. Формирование очередей документов на обработку.
4. Формирование регистрационно – контрольной карточки (далее РКК) документа.
5. Определение маршрутов исполнения с возможностью использования графического редактора и формирование списков рассылки документов При определении задания можно назначить пользователю возможность переназначения пришедшего задания (например, в случае неизвестного заранее исполнителя действия задание назначается делопроизводителю или начальнику отдела, а он в свою очередь переназначает задание подчиненному).
6. Возможность использования в ходе создания технологического процесса в качестве основы проектируемого маршрута частей имеющихся типовых маршрутов.
7. Возможность определения местонахождения документа на маршруте в процессе прохождения документа или группы документов по маршруту с указанием статуса задачи, в рамках которой он (они) посланы.
8. Возможность установки уведомления о сроках исполнения, если данное действие не было выполнено в определенный промежуток времени как с начала получения задания исполнителем, так и со времени запуска технологического процесса.
9. Автоматическое удаление ссылок на обработку из очередей для разосланных документов и их появление в очередях у тех пользователей, к которым эти документы направлены.
10. Автоматическое продвижение документов по этапам их жизненного цикла (ручное продвижение документов по этапам их жизненного цикла только в случаях, когда конкретные документы требуют специальной обработки либо стандартные процедуры делопроизводства не могут быть применены)
11. Определение дальнейшего маршрута прохождения документа как в зависимости от выбора пользователя, выполняющего задание на определенном этапе маршрута, так и в зависимости от атрибута документа.
12. Создание жизненных циклов документов и настройки специальных алгоритмов обработки на каждом этапе жизненного цикла при помощи:
• дизайнера жизненного цикла, включая проверку правильности заполнения атрибутов (выполнение условия для переведения документа в данное состояние жизненного цикла);
• средств визуального проектирования произвольного технологического процесса (маршрута) документа
13. Настройка необходимых действий, производимых при перемещении документа в каждое состояние, в том числе определение динамического исполнителя, когда известно, какое действие должно быть произведено над документом (например, для операции «Утверждение» ее исполнитель назначается на одном из этапов прохождения документа по маршруту). Также возможность задания исполнения данного действия как всеми пользователями группы или роли (например, при согласовании документа он должен быть просмотрен всеми пользователями группы), так и одним пользователем из группы (например, для документа, направленного в секретариат, где работают несколько пользователей назначенной группы, достаточно назначить из их числа одного исполнителя) т автоматической динамической балансировкой загрузки исполнителей (задание появится у выполняющего наименьшее количество задач сотрудника или же будет назначено первому, кто возьмет его на исполнение)
14. Изменение интерфейсных форм (изменение внешнего вида РКК)
15. Конвертация типов документов
16. Обеспечение ведения по каждому документу журнала, фиксирующего действия, связанные с созданием, согласованием и утверждением, регистрацией, обращениями, оформлением резолюций и поручений к документу. Данные журнала отображаются в регистрационной карточке документа в табличной форме.
17. Формирование справок о реквизитах и состоянии конкретных проектов и документов (где находится, кем согласован, какие по проекту замечания, какие по документу резолюции, поручения и т.д.), а также делопроизводственных отчетов с возможностью их параметризации и установки фильтров (т.е. включения в отчеты проектов и документов с заданными значениями или областями значений реквизитов) путем сохранения формируемых поисковых запросов, программно формируемых запросов, также представляемых пользователю в виде сохраненных запросов, через средства формирования отчетов, путем вывода результатов соответствующих запросов, формируемых через язык запросов в текст документов Microsoft office (формирование Word и Excel –документа). Сохранение формируемых поисковых запросов через визуальный интерфейс, в котором можно указать один или несколько атрибутов, сопоставляя каждому из атрибутов единственное значение или диапазон значений, задаваемый с использованием логических операторов. Задание полнотекстового поиска вхождения указанного текста в тело документа, автора, даты создания, типа документа и любых других атрибутов и групп атрибутов, с визуально настраиваемой группировкой и сортировкой атрибутов, включаемых в выводимый отчет
18. Формирование отчетов с включением документов с заданными значениями или областями значений реквизитов:
• по проектам документов – вывод списка проектов, содержащихся в хранилище с указанием для каждого проекта его автора, даты создания, даты утверждения, вида документа, основания для разработки (реквизитов поручения, на основании которого был создан проект);
• по содержимому обязательных и персональных дел – вывод списка документов, содержащегося в конкретном деле, с указанием для каждого документа наименования, регистрационного номера, даты регистрации, подразделения, где был подготовлен документ, автора документа, вида документа, полномочий доступа;
• по поручениям руководителей – список выданных поручений с указанием для каждого поручения (выполнено/отменено/ в работе). Невыполненные поручения должны выделяются жирным шрифтом (возможно выделение иным способом);
• по персональным накопителям – список документов, находящихся в накопителе с указанием для каждого документа даты поступления, отправителя или адресата вида документа. Невыполненные поручения выделяются жирным шрифтом (возможно выделение иным способом)

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

19. Подготовка документов к сканированию.
20. Сканирование документов.
21. Распознавание отсканированной информации, в том числе:
• Автоматическое определение различных форм;
• Оптическое распознавание символов OCR;
• Интеллектуальное распознавание символов ICR;
• Оптическое распознавание метки OMR;
• Распознавание штриховых кодов;
• Очистка изображения
22. Проверка результатов распознавания и ручное индексирование.
23. Подтверждение индексных значений.
24. Полнотекстовое распознавание документов.
25. Контроль качества и повторное сканирование.
26. Публикация – выпуск ЭД с формированием метаданных в КМПКФ.

9.3. Управление ЭД (электронный документооборот)
9.3.1. Разработка, согласование и утверждение ЭД
1. Создание проектов ЭД, ЭД с возможностью использованию хранящихся системы шаблонов.
2. Возможность автоматического формирования проектов ЭД, ЭД, состоящего из различных частей с отслеживанием актуальности каждой части (виртуальные ЭД).
3. Маршрутизация вновь созданных проектов ЭД, ЭД для их согласования и утверждения, согласно полномочиям конкретного пользователя системы.
4. Формирование метаданных ЭД, согласно КМПКФ.

9.3.2. Обработка внутренних ЭД организации
5. Создание задания на разработку внутреннего ЭД по инициативе пользователей, имеющих на это полномочия.
6. Создание новых ЭД согласно заданию на разработку ЭД на основе шаблонов, хранящихся в системе.
7. Возможность автоматического формирования ЭД, состоящего из различных частей с отслеживанием актуальности каждой части (виртуальные ЭД);
8. Маршрутизация вновь созданных внутренних ЭД для их согласования и утверждения, согласно полномочиям конкретного пользователя системы.
9. Утверждение внутренних ЭД посредством механизма ЭЦП.
10. Регистрация утвержденных внутренних ЭД в ЕСЭДО-В организации.
11. Хранение зарегистрированных внутренних ЭД в ЕСЭДО – В организации и автоматическое информирование заинтересованных пользователей системы о поступлении новых ЭД..

9.3.3. Обработка исходящих ЭД
1. Формирование и ведение списков рассылки организации.
2. Назначение списков рассылки исходящим ЭД, в том числе и индивидуальных списков рассылки.
3. Организация процесса согласования, визирования, утверждения и/или подписания исходящих ЭД у соответствующих сотрудников организации (руководства организации, руководителей структурного подразделения организации, имеющих право подписи) посредством механизма ЭЦП.
4. Регистрация утвержденных исходящих ЭД.
5. Автоматическая рассылка ЭД.

9.3.4. Контроль исполнения ЭД
1. Прозрачный контроль за прохождением ЭД инициатором процесса обработки ЭД (руководителем организации или структурного подразделения организации).
2. Контроль своевременного исполнения содержащих поручения ЭД.
3. Возможность постановки отдельных частей ЭД на контроль.
4. Корректировка сроков исполнения ЭД, стоящих на контроле, с указанием ЭД, являющимся основанием для корректировки данных сроков.
5. Формирование предупредительных сводок по исполнению ЭД.
6. Формирование сводок просроченных и неисполненных ЭД.
7. Получение отчетов по исполнению ЭД по запросам пользователей..

9.3.5. Общие функции обработки ЭД в ЕСЭДО РК
8. Присвоение метаданных согласно системе классификации на основе КМПКФ.
9. Автоматический учет всех создаваемых ЭД.
10. Сохранение внутренних, исходящих и входящих ЭД в ЕСЭДО-В организации.
11. Передача ЭД через Транспортную Среду ЕСЭДО РК
12. Сохранение исходящих и входящих ЭД в Национальном фонде ЭД.
13. Маршрутизация ЭД на всех уровнях его обработки без ограничения числа уровней (начиная с руководства организации и заканчивая конкретными исполнителями).
14. Автоматическая поддержка жизненного цикла ЭД с изменением прав доступа к ЭД по мере прохождения им отдельных этапов обработки.
15. Поддержка обработки составных ЭД, состоящих из различных частей, хранящихся в различных форматах и имеющих разные права доступа, с возможностью сборки окончательного ЭД в произвольный момент времени (поддержка виртуальных ЭД).
16. Возможность работы с содержащими видео и аудио информацию ЭД (аннотирование, просмотр, просмотр без запуска авторского приложения, перевод ЭД в другие форматы).
17. Классификация ЭД с использованием метаданных, получаемых в результате автоматической обработки содержания ЭД с использованием полнотекстового (в том числе и нечеткого), семантического, морфологического, фактографического, многоязычного, логического поиска, ручного ввода, а затем с окончательной корректировкой метаданных при необходимости с экспертным уточнением запросов поиска
18. Возможность поиска ЭД как по их содержанию, так и по метаданным.
19. Определение связей между ЭД.

9.4. Функции взаимодействия ЕСЭДО РК с системами НИИ РК и внешними системами
1. Передача ЭД на архивное хранение в СЭА ГО.
2. Предоставление возможности работы пользователям ЕСЭДО РК с архивными ЭД, находящимися на хранении в СЭА ГО
3. Обмен ЭД с системами НИИ РК через Транспортную Среду ЕСЭДО РК
4. Обмен ЭД с внешними системами через подсистему массового доступа к открытым ЭД и знаниям, подключенной к Интернету

9.5. Функции информационно – справочной работы
5. Поддержка каталога системы.
6. Поддержка и согласование классификаторов системы
7. Формирование отчетов по запросам пользователей согласно предоставленных им прав доступа к ресурсам системы. организации;
8. Поиск ЭД как по их метаданным, так и по содержанию.

9.6. Функции управления знаниями
Из накапливаемых в ЕСЭДО РК ЭД необходимо выделить информацию, что достигается применением функций интеллектуального анализа ЭД, и сохранить ее в хранилище данных (ХД) ЕСЭДО РК.
Получение знаний достигается обработкой хранящейся в ХД информации комплексами управления знаниями, OLTP и OLAP.

9.6.1. Общие функции управления знаниями
1. Интеллектуальный анализ данных, то есть добыча данных и текстов (Data mining, Text Mining) — распознавание образов, выделение значимых закономерностей, данных, находящихся в электронных документах.
2. Адаптивное распознавание образов, повышающее эффективность работы с любой информацией, представленной в электронном виде – текстов (с применением нечеткого поиска), аудио, видеоинформации
3. Автоматическое выявление уникальной ранее неизвестной информации, формирования и ведения тематических досье, исследования потенциальных угроз и тревожных тенденций, определения источников негативной информации, выявления скрытых взаимосвязей людей, событий и процессов.
4. Объединение - выделение структур, повторяющихся во временной последовательности данных с обнаружением правил, по которым присутствие одного набора элементов коррелирует с другим.
5. Кластеризация данных.
6. Факторный анализ данных для нахождения скрытых факторов среди выбранных показателей

9.6.2. Функции интеллектуального анализа данных
1. Свободный поиск
• Выявление закономерностей условной логики
• Выявление закономерностей ассоциативной логики
• Выявление трендов и колебаний
2. Прогностическое моделирование
• Предсказание неизвестных значений
• Прогнозирование развития процессов
3. Анализ исключений
4. Выявление отклонений
5. Непосредственное использование обучающих данных. Построение алгоритмов на основе анализа прецедентов (алгоритмы типы Lazy – Learning – метод ближайшего соседа, метод k-того соседа, метод NGE и т. п.)
6. Выявление и использование формализованных закономерностей
• Использование методов кросс – табуляции (кросс – табличная визуализация, байесовские сети)
• Использование методов логической индукции (деревья решений, индукция правил)
• Использование методов вывода уравнений (нейронные сети, ряды динамики, корреляционно – регрессионный анализ, нелинейная регрессия)

9.6.3. Основные функции OLTP
1. Предусмотреть составление финансового плана.
2. Предусмотреть планирование денежных потоков.
3. Бюджетирование расходов по центрам затрат, проектам и подразделениям, центрам ответственности.
4. Создание иерархических бюджетов различной структуры, содержания и назначения в зависимости от задач и объектов бюджетирования.
5. Формирование консолидированных бюджетов.
6. Построение бюджетов по схемам: метода break-down (сверху-вниз) и метода build-up (снизу-вверх).
7. Создание переменных бюджетов по калькуляционным единицам и фиксированных бюджетов по центрам затрат.
8. Предусмотреть контроллинг деятельности
9. Создание многоуровневых циклов перераспределения взаимных услуг обслуживающих предприятий.
10. Использование различных баз распределения затрат.
11. Калькуляция себестоимости с полным распределением затрат на объекты затрат или по переменным издержкам, гибкое определение параметров себестоимости, расширенные возможности моделирования типа "что - если" ("what - if"). Отчеты для сравнению результатов вычислений, проведенных по различным сценариям. Поддержка расчета цены продажи по методу "затраты плюс" ("Cost - Plus Method"). Расширенные отчеты по себестоимости с итогами данными и разбивкой по времени. По каждому коду могут быть различные данные. Для каждого кода система просчитает результирующие последствия. Количество возможных вариантов не ограничено. Доступны различные методы расчета: "сверху-вниз", "снизу-вверх" и одноуровневый. Для каждого кода должно быть определено, ведется ли калькуляция (себестоимости) по предельным затратам. Для каждого кода могут быть определены:
• нормы затрат на операции
• начисления
• затраты по договорам субподряда по каждому поставщику
• моделируемая цена
12. Регистрация фактических показателей деятельности
13. Организация бюджетного контроля путем сравнения фактических показателей с запланированными (фактические затраты / отклонения).
14. Расчет и анализ отклонений с последующей корректировкой бюджета.
15. Возможность использования рассчитанных бюджетных нормативов в качестве норм затрат на производственные операции.
16. Возможности определения лимитов (овердрафта, кредита, неснижаемый остаток на счете, др.)
17. Обработка паспортов сделок.
18. Предусмотреть выделение различных данных о контрагентах: наименование компании, ее адрес, номер для налогообложения, категория налогообложения, транспортный адрес, страна месторасположения, валюта и т.д.
19. Возможность использования неограниченного количества единиц измерения для каждого изделия
20. Для каждого изделия может быть определено неограниченное количество альтернативных изделий. В случае нехватки конкретных изделий на складе доступен перечень их альтернатив. Для альтернативных изделий могут быть определены следующие данные: приоритет, обратимая альтернатива (когда возможна обратная замена) и "естественная" альтернатива (т.е. 100% взаимозаменяемость).
21. Учет создания заказов на поставку по системам MPS (Master Production Scheduling), MRP (Material Requirements Planning), SIC (Statistical Inventory Control), FAS (Final Assembly Schedule), Вручную и контроль за их выполнением.
22. Анализ товарооборота по подразделениям, товарным группам.
23. Операции с запасами:
• корректировка запасов
• перемещение запасов
• отпуск на производство
• поступления с производства
• отпуск на продажу
• поступления по закупке
24. По каждому типу операций с запасами могут быть определены права доступа.
25. Могут быть введены операции с плановыми запасами (заказанным, распределенным и т.п.)
26. Операции с запасом "задним числом" оцениваются в соответствии с текущим значением себестоимости.
27. Учет запасов по изделиям в аналитике по секциям, складам, валютам.
28. Формирование отчетов по товарным запасам и товародвижению и др.
29. На основании АВС - классификации) может быть определен интервал инвентаризации для каждого изделия. Система использует этот интервал, чтобы следить, какие изделия подлежат циклической инвентаризации.
30. Может быть задан диапазон изделий, которые подлежат инвентаризации на конкретных складах/складских местах. Система будет генерировать распоряжения на циклическую инвентаризацию.
31. Отчеты по результатам циклической инвентаризацию могут быть получены по различным критериям сортировки, в том числе, если необходимо, по системным данным о запасах .
32. Выявление расхождений по запасам по дате инвентаризации.
33. Возможность детализации данных по запасам по складам (наличный, заказанный, распределенный, зарезервированный и запасы в обеспечение оферты с учетом коэффициента успеха). На основании первых трех разновидностей рассчитывается оптимальный запас.
34. Возможность определения точки заказа для каждого изделия через использование параметров заказа.
35. При задании "масштаба видимости" для изделия возможно сделать разбивку по времени распределения запасов или заказов.
36. Использование интервала заказа4, резервного время, цикла заказа, метода заказа при выработке рекомендации о заказе.
37. Возможность генерации точки заказа отдельно на основе прогноза.
38. Проведение АВС - анализа по складам или для выборки изделий.
39. Определение интервала циклической инвентаризации с учетом АВС - классификации.
40. Анализ по неходовым изделиям на основе коэффициента оборачиваемости запасов.
41. Различные критерии выбора для анализа файла оценки товарно-материальных запасов.
42. Присвоение параметров прогноза спроса и заказа для любого изделия.
43. Поддерживать методы прогноза:
• Последний период" - на основании данных по потреблению изделия за последний период прогнозируется его потребление в предстоящем периоде.
• "Среднее потребление" - по этому методу среднее потребление изделия рассчитывается с учетом определяемого пользователем количества периодов ретроспективы.
• "Предыдущий год" - при этом методе система позволяет пользователю в качестве базы прогноза выбрать любой период из прошлых лет. Конкретное применение этого метода возможно только в том случае, если могут быть идентифицированы годовые циклы.
• Экспоненциальное сглаживание - в этом методе используется коэффициент сглаживания, который обеспечивает "взвешивание" (в большую или меньшую сторону) дисперсии среднего значения. Следующие факторы определяются пользователем: коэффициент сглаживания, коэффициент сглаживания для анализа ошибок и "сигнал критического отслеживания" для автоматической корректировки выбранной переменной сглаживания. При этом методе система также анализирует дисперсию потребления изделия относительно среднего в тренде, а также возможное использование результирующего тренда для расчета прогноза.
44. Прогноз ожидаемого потребления изделия в следующем периоде.
45. Автоматическая выдача рекомендаций по точке заказа и резервному запасу, а также по циклу заказа на основании прогноза потребления изделия. В этих рекомендациях могут быть учтены: уровень обслуживания (который, в свою очередь, определяет рекомендацию по резервному запасу на основе конкретной дисперсии запаса), структура сезонного спроса, коэффициент тренда и т.д.
46. Возможность на основе прогноза, ошибки прогноза (абсолютной и фактической) и используемого коэффициента сглаживания (если прогноз осуществляется по методу экспоненциального сглаживания) определить ожидаемый годовой отпуск запасов.
47. Использование формулы Кэмпа для вычисления объема оптимального заказа на основе затрат на выполнение заказа, затрат на содержание запаса и ожидаемого годового потребления изделия.
48. Возможность определения следующих данных по любому изделию:
• резервный запас,
• максимальный запас,
• кратность объема заказа ;
• минимальный, максимальный, фиксированный или оптимальный объем заказа,
• точка заказа,
• интервал заказа,
• резервное время.
49. Взаимосвязь со складом, группой изделий, изделием и/или составляющей себестоимости, основанная на типе заказа и типе операции.
50. Возможность для каждой операции определения счета и \ или дебетового центра затрат.
51. Возможность определения соглашения о цене и скидке, варьируя уровень детализации: от общего уровня до уровня очень подробной детализации.
52. Возможность задания цены и скидки в виде шкал, где отражена их зависимость от размера закупки в натуральном или стоимостном выражении.
53. Возможность использования даты начала и конца периода действия цен и скидок для того, чтобы правильно выбрать цены и скидки автоматически.
54. Возможность использовать брутто- или нетто-цены .
55. Предусмотреть специальную функцию для глобального обновления цен и скидок (основана на детализированном выборе) на фиксированную величину или в процентном отношении; измененные цены могут округляться.
56. Автоматический расчет закупочной цены на основе прейскурантов.
57. Расчет сроков поставки.
58. Моделирование закупочных цен.
59. Управление текущими и открытыми заказами с возможностью указания специальных условий закупки по изделию (или группе изделий) и регистрация самой последней закупочной цены изделия и т.д.
60. Независимость финансовой обработки заказов и операций с запасами друг от друга.
61. Пользователь может определить различные типы заказа (распоряжения):
• заказ "с прилавка" (с непосредственным обновлением уровня запасов)
• распоряжение о возврате (заказ на возврат) (для продукции, не прошедшей входной контроль)
• распоряжение об отнесении затрат (для учетных единиц, не входящих в категорию товарно-материальных запасов)
• заказ на субподряд
62. Для каждого типа заказа пользователь может определить отдельную процедуру.
63. Возможность связи дополнительных затрат с заказами на закупку путем использования предварительно определенных наборов затрат.
64. Возможность обработки частичных поставок с одновременным автоматическим формированием дополнительных заказов (дозаказов).
65. Возможность определения размеров раскроя и резки для каждой позиции заказа на закупку.
66. Группировка поступления комплектующих в момент регистрации при помощи спецификации.
67. Генерация напоминаний при истечении согласованного времени поставки
68. Предоставление пользователю возможности просмотра статуса (состояния) по каждой позиции закупочного заказа.
69. Ввод данных о полученных товарах по номеру заказа или номеру поступления с использованием серий при необходимости. Если ввод осуществляется по номеру поступления, каждому поступлению присваивается номер. Все невыполненные (открытые) заказы по каждому поставщику могут быть представлены в виде списка и подтверждены.
70. Формирование рекламаций, если объемы, обозначенные в описи вложения, отличаются от фактически полученных.
71. Формирование ведомостей хранения для идентификации хранения товаров на складе в надлежащем месте.
72. Формирование извещения о возврате.
73. Регистрация зарезервированных запасов, освобождающихся только после проведения фактического контроля.
74. Возможность учета партий.
75. Запрет удаления заказов до сверки с фактическими счетами-фактурами.
76. Детализированная статистика закупок по странам, регионам, направлениям бизнеса, типам заказов, группам поставщиков, поставщикам, прейскурантам, покупателям, адресам, складам, статистическим группам, группам изделий и изделиям проекта.
77. Оценка надежности поставщика на основании ретроспективных данных о договорных/фактических датах поставки и заказанных/принятых количествах с оценкой по поставкам: раньше/позже/вовремя. Статистика периодов может быть построена при условии точного определения пользователем, за какой срок ему необходимы данные. Периоды могут вводиться вручную или определяться автоматически. Статистика может быть получена и сохранена индивидуально или в многоуровневом виде.
78. Возможность сравнения предложений с автоматической генераций заказа, связанного с наиболее предпочтительным предложением. Запросы, которые не завершаются заказами, могут быть удалены, но при этом их можно вызывать из ретроспективы.
79. Управление контрактами, в том числе сверки, определение графика поставки и его использование при генерации заказов на закупку, предусматривающих поставки в пределах определенного периода, анализ ретроспективы, возможность установления любой структуры цен и скидок, в том числе базирующихся на:
• себестоимости изделия
• стандартной цене продажи изделия
• предполагаемой розничной цене изделия
• цене, определенной на основе структуры цены (когда система учитывает ценовые шкалы, дату начала срока действия цены и т.д.).
80. Анализ верхних и нижних пределов цен для каждого изделия в отдельности с реакцией на выход из указанных пределов одним из следующих (определенных пользователем) способов:
• отказ воспринимать данные
• генерация предупреждения (сигнала)
• регистрация данных
• блокировка заказа
81. Пользователь может определить различные типы заказа (распоряжения):
• заказ "с прилавка" (с непосредственным обновлением уровня запасов)
• распоряжение о возврате (заказ на возврат) (для продукции, не прошедшей входной контроль)
• распоряжение об отнесении затрат (для учетных единиц, не входящих в категорию товарно-материальных запасов)
82. Для каждого типа заказа пользователь может определить отдельную процедуру. Это подразумевает спецификацию документов, определение необходимых шагов процедуры обработки заказа и последовательности различных шагов.Для того, чтобы ускорить процесс ввода заказа, ряд данных может быть определен по умолчанию (тип заказа, серия заказа, код склада).
83. Во время ввода заказа пользователь может определить и ввести в систему новые изделия и новых клиентов в режиме подпроцессов (подсеансов).
84. Блокировка заказа или генерация сообщения во время выполнения процедуры обработки заказа, если складывается одна из следующих ситуаций (или комбинация этих ситуаций):
• клиент имеет статус "ненадежный";
• сумма открытых и вводимых (оформляемых) заказов по клиенту превышает его лимит кредита;
• клиент имеет просроченные счета-фактуры;
• цена не соответствует установленным пределам отклонения (коридору) цен.
85. Пользователь может определить, как долго заказ должен оставаться заблокированным. Для разблокирования заказа применяется специальная функция. При разблокировании заказа система регистрирует причину, дату/время снятия блокировки и пользователя, который выполнил эту операцию.
86. На основании заказа на продажу может быть автоматически сгенерирован заказ на закупку. Между такими заказами поддерживается связь, в частности, она отражается в приходной накладной.
87. Заказ на закупку, который автоматически генерируется на основании заказа на продажу, может быть напрямую поставлен клиенту (пр
Канат
Гость




[5037] Чт Сен 25, 2003 04:40
ТЗ ЕСЭДО-Н продолжение
87. Заказ на закупку, который автоматически генерируется на основании заказа на продажу, может быть напрямую поставлен клиенту (прямая поставка). Система проверяет, имеет ли отношение заказ на закупку к прямой поставке, осуществляемой в отделе продаж.
88. В момент, когда пользователь информирует систему, что поставка осуществлена, происходит изменение статуса заказа на продажу, которое позволяет выдать на печать счет-фактуру.
89. Во время ввода заказа система в тот же момент проверяет имеющиеся запасы (включая также и запасы, поступления или уходы которых распределены по времени). Если запас недостаточен для обслуживания данного заказа, то система сообщает об этом, после чего могут быть предприняты специальные действия, способствующие решению проблемы:
• просмотр данных о реализации запасов с учетом распределения по времени
• показ альтернативных изделий
• просмотр запасов по складам
• создание заказа на закупку
• создание дозаказа на необходимое количество изделий
90. Для каждого заказа могут быть определены различные частичные платежи (взносы) по счетам-фактурам.
91. Статус частичного платежа показывает, может ли быть выставлен (или нет) по нему счет-фактура, или он уже выставлен.
92. Графики выставления счетов-фактур могут поддерживаться из верхнего колонтитула (заголовка) заказа, позиций заказа или поставок и могут быть распечатаны на документе подтверждения заказа.
93. Частичные платежи могут осуществляться против поставок товаров или независимо от них.
94. Долевое выставление счетов-фактур может быть использовано для предоплат, оплат в рассрочку, гарантийных оплат или для комплексной выписки счетов-фактур по проектам.
95. Дополнительные затраты могут быть связаны с заказом на продажу путем определения набора затрат.
96. Коды набора затрат могут быть определены в таблице. Эта таблица содержит единицу измерения, на основе которой рассчитываются начисления на заказ на продажу. Этой единицей может быть количество (выраженное в единицах цены, запаса или продаж), вес или сумма.
97. В таблицу пользователь может включить верхний или нижний предел, выраженный в конкретных единицах измерения, выше или ниже которого никакие затраты не начисляются. Это дает возможность, например, относить затраты на фрахт в зависимости от веса груза или не начислять административные расходы выше определенного для данного заказа предела. В этой таблице учетные единицы затрат или учетные единицы управления связаны с набором затрат. Для этих учетных единиц в соглашение о цене может включаться ранжированный прейскурант.
98. Наборы затрат могут быть связаны с клиентами, группами клиентов или с номером компании.
99. Поставки комплектующих могут регистрироваться в групповом режиме с помощью спецификации изделия.
100. Доступность связи с особыми контрактами.
101. Пользователь может просмотреть статус каждого заказа.
102. "Финансовая многозвенность" при описании процедур продажи.
103. Если изделие компонуется из составных частей, то система может напечатать основное изделие, его компоненты или и то и другое вместе.
104. Поставки могут вводиться в систему по заказу или по ведомости комплектации.
105. Обеспечение ввода количества грузовых мест и веса для оплаты транспортировки. различными видами транспорта.
106. Обработка частичных поставок сопровождается автоматическим созданием дозаказов.
107. Дозаказы могут запускаться на исполнение при использовании специальной функции подтверждения. Возможна распечатка упаковочного листа для каждого экспедитора в отдельности, а также товарных ярлыков, определяемых пользователем.
108. Данные по поставкам могут вызываться:
• по заказам
• по ведомостям комплектации
• по описям вложения
• по коносаментам
• по счетам-фактурам
109. Могут быть заданы области значений номеров заказов для идентификации типов счетов-фактур.
110. Пользователь может напечатать контрольный лист для каждой процедуры выписки счетов-фактур с разнообразными итоговыми суммами. Планы продаж можно копировать из ретроспективы, из других планов продаж и т.д.
111. Система может генерировать финансовое распределение планов в абсолютных суммах на базе предопределенных процентных соотношений.
112. Планы продаж могут сопровождаться или модифицироваться в ручном режиме.
113. Планы продаж можно сравнивать со статистикой реальных продаж. Коммерческие предложения могут автоматически преобразовываться в заказы на продажу, включая все их данные, тексты и т.д. Безрезультатные коммерческие предложения удаляются, но могут быть указаны причина неудачи и конкурент, которому вы уступили заказ.
114. Открытые коммерческие предложения могут быть идентифицированы по различным спискам, таким как список по дате окончания срока, список по торговым представителям, по изделиям и т.д.
115. Успешные коммерческие предложения (имеющие результатом заказ на продажу), а также безрезультатные можно идентифицировать в ретроспективе, где они могут быть сгруппированы по причинам успеха/неудачи или по конкурентам.
116. Для каждого складского места можно определить основные данные, включая текстовую информацию.
117. Могут быть установлены приоритеты для порядка размещения изделий.
118. Можно задать последовательный номер при отпуске
119. С местом на складе можно связывать какие-либо сообщения.
120. Может быть задана граничная вместимость (емкость) складского места. Для каждого места можно специфицировать максимальную емкость, а также предупреждающую процентовку степени наполнения места, которая должна выдаваться при приближении к максимально разрешенной емкости или ее превышении.
121. Складские места могут быть заблокированы для проведения конкретных операций (размещения, отпуска, перемещений с места или на место) или для всех типов операций.
122. Для каждого склада может быть указано место приемки и контроля поступлений.
123. Пользователь системы может определять, в каком режиме используются конкретные места на складе: однономенклатурном (для изделий одного типа или одной партии) или многономенклатурном (одновременно для различных изделий или разных партий).
124. Изделия можно приписывать к фиксированным местам хранения.
125. Если организация хочет перейти от использования складской системы без ведения учета складских мест к системе с таким учетом, этот переход может быть осуществлен автоматизированным способом, и все запасы расписаны по складским местам. Такой подход обеспечивает в результате быстрое внедрение системы складского учета с регистрацией складских мест.
126. Каждое складское место может идентифицироваться координатами: ряд, полка, ячейка .
127. Предусмотрены стандартные процедуры по созданию складской системы с регистрацией складских мест по рядам, полкам, ячейкам.
128. Ниже перечисленные операции с запасами производятся по складам, по складским местам, по единицам хранения и, при необходимости, по партиям (работа с этими операциями может учитывать их распределение во времени (по временным этапам)):
• корректировка запасов
• перемещения запасов
• заказы на закупку
• заказы на продажу
• отпуск на производство
• поступления с производства
129. Каждая операция с запасами может быть санкционирована.
130. Все операции с запасами можно списочно отразить в различных отчетах
131. Могут предварительно определяться такие аспекты, как максимальное количество складских мест, подлежащих инвентаризации, нужно ли распечатывать результаты инвентаризации в инвентарных ведомостях и т.д.
132. Учтенные запасы могут быть проверены по проверочному отчету перед тем, как система приступит к обработке результатов инвентаризации.
133. Предоставляются списки, отсортированные по различным критериям; данные по запасам могут быть распечатаны и проанализированы и в единицах запаса и в единицах физического хранения.
134. Для изготовляемых изделий можно получать покомпонентные списки запасов. Можно распечатывать списки пополнения запасов, исходя из принципа пополнения часто используемых складских мест запасами из менее используемых мест хранения.
135. Каждая операция с запасами должна будет зарегистрирована в файле ретроспективы и может быть потом из него восстановлена.
136. Пользователь может произвести "чистку" ретроспективы, установив соответствующую дату, инициирующую этот процесс.
137. Условия хранения можно определять на четырех уровнях:
• по складам
• по складским местам
• по группам изделий
• по изделиям
138. Характеристика условий хранения может иметь три градации: приемлемые, неприемлемые, универсально пригодные.
139. Условия хранения проверяются при размещении товара на хранение. Если изделию назначается место с неадекватными условиями, система будет осуществлять поиск другого складского места с условиями, отвечающими требованиям, пока оно не будет найдено.
140. Поддержка дискретного производства различных типов – единичного, серийного, массового.
141. Поддержка методов организации производства “Джит” (JIT), “канбан” и “непрерывный производственный поток” и их сочетаний.
142. Расчет нормативной и фактической себестоимости продукции.
143. Оперативное управление производственным процессом\.
144. Предусмотреть моделирование производственных планов, в том числе: Master Production Scheduling, MPS с учетом разбиения “родительского” планового заказа на общие потребности в компонентах, взаимная компенсация для определения чистых потребностей, размеров партий и опережений, рекомендации по перепланированию, вычисление потребностей в производственных мощностях и ликвидных ресурсах
145. Создание и отслеживание выполнения планов производства, основного плана – графика многозвенных структур, планирование производственных ресурсов MRP II, планирование потребности в производственных мощностях (CRP)..
146. Учет затрат машинного и рабочего времени, материалов, финансовые анализы MRP/CRP и другие функции;
147. Планирование производственно-хозяйственной деятельности с учетом ограничений и приоритетов;
148. Управление инвестиционными проектами и капитальным строительством;
149. Управление качеством продукции (в соответствии со стандартом качества ISO-9000).
150. Управление заказами транспорта с использованием любых систем тарифов.
151. Управление техническим обслуживанием.
152. Контроль горюче – смазочных материалов.
153. Учет отработанного времени и издержек.
154. Планирование заказов с определением и сравнением затрат.
155. Управление упаковкой.
156. Управление установкой оборудования.
157. Управление периодическим обслуживанием.
158. Управление вызовами при авариях.
159. Поддержка справочника номенклатуры.
160. Возможность задания маркетинговых проектов, в которых содержится информация по коммерческим отношениям, фазам проекта, контактным лицам, работникам подразделения маркетинга, датам контактов, а также по другим определяемым пользователем характеристикам, количество которых не ограничивается. Работы могут быть связаны с финансовыми планами, коммерческими предложениями, заказами на продажу и заказами на обслуживание.
161. Поддержка рабочих планов.
162. Поддержка указаний о том, кто и какие действия должен выполнять. Если некоторая работа требует выполнения дополнительных действий, то предусмотреть на основе определенного критерия отбора автоматически внести эти действия в качестве следующего шага маркетингового проекта.

9.6.4. Основные функции OLAP
1. Многомерное концептуальное представление данных (Multi-Dimensional Conceptual View). Концептуальное представление модели данных должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции "анализа вдоль и поперек" ("slice and dice"), вращения (rotate) и размещения (pivot) направлений консолидации.
2. Прозрачность (Transparency). Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.
3. Доступность (Accessibility). Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы, но при этом данные могут оставаться под управлением СУБД, будучи при этом привязанными к общей аналитической модели. То есть инструментарий OLAP должен накладывать свою логическую схему на физические массивы данных, выполняя все преобразования, требующиеся для обеспечения единого, согласованного и целостного взгляда пользователя на информацию.
4. Устойчивая производительность (Consistent Reporting Performance). С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.
5. Равноправие измерений (Generic Dimensionality). Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены отдельным измерениям, но поскольку все они симметричны, данная дополнительная функциональность может быть предоставлена любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение.
6. Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling). Инструмент OLAP должен обеспечивать оптимальную обработку разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной величиной для моделей, имеющих разное число измерений и различную разреженность данных.
7. Неограниченная поддержка кроссмерных операций (Unrestricted Cross-dimensional Operations). Вычисления и манипуляция данными по любому числу измерений не должны запрещать или ограничивать любые отношения между ячейками данных. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формульном языке.
8. Интуитивное манипулирование данными (Intuitive Data Manipulation). Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе.
9. Гибкий механизм генерации отчетов (Flexible Reporting). Должны поддерживаться различные способы визуализации данных, то есть отчеты должны представляться в любой возможной ориентации.
10. Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels). Каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.
11. Удобство средств администрирования (формирование новых измерений, модификация существующей модели, возможность анализировать данные, собранные в ранее созданных базах)
12. Гибкость настройки и наглядность форм демонстрации результатов. (Интуитивность представления информации, качественность и удобство формирования отчётов, наглядность графических возможностей, связь с ГИС-технологиями, наличие механизмов экспорта результатов в стандартные форматы)
13. Широкий спектр методов постобработки данных, доступность средств интеллектуального анализа (Расширенные аналитические возможности и элементы Data Mining)
14. Возможность обработки больших хранилищ данных с приемлемой производительностью.
15. Увязка OLAP-инструментария со всеми используемыми в ЕСЭДО РК СУБД.

9.7. Функции поддержки принятия решений
1. Графическое представление деятельности ведомства, отрасли, государства в виде дерева, ветвями которого являются группы показателей, характеризующих то или иное направление деятельности
2. Разработка системы показателей на этапе настройки с возможностью усовершенствования в любой момент. Показатель вычисляется по произвольной заданной на этапе настройки формуле, исходными данными для которой являются данные системы. Для каждого показателя задаются минимальное, максимальное, стандартные значения и границы «рискованных» диапазонов
3. Иерархическая структура диаграмм с возможностью детального анализа причин возникновения критического отклонения показателей от оптимальных значений
4. Определение по каждому показателю лица либо организации, ответственных за нормальное функционирование направления деятельности
5. Специализированная, интуитивная и интерактивная поддержка принятия решений по сценарию:
• Где мы сейчас находимся?
• Куда мы намерены идти?
• Как мы туда дойдем?
• Как мы измерим наш прогресс?
• Как идет исполнение по сравнению с намеченными целями?
• Что идет не так?
• Какие тренды?
• Какие причинные факторы?
• Где мы должны вмешаться?
• Каково воздействие нашего вмешательства?
• Кто будут наилучшими партнерами (контрагентами)?
• Как сохранить и повторно использовать полученный опыт?
6. Предоставление субъектно – ориентированной, структурированной интегрированной информации во многих измерениях с возможностью drill down.
10. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ ВТОРОЙ ОЧЕРЕДИ (НАЦИОНАЛЬНОГО УРОВНЯ) ЕСЭДО РК
Поскольку работы второй очереди ЕСЭДО РК являются логическим продолжением работ по разработке и опытной эксплуатации подсистем первой очереди ЕСЭДО РК на первом этапе «Проектные работы», охватывающем 2 и 3 кварталов 2003 года, должны быть осуществлены:
1) разработка методологии национального уровня ЕСЭДО РК и уточнение конфигурации подсистем;
2) разработка технорабочего проекта на подсистемы национального уровня ЕСЭДО РК, в котором будут уточнены тип вычислительной техники, лицензионного программного обеспечения, сетевого оборудования;
3) разработка базового и специального программного обеспечения с использованием лицензионного ПО;
4) проведение тестирования и опытной эксплуатации подсистем национального уровня ЕСЭДО РК;
5) доработка программного обеспечения по результатам опытной эксплуатации.
На втором этапе «Поставка оборудования» в течение 2 и 3 кварталов 2003 года осуществляется:
1) определение поставщиков одного комплекта серверного и сетевого оборудования из числа надежных отечественных компаний;
2) заключение договоров о поставке;
3) поставка и монтаж оборудования, установка, настройка и параметризация программного обеспечения для проведения опытной эксплуатации ЕСЭДО-Н РК.
На третьем этапе в течение 4 квартала 2003 года подключение подсистем ведомственного уровня пилотной зоны внедрения ЕСЭДО к ЕСЭДО-Н РК, проведение тестирования и опытной эксплуатации.

11. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ВТОРОЙ ОЧЕРЕДИ (НАЦИОНАЛЬНОГО УРОВНЯ) ЕСЭДО РК
1. Предварительное тестирование системы;
2. Тестирование системы;
3. Опытная эксплуатация;
4. Сбор замечаний по программному комплексу и проведение доработки;
5. Сдача программного комплекса ЕСЭДО-Н РК в промышленную эксплуатацию.
Перечень участвующих предприятий и организаций:
Заказчик: Комитет по связи и информатизации Министерствв транспорта и коммуникаций Республики Казахстан.
Объект внедрения – государственные органы Республики Казахстан.
Исполнитель – ЗАО «НИТ РК»
Место проведения - на объекте внедрения.
Сроки проведения опытной эксплуатации – определяется дополнительным соглашением сторон.



12. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ ВТОРОЙ ОЧЕРЕДИ (НАЦИОНАЛЬНОГО УРОВНЯ) ЕСЭДО РК В ДЕЙСТВИЕ
При подготовке объекта автоматизации (каждого из трех создаваемых Центров управления национальным уровнем ЕСЭДО РК отдельно) должны быть выполнены следующие мероприятия:
1. Разработка (конкретизация) плана работ по внедрению Национального уровня ЕСЭДО РК;
2. Подготовка и обучение персонала;
3. Подготовка и обучение пользователей;
4. Подготовка ЛВС к инсталляции программного комплекса ЕСЭДО-Н;
5. Подготовка сервера к инсталляции ЕСЭДО-Н
6. Сбор данных о специфике ведения архива в ведомстве;
7. Инсталляция серверной части программного комплекса ЕСЭДО-Н на сервер;
8. Инсталляция клиентской части программного комплекса ЕСЭДО-Н на рабочие станции;
9. Настройка и параметризация ЕСЭДО-Н;
10. Опытная эксплуатация;
11. Сдача программного комплекса ЕСЭДО-Н в опытную эксплуатацию.





13. ТРЕБОВАНИЯ К АППАРАТНОМУ ОБЕСПЕЧЕНИЮ
13.1. Требования к аппаратному обеспечению серверов системы
При построении ЕСЭДО-Н РК необходимо обеспечить высокую производительность и надежность компьютерных систем. Ниже приводится перечень компонентов аппаратного обеспечения высокой производительности:
• быстродействующий процессор;
• большая оперативная память и кэш с высокой загрузкой;
• быстродействующая система ввода-вывода;
• быстродействующая система хранения данных.
Процессор сервера.
При выборе аппаратного обеспечения серверов для ЕСЭДО-Н РК необходимы системы с RISC-процессором, поддерживающие многопроцессорность (симметричный мультипроцессор, массовый параллелизм процессов) с возможностью объединения в кластеры.
Оперативная память сервера.
Оперативная память аппаратного обеспечения должна обеспечить корректную, надежную и быструю реакцию. При выборе компьютерных систем для ЕСЭДО РК необходимо наличие оперативной памяти типа DDR SDRAM, DDR SDRAM-II, оперативной памяти с контролем четности.
Система ввода-вывода сервера.
Система ввода-вывода аппаратного обеспечения должна обеспечивать поддержку следующих международных стандартов: SCSI (UltraWide SCSI, UltraWide SCSI2), HIPPI, FDDI, FC-AL.
Система хранения данных сервера.
Система хранения должна обеспечить защиту от аппаратных сбоев, увеличить одновременно используемых процессами пространства на жестком диске. Системы хранения данных должны поддерживать использование избыточных массивов независимых дисков (Redundant Arrays of Independent Disks, RAID).
Внешние устройства хранения информации.
Устройства хранения информации должны быть готовы к построению выделенной сети хранения SAN, не связанной с сетью серверов. SAN позволяет любому серверу получить доступ к любому накопителю, не загружая при этом ни другие серверы, ни локальную сеть. Кроме того, возможен обмен данными между накопителями и без участия серверов.
Коммуникационное оборудование.
Коммуникационное оборудование, обеспечивающее функционирование серверов и систем хранения информации ЕСЭДО-Н, должно обеспечивать максимально возможную производительность с использованием технологий Gigabit Ethernet.
Дополнительные характеристики аппаратного обеспечения ЕСЭДО-Н РК.
Дополнительно аппаратное обеспечение ЕСЭДО-Н РК должно обеспечивать:
работу в территориально-распределенной реализации проекта;
• для обеспечения бесперебойной работы также необходимо иметь возможность использования кластерной технологии;
• при вводе в эксплуатацию ЕСЭДО-Н РК обязательно наличие систем оперативного архивирования/восстановления данных большого объема;
• аппаратное обеспечение должно сохранять работоспособность в случае отключения электропитания в течение 48 часов.
ЕСЭДО-Н РК представляет собой следующий комплект серверов организующих интерфейс доступа с обеспечением первого уровня авторизации и защиты информации:
Коммуникационный сервер, обеспечивающий функции разделения и защиты внутренних локальных сетей и внешних сетей, функции proxy-сервера (при необходимости), управления и стандартных сервисов Интернет. Этот сервер должен также работать как сервер электронной почты, обеспечивающий обмен массивами информации, автоматизированный пакетный ввод, корректуру, автоматический доступу пользователей к подсистемам ЕСЭДО-Н РК посредством стандартизированного набора команд.
Серверы приложений, должны обеспечить организацию доступа всех генераторов информации и пользователей различных уровней к сервисам ЕСЭДО-Н РК (управления знаниями, поддержки принятия решения, массового доступа к ЭД и знаниям) с использованием стандартных протоколов верхнего уровня. Для обеспечения оптимальной надежности всей подсистемы на этапе технического проектирования определяется необходимость дублирования всех критических подсистем.
Сервер электронной почты, обеспечивающий обмен массивами информации, автоматизированный пакетный ввод, корректуру, автоматический доступу пользователей к БД ЕСЭДО-Н РК посредством стандартизированного набора команд. Указанные задачи требуют на этапе реализации проекта разработки и внедрения специальных программных комплексов.
Кроме того, ЕСЭДО-Н РК включает комплект серверов обеспечивающих функционирование подсистем управления знаниями и организации хранения информации:
Полные требования к серверному и сетевому аппаратному обеспечению ЕСЭДО-Н РК уточняются на этапе «Проектных работ».
14. ТРЕБОВАНИЯ К БАЗОВОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
14.1. Требования к базовому программному клиентских мест системы
• Операционная система
Операционная система должна иметь интуитивно-понятный и привычный для большинства пользователей интерфейс.
В качестве клиентских операционных систем выбраны Windows 2000/ХР, либо Linux.
• Internet-browser
выбран Microsoft Internet Explorer 5/6, т.к. это комплексное решение, обеспечивающее полную поддержку Internet и Intranet технологий в прикладных системах. Он поддерживает большинство существующих стандартов и модификаций HTML.
• Средства делопроизводства
Программные средства делопроизводства офиса являются стандартными средствами создания документов. Средства делопроизводства офиса могут быть использованы для визуализации и дополнительной обработки информации, а также организации групповой работы пользователей. Также эти средства должны поддерживать технологии ODBC, ODMA.
В качестве базового программного пакета автоматизации делопроизводства офиса выбран пакет MS Office ХР, включающий следующие программные средства:
- текстовый процессор Microsoft Word 2002;
- табличный процессор Microsoft Excel 2002.
• Средства антивирусной защиты ПО и данных
должны иметь механизмы эвристического анализа, резидентного сканирования, автоматического обновления антивирусных баз из внешнего источника. В качестве средства антивирусной защиты ПО и данных выбран Dr.Web, имеющий наилучшие показатели по обнаружению вирусов по данным Virus Bulletin.
14.2. Требования к базовому программному обеспечению серверов национального уровня
• Операционная система - Системное программное обеспечение серверов баз данных и серверов приложений принадлежать классу UNIX-систем, имеющих конкретную реализацию в зависимости от серверной платформы, имеющих поддержку реализаций серверов по кластерной технологии.
• Программы резервного хранения информации - Legato Storage Manager, Tivoli Storage Manager, Tivoli Data Protection (или аналогичные продукты других вендеров).
15. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
В состав документов должны быть включены следующие основные документы:
1. Пояснительная записка техно-рабочего проекта;
2. Общее описание системы;
3. Программа и методика испытаний;
4. Руководство администратора;
5. Руководство пользователя.
6. Технологические инструкции.

15.1. Пояснительная записка техно-рабочего проекта
Пояснительная записка техно-рабочего проекта предназначена для определения обоснованности выбора проектных решений. Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.
В качестве дополнительных разделов (или подразделов) в пояснительную записку необходимо включить структурную схему ЕСЭДО-Н и ее описание а также схему функциональной структуры ЕСЭДО-Н и её описание.

15.2. Общее описание системы
Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.

15.3. Программа и методика испытаний
Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.

15.4. Руководство администратора БД
Документ подготавливается Разработчиком и должен включать следующие разделы:
1. Общие положения;
2. Назначение и условия применения;
3. Установка и подготовка системы к работе;
4. Регистрация и сопровождение пользователей;
5. Распределение прав и уровней доступа в системе;
6. Обеспечение сохранности данных;
7. Обеспечение безопасности данных;
8. Репликация и актуализация данных;
9. Конвертирование данных;
10. Взаимодействие с внешними системами.

15.5. Руководство пользователя
Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.

15.6. Технологические инструкции
Документы подготавливаются на каждую технологическую операцию Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.
На разрабатываемое программное обеспечение должна быть представлена документация в соответствии с действующим ГОСТ (ЕСПД).
Покупные изделия должны поставляться в комплекте с документацией.
Chief constructor
Новичок

Зарегистрирован: 24.02.2003
Сообщения: 16

[5047] Пт Сен 26, 2003 15:30
Использование XML/EDI UN для управления эл. документами
Принято решение о введении в состав обязательных тэгов ss_id - идентификатор системы структурирования.
Для управления электронными документами в ЕСЭДО РК и СЭА ГО РК будет использовано подмножество стандарта XML/EDIFACT UN:
<?xml version="1.0" encoding="UTF-8"?>
<mandatory_attributes>
<uniqueid>уникальный идентификатор документа </uniqueid>
<title>наименование документа</title>
<processingdata>
<formatversion>версия формата</formatversion>
<mode_document>вид документа</mode_document>
<ss_id>идентификатор системы структурирования </ss_id>
<xml_edifact_un> метаданные ЭД в стандарте EDIFACT </xml_edifact_un>
</mandatory_attributes>
sergb
Гость




[5060] Вт Сен 30, 2003 14:21
ГБЛ - госбаза физлиц
C представителями «СофтИнженер» jбсуждалась реализация разработчиками фирмы формата обмена данными. Выяснено, что в данный момент исключена возможность его применения как универсального формата для создаваемых государственных информационных систем, в том числе ГБЛ. На последовавшем затем 23 сентября техническом совещании специалистов ЗАО НИТ была подчеркнута необходимость практической проверки данного формата в рамках второй очереди ЕСЭДО, прежде чем его можно будет рассматривать как вариант на утверждение в качестве стандарта межведомственного обмена.
JLM
Гость




[5070] Пт Окт 03, 2003 07:23
Emotional AI
I am reproducing some of your questions below and addressing them
individually.

Perhaps a little of my background would be in order. As you have
probably gathered I am not an expert in the SW and machine understandable field, being an
independent researcher with a master's degree in counseling
psychology. Sometimes, however, the best cross pollination comes
from outside the field! I had heard that the SW project
sometimes enters into esoteric and metaphysical issues, hence I
thought my somewhat unconventional ethical applications to
computing might be tolerated in context.
Along these lines, I was granted a patent for ethical AI just
several months ago and thought there might be applications to the
SW, being as it is the cutting edge endeavor in web development.
My main interest is seeing if adding a set of
emotional/motivational tags to a litany of what has already been
achieved would be of value to the project. After all,
motivational issues are why humans access the web to begin with.
My new system systematizes this domain to the considerable degree
of intricacy and detail required for the task. If the SW could
incorporate some of this type of organization, then it could
greatly increase its utility and versatility.
This is probably a lot to ask, but I would like to appeal to the
SW community to seriously evaluate my newly issued patent for
these kind of the applications to the project. Although the
patent is quoted at 90 pages, half of this is diagrams, with the
text really amounting to about 12 pages in a Journal style
format. The complete specification, along with diagrams, is
posted at:
www.ethicalvalues.com
Should this truly hold potential, I would be willing to waive my
proprietary rights in the interests of the bigger SW picture.
Should the consensus opinion be skeptical, then I will desist
from posting any more announcements in this regard. My
intentions are heartfelt and I would deeply appreciate an
evaluation from experts within the field.
Sincerely
John E. LaMuth MS

***********************************
Questions

"...the key knowledge bases of the AI computer would be
distributed as open source code..."
What does it mean to distribute a knowledge base as open source
code?

Ans. The knowledge base for a convincing AI simulation would be
enormous, making the Web a perfect resource for storage and easy
access by the inference engines that would drive the simulation.
With the proper tags, the entire SW could function in this
regard, evolving and refining overtime.

"...of the AI mode would theoretically process of a large number
of conversations simultaneously..."
What is the AI mode? Why are we processing conversations?

Ans.. My system is divided into three basic modes of operation,
the passive monitoring mode-which monitors conversations without
intervening itself; the active monitoring mode-which intervenes
with simple questions for clarifications; and the true AI
mode-which takes part as a full entity in the interchange.

You spend a lot of time talking about distributed processing yet
as far as I can tell your work does not address this issue in any
way!

ANS… the inference engine is composed of multiple processors
(one devoted to each motivational term) therefore splitting up
the decoding of ongoing conversation into manageable units of
processing.

>From your linked to patent application "...The concept of
artificial intelligence (AI) refers to language simulated using a
computer...". No it doesn't! Although hard to define concisely it
means something like simulating intelligence with a machine, or
if you prefer, programming machines to perform tasks that
seemingly require intelligence (for a complete treatment of this
issue Franklin's "Artifical Minds" is a great read - ISBN:
0262561093).

Ans. I was referring to the classical definition by Turing
where he uses a ticker-tape machine, in this case, the
intelligent use of language reflects intelligence itself.

When you say AI do you mean a branch of AI like natural language
processing, or computational linguistics?

My patent aims to implement AI as classically defined, where a
true personality and intelligence in the use of language is
simulated through the aid of the elaborate system of ethical and
motivational terms contained therein.

In regards to your contributions to ethics, I am unsure as to
their worth, your heirarchy does seem interesting, but again no
references, I always thought philosphy renowned for it's lengthy
bibliographies.

Ans…. I have a four page bibliography in my latest book that
credits the many influences in my theories. I would be glad to
forward these to those interested, although this informal
list-serve I think it is not the proper place. My new ethical
theory is a culmination of over 20 years of intensive Independent
Research, being released only over last couple years to a limited
audience (considering its complexity). I am hoping that its
wide-ranging applications will remedy these limitations in the
future.

Although we are tempted with "...the SW initiative would be wise
to at least leave open the potentiality for such a motivational
AI kernel...", there seems to be little relationship between this
work and the semantic web. Are you proposing that the logic/proof
layer of the semantic web analyse web content based on your
emotional taxonomy? This seems counter intuitive as the whole
point of ontologies which is to make the meaning of a statement
clear.

Answer …. Again I am appealing to those experts within the field
to proffer a preliminary evaluation of what potential this
ethical innovation may offer, perhaps even coming up with an
angle I could not have imagined, to the benefit of the overall
project in general.
Sincerely
JLM
Bazilio
Гость




[5071] Пт Окт 03, 2003 11:18

Начальный автор треда сделал серьезнейший промах, выпустив нить дискуссии из рук: просто вываливая сюда скопом свои многотонные 'Требования к 2-й очереди' (впрочем, так и не приоткрыв для тех, кто не в курсе, физического состояния реализаций Первой). И при этом умудрился так и не сформулировать ни одного ясного вопроса, что именно он собирается услышать?

Естественно, что тред превратился в какой-то мусор частных анонсов. Кажется, у каждого выступающего впечатление одно - у Буратино в кармане золотые и без четкого плана на них, теперь нам осталось лишь поактивней показать ему направление, в котором то самое поле чудес и то дерево, под которым обычно их принято закапывать.. Wink
Гость





[5072] Пт Окт 03, 2003 14:58
О состоянии работ по первой очереди создания ЕСЭДО РК
В настоящее время функционируют 3 ЕСЭДО-В автоматизации бумажного документооборота - в АДминистрации Президента, Минсельхозе и МИД. До конца года будут сданы еще 9 ЕСЭДО-В 1.1 разработки ЗАО НИТ и 9 ЕСЭДО-В (версия не присвоена) разработки ТОО "Софтинженер". После согласования и утверждения нормативно-правовых документов на систему кодирования и классификации для использования КМПКФ в ЕСЭДО РК, Национальный центр ЕСЭДО РК в октябре - ноябре с. г. создаются предпосылки для разработки ЕСЭДО-В в версии автоматизации электронного документооборота с января 2004 года.
Chief constructor
Новичок

Зарегистрирован: 24.02.2003
Сообщения: 16

[5074] Вс Окт 05, 2003 12:09
Чего я хочу от посетителей темы КМПКФ
Уважаемый Bazilio сделал серьезное замечание в первой части своей заметки, но в пылу полемики пропустил, вероятно, мой призыв к обсуждению на первой странице темы.
Чтобы не повторяться, изложу, чего я бы хотел от вас, уважаемые посетители, сейчас (тактически).
ТОО "Софтинженер" создает сейчас вторую очередь ЕСЭДО. Разработчиков волнуют, прежде всего, прикладные вопросы реализации КМПКФ для электронного документооборота, иначе им не удастся осуществить взаимодействие ведомственного и национального уровня.
Меня же интересует взаимодействие ВСЕХ систем в составе Национальной Информационной Инфраструктуры НИИ РК. Для этой цели надо было найти компромисс при доработке КМПКФ, позволяющий увеличить его гибкость. Итак, этот формат имеет на сегодняшний день лишь ТРИ обязательный тэга: uniqueid, title и posessingdata. В последний включен ss_id - идентификатор системы структурирования. И пусть софтинженеры используют для электронного документооборота XML/EDI - это всего лишь одна из множества систем структурирования формата. Плохо будет идти работа - передаелаем правила на другой классификатор либо подключим к EDIFACT еще что-то. Но как сделать связки между EDIFACT и этим "что-то", например, всего лишь УДК с его 700 страницами рубрик в 2 колонки? Это ведь всеобъемлющая система, а не те ограниченные выборки онтологий, над которыми усердно работает сейчас множество людей в SW! А если "что-то" - тридцать систем объемом с УДК???
Вот расплата
За гибкость формата!
Да еще таксономии автоматически строятся лишь на пару - тройку уровней!
Налицо изобретательская ситуация и разрешить ее может новый google-вод, по известной аналогии - то, что не смогли сделать yahoo etc., решили разработчики Google с алгоритмом, учитывающим число кликов пользователей на страницу.
Вот этот шаг, один лишь маленький шаг позволит приблизиться к построению связок между рубриками разных систем, а отсюда и до автоматического
Итак вопрос,
"Как использовать читателей документов
для классификации прочитанных документов?"
Bazilio
Гость




[5075] Пн Окт 06, 2003 11:02

Нет, без дальнейших пояснений скорее потемнело, чем посветлело
Скорее всего, "вам виднее", но на скромный взгляд постороннего:

1. Всякие EDIFACT, вне зависимости от степени кривизны, в кон. итоге пытаются (скажем, через EANCOM или нечто иное) ТОЧНО классифицировать "товары, услуги, компании и т.п." - ну или некие объекты бизнеса

2. Всякие УДК, скорее, пытаются ТОЧНО классифицировать что-то иное, не объекты и услуги, а "беллетристику документов", пусть даже иногда и относящуюся к товарам, бизнесу или всяким связям.. Проблема mapping'а между EDIFACT и, скажем, УДК, нет слов, крайне непроста и тяжела, но _КАЖЕТСЯ_, что понятие mapping (тот или иной механизм трансляций/преобразований) - единственный практический подход.

3. yahoo и Google вообще ничего ТОЧНО НЕ классифицируют и даже не пытаются и на их принципах вообще нельзя строить никаких документооборотов - они по-своему решают задачу "НАЙТИ", и их _результатом_ (неважно, как выглядят лежащие сбоку/на-лице/сверху/снизу их классификаторы) являются обычно лишь того или иного качества болота ссылок на "кто-что-когда-сказал во всемирной сети" ОЧЕНЬ-ПРИМЕРНО-relevant тому, что _сказал_ (в формуле поиска) некто, плюс лучше если этот некто хорошо понимающий проблемы СВОЕЙ неточности и ИХ неточности...

4. SW: Неверно, что SW обязательно двинется на тропу классификации "вообще". Да, львиная доля усилий в SW на это повязана, но есть и другие подходы, в частности отрицающие принцип общей классификации, а просто исследующие поле "машино-семантического понимания того, что размечено" - в любом случае ответом там являются единичные факты типа "фирма xyz купила табуретку RX6785", а не туча странных ссылок для дальнейшего изучения, в каком/каких документах однажды сказали о табуретке или о фирме xyz...

в любом случае без ваших дальнейших пояснений вопрос:
>> "Как использовать читателей документов
для классификации прочитанных документов?"

в рамках темы, ЕСЭДО, НИИРК и пр. этот вопрос выглядит странным и неясным. Ведь только в одном случае - если ЕСЭДО-2 должно походить на общий поисковик типа Google (пусть Google-ver.10) и решать исключительно похожие на гугль задачи, вот только тогда, вероятно, заданный вопрос правомерен. Возможно, я где-то ошибаюсь...
Chief constructor
Новичок

Зарегистрирован: 24.02.2003
Сообщения: 16

[5085] Пт Окт 10, 2003 16:44
на замечания Bazilio
Прошу прощения за задержку с ответом - в Астане всегда сложно со временем - приходится решать сразу много дел не мыслительного направления Smile
Согласен с замечанием Bazilio, что механизм установления соответствий между рубриками разных систем структурирования должен быть, иначе идея КМПКФ теряет всякий смысл.
А вот по поводу крупнейших поисковых сайтов - имхо, в этих организациях имеются довольно большие команды, поддерживающие ИХ классификаторы, хотя, конечно им до того же УДК – ББК и тем более МКИ – как до луны.
Как будет развиваться далее SW, действительно трудно предположить – здесь априорно надо мыслить совсем другими категориями, чем в процессе формулировании проблемы SW Тем не менее, имхо, подход «намусорил – разбери» свойственен человеческой природе и вероятность «причесывания» существующего Инета явно ненулевая.
Ну вот, добрались и до вопроса «Как использовать читателей документов для классификации прочитанных ими документов?»
Предположим, что мы определили "стиль" в подборке документов по рубрике одного классификатора на основе обработки имеющихся в Инете рубрицированных по данному классификатору документов (Стиль здесь понятие, похожее на авторство, которое многие программки сейчас определяют по результату обработки авторских текстов, в т. ч. для нахождения плагиата либо отнесения документа к наиболее вероятному автору, но отличающееся тем, что указывает на отношение документа к рубрике. Помогите с термином, пжлста! Smile ) Теперь эту машинную классификацию надо бы проверить, что должен сделать читатель документа. Такой смешанный подход очень пригодится в процессе обучения поисковика с использованием нейронных сетей (Convera, например). Кстати, поисковик a la Google etc. есть обязательная принадлежность ЕСЭДО-Н. Но как это сделать, как подвигнуть читателя на определенные усилия?
Прошу правильно понять – задача машинной обработки находится еще в стадии решения, но там хоть что-то видно, а вот с читателем – сложнее…
Создать новый Google++ за гос. деньги никто не даст... А без людей ну никак не обойтись.
Bazilio
Гость




[5086] Сб Окт 11, 2003 10:23

a) если для поиска нужных сведений (мы даже не произносим о 'решении или задач') вам нравится (или полезна) система Google, вероятно лучшее, что тут можно посоветовать в свете экономии вашего же времени - задайте все нужные вам вопросы у нее(него) - у Google (не сомневайтесь, оно дает тонны важной информации).
Вероятно, в этом заключена наиболее полезная часть ответа, но чтобы хоть чем-то вам помочь и прикоснуться к мучающему вас конкретному вопросу:

>> Как использовать читателей документов
для классификации прочитанных документов?

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

c)

Цитата:

... это решили разработчики Google с алгоритмом, учитывающим число кликов пользователей на страницу. Вот этот шаг, ОДИН ЛИШЬ [выделено мной] маленький шаг позволит ...


То, что, кажется, назвали алгоритмом Google вы - по-моему, нечто, которое тупо по клику читателя (любому клику) просто делает update некоего 'хранимого коэффициента актуальности страницы' (пусть по-другому называется), причем делает это тривиальной весовой функцией, не раз где-то мелькавшей, и кажется, из которой секретов никто и не делал.

No magic - НЕТ в Google (как и любом прогрессе) никакой магии, но есть результативность. То, что назвал бы алгоритмом Google я - это годы пота умных людей над сотнями сверх-быстрых кодов (на уровне кристаллизации ассемблера из C), ну и быстрое железо. Вам нужен a-la-Google - купите у них часть движка, на которую просто хватит сумм (и думаю, что самую важную формулу 'шага, учитывающего число кликов' они отдадут за 10 долларов)

d) >> Как использовать читателей документов
для классификации прочитанных документов?

Клик - здесь максимумум, что вам удастся "взять" с читателя, тем паче чиновника (и кажется, АБСОЛЮТНЫЙ максимум). Тем не менее, по мне постановки, умудряющиеся термин "дать" заменить на плоскость изящной непосредственности термина "взять" - как часто они удивительны и восхищают.. (тссс.. между нами Wink
Chief constructor
Новичок

Зарегистрирован: 24.02.2003
Сообщения: 16

[5088] Вс Окт 12, 2003 13:45
Нам не нужно ждать милостей..., взять их - наша задача
Argumentum ad hominem, mr. Bazilio! Smile
Не чиновники нужны, но читатели Инета, поскольку (виноват, неочевидно из моих мыслей на форум) лишь в Инете есть достаточные для посмертной рубрикации ресурсы. А "дать - взять" - игра слов лишь. И Google'вский алгоритм здесь не поможет, ибо для других целей он.
Завлекушечки - примитивно, обращения - не будут действовать и т. д. и т. п. А ИКР (идеальный конечный результат - системы нет, а ее функции выполняются) стоит неприступной стеной, других дураков ожидает (парафраз русской народной, простите за дурака).
Для того пишу на форум,
Пусть ругают долго хором,
Вдруг обронит кто зерно,
В нем нуждаемся давно!
Вот снова и снова выходит народ с идеей о ERP - системе на XML, значит интересно...
А здесь, с форматом-то, что-то никак мешок с идеями не прохудится. Может вы почин сделаете, Bazilio? Пожалуйста... время поджимает, да и на общую, а не частную пользу это будет Smile
Bazilio
Гость




[5089] Вс Окт 12, 2003 18:28

Не поймите превратно - я довольно слаб в риторике и вовсе не хотел бы никого упрекнуть, а просто хоть на 2 цента понять рассуждения собеседника

В постановке на ЕСЭДО черным по белому в неск. местах было вывешено:

>> создание Eдиной Системы Электронного Документооборота государственных органов РК

С какой-то долей понимания (с локомотивом приложенных пунктов) простынь казалась толкуемой, в главном пользователе виделись некие Чиновники, а ИПС типа Kazakh-Yandex казалась чем-то таким же далеким, как скажем, Google от Госдепартамента (тем более что навскидку любая ИПС должна "заявиться" и только лет через 5 практической работы из нее, возможно, выйдет APort). Но затем, по ходу "вытаскивания из вас видения", вы честно сообщили, что главным [по линии ЭСЭДО] и интересным вопросом на форуме являются вовсе не Гос.., а "клики читателей Инета",

>> поскольку.. лишь в Инете есть достаточные для посмертной рубрикации ресурсы.

Уразуметь, где именно "д.б. Документооборот гос-органов" не вышло (как-то раньше казалось, что если б Google делал Госдеп, то где-нить к массовому освоения Марса - ну, все понимают..)

Вы считаете, нужна чиновнику Google?
Возможно, от чиновников вышел отворот. Тогда, если нужна национальная ИПС - почему не напустить на .kz просто Яндекс или Google или Yahoo, или.. или.. - все лучше любая из них (договориться), чем с нуля (?) ну, а если не с нуля, то непонятного в ваших фразах все больше и больше.

Просто, дабы проронить хоть что-то разумное, хотелось бы хоть на мизинец уразуметь задачу.
... или идею.