 |
| | Источник: ЭльАрхиво
 В предыдущей публикациимы описали различия между двумя типами программного обеспечения — системами управления документами и системами управления записями. Сегодняшняя публикация посвящена анализу очень важного практического вопроса: как выбрать систему, наиболее подходящую для решения конкретных задач конкретной организации. Сразу же отметим, что мы не собираемся склонить читателей к выбору какой-то определенной системы. Мы ставим перед собой задачу иного плана и хотим попытаться сформулировать методологические принципы, на основе которых можно подобрать необходимое программное решение.
В этой статье мы сознательно акцентируем внимание на моментах, о которых вендоры, как правило, предпочитают не говорить. А между тем от этих моментов напрямую зависит корректное функционирование системы и возможность ее использования для решения вполне конкретных практических задач.
Начнем с замечаний общего характера. Как правило, внедрению программного обеспечения предшествует осознание того, что перед организацией стоит некоторая проблема, решение которой позволит сделать ее работу более эффективной и результативной. После осознания и прояснения проблем начинается поиск путей их решения. Как правило, решение заключается в оптимизации тех или иных аспектов деятельности организации. Во многих случаях работу можно существенно улучшить за счет автоматизации, ради которой и осуществляется внедрение соответствующего ПО. Процесс выбора можно условно разделить на несколько этапов. Сперва необходимо определиться с категорией внедряемого ПО. Эта задача не так проста, как может показаться на первый взгляд. Приведем ряд практических примеров.
Пример первый. В некоторой организации для утверждения контрактов необходимо получить согласование от 3 -10 ответственных лиц. Учитывая, что все эти лица находятся территориально удаленно друг от друга, процесс согласования контракта существенно растянут во времени, что мешает компании оперативно решать вопросы согласования и подписания контрактов, и создает ряд трудностей при работе с клиентами и поставщиками. Следовательно, необходимо внедрить такое ПО, которое позволяло бы: (1) создавать контракты; (2) автоматизировать движение контрактов по определенному маршруту и при необходимости этот маршрут изменять; (3) поддерживать процедуру подписания; (4) хранить все версии документа по процессу согласования и конечную подписанную версию. Для решения поставленных задач в данном примере идеальным образом подойдет система электронного документооборота.
Пример второй. В строительной организации предполагается автоматизировать процессы систематизации и хранения всей информации, получаемой и создаваемой в процессе выполнения проекта. Информация разнообразна по типам и форматам, обширна в объемах: конкурсная документация, контракты и приказы, проектная и рабочая документации на строительство и изменения к ним, сметы и изменения к ним, ПОР, ПОС и ППР, акты освидетельствования, заключения, фото и видеоматериалы, и другая необходимая документация. Она может быть в любой момент затребована подрядчиками, субподрядчиками, контролирующими и проверяющими процесс строительства и приемки организациями. Указанная документация собирается по мере исполнения проекта, поступает как из внешних источников, так и является результатом внутренних работ, в частности может создаваться в различных внутренних информационных системах. Следовательно, необходимо внедрить такое ПО, которое позволило бы: (1) вносить и структурировать перечисленную выше информацию по мере исполнения и сдачи проекта (2) находить информацию по различным критериям и оперативно просматривать ее; (3) обеспечивать необходимые уровни безопасности по доступу. Здесь тоже все предельно просто: нужно внедрять систему электронного архива.
Впрочем, нередки случаи, когда нет однозначности в определении категории ПО.
Пример третий. В настоящее время достаточно актуальной как в России, так и в других странах является проблема постепенного перехода учреждений здравоохранения на электронные медицинские карты и электронные истории болезни. С одной стороны, индивидуальная медицинская карта представляет собой документ, в котором содержится информация о состоянии здоровья пациента в течении всей жизни (в качестве подтверждения этой информации используются рентгеновские снимки, кардиограммы, томограммы и т. п.). С другой — карта находится в постоянном движении; по мере обращения пациента к врачам-специалистам в нее вносятся новые записи. Какое ПО следует внедрить в данном случае? Конечно, для автоматизации медицинского делопроизводства вполне можно воспользоваться системой электронного документооборота (и такие рекомендации действительно даются в некоторых публикациях). Но к электронным медицинским картам и историям болезни неизбежно придется присоединять большое количество объемных, «тяжелых» файлов (например, оцифрованные рентгеновские снимки). Для решения описанных проблем необходимо такое ПО, которое: (1) позволяет создавать и редактировать карты; (2) автоматизирует движение карты по определенным маршрутам и (3) обеспечивает защищенное структурированное хранение всех прикрепленных к карте материалов. Для определения категории ПО в таком случае необходимо расставить приоритеты по задачам. Когда приоритеты расставлены, значительно проще определиться с функциональностью, которая требуется от системы. Если объем данных по картам достаточно велик (гигабайты разнородной информации) и основной упор в работе делается на хранение, поиск и просмотр информации по картам пациентов, а вопросы изменения карты не подразумевают ее движение по часто меняющимся маршрутам, то система управления записями (электронный архив в российской терминологии), включающая при этом дополнительный набор функций для оперативной работы, здесь была к месту. Если карта подразумевает большей частью набор текстовой информации без нагрузки ее копиями других документов, а основной работой является ее создание, изменение и согласование, то система электронного документооборота с легкостью решит данную задачу.
Исходя из приведенных примеров, можно отметить: определившись с задачами компании и их приоритетами, следует переходить к определению категории ПО. В затруднительных случаях рекомендуется обращаться к стандартам, с помощью которых можно прояснить базовую функциональность. Определившись с категорией ПО следует переходить к выбору конкретного решения (т.е ПО) и соответственно его поставщика.
При выборе конкретного ПО следует в первую очередь обращать внимание не только на то, ЧТО именно может делать система, т.е. функциональность (это уже было неоднократно определено и в процессе определения категории ПО и по стандартам), но еще на то, КАК реализованы те или иные требуемые функции. Ответ на вопрос «как?» вряд ли можно найти в стандартах. Более того, его вообще сложно отыскать в каких-либо открытых источниках. При ответе на этот вопрос необходимо проводить испытания ПО, используя демо-версии или пробные версии системы, что позволит оценить, конечно в определенных пределах, КАК реализованы те или иные функции и отсеять неудобные или несоответствующие вам системы.
Помимо способа реализации тех или иных функций следует учитывать ряд аспектов, весьма существенных для успешной работы выбранного ПО, но которым в то же время мало кто уделяет внимание. Такими аспектами в первую очередь являются архитектура и технологии.
Отказ от работы с уже внедренной системой болезнен как по финансовым, организационным, так и политическим аспектам, поэтому архитектуре и технологиям в данной статье мы уделим особое внимание. Следует также учитывать, что данные особенности системы невозможно рассмотреть при работе с демо-версией, но можно выяснить при общении с разработчиком или поставщиком ПО.
Первое — следует обязательно обратить внимание на особенности архитектуры. Система может представлять собой как двухзвенную архитектуру (клиент — СУБД), так и трехзвенную (клиент-сервер-СУБД). Оба варианта имеют как свои плюсы, так и свои минусы. Если система имеет двухзвенную архитектуру, то исключается такой момент, как необходимость заниматься администрированием сервера. Средствами СУБД организуются хранение данных и распределение прав доступа к ним. Но минусом этого является организация обработки данных на стороне клиента (так называемого «толстого» клиента). Для получения данных клиенту предоставляется прямой доступ к СУБД, что может привести к несанкционированному доступу к данным и нарушению их целостности.
Трехзвенная архитектура позволяет организовывать более гибкую структуру системы безопасности и не ограничиваться возможностями СУБД, исключить несанкционированный доступ к данным и осуществлять мониторинг вносимых изменений за счет контроля сервером операций с данными, производимых клиентом.
Кроме того, стоит обратить внимание на то, как система работает с файлами. Возможно два варианта: двух- и трехзвенная архитектуры могут хранить файлы в самой СУБД. Что происходит в такой ситуации? С одной стороны, решение простое — все отдается на откуп СУБД, которая сама хранит всю информацию, обрабатывает, осуществляет ее резервное копирование, восстановление и пр. Но при работе с большими объемами информации возникают многочисленные проблемы эксплуатационного характера. Нередко бывает так, что ресурсов одной машины становится недостаточно. В таких случаях приходится переводить работу СУБД в кластерный режим, использующий ресурсы нескольких машин. При использовании платных СУБД это приводит к существенным дополнительным расходам. СУБД, работающая в кластере, возможно, и более надежна, но это в то же время не отменяет необходимости создавать резервные копии. И тут велика вероятность возникновения проблемы, решения практически не имеющей: размер бэкап-файлов достигает такой величины, что создавать, хранить, а затем и восстанавливать их становится невозможно.
Некоторые поставщики в качестве возможного решения проблемы «разбухания» базы данных предлагают использовать механизмы частичного бэкапирования, предполагающие резервное копирование части данных с последующим удалением их из СУБД. Однако данное решение представляется неприемлемым уже хотя бы потому, что в системе, предназначенной для хранения бизнес-значимой информации, ненужных (т. е. тех, которые можно просто взять — и удалить) частей просто-напросто быть не может! Кроме того, если разные части базы данных физически удалены из системы (лежат где-то в резервной копии), то сквозной поиск невозможен и сама идея электронного архива теряет смысл.
При использовании обеих архитектур возможно организовать хранение файлов вне СУБД, что решает проблемы с огромными размерами СУБД – их просто очень сложно достичь. Однако в подобных системах следует обратить внимание на способ доступа к файлам. В двухзвенной архитектуре можно предоставить клиенту только напрямую ссылку на файл, но это может привести к нарушению политик безопасности. В трехзвенной системе можно также предоставлять прямую ссылку, однако более надежными системами считаются те, которые проксируют сквозь себя запрашиваемые файлы, что исключает возможность обойти систему безопасности. Проксирование в двухзвенной архитектуре нечем осуществлять.
С архитектурой системы напрямую связана такая ее характеристика, как способность масштабирования. Существует несколько возможных технических решений проблемы масштабирования, однако в первую очередь следует обратить внимание на то, что при увеличении хранимых системой данных время отклика системы должно оставаться в допустимых (т. е. адекватных цели и конкретной ситуации использования системы) пределах. Например, доступ к одному найденному по поиску объекту в течение 10 секунд кажется незначительным, но при массовой работе такой промежуток времени может оказаться слишком длительным для комфортного использования системы. А ведь именно скорость поиска является главным свидетельством производительности системы для рядового пользователя!
Второе — при выборе системы следует также обращать внимание и на используемые в реализации системы технологии. Следует учитывать, что все системы имеют как плюсы, так и минусы тех технологических платформ, на основе которых они реализованы. Так, существенным минусом всех решений от Microsoft является привязка к определенной операционной платформе с невозможностью мигрирования на другие платформы, например, под Linux, невысокий уровень безопасности, повышенная чувствительность к нагрузкам и высокая суммарная стоимость владения всем решением (а не стоимостью конкретной системы) при высокой скорости разработки решений на их основе и большом количестве специалистов, знающих данные технологии на приемлемом уровне. В то же время, системы на основе J2EE более надежны, не привязаны к определенной платформе, но в то же время они более требовательны к аппаратным ресурсам, в частности к оперативной памяти, что правда в настоящее время благодаря бурному развитию аппаратных средств и существенному их удешевлению перестает быть проблемой. Кроссплатформенность решения дает клиенту свободу в части использования системного и сопутствующего ПО, что приводит к снижению стоимости владения системой за счет использования открытого и бесплатного ПО, например, операционных систем Unix/Linux, СУБД Postgress и пр. open source-сных продуктов и систем.
На основании вышесказанного можно сформулировать следующие практические рекомендации по выбору ECM-системы:
- Перед выбором системы четко сформулируйте цели компании и задачи, которые могут быть решены системой.
- Определившись с целями и задачами, переходите к определению категории ПО. При выборе категории используйте перечень необходимых для решения ваших задач функций (здесь можно руководствоваться стандартами) и их приоритеты друг относительно друга.
- Определившись с категорией ПО можно приступать к выбору конкретного решения, где основное внимание надо уделить уже не тому ЧТО может делать система, а тому КАК она это делает.
- При оценке системы кроме функционального соответствия следует обратить особое внимание на следующие параметры: архитектура, используемые технологии, совокупная стоимость владения системы. Так как они в длительной перспективе определяют возможность использования ПО.
Ссылка на статью на хабрахабре:
http://habrahabr.ru/company/alee/blog/138555/
|
|
| |
