Сервисы dms ]Метаданные

Метаданные обычно хранятся для каждого документа. Метаданные, например, могут включать дату занесения документа в хранилище и идентификатор пользователя, совершившего это действие. DMS также может извлекать метаданные из документа автоматически или запрашивать их у пользователя. Некоторые системы предоставляют сервис оптического распознавания текста сканированных документов, или извлекают текст из электронных документов. Используя извлечённый текст система позволяет производить поиск документа по ключевым словам внутри документа.

Интеграция

Многие системы управления документами пытаются интегрировать функцию управления документами непосредственно в различные приложения, позволяя пользователю получать документ сразу из хранилища системы управления документами, делать какие-либо модификации, и сохранять его обратно в хранилище в качестве новой версии, и всё это проделывать в одном приложении, не выходя из него. Данная интеграция, в основном, доступна для офисных пакетов и почтовых клиентов или для программного обеспечения, предназначенного для групповой/коллективной работы. Интеграция обычно подразумевает использование открытых стандартов та-ких как: ODMA, LDAP, WebDAV и SOAP.

Захват

Перевод в цифру бумажных документов, используя сканеры и МФУ. Также часто используется программное обеспечение для оптического распознавания текста, чтобы конвертировать цифровые изображения в машиночитаемый текст.

Индексирование

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

Хранилище

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

Хранилище документов может представлять собой как файловое хранилище, так и хранилище в виде СУБД (базы данных). В свою очередь, хранилище документов в СУБД может производиться как в одной (единой) базе данных, так и в раздельных базах данных.

Развитые возможности поиска Известные системы

Наиболее перспективным считается направление систем, предоставляемых по модели SaaS.

22. Примеры систем автоматизации документооборота, критерии выбора.

Технологические критерии Lotus или не Lotus

Все системы, представленные на рынки, делятся на два больших класса — работающие в среде Lotus Notes и все остальные.

Если в организации используется Lotus и с него не собираются уходить, естественным выбором являются системы лотусовского семейства — от «Интертраста», «АйТи», ИРМ и пр.

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

При этом нельзя сказать, что по своим пользовательским качествам системы на базе Lotus превосходят конкурентов из не-лотусовского мира. Более того, в силу функциональных ограничений Lotus Notes до 5-й версии включительно эти системы страдали некоторыми «родовыми дефектами», снижающими их надежность при большом потоке документов.

Правда, надо заметить, что в современной версии Lotus Notes (R6) наконец реализованы транзакции в их честном СУБД'шном смысле (согласованная модификация группы записей в БД с гарантированным результатом). Тем самым устранен главный, на мой взгляд, технологический дефект Lotus, и открыта принципиальная возможность реализации OLTP-систем на его базе.

Так что сейчас технологические противопоказания с лотусовских систем сняты, и выбор является только делом вкуса. Но я склонен думать, что больших миграций уже не будет: те, кто использует Lotus, продолжат его использовать, а те, кто не подсел на него, уже и не подсядут — слишком высока цена смены корпоративной информационной инфраструктуры. Конечно, за исключением форс-мажоров, возникающих при поглощении компаний, — типа покупки ТНК корпорацией British Petroleum, в результате которой ТНК переходит на Lotus, являющийся корпоративным стандартом BP.

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

- если Lotus уже внедрен, несложные подсистемы на его базе запускаются очень быстро и начинают приносить реальную пользу; - поскольку сам Lotus является конструктором (см. дальше), то системы на его базе легко подстраиваются к поверхностным особенностям бизнес-процессов компании, что позволяет как удовлетворить ревнителей существующей практики, так и обеспечить вечной работой по подкручиванию системы IT-департамент компании; - как с любыми дорогими западными системами, при покупке значительного количества лицензий на Lotus можно рассчитывать на хорошие «откаты»; - но полноценные лицензии можно и не покупать — имеются «бюджетные» варианты для обеспечения работы через Web.

Используемая СУБД

Собственно, очевидных лидеров тут два — MS SQL Server и Oracle. Практически все не-лотусовские системы, представленные на рынке, используют MS SQL. Некоторые умеют также работать с Oracle (скажем, «Дело»). Системы, ориентированные исключительно на Oracle, мне неизвестны.

Правда, имеется также класс систем, использующих собственные хранилища документов. Как правило, они выросли из некоторых информационно-поисковых систем с большой историей (скажем, «Евфрат» от Cognitive). Свои форматы хранилищ используют также «большие» западные системы — Documentum, HB5 (ex-DocsOpen).

Использование стандартных СУБД является явным плюсом с точки зрения сопровождаемости и масштабируемости системы и простоты ее интеграции в корпоративную IT-инфрастуктуру. Хотя собственное хранилище также обладает некоторыми плюсами: не требуется дополнительно покупать лицензии на СУБД, а с точки зрения администрирования система выступает как единый «черный ящик».

Функциональные критерии Готовая «коробочная» система или (полу)заказная разработка

Это отличие определяется не столько декларациями поставщика, сколько множеством объективных факторов — функциональной полнотой системы, качеством дистрибутива, качеством и объемом документации и др. То есть, в конечном счете, может ли система быть установлена и внедрена силами «типичного» заказчика без участия программистов фирмы-поставщика. Единственным критерием тут является практика — количество заказчиков, самостоятельно установивших и эксплуатирующих систему.  Известно, что превращение проекта (заказной системы) в продукт (коробочную версию) обходится примерно втрое дороже, чем сама разработка, — такова стоимость необходимой функциональной доработки, качественного тестирования, пакетирования дистрибутива, написания документации и других мероприятий, необходимых для выпуска продукта.

Но типичной является ситуация, когда фирма сделала конкретную прикладную систему в дружественной организации Х, затем, переписав треть кода, внедрила ее в организации Y, затем, доделав ее еще немного и внедрив в организации Z, вышла с нею на рынок. Такая система, скорее всего, долго будет нуждаться в существенной адаптации (включающей модификацию кода и документации системы) под каждого нового заказчика. Процесс ее внедрения является чем-то промежуточным между собственно внедрением и заказной разработкой (поэтому мы и называем ее полузаказной).

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

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

Конструктор типа «сделай сам» или готовая прикладная система

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

В основе каждого такого конструктора лежит некоторая «метамодель», определяющая, с одной стороны, класс систем, которые собираются на нем легко и быстро, а с другой — границы его применимости.

Но в любом случае, прежде чем начать эксплуатировать систему на базе конструктора, ее нужно спроектировать и реализовать. При этом, как правило, необходимо участие программистов, так как процедуры обычно пишутся на каком-либо языке — собственном (встроенном) или стандартном (сейчас обычно на VB). Однако нет никакой гарантии, что в процессе реализации вы не наткнетесь на трудно преодолимые ограничения конструктора. В противоположность этому прикладные системы уже имеют встроенный и готовый к использованию функционал и практически не нуждаются в участии программистов для того, чтобы начинать эксплуатацию.

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

Тем не менее водораздел между ними, как правило, достаточно четкий. Если при демонстрации системы вы, к примеру, спрашиваете: как осуществляется контроль отправки исходящих документов нашей экспедицией? — и вам показывают как, — вы имеете дело с прикладной системой. А если вам начинают говорить, что это можно легко запрограммировать, для этого достаточно добавить туда-то такое-то поле и т. д., — вы имеете дело с конструктором.

И это понятно — гибкость и универсальность нередко вступают в противоречие с прикладной функциональностью. Это противоречие может сниматься при очень высоком уровне развития. Скажем, в классе бухгалтерских систем для «1С:Предприятие» оно уже снято. Этот пакет, с одной стороны, является мощным конструктором, а с другой — конкретной прикладной системой, функциональность которой описана в типовой конфигурации и успешно используется в неизменном виде большинством пользователей.

Кстати, Lotus можно рассматривать именно как такой конструктор, а все лотусовские системы — как надстройки (конфигурации).

Заметим, что именно засилье конструкторов и полузаказных систем на рынке не позволяет составить пресловутую табличку сравнительного анализа систем, так как для систем класса конструкторов почти в любую клеточку правомерно ставить плюсик — «можно запрограммировать». А какова при этом будет цена вопроса, особенно если нужно запрограммировать не только одну конкретную функцию, а их тесно взаимодействующую совокупность, — непонятно….

Плюсы и минусы выбора между конструктором и прикладной системой очевидны. Если вам нужно что-то нестандартное, не реализованное в функционале имеющихся готовых систем, или вам хочется «поиграться» (то есть занять свой персонал внутренней разработкой и настройкой системы или под это дело получить дополнительные ресурсы) — преимущества имеет конструктор. Если нужно быстро внедрять — то очевидные преимущества имеет готовая прикладная система с устраивающей вас функциональностью.

С точки зрения рисков — на конструкторе больше риск вообще не получить результата, а у готовой системы — упереться в границы ее функционала при развитии организации или увеличении масштабов внедрения. С финансовой точки зрения — на рынке имеются как «бюджетные» отечественные конструкторы cо стоимостью лицензии от десятков до сотен долларов, так и очень дорогие импортные VIP-конструкторы (тот же Documentum с лицензиями от $1000 на одного пользователя), предоставляющие неограниченные перспективы удовлетворения материальных притязаний заинтересованных лиц.

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

23. Понятие искусственного интеллекта.

Иску́сственный интелле́кт — наука и технология создания интеллектуальных машин, особенно интеллектуальных компьютерных программ. ИИ связан со сходной задачей использования компьютеров для понимания человеческого интеллекта, но не обязательно ограничивается биологически правдоподобными методами.