О чем не расскажет вендор: технические тонкости выбора ECM-системы

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

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


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

    Пример первый. В некоторой организации для утверждения контрактов необходимо получить согласование от 3 -10 ответственных лиц. Учитывая, что все эти лица находятся территориально удаленно друг от друга, процесс согласования контракта существенно растянут во времени, что мешает компании оперативно решать вопросы согласования и подписания контрактов, и создает ряд трудностей при работе с клиентами и поставщиками. Следовательно, необходимо внедрить такое ПО, которое позволяло бы: (1) создавать контракты; (2) автоматизировать движение контрактов по определенному маршруту и при необходимости этот маршрут изменять; (3) поддерживать процедуру подписания; (4) хранить все версии документа по процессу согласования и конечную подписанную версию. Для решения поставленных задач в данном примере идеальным образом подойдет система электронного документооборота.

    Пример второй. В строительной организации предполагается автоматизировать процессы систематизации и хранения всей информации, получаемой и создаваемой в процессе выполнения проекта. Информация разнообразна по типам и форматам, обширна в объемах: конкурсная документация, контракты и приказы, проектная и рабочая документации на строительство и изменения к ним, сметы и изменения к ним, ПОР, ПОС и ППР, акты освидетельствования, заключения, фото и видеоматериалы, и другая необходимая документация. Она может быть в любой момент затребована подрядчиками, субподрядчиками, контролирующими и проверяющими процесс строительства и приемки организациями. Указанная документация собирается по мере исполнения проекта, поступает как из внешних источников, так и является результатом внутренних работ, в частности может создаваться в различных внутренних информационных системах. Следовательно, необходимо внедрить такое ПО, которое позволило бы: (1) вносить и структурировать перечисленную выше информацию по мере исполнения и сдачи проекта (2) находить информацию по различным критериям и оперативно просматривать ее; (3) обеспечивать необходимые уровни безопасности по доступу. Здесь тоже все предельно просто: нужно внедрять систему электронного архива.

    Впрочем, нередки случаи, когда нет однозначности в определении категории ПО.
    Пример третий. В настоящее время достаточно актуальной как в России, так и в других странах является проблема постепенного перехода учреждений здравоохранения на электронные медицинские карты и электронные истории болезни. С одной стороны, индивидуальная медицинская карта представляет собой документ, в котором содержится информация о состоянии здоровья пациента в течении всей жизни (в качестве подтверждения этой информации используются рентгеновские снимки, кардиограммы, томограммы и т. п.). С другой — карта находится в постоянном движении; по мере обращения пациента к врачам-специалистам в нее вносятся новые записи. Какое ПО следует внедрить в данном случае? Конечно, для автоматизации медицинского делопроизводства вполне можно воспользоваться системой электронного документооборота (и такие рекомендации действительно даются в некоторых публикациях). Но к электронным медицинским картам и историям болезни неизбежно придется присоединять большое количество объемных, «тяжелых» файлов (например, оцифрованные рентгеновские снимки). Для решения описанных проблем необходимо такое ПО, которое: (1) позволяет создавать и редактировать карты; (2) автоматизирует движение карты по определенным маршрутам и (3) обеспечивает защищенное структурированное хранение всех прикрепленных к карте материалов. Для определения категории ПО в таком случае необходимо расставить приоритеты по задачам. Когда приоритеты расставлены, значительно проще определиться с функциональностью, которая требуется от системы. Если объем данных по картам достаточно велик (гигабайты разнородной информации) и основной упор в работе делается на хранение, поиск и просмотр информации по картам пациентов, а вопросы изменения карты не подразумевают ее движение по часто меняющимся маршрутам, то система управления записями (электронный архив в российской терминологии), включающая при этом дополнительный набор функций для оперативной работы, здесь была к месту. Если карта подразумевает большей частью набор текстовой информации без нагрузки ее копиями других документов, а основной работой является ее создание, изменение и согласование, то система электронного документооборота с легкостью решит данную задачу.

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

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

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

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

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

    Кроме того, стоит обратить внимание на то, как система работает с файлами. Возможно два варианта: двух- и трехзвенная архитектуры могут хранить файлы в самой СУБД. Что происходит в такой ситуации? С одной стороны, решение простое — все отдается на откуп СУБД, которая сама хранит всю информацию, обрабатывает, осуществляет ее резервное копирование, восстановление и пр. Но при работе с большими объемами информации возникают многочисленные проблемы эксплуатационного характера. Нередко бывает так, что ресурсов одной машины становится недостаточно. В таких случаях приходится переводить работу СУБД в кластерный режим, использующий ресурсы нескольких машин. При использовании платных СУБД это приводит к существенным дополнительным расходам. СУБД, работающая в кластере, возможно, и более надежна, но это в то же время не отменяет необходимости создавать резервные копии. И тут велика вероятность возникновения проблемы, решения практически не имеющей: размер бэкап-файлов достигает такой величины, что создавать, хранить, а затем и восстанавливать их становится невозможно.

    Некоторые поставщики в качестве возможного решения проблемы «разбухания» базы данных предлагают использовать механизмы частичного бэкапирования, предполагающие резервное копирование части данных с последующим удалением их из СУБД. Однако данное решение представляется неприемлемым уже хотя бы потому, что в системе, предназначенной для хранения бизнес-значимой информации, ненужных (т. е. тех, которые можно просто взять — и удалить) частей просто-напросто быть не может! Кроме того, если разные части базы данных физически удалены из системы (лежат где-то в резервной копии), то сквозной поиск невозможен и сама идея электронного архива теряет смысл.
    При использовании обеих архитектур возможно организовать хранение файлов вне СУБД, что решает проблемы с огромными размерами СУБД – их просто очень сложно достичь. Однако в подобных системах следует обратить внимание на способ доступа к файлам. В двухзвенной архитектуре можно предоставить клиенту только напрямую ссылку на файл, но это может привести к нарушению политик безопасности. В трехзвенной системе можно также предоставлять прямую ссылку, однако более надежными системами считаются те, которые проксируют сквозь себя запрашиваемые файлы, что исключает возможность обойти систему безопасности. Проксирование в двухзвенной архитектуре нечем осуществлять.

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

    Второе — при выборе системы следует также обращать внимание и на используемые в реализации системы технологии. Следует учитывать, что все системы имеют как плюсы, так и минусы тех технологических платформ, на основе которых они реализованы. Так, существенным минусом всех решений от Microsoft является привязка к определенной операционной платформе с невозможностью мигрирования на другие платформы, например, под Linux, невысокий уровень безопасности, повышенная чувствительность к нагрузкам и высокая суммарная стоимость владения всем решением (а не стоимостью конкретной системы) при высокой скорости разработки решений на их основе и большом количестве специалистов, знающих данные технологии на приемлемом уровне. В то же время, системы на основе J2EE более надежны, не привязаны к определенной платформе, но в то же время они более требовательны к аппаратным ресурсам, в частности к оперативной памяти, что правда в настоящее время благодаря бурному развитию аппаратных средств и существенному их удешевлению перестает быть проблемой. Кроссплатформенность решения дает клиенту свободу в части использования системного и сопутствующего ПО, что приводит к снижению стоимости владения системой за счет использования открытого и бесплатного ПО, например, операционных систем Unix/Linux, СУБД Postgress и пр. open source-сных продуктов и систем.

    На основании вышесказанного можно сформулировать следующие практические рекомендации по выбору ECM-системы:
    • Перед выбором системы четко сформулируйте цели компании и задачи, которые могут быть решены системой.
    • Определившись с целями и задачами, переходите к определению категории ПО. При выборе категории используйте перечень необходимых для решения ваших задач функций (здесь можно руководствоваться стандартами) и их приоритеты друг относительно друга.
    • Определившись с категорией ПО можно приступать к выбору конкретного решения, где основное внимание надо уделить уже не тому ЧТО может делать система, а тому КАК она это делает.
    • При оценке системы кроме функционального соответствия следует обратить особое внимание на следующие параметры: архитектура, используемые технологии, совокупная стоимость владения системы. Так как они в длительной перспективе определяют возможность использования ПО.


    Удачного выбора!
    ALEE Software
    42,00
    ПО стандартизации и управления качеством
    Поделиться публикацией

    Комментарии 4

      –3
      1.
      Для получения данных клиенту предоставляется прямой доступ к СУБД, что может привести к несанкционированному доступу к данным и нарушению их целостности


      Вот эта фраза отражает уровень квалификации автора.

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

      Как вы себе это представляете? Договоры в ECM, а отгрузки по нему в ERP. Очень интересно.
      В компании должен быть один продукт, в который интегрировано максимально количество бизнес-процессов.

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


      Без комментариев. Она конечно может и позволяет, только почему это позволяет делать ТОЛЬКО трехзвенная? Видимо, потому что ваша компания как раз и производит трехзвенку. Такое случайное совпадение :-))))
        +3
        Следуя вашей логике, кроме карьерных самосвалов никакого транспорта больше и не должно существовать, хотя нет, поправлюсь в вашем представлении в компаниях должен быть один универсальный вид транспорта, что-то то типа грузопассажирской газели и на ней будут ездить и директор и сотрудники и заодно руду возить:)

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

        Договоры и первичка — отдельная тема, но и их не особо любят заливать в учетные системы. Или в вашей AVA ERP все замечательно крутится? Если да, то какой максимальный объем документов, не просто вордовских исходников, а сканов с живыми печатями и подписями вы туда пробовали заливать?

        А по поводу двух-, трех- или четырехзвенности клиент-серверных архитектур, конечному клиенту глубоко наплевать, главное чтобы система выполняла свои задачи быстро и корректно.
          +2
          P.S. Александр, если я правильно понимаю, ваше негодование больше относится к появлению статьи по ECM в разделе ERP? Иначе мне сложно понять ваши гневные нападки на автора и его компанию.
            +1
            Я сделаю критическое заявление: обсирать других людей проще всего.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое