Отправляет email-рассылки с помощью сервиса Sendsay

Всё о документообороте

Рассылка закрыта

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Май 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Mikou

Статистика

750 подписчиков
+1 за неделю
←   Все выпуски   →

Всё о документообороте


Всё о ДОКУМЕНТООБОРОТЕ
Ведущий рассылки
Михаил Кузьмин
 

Готовые решения и платформы

Добрый день.

Новые статьи на сайте с момента выхода предыдущего анонса:

  • А. Пахчанян, Технологии электронного документооборота
    Для того чтобы в современном мире оставаться на месте, надо быстро бежать. Но скорости все увеличиваются. Что делать? Совсем не очевидно, что спасение в системе электронного документооборота, однако полезно рассмотреть типичные симптомы проблем, решению которых он поможет.
  • Госорганы задыхаются без стандарта СЭД
    Государственный аппарат России прибывает в состоянии постоянного реформирования. Происходящие изменения приводят к выпадению из поля зрения государственного регулирования ряда функций исполнительной власти. Такая участь постигла делопроизводственную сферу.
  • В. Андреев, За границами ERP
    ERP-системы становятся реалиями в автоматизации отечественных предприятий. Сегодня по тому, задумывается ли руководитель организации о внедрении той или иной ERP-системы, можно судить о серьезности бизнеса и его масштабах, квалификации и амбициях руководства компании.
  • В. Сенкевич, СЭД: во что обходится автоматизация хаоса?
    Совершенствование бизнес-процессов предприятия часто начинается с автоматизации, с введения электронного документооборота. Именно компании с несовершенными бизнес-процессами в первую очередь нуждаются в СЭД, служащей толчком к началу данного процесса. От выбора типа СЭД, определения качественных и количественных оценок ее эффективности зависят сроки внедрения и окупаемости всей системы.
  • И. Штефан, СЭД в банке: план работ по отделам
    Банковская сфера настолько специфична, что автоматизация документооборота в ней становится слишком сложной проблемой, чаще всего невозможной в рамках одной АБС. Каждый отдел банка выполняет свои задачи и требует специфического оборудования и ПО. Как быть в такой ситуации?
  • О. Седов, Электронный фундамент министерства
    Министров, которые на заседания Правительства РФ приходят со своим персональным ноутбуком, у нас не так много. Один из них – глава Министерства экономического развития и торговли Российской Федерации Герман Греф. В 2002 году он поставил перед своим ведомством задачу внедрения электронного документооборота внутри министерства.
    В былые времена документ, поступивший в министерство, проходил долгую процедуру: сначала регистрация (на это тратились сутки), затем подготовка проектов поручений (еще сутки), после этого – передача руководителю. Только через две недели, а то и более документ находил своих исполнителей внутри министерства.
  • В. Чернецкий, Порталы как инструмент управления
    Ключевыми вопросами, от решения которых зависит качество работы портала, являются выбор подходящего решения и функциональных возможностей современных портальных технологий.
  • Выдержки из статьи В.Л. Носевича, Документационное обеспечение управления на заре нового века
    Наше время, насыщенное информационными технологиями, предъявляет новые требования к документам и службам, ответственным за их создание, обращение и хранение. Компьютер позволяет не только быстро и качественно оформить документ, но и предоставляет невиданные ранее возможности по учету, контролю за исполнением документов, их передаче по каналам телекоммуникаций, оперативному хранению и поиску нужной информации. Современному руководителю не нужно ждать, пока секретарь-делопроизводитель отыщет отметку нужного документа по журналу входящей документации, затем перелистает соответствующую папку, чтобы найти сам документ. Все эти функции могут быть полностью автоматизированы, что позволяет весьма повысить скорость принятия решения и, соответственно, эффективность управления.
  • Текущие результаты говорят о реальной конкурентоспособности отечественных систем управления документами и бизнес-процессами
    Рынок ПО в России сегодня — это достаточно большая отрасль, весьма неоднородная по структуре. Поскольку мы специализируемся в области автоматизированной поддержки процессов управления и документооборота, мы достаточно адекватно можем судить о тенденциях именно этого сегмента рынка делового программного обеспечения.
  • Последствия применения факсимиле
    Наверняка почти каждая организация сталкивалась с ситуациями, когда срочно требовалась подпись руководства. И именно в этот момент выяснялось, что директора сегодня не будет и никто из присутствующих не наделен правом подписи. Или другой пример: начальнику приносят на подпись стопку документов, вес которой измеряется килограммами. Что же делать? В подобных ситуациях выручит факсимиле.

М.К.

Готовые решения и платформы

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

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

Каждая конкретная СЭД позволяет реализовать это в большей или меньшей степени. Понятно, что в наибольшей мере это реализует собственная разработка, но в подавляющем большинстве ситуаций этот вариант абсолютно неоправдан. Почему? Своё мнение по этому поводу я изложил в конце статьи.

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

  • готовые, в той или иной мере, настраиваемые решения;
  • платформы и прикладные решения на их основе.

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

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

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

Что характеризует платформу?

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

Понятно, что всё это не бесконечно, платформа тоже имеет свои ограничения и, в этой связи, платформы можно разделить на группы по степени развитости, например, известные западные бренды Documentum , Hummingbird или Lotus имеют богатейшие возможности для реализации на их основе собственного прикладного функционала. Системы от отечественных разработчиков в качестве платформ пока не настолько развиты и занимают, скорее, промежуточное положение, но движутся в ту же сторону.

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

В любом случае, разработка решения на базе платформы или разработка СЭД совсем "с нуля" это, как говорится, две большие разницы. Платформенные средства разработки позволяют получить собственное прикладное решение на порядок быстрее и легче.

Тенденции

Изначально платформ было немного, в основном западных, из которых одна из самых известных (и по сей день) Lotus Notes . Отечественные же разработчики предлагали либо решения под конкретного заказчика (конкретную специфику), либо настраиваемые коробочные решения.

Сейчас отечественные разработчики также начали выводить на рынок собственные платформы. Например, анонсированная пару лет назад и разрабатываемая в настоящее время система "ДЕЛО+", как развитие системы "ДЕЛО", но уже в качестве платформы.

Более молодые системы, такие как Directum , изначально созданы как прикладные решения на собственной же платформе, что с одной стороны позволяет настраивать и развивать систему под заказчика или реализовывать на базе платформы решения несколько другого плана, такие как CRM или управление совещаниями, а с другой стороны это уже не "голая" платформа, а готовое решение, которое может быть взято за основу при реализации проекта СЭД.

Аналогичным образом, собственные средства создания прикладных приложений на базе системы документооборота или системы управления бизнес-процессами имеют DocsVision , OPTiMA WorkFlow , Евфрат-документооборот.

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

Теперь почему неоправданна собственная разработка СЭД

Моё отношение к собственной разработке СЭД можно выразить так: ничего приличного скорее всего все-равно не разработаете, поэтому не теряйте времени и денег, или же будьте уверены, что вам это действительно нужно.

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

Ещё имеют место следующие аспекты:

  • Постановка – есть ли у вас специалисты по организации документооборота и разработке СЭД, способные охватить весь объем требований и сделать грамотную постановку?
  • Команда – потребуется команда разработчиков, в которых можно быть уверенным на ближайшие несколько лет (как минимум, в нескольких ключевых) и которые не откажутся от этой задачи после первого же релиза, когда у пользователей может возникнуть масса вопросов и предложений по доработке.
  • Стоимость – стоимость индивидуальной разработки "под себя" всегда выше покупки чего-то готового. Как говорится, "индпошив". Есть ли смысл платить больше? И чем полученный в этом случае результат будет качественно отличаться от уже существующих на рынке систем?
  • Ограниченность полученного результата – как правило, разработанная под заказ "с нуля" система будет значительно уступать существующим на рынке аналогам с точки зрения базового набора функций и технологий. По мере роста "аппетита" к СЭД и, соответственно, сложности реализации новых требований в созданной системе вполне вероятно можно придти к мысли, что проще будет выбрать что-то готовое и перейти на новую систему.
  • Развитие и сопровождение – как продолжение предыдущих пунктов – потребует сохранение проектной команды, влечет усложнение системы и, возможно, ограничение в развитии либо отказ в перспективе пользу чего-то готового.

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

Тем не менее заказные разработки СЭД периодически появляются.

Думаю, что заинтересованной стороной здесь выступает ИТ-компания (либо некая ИТ-структура), желающая выйти на рынок СЭД с собственной системой. Инвестировать в создание системы с нуля рискованно и может оказаться абсолютно неоправданно.

Поэтому предпочтительнее (помним, что именно для ИТ-компании) выглядит вариант найти заказчика, готового оплатить создание "под себя" системы документооборота. А затем уже придав полученной системе универсальность можно выходить с ней на рынок. Большинство современных СЭД изначально были созданы именно таким образом и ещё появятся.

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

И, кстати, о пожеланиях

Иногда встречается такое "да, нам нужна система документооборота, которая бы и документы учитывала, и как там дела на складе показывала, и контроль платежей ..." Тут уж или разделить задачи, или без собственной разработки, или, как минимум, платформы не обойдешься. :)

Как понять, что вам нужно, коробка или платформа?

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

И напоследок

Кстати, если среди читателей из Беларуси найдутся желающие заказать разработку СЭД по себя – пишите, есть интересные предложения.

 
Любое письмо может быть опубликовано в рассылке, если нет явного запрета на публикацию.
Для публикации адреса электронной почты, указывайте его в тексте письма.
 
С пожеланиями успехов,
Михаил Кузьмин
 
Сайт рассылки http://edoc.at.tut.by
БЛОГ автора рассылки
http://itstrategy.livejournal.com
В избранное