Наверх

Плюсы и минусы SaaS для ECM-систем

Архив
Время чтения: 3 минуты
2
Плюсы и минусы SaaS для ECM-систем

Плюсы и минусы SaaS для ECM-систем

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

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

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

Есть и минусы. Стоимость ПО во время аренды может измениться (и, вероятнее всего, вырастет). Могут возникнуть сложности с миграцией уже накопленных в системе данных после окончания срока аренды.

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

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

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

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

Переход же на новую версию для систем, уже успешно реализующих бизнес-задачи, зачастую не будет экономически оправдан, т.к. влечет за собой больше затрат, чем бонусов (конвертация данных, переобучение сотрудников).
Добавлю свои 5 копеек. Если заказчика не устраивает вновь вводимый функционал, он не только не может отказаться от обновления, но даже просто отложить его до лучших времен.
Хочу добавить в раздел "в четвертых" - хранить где-то далеко документы с конфиденциальной информацией мало кто захочет (есть кто-то из читателей, кто согласиться хранить коды от кредитной карточки на специально выделенном сайте в зашифрованном, конечно, виде?). А на предприятии каждый пятый-десятый документ содержит такую информацию. Значит придется хранить ее в рамках ЛВС. А использовать внешнюю систему для одних данных, и внутреннюю для других не удобно, мягко говоря.
Чтобы прокомментировать, или зарегистрируйтесь